目前廣為人知的Druid有兩個，一個是阿里巴巴開源的Durid數據庫連接池，一個是MetaMarkets開源的分布式、實時多維OLAP分析的數據處理系統。

這篇文章將介紹后者，即Apache Druid。由美國廣告技術公司MetaMarkets公司2012年開源，孵化于Apache。

一、Apache Druid 是什么？

Druid 是一個分布式的、支持實時多維 OLAP 分析的數據處理系統。它既支持高速的數據實時攝入處理，也支持實時且靈活的多維數據分析查詢。因此 Druid 最常用的場景就是大數據背景下、靈活快速的多維 OLAP 分析。另外，Druid 還有一個關鍵的特點：它支持根據時間戳對數據進行預聚合攝入和聚合分析，因此也有用戶經常在有時序數據處理分析的場景中用到它。

二、Apache Druid基本特點

Druid是一個用于大數據實時查詢和分析的高容錯、高性能開源分布式系統，旨在快速處理大規模的數據，并能夠實現快速查詢和分析。分析和存儲系統，提供極具成本效益并且永遠在線的實時數據攝取和任意數據處理。

為分析而設計——Druid是為OLAP工作流的探索性分析而構建。它支持各種filter、aggregator和查詢類型，并為添加新功能提供了一個框架。用戶已經利用Druid的基礎設施開發了高級查詢和直方圖功能。

交互式查詢——Druid的低延遲數據攝取架構允許事件在它們創建后毫秒內查詢，因為Druid的查詢延時通過只讀取和掃描有必要的元素被優化。Aggregate和 filter沒有坐等結果。

高可用性——Druid是用來支持需要一直在線的SaaS的實現。你的數據在系統更新時依然可用、可查詢。規模的擴大和縮小不會造成數據丟失。

可伸縮——現有的Druid部署每天處理數十億事件和TB級數據。Druid被設計成PB級別。

Druid主要是解決低延遲下實時數據攝入與查詢的平臺，本質是一個數據存儲。數據存儲格式對一款存儲系統來說是最核心的組件，Druid 的數據格式是自定義的，以此保證了在海量數據下的亞秒級查詢。

Druid有如下一些特性：

1. 亞秒響應的交互式查詢，支持較高并發。

2. 支持實時導入，導入即可被查詢，支持高并發導入。

3. 采用分布式 shared-nothing 的架構，可以擴展到PB級。

4. 支持聚合函數，count 和 sum，以及使用 JAVAscript 實現自定義 UDF。

5. 支持復雜的 Aggregator，近似查詢的 Aggregator，例如 HyperLoglog 以及 Yahoo 開源的 DataSketches。

6. 支持Groupby，Select，Search查詢。

7. 不支持大表之間的Join，但其 lookup 功能滿足和維度表的 Join。

Druid為什么查詢速度快？

數據的預聚合：Druid 可以按照給定的時間粒度和所有維度列，進行最細粒度的指標聚合運算，并加以保存為原始數據。

列式存儲：對部分列進行查詢時可以顯著提高效率。

Bitmap 索引：利用位圖對所有維度列構建索引，可以快速定位數據行。

mmap：通過內存映射文件的方式加快對于 Segment 的訪問。

查詢結果的中間緩存：支持對于查詢級別和 Segment 級別的緩存。

三、Druid使用場景

Druid適合于以下場景：

插入頻繁，但很少更新。

大多數查詢都是聚合和報告性質的查詢（group by查詢）以及搜索和掃描查詢。

查詢延遲要求為100毫秒到幾秒。

數據中有一個時間組件（Druid包括具體與時間相關的優化和設計選擇）。

有多個表，但每次查詢只能訪問一個大的分布式表，或者查詢可能會遇到多個較小的“查找”表。

有高基數數據列（例如URL，用戶ID），需要對它們進行快速計數和排名。

希望從Kafka，HDFS，文件或對象存儲（如Amazon S3）中加載數據。

Druid不適用于以下場景：

需要使用主鍵對現有記錄進行低延遲更新。Druid支持流式插入，但不支持流式更新（使用后臺批處理作業進行更新）。

需要構建一個離線報告系統，其中查詢延遲不是很重要。

想做big joins(將一個大事實表連接到另一個大事實表)，可能完成這些查詢需要花費你幾個小時。

四、Druid架構圖

如圖所示，分為三種服務器類型：主服務器（Master）、查詢服務器（Query）和數據服務器（Data）。

Master：運行Coordinator和Overlord進程，管理數據可用性和攝取。

Query：運行Broker和可選的Router進程，處理來自外部客戶端的查詢。

