Apache Kylin VS Apache Doris
作者: 康凱森
日期: 2018-04-17
分類:?OLAP
- 1 系統(tǒng)架構(gòu)
- 1.1 What is Kylin
- 1.2 What is Doris
- 2 數(shù)據(jù)模型
- 2.1 Kylin的聚合模型
- 2.2 Doris的聚合模型
- 2.3 Kylin Cuboid VS Doris RollUp
- 2.4 Doris的明細模型
- 3 存儲引擎
- 4 數(shù)據(jù)導入
- 5 查詢
- 6 精確去重
- 7 元數(shù)據(jù)
- 8 高性能
- 9 高可用
- 10 可維護性
- 10.1 部署
- 10.2 運維
- 10.3 客服
- 11 易用性
- 11.1 查詢接入
- 11.2 學習成本
- 11.3 Schema Change
- 12 功能
- 13 社區(qū)和生態(tài)
- 14 總結(jié)
- 15 參考資料
Apache Kylin 和 Apache Doris 都是優(yōu)秀的開源OLAP系統(tǒng)，本文將全方位地對比Kylin和Doris。Kylin和Doris分別是MOALP和ROLAP的代表，對比這兩個系統(tǒng)的目的不是為了說明哪個系統(tǒng)更好，只是為了明確每個系統(tǒng)的設(shè)計思想和架構(gòu)原理，讓大家可以根據(jù)自己的實際需求去選擇合適的系統(tǒng)，也可以進一步去思考我們?nèi)绾稳ピO(shè)計出更優(yōu)秀的OLAP系統(tǒng)。
本文對Apache Kylin的理解基于近兩年來在生產(chǎn)環(huán)境大規(guī)模地使用，運維和深度開發(fā)，我已向Kylin社區(qū)貢獻了98次Commit，包含多項新功能和深度優(yōu)化。
本文對Apache Doris的理解基于官方文檔和論文的閱讀，代碼的粗淺閱讀和較深入地測試。
注： 本文的對比基于Apache Kylin 2.0.0 和Apache Doris 0.9.0。
1 系統(tǒng)架構(gòu)
1.1 What is Kylin
Kylin的核心思想是預計算，利用空間換時間來加速查詢模式固定的OLAP查詢。
Kylin的理論基礎(chǔ)是Cube理論，每一種維度組合稱之為Cuboid，所有Cuboid的集合是Cube。 其中由所有維度組成的Cuboid稱為Base Cuboid，圖中(A,B,C,D)即為Base Cuboid，所有的Cuboid都可以基于Base Cuboid計算出來。 在查詢時，Kylin會自動選擇滿足條件的最“小”Cuboid，比如下面的SQL就會對應Cuboid（A,B）:
select xx from table where A=xx group by B
下圖是Kylin數(shù)據(jù)流轉(zhuǎn)的示意圖，Kylin自身的組件只有兩個：JobServer和QueryServer。 Kylin的JobServer主要負責將數(shù)據(jù)源（Hive,Kafka）的數(shù)據(jù)通過計算引擎（MapReduce，Spark）生成Cube存儲到存儲引擎（HBase）中；QueryServer主要負責SQL的解析，邏輯計劃的生成和優(yōu)化，向HBase的多個Region發(fā)起請求，并對多個Region的結(jié)果進行匯總，生成最終的結(jié)果集。?
下圖是Kylin可插拔的架構(gòu)圖, 在架構(gòu)設(shè)計上，Kylin的數(shù)據(jù)源，構(gòu)建Cube的計算引擎，存儲引擎都是可插拔的。Kylin的核心就是這套可插拔架構(gòu)，Cube數(shù)據(jù)模型和Cuboid的算法。
1.2 What is Doris
Doris是一個MPP的OLAP系統(tǒng)，主要整合了Google Mesa（數(shù)據(jù)模型），Apache Impala（MPP Query Engine)和Apache ORCFile?(存儲格式，編碼和壓縮) 的技術(shù)。
Doris的系統(tǒng)架構(gòu)如下，Doris主要分為FE和BE兩個組件，FE主要負責查詢的編譯，分發(fā)和元數(shù)據(jù)管理（基于內(nèi)存，類似HDFS NN）；BE主要負責查詢的執(zhí)行和存儲系統(tǒng)。
2 數(shù)據(jù)模型
2.1 Kylin的聚合模型
Kylin將表中的列分為維度列和指標列。在數(shù)據(jù)導入和查詢時相同維度列中的指標會按照對應的聚合函數(shù)(Sum, Count, Min, Max, 精確去重，近似去重，百分位數(shù)，TOPN)進行聚合。
在存儲到HBase時，Cuboid+維度 會作為HBase的Rowkey, 指標會作為HBase的Value，一般所有指標會在HBase的一個列族，每列對應一個指標，但對于較大的去重指標會單獨拆分到第2個列族。
2.2 Doris的聚合模型
Doris的聚合模型借鑒自Mesa，但本質(zhì)上和Kylin的聚合模型一樣，只不過Doris中將維度稱作Key，指標稱作Value。
Doris中比較獨特的聚合函數(shù)是Replace函數(shù)，這個聚合函數(shù)能夠保證相同Keys的記錄只保留最新的Value，可以借助這個Replace函數(shù)來實現(xiàn)點更新。一般OLAP系統(tǒng)的數(shù)據(jù)都是只支持Append的，但是像電商中交易的退款，廣告點擊中的無效點擊處理，都需要去更新之前寫入的單條數(shù)據(jù)，在Kylin這種沒有Relpace函數(shù)的系統(tǒng)中我們必須把包含對應更新記錄的整個Segment數(shù)據(jù)全部重刷，但是有了Relpace函數(shù)，我們只需要再追加1條新的記錄即可。 但是Doris中的Repalce函數(shù)有個缺點：無法支持預聚合，就是說只要你的SQL中包含了Repalce函數(shù)，即使有其他可以已經(jīng)預聚合的Sum，Max指標，也必須現(xiàn)場計算。
為什么Doirs可以支持點更新呢？
Kylin中的Segment是不可變的，也就是說HFile一旦生成，就不再發(fā)生任何變化。但是Doirs中的Segment文件和HBase一樣，是可以進行Compaction的，具體可以參考Google Mesa 論文解讀中的Mesa數(shù)據(jù)版本化管理
Doris的聚合模型相比Kylin有個缺點：就是一個Column只能有一個預聚合函數(shù)，無法設(shè)置多個預聚合函數(shù)。 不過Doris可以現(xiàn)場計算出其他的聚合函數(shù)。 Apache Doris的開發(fā)者Review時提到，針對這個問題，Doris還有一種解法：由于Doris支持多表導入的原子更新，所以1個Column需要多個聚合函數(shù)時，可以在Doris中建多張表，同一份數(shù)據(jù)導入時，Doris可以同時原子更新多張Doris表，缺點是多張Doris表的查詢路由需要應用層來完成。
Doris中和Kylin的Cuboid等價的概念是RollUp表，Cuboid和RollUp表都可以認為是一種Materialized Views或者Index。Doris的RollUp表和Kylin的Cuboid一樣，在查詢時不需要顯示指定，系統(tǒng)內(nèi)部會根據(jù)查詢條件進行路由。 如下圖所示：
Doris中RollUp表的路由規(guī)則如下：
2.3 Kylin Cuboid VS Doris RollUp
2.4 Doris的明細模型
由于Doris的聚合模型存在下面的缺陷，Doris引入了明細模型。
- 必須區(qū)分維度列和指標列
- 維度列很多時，Sort的成本很高
- Count成本很高，需要讀取所有維度列（可以參考Kylin的解決方法進行優(yōu)化）
Doris的明細模型不會有任何預聚合，不區(qū)分維度列和指標列，但是在建表時需要指定Sort Columns，數(shù)據(jù)導入時會根據(jù)Sort Columns進行排序，查詢時根據(jù)Sort Column過濾會比較高效。
如下圖所示，Sort Columns是Year和City。
這里需要注意一點，Doris中一張表只能有一種數(shù)據(jù)模型，即要么是聚合模型，要么是明細模型，而且Roll Up表的數(shù)據(jù)模型必須和Base表一致，也就是說明細模型的Base 表不能有聚合模型的Roll Up表。
3 存儲引擎
Kylin存儲引擎HBase：
如上圖所示，在Kylin中1個Cube可以按照時間拆分為多個Segment,Segment是Kylin中數(shù)據(jù)導入和刷新的最小單位。Kylin中1個Segment對應HBase中一張Table。 HBase中的Table會按照Range分區(qū)拆分為多個Region,每個Region會按照大小拆分為多個HFile。
關(guān)于HFile的原理網(wǎng)上講述的文章已經(jīng)很多了，我這里簡單介紹下。首先HFile整體上可以分為元信息，Blcoks，Index3部分，Blcoks和Index都可以分為Data和Meta兩部分。Block是數(shù)據(jù)讀取的最小單位，Block有多個Key-Value組成，一個Key-Value代表HBase中的一行記錄，Key-Value由Kylin-Len，Value-Len，Key-Bytes,Value-Bytes 4部分組成。更詳細的信息大家可以參考下圖(下圖來源于互聯(lián)網(wǎng)，具體出處不詳）：
Doris存儲引擎：
如上圖所示，Doris的Table支持二級分區(qū)，可以先按照日期列進行一級分區(qū)，再按照指定列Hash分桶。具體來說，1個Table可以按照日期列分為多個Partition， 每個Partition可以包含多個Tablet，Tablet是數(shù)據(jù)移動、復制等操作的最小物理存儲單元，各個Tablet之間的數(shù)據(jù)沒有交集，并且在物理上獨立存儲。Partition 可以視為邏輯上最小的管理單元，數(shù)據(jù)的導入與刪除，僅能針對一個 Partition進行。1個Table中Tablet的數(shù)量= Partition num * Bucket num。Tablet會按照一定大小（256M）拆分為多個Segment文件，Segment是列存的，但是會按行（1024）拆分為多個Rowblock。
下面我們來看下Doris Segment文件的具體格式，Doris文件格式主要參考了Apache ORC。如上圖所示，Doris文件主要由Meta和Data兩部分組成，Meta主要包括文件本身的Header，Segment Meta，Column Meta，和每個Column 數(shù)據(jù)流的元數(shù)據(jù)，每部分的具體內(nèi)容大家看圖即可，比較詳細。 Data部分主要包含每一列的Index和Data，這里的Index指每一列的Min,Max值和數(shù)據(jù)流Stream的Position；Data就是每一列具體的數(shù)據(jù)內(nèi)容，Data根據(jù)不同的數(shù)據(jù)類型會用不同的Stream來存儲，Present Stream代表每個Value是否是Null，Data Stream代表二進制數(shù)據(jù)流，Length Stream代表非定長數(shù)據(jù)類型的長度。 下圖是String使用字典編碼和直接存儲的Stream例子。
下面我們來看下Doris的前綴索引：
本質(zhì)上，Doris 的數(shù)據(jù)存儲是類似 SSTable（Sorted String Table）的數(shù)據(jù)結(jié)構(gòu)。該結(jié)構(gòu)是一種有序的數(shù)據(jù)結(jié)構(gòu)，可以按照指定的列有序存儲。在這種數(shù)據(jù)結(jié)構(gòu)上，以排序列作為條件進行查找，會非常的高效。而前綴索引，即在排序的基礎(chǔ)上，實現(xiàn)的一種根據(jù)給定前綴列，快速查詢數(shù)據(jù)的索引方式。前綴索引文件的格式如上圖所示，索引的Key是每個Rowblock第一行記錄的Sort Key的前36個字節(jié)，Value是Rowblock在Segment文件的偏移量。
有了前綴索引后，我們查詢特定Key的過程就是兩次二分查找：
4 數(shù)據(jù)導入
Kylin數(shù)據(jù)導入：?
如上圖，Kylin數(shù)據(jù)導入主要分為建Hive大寬表(這一步會處理Join)；維度列構(gòu)建字典；逐層構(gòu)建Cuboid；Cuboid轉(zhuǎn)為HFile；Load HFile To HBase; 元數(shù)據(jù)更新這幾步。
其中Redistribute大寬表這一步的作用是為了將整個表的數(shù)據(jù)搞均勻，避免后續(xù)的步驟中有數(shù)據(jù)傾斜，Kylin有配置可以跳過這一步。
其中Extract Distinct Columns這一步的作用是獲取需要構(gòu)建字典的維度列的Distinct值。假如一個ID維度列有1，2，1，2，2，1，1，2這8行，那么經(jīng)過這一步后ID列的值就只有1，2兩行，做這一步是為了下一步對維度列構(gòu)建字典時更快速。
其他幾個步驟都比較好理解，我就不再贅述。更詳細的信息可以參考?Apache Kylin Cube 構(gòu)建原理
Doris數(shù)據(jù)導入：?
Doris 數(shù)據(jù)導入的兩個核心階段是ETL和LOADING, ETL階段主要完成以下工作：
- 數(shù)據(jù)類型和格式的校驗
- 根據(jù)Teblet拆分數(shù)據(jù)
- 按照Key列進行排序, 對Value進行聚合
LOADING階段主要完成以下工作：
- 每個Tablet對應的BE拉取排序好的數(shù)據(jù)
- 進行數(shù)據(jù)的格式轉(zhuǎn)換，生成索引
LOADING完成后會進行元數(shù)據(jù)的更新。
5 查詢
Kylin查詢：
如上圖，整個Kylin的查詢過程比較簡單，是個Scatter-Gather的模型。圖中圓形框的內(nèi)容發(fā)生在Kylin QueryServer端，方形框的內(nèi)容發(fā)生在HBase端。Kylin QueryServer端收到SQL后，會先進行SQL的解析，然后生成和優(yōu)化Plan，再根據(jù)Plan生成和編譯代碼，之后會根據(jù)Plan生成HBase的Scan請求，如果可能，HBase端除了Scan之外，還會進行過濾和聚合（基于HBase的Coprocessor實現(xiàn)），Kylin會將HBase端返回的結(jié)果進行合并，交給Calcite之前生成好的代碼進行計算。
Doris查詢：
Doris的查詢引擎使用的是Impala，是MPP架構(gòu)。 Doris的FE 主要負責SQL的解析，語法分析，查詢計劃的生成和優(yōu)化。查詢計劃的生成主要分為兩步：
第一步主要包括Plan Tree的生成，謂詞下推， Table Partitions pruning，Column projections，Cost-based優(yōu)化等；第二步 將單節(jié)點的查詢計劃分布式化，分布式化的目標是最小化數(shù)據(jù)移動和最大化本地Scan，分布式化的方法是增加ExchangeNode，執(zhí)行計劃樹會以ExchangeNode為邊界拆分為PlanFragment，1個PlanFragment封裝了在一臺機器上對同一數(shù)據(jù)集的部分PlanTree。如上圖所示：各個Fragment的數(shù)據(jù)流轉(zhuǎn)和最終的結(jié)果發(fā)送依賴：DataSink。
當FE生成好查詢計劃樹后，BE對應的各種Plan Node（Scan, Join, Union, Aggregation, Sort等）執(zhí)行自己負責的操作即可。
6 精確去重
Kylin的精確去重：
Kylin的精確去重是基于全局字典和RoaringBitmap實現(xiàn)的基于預計算的精確去重。具體可以參考?Apache Kylin 精確去重和全局字典權(quán)威指南
Doris的精確去重：
Doris的精確去重是現(xiàn)場精確去重，Doris計算精確去重時會拆分為兩步：
下面是個簡單的等價轉(zhuǎn)換的例子：
select count(distinct lo_ordtotalprice) from ssb_sf20.v2_lineorder;select count(*) from (select count(*) from ssb_sf20.v2_lineorder group by lo_ordtotalprice) a;Doris現(xiàn)場精確去重計算性能和去重列的基數(shù)、去重指標個數(shù)、過濾后的數(shù)據(jù)大小成負相關(guān)；
7 元數(shù)據(jù)
Kylin的元數(shù)據(jù)?：
Kylin的元數(shù)據(jù)是利用HBase存儲的，可以很好地橫向擴展。Kylin每個具體的元數(shù)據(jù)都是一個Json文件，HBase的Rowkey是文件名，Value是Json文件的內(nèi)容。Kylin的元數(shù)據(jù)表設(shè)置了IN_MEMORY => 'true' 屬性, 元數(shù)據(jù)表會常駐HBase RegionServer的內(nèi)存，所以元數(shù)據(jù)的查詢性能很好，一般在幾ms到幾十ms。
Kylin元數(shù)據(jù)利用HBase存儲的一個問題是，在Kylin可插拔架構(gòu)下，即使我們實現(xiàn)了另一種存儲引擎，我們也必須部署HBase來存儲元數(shù)據(jù)，所以Kylin要真正做到存儲引擎的可插拔，就必須實現(xiàn)一個獨立的元數(shù)據(jù)存儲。
Doris的元數(shù)據(jù)：
Doris的元數(shù)據(jù)是基于內(nèi)存的，這樣做的好處是性能很好且不需要額外的系統(tǒng)依賴。 缺點是單機的內(nèi)存是有限的，擴展能力受限，但是根據(jù)Doris開發(fā)者的反饋，由于Doris本身的元數(shù)據(jù)不多，所以元數(shù)據(jù)本身占用的內(nèi)存不是很多，目前用大內(nèi)存的物理機，應該可以支撐數(shù)百臺機器的OLAP集群。 此外，OLAP系統(tǒng)和HDFS這種分布式存儲系統(tǒng)不一樣，我們部署多個集群的運維成本和1個集群區(qū)別不大。
關(guān)于Doris元數(shù)據(jù)的具體原理大家可以參考Doris官方文檔Doris 元數(shù)據(jù)設(shè)計文檔
8 高性能
Why Kylin Query Fast：
Kylin查詢快的核心原因就是預計算，如圖(圖片出處?Apache kylin 2.0: from classic olap to real-time data warehouse)，Kylin現(xiàn)場查詢時不需要Join，也幾乎不需要聚合，主要就是Scan + Filter。
Why Doris Query Fast：
9 高可用
Kylin高可用：
Kylin JobServer的高可用： Kylin的JobServer是無狀態(tài)的，一臺JobServer掛掉后，其他JobServer會很快接管正在Running的Job。JobServer的高可用是基于Zookeeper實現(xiàn)的，具體可以參考Apache Kylin Job 生成和調(diào)度詳解。
Kylin QueryServer的高可用：Kylin的QueryServer也是無狀態(tài)的，其高可用一般通過Nginx這類的負載均衡組件來實現(xiàn)。
Kylin Hadoop依賴的高可用： 要單純保證Kylin自身組件的高可用并不困難，但是要保證Kylin整體數(shù)據(jù)導入和查詢的高可用是十分困難的，因為必須同時保證HBase，Hive，Hive Metastore，Spark，Mapreduce，HDFS，Yarn，Zookeeper，Kerberos這些服務的高可用。
Doris高可用：
Doris FE的高可用： Doris FE的高可用主要基于BerkeleyDB java version實現(xiàn)，BDB-JE實現(xiàn)了類Paxos一致性協(xié)議算法。
Doris BE的高可用：?Doris會保證每個Tablet的多個副本分配到不同的BE上，所以一個BE down掉，不會影響查詢的可用性。
10 可維護性
10.1 部署
Kylin部署：如果完全從零開始，你就需要部署1個Hadoop集群和HBase集群。 即使公司已經(jīng)有了比較完整的Hadoop生態(tài)，在部署Kylin前，你也必須先部署Hadoop客戶端，HBase客戶端，Hive客戶端，Spark客戶端。
Doris部署： 直接部署FE和BE組件即可。
10.2 運維
Kylin運維：?運維Kylin對Admin有較高的要求，首先必須了解HBase，Hive，MapReduce，Spark，HDFS，Yarn的原理；其次對MapReduce Job和Spark Job的問題排查和調(diào)優(yōu)經(jīng)驗要豐富；然后必須掌握對Cube復雜調(diào)優(yōu)的方法；最后出現(xiàn)問題時排查的鏈路較長，復雜度較高。
Doris運維：?Doris只需要理解和掌握系統(tǒng)本身即可。
10.3 客服
Kylin 客服：?需要向用戶講清Hadoop相關(guān)的一堆概念；需要教會用戶Kylin Web的使用；需要教會用戶如何進行Cube優(yōu)化（沒有統(tǒng)一，簡潔的優(yōu)化原則）；需要教會用戶怎么查看MR和Spark日志；需要教會用戶怎么查詢；
Doris 客服：?需要教會用戶聚合模型，明細模型，前綴索引，RollUp表這些概念。
11 易用性
11.1 查詢接入
Kylin查詢接入：Kylin支持Htpp,JDBC,ODBC 3種查詢方式。
Doris查詢接入：?Doris支持Mysql協(xié)議，現(xiàn)有的大量Mysql工具都可以直接使用，用戶的學習和遷移成本較低。
11.2 學習成本
Kylin學習成本：用戶要用好Kylin，需要理解以下概念：
- Cuboid
- 聚集組
- 強制維度
- 聯(lián)合維度
- 層次維度
- 衍生維度
- Extend Column
- HBase RowKey 順序
此外，前面提到過，用戶還需要學會怎么看Mapreduce Job和Spark Job日志。
Doris學習成本：用戶需要理解聚合模型，明細模型，前綴索引，RollUp表這些概念。
11.3 Schema Change
Schema在線變更是一個十分重要的feature，因為在實際業(yè)務中，Schema的變更會十分頻繁。
Kylin Schema Change： Kylin中用戶對Cube Schema的任何改變，都需要在Staging環(huán)境重刷所有數(shù)據(jù)，然后切到Prod環(huán)境。整個過程周期很長，資源浪費比較嚴重。
Doris Schema Change：Doris支持Online Schema Change。
所謂的Schema在線變更就是指Scheme的變更不會影響數(shù)據(jù)的正常導入和查詢，Doris中的Schema在線變更有3種：
- direct schema change：就是重刷全量數(shù)據(jù)，成本最高，和kylin的做法類似。當修改列的類型，稀疏索引中加一列時需要按照這種方法進行。
- sorted schema change: 改變了列的排序方式，需對數(shù)據(jù)進行重新排序。例如刪除排序列中的一列, 字段重排序。
- linked schema change: 無需轉(zhuǎn)換數(shù)據(jù)，直接完成。對于歷史數(shù)據(jù)不會重刷，新攝入的數(shù)據(jù)都按照新的Schema處理，對于舊數(shù)據(jù)，新加列的值直接用對應數(shù)據(jù)類型的默認值填充。例如加列操作。Druid也支持這種做法。
12 功能
注： 關(guān)于Kylin的明細查詢，Kylin本身只有聚合模型，但是也可以通過將所有列作為維度列，只構(gòu)建Base Cuboid來實現(xiàn)明細查詢， 缺點是效率比較低下。
注： 雖然Doirs理論上可以同時支持高并發(fā)，低延遲的OLAP查詢和高吞吐的Adhoc查詢，但顯然這兩類查詢會相互影響。所以Baidu在實際應用中也是用兩個集群分別滿足OLAP查詢和Adhoc查詢需求。
13 社區(qū)和生態(tài)
Doris社區(qū)剛剛起步，目前核心用戶只有Baidu；Kylin的社區(qū)和生態(tài)已經(jīng)比較成熟，Kylin是第一個完全由中國開發(fā)者貢獻的Apache頂級開源項目，目前已經(jīng)在多家大型公司的生產(chǎn)環(huán)境中使用。
14 總結(jié)
本文從多方面對比了Apache Kylin和Apache Doris，有理解錯誤的地方歡迎指正。本文更多的是對兩個系統(tǒng)架構(gòu)和原理的客觀描述，主觀判斷較少。最近在調(diào)研了Doirs，ClickHouse，TiDB之后，也一直在思考OLAP系統(tǒng)的發(fā)展趨勢是怎樣的，下一代更優(yōu)秀的OLAP系統(tǒng)架構(gòu)應該是怎樣的，一個系統(tǒng)是否可以同時很好的支持OLTP和OLAP，這些問題想清楚后我會再寫篇文章描述下，當然，大家有好的想法，也歡迎直接Comment。
15 參考資料
1 Doris文檔和源碼
2 Kylin源碼
3 Apache kylin 2.0: from classic olap to real-time data warehouse?在Kylin高性能部分引用了第4頁PPT的截圖
4 百度MPP數(shù)據(jù)倉庫Palo開源架構(gòu)解讀與應用?在Doris查詢部分引用了第31頁PPT的截圖
總結(jié)
以上是生活随笔為你收集整理的Apache Kylin VS Apache Doris的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Apache Doris : 一个开源
- 下一篇： 眯缝眼怎么改善