1. Druid簡(jiǎn)介

1. 1 概述

Druid是一個(gè)快速的列式分布式的支持實(shí)時(shí)分析的數(shù)據(jù)存儲(chǔ)系統(tǒng)。它在處理PB級(jí)數(shù)據(jù)、毫秒級(jí)查詢、數(shù)據(jù)實(shí)時(shí)處理方面，比傳統(tǒng)的OLAP系統(tǒng)有了顯著的性能改進(jìn)。

10年積累的成都做網(wǎng)站、成都網(wǎng)站制作、成都外貿(mào)網(wǎng)站建設(shè)經(jīng)驗(yàn)，可以快速應(yīng)對(duì)客戶對(duì)網(wǎng)站的新想法和需求。提供各種問(wèn)題對(duì)應(yīng)的解決方案。讓選擇我們的客戶得到更好、更有力的網(wǎng)絡(luò)服務(wù)。我雖然不認(rèn)識(shí)你，你也不認(rèn)識(shí)我。但先網(wǎng)站設(shè)計(jì)后付款的網(wǎng)站建設(shè)流程，更有雁峰免費(fèi)網(wǎng)站建設(shè)讓你可以放心的選擇與我們合作。

OLAP分析分為關(guān)系型聯(lián)機(jī)分析處理(ROLAP)、多維聯(lián)機(jī)分析處理(MOLAP)兩種，MOLAP需要數(shù)據(jù)預(yù)計(jì)算好為一個(gè)多維數(shù)組，典型方式就是Cube，而ROLAP就是數(shù)據(jù)本身什么樣就是什么樣，查詢時(shí)通過(guò)MPP提高分布式計(jì)算能力。

Druid是ROLAP路線，實(shí)時(shí)攝取數(shù)據(jù)，實(shí)時(shí)出結(jié)果，不像Kylin一樣，有一個(gè)顯式的預(yù)計(jì)算過(guò)程。

1.1.2 補(bǔ)充

MPP：俗稱大規(guī)模并行處理，數(shù)據(jù)庫(kù)集群中，每個(gè)節(jié)點(diǎn)都有獨(dú)立的磁盤存儲(chǔ)系統(tǒng)跟內(nèi)存系統(tǒng)，業(yè)務(wù)數(shù)據(jù)根據(jù)數(shù)據(jù)庫(kù)模型跟應(yīng)用特點(diǎn)被劃分到各個(gè)節(jié)點(diǎn)，MPP就是將任務(wù)并行分散到多個(gè)節(jié)點(diǎn)，每個(gè)節(jié)點(diǎn)計(jì)算完畢后將結(jié)果匯總下來(lái)得到最終結(jié)果。

Lambda架構(gòu)：該 架構(gòu)的設(shè)計(jì)是為了在處理大規(guī)模數(shù)據(jù)時(shí)，同時(shí)發(fā)揮流處理和批處理的優(yōu)勢(shì)。通過(guò)批處理提供全面、準(zhǔn)確的數(shù)據(jù)，通過(guò)流處理提供低延遲的數(shù)據(jù)，從而達(dá)到平衡延遲、吞吐量和容錯(cuò)性的目的。為了滿足下游的即席查詢，批處理和流處理的結(jié)果會(huì)進(jìn)行合并。一般有三層。

Batch Layer：批處理層，對(duì)離線的歷史數(shù)據(jù)進(jìn)行預(yù)計(jì)算。
Speed Layer：加速處理層，處理實(shí)時(shí)的增量數(shù)據(jù)。
Serving Layer：合并層，計(jì)算歷史數(shù)據(jù)和實(shí)時(shí)數(shù)據(jù)都有了。

注意：阿里巴巴也曾創(chuàng)建過(guò)一個(gè)開(kāi)源項(xiàng)目叫作Druid(簡(jiǎn)稱阿里Druid)，它是一個(gè)數(shù)據(jù)庫(kù)連接池的項(xiàng)目。阿里Druid和本文討論的Druid沒(méi)有任何關(guān)系，它們解決完全不同的問(wèn)題。

1.2 Druid 特點(diǎn)