Data：運行Historical和MiddleManager進程，運行數據的采集以及存儲所有歷史查詢數據負載。

Druid有若干不同類型的進程，簡單描述如下：

Coordinator 進程：負責集群 Segment 的管理和發布，并確保 Segment 在 Historical 集群中的負載均衡。

Overlord 進程：負責接受任務、協調任務的分配、創建任務鎖以及收集、返回任務運行狀態給客戶端；通過設置 druid.Coordinator.asOverlord.enabled 屬性，Coordinator進程和Overlord進程可以作為單個組合進程運行。讓 Coordinator 具備 Overlord 功能，這樣可以減少一個組件的部署和運維。

Broker 進程：負責從客戶端接收查詢請求，并將查詢請求轉發給 Historical 節點和 MiddleManager 節點。Broker 節點需要感知 Segment 信息在集群上的分布。

Router 進程：是一個可選進程，可以將請求路由到Brokers、Coordinators和Overlords。

Historical 進程：主要負責加載索引文件，同時提供歷史數據的查詢服務。

MiddleManager 進程：主要是負責數據索引，生成索引文件，并把索引文件先發布到一個共享的存儲系統里，如普遍采用的 HDFS 系統。

在架構圖中，最下面的部分是外部依賴。除了內置的進程類型外，Druid同時有三個外部依賴，它們旨在利用現有的基礎設施。

（1）Metadata Storage

存儲關于Druid中的Metadata，規則數據、配置數據等，主要包含以下幾張表：

druid_config（通常是空的），druid_rules（協作節點使用的一些規則信息，比如哪個segment從哪個node去load），druid_segments（存儲每個segment的metadata信息）。

生產環境中可以使用MySQL。

（2）Zookeeper

分布式協調服務，用于節點管理和事件監控。

查詢節點通過Zookeeper來感知實時節點和歷史節點的存在，提供查詢服務。

協調節點通過Zookeeper感知歷史節點，實現負載均衡。

統治節點、協調節點的leader選舉。

（2）Deep Storage

用于存儲 Segment 文件供 Historical 節點下載。Deep Storage 不屬于 Druid 內部組件，用戶可根據系統規模來自定義配置。單節點可用本地磁盤，分布式可用 HDFS。

五、Druid的數據源和分段

Druid的數據存儲在DataSource中，DataSource 是一個邏輯概念，表示 Druid 的基本數據結構，可以理解為關系型數據庫中的表。它包含時間、維度和指標三列。

時間（TimeStamp）：表明每行數據的時間值，默認使用 UTC 時間格式且精確到毫秒級別。這個列是數據聚合與范圍查詢的重要維度。

維度（Dimension）：標識數據行的各個類別信息。

指標（Metric）：用于聚合計算的列，這些指標列通常是一些數字，主要操作包括 Count、Sum 和 Mean 等。

每一個數據源按照時間進行分段，當然你還可以選擇其他屬性進行分段。

每一個時間區間被稱為一個"Chunk"。舉個例子，如果以天分區，則一個Chunk為一天。在一個Chunk內，數據被分成一個或者多個"segments"。每個segment是一個單獨的文件，它由數以百萬的數據行構成。因為segment是組織在時間Chunk里的，所以按照時間曲線有助于理解segments。

這些segment是按照時間組織成的Chunk，所以在按照時間查詢數據時，效率非常高。

segment 是 Druid 中數據的實際物理存儲格式，Druid 正是通過 segment 實現了對數據的橫縱向切割（Slice and Dice）操作：

橫向：通過參數 segmentGranularity 的設置，將不同時間范圍內的數據存儲在不同的 segment 數據塊中。這樣在指定時間范圍內查詢時，可以不用掃全表。

縱向：即列式存儲，對每個列進行切分并壓縮，且利用 Bitmap 構建索引從而優化數據訪問。

一個數據源剛開始由幾個segments組成，一直擴展到幾百幾千甚至上百萬個segments。每個segment的生命周期始于被MiddleManager創建，這個時候segment是可變的沒有被提交的。一個segment的構建包含以下列出來的幾個步驟，這種設計是為了滿足一個可以支持壓縮并可以被快速查詢的文件格式。

轉換成列式存儲格式

利用bitmap建立索引

利用多種算法進行壓縮

segments會周期性地提交。此時它會被寫入deep storage，然后狀態改為不可變的。隨后它會被從MiddleManager移動到Historical進程中去。與此同時，關于這個segment的一個條目也會被寫入元數據存儲。這個條目是描述該segment的元數據，包含segment的schema、大小、以及它在deep storage上的存儲位置。所有這些類似的條目都會被Coordinator用來尋找對應的數據是否在集群上是可用狀態的。