共计 4862 个字符，预计需要花费 13 分钟才能阅读完成。
文章转载于：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 也包含一些特有的引擎。总结演绎下来，这些优化办法包含：
- 用平表构造，代替多表 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 有各种应用的畛域和场景。古代数据分析畛域没有一种能适应所有场景的剖析引擎。企业须要依据本人的业务场景，抉择适合的工具解决具体问题。心愿本文可能帮忙企业做出适合的技术选型。