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

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

一、Apache Druid 是什么？

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

二、Apache Druid基本特點(diǎn)

Druid是一個用于大數(shù)據(jù)實時查詢和分析的高容錯、高性能開源分布式系統(tǒng)，旨在快速處理大規(guī)模的數(shù)據(jù)，并能夠?qū)崿F(xiàn)快速查詢和分析。分析和存儲系統(tǒng)，提供極具成本效益并且永遠(yuǎn)在線的實時數(shù)據(jù)攝取和任意數(shù)據(jù)處理。

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

交互式查詢——Druid的低延遲數(shù)據(jù)攝取架構(gòu)允許事件在它們創(chuàng)建后毫秒內(nèi)查詢，因為Druid的查詢延時通過只讀取和掃描有必要的元素被優(yōu)化。Aggregate和 filter沒有坐等結(jié)果。

高可用性——Druid是用來支持需要一直在線的SaaS的實現(xiàn)。你的數(shù)據(jù)在系統(tǒng)更新時依然可用、可查詢。規(guī)模的擴(kuò)大和縮小不會造成數(shù)據(jù)丟失。

可伸縮——現(xiàn)有的Druid部署每天處理數(shù)十億事件和TB級數(shù)據(jù)。Druid被設(shè)計成PB級別。

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

Druid有如下一些特性：

1. 亞秒響應(yīng)的交互式查詢，支持較高并發(fā)。

2. 支持實時導(dǎo)入，導(dǎo)入即可被查詢，支持高并發(fā)導(dǎo)入。

3. 采用分布式 shared-nothing 的架構(gòu)，可以擴(kuò)展到PB級。

4. 支持聚合函數(shù)，count 和 sum，以及使用 JAVAscript 實現(xiàn)自定義 UDF。

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

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

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

Druid為什么查詢速度快？

數(shù)據(jù)的預(yù)聚合：Druid 可以按照給定的時間粒度和所有維度列，進(jìn)行最細(xì)粒度的指標(biāo)聚合運(yùn)算，并加以保存為原始數(shù)據(jù)。

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

Bitmap 索引：利用位圖對所有維度列構(gòu)建索引，可以快速定位數(shù)據(jù)行。

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

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

三、Druid使用場景

Druid適合于以下場景：

插入頻繁，但很少更新。

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

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

數(shù)據(jù)中有一個時間組件（Druid包括具體與時間相關(guān)的優(yōu)化和設(shè)計選擇）。

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

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

希望從Kafka，HDFS，文件或?qū)ο蟠鎯Γㄈ鏏mazon S3）中加載數(shù)據(jù)。

Druid不適用于以下場景：

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

需要構(gòu)建一個離線報告系統(tǒng)，其中查詢延遲不是很重要。

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

四、Druid架構(gòu)圖

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

Master：運(yùn)行Coordinator和Overlord進(jìn)程，管理數(shù)據(jù)可用性和攝取。

Query：運(yùn)行Broker和可選的Router進(jìn)程，處理來自外部客戶端的查詢。

Data：運(yùn)行Historical和MiddleManager進(jìn)程，運(yùn)行數(shù)據(jù)的采集以及存儲所有歷史查詢數(shù)據(jù)負(fù)載。

Druid有若干不同類型的進(jìn)程，簡單描述如下：

Coordinator 進(jìn)程：負(fù)責(zé)集群 Segment 的管理和發(fā)布，并確保 Segment 在 Historical 集群中的負(fù)載均衡。

Overlord 進(jìn)程：負(fù)責(zé)接受任務(wù)、協(xié)調(diào)任務(wù)的分配、創(chuàng)建任務(wù)鎖以及收集、返回任務(wù)運(yùn)行狀態(tài)給客戶端；通過設(shè)置 druid.Coordinator.asOverlord.enabled 屬性，Coordinator進(jìn)程和Overlord進(jìn)程可以作為單個組合進(jìn)程運(yùn)行。讓 Coordinator 具備 Overlord 功能，這樣可以減少一個組件的部署和運(yùn)維。

