作者: 康凱森
日期: 2018-04-17
分類:?OLAP
2.3 Kylin Cuboid VS Doris RollUp
Apache Kylin 和 Apache Doris 都是優(yōu)秀的開源OLAP系統(tǒng)览濒，本文將全方位地對比Kylin和Doris呆盖。Kylin和Doris分別是MOALP和ROLAP的代表拖云，對比這兩個系統(tǒng)的目的不是為了說明哪個系統(tǒng)更好，只是為了明確每個系統(tǒng)的設計思想和架構原理应又，讓大家可以根據(jù)自己的實際需求去選擇合適的系統(tǒng)宙项，也可以進一步去思考我們?nèi)绾稳ピO計出更優(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)架構
1.1 What is Kylin
Kylin的核心思想是預計算改基，利用空間換時間來加速查詢模式固定的OLAP查詢。
Kylin的理論基礎是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可插拔的架構圖, 在架構設計上，Kylin的數(shù)據(jù)源了罪，構建Cube的計算引擎锭环，存儲引擎都是可插拔的。Kylin的核心就是這套可插拔架構泊藕，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?(存儲格式汽久，編碼和壓縮) 的技術。
Doris的系統(tǒng)架構如下踊餐，Doris主要分為FE和BE兩個組件景醇，F(xiàn)E主要負責查詢的編譯，分發(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ù)。 不過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ī)則如下：
選擇包含所有查詢列的RollUp表
按照過濾和排序的Column篩選最符合的RollUp表
按照Join的Column篩選最符合的RollUp表
行數(shù)最小的
列數(shù)最小的
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盛嘿。
關于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é)構例衍。該結(jié)構是一種有序的數(shù)據(jù)結(jié)構，可以按照指定的列有序存儲已卸。在這種數(shù)據(jù)結(jié)構上佛玄，以排序列作為條件進行查找，會非常的高效累澡。而前綴索引梦抢，即在排序的基礎上，實現(xiàn)的一種根據(jù)給定前綴列永乌，快速查詢數(shù)據(jù)的索引方式惑申。前綴索引文件的格式如上圖所示，索引的Key是每個Rowblock第一行記錄的Sort Key的前36個字節(jié)翅雏，Value是Rowblock在Segment文件的偏移量圈驼。
有了前綴索引后，我們查詢特定Key的過程就是兩次二分查找：
先加載Index文件望几，二分查找Index文件獲取包含特定Key的Row blocks的Offest,然后從Sement Files中獲取指定的Rowblock绩脆；
在Rowblocks中二分查找特定的Key
4 數(shù)據(jù)導入
Kylin數(shù)據(jù)導入：?
如上圖，Kylin數(shù)據(jù)導入主要分為建Hive大寬表(這一步會處理Join)橄抹；維度列構建字典靴迫；逐層構建Cuboid；Cuboid轉(zhuǎn)為HFile楼誓；Load HFile To HBase; 元數(shù)據(jù)更新這幾步玉锌。
其中Redistribute大寬表這一步的作用是為了將整個表的數(shù)據(jù)搞均勻，避免后續(xù)的步驟中有數(shù)據(jù)傾斜疟羹，Kylin有配置可以跳過這一步主守。
其中Extract Distinct Columns這一步的作用是獲取需要構建字典的維度列的Distinct值禀倔。假如一個ID維度列有1，2参淫，1救湖，2，2涎才，1鞋既，1，2這8行耍铜，那么經(jīng)過這一步后ID列的值就只有1邑闺，2兩行，做這一步是為了下一步對維度列構建字典時更快速业扒。
其他幾個步驟都比較好理解检吆，我就不再贅述。更詳細的信息可以參考?Apache Kylin Cube 構建原理
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架構籍滴。 Doris的FE 主要負責SQL的解析，語法分析榴啸，查詢計劃的生成和優(yōu)化孽惰。查詢計劃的生成主要分為兩步：
生成單節(jié)點查詢計劃 （上圖左下角）
將單節(jié)點的查詢計劃分布式化，生成PlanFragment（上圖右半部分）
第一步主要包括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 精確去重和全局字典權威指南
Doris的精確去重：
Doris的精確去重是現(xiàn)場精確去重借跪，Doris計算精確去重時會拆分為兩步：
按照所有的group by 字段和精確去重的字段進行聚合
按照所有的group by 字段進行聚合
SELECT a, COUNT(DISTINCT b, c), MIN(d), COUNT(*) FROM T GROUP BY a* -1st phase grouping exprs: a, b, c* -1st phase agg exprs: MIN(d), COUNT(*)* -2nd phase grouping exprs: a* -2nd phase agg exprs: COUNT(*), MIN(), SUM()
下面是個簡單的等價轉(zhuǎn)換的例子：
select count(distinct lo_ordtotalprice)fromssb_sf20.v2_lineorder;select count(*)from(select count(*)fromssb_sf20.v2_lineorder group by lo_ordtotalprice) a;
Doris現(xiàn)場精確去重計算性能和去重列的基數(shù)、去重指標個數(shù)酌壕、過濾后的數(shù)據(jù)大小成負相關掏愁；
7 元數(shù)據(jù)
Kylin的元數(shù)據(jù)?：
Kylin的元數(shù)據(jù)是利用HBase存儲的，可以很好地橫向擴展卵牍。Kylin每個具體的元數(shù)據(jù)都是一個Json文件果港，HBase的Rowkey是文件名，Value是Json文件的內(nèi)容糊昙。Kylin的元數(shù)據(jù)表設置了IN_MEMORY => 'true' 屬性, 元數(shù)據(jù)表會常駐HBase RegionServer的內(nèi)存辛掠，所以元數(shù)據(jù)的查詢性能很好，一般在幾ms到幾十ms释牺。
Kylin元數(shù)據(jù)利用HBase存儲的一個問題是萝衩，在Kylin可插拔架構下，即使我們實現(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ū)別不大。
關于Doris元數(shù)據(jù)的具體原理大家可以參考Doris官方文檔Doris 元數(shù)據(jù)設計文檔
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：
In-Memory Metadata。 Doris的元數(shù)據(jù)就在內(nèi)存中保檐，元數(shù)據(jù)訪問速度很快耕蝉。
聚合模型可以在數(shù)據(jù)導入時進行預聚合。
和Kylin一樣夜只，也支持預計算的RollUp Table垒在。
MPP的查詢引擎。
向量化執(zhí)行扔亥。相比Kylin中Calcite的代碼生成场躯，向量化執(zhí)行在處理高并發(fā)的低延遲查詢時性能更好，Kylin的代碼生成本身可能會花費幾十ms甚至幾百ms旅挤。
列式存儲 + 前綴索引推盛。
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相關的一堆概念缘滥；需要教會用戶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 功能
注： 關于Kylin的明細查詢速侈，Kylin本身只有聚合模型，但是也可以通過將所有列作為維度列迫卢，只構建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)架構和原理的客觀描述纳账，主觀判斷較少。最近在調(diào)研了Doirs捺疼，ClickHouse疏虫，TiDB之后，也一直在思考OLAP系統(tǒng)的發(fā)展趨勢是怎樣的帅涂，下一代更優(yōu)秀的OLAP系統(tǒng)架構應該是怎樣的议薪，一個系統(tǒng)是否可以同時很好的支持OLTP和OLAP，這些問題想清楚后我會再寫篇文章描述下媳友，當然斯议，大家有好的想法，也歡迎直接Comment醇锚。
15 參考資料
3 Apache kylin 2.0: from classic olap to real-time data warehouse?在Kylin高性能部分引用了第4頁PPT的截圖
4 百度MPP數(shù)據(jù)倉庫Palo開源架構解讀與應用?在Doris查詢部分引用了第31頁PPT的截圖
原文地址：https://blog.bcmeng.com/post/apache-kylin-vs-baidu-palo.html
