Druid有什么特點

這篇文章主要介紹“Druid有什么特點”，在日常操作中，相信很多人在Druid有什么特點問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”Druid有什么特點”的疑惑有所幫助！接下來，請跟著小編一起來學習吧！

Druid 命名來自游戲中的德魯伊角色，比如在Dota里德魯伊有人和熊兩種形態(tài)，還可以召喚小熊，不多說廢話了。主要比喻面向各種場景都能適用。

Druid 針對的數(shù)據(jù)是日志數(shù)據(jù)。什么是日志呢？日志就是系統(tǒng)中發(fā)生的事情的記錄。比如你在百度百科里編輯了一個詞條，會產(chǎn)生一個日志，這個日志包含你操作的時間、你的名字、你編輯的條目、增加了多少字、去掉了多少個字等屬性。這些屬性中，時間是必不可少的，每個日志都有一個時間戳 time，long類型，時間戳也主要作為查詢語句中的過濾條件；其他屬性比如你的名字，條目等作為屬性維度 dimension，通常為字符串類型；增加了多少個字，去掉了多少個字這種屬性叫做度量列，metric，通常為數(shù)值類型。

日志數(shù)據(jù)通常按照時間順序產(chǎn)生的。系統(tǒng)不可能產(chǎn)生一條2點的日志，又產(chǎn)生一條1點日志。但是，日志在從產(chǎn)生后，傳輸?shù)搅硪粋€地方是可能出現(xiàn)亂序的。

通常日志數(shù)據(jù)存儲在 Hadoop 中，但是 hadoop 沒有對查詢過濾提供很好的支持，無法滿足用戶的交互查詢需求。同時，用戶需要高可用，0 宕機重啟時間。

Druid 中一共有 4 種類型的節(jié)點。注意是 4 種類型，每種類型的節(jié)點都可以有多個。我們一個一個介紹：

Real-time 節(jié)點：

這些節(jié)點的本質是 Kafka 的消費者。用來處理實時到達的數(shù)據(jù)。因此，這些節(jié)點的性質和 Kafka 的 consumer 一樣。比如他們屬于一個 消費者組，去消費 Kafka 的一個 Topic。這樣他們的數(shù)據(jù)就不重復。當然他們也可以作為不同的 消費者組 去消費，這樣他們的數(shù)據(jù)就是重復的，重復不一定是壞事，重復可以做副本。 

Real-time 節(jié)點在內存中維護一個索引，隨著日志數(shù)據(jù)的到達，會先加到內存索引中，并周期性的將索引和當前內存數(shù)據(jù)持久化到磁盤上，比如每 10 分鐘持久化一次，或者每處理10000條數(shù)據(jù)持久化一次。每次持久化的數(shù)據(jù)和索引不可更改，這也簡化了其系統(tǒng)設計。

一個 read-time 節(jié)點負責的數(shù)據(jù)段是有時間限制的，比如當前節(jié)點只接收 1點-2點的數(shù)據(jù)，當過了2點之后，不再接收1點-2點的數(shù)據(jù)，而開始接收2點-3點的數(shù)據(jù)。由于1點-2點的數(shù)據(jù)已經(jīng)被寫到磁盤了。需要一個合并任務來將這些數(shù)據(jù)和索引合并成一份。叫做 Segment。Segment 是 Druid 數(shù)據(jù)存儲的基本單位。

Historical 節(jié)點：

Real-time 節(jié)點整理好的 Segment，交給了底層存儲。Historical 節(jié)點負責從底層存儲中讀取 Segment，讀到內存中以供查詢。

Historical 節(jié)點獨立工作，互不感知。Historical 節(jié)點維護了一個 cache，緩存一部分 Segment，每次需要讀取一個 Segment 時，先檢查 Cache，如果 Cache 沒命中，再去底層存儲下載 Segment。

Historical 節(jié)點可以劃分為不同層次。 各個層次可以單獨配置。比如，可以將系統(tǒng)中那些性能比較好的 Historical 節(jié)點組成一個 熱數(shù)據(jù)層，性能一般的節(jié)點組成 冷數(shù)據(jù)層。這樣，熱數(shù)據(jù)層的 Historical 節(jié)點就可以頻繁加載數(shù)據(jù)。主要為了異構集群的負載均衡。

Broker 節(jié)點；

這些節(jié)點負責查詢路由和結果合并。Broker 節(jié)點也有個 cache，主要維護了查詢請求和對應的結果。這個結果只維護了 Historical 節(jié)點的查詢結果，因為 real-time 節(jié)點的數(shù)據(jù)是實時的、不斷變化的。如果 Historical 節(jié)點的 Segment 滿足 cache了，就直接讀 cache，剩下的再發(fā)送請求去讀數(shù)據(jù)。

這個節(jié)點還負責結果合并。由于一次查詢請求可能涉及多個節(jié)點，因此需要結果合并。

Coordinator 節(jié)點：

MySQL 中存儲了每個 Segment 的元信息，Real-time 節(jié)點每處理完一個 Segment，會將其信息注冊到 MySQL 中。除此之外，MySQL 還存了一個 規(guī)則表，用來定義冷熱 Segment。在這種分布式系統(tǒng)中，關系關系數(shù)據(jù)庫如 MySQL 的功能基本就是管理系統(tǒng)元數(shù)據(jù)。

Coordinator 節(jié)點與 MySQL 相連，讀到了所有 Segment 信息，就開始把各個 Segment 分配到各個 Historical 節(jié)點上，負責 Historical 節(jié)點的負載均衡。還可以控制 Segment 的復制因子。由于副本的存在，各個節(jié)點都可以隨時替換，完成不宕機情況下的軟件升級。

按數(shù)據(jù)范圍和時間段劃分 Segment 。比如數(shù)據(jù)跨度為1年，1天一個 Segment 就比較合適。按照時間劃分 Segment 后，就可以按照時間進行過濾，相當于時間是主索引。

其次，Segment 是列式存儲的，每列可以選擇編碼和壓縮方式。一般 String 類型選擇字典編碼。RLE 、BitMap等。

存儲模型沒什么特殊的地方，基本都是列式存儲的特點。

Druid 的基本數(shù)據(jù)組織為 Segment ，由 data source identifier、時間段、一個遞增的版本號、 partition id（分區(qū)號）唯一確定。當 real-time 節(jié)點屬于同一個consumer group，他們各自消費的數(shù)據(jù)是不重疊的，這時這些 real-time 節(jié)點產(chǎn)生的同一個時間段的 segment 都是一個版本的，只是 partition id 不一樣。這時一個時間段的所有 Segment 組成了一個 block，當這個 block 的數(shù)據(jù)都準備好后才會執(zhí)行查詢。

到此，關于“Druid有什么特點”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續(xù)學習更多相關知識，請繼續(xù)關注億速云網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>