這期內(nèi)容當(dāng)中小編將會給大家?guī)碛嘘P(guān)Druid實(shí)時OLAP數(shù)據(jù)分析存儲系統(tǒng)怎么入門，文章內(nèi)容豐富且以專業(yè)的角度為大家分析和敘述，閱讀完這篇文章希望大家可以有所收獲。

成都一家集口碑和實(shí)力的網(wǎng)站建設(shè)服務(wù)商，擁有專業(yè)的企業(yè)建站團(tuán)隊(duì)和靠譜的建站技術(shù)，10余年企業(yè)及個人網(wǎng)站建設(shè)經(jīng)驗(yàn) ,為成都上千多家客戶提供網(wǎng)頁設(shè)計(jì)制作,網(wǎng)站開發(fā),企業(yè)網(wǎng)站制作建設(shè)等服務(wù),包括成都營銷型網(wǎng)站建設(shè)，品牌網(wǎng)站建設(shè)，同時也為不同行業(yè)的客戶提供成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站的服務(wù),包括成都電商型網(wǎng)站制作建設(shè),裝修行業(yè)網(wǎng)站制作建設(shè)，傳統(tǒng)機(jī)械行業(yè)網(wǎng)站建設(shè),傳統(tǒng)農(nóng)業(yè)行業(yè)網(wǎng)站制作建設(shè)。在成都做網(wǎng)站,選網(wǎng)站制作建設(shè)服務(wù)商就選成都創(chuàng)新互聯(lián)公司。

簡介

Druid 是一個開源的，分布式的，列存儲的，適用于實(shí)時數(shù)據(jù)分析的存儲系統(tǒng)，能夠快速聚合、靈活過濾、毫秒級查詢、和低延遲數(shù)據(jù)導(dǎo)入。

• Druid在設(shè)計(jì)時充分考慮到了高可用性，各種節(jié)點(diǎn)掛掉都不會使得druid停止工作（但是狀態(tài)會無法更新）；

• Druid中的各個組成部分之間耦合性低，如果不需要實(shí)時數(shù)據(jù)完全可以忽略實(shí)時節(jié)點(diǎn)；

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

架構(gòu)

整體架構(gòu)

Druid集群包含不同類型的節(jié)點(diǎn)，而每種節(jié)點(diǎn)都被設(shè)計(jì)來做好某組事情。這樣的設(shè)計(jì)可以隔離關(guān)注并簡化整個系統(tǒng)的復(fù)雜度。

不同節(jié)點(diǎn)的運(yùn)轉(zhuǎn)幾乎都是獨(dú)立的并且和其他的節(jié)點(diǎn)有著最小化的交互，因此集群內(nèi)的通信故障對于數(shù)據(jù)可用性的影響非常小。

Druid集群的構(gòu)成和數(shù)據(jù)流向如圖1所示：

（圖1）

Druid 本身包含了五種節(jié)點(diǎn) ：Realtime、Historical、Coordinator、Broker、Indexer

• Historical 歷史節(jié)點(diǎn)是進(jìn)行存儲和查詢的“歷史”數(shù)據(jù)（非實(shí)時）的工作區(qū)，它會從深存儲區(qū)(Deep Storage)中加載數(shù)據(jù)段(Data/Segments)，響應(yīng) Broker 節(jié)點(diǎn)的查詢請求并返回結(jié)果。

  歷史節(jié)點(diǎn)通常會在本機(jī)同步深存儲區(qū)上的部分?jǐn)?shù)據(jù)段，所以即使深存儲區(qū)不可訪問了，歷史節(jié)點(diǎn)還是能查詢到已經(jīng)同步的數(shù)據(jù)段。

• Realtime 實(shí)時節(jié)點(diǎn)是進(jìn)行存儲和查詢實(shí)時數(shù)據(jù)的工作區(qū)，它也會響應(yīng)Broker節(jié)點(diǎn)的查詢請求并返回結(jié)果 。

  實(shí)時節(jié)點(diǎn)會定期地將數(shù)據(jù)建立成數(shù)據(jù)段移到歷史節(jié)點(diǎn)中。

• Coordinator 協(xié)調(diào)節(jié)點(diǎn)可以認(rèn)為是Druid中的master，它通過Zookeeper管理歷史節(jié)點(diǎn)和實(shí)時節(jié)點(diǎn)，且通過MySQL中的metadata管理數(shù)據(jù)段。

