> Photo by Carlos Muza on Unsplash

Apache druid是最流行的在線分析處理（OLAP）開源解決方案之一。 Airbnb和Netflix等許多科技公司都使用它來對每分鐘包含數百萬個事件的數據流進行查詢。 它使公司可以近乎實時地做出決策。

Druid的主要賣點是它可以輕松擴展到百萬RPM的寫入速度，甚至超過亞秒級的延遲，并且在整個操作過程中都具有很高的可用性。 但是如今，許多數據庫都具有高可用性和亞秒級的延遲，那么，什么使druid與眾不同？

鍵/值存儲 和 Druid

> From druid's official documentation (http://druid.io/technology)

關系數據庫（例如MySQL）擅長處理通常具有行級查詢的事務性工作負載。 對于分析，您需要獲取某些列的匯總，這需要掃描多個分片上的很多行。 RDBMS不能足夠高效地執行實時數據探查。

就NoSQL鍵值數據庫而言，由于您需要查詢多個節點上的多個分區，因此聚合計算肯定會效率低下。 您可以通過以某種粒度（例如1分鐘）預先計算數據并將其存儲在密鑰中來解決此問題。 但是，通過遵循這種方法，您將失去在多個窗口上進行瀏覽的能力。 為所有可能的列組合存儲聚集體也是不可行的，因為這會導致存儲需求呈指數增長。

Druid旨在解決這些問題，即能夠在提供低延遲和高可用性的同時探索實時數據和歷史數據。

它是如何工作的？

Druid由多個節點組成，每個節點扮演不同的角色。 這些所有節點相互協調工作（通常使用Apache Zookeeper進行協調）以提供性能。

> Druid Architecture from http://druid.io/docs/latest/design/

讓我們更詳細地討論每個節點。 如果您已經熟悉節點及其交互，則可以直接跳到最后一部分。

實時（中層管理）

這些節點負責處理讀寫的實時數據。 這些文章特別包括四個主要步驟：

• · 攝取-將數據寫入Druid時，它首先進入該節點的內存索引緩沖區。 該緩沖區基于堆，事件以行方式存儲。
• · 持久-為了避免堆溢出，該索引會定期保留在磁盤上以提高持久性。 內存中的緩沖區將轉換為面向列的存儲格式，并使其不可變。 然后，將持久化的索引加載到堆外內存中以進行更快的查詢。
• · 合并-定期的后臺任務將不可變的塊合并為所謂的段。
• · 移交-段最終上傳到分布式數據存儲（稱為深度存儲），例如HDFS，以提高持久性和可用性。 它還會在MySQL中更新細分的元數據，以供其他節點查看。

歷史的

這些節點從深度存儲加載段，然后在其之上提供查詢。 在Druid上運行的大多數分析查詢大部分時間將進入這些節點。 因此，這些節點是集群的主要工作者。

節點從Zookeeper獲得在深度存儲中發布的任何新段的信息。 然后下載并加載該細分受眾群以進行投放。 節點還在本地磁盤中緩存了一些段，這使它們可以在發生某些重啟時快速為查詢提供服務。 節點還提供讀取一致性，因為它們僅處理不可變的段。

歷史節點也可以分為多個層次，每個層次具有不同的可配置性。 例如 可以將具有較高核心數的節點放在一個層中，以為經常訪問的數據提供服務，而為其他數據提供資源較少的節點。

ZooKeeper的可用性阻礙了這些節點加載新段的能力，但是舊段繼續提供服務而沒有任何停機時間。

> Historical Nodes in action (from druid whitepaper)

經紀人Broker

所有用戶查詢都轉到代理節點。 然后，這些節點將請求重定向到適當的歷史和實時節點，將結果合并并發送回去。 節點還維護內存中的LRU緩存（可以更改為使用Memcached）。 緩存包含每個段的結果。 但是，僅歷史節點段的結果是緩存，因為實時數據會經常保留更改。

這些節點還使用Zookeeper發現其他節點。 如果Zookeeper發生故障，它們將以集群狀態的最后快照為數據提供服務。

協調員

