Apache Kylin與ClickHouse的區別是什么

今天小編給大家分享一下Apache Kylin與ClickHouse的區別是什么的相關知識點，內容詳細，邏輯清晰，相信大部分人都還太了解這方面的知識，所以分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后有所收獲，下面我們一起來了解一下吧。

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

用平表結構，代替多表 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，因為查詢量大，利用大的計算資源將計算結果保存，前期的計算成本能夠攤薄每個查詢中，因此是最經濟的。

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 有各種使用的領域和場景 。現代數據分析領域沒有一種能適應所有場景的分析引擎。企業需要根據自己的業務場景，選擇合適的工具解決具體問題。

以上就是“Apache Kylin與ClickHouse的區別是什么”這篇文章的所有內容，感謝各位的閱讀！相信大家閱讀完這篇文章都有很大的收獲，小編每天都會為大家更新不同的知識，如果還想學習更多的知識，請關注億速云行業資訊頻道。