• Broker節(jié)點(diǎn)負(fù)責(zé)響應(yīng)外部的查詢請求，通過查詢Zookeeper將請求分別轉(zhuǎn)發(fā)給歷史節(jié)點(diǎn)和實(shí)時節(jié)點(diǎn)，最終合并并返回查詢結(jié)果給外部， 由Broker節(jié)點(diǎn)通過zookeeper決定哪些歷史節(jié)點(diǎn)和實(shí)時節(jié)點(diǎn)提供服務(wù)。

• Indexer 索引節(jié)點(diǎn)負(fù)責(zé)數(shù)據(jù)導(dǎo)入，加載批次和實(shí)時數(shù)據(jù)到系統(tǒng)中，并可以修改存儲到系統(tǒng)中的數(shù)據(jù) 。

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

• Mysql：

  存儲關(guān)于Druid中的metadata而不是存儲實(shí)際數(shù)據(jù)，包含3張表：

  ”druid_config”（通常是空的）, “druid_rules”（協(xié)作節(jié)點(diǎn)使用的一些規(guī)則信息，比如哪個segment從哪個node去load）和“druid_segments”（存儲 每個segment的metadata信息）；

• Deep storage: 存儲segments，Druid目前已經(jīng)支持本地磁盤，NFS掛載磁盤，HDFS，S3等。

  Deep Storage的數(shù)據(jù)有2個來源，一個是批數(shù)據(jù)攝入, 另一個來自實(shí)時節(jié)點(diǎn)；

• ZooKeeper: 被Druid用于管理當(dāng)前cluster的狀態(tài)，比如記錄哪些segments從實(shí)時節(jié)點(diǎn)移到了歷史節(jié)點(diǎn)；

實(shí)時節(jié)點(diǎn)

實(shí)時節(jié)點(diǎn)封裝了導(dǎo)入和查詢事件數(shù)據(jù)的功能，經(jīng)由這些節(jié)點(diǎn)導(dǎo)入的事件數(shù)據(jù)可以立刻被查詢。實(shí)時節(jié)點(diǎn)只關(guān)心一小段時間內(nèi)的事件數(shù)據(jù)，并定期把這段時間內(nèi)收集的這批數(shù)據(jù)導(dǎo)入到深存儲區(qū)里。實(shí)時節(jié)點(diǎn)通過Zookeeper來宣布它們的在線狀態(tài)和它們提供的數(shù)據(jù)。

（圖2）

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

歷史節(jié)點(diǎn)

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

（圖3）

如圖3，在歷史節(jié)點(diǎn)從深存儲區(qū)下載某一segment之前，它會先檢查本 地緩存信息中看segment是否已經(jīng)存在于節(jié)點(diǎn)中，如果segment還不存在緩存中，歷史節(jié)點(diǎn)會從深存儲區(qū)下載segment到本地。這階段處理完 成，這個segment就會在Zookeeper中進(jìn)行通告。此時，這個segment就可以被查詢了，查詢之前需要將segment加載到內(nèi)存中。

協(xié)調(diào)節(jié)點(diǎn)

協(xié)調(diào)節(jié)點(diǎn)主要負(fù)責(zé)Segment的管理和在歷史節(jié)點(diǎn)上的分布。協(xié)調(diào)節(jié)點(diǎn)告訴歷史節(jié)點(diǎn)加載新數(shù)據(jù)、卸載過期數(shù)據(jù)、復(fù)制數(shù)據(jù)、和為了負(fù)載均衡移動數(shù)據(jù)。 Druid為了維持穩(wěn)定的視圖，使用一個多版本的并發(fā)控制交換協(xié)議來管理不可變的segment。如果任何不可變的segment包含的數(shù)據(jù)已經(jīng)被新的 segment完全淘汰了，則過期的segment會從集群中卸載掉。協(xié)調(diào)節(jié)點(diǎn)會經(jīng)歷一個leader選舉的過程，來決定由一個獨(dú)立的節(jié)點(diǎn)來執(zhí)行協(xié)調(diào)功 能，其余的協(xié)調(diào)節(jié)點(diǎn)則作為冗余備份節(jié)點(diǎn)。

Broker節(jié)點(diǎn)