• 低延遲交互式查詢：Druid提供低延遲實(shí)時(shí)數(shù)據(jù)攝取(?庫(kù))，典型的lambda架構(gòu)。并采?預(yù)聚合、列式存儲(chǔ)、位圖索引等?段使得海量數(shù)據(jù)分析能夠亞秒級(jí)響應(yīng)。
• ?可?性( High Available )：Druid 使?用 HDFS/S3 作為 Deep Storage，Segment 會(huì)在多個(gè)Historical 節(jié)點(diǎn)上進(jìn)行加載，攝取數(shù)據(jù)時(shí)也可以多副本攝取，保證數(shù)據(jù)可?性和容錯(cuò)性。
• 可伸縮( Horizontal Scalable )：Druid 部署架構(gòu)都可以?平擴(kuò)展，增加大量服務(wù)器來(lái)加快數(shù)據(jù)攝取，以保證亞秒級(jí)的查詢服務(wù)。集群擴(kuò)展和縮小，只需添加或刪除服務(wù)器，集群將在后臺(tái)自動(dòng)重新平衡，無(wú)需任何停機(jī)時(shí)間。
• 并行處理( Parallel Processing ): Druid 可以在整個(gè)集群中進(jìn)行大規(guī)模的并行處理查詢(MPP)。
• 豐富的查詢能力( Rich Query )：Druid支持時(shí)間序列、 TopN、 GroupBy等查詢，同時(shí)提供了2種查詢方式：API 和 SQL(功能較少)。

1.3 Druid 適用 & 不適用場(chǎng)景

?句話總結(jié)，Druid適合帶時(shí)間維度、海量數(shù)據(jù)的實(shí)時(shí)/準(zhǔn)實(shí)時(shí)分析

• 帶時(shí)間字段的數(shù)據(jù)，且時(shí)間維度為分析的主要維度。
• 快速交互式查詢，且亞秒級(jí)快速響應(yīng)。
• 多維度海量數(shù)據(jù)，能夠預(yù)先定義維度。
• 適用于清洗好的記錄實(shí)時(shí)錄入，但不需要更新操作。
• 適用于支持寬表，不用Join的方式(換句話說(shuō)就是一張單表)。
• 適用于可以總結(jié)出基礎(chǔ)的統(tǒng)計(jì)指標(biāo)，用一個(gè)字段表示。
• 適用于對(duì)數(shù)據(jù)質(zhì)量的敏感度不高的場(chǎng)景(原生版本非精確去重)。

Druid 不適合的場(chǎng)景

• 要求明細(xì)查詢(破解?法是數(shù)據(jù)冗余)。
• 要求原?生Join(提前Join再入Druid)。
• 沒(méi)有時(shí)列或者不以時(shí)間作為主要分析維度。
• 不支持多時(shí)間維度，所有維度均為string類型。
• 想通過(guò)單純SQL語(yǔ)法查詢。

1.4 橫向?qū)Ρ?/h3>

產(chǎn)品對(duì)比

• Druid：是一個(gè)實(shí)時(shí)處理時(shí)序數(shù)據(jù)的OLAP數(shù)據(jù)庫(kù)，因?yàn)樗乃饕紫劝凑諘r(shí)間分片，查詢的時(shí)候也是按照時(shí)間線去路由索引。提起預(yù)聚合了模型，不適合即席查詢分享，不支持JOIN，SQL支持雞肋，不適合明細(xì)查詢。
• Kylin：核心是Cube，Cube是一種預(yù)計(jì)算技術(shù)，基本思路是預(yù)先對(duì)數(shù)據(jù)作多維索引，查詢時(shí)只掃描索引而不訪問(wèn)原始數(shù)據(jù)從而提速。不適合即席查詢(提前定于模型預(yù)聚合，預(yù)技術(shù)量大)，不支持明細(xì)查詢，外部依賴較多，不支持多事實(shí)表Join。
• Presto：它沒(méi)有使用MapReduce，大部分場(chǎng)景下比Hive快一個(gè)數(shù)量級(jí)，其中的關(guān)鍵是所有的處理都在內(nèi)存中完成。不支持預(yù)聚合，自己沒(méi)存儲(chǔ)。
• Impala：基于內(nèi)存運(yùn)算，速度快，支持的數(shù)據(jù)源沒(méi)有Presto多。不支持預(yù)聚合，自己沒(méi)存儲(chǔ)。
• Spark SQL：基于Spark平臺(tái)上的一個(gè)OLAP框架，基本思路是增加機(jī)器來(lái)并行計(jì)算，從而提高查詢速度。
• ElasticSearch：最大的特點(diǎn)是使用了倒排索引解決索引問(wèn)題。根據(jù)研究，ES在數(shù)據(jù)獲取和聚集用的資源比在Druid高。不支持預(yù)聚合，不適合超大規(guī)模數(shù)據(jù)處理，組合查詢性能欠佳。
• ClickHouse：C++編寫的高性能OLAP工具，不支持高并發(fā)，數(shù)據(jù)量超大會(huì)出現(xiàn)瓶頸(盡量選擇預(yù)聚合出結(jié)果表)，賊吃CPU資源(新版支持MVCC)。
• 框架選型：從超大數(shù)據(jù)的查詢效率來(lái)看 Druid > Kylin > Presto > Spark SQL，從支持的數(shù)據(jù)源種類來(lái)講 Presto > Spark SQL > Kylin > Druid。

