Apache Druid是基於事件的亞秒級的萬億行響應的開源資料庫

banq發表於2022-02-23
ApacheUI事件資料庫

Netflix 使用開源 Druid 分析資料庫來了解和量化使用者裝置如何處理瀏覽和播放。
 
一家名為 Metamarkets 的廣告技術公司最初於 2011 年將 Druid 設計為分散式實時資料儲存，以提供 SaaS 分析。Metamarkets 為廣告商提供互動式分析儀表板工具，以瞭解程式化廣告活動的執行情況。它於 2017 年被 Snap 收購。Druid 於 2015 年轉移到 Apache 許可證。
Metamarkets部落格描述了其最初的需求：“我們的需求是由我們的線上廣告客戶推動的，這些客戶每月的資料量通常超過數千億事件，需要對最新資料進行高度互動的查詢以及任意過濾的能力跨任何維度——資料集包含 30 個或更多維度。例如，一個典型的查詢可能是“看看有多少廣告是由來自美國、英國和加拿大的 35 至 44 歲的女性高管在週末閱讀體育部落格時看到的”。
它需要實時訪問包含數十億時間序列事件的商店。資料倉儲被排除在外，因為它們的掃描速度太慢，而且快取速度被擊敗，因為 Metamarkets 需要進行任意攝取。
  1. 關聯式資料庫也不適合：“RDBMS 資料更新本質上是批處理的，透過插入進行的更新會導致查詢行鎖定。”
  2. NoSQL 方法並不好，因為“預聚合需要數小時的處理時間來處理數百萬條記錄（在約 10 節點的 Hadoop 叢集上）。......隨著維度數量的增加，聚合和處理時間呈指數增長，超過 24 小時。” 

這意味著沒有實時查詢。
因此 Metamarkets 決定建立自己的資料儲存，並透過其中的並行處理使其具有極大的可擴充套件性。它具有分散式架構、實時資料攝取、查詢實時和歷史資料的能力，以及具有資料壓縮的列方向以提高掃描速度。使用帶有所謂的簡潔壓縮的點陣圖索引也有助於提高速度。
Druid 可以擴充套件以每秒執行 260 億行或更多行的掃描，並且每個節點每秒可以攝取多達 10,000 條記錄。Druid 叢集中的伺服器可以縱向擴充套件或橫向擴充套件，這提供了比縱向擴充套件更多的擴充套件能力。
 

Druid架構
Druid部署使用商業上可用的伺服器，這些伺服器被稱為節點。有三種基本型別：主節點、資料節點和查詢節點。舊資料儲存在所謂的深度儲存中，這是Druid之外的可插拔儲存，如Ceph、NFS、Hadoop（HDFS）或S3。節點執行程式，這些程式可以在專用伺服器中執行，被稱為節點--或伺服器。

  • 主節點--主節點、協調員、Zookeeper、後設資料儲存程式。
  • 資料節點--中間管理者/索引者、歷史程式。
  • 查詢節點--經紀人程式和網路控制檯。

 

資料攝取
讓我們試著弄清楚發生了什麼，並從發生在資料節點或伺服器層的資料攝取開始。
可以攝取來自 Kafka、Kinesis、Tranquility 或其他來源的流資料，也可以攝取來自 Hadoop、S3、RDBMS 以及其他來源的批處理資料。中間管理器節點（有時稱為 Ingestor 或 Real-Time 節點）處理此問題，並按時間（可配置的持續時間）將資料分段或分割槽為不可變的壓縮列檔案，該檔案被寫入深度儲存。 
有三種可能的列型別：時間戳、維度（欄位名稱）或度量（從其他欄位派生的數字資料）。
中層管理者還在建立細分之前對資料進行索引和預聚合。指定時間間隔內的所有傳入資料按順序寫入同一段。Druid 使用平面資料模型，而不是巢狀資料模型。
一旦資料進入深度儲存，歷史節點（Historicals）負責獲取資料以響應查詢。
 

主節點
主節點形成一個 Druid 叢集控制平面。Overlords 對 Middle Manager 進行資料負載均衡。協調器在歷史程式或節點之間進行資料負載平衡，在需要從深度儲存載入資料段時通知它們，在不再需要時驅逐段並複製段。
後設資料儲存包含由中間管理器在 MySQL 或 PostgreSQL 等關聯式資料庫中建立的所有後設資料。Zookeeper 程式是一個 Apache 專案，用於當前叢集狀態管理、內部服務發現、協調和叢集領導者選舉。
我們需要了解，當中間管理器建立新資料段時，後設資料儲存會通知協調器。然後將其提供給 Historical，以便可以將其寫入底層檔案系統。那時，它被從中間管理器中逐出。中層管理器將其預先聚合的段資料儲存在記憶體中，而歷史記錄將新段寫入深度儲存。在那裡，段是隻讀的。
如果中間管理器節點出現故障，Zookeeper 將獲得由剩餘的中間管理器節點重構的資料集。
 

查詢節點和查詢流程
有一種單一型別的查詢節點，稱為 Broker，Web 控制檯也位於 Druid 的這一層。代理可以橫向擴充套件以增加實時查詢處理能力。
Brokers 以 JSON 查詢語言或透過 Druid SQL 從客戶端應用程式接收傳入查詢，並將它們分配給相關的中間管理器和歷史記錄——它們包含（可以服務）這些資料段。Broker 將傳入的查詢拆分為子查詢，並將它們傳送給已識別的中間管理器和歷史記錄以執行。
歷史記錄從深度儲存中獲取請求的資料，而中間管理器獲取任何實時資料段。
當返回結果時，它們被合併並輸出到客戶端。
這樣做的最終結果是 Druid 可以查詢巨大的資料集，其中可以包括實時資料和歷史資料。它最初是一個 adtech 實時查詢/分析資料庫工具，但在需要類似能力查詢大量資料集的應用程式中得到使用，這些資料集不斷從事件日誌中實時攝取流資料。例如，點選流分析、APM（應用程式效能管理）、供應鏈、網路遙測、數字營銷和風險/欺詐分析。
正如 Metamarkets 所說，“以前需要幾分鐘或幾小時才能執行的超過數十億行的查詢現在可以直接以亞秒級的響應時間進行調查。” Druid 可以處理數 PB 資料儲存中的數萬億行資料。
我覺得 Druid 和 Druid 型別的應用程式將得到更廣泛的應用，因為分析數字事件資料流以最佳化流程，並隨著時間的推移微調涉及數十億甚至數萬億事件的企業流程。
 
Druid 可以在GitHub 上下載，更多資訊可以在Druid 專案網站上找到。

相關文章