Druid學習筆記（1）Druid介紹與基本概念
概述
隨著網際網路快速發展，資料量增長快，達到TB、PB，以交通車流量為例，如湖南省每月的車輛流量至少達到4億，這個資料量遠不止如此。資料量如此大，如何滿足後期分析，傳統面向OLTP型資料庫（ORACLE、MYSQL等）無法要求，漸漸開始轉向OLAP，如GreenPlum等，雖然很多OLAP資料庫吸收分散式計算思想，資料達到20億以上後，進行Count、聚合等操作效能仍然達不到客戶實時分析要求。
雖然相關大資料框架及元件已經很流行：Hadoop（離線分析）、Spark、storm、Hive、Impala、Hbase等，Hadoop生態系統大龐大，Spark一站式安裝部署，但是滿足實時分析還需藉助其它元件、開發要求很高。
Druid是一個用於大資料實時查詢和分析的高容錯、高效能開源分散式時序資料庫系統，旨在快速處理大規模的資料，並能夠實現快速查詢和分析。尤其是當發生程式碼部署、機器故障以及其他產品系統遇到宕機等情況時，Druid仍能夠保持100%正常執行。建立Druid的最初意圖主要是為了解決查詢延遲問題，當時試圖使用Hadoop來實現互動式查詢分析，但是很難滿足實時分析的需要。而Druid提供了以互動方式訪問資料的能力，並權衡了查詢的靈活性和效能而採取了特殊的儲存格式。
Druid適用場景
Druid應用最多的是類似於廣告分析創業公司Metamarkets中的應用場景，如廣告分析、網際網路廣告系統監控以及網路監控等。當業務中出現以下情況時，Druid是一個很好的技術方案選擇：
- 需要互動式聚合和快速探究大量資料時；
- 需要實時查詢分析時；
- 具有大量資料時，如每天數億事件的新增、每天數10T資料的增加；
- 對資料尤其是大資料進行實時分析時；
- 需要一個高可用、高容錯、高效能資料庫時
Druid資料
Druid是一個開源的資料儲存設計的事件資料的OLAP查詢，提供一個高層次的概述如何儲存資料和Druid叢集的體系結構。
資料樣例
timestamp publisher advertiser gender country click price
2011-01-01T01:01:35Z bieberfever.com 資料集由三個不同的元件組成：
時間序列化列：以時間序列進行資料分片，所有查詢以時間為中心軸。
維度列：Druid基於列式儲存，查詢結果展示列，常用於資料過濾，如示例資料集有四個維度:出版商，廣告商，性別和國家。
聚合列：通常用於計算值，操作方法如：COUNT、SUM等。
Druid 聚合
上述例子資料集中的單條資訊作用不大，因為這樣的資料萬億。然而這種型別的資料研究概述可以產生經濟效益。Druid使用我們稱之為“聚合”的過程對這些原始資料聚合操作，類似（虛擬碼）如下：
GROUP BY timestamp, publisher, advertiser, gender, country
:: impressions = COUNT(1), clicks = SUM(click), revenue = SUM(price) 在實踐中我們看到聚合資料可以大大減少需要被儲存的資料的大小（高達100倍）。減少儲存確實是以成本為代價的，聚合資料後無法查詢單個數據的能力；另一種解決方式減少聚合粒度，儘量滿足查詢資料的最小粒度。因此Druid通過queryGranularity方法(或屬性granularity)定義這個粒度查詢資料，最低支援為毫秒。
通過上述虛擬碼聚合後的資料：
timestamp publisher advertiser gender country impressions clicks revenue
2011-01-01T01:00:00Z ultratrimfast.com google.com Male USA 1800 25 15.70
2011-01-01T01:00:00Z bieberfever.com google.com Male USA 2912 42 29.18
2011-01-01T02:00:00Z ultratrimfast.com google.com Male UK 1953 17 17.31
2011-01-01T02:00:00Z bieberfever.com google.com Male UK 3194 170 34.01
Druid 分片資料
Druid的分片稱之為Segment（即段），通常按時間對資料進行分片。如對示例資料進行壓縮，我們可以建立兩個段，按每小時分片。
段是儲存時間間隔內資料，段包含按列儲存的資料以及這些列的索引，Druid查詢索引掃描段。段由資料來源、間隔、版本的唯一標識，和一個可選的分割槽號。段命名規範如：
datasource_interval_version_partitionnumber
例如：
Segment sampleData_2011-01-01T01:00:00:00Z_2011-01-01T02:00:00:00Z_v1_0 contains
2011-01-01T01:00:00Z ultratrimfast.com google.com Male USA 1800 25 15.70
2011-01-01T01:00:00Z bieberfever.com google.com Male USA 2912 42 29.18Segment sampleData_2011-01-01T02:00:00:00Z_2011-01-01T03:00:00:00Z_v1_0 contains
2011-01-01T02:00:00Z ultratrimfast.com google.com Male UK 1953 17 17.31
2011-01-01T02:00:00Z bieberfever.com google.com Male UK 3194 170 34.01Druid 索引資料
Druid查詢速度取決於如何儲存資料。從搜尋基礎架構借用想法，Druid建立只讀資料快照，查詢分析儲存在高度優化的資料結構。
Druid是一個列儲存，每列被單獨儲存。Druid查詢相當好，是因為只查詢所需的列。不同的列還可以採用不同的壓縮方式，不同的列也可以有與它們相關的不同的索引。
Druid 索引資料在資料分片級別上。
Druid 資料載入
Druid有兩方式獲取資料，實時和批量，Druid實時獲取很費勁，確切的說Druid不能保證實時獲取。批量獲取可以保證批量建立段及相應資料。Druid通常採用實時管道獲取實時資料（最近資料），採用批管道獲取副本資料。
Druid 資料查詢
Druid的本地查詢語言是JSON通過HTTP，雖然社群在眾多的語言中提供了查詢庫，包括SQL查詢貢獻庫；Druid設計用於單表操作，目前不支援聯接
Druid 叢集
Druid是由不同角色的系統構建而成的一個整體系統，它的名字來自在許多角色扮演遊戲中的Druid類：它是一個shape-shifter，可以在一個群組中採取許多不同的形式來滿足各種不同的角色。Druid的整體架構中目前包括以下節點型別：
- Historical
對“historical”資料（非實時）進行處理儲存和查詢的地方。historical節點響應從broker節點發來的查詢，並將結果返回給broker節點。它們在Zookeeper的管理下提供服務，並使用Zookeeper監視訊號載入或刪除新資料段。
- Realtime
實時攝取資料，它們負責監聽輸入資料流並讓其在內部的Druid系統立即獲取，Realtime節點同樣只響應broker節點的查詢請求，返回查詢結果到broker節點。舊資料會被從Realtime節點轉存至Historical節點。
- Coordinator
監控historical節點組，以確保資料可用、可複製，並且在一般的“最佳”配置。它們通過從MySQL讀取資料段的元資料資訊，來決定哪些資料段應該在叢集中被載入，使用Zookeeper來確定哪個historical節點存在，並且建立Zookeeper條目告訴historical節點載入和刪除新資料段。
- Broker
接收來自外部客戶端的查詢，並將這些查詢轉發到Realtime和Historical節點。當Broker節點收到結果，它們將合併這些結果並將它們返回給呼叫者。由於瞭解拓撲，Broker節點使用Zookeeper來確定哪些Realtime和Historical節點的存在。
- Indexer
節點會形成一個載入批處理和實時資料到系統中的叢集，同時會對儲存在系統中的資料變更（也稱為索引服務）做出響應。這種分離讓每個節點只關心自身的最優操作。通過將Historical和Realtime分離，將對進入系統的實時流資料監控和處理的記憶體分離。通過將Coordinator和Broker分離，把查詢操作和維持叢集上的“好的”資料分佈的操作分離。
資料流和各個節點的關係如下圖:
相關節點和叢集管理所依賴的其他元件（Zookeeper）如下：
高可用
Druid為高可用架構，不會存在單點故障，一種節點出現問題後，其他節點的服務也不會受到影響。