2. Druid 架構(gòu)

Druid為了實(shí)現(xiàn)海量數(shù)據(jù)實(shí)時(shí)分析采?了?些特殊的?段和?較復(fù)雜的架構(gòu)，大致分兩節(jié)分別介紹。

2.1 Druid 核心概念

Druid能實(shí)現(xiàn)海量數(shù)據(jù)實(shí)時(shí)分析，主要采取了如下特殊手段。

• 預(yù)聚合。
• 列式存儲(chǔ)。
• 多級(jí)分區(qū) + 位圖索引(Datasource、Segments)。

2.1.1 roll up 預(yù)聚合

分析查詢逃不開(kāi)聚合操作，Druid在數(shù)據(jù)?庫(kù)時(shí)就提前進(jìn)行了聚合，這就是所謂的預(yù)聚合(roll-up)。Druid把數(shù)據(jù)按照選定維度的相同的值進(jìn)行分組聚合，可以?大降低存儲(chǔ)?小。數(shù)據(jù)查詢的時(shí)候只需要預(yù)聚合的數(shù)據(jù)基礎(chǔ)上進(jìn)行輕量的?次過(guò)濾和聚合即可快速拿到分析結(jié)果，當(dāng)然預(yù)聚合是以犧牲明細(xì)數(shù)據(jù)分析查詢?yōu)榇鷥r(jià)。

要做預(yù)聚合，Druid要求數(shù)據(jù)能夠分為三個(gè)部分：

• Timestamp列：Druid所有分析查詢均涉及時(shí)間(思考：時(shí)間實(shí)際上是?個(gè)特殊的維度，它可以衍?出一堆維度，Druid把它單列列出來(lái)了)
• Dimension列(維度)：Dimension列指?于分析數(shù)據(jù)?度的列，例如從地域、產(chǎn)品、用戶的角度來(lái)分析訂單數(shù)據(jù)，一般?用于過(guò)濾、分組等等。
• Metric列(度量)：Metric列指的是?于做聚合和其他計(jì)算的列。?般來(lái)說(shuō)是數(shù)字。

{"timestamp":"2018-01-01T01:01:35Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":20,"bytes":9024}
{"timestamp":"2018-01-01T01:01:51Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":255,"bytes":21133}
{"timestamp":"2018-01-01T01:01:59Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":11,"bytes":5780}
{"timestamp":"2018-01-01T01:02:14Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":38,"bytes":6289}
{"timestamp":"2018-01-01T01:02:29Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":377,"bytes":359971}
{"timestamp":"2018-01-01T01:03:29Z","srcIP":"1.1.1.1","dstIP":"2.2.2.2","packets":49,"bytes":10204}
{"timestamp":"2018-01-02T21:33:14Z","srcIP":"7.7.7.7","dstIP":"8.8.8.8","packets":38,"bytes":6289}
{"timestamp":"2018-01-02T21:33:45Z","srcIP":"7.7.7.7","dstIP":"8.8.8.8","packets":123,"bytes":93999}
{"timestamp":"2018-01-02T21:35:45Z","srcIP":"7.7.7.7","dstIP":"8.8.8.8","packets":12,"bytes":2818}

比如上面這樣一份明細(xì)數(shù)據(jù)，timestamp當(dāng)然是Timestamp列，srcIP和dstIP是Dimension列(維度)，packets和bytes是Metric列。該數(shù)據(jù)?庫(kù)到Druid時(shí)如果我們打開(kāi)預(yù)聚合功能(可以不打開(kāi)聚合，數(shù)據(jù)量?大就不?了)，要求對(duì)packets和bytes進(jìn)?行行累加(sum)，并且要求按條計(jì)數(shù)(count *)，聚合之后的數(shù)據(jù)是這樣的：

聚合后數(shù)據(jù)

2.1.2 列式存儲(chǔ)

行式：

行式存儲(chǔ)查詢

列式：

列式存儲(chǔ)查詢

在大數(shù)據(jù)領(lǐng)域列式存儲(chǔ)是個(gè)常見(jiàn)的優(yōu)化手段，一般在OLTP數(shù)據(jù)庫(kù)會(huì)用行式存儲(chǔ)，OLAP數(shù)據(jù)庫(kù)會(huì)使用列式存儲(chǔ)。列式存儲(chǔ)一般有如下優(yōu)點(diǎn)：

