Druid 實時數據分析存儲系統

簡介

Druid 是一個開源的，分佈式的，列存儲的，適用於實時數據分析的存儲系統，可以快速聚合、靈活過濾、毫秒級查詢、和低延遲數據導入。

 

• Druid在設計時充分考慮到了高可用性，各類節點掛掉都不會使得druid中止工做（可是狀態會沒法更新）；

• Druid中的各個組成部分之間耦合性低，若是不須要實時數據徹底能夠忽略實時節點；

• Druid使用Bitmap indexing加速列存儲的查詢速度，並使用CONCISE算法來對bitmap indexing進行壓縮，使得生成的segments比原始文本文件小不少；

架構

總體架構

Druid集羣包含不一樣類型的節點，而每種節點都被設計來作好某組事情。這樣的設計能夠隔離關注並簡化整個系統的複雜度。

不一樣節點的運轉幾乎都是獨立的而且和其餘的節點有着最小化的交互，所以集羣內的通訊故障對於數據可用性的影響很是小。

Druid集羣的構成和數據流向如圖1所示：

 

（圖1）

Druid 自己包含了五種節點 ： Realtime、Historical、Coordinator、Broker、Indexer

• Historical 歷史節點是進行存儲和查詢的「歷史」數據（非實時）的工做區，它會從深存儲區(Deep Storage)中加載數據段(Data/Segments)，響應 Broker 節點的查詢請求並返回結果。歷史節點一般會在本機同步深存儲區上的部分數據段，因此即便深存儲區不可訪問了，歷史節點仍是能查詢到已經同步的數據段。

• Realtime 實時節點是進行存儲和查詢實時數據的工做區，它也會響應Broker節點的查詢請求並返回結果 。實時節點會按期地將數據創建成數據段移到歷史節點中。

• Coordinator 協調節點能夠認爲是Druid中的master，它經過Zookeeper管理歷史節點和實時節點，且經過Mysql中的metadata管理數據段。

• Broker節點負責響應外部的查詢請求，經過查詢Zookeeper將請求分別轉發給歷史節點和實時節點，最終合併並返回查詢結果給外部， 由Broker節點經過zookeeper決定哪些歷史節點和實時節點提供服務。

• Indexer 索引節點負責數據導入，加載批次和實時數據到系統中，並能夠修改存儲到系統中的數據 。

 

Druid 包含3個外部依賴 ：Mysql、Deep storage、Zookeeper

 

• Mysql：存儲關於Druid中的metadata而不是存儲實際數據，包含3張表：」druid_config」（一般是空的）, 「druid_rules」（協做節點使用的一些規則信息，好比哪一個segment從哪一個node去load）和「druid_segments」（存儲每一個segment的metadata信息）；

• Deep storage: 存儲segments，Druid目前已經支持本地磁盤，NFS掛載磁盤，HDFS，S3等。Deep Storage的數據有2個來源，一個是批數據攝入, 另外一個來自實時節點；

• ZooKeeper: 被Druid用於管理當前cluster的狀態，好比記錄哪些segments從實時節點移到了歷史節點；

實時節點

實時節點封裝了導入和查詢事件數據的功能，經由這些節點導入的事件數據能夠馬上被查詢。實時節點只關心一小段時間內的事件數據，並按期把這段時間內收集的這批數據導入到深存儲區裏。實時節點經過Zookeeper來宣佈它們的在線狀態和它們提供的數據。

（圖2）

如圖2，實時節點緩存事件數據到內存中的索引上，而後有規律的持久化到磁盤上。在轉移以前，持久化的索引會週期性地合併在一塊兒。查詢會同時命中內存中的和已持久化的索引。全部的實時節點都會週期性的啓動後臺的計劃任務搜索本地的持久化索引，後臺計劃任務將這些持久化的索引合併到一塊兒並生成一塊不可變的數據，這些數據塊包含了一段時間內的全部已經由實時節點導入的事件數據，稱這些數據塊爲」Segment」。在傳送階段，實時節點將這些segment上傳到一個永久持久化的備份存儲中，一般是一個分佈式文件系統，例如S3或者HDFS，稱之爲」Deep Storage」(深存儲區)。

歷史節點

歷史節點遵循shared-nothing的架構，所以節點間沒有單點問題。節點間是相互獨立的而且提供的服務也是簡單的，它們只須要知道如何加載、刪除和處理Segment。相似於實時節點，歷史節點在Zookeeper中通告它們的在線狀態和爲哪些數據提供服務。加載和刪除segment的指令會經過Zookeeper來進行發佈，指令會包含segment保存在deep storage的什麼地方和怎麼解壓、處理這些segment的相關信息。

（圖3）

如圖3，在歷史節點從深存儲區下載某一segment以前，它會先檢查本地緩存信息中看segment是否已經存在於節點中，若是segment還不存在緩存中，歷史節點會從深存儲區下載segment到本地。這階段處理完成，這個segment就會在Zookeeper中進行通告。此時，這個segment就能夠被查詢了，查詢以前須要將segment加載到內存中。

 

