作者簡介

周耀，Kyligence 解決方案架構師，Apache Kylin、Apache Superset Contributor。

出處:https://mp.weixin.qq.com/s?__biz=MzAwODE3ODU5MA==&mid=2653081811&idx=1&sn=a30d9f66cedaa8b466fd56202e9ac1b3

Apache Kylin 和 ClickHouse 都是目前市場流行的大資料 OLAP 引擎；Kylin 最初由 eBay 中國研發中心開發，2014 年開源並貢獻給 Apache 軟體基金會，憑藉著亞秒級查詢的能力和超高的併發查詢能力，被許多大廠所採用，包括美團，滴滴，攜程，貝殼找房，騰訊，58同城等；

OLAP 領域這兩年炙手可熱的 ClickHouse，由俄羅斯搜尋巨頭 Yandex 開發，於2016年開源，典型使用者包括位元組跳動、新浪、騰訊等知名企業。

這兩種 OLAP 引擎有什麼差異，各自有什麼優勢，如何選擇 ？ 本文將嘗試從技術原理、儲存結構、最佳化方法和優勢場景等方面，對比這兩種 OLAP 引擎， 為大家的技術選型提供一些參考。

01

技術原理

技術原理方面，我們主要從 架構 和 生態 兩方面做個比較。

1.1 技術架構

Kylin 是基於 Hadoop 的 MOLAP (Multi-dimensional OLAP) 技術，核心技術是 OLAP Cube ；與傳統 MOLAP 技術不同，Kylin 執行在 Hadoop 這個功能強大、擴充套件性強的平臺上，從而可以支援海量 (TB到PB) 的資料；它將預計算（透過 MapReduce 或 Spark 執行）好的多維 Cube 匯入到 HBase 這個低延遲的分散式資料庫中，從而可以實現亞秒級的查詢響應；最近的 Kylin 4 開始使用 Spark + Parquet 來替換 HBase，從而進一步簡化架構。由於大量的聚合計算在離線任務（Cube 構建）過程中已經完成，所以執行 SQL 查詢時，它不需要再訪問原始資料，而是直接利用索引結合聚合結果再二次計算，效能比訪問原始資料高百倍甚至千倍；由於 CPU 使用率低，它可以支援較高的併發量，尤其適合自助分析、固定報表等多使用者、互動式分析的場景。

ClickHouse 是基於 MPP 架構的分散式 ROLAP （Relational OLAP）分析引擎 ，各節點職責對等，各自負責一部分資料的處理（shared nothing），開發了向量化執行引擎，利用日誌合併樹、稀疏索引與 CPU 的 SIMD（單指令多資料 ，Single Instruction Multiple Data）等特性，充分發揮硬體優勢，達到高效計算的目的。因此當 ClickHouse 面對大資料量計算的場景，通常能達到 CPU 效能的極限。

1. 2 技術生態

Kylin 採用 Java 編寫，充分融入 Hadoop 生態系統，使用 HDFS 做分散式儲存，計算引擎可選 MapReduce、Spark、Flink；儲存引擎可選 HBase、Parquet（結合 Spark)。源資料接入支援 Hive、Kafka、RDBMS 等，多節點協調依賴 Zookeeper；相容 Hive 元資料，Kylin 只支援 SELECT 查詢，schema 的修改等都需要在 Hive 中完成，然後同步到 Kylin；建模等操作透過 Web UI 完成，任務排程透過 Rest API 進行，Web UI 上可以檢視任務進度。

ClickHouse 採用 C++ 編寫，自成一套體系，對第三方工具依賴少。支援較完整的 DDL 和 DML，大部分操作可以透過命令列結合 SQL 就可以完成；分散式叢集依賴 Zookeper 管理，單節點不用依賴 Zookeper，大部分配置需要透過修改配置檔案完成。

Kylin 採用 Hadoop 生態的 HBase 或 Parquet 做儲存結構，依靠 HBase 的 rowkey 索引或 Parquet 的 Row group 稀疏索引來做查詢提速，使用 HBase Region Server 或 Spark executor 做分散式平行計算。ClickHouse 自己管理資料儲存，它的儲存特點包括：MergeTree 作主要的儲存結構，資料壓縮分塊，稀疏索引等。下面將針對兩者的引擎做詳細對比。

2.1 Kylin 的儲存結構

