淺淡 Apache Kylin 與 ClickHouse 的對比

文章轉載於：https://mp.weixin.qq.com/s?__...

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，大部分配置須要經過修改配置文件完成。

02

存儲

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 也包括一些特有的引擎。總結概括下來，這些優化方法包括：

1. 用平表結構，代替多表 Join，避免昂貴的 Join 操做和數據混洗
2. 設置合理的分區鍵，排序鍵，二級索引，減小數據掃描
3. 搭建 ClickHouse 分佈式集羣增長分片和副本，添加計算資源
4. 結合物化視圖，適當採用 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，由於查詢量大，利用大的計算資源將計算結果保存，前期的計算成本可以攤薄每一個查詢中，所以是最經濟的。

05

總結

本文就技術原理，存儲結構，優化方法及優點場景，對 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 有各類使用的領域和場景 。現代數據分析領域沒有一種能適應全部場景的分析引擎。企業須要根據本身的業務場景，選擇合適的工具解決具體問題。但願本文可以幫助企業作出合適的技術選型。