2.3 Kylin Cuboid VS Palo RollUp
Apache Kylin和Baidu Palo都是優(yōu)秀的開源OLAP系統(tǒng)渡蜻，本文將全方位地對比Kylin和Palo传藏。Kylin和Palo分別是MOALP和ROLAP的代表做修，對比這兩個系統(tǒng)的目的不是為了說明哪個系統(tǒng)更好宾濒，只是為了明確每個系統(tǒng)的設(shè)計(jì)思想和架構(gòu)原理榄棵，讓大家可以根據(jù)自己的實(shí)際需求去選擇合適的系統(tǒng)杠茬，也可以進(jìn)一步去思考我們?nèi)绾稳ピO(shè)計(jì)出更優(yōu)秀的OLAP系統(tǒng)。
本文對Apache Kylin的理解基于近兩年來在生產(chǎn)環(huán)境大規(guī)模地使用，運(yùn)維和深度開發(fā)边臼，我已向Kylin社區(qū)貢獻(xiàn)了98次Commit葵擎，包含多項(xiàng)新功能和深度優(yōu)化几缭。
本文對Baidu Palo的理解基于官方文檔和論文的閱讀沃呢，代碼的粗淺閱讀和較深入地測試年栓。
注： 本文的對比基于Apache Kylin 2.0.0 和Baidu Palo 0.8.0。
Kylin的核心思想是預(yù)計(jì)算薄霜，利用空間換時間來加速查詢模式固定的OLAP查詢某抓。
Kylin的理論基礎(chǔ)是Cube理論，每一種維度組合稱之為Cuboid惰瓜，所有Cuboid的集合是Cube否副。 其中由所有維度組成的Cuboid稱為Base Cuboid，圖中(A,B,C,D)即為Base Cuboid崎坊，所有的Cuboid都可以基于Base Cuboid計(jì)算出來备禀。 在查詢時，Kylin會自動選擇滿足條件的最“小”Cuboid流强，比如下面的SQL就會對應(yīng)Cuboid（A,B）:
select xx from table where A=xx group by B
下圖是Kylin數(shù)據(jù)流轉(zhuǎn)的示意圖痹届，Kylin自身的組件只有兩個：JobServer和QueryServer。 Kylin的JobServer主要負(fù)責(zé)將數(shù)據(jù)源（Hive,Kafka）的數(shù)據(jù)通過計(jì)算引擎（MapReduce打月，Spark）生成Cube存儲到存儲引擎（HBase）中；QueryServer主要負(fù)責(zé)SQL的解析蚕捉，邏輯計(jì)劃的生成和優(yōu)化奏篙，向HBase的多個Region發(fā)起請求，并對多個Region的結(jié)果進(jìn)行匯總，生成最終的結(jié)果集秘通。
下圖是Kylin可插拔的架構(gòu)圖, 在架構(gòu)設(shè)計(jì)上为严，Kylin的數(shù)據(jù)源，構(gòu)建Cube的計(jì)算引擎肺稀，存儲引擎都是可插拔的第股。Kylin的核心就是這套可插拔架構(gòu)，Cube數(shù)據(jù)模型和Cuboid的算法话原。
Palo是一個基于MPP的OLAP系統(tǒng)夕吻，主要整合了Google Mesa（數(shù)據(jù)模型），Apache Impala（MPP Query Engine)和Apache ORCFile(存儲格式繁仁，編碼和壓縮) 的技術(shù)涉馅。
Palo的系統(tǒng)架構(gòu)如下，Palo主要分為FE和BE兩個組件黄虱，F(xiàn)E主要負(fù)責(zé)查詢的編譯稚矿，分發(fā)和元數(shù)據(jù)管理（基于內(nèi)存，類似HDFS NN）捻浦；BE主要負(fù)責(zé)查詢的執(zhí)行和存儲系統(tǒng)晤揣。
Kylin將表中的列分為維度列和指標(biāo)列。在數(shù)據(jù)導(dǎo)入和查詢時相同維度列中的指標(biāo)會按照對應(yīng)的聚合函數(shù)(Sum, Count, Min, Max, 精確去重朱灿，近似去重碉渡，百分位數(shù)，TOPN)進(jìn)行聚合母剥。
在存儲到HBase時滞诺，Cuboid+維度 會作為HBase的Rowkey, 指標(biāo)會作為HBase的Value，一般所有指標(biāo)會在HBase的一個列族环疼，每列對應(yīng)一個指標(biāo)习霹，但對于較大的去重指標(biāo)會單獨(dú)拆分到第2個列族。
Palo的聚合模型借鑒自Mesa炫隶，但本質(zhì)上和Kylin的聚合模型一樣淋叶，只不過Palo中將維度稱作Key，指標(biāo)稱作Value伪阶。
Palo中比較獨(dú)特的聚合函數(shù)是Replace函數(shù)煞檩，這個聚合函數(shù)能夠保證相同Keys的記錄只保留最新的Value，可以借助這個Replace函數(shù)來實(shí)現(xiàn)點(diǎn)更新栅贴。一般OLAP系統(tǒng)的數(shù)據(jù)都是只支持Append的斟湃，但是像電商中交易的退款，廣告點(diǎn)擊中的無效點(diǎn)擊處理檐薯，都需要去更新之前寫入的單條數(shù)據(jù)凝赛，在Kylin這種沒有Relpace函數(shù)的系統(tǒng)中我們必須把包含對應(yīng)更新記錄的整個Segment數(shù)據(jù)全部重刷注暗，但是有了Relpace函數(shù)，我們只需要再追加1條新的記錄即可墓猎。 但是Palo中的Repalce函數(shù)有個缺點(diǎn)：無法支持預(yù)聚合捆昏，就是說只要你的SQL中包含了Repalce函數(shù)，即使有其他可以已經(jīng)預(yù)聚合的Sum毙沾，Max指標(biāo)骗卜，也必須現(xiàn)場計(jì)算。
為什么Palo可以支持點(diǎn)更新呢左胞？
Kylin中的Segment是不可變的寇仓，也就是說HFile一旦生成，就不再發(fā)生任何變化罩句。但是Palo中的Segment文件和HBase一樣焚刺，是可以進(jìn)行Compaction的，具體可以參考Google Mesa 論文解讀中的Mesa數(shù)據(jù)版本化管理
Palo的聚合模型相比Kylin有個缺點(diǎn)：就是一個Column只能有一個預(yù)聚合函數(shù)门烂，無法設(shè)置多個預(yù)聚合函數(shù)乳愉。 不過Palo可以現(xiàn)場計(jì)算其他的聚合函數(shù)。 Baidu Palo的開發(fā)者Review時提到屯远，針對這個問題蔓姚，Palo還有一種解法：由于Palo支持多表導(dǎo)入的原子更新，所以1個Column需要多個聚合函數(shù)時慨丐，可以在Palo中建多張表坡脐，同一份數(shù)據(jù)導(dǎo)入時，Palo可以同時原子更新多張Palo表房揭，缺點(diǎn)是多張Palo表的查詢路由需要應(yīng)用層來完成备闲。
Palo中和Kylin的Cuboid等價(jià)的概念是RollUp表，Cuboid和RollUp表都可以認(rèn)為是一種Materialized Views或者Index捅暴。 Palo的RollUp表和Kylin的Cuboid一樣恬砂，在查詢時不需要顯示指定，系統(tǒng)內(nèi)部會根據(jù)查詢條件進(jìn)行路由蓬痒。 如下圖所示：
Palo中RollUp表的路由規(guī)則如下：
選擇包含所有查詢列的RollUp表
按照過濾和排序的Column篩選最符合的RollUp表
按照J(rèn)oin的Column篩選最符合的RollUp表
行數(shù)最小的
列數(shù)最小的
2.3 Kylin Cuboid VS Palo RollUp
由于Palo的聚合模型存在下面的缺陷泻骤，Palo引入了明細(xì)模型。
必須區(qū)分維度列和指標(biāo)列
維度列很多時梧奢，Sort的成本很高
Count成本很高狱掂，需要讀取所有維度列（可以參考Kylin的解決方法進(jìn)行優(yōu)化）
Palo的明細(xì)模型不會有任何聚合，不區(qū)分維度列和指標(biāo)列亲轨，但是在建表時需要指定Sort Columns趋惨，數(shù)據(jù)導(dǎo)入時會根據(jù)Sort Columns進(jìn)行排序，查詢時根據(jù)Sort Column過濾會比較高效瓶埋。
如下圖所示希柿，Sort Columns是Year和City诊沪。
這里需要注意一點(diǎn)养筒，Palo中一張表只能有一種數(shù)據(jù)模型曾撤，即要么是聚合模型，要么是明細(xì)模型晕粪，而且Roll Up表的數(shù)據(jù)模型必須和Base表一致挤悉，也就是說明細(xì)模型的Base 表不能有聚合模型的Roll Up表。
Kylin存儲引擎HBase：
如上圖所示巫湘，在Kylin中1個Cube可以按照時間拆分為多個Segment,Segment是Kylin中數(shù)據(jù)導(dǎo)入和刷新的最小單位装悲。Kylin中1個Segment對應(yīng)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部分組成捣炬。更詳細(xì)的信息大家可以參考下圖(下圖來源于互聯(lián)網(wǎng)熊昌，具體出處不詳）：
Palo存儲引擎：
如上圖所示，Palo的Table支持二級分區(qū)湿酸，可以先按照日期列進(jìn)行一級分區(qū)婿屹，再按照指定列Hash分桶。具體來說稿械，1個Table可以按照日期列分為多個Partition选泻， 每個Partition可以包含多個Tablet，Tablet是數(shù)據(jù)移動美莫、復(fù)制等操作的最小物理存儲單元页眯，各個Tablet之間的數(shù)據(jù)沒有交集，并且在物理上獨(dú)立存儲厢呵。Partition 可以視為邏輯上最小的管理單元窝撵，數(shù)據(jù)的導(dǎo)入與刪除，僅能針對一個 Partition進(jìn)行襟铭。1個Table中Tablet的數(shù)量= Partition num * Bucket num碌奉。Tablet會按照一定大卸淘（256M）拆分為多個Segment文件，Segment是列存的赐劣，但是會按行（1024）拆分為多個Rowblock嫉拐。
下面我們來看下Palo Segment文件的具體格式，Palo文件格式主要參考了Apache ORC魁兼。如上圖所示婉徘，Palo文件主要由Meta和Data兩部分組成，Meta主要包括文件本身的Header咐汞，Segment Meta盖呼，Column Meta，和每個Column 數(shù)據(jù)流的元數(shù)據(jù)化撕，每部分的具體內(nèi)容大家看圖即可几晤，比較詳細(xì)。 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代表二進(jìn)制數(shù)據(jù)流，Length Stream代表非定長數(shù)據(jù)類型的長度惨撇。 下圖是String使用字典編碼和直接存儲的Stream例子伊脓。
下面我們來看下Palo的前綴索引：
本質(zhì)上，Palo 的數(shù)據(jù)存儲是類似 SSTable（Sorted String Table）的數(shù)據(jù)結(jié)構(gòu)魁衙。該結(jié)構(gòu)是一種有序的數(shù)據(jù)結(jié)構(gòu)报腔，可以按照指定的列有序存儲。在這種數(shù)據(jù)結(jié)構(gòu)上剖淀，以排序列作為條件進(jìn)行查找纯蛾，會非常的高效。而前綴索引纵隔，即在排序的基礎(chǔ)上翻诉，實(shí)現(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
Kylin數(shù)據(jù)導(dǎo)入：
如上圖个少，Kylin數(shù)據(jù)導(dǎo)入主要分為建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)建字典時更快速乌询。
其他幾個步驟都比較好理解榜贴，我就不再贅述。更詳細(xì)的信息可以參考Apache Kylin Cube 構(gòu)建原理
Palo數(shù)據(jù)導(dǎo)入：
Palo 數(shù)據(jù)導(dǎo)入的兩個核心階段是ETL和LOADING, ETL階段主要完成以下工作：
數(shù)據(jù)類型和格式的校驗(yàn)
根據(jù)Teblet拆分?jǐn)?shù)據(jù)
按照Key列進(jìn)行排序, 對Value進(jìn)行聚合
LOADING階段主要完成以下工作：
每個Tablet對應(yīng)的BE拉取排序好的數(shù)據(jù)
進(jìn)行數(shù)據(jù)的格式轉(zhuǎn)換妹田，生成索引
LOADING完成后會進(jìn)行元數(shù)據(jù)的更新唬党。
Kylin查詢：
如上圖，整個Kylin的查詢過程比較簡單鬼佣，是個Scatter-Gather的模型驶拱。圖中圓形框的內(nèi)容發(fā)生在Kylin QueryServer端，方形框的內(nèi)容發(fā)生在HBase端晶衷。Kylin QueryServer端收到SQL后蓝纲，會先進(jìn)行SQL的解析，然后生成和優(yōu)化Plan晌纫，再根據(jù)Plan生成和編譯代碼税迷，之后會根據(jù)Plan生成HBase的Scan請求，如果可能缸匪，HBase端除了Scan之外翁狐，還會進(jìn)行過濾和聚合（基于HBase的Coprocessor實(shí)現(xiàn)），Kylin會將HBase端返回的結(jié)果進(jìn)行合并凌蔬，交給Calcite之前生成好的代碼進(jìn)行計(jì)算露懒。
Palo查詢：
Palo的查詢引擎使用的是Impala闯冷，是MPP架構(gòu)。 Palo的FE 主要負(fù)責(zé)SQL的解析懈词，語法分析蛇耀，查詢計(jì)劃的生成和優(yōu)化。查詢計(jì)劃的生成主要分為兩步：
生成單節(jié)點(diǎn)查詢計(jì)劃 （上圖左下角）
將單節(jié)點(diǎn)的查詢計(jì)劃分布式化坎弯，生成PlanFragment（上圖右半部分）
第一步主要包括Plan Tree的生成纺涤，謂詞下推， Table Partitions pruning抠忘，Column projections撩炊，Cost-based優(yōu)化等；第二步 將單節(jié)點(diǎn)的查詢計(jì)劃分布式化崎脉，分布式化的目標(biāo)是最小化數(shù)據(jù)移動和最大化本地Scan拧咳，分布式化的方法是增加ExchangeNode，執(zhí)行計(jì)劃樹會以ExchangeNode為邊界拆分為PlanFragment囚灼，1個PlanFragment封裝了在一臺機(jī)器上對同一數(shù)據(jù)集的部分PlanTree骆膝。如上圖所示：各個Fragment的數(shù)據(jù)流轉(zhuǎn)和最終的結(jié)果發(fā)送依賴：DataSink。
當(dāng)FE生成好查詢計(jì)劃樹后灶体，BE對應(yīng)的各種Plan Node（Scan, Join, Union, Aggregation, Sort等）執(zhí)行自己負(fù)責(zé)的操作即可阅签。
Kylin的精確去重：
Kylin的精確去重是基于全局字典和RoaringBitmap實(shí)現(xiàn)的基于預(yù)計(jì)算的精確去重。具體可以參考Apache Kylin 精確去重和全局字典權(quán)威指南
Palo的精確去重：
Palo的精確去重是現(xiàn)場精確去重蝎抽，Palo計(jì)算精確去重時會拆分為兩步：
按照所有的group by 字段和精確去重的字段進(jìn)行聚合
按照所有的group by 字段進(jìn)行聚合
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()
下面是個簡單的等價(jià)轉(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;
Palo現(xiàn)場精確去重計(jì)算性能和去重列的基數(shù)政钟、去重指標(biāo)個數(shù)、過濾后的數(shù)據(jù)大小成負(fù)相關(guān)织中；
Kylin的元數(shù)據(jù)：
Kylin的元數(shù)據(jù)是利用HBase存儲的锥涕，可以很好地橫向擴(kuò)展。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)下灶挟，即使我們實(shí)現(xiàn)了另一種存儲引擎誉察，我們也必須部署HBase來存儲元數(shù)據(jù)高诺，所以Kylin要真正做到存儲引擎的可插拔摘悴，就必須實(shí)現(xiàn)一個獨(dú)立的元數(shù)據(jù)存儲峭梳。
Palo的元數(shù)據(jù)：
Palo的元數(shù)據(jù)是基于內(nèi)存的，這樣做的好處是性能很好且不需要額外的系統(tǒng)依賴。 缺點(diǎn)是單機(jī)的內(nèi)存是有限的葱椭，擴(kuò)展能力受限捂寿，但是根據(jù)Palo開發(fā)者的反饋，由于Palo本身的元數(shù)據(jù)不多孵运，所以元數(shù)據(jù)本身占用的內(nèi)存不是很多秦陋，目前用大內(nèi)存的物理機(jī)，應(yīng)該可以支撐數(shù)百臺機(jī)器的OLAP集群治笨。 此外驳概，OLAP系統(tǒng)和HDFS這種分布式存儲系統(tǒng)不一樣，我們部署多個集群的運(yùn)維成本和1個集群區(qū)別不大旷赖。
關(guān)于Palo元數(shù)據(jù)的具體原理大家可以參考Palo官方文檔Palo 元數(shù)據(jù)設(shè)計(jì)文檔
Why Kylin Query Fast：
Kylin查詢快的核心原因就是預(yù)計(jì)算顺又，如圖(圖片出處Apache kylin 2.0: from classic olap to real-time data warehouse)，Kylin現(xiàn)場查詢時不需要Join杠愧，也幾乎不需要聚合待榔，主要就是Scan + Filter。
Why Palo Query Fast：
In-Memory Metadata流济。 Palo的元數(shù)據(jù)就在內(nèi)存中，元數(shù)據(jù)訪問速度很快腌闯。
聚合模型可以在數(shù)據(jù)導(dǎo)入時進(jìn)行預(yù)聚合绳瘟。
和Kylin一樣，也支持預(yù)計(jì)算的RollUp Table姿骏。
MPP的查詢引擎糖声。
向量化執(zhí)行。相比Kylin中Calcite的代碼生成分瘦，向量化執(zhí)行在處理高并發(fā)的低延遲查詢時性能更好蘸泻，Kylin的代碼生成本身可能會花費(fèi)幾十ms甚至幾百ms。
列式存儲 + 前綴索引嘲玫。
Kylin高可用：
Kylin JobServer的高可用： Kylin的JobServer是無狀態(tài)的悦施，一臺JobServer掛掉后，其他JobServer會很快接管正在Running的Job去团。JobServer的高可用是基于Zookeeper實(shí)現(xiàn)的抡诞，具體可以參考Apache Kylin Job 生成和調(diào)度詳解。
Kylin QueryServer的高可用：Kylin的QueryServer也是無狀態(tài)的土陪，其高可用一般通過Nginx這類的負(fù)載均衡組件來實(shí)現(xiàn)昼汗。
Kylin Hadoop依賴的高可用： 要單純保證Kylin自身組件的高可用并不困難，但是要保證Kylin整體數(shù)據(jù)導(dǎo)入和查詢的高可用是十分困難的鬼雀，因?yàn)楸仨毻瑫r保證HBase顷窒，Hive，Hive Metastore源哩，Spark鞋吉，Mapreduce出刷，HDFS，Yarn坯辩，Zookeeper馁龟，Kerberos這些服務(wù)的高可用。
Palo高可用：
Palo FE的高可用： Palo FE的高可用主要基于BerkeleyDB java version實(shí)現(xiàn)漆魔，BDB-JE實(shí)現(xiàn)了類Paxos一致性協(xié)議算法坷檩。
Palo BE的高可用：Palo會保證每個Tablet的多個副本分配到不同的BE上，所以一個BE down掉改抡，不會影響查詢的可用性矢炼。
Kylin部署：如果完全從零開始，你就需要部署1個Hadoop集群和HBase集群阿纤。 即使公司已經(jīng)有了比較完整的Hadoop生態(tài)句灌，在部署Kylin前，你也必須先部署Hadoop客戶端欠拾，HBase客戶端胰锌，Hive客戶端，Spark客戶端藐窄。
Palo部署： 直接啟動FE和BE资昧。
Kylin運(yùn)維：運(yùn)維Kylin對Admin有較高的要求，首先必須了解HBase荆忍，Hive格带，MapReduce，Spark刹枉，HDFS叽唱，Yarn的原理；其次對MapReduce Job和Spark Job的問題排查和調(diào)優(yōu)經(jīng)驗(yàn)要豐富微宝；然后必須掌握對Cube復(fù)雜調(diào)優(yōu)的方法棺亭；最后出現(xiàn)問題時排查的鏈路較長，復(fù)雜度較高芥吟。
Palo運(yùn)維：Palo只需要理解和掌握系統(tǒng)本身即可侦铜。
Kylin 客服：需要向用戶講清Hadoop相關(guān)的一堆概念；需要教會用戶Kylin Web的使用钟鸵；需要教會用戶如何進(jìn)行Cube優(yōu)化（沒有統(tǒng)一钉稍，簡潔的優(yōu)化原則）；需要教會用戶怎么查看MR和Spark日志棺耍；需要教會用戶怎么查詢贡未；
Palo 客服：需要教會用戶聚合模型，明細(xì)模型，前綴索引俊卤，RollUp表這些概念嫩挤。
Kylin查詢接入：Kylin支持Htpp,JDBC,ODBC 3種查詢方式。
Palo查詢接入：Palo支持Mysql協(xié)議消恍，現(xiàn)有的大量Mysql工具都可以直接使用岂昭，用戶的學(xué)習(xí)和遷移成本較低。
Kylin學(xué)習(xí)成本：用戶要用好Kylin狠怨，需要理解以下概念：
Cuboid
聚集組
強(qiáng)制維度
聯(lián)合維度
層次維度
衍生維度
Extend Column
HBase RowKey 順序
此外约啊，前面提到過，用戶還需要學(xué)會怎么看Mapreduce Job和Spark Job日志佣赖。
Palo學(xué)習(xí)成本：用戶需要理解聚合模型恰矩，明細(xì)模型，前綴索引憎蛤，RollUp表這些概念外傅。
Schema在線變更是一個十分重要的feature，因?yàn)樵趯?shí)際業(yè)務(wù)中俩檬，Schema的變更會十分頻繁萎胰。
Kylin Schema Change： Kylin中用戶對Cube Schema的任何改變，都需要在Staging環(huán)境重刷所有數(shù)據(jù)豆胸，然后切到Prod環(huán)境奥洼。整個過程周期很長，資源浪費(fèi)比較嚴(yán)重晚胡。
Palo Schema Change：Palo支持Online Schema Change。
所謂的Schema在線變更就是指Scheme的變更不會影響數(shù)據(jù)的正常導(dǎo)入和查詢嚼沿，Palo中的Schema在線變更有3種：
direct schema change：就是重刷全量數(shù)據(jù)估盘，成本最高，和kylin的做法類似骡尽。當(dāng)修改列的類型遣妥，稀疏索引中加一列時需要按照這種方法進(jìn)行。
sorted schema change: 改變了列的排序方式攀细，需對數(shù)據(jù)進(jìn)行重新排序箫踩。例如刪除排序列中的一列, 字段重排序。
linked schema change: 無需轉(zhuǎn)換數(shù)據(jù)谭贪，直接完成境钟。對于歷史數(shù)據(jù)不會重刷，新攝入的數(shù)據(jù)都按照新的Schema處理俭识，對于舊數(shù)據(jù)慨削，新加列的值直接用對應(yīng)數(shù)據(jù)類型的默認(rèn)值填充。例如加列操作。Druid也支持這種做法缚态。
注： 關(guān)于Kylin的明細(xì)查詢磁椒，Kylin本身只有聚合模型，但是也可以通過將所有列作為維度列玫芦，只構(gòu)建Base Cuboid來實(shí)現(xiàn)明細(xì)查詢浆熔， 缺點(diǎn)是效率比較低下。
注： 雖然Palo可以同時支持高并發(fā)桥帆，低延遲的OLAP查詢和高吞吐的Adhoc查詢医增，但顯然這兩類查詢會相互影響。所以Baidu在實(shí)際應(yīng)用中也是用兩個集群分別滿足OLAP查詢和Adhoc查詢需求环葵。
Palo社區(qū)剛剛起步调窍，目前核心用戶只有Baidu；Kylin的社區(qū)和生態(tài)已經(jīng)比較成熟张遭，Kylin是第一個完全由中國開發(fā)者貢獻(xiàn)的Apache頂級開源項(xiàng)目邓萨，目前已經(jīng)在多家大型公司的生產(chǎn)環(huán)境中使用。
本文從多方面對比了Apache Kylin和Baidu Palo菊卷，有理解錯誤的地方歡迎指正缔恳。本文更多的是對兩個系統(tǒng)架構(gòu)和原理的客觀描述，主觀判斷較少洁闰。最近在調(diào)研了Palo歉甚，ClickHouse，TiDB之后扑眉，也一直在思考OLAP系統(tǒng)的發(fā)展趨勢是怎樣的纸泄，下一代更優(yōu)秀的OLAP系統(tǒng)架構(gòu)應(yīng)該是怎樣的，一個系統(tǒng)是否可以同時很好的支持OLTP和OLAP腰素，這些問題想清楚后我會再寫篇文章描述下聘裁，當(dāng)然，大家有好的想法弓千，也歡迎直接Comment衡便。
3 Apache kylin 2.0: from classic olap to real-time data warehouse在Kylin高性能部分引用了第4頁P(yáng)PT的截圖
4 百度MPP數(shù)據(jù)倉庫Palo開源架構(gòu)解讀與應(yīng)用在Palo查詢部分引用了第31頁P(yáng)PT的截圖
贊
作者: 康凱森
日期: 2018-04-17
分類:OLAP
2.3 Kylin Cuboid VS Palo RollUp
Apache Kylin和Baidu Palo都是優(yōu)秀的開源OLAP系統(tǒng)，本文將全方位地對比Kylin和Palo洋访。Kylin和Palo分別是MOALP和ROLAP的代表镣陕，對比這兩個系統(tǒng)的目的不是為了說明哪個系統(tǒng)更好，只是為了明確每個系統(tǒng)的設(shè)計(jì)思想和架構(gòu)原理姻政，讓大家可以根據(jù)自己的實(shí)際需求去選擇合適的系統(tǒng)呆抑，也可以進(jìn)一步去思考我們?nèi)绾稳ピO(shè)計(jì)出更優(yōu)秀的OLAP系統(tǒng)。
本文對Apache Kylin的理解基于近兩年來在生產(chǎn)環(huán)境大規(guī)模地使用扶歪，運(yùn)維和深度開發(fā)理肺，我已向Kylin社區(qū)貢獻(xiàn)了98次Commit摄闸，包含多項(xiàng)新功能和深度優(yōu)化。
本文對Baidu Palo的理解基于官方文檔和論文的閱讀妹萨，代碼的粗淺閱讀和較深入地測試年枕。
注： 本文的對比基于Apache Kylin 2.0.0 和Baidu Palo 0.8.0。
Kylin的核心思想是預(yù)計(jì)算乎完，利用空間換時間來加速查詢模式固定的OLAP查詢熏兄。
Kylin的理論基礎(chǔ)是Cube理論，每一種維度組合稱之為Cuboid树姨，所有Cuboid的集合是Cube摩桶。 其中由所有維度組成的Cuboid稱為Base Cuboid，圖中(A,B,C,D)即為Base Cuboid帽揪，所有的Cuboid都可以基于Base Cuboid計(jì)算出來硝清。 在查詢時，Kylin會自動選擇滿足條件的最“小”Cuboid转晰，比如下面的SQL就會對應(yīng)Cuboid（A,B）:
select xx from table where A=xx group by B
下圖是Kylin數(shù)據(jù)流轉(zhuǎn)的示意圖芦拿，Kylin自身的組件只有兩個：JobServer和QueryServer。 Kylin的JobServer主要負(fù)責(zé)將數(shù)據(jù)源（Hive,Kafka）的數(shù)據(jù)通過計(jì)算引擎（MapReduce查邢，Spark）生成Cube存儲到存儲引擎（HBase）中；QueryServer主要負(fù)責(zé)SQL的解析缓苛，邏輯計(jì)劃的生成和優(yōu)化邓深，向HBase的多個Region發(fā)起請求，并對多個Region的結(jié)果進(jìn)行匯總钢属，生成最終的結(jié)果集。
下圖是Kylin可插拔的架構(gòu)圖, 在架構(gòu)設(shè)計(jì)上门躯，Kylin的數(shù)據(jù)源讶凉，構(gòu)建Cube的計(jì)算引擎懂讯，存儲引擎都是可插拔的褐望。Kylin的核心就是這套可插拔架構(gòu)瘫里，Cube數(shù)據(jù)模型和Cuboid的算法谨读。
Palo是一個基于MPP的OLAP系統(tǒng)铐尚，主要整合了Google Mesa（數(shù)據(jù)模型）宣增，Apache Impala（MPP Query Engine)和Apache ORCFile(存儲格式，編碼和壓縮) 的技術(shù)誉简。
Palo的系統(tǒng)架構(gòu)如下闷串，Palo主要分為FE和BE兩個組件，F(xiàn)E主要負(fù)責(zé)查詢的編譯肋拔，分發(fā)和元數(shù)據(jù)管理（基于內(nèi)存凉蜂，類似HDFS NN）窿吩；BE主要負(fù)責(zé)查詢的執(zhí)行和存儲系統(tǒng)纫雁。
Kylin將表中的列分為維度列和指標(biāo)列刽脖。在數(shù)據(jù)導(dǎo)入和查詢時相同維度列中的指標(biāo)會按照對應(yīng)的聚合函數(shù)(Sum, Count, Min, Max, 精確去重忌愚，近似去重翘地，百分位數(shù)衙耕，TOPN)進(jìn)行聚合橙喘。
在存儲到HBase時，Cuboid+維度 會作為HBase的Rowkey, 指標(biāo)會作為HBase的Value和簸，一般所有指標(biāo)會在HBase的一個列族锁保，每列對應(yīng)一個指標(biāo)爽柒，但對于較大的去重指標(biāo)會單獨(dú)拆分到第2個列族。
Palo的聚合模型借鑒自Mesa心墅，但本質(zhì)上和Kylin的聚合模型一樣，只不過Palo中將維度稱作Key严肪，指標(biāo)稱作Value。
Palo中比較獨(dú)特的聚合函數(shù)是Replace函數(shù)，這個聚合函數(shù)能夠保證相同Keys的記錄只保留最新的Value悍手，可以借助這個Replace函數(shù)來實(shí)現(xiàn)點(diǎn)更新。一般OLAP系統(tǒng)的數(shù)據(jù)都是只支持Append的滞欠，但是像電商中交易的退款筛璧，廣告點(diǎn)擊中的無效點(diǎn)擊處理，都需要去更新之前寫入的單條數(shù)據(jù)朗儒，在Kylin這種沒有Relpace函數(shù)的系統(tǒng)中我們必須把包含對應(yīng)更新記錄的整個Segment數(shù)據(jù)全部重刷采蚀，但是有了Relpace函數(shù)，我們只需要再追加1條新的記錄即可妆够。 但是Palo中的Repalce函數(shù)有個缺點(diǎn)：無法支持預(yù)聚合，就是說只要你的SQL中包含了Repalce函數(shù)鸵荠，即使有其他可以已經(jīng)預(yù)聚合的Sum蛹找，Max指標(biāo)乍楚，也必須現(xiàn)場計(jì)算徒溪。
為什么Palo可以支持點(diǎn)更新呢？
Kylin中的Segment是不可變的缺虐，也就是說HFile一旦生成高氮，就不再發(fā)生任何變化。但是Palo中的Segment文件和HBase一樣罪裹，是可以進(jìn)行Compaction的，具體可以參考Google Mesa 論文解讀中的Mesa數(shù)據(jù)版本化管理
Palo的聚合模型相比Kylin有個缺點(diǎn)：就是一個Column只能有一個預(yù)聚合函數(shù)峡继，無法設(shè)置多個預(yù)聚合函數(shù)。 不過Palo可以現(xiàn)場計(jì)算其他的聚合函數(shù)舶吗。 Baidu Palo的開發(fā)者Review時提到誓琼，針對這個問題呵扛，Palo還有一種解法：由于Palo支持多表導(dǎo)入的原子更新，所以1個Column需要多個聚合函數(shù)時，可以在Palo中建多張表帖鸦，同一份數(shù)據(jù)導(dǎo)入時，Palo可以同時原子更新多張Palo表攻锰，缺點(diǎn)是多張Palo表的查詢路由需要應(yīng)用層來完成。
Palo中和Kylin的Cuboid等價(jià)的概念是RollUp表妒蛇，Cuboid和RollUp表都可以認(rèn)為是一種Materialized Views或者Index绣夺。 Palo的RollUp表和Kylin的Cuboid一樣，在查詢時不需要顯示指定物臂，系統(tǒng)內(nèi)部會根據(jù)查詢條件進(jìn)行路由。 如下圖所示：
Palo中RollUp表的路由規(guī)則如下：
選擇包含所有查詢列的RollUp表
按照過濾和排序的Column篩選最符合的RollUp表
按照J(rèn)oin的Column篩選最符合的RollUp表
行數(shù)最小的
列數(shù)最小的
2.3 Kylin Cuboid VS Palo RollUp
由于Palo的聚合模型存在下面的缺陷，Palo引入了明細(xì)模型留凭。
必須區(qū)分維度列和指標(biāo)列
維度列很多時蔼夜，Sort的成本很高
Count成本很高，需要讀取所有維度列（可以參考Kylin的解決方法進(jìn)行優(yōu)化）
Palo的明細(xì)模型不會有任何聚合匠题，不區(qū)分維度列和指標(biāo)列，但是在建表時需要指定Sort Columns钱磅，數(shù)據(jù)導(dǎo)入時會根據(jù)Sort Columns進(jìn)行排序，查詢時根據(jù)Sort Column過濾會比較高效禁舷。
如下圖所示，Sort Columns是Year和City洁桌。
這里需要注意一點(diǎn)，Palo中一張表只能有一種數(shù)據(jù)模型，即要么是聚合模型工坊，要么是明細(xì)模型罢吃，而且Roll Up表的數(shù)據(jù)模型必須和Base表一致尿招，也就是說明細(xì)模型的Base 表不能有聚合模型的Roll Up表。
Kylin存儲引擎HBase：
如上圖所示饮睬，在Kylin中1個Cube可以按照時間拆分為多個Segment,Segment是Kylin中數(shù)據(jù)導(dǎo)入和刷新的最小單位割去。Kylin中1個Segment對應(yīng)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部分組成晴圾。更詳細(xì)的信息大家可以參考下圖(下圖來源于互聯(lián)網(wǎng)，具體出處不詳）：
Palo存儲引擎：
如上圖所示，Palo的Table支持二級分區(qū)，可以先按照日期列進(jìn)行一級分區(qū)涤垫，再按照指定列Hash分桶。具體來說柄粹，1個Table可以按照日期列分為多個Partition， 每個Partition可以包含多個Tablet堪夭，Tablet是數(shù)據(jù)移動、復(fù)制等操作的最小物理存儲單元，各個Tablet之間的數(shù)據(jù)沒有交集雕旨，并且在物理上獨(dú)立存儲棒搜。Partition 可以視為邏輯上最小的管理單元可款，數(shù)據(jù)的導(dǎo)入與刪除，僅能針對一個 Partition進(jìn)行。1個Table中Tablet的數(shù)量= Partition num * Bucket num立镶。Tablet會按照一定大小（256M）拆分為多個Segment文件缭召，Segment是列存的萄凤，但是會按行（1024）拆分為多個Rowblock噩死。
下面我們來看下Palo Segment文件的具體格式已维，Palo文件格式主要參考了Apache ORC行嗤。如上圖所示，Palo文件主要由Meta和Data兩部分組成垛耳，Meta主要包括文件本身的Header栅屏，Segment Meta，Column Meta栈雳，和每個Column 數(shù)據(jù)流的元數(shù)據(jù)，每部分的具體內(nèi)容大家看圖即可缔莲，比較詳細(xì)哥纫。 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代表二進(jìn)制數(shù)據(jù)流擅憔，Length Stream代表非定長數(shù)據(jù)類型的長度。 下圖是String使用字典編碼和直接存儲的Stream例子檐晕。
下面我們來看下Palo的前綴索引：
本質(zhì)上暑诸，Palo 的數(shù)據(jù)存儲是類似 SSTable（Sorted String Table）的數(shù)據(jù)結(jié)構(gòu)。該結(jié)構(gòu)是一種有序的數(shù)據(jù)結(jié)構(gòu)辟灰，可以按照指定的列有序存儲屠列。在這種數(shù)據(jù)結(jié)構(gòu)上，以排序列作為條件進(jìn)行查找伞矩，會非常的高效笛洛。而前綴索引，即在排序的基礎(chǔ)上乃坤，實(shí)現(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
Kylin數(shù)據(jù)導(dǎo)入：
如上圖，Kylin數(shù)據(jù)導(dǎo)入主要分為建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)建字典時更快速。
其他幾個步驟都比較好理解吃粒，我就不再贅述潦俺。更詳細(xì)的信息可以參考Apache Kylin Cube 構(gòu)建原理
Palo數(shù)據(jù)導(dǎo)入：
Palo 數(shù)據(jù)導(dǎo)入的兩個核心階段是ETL和LOADING, ETL階段主要完成以下工作：
數(shù)據(jù)類型和格式的校驗(yàn)
根據(jù)Teblet拆分?jǐn)?shù)據(jù)
按照Key列進(jìn)行排序, 對Value進(jìn)行聚合
LOADING階段主要完成以下工作：
每個Tablet對應(yīng)的BE拉取排序好的數(shù)據(jù)
進(jìn)行數(shù)據(jù)的格式轉(zhuǎn)換，生成索引
LOADING完成后會進(jìn)行元數(shù)據(jù)的更新徐勃。
Kylin查詢：
如上圖事示，整個Kylin的查詢過程比較簡單，是個Scatter-Gather的模型僻肖。圖中圓形框的內(nèi)容發(fā)生在Kylin QueryServer端肖爵，方形框的內(nèi)容發(fā)生在HBase端。Kylin QueryServer端收到SQL后臀脏，會先進(jìn)行SQL的解析劝堪，然后生成和優(yōu)化Plan冀自，再根據(jù)Plan生成和編譯代碼，之后會根據(jù)Plan生成HBase的Scan請求秒啦，如果可能熬粗，HBase端除了Scan之外，還會進(jìn)行過濾和聚合（基于HBase的Coprocessor實(shí)現(xiàn)）余境，Kylin會將HBase端返回的結(jié)果進(jìn)行合并驻呐，交給Calcite之前生成好的代碼進(jìn)行計(jì)算。
Palo查詢：
Palo的查詢引擎使用的是Impala芳来，是MPP架構(gòu)鞠评。 Palo的FE 主要負(fù)責(zé)SQL的解析，語法分析逞敷，查詢計(jì)劃的生成和優(yōu)化绎狭。查詢計(jì)劃的生成主要分為兩步：
生成單節(jié)點(diǎn)查詢計(jì)劃 （上圖左下角）
將單節(jié)點(diǎn)的查詢計(jì)劃分布式化，生成PlanFragment（上圖右半部分）
第一步主要包括Plan Tree的生成侥涵，謂詞下推沼撕， Table Partitions pruning，Column projections芜飘，Cost-based優(yōu)化等务豺；第二步 將單節(jié)點(diǎn)的查詢計(jì)劃分布式化，分布式化的目標(biāo)是最小化數(shù)據(jù)移動和最大化本地Scan嗦明，分布式化的方法是增加ExchangeNode笼沥，執(zhí)行計(jì)劃樹會以ExchangeNode為邊界拆分為PlanFragment，1個PlanFragment封裝了在一臺機(jī)器上對同一數(shù)據(jù)集的部分PlanTree娶牌。如上圖所示：各個Fragment的數(shù)據(jù)流轉(zhuǎn)和最終的結(jié)果發(fā)送依賴：DataSink奔浅。
當(dāng)FE生成好查詢計(jì)劃樹后，BE對應(yīng)的各種Plan Node（Scan, Join, Union, Aggregation, Sort等）執(zhí)行自己負(fù)責(zé)的操作即可诗良。
Kylin的精確去重：
Kylin的精確去重是基于全局字典和RoaringBitmap實(shí)現(xiàn)的基于預(yù)計(jì)算的精確去重汹桦。具體可以參考Apache Kylin 精確去重和全局字典權(quán)威指南
Palo的精確去重：
Palo的精確去重是現(xiàn)場精確去重，Palo計(jì)算精確去重時會拆分為兩步：
按照所有的group by 字段和精確去重的字段進(jìn)行聚合
按照所有的group by 字段進(jìn)行聚合
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()
下面是個簡單的等價(jià)轉(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;
Palo現(xiàn)場精確去重計(jì)算性能和去重列的基數(shù)鉴裹、去重指標(biāo)個數(shù)舞骆、過濾后的數(shù)據(jù)大小成負(fù)相關(guān)；
Kylin的元數(shù)據(jù)：
Kylin的元數(shù)據(jù)是利用HBase存儲的径荔，可以很好地橫向擴(kuò)展督禽。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)下，即使我們實(shí)現(xiàn)了另一種存儲引擎，我們也必須部署HBase來存儲元數(shù)據(jù)偷溺，所以Kylin要真正做到存儲引擎的可插拔，就必須實(shí)現(xiàn)一個獨(dú)立的元數(shù)據(jù)存儲硫麻。
Palo的元數(shù)據(jù)：
Palo的元數(shù)據(jù)是基于內(nèi)存的券敌，這樣做的好處是性能很好且不需要額外的系統(tǒng)依賴卑雁。 缺點(diǎn)是單機(jī)的內(nèi)存是有限的，擴(kuò)展能力受限粹排，但是根據(jù)Palo開發(fā)者的反饋芒涡，由于Palo本身的元數(shù)據(jù)不多，所以元數(shù)據(jù)本身占用的內(nèi)存不是很多勾笆，目前用大內(nèi)存的物理機(jī)酸舍，應(yīng)該可以支撐數(shù)百臺機(jī)器的OLAP集群。 此外，OLAP系統(tǒng)和HDFS這種分布式存儲系統(tǒng)不一樣，我們部署多個集群的運(yùn)維成本和1個集群區(qū)別不大昆稿。
關(guān)于Palo元數(shù)據(jù)的具體原理大家可以參考Palo官方文檔Palo 元數(shù)據(jù)設(shè)計(jì)文檔
Why Kylin Query Fast：
Kylin查詢快的核心原因就是預(yù)計(jì)算，如圖(圖片出處Apache kylin 2.0: from classic olap to real-time data warehouse)，Kylin現(xiàn)場查詢時不需要Join，也幾乎不需要聚合茉继，主要就是Scan + Filter终吼。
Why Palo Query Fast：
In-Memory Metadata。 Palo的元數(shù)據(jù)就在內(nèi)存中幔戏，元數(shù)據(jù)訪問速度很快玛追。
聚合模型可以在數(shù)據(jù)導(dǎo)入時進(jìn)行預(yù)聚合。
和Kylin一樣闲延，也支持預(yù)計(jì)算的RollUp Table痊剖。
MPP的查詢引擎。
向量化執(zhí)行垒玲。相比Kylin中Calcite的代碼生成陆馁，向量化執(zhí)行在處理高并發(fā)的低延遲查詢時性能更好，Kylin的代碼生成本身可能會花費(fèi)幾十ms甚至幾百ms合愈。
列式存儲 + 前綴索引氮惯。
Kylin高可用：
Kylin JobServer的高可用： Kylin的JobServer是無狀態(tài)的，一臺JobServer掛掉后想暗，其他JobServer會很快接管正在Running的Job妇汗。JobServer的高可用是基于Zookeeper實(shí)現(xiàn)的，具體可以參考Apache Kylin Job 生成和調(diào)度詳解说莫。
Kylin QueryServer的高可用：Kylin的QueryServer也是無狀態(tài)的杨箭，其高可用一般通過Nginx這類的負(fù)載均衡組件來實(shí)現(xiàn)。
Kylin Hadoop依賴的高可用： 要單純保證Kylin自身組件的高可用并不困難储狭，但是要保證Kylin整體數(shù)據(jù)導(dǎo)入和查詢的高可用是十分困難的互婿，因?yàn)楸仨毻瑫r保證HBase，Hive辽狈，Hive Metastore慈参，Spark，Mapreduce刮萌，HDFS驮配，Yarn，Zookeeper着茸，Kerberos這些服務(wù)的高可用壮锻。
Palo高可用：
Palo FE的高可用： Palo FE的高可用主要基于BerkeleyDB java version實(shí)現(xiàn)，BDB-JE實(shí)現(xiàn)了類Paxos一致性協(xié)議算法涮阔。
Palo BE的高可用：Palo會保證每個Tablet的多個副本分配到不同的BE上猜绣，所以一個BE down掉，不會影響查詢的可用性敬特。
Kylin部署：如果完全從零開始掰邢，你就需要部署1個Hadoop集群和HBase集群牺陶。 即使公司已經(jīng)有了比較完整的Hadoop生態(tài)，在部署Kylin前辣之，你也必須先部署Hadoop客戶端义图，HBase客戶端，Hive客戶端召烂，Spark客戶端。
Palo部署： 直接啟動FE和BE娃承。
Kylin運(yùn)維：運(yùn)維Kylin對Admin有較高的要求奏夫，首先必須了解HBase，Hive历筝，MapReduce酗昼，Spark，HDFS梳猪，Yarn的原理麻削；其次對MapReduce Job和Spark Job的問題排查和調(diào)優(yōu)經(jīng)驗(yàn)要豐富；然后必須掌握對Cube復(fù)雜調(diào)優(yōu)的方法春弥；最后出現(xiàn)問題時排查的鏈路較長呛哟，復(fù)雜度較高。
Palo運(yùn)維：Palo只需要理解和掌握系統(tǒng)本身即可匿沛。
Kylin 客服：需要向用戶講清Hadoop相關(guān)的一堆概念扫责；需要教會用戶Kylin Web的使用；需要教會用戶如何進(jìn)行Cube優(yōu)化（沒有統(tǒng)一逃呼，簡潔的優(yōu)化原則）鳖孤；需要教會用戶怎么查看MR和Spark日志；需要教會用戶怎么查詢抡笼；
Palo 客服：需要教會用戶聚合模型苏揣，明細(xì)模型，前綴索引推姻，RollUp表這些概念平匈。
Kylin查詢接入：Kylin支持Htpp,JDBC,ODBC 3種查詢方式。
Palo查詢接入：Palo支持Mysql協(xié)議藏古，現(xiàn)有的大量Mysql工具都可以直接使用吐葱，用戶的學(xué)習(xí)和遷移成本較低。
Kylin學(xué)習(xí)成本：用戶要用好Kylin校翔，需要理解以下概念：
Cuboid
聚集組
強(qiáng)制維度
聯(lián)合維度
層次維度
衍生維度
Extend Column
HBase RowKey 順序
此外弟跑，前面提到過，用戶還需要學(xué)會怎么看Mapreduce Job和Spark Job日志防症。
Palo學(xué)習(xí)成本：用戶需要理解聚合模型孟辑，明細(xì)模型哎甲，前綴索引，RollUp表這些概念饲嗽。
Schema在線變更是一個十分重要的feature炭玫，因?yàn)樵趯?shí)際業(yè)務(wù)中，Schema的變更會十分頻繁貌虾。
Kylin Schema Change： Kylin中用戶對Cube Schema的任何改變吞加，都需要在Staging環(huán)境重刷所有數(shù)據(jù)，然后切到Prod環(huán)境尽狠。整個過程周期很長衔憨，資源浪費(fèi)比較嚴(yán)重。
Palo Schema Change：Palo支持Online Schema Change袄膏。
所謂的Schema在線變更就是指Scheme的變更不會影響數(shù)據(jù)的正常導(dǎo)入和查詢践图，Palo中的Schema在線變更有3種：
direct schema change：就是重刷全量數(shù)據(jù)，成本最高沉馆，和kylin的做法類似码党。當(dāng)修改列的類型，稀疏索引中加一列時需要按照這種方法進(jìn)行斥黑。
sorted schema change: 改變了列的排序方式揖盘，需對數(shù)據(jù)進(jìn)行重新排序。例如刪除排序列中的一列, 字段重排序锌奴。
linked schema change: 無需轉(zhuǎn)換數(shù)據(jù)扣讼，直接完成。對于歷史數(shù)據(jù)不會重刷缨叫，新攝入的數(shù)據(jù)都按照新的Schema處理椭符，對于舊數(shù)據(jù)，新加列的值直接用對應(yīng)數(shù)據(jù)類型的默認(rèn)值填充耻姥。例如加列操作销钝。Druid也支持這種做法。
注： 關(guān)于Kylin的明細(xì)查詢琐簇，Kylin本身只有聚合模型蒸健，但是也可以通過將所有列作為維度列，只構(gòu)建Base Cuboid來實(shí)現(xiàn)明細(xì)查詢婉商， 缺點(diǎn)是效率比較低下似忧。
注： 雖然Palo可以同時支持高并發(fā)，低延遲的OLAP查詢和高吞吐的Adhoc查詢丈秩，但顯然這兩類查詢會相互影響盯捌。所以Baidu在實(shí)際應(yīng)用中也是用兩個集群分別滿足OLAP查詢和Adhoc查詢需求。
Palo社區(qū)剛剛起步蘑秽，目前核心用戶只有Baidu饺著；Kylin的社區(qū)和生態(tài)已經(jīng)比較成熟箫攀，Kylin是第一個完全由中國開發(fā)者貢獻(xiàn)的Apache頂級開源項(xiàng)目，目前已經(jīng)在多家大型公司的生產(chǎn)環(huán)境中使用幼衰。
本文從多方面對比了Apache Kylin和Baidu Palo靴跛，有理解錯誤的地方歡迎指正。本文更多的是對兩個系統(tǒng)架構(gòu)和原理的客觀描述渡嚣，主觀判斷較少梢睛。最近在調(diào)研了Palo，ClickHouse识椰，TiDB之后绝葡，也一直在思考OLAP系統(tǒng)的發(fā)展趨勢是怎樣的，下一代更優(yōu)秀的OLAP系統(tǒng)架構(gòu)應(yīng)該是怎樣的裤唠，一個系統(tǒng)是否可以同時很好的支持OLTP和OLAP，這些問題想清楚后我會再寫篇文章描述下莹痢，當(dāng)然种蘸，大家有好的想法，也歡迎直接Comment竞膳。
