Druid 實時數據分析存儲系統

jopen 9年前發布 | 20K 次閱讀 Druid 分布式/云計算/大數據

簡介

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

 

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

  • Druid中的各個組成部分之間耦合性低，如果不需要實時數據完全可以忽略實時節點；

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


架構

整體架構

Druid集群包含不同類型的節點，而每種節點都被設計來做好某組事情。這樣的設計可以隔離關注并簡化整個系統的復雜度。

不同節點的運轉幾乎都是獨立的并且和其他的節點有著最小化的交互，因此集群內的通信故障對于數據可用性的影響非常小。

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

 

Druid 實時數據分析存儲系統

（圖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來宣布它們的在線狀態和它們提供的數據。

Druid 實時數據分析存儲系統（圖2）

如圖2，實時節點緩存事件數據到內存中的索引上，然后有規律的持久化到磁盤上。在轉移之前，持久化的索引會周期性地合并在一起。查詢會同時命中內存中的和已持久化的索引。所有的實時節點都會周期性的啟動后臺的計劃任務搜索本地的持久化索引，后臺計劃任務將這些持久化的索引合并到一起并生成一塊不可變的數據，這些數據塊包含了一段時間內的所有已經由實時節點導入的事件數據，稱這些數據塊為”Segment”。在傳送階段，實時節點將這些segment上傳到一個永久持久化的備份存儲中，通常是一個分布式文件系統，例如S3或者HDFS，稱之為”Deep Storage”(深存儲區)。


歷史節點

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



Druid 實時數據分析存儲系統（圖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失效策略的緩存。

Druid 實時數據分析存儲系統（圖4）

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


Indexer節點

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

 

Druid 實時數據分析存儲系統（圖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

來自：http://my.oschina.net/betaoo/blog/530088

 本文由用戶 jopen 自行上傳分享，僅供網友學習交流。所有權歸原作者，若您的權利被侵害，請聯系管理員。
 轉載本站原創文章，請注明出處，并保留原始鏈接、圖片水印。
 本站是一個以用戶分享為主的開源技術平臺，歡迎各類分享！