Broker 節(jié)點(diǎn)是歷史節(jié)點(diǎn)和實(shí)時節(jié)點(diǎn)的查詢路由。Broker節(jié)點(diǎn)知道發(fā)布于Zookeeper中的segment的信息，Broker節(jié)點(diǎn)就可以將到來的查詢請求 路由到正確的歷史節(jié)點(diǎn)或者是實(shí)時節(jié)點(diǎn)，Broker節(jié)點(diǎn)也會將歷史節(jié)點(diǎn)和實(shí)時節(jié)點(diǎn)的局部結(jié)果進(jìn)行合并，然后返回最終的合并后的結(jié)果給調(diào)用者。Broker 節(jié)點(diǎn)包含一個支持LRU失效策略的緩存。

（圖4）

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

Indexer節(jié)點(diǎn)

索引服務(wù)是運(yùn)行索引任務(wù)相關(guān)的高可用性，分布式的服務(wù)。索引服務(wù)創(chuàng)建（有時破壞）Druid的Segment。索引服務(wù)有一個類似主/從的架構(gòu)。

（圖5）

索引服務(wù)是由三個主要部分組成：可以運(yùn)行單個任務(wù)的peon組件，用于管理peon的中層管理組件，以及管理任務(wù)分配到中層管理組件的overlord組件。overlord組件和中層管理組件可以在同一節(jié)點(diǎn)上或跨多個節(jié)點(diǎn)上運(yùn)行，而中層管理組件和peon組件總是相同的節(jié)點(diǎn)上運(yùn)行。

ZooKeeper 

Druid 使用ZooKeeper（ZK）管理當(dāng)前集群狀態(tài)，在ZK上發(fā)生的操作有：

1.協(xié)調(diào)節(jié)點(diǎn)的leader選舉

2.歷史和實(shí)時節(jié)點(diǎn)發(fā)布segment協(xié)議

3.協(xié)調(diào)節(jié)點(diǎn)和歷史節(jié)點(diǎn)之間的segment Load/Drop協(xié)議

4.overlord的leader選舉

5.索引服務(wù)任務(wù)管理

Druid vs 其他系統(tǒng)

Druid vs Impala/Shark

Druid和Impala、Shark 的比較基本上可以歸結(jié)為需要設(shè)計(jì)什么樣的系統(tǒng)

Druid被設(shè)計(jì)用于：

• 一直在線的服務(wù)

• 獲取實(shí)時數(shù)據(jù)

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

查詢速度不同：

• Druid是列存儲方式，數(shù)據(jù)經(jīng)過壓縮加入到索引結(jié)構(gòu)中，壓縮增加了RAM中的數(shù)據(jù)存儲能力，能夠使RAM適應(yīng)更多的數(shù)據(jù)快速存取。

  索引結(jié)構(gòu)意味著，當(dāng)添加過濾器來查詢，Druid少做一些處理，將會查詢的更快。

• Impala/Shark可以認(rèn)為是HDFS之上的后臺程序緩存層。

  但是他們沒有超越緩存功能，真正的提高查詢速度。

數(shù)據(jù)的獲取不同：

• Druid可以獲取實(shí)時數(shù)據(jù)。

• Impala/Shark是基于HDFS或者其他后備存儲，限制了數(shù)據(jù)獲取的速度。

查詢的形式不同：

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

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

Druid vs Elasticsearch

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

Druid側(cè)重于OLAP工作流程。Druid是高性能（快速聚集和獲取）以較低的成本進(jìn)行了優(yōu)化，并支持廣泛的分析操作。Druid提供了結(jié)構(gòu)化的事件數(shù)據(jù)的一些基本的搜索支持。

Druid vs Spark

Spark 是圍繞彈性分布式數(shù)據(jù)集（ RDD ）的概念，建立了一個集群計(jì)算框架，可以被看作是一個后臺分析平臺。 RDD啟用數(shù)據(jù)復(fù)用保持中間結(jié)果存在內(nèi)存中，給Spark提供快速計(jì)算的迭代算法。這對于某些工作流程，如機(jī)器學(xué)習(xí)，相同的操作可應(yīng)用一遍又一遍，直到有 結(jié)果后收斂尤其有益。Spark提供分析師與不同算法各種各樣運(yùn)行查詢和分析大量數(shù)據(jù)的能力。

Druid重點(diǎn)是數(shù)據(jù)獲取和提供查詢數(shù)據(jù)的服務(wù)，如果建立一個web界面，用戶可以隨意查看數(shù)據(jù)。

上述就是小編為大家分享的Druid實(shí)時OLAP數(shù)據(jù)分析存儲系統(tǒng)怎么入門了，如果剛好有類似的疑惑，不妨參照上述分析進(jìn)行理解。如果想知道更多相關(guān)知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道。