對於druid架構的理解

大數據時代，對於數據的各種操作要求往往是分離開的，比如有專門的系統負責插入，有專門的系統負責查詢。druid的就很好的體現了這一點。

Druid存在的意義

為理解druid的意義，需了解druid所面向的對象：大數據。了解大數據的一些特點屬性，我們才能理解druid在利用大數據的哪個特點進行決策。

IBM曾提出大數據的5V特點：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（低價值密度）、Veracity（真實性）。

這些特點意味著什麼？

意味著，傳統的架構（比如單機、單節點結構）很難處理這些特點。

比如，「大量」這個特點決定了數據不可能在單塊磁碟上存儲下來，必須多塊磁碟協作起來（單塊磁碟如果能夠達到PB級別，在現有的技術下，將會把硬碟做的很大，這樣子造成的後果是，磁碟如果毀壞代價很大，另一個方面定址的時間也會大大增加，因為盤面大了，機械臂定址的路徑就長了）。

比如，「高速」這個特點來源於，互聯網的普及，群眾創造數據的速度驚人，針對這個特點機器需要有專門的系統負責處理快速產生的數據，否則會有大量的信息會被丟棄。（實時處理系）

這些數據是「真實」的，但是卻是「低價值密度」的。所以有必要對其進行提取，抽象（求和，求平均等），進而將這些小的價值收集起來，匯總成大的價值（規律）。

druid的作用

druid解決的問題在於，數據的快速攝入，數據的快速查詢。它的攝入及查詢是兩個不同的系統，需要區別對待。

個人認為其特色在於，快速響應用戶的查詢請求，在其查詢的結果中包含過去的歷史數據，還有最近很短時間產生的查詢結果（創新之處）。

基於MapReduce的工具框架，處理的大多是已經存放於硬碟的歷史數據。這意味著處理的數據距離當前時間點有一定的差距，因為當前還有一段時間的數據中緩存在內存中，這些並沒有參與到計算中來。druid的將內存中的數據和已經存儲在內存中的數據都考慮進來，並進行了相應的匯總。

druid架構

理解druid，需要將其理解為兩個系統，即輸入系統和查詢系統。

druid總體架構

• 【druid本身節點】Broker(查詢)，RealTime(處理實時大數據)，Historical（處理批量數據），Coordinator(監控history節點數據的狀態)
• 【依賴的外部節點】Metadata Storage （存儲元數據信息），Deep Storage(永久存儲數據信息)，Distributed Coordination(分散式協調節點，協調其他各節點的狀態等信息)

接下來，分別就外部節點以及內部節點進行相應的說明。

依賴的外部節點有何作用？

Metadata Storage :

druid若要查詢數據（比如查詢2017年發生的事情），它需要將這些條件的信息找到（在哪個機器的哪個文件之中），然後再去篩選。去那裡找這些數據，也就是位置信息，就是一種元數據信息（描述數據的存儲位置），這些信息存儲在Metadata Storage中，可以說Metadata Storage在某種程度上，起到了書本中目錄的作用。

沒有Metadata Storage之後，你將失去了進入各個數據文件的入口。

Deep Storage:

相對於前面而言，該節點負責的是存儲的具體的數據（比如2017年具體的事件），要與前面的元數據區分開來。

該類存儲的特點是：插入，讀取慢，但能夠永久存儲。（本地硬碟，HDFS都是屬於這類存儲）

與Metadata Storage 相互配合，才能定位出數據所在位置，並且取出相應的數據。

Distributed Coordination:(比如Zookeeper)

該節點的作用在於協調各個節點。聽起來很模糊，舉一個簡單的例子，zookeeper中保存著各個節點的狀態（比如某個節點是否可用），然後創建了一個任務，要分配到相應的節點中去執行，先去zookeeper上查看相關的節點的狀態，如果節點可用，並且資源較多，那麼就把任務分配到該節點上。（節點可用，資源較多這些信息就是存儲在zookeeper上的）

druid內部各節點的職責

查詢節點

• 對外提供查詢服務
• 調用實時節點、歷史節點進行查詢，合併兩者的查詢結果
• 【注意】查詢的過程是漫長的，因為數據量大，但 broker本身只是把查詢計算任務分配給了實時節點以及歷史節點。 它只是對於最後的結果進行了簡單的匯總。
• broker 根據zookeeper中的節點狀態信息(歷史節點，實時節點 )，去決定何時合併，如何合併在各個節點上查詢出的結果。

實時節點

• 攝入實時數據
• 將實時數據生成Segment，存儲到DeepStorage中
• 為查詢數據進行服務
• 【注意】具有查詢、攝入兩種功能

歷史節點

• 【可查詢】為查詢數據提供服務
• 不提供攝入服務
• 和DeepStorage關係緊密。
• 【進一步解釋】因為DeepStorage只是提供了硬碟，而沒有提供計算及內存。所以歷史節點就擔當了這些責任，從DeepStorage那裡獲得數據，載入到歷史節點的內存中，然後進行計算。簡而言之，history節點主要負責對於歷史信息的查詢計算。

協調者節點（與外部協調者相區分）

• 協調歷史節點
• 相當於hadoop中的Jobtracker,只不過是針對查詢的Jobtracker.
• 類似於Master-Slave結構，其中協調者是Master,而歷史節點是Slave. Master根據Slave的資源使用等情況，對歷史節點分配相應適當的任務。

索引服務節點

• 【責任】數據攝入
• 將數據攝入，並整理成Segment（druid中的高層抽象概念）的形式。
• 【結構】數據攝入是一個較為複雜的過程，所以單就索引服務方面而言就設計成了Master-Slave結構的形式。為何複雜呢？因為它需要把接收到的數據，存儲到各台機器上，這意味著在每台相應的機器上還應該有負責在單個節點上進行存儲的員工。Master負責選擇機器，而Slave負責相關節點的數據存儲轉化。所以在索引服務中，又進一步劃分成了三類節點：統治節點（即Master節點），中間管理者節點，苦工節點。
• 【統治節點】在分散式中的管理者，負責任務分配到相應的機器。
• 【中間管理者】在本地上，負責將任務分配到具體的進程。
• 【苦工】接受任務，然後真正辦實事（具體任務的執行）。
• 【注意】與數據查詢時，協調者節點與歷史節點構成的Master-Slave節點相區分。此處針對的是數據攝入，為了快速攝入以及快速查詢，所以將這兩部分功能分開做了。

索引服務架構圖：

各節點間的關係

查詢及攝入的數據流圖：

PS：

• 區分查詢與攝入，這是理解該架構的關鍵點。
• 實時節點，歷史節點屬於數據節點。
• 多處使用Master-Slave結構（索引方式數據攝入，歷史節點查詢）
• Coordinator & Index（lord,midmanager）有何區別？
• 攝入數據是通過index的方式攝入的，實時數據必須經過實時節點，而批量數據不經過歷史節點，直接藉助index節點被存入到DeepStorage中。

參考：

《Druid實時大數據分析原理與實踐》

druid官方文檔：（http://druid.io/docs/0.12.0/design/index.html）

【維基百科】元數據倉庫（https://en.wikipedia.org/wiki/Metadata_repository）

推薦閱讀：