對(duì)于分析查詢，?般只需要?到少量的列，在列式存儲(chǔ)中，只需要讀取所需的數(shù)據(jù)列即可。例例如，如果您需要100列列中的5列，則I / O減少20倍。

按列分開(kāi)存儲(chǔ)，按數(shù)據(jù)包讀取時(shí)因此更易于壓縮。列中的數(shù)據(jù)具有相同特征也更易于壓縮， 這樣可以進(jìn)?步減少I / O量。

由于減少了I / O，因此更更多數(shù)據(jù)可以容納在系統(tǒng)緩存中，進(jìn)?步提?分析性能。

2.1.3 DataSource & Segments

Druid的數(shù)據(jù)在存儲(chǔ)層面是按照Datasource和Segments實(shí)現(xiàn)多級(jí)分區(qū)存儲(chǔ)的，并建?了位圖索引。

• Datasource相當(dāng)于關(guān)系型數(shù)據(jù)庫(kù)中的表，
• Datasource會(huì)按照時(shí)間來(lái)分片(類似于HBase?里里的Region和Kudu?的tablet)，每?個(gè)時(shí)間分?被稱為chunk，
• chunk并不是直接存儲(chǔ)單元，在chunk內(nèi)部數(shù)據(jù)還會(huì)被切分為?個(gè)或者多個(gè)segment。所有的segment獨(dú)?立存儲(chǔ)，通常包含數(shù)百萬(wàn)?行行，segment與chunk的關(guān)系如下圖：

Segment跟Chunk

Segment是Druid數(shù)據(jù)存儲(chǔ)的最小單元，內(nèi)部采用列式存儲(chǔ)，建立了位圖索引，對(duì)數(shù)據(jù)進(jìn)行了編碼跟壓縮。

Druid數(shù)據(jù)存儲(chǔ)的攝取方式、聚合方式、每列數(shù)據(jù)存儲(chǔ)的字節(jié)起始位都有存儲(chǔ)。

2.1.4 位圖索引

假設(shè)現(xiàn)有這樣一份數(shù)據(jù)：

原始數(shù)據(jù)

以tp為時(shí)間列，appkey和city為維度，以value為度量值，導(dǎo)?Druid后按天聚合，最終結(jié)果是：

聚合后

數(shù)據(jù)經(jīng)過(guò)聚合之后查詢本身就很快了，為了進(jìn)?步加速對(duì)聚合之后數(shù)據(jù)的查詢，Druid會(huì)建立位圖索引：

位圖索引

上?的位圖索引不是針對(duì)列?是針對(duì)列的值，記錄了列的值在數(shù)據(jù)的哪?行出現(xiàn)過(guò)，第一列是具體列的值，后續(xù)列標(biāo)識(shí)該列的值在某??是否出現(xiàn)過(guò)，依次是第1列到第n列。例如appkey1在第??出現(xiàn)過(guò)，在其他?沒(méi)出現(xiàn)，那就是1000(例子中只有四個(gè)列)。

Select sum(value) from xxx where time=’2019-11-11’and appkey in
(‘a(chǎn)ppkey1’,’appkey2’) and area=’北京’

當(dāng)我們有如上查詢時(shí)，?先根據(jù)時(shí)間段定位到segment，然后根據(jù)appkey in (‘a(chǎn)ppkey1’,’appkey2’) and area=’北京’ 查到各?的bitmap：(appkey1(1000) or appkey2(0110)) and 北京(1100) = (1100) 也就是說(shuō)，符合條件的列是第?行和第?行，這兩?的metric的和為125.

2.2 Druid 架構(gòu)

2.2.1 核心架構(gòu)

Druid在架構(gòu)上主要參考了Google的Dremel，PowerDrill。

Druid官方架構(gòu)圖

Druid核?架構(gòu)中包括如下節(jié)點(diǎn)(Druid 的所有功能都在同?個(gè)包，通過(guò)不同的命令啟動(dòng))：

