Kylin/Druid/ClickHouse核心技術對比
導讀:Kylin、Druid、ClickHouse是目前主流的OLAP引擎,本文嘗試從資料模型和索引結構兩個角度,分析這幾個引擎的核心技術,並做簡單對比。在閱讀本文之前希望能對Kylin、Druid、ClickHouse有所理解。
01
Kylin資料模型
Kylin的資料模型本質上是將二維表(Hive表)轉換為Cube,然後將Cube儲存到HBase表中,也就是兩次轉換。
第一次轉換,其實就是傳統資料庫的Cube化,Cube由CuboId組成,下圖每個節點都被稱為一個CuboId,CuboId表示固定列的資料資料集合,比如“ AB” 兩個維度組成的CuboId的資料集合等價於以下SQL的資料集合:
select A, B, sum(M), sum(N) from table group by A, B
第二次轉換,是將Cube中的資料儲存到HBase中,轉換的時候CuboId和維度資訊序列化到rowkey,度量列組成列簇。在轉換的時候資料進行了預聚合。下圖展示了Cube資料在HBase中的儲存方式。
02
Kylin索引結構
因為Kylin將資料儲存到HBase中,所以kylin的資料索引就是HBase的索引。HBase的索引是簡化版本的B+樹,相比於B+樹,HFile沒有對資料檔案的更新操作。
HFile的索引是按照rowkey排序的聚簇索引,索引樹一般為二層或者三層,索引節點比MySQL的B+樹大,預設是64KB。資料查詢的時候通過樹形結構定位到節點,節點內部資料是按照rowkey有序的,可以通過二分查詢快速定位到目標。
Kylin小結:適用於聚合查詢場景;因為資料預聚合,Kylin可以說是最快的查詢引擎(group-by查詢這樣的複雜查詢,可能只需要掃描1條資料);kylin查詢效率取決於是否命中CuboId,查詢波動較大;HBase索引有點類似MySQL中的聯合索引,維度在rowkey中的排序和查詢維度組合對查詢效率影響巨大;所以Kylin建表需要業務專家參與。
03
Druid資料模型
Druid資料模型比較簡單,它將資料進行預聚合,只不過預聚合的方式與Kylin不同,kylin是Cube化,Druid的預聚合方式是將所有維度進行Group-by,可以參考下圖:
04
Druid索引結構
Druid索引結構使用自定義的資料結構,整體上它是一種列式儲存結構,每個列獨立一個邏輯檔案(實際上是一個物理檔案,在物理檔案內部標記了每個列的start和offset)。對於維度列設計了索引,它的索引以Bitmap為核心。下圖為“city”列的索引結構:
首先將該列所有的唯一值排序,並生成一個字典,然後對於每個唯一值生成一個Bitmap,Bitmap的長度為資料集的總行數,每個bit代表對應的行的資料是否是該值。Bitmap的下標位置和行號是一一對應的,所以可以定位到度量列,Bitmap可以說是反向索引。同時資料結構中保留了字典編碼後的所有列值,其為正向的索引。
那麼查詢如何使用索引呢?以以下查詢為例:
select site, sum(pv) from xx where date=2020-01-01 and city='bj' group by site
- city列中二分查詢dictionary並找到'bj'對應的bitmap
-
遍歷city列,對於每一個字典值對應的bitmap與'bj'的bitmap做與操作
-
每個相與後的bitmap即為city='bj'查詢條件下的site的一個group的pv的索引
-
通過索引在pv列中查詢到相應的行,並做agg
-
後續計算
Druid小結:Druid適用於聚合查詢場景但是不適合有超高基維度的場景;儲存全維度group-by後的資料,相當於只儲存了KYLIN Cube的 Base-CuboID;每個維度都有建立索引,所以每個查詢都很快,並且沒有類似KYLIN的巨大的查詢效率波動。
05
ClickHouse索引結構(只討論MergeTree引擎)
因為Clickhouse資料模型就是普通二維表,這裡不做介紹,只討論索引結構。整體上Clickhouse的索引也是列式索引結構,每個列一個檔案。Clickhouse索引的大致思路是:首先選取部分列作為索引列,整個資料檔案的資料按照索引列有序,這點類似MySQL的聯合索引;其次將排序後的資料每隔8192行選取出一行,記錄其索引值和序號,注意這裡的序號不是行號,序號是從零開始並遞增的,Clickhouse中序號被稱作Mark’s number;然後對於每個列(索引列和非索引列),記錄Mark’s number與對應行的資料的offset。
下圖中以一個二維表(date, city, action)為例介紹了整個索引結構,其中(date,city)是索引列。
那麼查詢如何使用索引呢?以以下查詢為例:
select count(distinct action) where date=toDate(2020-01-01) and city=’bj’
- 二分查詢primary.idx並找到對應的mark's number集合(即資料block集合)
-
在上一步驟中的 block中,在date和city列中查詢對應的值的行號集合,並做交集,確認行號集合
-
將行號轉換為mark's number 和 offset in block(注意這裡的offset以行為單位而不是byte)
-
在action列中,根據mark's number和.mark檔案確認資料block在bin檔案中的offset,然後根據offset in block定位到具體的列值。
- 後續計算
該例項中包含了對於列的正反兩個方向的查詢過程。反向:查詢date=toDate(2020-01-01) and city=’bj’資料的行號;正向:根據行號查詢action列的值。對於反向查詢,只有在查詢條件匹配最左字首的時候,才能剪枝掉大量資料,其它時候並不高效。
Clickhouse小結:MergeTree Family作為主要引擎系列,其中包含適合明細資料的場景和適合聚合資料的場景;Clickhouse的索引有點類似MySQL的聯合索引,當查詢字首元組能命中的時候效率最高,可是一旦不能命中,幾乎會掃描整個表,效率波動巨大;所以建表需要業務專家,這一點跟kylin類似。
06
小結
-
Kylin、Druid只適合聚合場景,ClickHouse適合明細和聚合場景
-
聚合場景,查詢效率排序:Kylin > Druid > ClickHouse
-
Kylin、ClickHouse建表都需要業務專家參與
-
Kylin、ClickHouse查詢效率都可能產生巨大差異
-
ClickHouse在向量化方面做得的最好,Druid少量運算元支援向量化、Kylin目前還不支援向量化計算。