Broker 進(jìn)程：負(fù)責(zé)從客戶端接收查詢請求，并將查詢請求轉(zhuǎn)發(fā)給 Historical 節(jié)點(diǎn)和 MiddleManager 節(jié)點(diǎn)。Broker 節(jié)點(diǎn)需要感知 Segment 信息在集群上的分布。

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

Historical 進(jìn)程：主要負(fù)責(zé)加載索引文件，同時提供歷史數(shù)據(jù)的查詢服務(wù)。

MiddleManager 進(jìn)程：主要是負(fù)責(zé)數(shù)據(jù)索引，生成索引文件，并把索引文件先發(fā)布到一個共享的存儲系統(tǒng)里，如普遍采用的 HDFS 系統(tǒng)。

在架構(gòu)圖中，最下面的部分是外部依賴。除了內(nèi)置的進(jìn)程類型外，Druid同時有三個外部依賴，它們旨在利用現(xiàn)有的基礎(chǔ)設(shè)施。

（1）Metadata Storage

存儲關(guān)于Druid中的Metadata，規(guī)則數(shù)據(jù)、配置數(shù)據(jù)等，主要包含以下幾張表：

druid_config（通常是空的），druid_rules（協(xié)作節(jié)點(diǎn)使用的一些規(guī)則信息，比如哪個segment從哪個node去load），druid_segments（存儲每個segment的metadata信息）。

生產(chǎn)環(huán)境中可以使用MySQL。

（2）Zookeeper

分布式協(xié)調(diào)服務(wù)，用于節(jié)點(diǎn)管理和事件監(jiān)控。

查詢節(jié)點(diǎn)通過Zookeeper來感知實時節(jié)點(diǎn)和歷史節(jié)點(diǎn)的存在，提供查詢服務(wù)。

協(xié)調(diào)節(jié)點(diǎn)通過Zookeeper感知?dú)v史節(jié)點(diǎn)，實現(xiàn)負(fù)載均衡。

統(tǒng)治節(jié)點(diǎn)、協(xié)調(diào)節(jié)點(diǎn)的leader選舉。

（2）Deep Storage

用于存儲 Segment 文件供 Historical 節(jié)點(diǎn)下載。Deep Storage 不屬于 Druid 內(nèi)部組件，用戶可根據(jù)系統(tǒng)規(guī)模來自定義配置。單節(jié)點(diǎn)可用本地磁盤，分布式可用 HDFS。

五、Druid的數(shù)據(jù)源和分段

Druid的數(shù)據(jù)存儲在DataSource中，DataSource 是一個邏輯概念，表示 Druid 的基本數(shù)據(jù)結(jié)構(gòu)，可以理解為關(guān)系型數(shù)據(jù)庫中的表。它包含時間、維度和指標(biāo)三列。

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

維度（Dimension）：標(biāo)識數(shù)據(jù)行的各個類別信息。

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

每一個數(shù)據(jù)源按照時間進(jìn)行分段，當(dāng)然你還可以選擇其他屬性進(jìn)行分段。

每一個時間區(qū)間被稱為一個"Chunk"。舉個例子，如果以天分區(qū)，則一個Chunk為一天。在一個Chunk內(nèi)，數(shù)據(jù)被分成一個或者多個"segments"。每個segment是一個單獨(dú)的文件，它由數(shù)以百萬的數(shù)據(jù)行構(gòu)成。因為segment是組織在時間Chunk里的，所以按照時間曲線有助于理解segments。

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

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

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

縱向：即列式存儲，對每個列進(jìn)行切分并壓縮，且利用 Bitmap 構(gòu)建索引從而優(yōu)化數(shù)據(jù)訪問。

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

轉(zhuǎn)換成列式存儲格式

利用bitmap建立索引

利用多種算法進(jìn)行壓縮

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

六、Druid應(yīng)用實踐

Druid當(dāng)前最新版本為0.20。下載鏈接：http://druid.apache.org/downloads.html

Druid 有著很成熟的用戶群體，包括國內(nèi)外的知名企業(yè)，國外的話當(dāng)屬 Airbnb，這家公司在內(nèi)部大量使用 Druid 來做分析，包括他們開源的知名 BI 工具 Apache Superset，也在其中專門為 Druid 寫了一套 Query Engine。國內(nèi)公司像阿里、小米、58都在用。