• Coordinator: 負(fù)責(zé)集群 Segment 的管理和發(fā)布，并確保 Segment 在 Historical 集群中的負(fù)載均衡。
• Broker : 負(fù)責(zé)從客戶端接收查詢請(qǐng)求，并將查詢請(qǐng)求轉(zhuǎn)發(fā)給 Historical 節(jié)點(diǎn)和MiddleManager 節(jié)點(diǎn)。Broker 節(jié)點(diǎn)需要感知 Segment 信息在集群上的分布。
• Historical ：負(fù)責(zé)按照規(guī)則加載Segment并提供歷史數(shù)據(jù)的查詢。
• Router(可選) ：可選節(jié)點(diǎn)，在 Broker 集群之上的API?網(wǎng)關(guān)，有了 Router 節(jié)點(diǎn) Broker 不不在是單點(diǎn)服務(wù)了，提?高了并發(fā)查詢的能力，提供類似Nginx的功能。
• Indexing Service : Indexing Service顧名思義就是指索引服務(wù)，在索引服務(wù)?成segment的過(guò)程中，由OverlordNode接收加載任務(wù)，然后?成索引任務(wù)(Index Service)并將任務(wù)分發(fā)給多個(gè)MiddleManager節(jié)點(diǎn)，MiddleManager節(jié)點(diǎn)根據(jù)索引協(xié)議?生成多個(gè)Peon，Peon將完成數(shù)據(jù)的索引任務(wù)并?成segment，并將segment提交到分布式存儲(chǔ)?面(?般是HDFS)，然后Coordinator節(jié)點(diǎn)感知到segment?成，給Historical節(jié)點(diǎn)分發(fā)下載任務(wù)，Historical節(jié)點(diǎn)從分布式存儲(chǔ)?面下載segment到本地(?持量和流式攝取)。
• Overlord : Overlord Node負(fù)責(zé)segment生成的任務(wù)，并提供任務(wù)的狀態(tài)信息，當(dāng)然原理跟上?類似，也在Zookeeper中對(duì)應(yīng)的?錄下，由實(shí)際執(zhí)行任務(wù)的最?單位在Zookeeper中同步更新任務(wù)信息，類似于回調(diào)函數(shù)的執(zhí)?過(guò)程。跟Coordinator Node?樣，它在集群里??般只存在一個(gè)，如果存在多個(gè)Overlord Node，Zookeeper會(huì)根據(jù)選舉算法(?一致性算法避免腦裂)產(chǎn)?生?一個(gè)Leader，其余的當(dāng)Follower，當(dāng)Leader遇到問(wèn)題宕機(jī)時(shí)，Zookeeper會(huì)在Follower中再次選取?一個(gè)Leader，從?維持集群?成segment服務(wù)的正常運(yùn)行。Overlord Node會(huì)將任務(wù)分發(fā)給MiddleManager Node，由MiddleManager Node負(fù)責(zé)具體的segment?成任務(wù)。
• MiddleManager : Overlord Node會(huì)將任務(wù)分發(fā)給MiddleManager Node，所以MiddleManager Node會(huì)在Zookeeper中感知到新的索引任務(wù)。?但感知到新的索引任務(wù)，會(huì)創(chuàng)建Peon(segment具體執(zhí)?者，也是索引過(guò)程的最?單位)來(lái)具體執(zhí)行索引任務(wù)，一個(gè) MiddleManager Node會(huì)運(yùn)行很多個(gè)Peon的實(shí)例。

簡(jiǎn)單來(lái)說(shuō)：

• coordinator : 管理集群的數(shù)據(jù)視圖，segment的load與dropr。
• historical : 歷史節(jié)點(diǎn)，負(fù)責(zé)歷史窗?口內(nèi)數(shù)據(jù)的查詢r(jià)。
• broker : 查詢節(jié)點(diǎn)，查詢拆分，結(jié)果匯聚r。
• indexing service : ?套實(shí)時(shí)/批量數(shù)據(jù)導(dǎo)?任務(wù)的調(diào)度服務(wù)r。
• overlord : 負(fù)責(zé)接收任務(wù)，管理理任務(wù)狀態(tài)，類似Hadoop中ResourceManager。
• middleManager : 接受任務(wù)啟動(dòng)任務(wù)，類似Hadoop中NodeManager。
• peon : 實(shí)際的任務(wù)進(jìn)程，類似Hadoop中的container。

總結(jié)下大致查詢鏈路，查詢打到Router， Router選擇對(duì)應(yīng)的broker，broker會(huì)根據(jù)查詢時(shí)間，查詢屬性等因素來(lái)進(jìn)行segment篩選。broker會(huì)查找到對(duì)應(yīng)的Historical跟MiddleManager節(jié)點(diǎn)，這倆節(jié)點(diǎn)會(huì)重寫為子查詢，然后最終把結(jié)果匯總到broker，需要注意middleManager可以查詢沒(méi)有發(fā)布到歷史節(jié)點(diǎn)的數(shù)據(jù)，這樣Druid可以進(jìn)行近實(shí)時(shí)查詢。

