點(diǎn)擊上方“朱小廝的博客”，選擇“設(shè)為星標(biāo)”

后臺(tái)回復(fù)"書(shū)"，獲取個(gè)gui

來(lái)源：jackywoo.cn

導(dǎo)讀：Kylin、Druid、ClickHouse是目前主流的OLAP引擎，本文嘗試從數(shù)據(jù)模型和索引結(jié)構(gòu)兩個(gè)角度，分析這幾個(gè)引擎的核心技術(shù)，并做簡(jiǎn)單對(duì)比。在閱讀本文之前希望能對(duì)Kylin、Druid、ClickHouse有所理解。

01

Kylin數(shù)據(jù)模型

Kylin的數(shù)據(jù)模型本質(zhì)上是將二維表（Hive表）轉(zhuǎn)換為Cube，然后將Cube存儲(chǔ)到HBase表中，也就是兩次轉(zhuǎn)換。

第一次轉(zhuǎn)換，其實(shí)就是傳統(tǒng)數(shù)據(jù)庫(kù)的Cube化，Cube由CuboId組成，下圖每個(gè)節(jié)點(diǎn)都被稱為一個(gè)CuboId，CuboId表示固定列的數(shù)據(jù)數(shù)據(jù)集合，比如“ AB” 兩個(gè)維度組成的CuboId的數(shù)據(jù)集合等價(jià)于以下SQL的數(shù)據(jù)集合：

select A, B, sum(M), sum(N) from table group by A, B

第二次轉(zhuǎn)換，是將Cube中的數(shù)據(jù)存儲(chǔ)到HBase中，轉(zhuǎn)換的時(shí)候CuboId和維度信息序列化到rowkey，度量列組成列簇。在轉(zhuǎn)換的時(shí)候數(shù)據(jù)進(jìn)行了預(yù)聚合。下圖展示了Cube數(shù)據(jù)在HBase中的存儲(chǔ)方式。

02

Kylin索引結(jié)構(gòu)

因?yàn)镵ylin將數(shù)據(jù)存儲(chǔ)到HBase中，所以kylin的數(shù)據(jù)索引就是HBase的索引。HBase的索引是簡(jiǎn)化版本的B+樹(shù)，相比于B+樹(shù)，HFile沒(méi)有對(duì)數(shù)據(jù)文件的更新操作。

HFile的索引是按照rowkey排序的聚簇索引，索引樹(shù)一般為二層或者三層，索引節(jié)點(diǎn)比MySQL的B+樹(shù)大，默認(rèn)是64KB。數(shù)據(jù)查找的時(shí)候通過(guò)樹(shù)形結(jié)構(gòu)定位到節(jié)點(diǎn)，節(jié)點(diǎn)內(nèi)部數(shù)據(jù)是按照rowkey有序的，可以通過(guò)二分查找快速定位到目標(biāo)。

Kylin小結(jié)：適用于聚合查詢場(chǎng)景；因?yàn)閿?shù)據(jù)預(yù)聚合，Kylin可以說(shuō)是最快的查詢引擎（group-by查詢這樣的復(fù)雜查詢，可能只需要掃描1條數(shù)據(jù)）；kylin查詢效率取決于是否命中CuboId，查詢波動(dòng)較大；HBase索引有點(diǎn)類(lèi)似MySQL中的聯(lián)合索引，維度在rowkey中的排序和查詢維度組合對(duì)查詢效率影響巨大；所以Kylin建表需要業(yè)務(wù)專(zhuān)家參與。

03

Druid數(shù)據(jù)模型

Druid數(shù)據(jù)模型比較簡(jiǎn)單，它將數(shù)據(jù)進(jìn)行預(yù)聚合，只不過(guò)預(yù)聚合的方式與Kylin不同，kylin是Cube化，Druid的預(yù)聚合方式是將所有維度進(jìn)行Group-by，可以參考下圖：

04

Druid索引結(jié)構(gòu)

Druid索引結(jié)構(gòu)使用自定義的數(shù)據(jù)結(jié)構(gòu)，整體上它是一種列式存儲(chǔ)結(jié)構(gòu)，每個(gè)列獨(dú)立一個(gè)邏輯文件（實(shí)際上是一個(gè)物理文件，在物理文件內(nèi)部標(biāo)記了每個(gè)列的start和offset）。對(duì)于維度列設(shè)計(jì)了索引，它的索引以Bitmap為核心。下圖為“city”列的索引結(jié)構(gòu)：

首先將該列所有的唯一值排序，并生成一個(gè)字典，然后對(duì)于每個(gè)唯一值生成一個(gè)Bitmap，Bitmap的長(zhǎng)度為數(shù)據(jù)集的總行數(shù)，每個(gè)bit代表對(duì)應(yīng)的行的數(shù)據(jù)是否是該值。Bitmap的下標(biāo)位置和行號(hào)是一一對(duì)應(yīng)的，所以可以定位到度量列，Bitmap可以說(shuō)是反向索引。同時(shí)數(shù)據(jù)結(jié)構(gòu)中保留了字典編碼后的所有列值，其為正向的索引。

那么查詢?nèi)绾问褂盟饕?#xff1f;以以下查詢?yōu)槔?#xff1a;

select site, sum(pv) from xx where date=2020-01-01 and city='bj' group by site

city列中二分查找dictionary并找到'bj'對(duì)應(yīng)的bitmap

遍歷city列，對(duì)于每一個(gè)字典值對(duì)應(yīng)的bitmap與'bj'的bitmap做與操作

