Druid有什么特點

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

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

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

日志數據通常按照時間順序產生的。系統不可能產生一條2點的日志，又產生一條1點日志。但是，日志在從產生后，傳輸到另一個地方是可能出現亂序的。

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

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

Real-time 節點：

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

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

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

Historical 節點：

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

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

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

Broker 節點；

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

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

Coordinator 節點：

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

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

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

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

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

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

到此，關于“Druid有什么特點”的學習就結束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學習，快去試試吧！若想繼續學習更多相關知識，請繼續關注億速云網站，小編會繼續努力為大家帶來更多實用的文章！