Druid通過(guò)下面三種優(yōu)化方法提高查詢性能：

• Segment 裁剪。
• 對(duì)于每個(gè)Segment，通過(guò)索引過(guò)濾指定行。
• 制度去結(jié)果所需的行列。

2.2.2 外部依賴

• Zookeeper ：主要用于內(nèi)部服務(wù)發(fā)現(xiàn)，協(xié)調(diào)跟leader選舉。
• 深度存儲(chǔ)(Deep Storage) : 深度存儲(chǔ)服務(wù)是能夠被每個(gè)Druid服務(wù)能訪問(wèn)到的共享文件系統(tǒng)，一般類似S3、HDFS或網(wǎng)絡(luò)文件系統(tǒng)。
• 元數(shù)據(jù)存儲(chǔ)(Metadata Store) : 元數(shù)據(jù)存儲(chǔ)服務(wù)主要用來(lái)存儲(chǔ)Druid中一些元數(shù)據(jù)，比如segment相關(guān)信息，跟Hadoop一樣，一般把數(shù)存儲(chǔ)到MySQL中。

3. 數(shù)據(jù)攝取

3.1 攝取分類

目前Druid數(shù)據(jù)攝取主要有批量跟流式兩大類。

數(shù)據(jù)攝取

Druid的indexing-service即?持批量也支持流式，上表中的Native batch/本地批量索引和kafkaindexing-service(Pull)均使?用了了indexing-service，只不過(guò)通過(guò)攝取任務(wù)類型來(lái)區(qū)分。

3.2 Index Service

Index Service是運(yùn)行索引相關(guān)任務(wù)的?可?性分布式服務(wù)，它的架構(gòu)中包括了了Overlord、MiddleManager、Peon。簡(jiǎn)單理解:

• Indexing Service : ?套實(shí)時(shí)/批量數(shù)據(jù)導(dǎo)?任務(wù)的調(diào)度服務(wù)。
• Overlord-調(diào)度服務(wù)的master節(jié)點(diǎn)，負(fù)責(zé)接收任務(wù)，管理理任務(wù)狀態(tài)。
• MiddleManager-worker節(jié)點(diǎn)，接收任務(wù)啟動(dòng)任務(wù)。
• Peon-實(shí)際的任務(wù)進(jìn)程(Hadoop批量索引方式下，Pero就是YARN client)。

index Service工作流程

在上圖中，通過(guò)index-service的方式批量攝取數(shù)據(jù)，我們需要向Overlord提交?個(gè)索引任務(wù)，Overlord接受任務(wù)，通過(guò)Zookeeper將任務(wù)信息分配給MiddleManger，Middlemanager領(lǐng)取任務(wù)后創(chuàng)建Peon進(jìn)程，Peon通過(guò)Zookeeper向Overlord定期匯報(bào)任務(wù)狀態(tài)。

3.3 攝取規(guī)則

Druid?持批量數(shù)據(jù)攝?和實(shí)時(shí)流數(shù)據(jù)攝入兩種數(shù)據(jù)攝?方式，?論是哪種?式都得指定?個(gè)攝取規(guī)則?文件(Ingestion Spec)定義攝取的詳細(xì)規(guī)則(類似于Flume采集數(shù)據(jù)都得指定?個(gè)配置文件?樣)。

數(shù)據(jù)攝取時(shí)type可指定為index、index_hadoop、kafka這三種，然后可以嘗試通過(guò)本地、HDFS、Kafka準(zhǔn)備數(shù)據(jù)源，準(zhǔn)備好數(shù)據(jù)攝取規(guī)則文件。

4. 查詢

Druid?直提供REST API進(jìn)行數(shù)據(jù)查詢，在0.10之前第三方提供SQL?持，但不是很成熟，從0.10開(kāi)始原生提供實(shí)驗(yàn)性SQL查詢功能，截?Druid0.12.3還是處于實(shí)驗(yàn)性階段。

查詢方式

4.1 REST API 查詢

用戶可通過(guò)REST API的方式將請(qǐng)求包裝為JSON格式進(jìn)行查詢，返回的結(jié)果也是JSON格式，接下來(lái)主要說(shuō)明下請(qǐng)求JSON的格式。

4.2 Filter

Filter就是過(guò)濾器，?用對(duì)維度進(jìn)行行篩選和過(guò)濾，滿?Filter的行將會(huì)被返回，類似sql中的where?句。