每個(gè)相與后的bitmap即為city='bj'查詢條件下的site的一個(gè)group的pv的索引

通過(guò)索引在pv列中查找到相應(yīng)的行，并做agg

后續(xù)計(jì)算

Druid小結(jié)：Druid適用于聚合查詢場(chǎng)景但是不適合有超高基維度的場(chǎng)景；存儲(chǔ)全維度group-by后的數(shù)據(jù)，相當(dāng)于只存儲(chǔ)了KYLIN Cube的 Base-CuboID；每個(gè)維度都有創(chuàng)建索引，所以每個(gè)查詢都很快，并且沒(méi)有類(lèi)似KYLIN的巨大的查詢效率波動(dòng)。

05

ClickHouse索引結(jié)構(gòu)（只討論MergeTree引擎）

因?yàn)镃lickhouse數(shù)據(jù)模型就是普通二維表，這里不做介紹，只討論索引結(jié)構(gòu)。整體上Clickhouse的索引也是列式索引結(jié)構(gòu)，每個(gè)列一個(gè)文件。Clickhouse索引的大致思路是：首先選取部分列作為索引列，整個(gè)數(shù)據(jù)文件的數(shù)據(jù)按照索引列有序，這點(diǎn)類(lèi)似MySQL的聯(lián)合索引；其次將排序后的數(shù)據(jù)每隔8192行選取出一行，記錄其索引值和序號(hào)，注意這里的序號(hào)不是行號(hào)，序號(hào)是從零開(kāi)始并遞增的，Clickhouse中序號(hào)被稱作Mark’s number；然后對(duì)于每個(gè)列（索引列和非索引列），記錄Mark’s number與對(duì)應(yīng)行的數(shù)據(jù)的offset。

下圖中以一個(gè)二維表（date, city, action）為例介紹了整個(gè)索引結(jié)構(gòu)，其中（date,city）是索引列。

那么查詢?nèi)绾问褂盟饕?#xff1f;以以下查詢?yōu)槔?#xff1a;

select count(distinct action) where date=toDate(2020-01-01) and city=’bj’

二分查找primary.idx并找到對(duì)應(yīng)的mark's number集合（即數(shù)據(jù)block集合）

在上一步驟中的 block中，在date和city列中查找對(duì)應(yīng)的值的行號(hào)集合，并做交集，確認(rèn)行號(hào)集合

將行號(hào)轉(zhuǎn)換為mark's number 和 offset in block（注意這里的offset以行為單位而不是byte）

在action列中，根據(jù)mark's number和.mark文件確認(rèn)數(shù)據(jù)block在bin文件中的offset，然后根據(jù)offset in block定位到具體的列值。

后續(xù)計(jì)算

該實(shí)例中包含了對(duì)于列的正反兩個(gè)方向的查找過(guò)程。反向：查找date=toDate(2020-01-01) and city=’bj’數(shù)據(jù)的行號(hào)；正向：根據(jù)行號(hào)查找action列的值。對(duì)于反向查找，只有在查找條件匹配最左前綴的時(shí)候，才能剪枝掉大量數(shù)據(jù)，其它時(shí)候并不高效。

Clickhouse小結(jié)：MergeTree Family作為主要引擎系列，其中包含適合明細(xì)數(shù)據(jù)的場(chǎng)景和適合聚合數(shù)據(jù)的場(chǎng)景；Clickhouse的索引有點(diǎn)類(lèi)似MySQL的聯(lián)合索引，當(dāng)查詢前綴元組能命中的時(shí)候效率最高，可是一旦不能命中，幾乎會(huì)掃描整個(gè)表，效率波動(dòng)巨大；所以建表需要業(yè)務(wù)專(zhuān)家，這一點(diǎn)跟kylin類(lèi)似。

06

小結(jié)

• Kylin、Druid只適合聚合場(chǎng)景，ClickHouse適合明細(xì)和聚合場(chǎng)景

• 聚合場(chǎng)景，查詢效率排序：Kylin > Druid > ClickHouse

• Kylin、ClickHouse建表都需要業(yè)務(wù)專(zhuān)家參與

• Kylin、ClickHouse查詢效率都可能產(chǎn)生巨大差異

• ClickHouse在向量化方面做得的最好，Druid少量算子支持向量化、Kylin目前還不支持向量化計(jì)算。

想知道更多？掃描下面的二維碼關(guān)注我

后臺(tái)回復(fù)"技術(shù)"，加入技術(shù)群

當(dāng)當(dāng)實(shí)付滿200-40優(yōu)惠碼：NBHH2P

【精彩推薦】

• 超清晰的DNS入門(mén)指南

• 深入理解Java Stream流水線

• 如何用ELK搭建TB級(jí)的日志系統(tǒng)

• 深度好文：Linux系統(tǒng)內(nèi)存知識(shí)

• 日志系統(tǒng)新貴Loki，確實(shí)比笨重的ELK輕

• 日志采集系統(tǒng)都用到哪些技術(shù)？

• 面試官：為什么HashMap的加載因子是0.75？

• 原創(chuàng)|OpenAPI標(biāo)準(zhǔn)規(guī)范

• Linux系統(tǒng)內(nèi)存知識(shí)總結(jié)

• 深度好文|奈飛微服務(wù)架構(gòu)解析

• 耗時(shí)3天，上億數(shù)據(jù)如何做到秒級(jí)查詢

點(diǎn)個(gè)贊+在看，少個(gè) bug?????

總結(jié)

以上是生活随笔為你收集整理的Kylin、Druid、ClickHouse核心技术对比的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。