Druid ：大數據實時處理的開源分佈式系統（1）

引言

Druid 是一個快速，近實時的查詢海量只讀數據的系統。Druid 的目標是可用性要達到100%，即便在部署新代碼，或者某些節點 down 機的狀況下。

Druid 目前支持的單表查詢方式和 Dremel，PowerDrill 比較類似。它的主要特性以下：

1．支持嵌套數據的列式存儲
2．層級查詢
3．二級索引
4．實時數據抽取
5．分佈式容錯架構

同 PowerDrill 和 Dremel 相比，從功能的角度來講，Druid 幾乎實現了 Dremel 提供的全部功能，而且參考了 PowerDrill 的數據存儲和壓縮方法。

Druid很是適合須要實時從一個數據流中攝取大量數據的產品。特別的，若是您但願零宕機，而且您的數據是時間序列數據，就再適合不過了。如何您更須要查詢的靈活性和原始數據，那 Druid 就不是一個很好地選擇。

架構

Druid 是由一系列不一樣角色的組件組成的系統。不一樣的組件以下：

歷史節點（Historical Node）：

該節點負責存儲數據和查詢。歷史節點從深度存儲中下載數據分片（segment），而且響應來自查詢節點的查詢。歷史節點會按期刷新自己存貯的 數據分片信息到 zookeeper，而且經過 zookeeper獲得須要加載或者卸載哪些數據分片。

實時節點（Realtime Node）:

實時節點負責攝取實時數據。它們負責監聽一個數據流，並把數據發到 Druid 系統當中。實時節點也接受來自查詢節點的查詢，並把結果返回。實時節點會把歷史數據寫到深度存儲中。實時節點會查詢 zookeeper，並確認當前存儲在實時節點的數據分片是否已經上傳至歷史節點。若是已經上傳，實時節點將刪除該數據分片。

協調節點（coordinator node）:

協調節點會監控全部的歷史節點，確保全部數據是可用的，多副本的。協調節點會從存儲 meta data 數據源中讀取 meta data 信息，去決定哪些數據分片應該在 druid 集羣當中。協調節點用 zookeeper 發現哪些歷史節點存在，而且經過 zookeeper 去通知歷史節點裝載和卸載相應的數據分片。

查詢節點（broker node）:

查詢節點接受從客戶端來的查詢，並轉發這些查詢到實時節點和歷史節點。查詢節點獲得分別來自實時節點和歷史節點的數據後，對這些數據進行合併，而後返回給客戶端。查詢節點也是利用zookeeper 去發現實時和歷史節點的存在。

這種節點劃分方式使得不一樣節點只須要處理好本身擅長的事情。

下面是在這個架構下地數據流圖：

下面這張圖，顯示的是 Druid 集羣是如何運做管理的，顯示了節點之間是如何經過 meta data 進行協調運做的

（未完待續）

---

OneAPM Mobile Insight 以真實用戶體驗爲度量標準進行 Crash 分析，監控網絡請求及網絡錯誤，提高用戶留存。訪問 OneAPM 官方網站感覺更多應用性能優化體驗，想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。