Druid實(shí)時(shí)OLAP數(shù)據(jù)分析存儲(chǔ)系統(tǒng)怎么入門

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

簡介

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

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

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

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

架構(gòu)

整體架構(gòu)

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

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

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

（圖1）

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

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

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

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

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

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

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

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

Druid 包含3個(gè)外部依賴 ：Mysql、Deep storage、Zookeeper

• Mysql：

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

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

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

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

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

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

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

（圖2）

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

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

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

（圖3）

如圖3，在歷史節(jié)點(diǎn)從深存儲(chǔ)區(qū)下載某一segment之前，它會(huì)先檢查本 地緩存信息中看segment是否已經(jīng)存在于節(jié)點(diǎn)中，如果segment還不存在緩存中，歷史節(jié)點(diǎn)會(huì)從深存儲(chǔ)區(qū)下載segment到本地。這階段處理完 成，這個(gè)segment就會(huì)在Zookeeper中進(jìn)行通告。此時(shí)，這個(gè)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ù)載均衡移動(dòng)數(shù)據(jù)。 Druid為了維持穩(wěn)定的視圖，使用一個(gè)多版本的并發(fā)控制交換協(xié)議來管理不可變的segment。如果任何不可變的segment包含的數(shù)據(jù)已經(jīng)被新的 segment完全淘汰了，則過期的segment會(huì)從集群中卸載掉。協(xié)調(diào)節(jié)點(diǎn)會(huì)經(jīng)歷一個(gè)leader選舉的過程，來決定由一個(gè)獨(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í)時(shí)節(jié)點(diǎn)的查詢路由。Broker節(jié)點(diǎn)知道發(fā)布于Zookeeper中的segment的信息，Broker節(jié)點(diǎn)就可以將到來的查詢請(qǐng)求 路由到正確的歷史節(jié)點(diǎn)或者是實(shí)時(shí)節(jié)點(diǎn)，Broker節(jié)點(diǎn)也會(huì)將歷史節(jié)點(diǎn)和實(shí)時(shí)節(jié)點(diǎn)的局部結(jié)果進(jìn)行合并，然后返回最終的合并后的結(jié)果給調(diào)用者。Broker 節(jié)點(diǎn)包含一個(gè)支持LRU失效策略的緩存。

（圖4）

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

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

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

（圖5）

索引服務(wù)是由三個(gè)主要部分組成：可以運(yùn)行單個(gè)任務(wù)的peon組件，用于管理peon的中層管理組件，以及管理任務(wù)分配到中層管理組件的overlord組件。overlord組件和中層管理組件可以在同一節(jié)點(diǎn)上或跨多個(gè)節(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í)時(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í)數(shù)據(jù)

• 處理slice-n-dice式的即時(shí)查詢

查詢速度不同：

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

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

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

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

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

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

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

查詢的形式不同：

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

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

Druid vs Elasticsearch

Elasticsearch(ES) 是基于Apache Lucene的搜索服務(wù)器。它提供了全文搜索的模式，并提供了訪問原始事件級(jí)數(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 ）的概念，建立了一個(gè)集群計(jì)算框架，可以被看作是一個(gè)后臺(tái)分析平臺(tái)。 RDD啟用數(shù)據(jù)復(fù)用保持中間結(jié)果存在內(nèi)存中，給Spark提供快速計(jì)算的迭代算法。這對(duì)于某些工作流程，如機(jī)器學(xué)習(xí)，相同的操作可應(yīng)用一遍又一遍，直到有 結(jié)果后收斂尤其有益。Spark提供分析師與不同算法各種各樣運(yùn)行查詢和分析大量數(shù)據(jù)的能力。

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

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