由于"歷史"節點很笨，因此協調員有責任告訴他們該怎么做。 具體來說，協調器發出以下命令：

• · 將實時節點發布的新細分加載到HDFS中。
• · 刪除過時的數據。
• · 復制數據以實現冗余，以便您可以容忍節點故障。
• · 跨多個節點負載均衡數據。

只有一個協調器節點被選為領導者，它負責整個操作，而其余節點僅充當備份者。

協調器從Zookeeper獲取最新的群集狀態，以及有關應從MySQL服務的段的信息。 MySQL的中斷以及Zookeeper的中斷阻礙了分配或刪除新段的能力，但是舊段仍然是可查詢的。

那么，什么使其比同行更好？

責任分工

由于每個節點只關注一個主要問題，因此簡化了整個系統的復雜性。 所有組件之間的交互最少，集群內通信故障（在讀取過程中）幾乎不影響可用性。 群集通過Zookeeper保持同步。 即使Zookeeper掉線了，盡管您將無法創建任何新的段，從而影響寫入，但讀取仍然可能發生。

列式存儲

由于druid是為分析查詢而設計的，因此它以列導向的格式存儲數據。 面向列的格式可以提供更好的壓縮率（因為單個列中的大多數數據都是相似的）和更好的查詢性能，因為通常在分析查詢中并非所有列都可以訪問，因此僅加載實際需要的數據。 對于字符串列，德魯伊通常執行字典編碼，然后應用LZF壓縮以減小數據大小。

防止不必要的掃描

Druid維護著一個字符串值的倒排索引，這樣我們就可以知道在哪個行中可以看到一個特定的值。 這允許僅掃描其中存在值的那些行。

上表的倒排索引看起來像

Foo：[1,0,0,1,0,1]

Bar：[0,1,1,0,1,0]

其中1表示索引中的行中存在特定鍵。 如果要掃描包含Foo和Bar的所有行，只需對兩個索引進行OR。

基數估計

為了獲得準確的基數匯總，例如確定每分鐘訪問您的站點的唯一用戶數，您需要將用戶存儲在某種數據結構（例如HashSet）中，然后對其中的元素總數進行計數。 但是，這導致大量空間需求。

另一方面，Druid使用HyperLogLog對其進行性能測試，其準確性約為97％。 對于大多數運行分析查詢的人來說，這通常很好。 您甚至可以通過在索引過程中在攝取時預先計算HLL來使其更快。

預聚集

德魯伊可以在攝取時預聚合數據（稱為匯總）。 這減少了存儲數據的大小，也使聚合查詢快得多。 在這種情況下，您確實會丟失每行信息，這就是為什么可以在攝取期間將其禁用。

快取

Druid在代理上維護每個段的查詢緩存，這有助于快速返回結果。 它還在歷史和實時服務器中緩存數據，以加快掃描速度。

> Per segment Cache (from druid whitepaper)

負載均衡

協調器以這樣的方式分配段：在歷史節點之間不偏斜段。 它考慮了數據大小，源和新近度，因此還提供了最佳性能，例如 普通查詢涵蓋了跨越最近創建的細分的單個數據源，因此明智的做法是以更高的速率復制最近創建的細分，以使這些查詢可以由多個節點提供服務。

基于時間的分區

Druid需要用于數據分發和保留的必填時間戳列。 包含一年中分布的時間戳的數據按天劃分更好，而具有一天中分布的時間戳的數據按小時劃分更好。 此時間戳還用于在寫入Druid時忽略舊事件。 按時間分區還有助于更好地分配和復制段。

如果您想了解有關Druid的更多信息，請參考以下鏈接：

• · 官方文件
• · 德魯伊：實時分析數據存儲（白皮書）
• · Druid簡介，您的交互式Analytics（大規模）
• · MetaMarkets-楊德進在YouTube上對Druid的介紹

(本文翻譯自Kartik Khare的文章《What Makes Apache Druid Great for Realtime Analytics?》，參考：
https://codeburst.io/what-makes-apache-druid-great-for-realtime-analytics-61f817ee5ff6)