Druid.io是“神馬”？

Druid.io是一個開源的，分散式的，列式儲存的，適用於實時資料分析的OLAP系統。它能夠快速聚合、靈活過濾、毫秒級查詢、和低延遲資料匯入。2011年，MetaMarkets公司為了解決廣告交易中海量實時資料的分析問題，在嘗試各種SQL和NoSQL方案後，決定自行設計並建立Druid並於2013年開源。Druid被設計成支援PB級別資料量每天處理數十億流式事件。Druid之所以保持高效有以下幾個原因：

1. 資料進行了有效的預聚合或預計算。
2. 資料結果的優化，應用了Bitmap的壓縮演算法。
3. 可擴充套件的高可用架構，靈活的支援部署和擴充套件。
4. 社群的力量，Druid開發和使用者社群保持活躍，不斷推動Druid完善和改進。

Druid叢集介紹

關於Druid的架構，我們先通過其總體設計架構圖來做一個概要了解，如下圖所示：

1. 實時節點(RealTime Node)：即時攝入資料，以及生成Segment資料檔案。
2. 歷史節點(Historical Node)：載入已經生成好的資料檔案，以供資料查詢。
3. 查詢節點(Broker Node)：對外提供資料查詢服務，並同時從實時節點與歷史節點查詢資料，合併後返回給呼叫方。
4. 協調節點(Coordinator Node)：負責歷史節點資料負載均衡，以及通過規則(Rule)來管理資料的生命週期。

叢集的外部依賴如下圖所示：

1. 元資料庫(Metastore)：儲存Druid叢集的元資料資訊，比如Segment的相關資訊，一般用MySQL或者PostgreSQL。
2. 分散式協調服務：為Druid叢集提供一致性協調服務元件，通常為Zookeeper。
3. 資料檔案儲存(DeepStorage)：存放生成的Segment資料檔案，並提供歷史節點下載。對於單節點叢集可以是本地磁碟，而對於分散式叢集一般是HDFS或NFS。

Druid實時節點

實時節點主要負責即時攝入資料，以及生成Segment檔案，其獨到的設計使其擁有超強的資料攝入速度。

Segment資料檔案從生成到傳播需要經歷一個完整的流程，步驟如下：

1. 實時節點生產出Segment資料檔案，並將其上傳到DeepStorage中。
2. Segment資料檔案的相關元資料資訊被儲存到MySQL中。實時節點轉存的Segment會在ZooKeeper中新增一條記錄
3. Master節點（即Coordinator幾點）從MetaStore裡得知Segment資料檔案的相關元資料資訊後，將其根據規則的設定分配符合條件的歷史節點。
4. 歷史節點得到指令會主動從DeepStorage中拉取指定的Segment資料檔案，並通過Zookeeper向叢集申明其負責提供該Segment資料檔案的查詢服務。
5. 實時節點丟棄該Segment資料檔案，並向叢集申明其不再提供該Segment資料檔案的查詢服務。

Druid歷史節點

歷史節點用於負責載入已經生成好的資料檔案以提供資料查詢。由於Druid的資料檔案有不可更改性，因此歷史節點的工作就是專注於提供資料查詢。

1. Coordinator在ZK與History節點相關聯的載入佇列路徑下建立一個臨時記錄。
2. 當歷史節點發現在Zookeeper中有需要載入的新的記錄。它首先檢查本地磁碟目錄（快取）中關於新的Segment的資訊。如果快取中沒有關於新的Segment的資訊，歷史節點將下載新的Segment的元資料資訊並告知Zookeeper。元資料包含新的Segment在“Deep Storage”中的儲存位置，怎樣去解壓縮和處理新的Segment的資訊。
3. 一旦歷史節點處理完一個Segment，就公佈該Segment可查詢。

Druid查詢節點

查詢節點對外提供資料查詢服務，並同時從實時節點與歷史節點查詢資料，合併後返回給呼叫方。Zookeeper維護有關歷史和實時的節點資訊和它們所能提供服務的Segment。當收某個資料來源和時間的查詢，代理節點執行查詢與查詢資料來源時間相關的時間軸和檢索包含資料查詢的節點。代理節點將查詢轉發到所選節點。

Druid協調節點

協調節點負責歷史節點的資料負載均衡，以及通過規則管理資料的生命週期。Druid針對每個DataSource設定規則來載入或者丟棄具體的資料檔案，以管理資料生命週期。可以對一個DataSource按照順序新增多條規則，對於一個Segment資料檔案來說，協調節點會逐條檢查規則，當碰到當前Segment資料檔案符合某條規則的時候，協調節點會立即命令歷史節點堆該Segment資料檔案執行這條規則——載入或者丟棄，並停止檢查餘下的規則，否則繼續檢查下一條規則。

Druid索引服務

除了通過實時節點產生出Segment資料檔案外，Druid還提供一組名為索引服務的元件。不同於實時節點的單點模式，索引服務實際包含一組元件，並以主從結構作為其架構方式，其中統治節點（Overlord Node）為主節點，而中間管理者（Middle Manager）為從節點。索引節點服務架構示意圖如下所示：

索引服務是主從結構，由三個部分組成：

1. peon元件：在一個單獨的jvm中執行單個任務，通過單獨的jvm對任務做資源隔離和日誌隔離。
2. Middle Manager：用於建立和管理peon的中層管理元件
3. overlord元件：管理任務分配到Middle Manager