本文對 Apache Kylin 的理解基於近兩年來在生產環境大規模地使用，運維和深度開發，我已向 Kylin 社群貢獻了 98 次 Commit，包含多項新功能和深度優化。本文對 Baidu Palo 的理解基於官方文件和論文的閱讀，程式碼的粗淺閱讀和較深入地測試。
更多幹貨內容請關注微信公眾號“AI 前線”，（ID：ai-front）
1 系統架構
1.1 What is Kylin
1.2 What is Palo
2 資料模型
2.1 Kylin 的聚合模型
2.2 Palo 的聚合模型
2.3 Kylin Cuboid VS Palo RollUp
2.4 Palo 的明細模型
3 儲存引擎
4 資料匯入
5 查詢
6 精確去重
7 後設資料
8 高效能
9 高可用
10 可維護性
10.1 部署
10.2 運維
10.3 客服
11 易用性
11.1 查詢接入
11.2 學習成本
11.3 Schema Change
12 功能
13 社群和生態
14 總結
15 參考資料
注： 本文的對比 基於 Apache Kylin 2.0.0 和 Baidu Palo 0.8.0。
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-cube
下圖是 Kylin 資料流轉的示意圖，Kylin 自身的元件只有兩個：JobServer 和 QueryServer。 Kylin 的 JobServer 主要負責將資料來源（Hive,Kafka）的資料通過計算引擎（MapReduce，Spark）生成 Cube 儲存到儲存引擎（HBase）中；QueryServer 主要負責 SQL 的解析，邏輯計劃的生成和優化，向 HBase 的多個 Region 發起請求，並對多個 Region 的結果進行彙總，生成最終的結果集。
kylin-data
下圖是 Kylin 可插拔的架構圖, 在架構設計上，Kylin 的資料來源，構建 Cube 的 計算引擎，儲存引擎都是可插拔的。Kylin 的核心就是這套可插拔架構，Cube 資料模型和 Cuboid 的演算法。
Kylin
Palo 是一個基於 MPP 的 OLAP 系統，主要整合了 Google Mesa（資料模型），Apache Impala（MPP Query Engine) 和 Apache ORCFile(儲存格式，編碼和壓縮) 的技術。
baidu-palo
Palo 的系統架構如下，Palo 主要分為 FE 和 BE 兩個元件，FE 主要負責查詢的編譯，分發和後設資料管理（基於記憶體，類似 HDFS NN）；BE 主要負責查詢的執行和儲存系統。
baidu-palo
Kylin 將表中的列分為維度列和指標列。在資料匯入和查詢時相同維度列中的指標會按照對應的聚合函式 (Sum, Count, Min, Max, 精確去重，近似去重，百分位數，TOPN) 進行聚合。
在儲存到 HBase 時，Cuboid+ 維度 會作為 HBase 的 Rowkey, 指標會作為 HBase 的 Value，一般所有指標會在 HBase 的一個列族，每列對應一個指標，但對於較大的去重指標會單獨拆分到第 2 個列族。
Kylin-model
Palo 的聚合模型借鑑自 Mesa，但本質上和 Kylin 的聚合模型一樣，只不過 Palo 中將維度稱作 Key，指標稱作 Value。
palo-data-model
Palo 中比較獨特的聚合函式是 Replace 函式，這個聚合函式能夠保證相同 Keys 的記錄只保留最新的 Value， 可以藉助這個 Replace 函式來實現 點更新。一般 OLAP 系統的資料都是隻支援 Append 的，但是像電商中交易的退款，廣告點選中的無效點選處理，都需要去更新之前寫入的單條資料，在 Kylin 這種沒有 Relpace 函式的系統中我們必須把包含對應更新記錄的整個 Segment 資料全部重刷，但是有了 Relpace 函式，我們只需要再追加 1 條新的記錄即可。 但是 Palo 中的 Repalce 函式有個缺點：無法支援預聚合， 就是說只要你的 SQL 中包含了 Repalce 函式，即使有其他可以已經預聚合的 Sum，Max 指標，也必須現場計算。
為什麼 Palo 可以支援點更新呢？
Kylin 中的 Segment 是不可變的，也就是說 HFile 一旦生成，就不再發生任何變化。但是 Palo 中的 Segment 檔案和 HBase 一樣，是可以進行 Compaction 的，具體可以參考 Google Mesa 論文解讀中的 Mesa 資料版本化管理（https://blog.bcmeng.com/post/google-mesa.html#mesa%E6%95%B0%E6%8D%AE%E7%89%88%E6%9C%AC%E5%8C%96%E7%AE%A1%E7%90%86）
Palo 的聚合模型相比 Kylin 有個缺點：就是一個 Column 只能有一個預聚合函式，無法設定多個預聚合函式。 不過 Palo 可以現場計算其他的聚合函式。 Baidu Palo 的開發者 Review 時提到，針對這個問題，Palo 還有一種解法：由於 Palo 支援多表匯入的原子更新，所以 1 個 Column 需要多個聚合函式時，可以在 Palo 中建多張表，同一份資料匯入時，Palo 可以同時原子更新多張 Palo 表，缺點是多張 Palo 表的查詢路由需要應用層來完成。
Palo 中和 Kylin 的 Cuboid 等價的概念是 RollUp 表，Cuboid 和 RollUp 表都可以認為是一種 Materialized Views 或者 Index。 Palo 的 RollUp 表和 Kylin 的 Cuboid 一樣，** 在查詢時不需要顯示指定，系統內部會根據查詢條件進行路由。 如下圖所示：
Palo Rollup
Palo 中 RollUp 表的路由規則如下：
選擇包含所有查詢列的 RollUp 表
按照過濾和排序的 Column 篩選最符合的 RollUp 表
按照 Join 的 Column 篩選最符合的 RollUp 表
行數最小的
列數最小的
Kylin cuboid vs palo rollup
由於 Palo 的聚合模型存在下面的缺陷，Palo 引入了明細模型。
必須區分維度列和指標列
維度列很多時，Sort 的成本很高
Count 成本很高，需要讀取所有維度列（可以參考 Kylin 的解決方法進行優化）
Palo 的明細模型不會有任何聚合，不區分維度列和指標列，但是在建表時需要指定 Sort Columns，資料匯入時會根據 Sort Columns 進行排序，查詢時根據 Sort Column 過濾會比較高效。
如下圖所示，Sort Columns 是 Year 和 City。
Kylin-detail-model
這裡需要注意一點，Palo 中一張表只能有一種資料模型，即要麼是聚合模型，要麼是明細模型，而且 Roll Up 表的資料模型必須和 Base 表一致， 也就是說明細模型的 Base 表不能有聚合模型的 Roll Up 表。
Kylin 儲存引擎 HBase：
如上圖所示，在 Kylin 中 1 個 Cube 可以按照時間拆分為多個 Segment,Segment 是 Kylin 中資料匯入和重新整理的最小單位。Kylin 中 1 個 Segment 對應 HBase 中一張 Table。 HBase 中的 Table 會按照 Range 分割槽拆分為多個 Region, 每個 Region 會按照大小拆分為多個 HFile。
關於 HFile 的原理網上講述的文章已經很多了，我這裡簡單介紹下。首先 HFile 整體上可以分為元資訊，Blcoks，Index3 部分，Blcoks 和 Index 都可以分為 Data 和 Meta 兩部分。Block 是資料讀取的最小單位，Block 有多個 Key-Value 組成，一個 Key-Value 代表 HBase 中的一行記錄，Key-Value 由 Kylin-Len，Value-Len，Key-Bytes,Value-Bytes 4 部分組成。更詳細的資訊大家可以參考下圖 (下圖來源於網際網路，具體出處不詳）：
HBase-HFile
Palo 儲存引擎：
如上圖所示，Palo 的 Table 支援二級分割槽，可以先按照日期列進行一級分割槽，再按照指定列 Hash 分桶。具體來說，1 個 Table 可以按照日期列分為多個 Partition， 每個 Partition 可以包含多個 Tablet，Tablet 是資料移動、複製等操作的最小物理儲存單元， 各個 Tablet 之間的資料沒有交集，並且在物理上獨立儲存。Partition 可以視為邏輯上最小的管理單元，資料的匯入與刪除，僅能針對一個 Partition 進行。1 個 Table 中 Tablet 的數量 = Partition num * Bucket num。Tablet 會按照一定大小（256M）拆分為多個 Segment 檔案，Segment 是列存的，但是會按行（1024）拆分為多個 Rowblock。
palo segment file
下面我們來看下 Palo Segment 檔案的具體格式，Palo 檔案格式主要參考了 Apache ORC。如上圖所示，Palo 檔案主要由 Meta 和 Data 兩部分組成，Meta 主要包括檔案本身的 Header，Segment Meta，Column Meta，和每個 Column 資料流的後設資料，每部分的具體內容大家看圖即可，比較詳細。 Data 部分主要包含每一列的 Index 和 Data，這裡的 Index 指每一列的 Min,Max 值和資料流 Stream 的 Position；Data 就是每一列具體的資料內容，Data 根據不同的資料型別會用不同的 Stream 來儲存，Present Stream 代表每個 Value 是否是 Null，Data Stream 代表二進位制資料流，Length Stream 代表非定長資料型別的長度。 下圖是 String 使用字典編碼和直接儲存的 Stream 例子。
Palo String encoding
下面我們來看下 Palo 的字首索引：
Palo index
本質上，Palo 的資料儲存是類似 SSTable（Sorted String Table）的資料結構。該結構是一種有序的資料結構，可以按照指定的列有序儲存。在這種資料結構上，以排序列作為條件進行查詢，會非常的高效。而字首索引，即在排序的基礎上，實現的一種根據給定字首列，快速查詢資料的索引方式。字首索引檔案的格式如上圖所示，索引的 Key 是每個 Rowblock 第一行記錄的 Sort Key 的前 36 個位元組，Value 是 Rowblock 在 Segment 檔案的偏移量。
有了字首索引後，我們查詢特定 Key 的過程就是兩次二分查詢：
先載入 Index 檔案，二分查詢 Index 檔案獲取包含特定 Key 的 Row blocks 的 Offest, 然後從 Sement Files 中獲取指定的 Rowblock；
在 Rowblocks 中二分查詢特定的 Key
Kylin 資料匯入：
Kylin data loading
如上圖，Kylin 資料匯入主要分為建 Hive 大寬表 (這一步會處理 Join)；維度列構建字典；逐層構建 Cuboid；Cuboid 轉為 HFile；Load HFile To HBase; 後設資料更新這幾步。
其中 Redistribute 大寬表這一步的作用是為了將整個表的資料搞均勻，避免後續的步驟中有資料傾斜，Kylin 有配置可以跳過這一步。
其中 Extract Distinct Columns 這一步的作用是獲取需要構建字典的維度列的 Distinct 值。假如一個 ID 維度列有 1，2，1，2，2，1，1，2 這 8 行，那麼經過這一步後 ID 列的值就只有 1，2 兩行，做這一步是為了下一步對維度列構建字典時更快速。
其他幾個步驟都比較好理解，我就不再贅述。更詳細的資訊可以參考 Apache Kylin Cube 構建原理（https://blog.bcmeng.com/post/kylin-cube.html）
Palo 資料匯入：
palo data loading
Palo 資料匯入的兩個核心階段是 ETL 和 LOADING, ETL 階段主要完成以下工作：
資料型別和格式的校驗
根據 Teblet 拆分資料
按照 Key 列進行排序, 對 Value 進行聚合
LOADING 階段主要完成以下工作：
每個 Tablet 對應的 BE 拉取排序好的資料
進行資料的格式轉換，生成索引LOADING 完成後會進行後設資料的更新。
Kylin 查詢：
Kylin query
如上圖，整個 Kylin 的查詢過程比較簡單，是個 Scatter-Gather 的模型。圖中圓形框的內容發生在 Kylin QueryServer 端，方形框的內容發生在 HBase 端。Kylin QueryServer 端收到 SQL 後，會先進行 SQL 的解析，然後生成和優化 Plan，再根據 Plan 生成和編譯程式碼，之後會根據 Plan 生成 HBase 的 Scan 請求，如果可能，HBase 端除了 Scan 之外，還會進行過濾和聚合（基於 HBase 的 Coprocessor 實現），Kylin 會將 HBase 端返回的結果進行合併，交給 Calcite 之前生成好的程式碼進行計算。
Palo 查詢：
palo-impala-query
Palo 的查詢引擎使用的是 Impala，是 MPP 架構。 Palo 的 FE 主要負責 SQL 的解析，語法分析，查詢計劃的生成和優化。查詢計劃的生成主要分為兩步：
生成單節點查詢計劃 （上圖左下角）
將單節點的查詢計劃分散式化，生成 PlanFragment（上圖右半部分）
第一步主要包括 Plan Tree 的生成，謂詞下推， Table Partitions pruning，Column projections，Cost-based 優化等；第二步 將單節點的查詢計劃分散式化，分散式化的目標是 最小化資料移動和最大化本地 Scan，分散式化的方法是增加 ExchangeNode，執行計劃樹會以 ExchangeNode 為邊界拆分為 PlanFragment，1 個 PlanFragment 封裝了在一臺機器上對同一資料集的部分 PlanTree。如上圖所示：各個 Fragment 的資料流轉和最終的結果傳送依賴：DataSink。
當 FE 生成好查詢計劃樹後，BE 對應的各種 Plan Node（Scan, Join, Union, Aggregation, Sort 等）執行自己負責的操作即可。
Kylin 的精確去重：
Kylin 的精確去重是基於全域性字典和 RoaringBitmap 實現的基於預計算的精確去重。具體可以參考 Apache Kylin 精確去重和全域性字典權威指南（https://blog.bcmeng.com/post/kylin-distinct-count-global-dict.html）
Palo 的精確去重：
Palo 的精確去重是現場精確去重，Palo 計算精確去重時會拆分為兩步：
按照所有的 group by 欄位和精確去重的欄位進行聚合
按照所有的 group by 欄位進行聚合
下面是個簡單的等價轉換的例子：
Palo 現場精確去重計算效能和 去重列的基數、去重指標個數、過濾後的資料大小成負相關；
Kylin 的後設資料 ：
Kylin 的後設資料是利用 HBase 儲存的，可以很好地橫向擴充套件。Kylin 每個具體的後設資料都是一個 Json 檔案，HBase 的 Rowkey 是檔名，Value 是 Json 檔案的內容。Kylin 的後設資料表設定了 IN_MEMORY => 'true' 屬性, 後設資料表會常駐 HBase RegionServer 的記憶體，所以後設資料的查詢效能很好，一般在幾 ms 到幾十 ms。
Kylin 後設資料利用 HBase 儲存的一個問題是，在 Kylin 可插拔架構下，即使我們實現了另一種儲存引擎，我們也必須部署 HBase 來儲存後設資料，所以 Kylin 要真正做到儲存引擎的可插拔，就必須實現一個獨立的後設資料儲存。
Palo 的後設資料：
Palo 的後設資料是基於記憶體的，這樣做的好處是效能很好且不需要額外的系統依賴。 缺點是單機的記憶體是有限的，擴充套件能力受限，但是根據 Palo 開發者的反饋，由於 Palo 本身的後設資料不多，所以後設資料本身佔用的記憶體不是很多，目前用大記憶體的物理機，應該可以支撐數百臺機器的 OLAP 叢集。 此外，OLAP 系統和 HDFS 這種分散式儲存系統不一樣，我們部署多個叢集的運維成本和 1 個叢集區別不大。
關於 Palo 後設資料的具體原理大家可以參考 Palo 官方文件 Palo 後設資料設計文件（https://github.com/baidu/palo/wiki/Metadata-Design）
Why Kylin Query Fast：
Kylin query
Kylin 查詢快的核心原因就是預計算，如圖 (圖片出處 Apache kylin 2.0: from classic olap to real-time data warehouse https://www.slideshare.net/YangLi43/apache-kylin-20-from-classic-olap-to-realtime-data-warehouse)，Kylin 現場查詢時不需要 Join，也幾乎不需要聚合，主要就是 Scan + Filter。
Why Palo Query Fast：
In-Memory Metadata。 Palo 的後設資料就在記憶體中，後設資料訪問速度很快。
聚合模型可以在資料匯入時進行預聚合。
和 Kylin 一樣，也支援預計算的 RollUp Table。
MPP 的查詢引擎。
向量化執行。相比 Kylin 中 Calcite 的程式碼生成，向量化執行在處理高併發的低延遲查詢時效能更好，Kylin 的程式碼生成本身可能會花費幾十 ms 甚至幾百 ms。
列式儲存 + 字首索引。
Kylin 高可用：
Kylin JobServer 的高可用： Kylin 的 JobServer 是無狀態的，一臺 JobServer 掛掉後，其他 JobServer 會很快接管正在 Running 的 Job。JobServer 的高可用是基於 Zookeeper 實現的，具體可以參考 Apache Kylin Job 生成和排程詳解（https://blog.bcmeng.com/post/kylin-job.html）。
Kylin QueryServer 的高可用：Kylin 的 QueryServer 也是無狀態的，其高可用一般通過 Nginx 這類的負載均衡元件來實現。
Kylin Hadoop 依賴的高可用： 要單純保證 Kylin 自身元件的高可用並不困難，但是要保證 Kylin 整體資料匯入和查詢的高可用是 十分困難的，因為必須同時保證 HBase，Hive，Hive Metastore，Spark，Mapreduce，HDFS，Yarn，Zookeeper，Kerberos 這些服務的高可用。
Palo 高可用：
Palo FE 的高可用： Palo FE 的高可用主要基於 BerkeleyDB java version 實現，BDB-JE 實現了類 Paxos 一致性協議演算法。
Palo BE 的高可用：Palo 會保證每個 Tablet 的多個副本分配到不同的 BE 上，所以一個 BE down 掉，不會影響查詢的可用性。
Kylin 部署： 如果完全從零開始，你就需要部署 1 個 Hadoop 叢集和 HBase 叢集。 即使公司已經有了比較完整的 Hadoop 生態，在部署 Kylin 前，你也必須先部署 Hadoop 客戶端，HBase 客戶端，Hive 客戶端，Spark 客戶端。
Palo 部署： 直接啟動 FE 和 BE。
Kylin 運維： 運維 Kylin 對 Admin 有較高的要求，首先必須瞭解 HBase，Hive，MapReduce，Spark，HDFS，Yarn 的原理；其次對 MapReduce Job 和 Spark Job 的問題排查和調優經驗要豐富；然後必須掌握對 Cube 複雜調優的方法；最後出現問題時排查的鏈路較長，複雜度較高。
Palo 運維： Palo 只需要理解和掌握系統本身即可。
Kylin 客服： 需要向使用者講清 Hadoop 相關的一堆概念；需要教會使用者 Kylin Web 的使用；需要教會使用者如何進行 Cube 優化（沒有統一，簡潔的優化原則）；需要教會使用者怎麼檢視 MR 和 Spark 日誌；需要教會使用者怎麼查詢；
Palo 客服： 需要教會使用者聚合模型，明細模型，字首索引，RollUp 表這些概念。
Kylin 查詢接入：Kylin 支援 Htpp,JDBC,ODBC 3 種查詢方式。
Palo 查詢接入： Palo 支援 Mysql 協議，現有的大量 Mysql 工具都可以直接使用，使用者的學習和遷移成本較低。
Kylin 學習成本： 使用者要用好 Kylin，需要理解以下概念：
Cuboid
聚集組
強制維度
聯合維度
層次維度
衍生維度
Extend Column
HBase RowKey 順序
此外，前面提到過，使用者還需要學會怎麼看 Mapreduce Job 和 Spark Job 日誌。
Palo 學習成本： 使用者需要理解聚合模型，明細模型，字首索引，RollUp 表這些概念。
Schema 線上變更是一個十分重要的 feature，因為在實際業務中，Schema 的變更會十分頻繁。
Kylin Schema Change： Kylin 中使用者對 Cube Schema 的任何改變，都需要在 Staging 環境重刷所有資料，然後切到 Prod 環境。整個過程週期很長，資源浪費比較嚴重。
Palo Schema Change：Palo 支援 Online Schema Change。
所謂的 Schema 線上變更就是指 Scheme 的變更不會影響資料的正常匯入和查詢，Palo 中的 Schema 線上變更有 3 種：
direct schema change：就是重刷全量資料，成本最高，和 kylin 的做法類似。當修改列的型別，稀疏索引中加一列時需要按照這種方法進行。
sorted schema change: 改變了列的排序方式，需對資料進行重新排序。例如刪除排序列中的一列, 欄位重排序。
linked schema change: 無需轉換資料，直接完成。對於歷史資料不會重刷，新攝入的資料都按照新的 Schema 處理，對於舊資料，新加列的值直接用對應資料型別的預設值填充。例如加列操作。Druid 也支援這種做法。
Apache kylin VS baidu palo
注： 關於 Kylin 的明細查詢，Kylin 本身只有聚合模型，但是也可以 通過將所有列作為維度列，只構建 Base Cuboid 來實現明細查詢， 缺點是效率比較低下。
注： 雖然 Palo 可以同時支援高併發，低延遲的 OLAP 查詢和高吞吐的 Adhoc 查詢，但顯然這兩類查詢會相互影響。所以 Baidu 在實際應用中也是用兩個叢集分別滿足 OLAP 查詢和 Adhoc 查詢需求。
Palo 社群剛剛起步，目前核心使用者只有 Baidu；Kylin 的社群和生態已經比較成熟，Kylin 是第一個完全由中國開發者貢獻的 Apache 頂級開源專案，目前已經在多家大型公司的生產環境中使用。
本文從多方面對比了 Apache Kylin 和 Baidu Palo，有理解錯誤的地方歡迎指正。本文更多的是對兩個系統架構和原理的客觀描述，主觀判斷較少。最近在調研了 Palo，ClickHouse，TiDB 之後，也一直在思考 OLAP 系統的發展趨勢是怎樣的，下一代更優秀的 OLAP 系統架構應該是怎樣的，一個系統是否可以同時很好的支援 OLTP 和 OLAP，這些問題想清楚後我會再寫篇文章描述下，當然，大家有好的想法，也歡迎直接 Comment。
1 Palo 文件和原始碼：https://github.com/baidu/palo
2 Kylin 原始碼：https://github.com/apache/kylin
3 Apache kylin 2.0: from classic olap to real-time data warehouse 在 Kylin 高效能部分引用了第 4 頁 PPT 的截圖：https://www.slideshare.net/YangLi43/apache-kylin-20-from-classic-olap-to-realtime-data-warehouse
4 百度 MPP 資料倉儲 Palo 開源架構解讀與應用 在 Palo 查詢部分引用了第 31 頁 PPT 的截圖 https://myslide.cn/slides/6392