面向時間序列的實時分析型數據庫DRUID
DRUID是一個面向時間序列數據的實時分析型數據庫。
系統設計目標：
Real-time Nodes。 Real-Time Node從kafka消費數據， 數據實時存放到Real-Time Node內存緩存， 內存數據量超過閾值時（或者定期）時，寫內存數據到外存形成外存索引。 內存數據加上多個外存索引， Real-Time Nodes以這種方式支持亞秒級數據可見性 。 Real-Time Node宕機會造成內存數據丟失， druid依賴kafka的數據回溯能力恢復數據： Real-time Node會記錄外存索引對應的kafka位置， 啟動之后從該位置繼續消費數據， 重新生成內存數據。
Real-time node的容量和查詢能力是有限的， 所以它會定期合并多個外存索引生成segment， segment對應一段時間范圍內的進入druid的數據。 segment生成之后馬上被上傳到deep storage， 很快就會有Historical Nodes下載該segment，并替代Real-time Node提供查詢服務。
</div>Historcial Nodes。 負責從DeepStorage下載segment， 提供數據查詢服務， Historical Nodes從Zookeeper獲取加載、刪除segment等基本指令， 它們之間相互不通訊。 Historical Nodes可分為多個tier， 比如熱數據放在一個tier， 冷數據放到另外一個tier，以達到冷熱數據分開處理的目的。
Broker Nodes。 查詢代理節點。 接收用戶查詢， 根據Zookeeper上的元數據信息定位查詢涉及的segment， 匯總各實時節點和歷史節點查詢結果， 返回給用戶， 并負責查詢的緩存。
Deep Storage。 存儲segment， 但是不負責查詢， Historical nodes從deep storage拉取segment。
Coordinator Nodes， 是全局協調者， 負責把segment分配給HIstorical Node以保證load balance， 負責指定segment副本個數， segment刪除策略等。
druid的查詢以HTTP/JSON形式提供， 查詢能力較為有限， 首先它不提供SQL, 其次也不提供Join。
上圖是一個查詢的例子， 對應到SQL是： select count(*) from wikipedia where date >= 2013-01-01 and date<2013-01-08 group by date。 值得一提的是， druid支持數據倉庫中常見的位圖索引。如果page維度上建有位圖索引， 可以大大減少查詢掃描的行數。
druid的設計目標之一是多租戶，多租戶的解決思路是給查詢分類， 優先執行耗時較短的探索性查詢。 看起來druid在多租戶方面沒有做太多工作， 沒有起碼的資源隔離。
</div>總結
Druid是一個面向時間序列數據的開源分布式實時分析型數據庫，基于列存和位圖索引提供良好的查詢性能， 不過列存和位圖索引都是常見技術， 查詢的性能取決于實現好差。 應用場景較為單一，且無法和hadoop生態有效結合是druid的致命弱點。
</div>參考文獻
DRUID: a realtime Analytical Data Store
</div> </div> </div> 原文 http://www.bitstech.net/2015/07/27/realtime-analytical-timeseries-druid/