實時分析性資料庫 Druid 架構解析

Druid 是一個實時分析型的資料庫，用于大規模實時資料導入、快速查詢分析的場景，包括網站通路點選流分析、網絡性能監控分析、應用性能名額存儲與分析、供應鍊分析、廣告分析等。

Druid 的核心內建了資料倉庫、時序資料庫、日志搜尋系統的設計，主要包含如下特性：

1. 列式存儲：Druid 使用列存方式組織資料，通路時可按需加載通路到的列，支援快速的掃描和聚合計算能力；同時資料按列式存儲，能極大的提升資料的壓縮率。
2. 分布式可擴充：Druid 叢集可擴充至上百台伺服器，可以高并發出力讀寫請求，提供每秒百萬級的資料導入，以及亞秒級的查詢延時。
3. 支援實時及批量導入：Druid 支援實時或批量方式導入資料，非常友善點支援從 Kafka、Hadoop 等資料源導入資料。
4. 高可用&負載均衡：Druid 叢集支援線上的增加、移除服務節點，叢集會進行自動的負載均衡，當有節點故障時，Druid 通過也可通過多副本高可用的方式自動 Failover。
5. 雲原生架構：Druid 将資料存儲在外部 Deep Storage（例如 雲存儲、HDFS 等），即使 Druid 服務節點故障，也不影響資料的可靠性。
6. 索引加速：Druid 通過位圖方式自動對資料建索引，支援快速的索引過濾。
7. 時間分區：Druid 會先将資料按時間分區，也可根據其他方式進一步分區，基于時間範圍的查詢隻會通路對應時間範圍内地資料。
8. 預聚合：Druid 支援在導入資料時對資料進行提前的聚合分析，例如sum、count、min、max等，作為資料的中繼資料存儲，當實際通路時，可直接通路預聚合好的資料。
9. SQL 支援：Druid 同時支援 SQL、HTTP 方式通路，表達能力強，靈活友善。

Druid 資料模型

架構解析

核心元件

• Coordinator 負責叢集的協調及資料高可用
• Overlord 控制叢集資料導入任務的配置設定
• Broker 處理用戶端查詢請求
• Router 是可選的路由元件
• Historical 負責可查詢資料的存儲
• MiddleMangager 負責資料的導入

部署方式

Druid 的各個元件可以随意部署，但根據元件的職能，會分成三類，每一類元件建議在伺服器上混部。

• Master Servers：運作叢集的 Coordinator 與 Overlord 控制類的元件。
• Query Servers：運作叢集查詢類元件，包括 Broker、Router
• Data Servers：運作叢集資料導入、存儲相關元件，包括 Middle Managers、Histricals

外部依賴

Druid 本身不存儲資料，資料的存儲依賴于外部的元件，資料的存儲（Deep Storage）依賴外部的存儲，例如 AWS S3、阿裡雲 OSS、HDFS 等分布式存儲，雲資料存儲依賴 MySQL、PostgreSQL 等資料庫；依賴 Zookeeper 實作服務發現、Leader 選舉等功能。

Deep Storage

Druid 本身不存儲資料，而将資料存儲到外部的 Deep Storage，由 Deep Storage 保證資料的可靠存儲，例如 AWS S3、阿裡雲 OSS、HDFS 等分布式存儲。

Druid 的資料會按資料順序組織，并按時間次元對資料進行分區存儲，一段時間範圍的資料會存儲到一起，組成一個 Segment。資料在 Segment 裡會按列存方式進行壓縮存儲，并對 Dimension 資料建立索引。

Segment 結構

Druid 的所有資料都包含時間戳列，還包含多個 Dimensions 以及 Metrics 列，其中 Dimension 列可支援快速過濾、聚合，Druid 在存儲 Dimension 列時，會進行壓縮存儲，并通過位圖方式建索引，每一列的資料包含

1. Dictionary：存儲列值到 整型 ID 的映射
2. Column Data：根據 1産生的一系列的整型 ID，進行壓縮存儲
3. Inverted Index（Bitmaps）：針對 Column 裡每個不同的 value，會建一個位圖反向索引

比如 Page 列的存儲，包含 "Justin Bieber", "Ke$ha" 兩個取值，該列對應的存儲類似如下三個部分

1: Dictionary that encodes column values
  {
    "Justin Bieber": 0,
    "Ke$ha":         1
  }

2: Column data
  [0,
   0,
   1,
   1]

3: Bitmaps - one for each unique value of the column
  value="Justin Bieber": [1,1,0,0]
  value="Ke$ha":         [0,0,1,1]
            

當某一段時間範圍内地資料量很大時，在将資料存儲為 Segments 時，可以采用 sharding 政策，比如按檔案大小切分 Segments、或根據指定的 Dimension 進行 Hash 分到多個 Segments，在檢索的時候，能進一步減少需要查詢的資料。

讀寫流程

資料導入

Druid 支援從 Kafka、Hadoop 裡導入資料，資料導入以 Task 方式進行，Overlord 負責導入任務的配置設定，Middle Manager 負責實際的資料導入，資料會先寫到 Middle Manager 的記憶體，積累到一定大小或時間視窗後，資料會組織為 Segment 寫到 Deep Storage，并将 Segment 的中繼資料寫入到 Metadata Storage。

Coordinator 會周期性的檢測 Metadata Storage，當發現新的 Segment 産生時，會将 Segment 根據負載情況分給其中的部分 Historical（根據副本數） 節點管理，Historical 節點接管 Segment 的管理，這部分 Segment 即可用于查詢。

資料查詢

Broker 接收資料的查詢請求，根據 Metadata 的資訊，計算出查詢關聯的 Middle Managers、Historicals 節點，并将請求發送到對應的節點， Middle Managers、Historicals 根據查詢的時間範圍，找出所有可能包含查詢資料的 Segments，并從中過濾出滿足條件的資料，Broker 負責将查詢結果進行彙總傳回給用戶端。

總結

1. Druid 與傳統資料庫通過讀寫 API 寫入資料的方式不同，通過 Pull 方式拉取資料，對接常用的 Kafka、HDFS等大資料生态資料源。
2. 借助外部可靠的 Deep Storage 和 Meatadata store 來實作資料、中繼資料的存儲，将 Druid 從資料存儲的高可靠管理中解放，讓各個元件的實作都非常輕量；
3. Druid 的實作高度子產品化，每個子產品有獨立的職能，但因為元件非常多，在部署管理上稍微有些複雜。
4. 通過列式存儲以及位圖索引，極大的降低存儲成本，并支援高效的資料過濾查詢。
5. 通過時間分區政策，對事件型、時序類型場景非常友好，能快速根據查詢時間範圍降低掃描的資料量。