協調節點

 

協調節點主要負責Segment的管理和在歷史節點上的分佈。協調節點告訴歷史節點加載新數據、卸載過時數據、複製數據、和爲了負載均衡移動數據。Druid爲了維持穩定的視圖，使用一個多版本的併發控制交換協議來管理不可變的segment。若是任何不可變的segment包含的數據已經被新的segment徹底淘汰了，則過時的segment會從集羣中卸載掉。協調節點會經歷一個leader選舉的過程，來決定由一個獨立的節點來執行協調功能，其他的協調節點則做爲冗餘備份節點。

Broker節點

Broker節點是歷史節點和實時節點的查詢路由。Broker節點知道發佈於Zookeeper中的segment的信息，Broker節點就能夠將到來的查詢請求路由到正確的歷史節點或者是實時節點，Broker節點也會將歷史節點和實時節點的局部結果進行合併，而後返回最終的合併後的結果給調用者。Broker節點包含一個支持LRU失效策略的緩存。

（圖4）

如圖4，每次Broker節點接收到查詢請求時，都會先將查詢映射到一組segment中去。這一組肯定的segment的結果可能已經存在於緩存中，而不須要從新計算。對於那些不存在於緩存的結果，Broker節點會將查詢轉發到正確的歷史節點和實時節點中去，一旦歷史節點返回結果，Broker節點會將這些結果緩存起來以供之後使用，這個過程如圖6所示。實時數據永遠不會被緩存，所以查詢實時節點的數據的查詢請求老是會被轉發到實時節點上去。實時數據是不斷變化的，所以緩存實時數據是不可靠的。

Indexer節點

索引服務是運行索引任務相關的高可用性，分佈式的服務。索引服務建立（有時破壞）Druid的Segment。索引服務有一個相似主/從的架構。

 

（圖5）

 

索引服務是由三個主要部分組成：能夠運行單個任務的peon組件，用於管理peon的中層管理組件，以及管理任務分配到中層管理組件的overlord組件。overlord組件和中層管理組件能夠在同一節點上或跨多個節點上運行，而中層管理組件和peon組件老是相同的節點上運行。

ZooKeeper 

Druid 使用ZooKeeper（ZK）管理當前集羣狀態，在ZK上發生的操做有：

 

1.協調節點的leader選舉

2.歷史和實時節點發布segment協議

3.協調節點和歷史節點之間的segment Load/Drop協議

4.overlord的leader選舉

5.索引服務任務管理

 

Druid vs 其餘系統

 

Druid vs Impala/Shark

Druid和Impala、Shark 的比較基本上能夠歸結爲須要設計什麼樣的系統

Druid被設計用於：

1. 一直在線的服務

2. 獲取實時數據

3. 處理slice-n-dice式的即時查詢
   

查詢速度不一樣：

• Druid是列存儲方式，數據通過壓縮加入到索引結構中，壓縮增長了RAM中的數據存儲能力，可以使RAM適應更多的數據快速存取。索引結構意味着，當添加過濾器來查詢，Druid少作一些處理，將會查詢的更快。

• Impala/Shark能夠認爲是HDFS之上的後臺程序緩存層。 可是他們沒有超越緩存功能，真正的提升查詢速度。

數據的獲取不一樣：

• Druid能夠獲取實時數據。

• Impala/Shark是基於HDFS或者其餘後備存儲，限制了數據獲取的速度。

查詢的形式不一樣：

• Druid支持時間序列和groupby樣式的查詢，但不支持join。

• Impala/Shark支持SQL樣式的查詢。

 

Druid vs Elasticsearch

Elasticsearch(ES) 是基於Apache Lucene的搜索服務器。它提供了全文搜索的模式，並提供了訪問原始事件級數據。 Elasticsearch還提供了分析和彙總支持。根據研究，ES在數據獲取和彙集用的資源比在Druid高。

Druid側重於OLAP工做流程。Druid是高性能（快速彙集和獲取）以較低的成本進行了優化，並支持普遍的分析操做。Druid提供告終構化的事件數據的一些基本的搜索支持。

 

Druid vs Spark

Spark是圍繞彈性分佈式數據集（ RDD ）的概念，創建了一個集羣計算框架，能夠被看做是一個後臺分析平臺。 RDD啓用數據複用保持中間結果存在內存中，給Spark提供快速計算的迭代算法。這對於某些工做流程，如機器學習，相同的操做可應用一遍又一遍，直到有結果後收斂尤爲有益。Spark提供分析師與不一樣算法各類各樣運行查詢和分析大量數據的能力。

Druid重點是數據獲取和提供查詢數據的服務，若是創建一個web界面，用戶能夠隨意查看數據。

 

引用

論文： Druid A Real-time Analytical Data Store 

官方文檔：http://druid.io/docs/0.8.1/design/index.html