• Selector Filte : 類似于SQL中的where colname=value。
• Regex Filter : 使用Java支持的正則表達(dá)式進(jìn)行維度過(guò)濾篩選。
• In Filter : 類似于SQL中的in語(yǔ)句。
• Bound Filter : 比較過(guò)濾器，包含?于，等于，?于三種，它默認(rèn)支持的就是字符串串?比較，如果使用數(shù)字進(jìn)行比較，需要在查詢中設(shè)定alpaNumeric的值為true，需要注意的是Bound Filter默認(rèn)的?小?較為>=或者<=，因此如果使用<或>,需要指定lowerStrict值為true，或者upperStrict值為true。
• Logincal Expression Filter : 包含and,not,or三種過(guò)濾器器，?持嵌套，可以構(gòu)建豐富的邏輯表達(dá)式，與sql 中的and、not、or類似。

4.3 granularity

granularity 配置項(xiàng)指定查詢時(shí)的時(shí)間聚合粒度，查詢時(shí)的時(shí)間聚合粒度要 >= 創(chuàng)建索引時(shí)設(shè)置的索引粒度，druid提供了了三種類型的聚合粒度分別是：Simple、Duration、Period。

Simple ：druid提供的固定時(shí)間粒度，?字符串串表示，默認(rèn)就是Simple，定義查詢規(guī)則的時(shí)候不需要顯示設(shè)置type配置項(xiàng)，druid提供的常?用Simple粒度：

all:會(huì)將起始和結(jié)束時(shí)間內(nèi)所有數(shù)據(jù)聚合到?一起返回?一個(gè)結(jié)果集，
none:按照創(chuàng)建索引時(shí)的最?粒度做聚合計(jì)算，最?粒度是毫秒為單位，不推薦使?，性能較差
minute:以分鐘作為聚合的最?小粒度
fifteen_minute:15分鐘聚合
thirty_minute:30分鐘聚合
hour:?小時(shí)聚合
day:天聚合
month：按年年聚合
quarter:按季度聚合

Duration : 對(duì)Simple的補(bǔ)充，duration聚合粒度提供了了更更加靈活的粒度，不不只局限于Simple聚合粒度提供的固定聚合粒度，?是以毫秒為單位?定義聚合粒度。

?如兩小時(shí)做?次聚合可以設(shè)置duration配置項(xiàng)為7200000毫秒，
所以Simple聚合粒度不能夠滿?足的聚合粒度可以選擇使?用Duration聚合粒度。
注意：使?用Duration聚合粒度需要設(shè)置配置項(xiàng)type值為duration。

Period : 聚合粒度采?了?期格式，常?的?種時(shí)間跨度表示?法。

一小時(shí)：PT1H
一周：P1W
?天：P1D
?月：P1M
注意： 使?Period聚合粒度需要設(shè)置配置項(xiàng)type值為period

4.4 Aggregator

聚合器在數(shù)據(jù)攝?和查詢是均可以使用，在數(shù)據(jù)攝?]入階段使?]用聚合器能夠在數(shù)據(jù)被查詢之前按照維度進(jìn)行聚合計(jì)算，提?查詢階段聚合計(jì)算性能，在查詢過(guò)程中，使?聚合器能夠?qū)崿F(xiàn)各種不同指標(biāo)的組合計(jì)算。

公共屬性：

• type : 聲明使?用的聚合器器類型
• name : 定義返回值的字段名稱，相當(dāng)于sql語(yǔ)法中的字段別名
• fieldName : 數(shù)據(jù)源中已定義的指標(biāo)名稱，該值不可以?自定義，必須與數(shù)據(jù)源中的指標(biāo)名?致

4.4.1 常見(jiàn)聚合器

• count

計(jì)數(shù)聚合器，等同于sql語(yǔ)法中的count函數(shù)，?于計(jì)算druid roll-up合并之后的數(shù)據(jù)條數(shù)，并不是原始數(shù)據(jù)條數(shù)。

在定義數(shù)據(jù)模式指標(biāo)規(guī)則中必須添加?個(gè)count類型的計(jì)數(shù)指標(biāo)count;
{"type":"count","name":out_name}

如果想要查詢?cè)紨?shù)據(jù)攝?入多少條，在查詢時(shí)使?用longSum,JSON示例例如下：
{"type":"longSum","name":out_name,"fieldName":"count"}

• sum

求和聚合器，等同于sql語(yǔ)法中的sum函數(shù)，druid提供兩種類型的聚合器，分別是long類型和double類型的聚合器。

longSum
doubleSum
floatSum

• Min/Max

類似SQL語(yǔ)法中的Min/Max

longMin
longMax
doubleMin
doubleMax
floatMin
floatMax

4.4.2 去重

