druid索引好的資料放在historical中，随着資料規模的擴大，分離資料的需求逐漸變得迫切。druid提供了tier機制與資料加載rule機制，通過它們能很好的将資料進行分離，進而達到靈活的分布資料的目的。
tier機制的作用是将historical節點進行分組。預設情況下所有的historical節點屬于語預設的“_default_tier”分組。但是我們能通過historical配置檔案中的“druid.server.tier”參數來指定分組。另外請注意tier隻針對historical節點，而與datasource無關。
設定了tier之後，再給tier添加對應的資料加載rule，就能實作資料分離的目的。資料加載rule機制是進行資料分離的基礎，也是本文的重點。
rule主要分兩大類load與drop，每個大類有細分為period、interval和forever三種。其中period的意思是最近的一段時間，比如最近一天，随着時間的推移這段時間内的資料也會更疊。interval和forever分别指固定時間段與整個資料源的生命周期。
與tier不同，rule都是針對datasource的。比如我們給datasource1設定了一些rule，這些rule隻針對datasource1的資料生效，對其它datasource沒有影響。
druid應用rule遵循兩個原則：（1）按順序；（2）資料隻能應用一條rule。為了更好的解釋它們，請看以下示例：
上例中分别應用了三條rule到三個tier中，這三條rule組合後的意思是：将最近一天的資料加載到hot分組中，後兩天的資料加載到cold分組中，剩下的資料加載到default分組中。
第一天（目前天）的資料很好了解應用rule1，資料被加載到hot分組所在的historical中。因為第一天的資料已經被應用了rule1，是以rule2對第一天的資料失效，是以隻有第二第三天的資料被加載到cold分組的historical中。同理前三天的資料已經應用了rule，隻有剩餘的資料應用rule3，加載到了default分組的historical中。
随着時間的推移，新的一天的資料變成了第一天，它們被加載到hot分組的historical中，老的第一天資料被遷移到cold分組的historical中，同理cold分組前移一天的資料到default分組的historical中。
interval類型的rule很好了解不做過多的解釋。以上是druid提供的tier與rule機制，它們對管理規劃druid中的資料提供了基礎。下面我們從幾個生産環境中很可能出現的場景讨論如何對druid中的資料進行規劃。
對于大部分業務來說使用者關注的焦點都在最近一段時間内，也就是對一個較長時間段内的資料來說，資料是分冷熱的，我們需要做的是盡量保證熱資料的高效查詢。
而對于druid來說查詢的高效與否有兩個很重要的因素：（1）機器配置，主要是cpu與記憶體；（2）作業系統buffer記憶體與資料量的比例。在考慮機器成本的前提下，如果我們把這兩項資源更多的傾向于熱資料，那麼對查詢效率的提升應該是顯而易見的。到此我們已經明确了需求與大概思路，下邊看具體如何解決。
首先看第一點将最近的熱資料放在配置較好的機器中，冷資料放在較差的機器中。我們将historical進行分組：一組為"hot"（配置較好的機器，打算存放最近的熱資料）；另一組為"_default_tier"（配置較差的機器，打算存放冷資料）。然後配置如下規則，以将冷熱不同的資料加載到對應的historical中。
druid内部采用json的形式來表示，這裡約定下文的rule也都采用json的形式。但是我們給datasource設定rule的時候是通過coordinator的web console界面完成的。
再來看第二點，druid使用作業系統buffer機制來減少磁盤io，進而加速查詢。historical能配置自己本地緩存資料使用磁盤最大容量，這是一個很重要的參數，存放冷資料的historical機器需要一個較大值以存放較多的資料。同樣該參數能通過historical的配置檔案指定：
為了保證查詢服務的高可用性，druid提供了資料replication機制。考慮到生産環境中機器的共性，比如是否在同一機架上，如果機架故障或斷電這一批機器将不可用。出于可用性考慮，可能有将資料分布到兩批機器上的需求。為此首先需要将兩批機器配置成不同的tier。然後配置如下rule：
預設情況下所有的historical節點都在“_default_tier”中，所有的datasource都公平的使用機器資源。在機器資源有限的情況下，需要優先保證重要業務的查詢。為此可以将業務進行分離，重要業務配置設定較多的機器資源。思路同上首先進行分組，在配置rule：
druid的使用場景多是一些報表類業務，報表具有很強的時效性，很多場景都隻關注最近一段時間的資料，是以為了更充分的利用資源，可以将不關注的資料從druid中剔除出去。我們可以配置如下rule:
上例的兩個rule保留最近3天的資料，其它的則從druid（也就是historical）中删掉。删掉的隻是druid本地緩存的資料，deep storage中的資料沒有删掉。是以有一天删掉這兩個rule，druid又會将資料加載回來。特别注意這兩個rule的順序，反過來的話會删掉druid中所有的資料。
druid對資料進行查詢的優化有兩個基本的點。第一在記憶體利用上充分利用作業系統buffer減少io操作；第二在架構上采用分布式查詢樹架構，以增加查詢的并行性。以下嘗試分别從記憶體利用與架構兩個方面對比資料分離與不分離對查詢的影響。
首先架構方面，druid采用的分布式查詢樹有點類似下圖：
broker節點接收到用戶端的請求後，同是分發請求到相應的多個historical節點，historical節點首先本地查詢并聚合一次資料，發送到borker節點，broker節點再次聚合多個historical節點發送過來的資料，并最終傳回給用戶端。在整個請求處理過程中，historical節點本地查詢資料環節占用大部分時間，是以盡量多的增加historical節點的并行度能有效縮短查詢時間。
是以就提高historical查詢并行度角度來說，分離資料後查詢效率是要降低的。
再來看記憶體利用方面，将查詢熱度最高的資料放到記憶體中能保證最優的整體查詢效率，由于作業系統buffer采用lru機制淘汰資料，是以它本身就保證了熱資料常駐記憶體的原則。如果人為将資料進行切割，如果切割得當還好，否則破壞了這個原則，對查詢效率是有影響的。
随着業務與資料的增加，分離資料的需求在特定場景下是有的。但是分離資料後對查詢效率是有影響的，尤其在叢集規模小的情況下，影響可能會較大，是以分離資料的時候需要謹慎。
以上是本人在使用druid過程中，對資料規劃方面的一點認識，由于水準有限，如有問題歡迎指正。