Kylin 透過預聚合計算出多維 Cube 資料，查詢的時候根據查詢條件，動態選擇最優的 Cuboid （類似於物化檢視），這會極大減小 CPU 計算量和 IO 的讀取量。

在 Cube 構建過程中，Kylin 將維度值進行一定的編碼壓縮如字典編碼，力圖最小化資料儲存；由於 Kylin 的儲存引擎和構建引擎都是可插拔式的，對於不同的儲存引擎，儲存結構也有所差異。

HBase 儲存

在使用 HBase 作為儲存引擎的情況下，在預計算時會對各個維度進行編碼，保證維度值長度固定，並且在生成 hfile 時把計算結果中的維度拼接成 rowkey，聚合值作為 value。維度的順序決定 rowkey 的設計，也會直接影響查詢的效率。

Parquet 儲存引擎

在使用 Parquet 作為儲存格式時則會直接儲存維度值和聚合值，而不需要進行編碼和 rowkey 拼接。在存成 Parquet 之前，計算引擎會根據維度對計算結果進行排序，維度欄位越是靠前，那麼在其上的過濾效率也就越高。另外在同一個分割槽下 shard 的數量和 parquet 檔案的 row group 數量也同樣會影響查詢的效率。

2.2 ClickHouse 的儲存結構

ClickHouse 在建立表結構的時候一般要求使用者指定分割槽列。採用資料壓縮和純粹的列式儲存技術， 使用 Mergetree 對每一列單獨儲存並壓縮分塊，

同時資料總會以片段的形式寫入磁碟，當滿足一定條件後 ClickHouse 會通過後臺執行緒定期合併這些資料片段。

當資料量持續增大，ClickHouse，會針對分割槽目錄的資料進行合併，提高資料掃描的效率。

同時 ClickHouse 針對每個資料塊，提供稀疏索引。在處理查詢請求的時候，就能夠利用稀疏索引，減少資料掃描起到加速作用。

03

最佳化方法

Kylin 和 ClickHouse 都是大資料處理系統，當資料量級持續增大的時候，採用合適的最佳化方法往往能事半功倍，極大地降低查詢響應時間，減少儲存空間，提升查詢效能。由於二者的計算系統和儲存系統不同，因此採用的最佳化方式也不一樣，下一小節將著重分析 Kylin 和 ClickHouse 兩者的最佳化方法。

3.1 Kylin 的最佳化方法

Kylin 的核心原理是預計算 ，正如第一小節技術原理所說：Kylin 的計算引擎用 Apache Spark，MapReduce；儲存用 HBase，Parquet；SQL 解析和後計算用 Apache Calcite。 Kylin 的核心技術是研發了一系列的最佳化方法，來幫助解決維度爆炸和掃描資料過多的問題 ，這些方法包括：設定聚合組，設定聯合維度，設定衍生維度，設定維度錶快照，設定 Rowkey 順序，設定 shard by 列等。

設定聚合組：透過聚合組進行剪枝，減少不必要的預計算組合；設定聯合維度：將經常成對出現的維度組合放在一起，減少不必要的預計算；設定衍生維度：將能透過其他維度計算出來的維度（例如年，月，日能透過日期計算出來）設定為衍生維度，減少不必要的預計算；設定維度錶快照：放入記憶體現算，減少佔用的儲存空間；字典編碼：減少佔用的儲存空間；RowKey 編碼，設定 shard by 列：透過減少資料掃描的行數，加速查詢效率3.2 ClickHouse 最佳化方法

MPP 架構的系統最常見的最佳化方式就是分庫分表，類似的， ClickHouse 最常見的最佳化方式包括設定分割槽和分片 ，此外 ClickHouse 也包括一些特有的引擎 。總結歸納下來，這些最佳化方法包括：

用平表結構，代替多表 Join，避免昂貴的 Join 操作和資料混洗設定合理的分割槽鍵，排序鍵，二級索引，減少資料掃描搭建 ClickHouse 分散式叢集增加分片和副本，新增計算資源結合物化檢視，適當採用 SummingMergetree，AggregateMergetree 等以預計算為核心的引擎

隨著後面效能和併發的要求越來越高，對機器的資源消耗也越來越大。在 ClickHouse 的官方網站文件中建議 ClickHouse 的併發數不超過 100，當併發要求高，為減少 ClickHouse 的資源消耗，可以結合 ClickHouse 的一些特殊引擎進行最佳化。

