druid索引好的資料放在historical中，隨著資料規模的擴大，分離資料的需求逐漸變得迫切。druid提供了tier機制與資料載入rule機制，通過它們能很好的將資料進行分離，從而達到靈活的分布資料的目的。
tier機制
tier機制的作用是將historical節點進行分組。預設情況下所有的historical節點屬於語預設的「_default_tier」分組。但是我們能通過historical配置檔案中的「druid.server.tier」引數來指定分組。另外請注意tier只針對historical節點，而與datasource無關。
資料載入rule機制
設定了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中。
,"period":"p1d"} //load recent 1 day data into hot tier
} //load the rest data into _default_tier tier
再來看第二點，druid使用作業系統buffer機制來減少磁碟io，從而加速查詢。historical能配置自己本地快取資料使用磁碟最大容量，這是乙個很重要的引數，存放冷資料的historical機器需要乙個較大值以存放較多的資料。同樣該引數能通過historical的配置檔案指定：
druid.segmentcache.locations=為了保證查詢服務的高可用性，druid提供了資料replication機制。考慮到生產環境中機器的共性，比如是否在同一機架上，如果機架故障或斷電這一批機器將不可用。出於可用性考慮，可能有將資料分布到兩批機器上的需求。為此首先需要將兩批機器配置成不同的tier。然後配置如下rule：
,"type":"loadforever"}預設情況下所有的historical節點都在「_default_tier」中，所有的datasource都公平的使用機器資源。在機器資源有限的情況下，需要優先保證重要業務的查詢。為此可以將業務進行分離，重要業務分配較多的機器資源。思路同上首先進行分組，在配置rule：
,"type":"loadforever"} // for important datasources
,"type":"loadforever"} // for normal datasources
druid的使用場景多是一些報表類業務，報表具有很強的時效性，很多場景都只關注最近一段時間的資料，所以為了更充分的利用資源，可以將不關注的資料從druid中剔除出去。我們可以配置如下rule:
}
資料分離對查詢效率的影響
druid對資料進行查詢的優化有兩個基本的點。第一在記憶體利用上充分利用作業系統buffer減少io操作；第二在架構上採用分布式查詢樹架構，以增加查詢的並行性。以下嘗試分別從記憶體利用與架構兩個方面對比資料分離與不分離對查詢的影響。
首先架構方面，druid採用的分布式查詢樹有點類似下圖：
broker節點接收到客戶端的請求後，同是分發請求到相應的多個historical節點，historical節點首先本地查詢並聚合一次資料，傳送到borker節點，broker節點再次聚合多個historical節點傳送過來的資料，並最終返回給客戶端。在整個請求處理過程中，historical節點本地查詢資料環節占用大部分時間，所以盡量多的增加historical節點的並行度能有效縮短查詢時間。
為了達到增加查詢並行度的目的，druid盡量將時間上連續的segment分散到不同的historical節點中，演算法細節可以檢視github上相關文件。但是如果將資料進行分離，就減小了查詢時候historical的並行度。
所以就提高historical查詢並行度角度來說，分離資料後查詢效率是要降低的。
再來看記憶體利用方面，將查詢熱度最高的資料放到記憶體中能保證最優的整體查詢效率，由於作業系統buffer採用lru機制淘汰資料，所以它本身就保證了熱資料常駐記憶體的原則。如果人為將資料進行切割，如果切割得當還好，否則破壞了這個原則，對查詢效率是有影響的。
隨著業務與資料的增加，分離資料的需求在特定場景下是有的。但是分離資料後對查詢效率是有影響的，尤其在集群規模小的情況下，影響可能會較大，所以分離資料的時候需要謹慎。
以上是本人在使用druid過程中，對資料規劃方面的一點認識，由於水平有限，如有問題歡迎指正。
Druid 資料攝取
流式 實時 資料攝取 攝取配置檔案結構說明 靜態資料源 需求 攝取hdfs上的wikiticker 2019 09 12 sampled.json檔案到druid中 操作步驟 1 啟動hdfs集群 yarn集群 2 上傳 druid測試資料源 維基百科訪問日誌資料到任意伺服器 root druid ...
druid字段級 Druid的資料結構
druid的資料結構 druid資料儲存結構可以分為三層 1.datasource 2.chunk 3.segment datasource相當於傳統資料庫的按時間分割槽的表，chunk相當於mysql中的按時間分割槽的表乙個分割槽，但是chunk不是乙個實體，只是乙個虛擬的概念，乙個chunk中可...
Druid學習之路 （三）Druid的資料來源和段
druid的資料儲存在 datasource 中,這其實類似於傳統的rdbms中的表.每乙個資料來源按照時間進行分段,當然你還可以選擇其他屬性進行分段.每乙個時間區間被稱為乙個 chunk 舉個列子,一天的時間區間的chunk,如果你的資料來源是按天進行分段的 在乙個chunk內,資料被分成乙個或者...