原生 Druid 去重功能支持情況

• 維度列

僅支持單維度，構(gòu)建時(shí)需要基于該維度做 hash partition。

不能跨 interval 進(jìn)行計(jì)算。

cardinality agg，非精確，基于 hll 。查詢時(shí) hash 函數(shù)較耗費(fèi) CPU。

嵌套 group by，精確，耗費(fèi)資源。

社區(qū) DistinctCount 插件，精確，但是局限很大。

• 指標(biāo)列

HyperUniques/Sketch，非精確，基于 hll，攝入時(shí)做計(jì)算，相比 cardinality agg 性能更高。

結(jié)論：Druid 缺乏一種支持預(yù)聚合、資源占用低、通用性強(qiáng)的精確去重支持。用戶可自己基于bitmap、unique做二次開(kāi)發(fā)精確去重。

4.4.3 Post Aggregator

Post-Aggregator可以對(duì)結(jié)果進(jìn)?行?次加工并輸出，最終的輸出既包含Aggregation的結(jié)果，也包含Post-Aggregator的結(jié)果，Post-Aggregator包含的類型：

• Arithmetic Post-Aggregator ?持對(duì)Aggregator的結(jié)果進(jìn)行加減乘除的計(jì)算。
• Field Accessor Post-Aggregator 返回指定的Aggregator的值，在Post-Aggregator中大部分情況下使?用fieldAccess來(lái)訪問(wèn)Aggregator，在fieldName中指定Aggregator里定義的name。

4.5 查詢類型

druid的查詢分為三大類，分別是聚合查詢，元數(shù)據(jù)查詢以及普通查詢。

普通的查詢：

Select
Scan
Search

聚合查詢：

Timeseries
TopN
GroupBy

元數(shù)據(jù)查詢：

Time Bounding
Segment Metadata
DataSource Metadata

普通的查詢沒(méi)什么好講的，只有一個(gè)需要注意的點(diǎn)，那就是select在查詢大量的數(shù)據(jù)的時(shí)候，很消耗內(nèi)存，如果沒(méi)有分頁(yè)的需求，可以用scan替代。

元數(shù)據(jù)的查詢，主要不是基于業(yè)務(wù)的查詢，而是對(duì)當(dāng)前表的屬性，或者是定義列的類型這一類屬性的查詢，比如xxx表中"country"是什么類型的數(shù)據(jù)，xxx表收集數(shù)據(jù)起止時(shí)間，或者當(dāng)前分段的版本是什么之類的信息。

主要需要理解的是三種內(nèi)置的聚合查詢，本質(zhì)上做的操作是這樣的。

• timeseries: 時(shí)序查詢，實(shí)際上即是對(duì)數(shù)據(jù)基于時(shí)間點(diǎn)(timestamp)的一次上卷。適合用來(lái)看某幾個(gè)度量在一個(gè)時(shí)間段內(nèi)的趨勢(shì)。排序可按時(shí)間降序或升序。
• topN: 在時(shí)間點(diǎn)的基礎(chǔ)上，又增加了一個(gè)維度(OLAP的概念算兩個(gè)維度)，進(jìn)而對(duì)源數(shù)據(jù)進(jìn)行切片，切片之后分別上卷，最后返回一個(gè)聚合集，你可以指定某個(gè)指標(biāo)作為排序的依據(jù)。官方文檔稱這對(duì)比單個(gè)druid dimension 的groupBy 更高效。適合看某個(gè)維度下的時(shí)間趨勢(shì)，(比如美國(guó)和中國(guó)十年內(nèi)GDP的增長(zhǎng)趨勢(shì)比對(duì)，在這里除了時(shí)間外國(guó)家就是另外一個(gè)維度)。
• GroupBy: 適用于兩個(gè)維度以上的查詢，druid會(huì)根據(jù)維度切塊，并且分別上卷，最后返回聚合集。相對(duì)于topN而言，這是一個(gè)向下鉆取的操作，每多一個(gè)維度意味著保留更多的細(xì)節(jié)。(比如增加一個(gè)行業(yè)的維度，就可以知道美國(guó)和中國(guó)十年內(nèi)，每一年不同行業(yè)貢獻(xiàn)GDP的占比)。

一般在查詢時(shí)需要指定若干參數(shù)的。

參考

Druid官網(wǎng)：https://druid.apache.org

快手Druid實(shí)戰(zhàn)：https://toutiao.io/posts/9pgmav/preview

文章標(biāo)題：ApacheDruid歷險(xiǎn)記
文章分享：http://uogjgqi.cn/article/dhhjegi.html