文章轉(zhuǎn)載于：https://mp.weixin.qq.com/s?__biz=MzAwODE3ODU5MA==&mid=2653081811&idx=1&sn=a30d9f66cedaa8b466fd56202e9ac1b3
Apache Kylin 和 ClickHouse 都是目前市場流行的大數(shù)據(jù) OLAP 引擎概疆；Kylin 最初由 eBay 中國研發(fā)中心開發(fā)筐高，2014 年開源并貢獻給 Apache 軟件基金會换团，憑借著亞秒級查詢的能力和超高的并發(fā)查詢能力埂蕊，被許多大廠所采用，包括美團武契，滴滴祭往，攜程，貝殼找房姆泻，騰訊啰脚，58同城等猜丹；
OLAP 領(lǐng)域這兩年炙手可熱的 ClickHouse，由俄羅斯搜索巨頭 Yandex 開發(fā)，于2016年開源泄朴，典型用戶包括字節(jié)跳動、新浪浸船、騰訊等知名企業(yè)褪储。
這兩種 OLAP 引擎有什么差異，各自有什么優(yōu)勢，如何選擇 榆骚？本文將嘗試從技術(shù)原理片拍、存儲結(jié)構(gòu)、優(yōu)化方法和優(yōu)勢場景等方面妓肢，對比這兩種 OLAP 引擎捌省， 為大家的技術(shù)選型提供一些參考。
01
技術(shù)原理
技術(shù)原理方面职恳，我們主要從架構(gòu)和生態(tài)兩方面做個比較所禀。
1.1 技術(shù)架構(gòu)
Kylin 是基于 Hadoop 的 MOLAP (Multi-dimensional OLAP) 技術(shù)，核心技術(shù)是 OLAP Cube放钦；與傳統(tǒng) MOLAP 技術(shù)不同色徘，Kylin 運行在 Hadoop 這個功能強大、擴展性強的平臺上操禀，從而可以支持海量 (TB到PB) 的數(shù)據(jù)褂策；它將預計算（通過 MapReduce 或 Spark 執(zhí)行）好的多維 Cube 導入到 HBase 這個低延遲的分布式數(shù)據(jù)庫中，從而可以實現(xiàn)亞秒級的查詢響應颓屑；最近的 Kylin 4 開始使用 Spark + Parquet 來替換 HBase斤寂，從而進一步簡化架構(gòu)。由于大量的聚合計算在離線任務（Cube 構(gòu)建）過程中已經(jīng)完成揪惦，所以執(zhí)行 SQL 查詢時遍搞，它不需要再訪問原始數(shù)據(jù)，而是直接利用索引結(jié)合聚合結(jié)果再二次計算器腋，性能比訪問原始數(shù)據(jù)高百倍甚至千倍溪猿；由于 CPU 使用率低，它可以支持較高的并發(fā)量纫塌，尤其適合自助分析诊县、固定報表等多用戶、交互式分析的場景措左。
ClickHouse 是基于 MPP 架構(gòu)的分布式 ROLAP （Relational OLAP）分析引擎依痊，各節(jié)點職責對等，各自負責一部分數(shù)據(jù)的處理（shared nothing）怎披，開發(fā)了向量化執(zhí)行引擎胸嘁，利用日志合并樹、稀疏索引與 CPU 的 SIMD（單指令多數(shù)據(jù) 钳枕，Single Instruction Multiple Data）等特性缴渊，充分發(fā)揮硬件優(yōu)勢，達到高效計算的目的鱼炒。因此當 ClickHouse 面對大數(shù)據(jù)量計算的場景衔沼，通常能達到 CPU 性能的極限。
1. 2 技術(shù)生態(tài)
Kylin 采用 Java 編寫，充分融入 Hadoop 生態(tài)系統(tǒng)指蚁，使用 HDFS 做分布式存儲菩佑，計算引擎可選 MapReduce、Spark凝化、Flink稍坯；存儲引擎可選 HBase、Parquet（結(jié)合 Spark)搓劫。源數(shù)據(jù)接入支持 Hive瞧哟、Kafka、RDBMS 等枪向，多節(jié)點協(xié)調(diào)依賴 Zookeeper勤揩；兼容 Hive 元數(shù)據(jù)，Kylin 只支持 SELECT 查詢秘蛔，schema 的修改等都需要在 Hive 中完成陨亡，然后同步到 Kylin；建模等操作通過 Web UI 完成深员，任務調(diào)度通過 Rest API 進行负蠕，Web UI 上可以查看任務進度。
ClickHouse 采用 C++ 編寫倦畅，自成一套體系遮糖，對第三方工具依賴少。支持較完整的 DDL 和 DML叠赐，大部分操作可以通過命令行結(jié)合 SQL 就可以完成止吁；分布式集群依賴 Zookeper 管理，單節(jié)點不用依賴 Zookeper燎悍，大部分配置需要通過修改配置文件完成。
02
存儲
Kylin 采用 Hadoop 生態(tài)的 HBase 或 Parquet 做存儲結(jié)構(gòu)盼理，依靠 HBase 的 rowkey 索引或 Parquet 的 Row group 稀疏索引來做查詢提速谈山，使用 HBase Region Server 或 Spark executor 做分布式并行計算。ClickHouse 自己管理數(shù)據(jù)存儲宏怔，它的存儲特點包括：MergeTree 作主要的存儲結(jié)構(gòu)奏路，數(shù)據(jù)壓縮分塊，稀疏索引等臊诊。下面將針對兩者的引擎做詳細對比鸽粉。
2.1 Kylin 的存儲結(jié)構(gòu)
Kylin 通過預聚合計算出多維 Cube 數(shù)據(jù)，查詢的時候根據(jù)查詢條件抓艳，動態(tài)選擇最優(yōu)的 Cuboid （類似于物化視圖）触机，這會極大減小 CPU 計算量和 IO 的讀取量。
在 Cube 構(gòu)建過程中，Kylin 將維度值進行一定的編碼壓縮如字典編碼儡首，力圖最小化數(shù)據(jù)存儲片任；由于 Kylin 的存儲引擎和構(gòu)建引擎都是可插拔式的，對于不同的存儲引擎蔬胯，存儲結(jié)構(gòu)也有所差異对供。
HBase 存儲
在使用 HBase 作為存儲引擎的情況下，在預計算時會對各個維度進行編碼氛濒，保證維度值長度固定产场，并且在生成 hfile 時把計算結(jié)果中的維度拼接成 rowkey，聚合值作為 value舞竿。維度的順序決定 rowkey 的設(shè)計京景，也會直接影響查詢的效率。
Parquet 存儲引擎
在使用 Parquet 作為存儲格式時則會直接存儲維度值和聚合值炬灭，而不需要進行編碼和 rowkey 拼接醋粟。在存成 Parquet 之前，計算引擎會根據(jù)維度對計算結(jié)果進行排序重归，維度字段越是靠前米愿，那么在其上的過濾效率也就越高。另外在同一個分區(qū)下 shard 的數(shù)量和 parquet 文件的 row group 數(shù)量也同樣會影響查詢的效率鼻吮。
2.2 ClickHouse 的存儲結(jié)構(gòu)
ClickHouse 在創(chuàng)建表結(jié)構(gòu)的時候一般要求用戶指定分區(qū)列育苟。采用數(shù)據(jù)壓縮和純粹的列式存儲技術(shù)， 使用 Mergetree 對每一列單獨存儲并壓縮分塊椎木，
同時數(shù)據(jù)總會以片段的形式寫入磁盤违柏，當滿足一定條件后 ClickHouse 會通過后臺線程定期合并這些數(shù)據(jù)片段。
當數(shù)據(jù)量持續(xù)增大香椎，ClickHouse畜伐，會針對分區(qū)目錄的數(shù)據(jù)進行合并万矾，提高數(shù)據(jù)掃描的效率笨枯。
同時 ClickHouse 針對每個數(shù)據(jù)塊窥突，提供稀疏索引梧税。在處理查詢請求的時候，就能夠利用稀疏索引凳谦，減少數(shù)據(jù)掃描起到加速作用缓醋。
03
優(yōu)化方法
Kylin 和 ClickHouse 都是大數(shù)據(jù)處理系統(tǒng)，當數(shù)據(jù)量級持續(xù)增大的時候，采用合適的優(yōu)化方法往往能事半功倍，極大地降低查詢響應時間，減少存儲空間喷好，提升查詢性能梗搅。由于二者的計算系統(tǒng)和存儲系統(tǒng)不同丐枉，因此采用的優(yōu)化方式也不一樣，下一小節(jié)將著重分析 Kylin 和 ClickHouse 兩者的優(yōu)化方法。
3.1 Kylin 的優(yōu)化方法
Kylin 的核心原理是預計算听绳，正如第一小節(jié)技術(shù)原理所說：Kylin 的計算引擎用 Apache Spark塔拳，MapReduce名惩；存儲用 HBase稚伍，Parquet垦搬；SQL 解析和后計算用 Apache Calcite。Kylin 的核心技術(shù)是研發(fā)了一系列的優(yōu)化方法猴贰，來幫助解決維度爆炸和掃描數(shù)據(jù)過多的問題对雪，這些方法包括：設(shè)置聚合組，設(shè)置聯(lián)合維度米绕，設(shè)置衍生維度瑟捣，設(shè)置維度表快照馋艺，設(shè)置 Rowkey 順序，設(shè)置 shard by 列等迈套。
設(shè)置聚合組：通過聚合組進行剪枝捐祠，減少不必要的預計算組合；
設(shè)置聯(lián)合維度：將經(jīng)常成對出現(xiàn)的維度組合放在一起桑李，減少不必要的預計算踱蛀；
設(shè)置衍生維度：將能通過其他維度計算出來的維度（例如年，月芙扎，日能通過日期計算出來）設(shè)置為衍生維度星岗，減少不必要的預計算；
設(shè)置維度表快照：放入內(nèi)存現(xiàn)算戒洼，減少占用的存儲空間俏橘；
字典編碼：減少占用的存儲空間；
RowKey 編碼圈浇，設(shè)置 shard by 列：通過減少數(shù)據(jù)掃描的行數(shù)寥掐，加速查詢效率
3.2 ClickHouse 優(yōu)化方法
MPP 架構(gòu)的系統(tǒng)最常見的優(yōu)化方式就是分庫分表，類似的磷蜀，ClickHouse 最常見的優(yōu)化方式包括設(shè)置分區(qū)和分片****召耘，此外 ClickHouse 也包括一些特有的引擎『致。總結(jié)歸納下來污它，這些優(yōu)化方法包括：
用平表結(jié)構(gòu)，代替多表 Join庶弃，避免昂貴的 Join 操作和數(shù)據(jù)混洗
設(shè)置合理的分區(qū)鍵衫贬，排序鍵，二級索引歇攻，減少數(shù)據(jù)掃描
搭建 ClickHouse 分布式集群增加分片和副本固惯，添加計算資源
結(jié)合物化視圖，適當采用 SummingMergetree缴守，AggregateMergetree 等以預計算為核心的引擎
隨著后面性能和并發(fā)的要求越來越高葬毫，對機器的資源消耗也越來越大。在 ClickHouse 的官方網(wǎng)站文檔中建議 ClickHouse 的并發(fā)數(shù)不超過 100屡穗，當并發(fā)要求高贴捡，為減少 ClickHouse 的資源消耗，可以結(jié)合 ClickHouse 的一些特殊引擎進行優(yōu)化村砂。
特殊引擎中最常用的是 SummingMergetree 和 AggregateMergetree烂斋，這兩種數(shù)據(jù)結(jié)構(gòu)是從 Mergetree 中派生而來，本質(zhì)是通過預計算將需要查詢的數(shù)據(jù)提前算出來，保存在 ClickHouse 中源祈，這樣查詢的時候就能進一步減少資源消耗。
從使用原理來看 SummingMergetree 和 AggregateMergetree 與 Kylin 的Cube有異曲同工之妙色迂。但是當維度過多的時候香缺，管理很多個物化視圖是不現(xiàn)實的做法，存在管理成本高等問題歇僧。與 ClickHouse 不同图张，Kylin 提供一系列簡單直接的優(yōu)化方法，來避免維度爆炸的問題诈悍。
可以看到祸轮，ClickHouse 和 Kylin 都提供一些方法減少存儲占用的空間，降低查詢時掃描數(shù)據(jù)的行數(shù)侥钳。通常認為：對 ClickHouse 和 Kylin 進行適當優(yōu)化适袜，都能在大數(shù)據(jù)量場景下滿足業(yè)務需求。ClickHouse 采用 MPP 現(xiàn)算舷夺，Kylin 采用預計算苦酱，由于兩者采用的技術(shù)路線不同因此相應優(yōu)勢場景也不同。
04
優(yōu)勢場景
Kylin 因為采用預計算技術(shù)给猾， 適合有固定模式的聚合查詢疫萤，例如：SQL 中的 join、group by敢伸、where條件模式比較固定等扯饶，數(shù)據(jù)量越大，使用 Kylin 的優(yōu)勢越明顯池颈；特別的尾序，Kylin 在去重（count distinct）、Top N饶辙、Percentile 等場景的優(yōu)勢尤為巨大蹲诀，大量使用在 Dashboard、各類報表弃揽、大屏展示脯爪、流量統(tǒng)計、用戶行為分析等場景矿微。美團痕慢、極光、貝殼找房等使用 Kylin 構(gòu)建了他們的數(shù)據(jù)服務平臺涌矢，每日提供高達數(shù)百萬到數(shù)千萬次的查詢服務掖举，且大部分查詢可以在 2 - 3 秒內(nèi)完成。這樣的高并發(fā)場景幾乎沒有更好的替代方案娜庇。
ClickHouse 因為采用 MPP 架構(gòu)現(xiàn)場計算能力很強塔次，當查詢請求比較靈活方篮，或者有明細查詢需求，并發(fā)量不大的時候比較適用励负。場景包括：非常多列且 where 條件隨意組合的用戶標簽篩選藕溅，并發(fā)量不大的復雜即席查詢等。如果數(shù)據(jù)量和訪問量較大继榆，需要部署分布式 ClickHouse 集群巾表，這時候?qū)\維的挑戰(zhàn)會比較高。
如果有些查詢非常靈活略吨，但不經(jīng)常查集币，采用現(xiàn)算就比較節(jié)省資源，由于查詢量少翠忠，即使每個查詢消耗計算資源大整體來說也可以是劃算的鞠苟。如果有些查詢有固定的模式，查詢量較大就更適合 Kylin负间，因為查詢量大偶妖，利用大的計算資源將計算結(jié)果保存，前期的計算成本能夠攤薄每個查詢中政溃，因此是最經(jīng)濟的趾访。
05
總結(jié)
本文就技術(shù)原理，存儲結(jié)構(gòu)董虱，優(yōu)化方法及優(yōu)勢場景扼鞋，對 Kylin 和 ClickHouse 進行了對比。
技術(shù)原理方面：ClickHouse 采用 MPP + Shared nothing 架構(gòu)愤诱，查詢比較靈活云头，安裝部署和操作簡便，由于數(shù)據(jù)存儲在本地淫半，擴容和運維相對較麻煩溃槐；Kylin 采用 MOLAP 預計算，基于 Hadoop科吭，計算與存儲分離（特別是使用 Parquet 存儲后）昏滴、Shared storage 的架構(gòu)，更適合場景相對固定但數(shù)據(jù)體量很大的場景对人，基于 Hadoop 便于與現(xiàn)有大數(shù)據(jù)平臺融合谣殊，也便于水平伸縮（特別是從 HBase 升級為 Spark + Parquet 后）。
存儲結(jié)構(gòu)方面：ClickHouse 存儲明細數(shù)據(jù)牺弄，特點包括MergeTree 存儲結(jié)構(gòu)和稀疏索引姻几，在明細之上可以進一步創(chuàng)建聚合表來加速性能；Kylin 采用預聚合以及 HBase 或 Parquet 做存儲，物化視圖對查詢透明蛇捌，聚合查詢非常高效但不支持明細查詢抚恒。
優(yōu)化方法方面：ClickHouse 包括分區(qū)分片和二級索引等優(yōu)化手段， Kylin 采用聚合組络拌、聯(lián)合維度柑爸、衍生維度、層級維度盒音，以及 rowkey 排序等優(yōu)化手段
優(yōu)勢場景方面：ClickHouse 通常適合幾億~幾十億量級的靈活查詢（更多量級也支持只是集群運維難度會加大）。Kylin 則更適合幾十億~百億以上的相對固定的查詢場景馅而。
下圖是一個多方面的匯總：
綜合下來祥诽， Kylin 和 ClickHouse 有各種使用的領(lǐng)域和場景 。現(xiàn)代數(shù)據(jù)分析領(lǐng)域沒有一種能適應所有場景的分析引擎瓮恭。企業(yè)需要根據(jù)自己的業(yè)務場景雄坪，選擇合適的工具解決具體問題。希望本文能夠幫助企業(yè)做出合適的技術(shù)選型屯蹦。