特殊引擎中最常用的是 SummingMergetree 和 AggregateMergetree，這兩種資料結構是從 Mergetree 中派生而來，本質是透過預計算將需要查詢的資料提前算出來，儲存在 ClickHouse 中，這樣查詢的時候就能進一步減少資源消耗。

從使用原理來看 SummingMergetree 和 AggregateMergetree 與 Kylin 的Cube有異曲同工之妙。但是當維度過多的時候，管理很多個物化檢視是不現實的做法，存在管理成本高等問題。與 ClickHouse 不同，Kylin 提供一系列簡單直接的最佳化方法，來避免維度爆炸的問題。

可以看到，ClickHouse 和 Kylin 都提供一些方法減少儲存佔用的空間，降低查詢時掃描資料的行數。通常認為：對 ClickHouse 和 Kylin 進行適當最佳化，都能在大資料量場景下滿足業務需求。ClickHouse 採用 MPP 現算，Kylin 採用預計算，由於兩者採用的技術路線不同因此相應優勢場景也不同。

04

優勢場景

Kylin 因為採用預計算技術， 適合有固定模式的聚合查詢，例如：SQL 中的 join、group by、where條件模式比較固定等，資料量越大，使用 Kylin 的優勢越明顯；特別的， Kylin 在去重（count distinct）、Top N、Percentile 等場景的優勢尤為巨大，大量使用在 Dashboard、各類報表、大屏展示、流量統計、使用者行為分析等場景 。美團、極光、貝殼找房等使用 Kylin 構建了他們的資料服務平臺，每日提供高達數百萬到數千萬次的查詢服務，且大部分查詢可以在 2 - 3 秒內完成。這樣的高併發場景幾乎沒有更好的替代方案。

ClickHouse 因為採用 MPP 架構現場計算能力很強，當查詢請求比較靈活，或者有明細查詢需求，併發量不大的時候比較適用 。 場景包括：非常多列且 where 條件隨意組合的使用者標籤篩選，併發量不大的複雜即席查詢等。如果資料量和訪問量較大，需要部署分散式 ClickHouse 叢集，這時候對運維的挑戰會比較高。

如果有些查詢非常靈活，但不經常查，採用現算就比較節省資源，由於查詢量少，即使每個查詢消耗計算資源大整體來說也可以是划算的。如果有些查詢有固定的模式，查詢量較大就更適合 Kylin，因為查詢量大，利用大的計算資源將計算結果儲存，前期的計算成本能夠攤薄每個查詢中，因此是最經濟的。

本文就技術原理，儲存結構，最佳化方法及優勢場景，對 Kylin 和 ClickHouse 進行了對比。

技術原理方面 ：ClickHouse 採用 MPP + Shared nothing 架構，查詢比較靈活，安裝部署和操作簡便，由於資料儲存在本地，擴容和運維相對較麻煩；Kylin 採用 MOLAP 預計算，基於 Hadoop，計算與儲存分離（特別是使用 Parquet 儲存後）、Shared storage 的架構，更適合場景相對固定但資料體量很大的場景，基於 Hadoop 便於與現有大資料平臺融合，也便於水平伸縮（特別是從 HBase 升級為 Spark + Parquet 後）。

儲存結構方面 ：ClickHouse 儲存明細資料，特點包括MergeTree 儲存結構和稀疏索引，在明細之上可以進一步建立聚合表來加速效能；Kylin 採用預聚合以及 HBase 或 Parquet 做儲存，物化檢視對查詢透明，聚合查詢非常高效但不支援明細查詢。

最佳化方法方面 ：ClickHouse 包括分割槽分片和二級索引等最佳化手段， Kylin 採用聚合組、聯合維度、衍生維度、層級維度，以及 rowkey 排序等最佳化手段

優勢場景方面 ：ClickHouse 通常適合幾億~幾十億量級的靈活查詢（更多量級也支援只是叢集運維難度會加大）。 Kylin 則更適合幾十億~百億以上的相對固定的查詢場景。

下圖是一個多方面的彙總：

綜合下來， Kylin 和 ClickHouse 有各種使用的領域和場景 。現代資料分析領域沒有一種能適應所有場景的分析引擎。企業需要根據自己的業務場景，選擇合適的工具解決具體問題。希望本文能夠幫助企業做出合適的技術選型。

出處:https://mp.weixin.qq.com/s?__biz=MzAwODE3ODU5MA==&mid=2653081811&idx=1&sn=a30d9f66cedaa8b466fd56202e9ac1b3