作者介绍

公司每日产生海量数据，按业务需要进行统计产出各类分析报表，但巨大的数据量加上复杂的数据模型，以及个性化的分析维度，采用传统的离线预计算方式难以灵活支持，为此需引入一种满足实时多维分析场景的计算引擎框架来支撑业务精细化运营场景。本文将分享ClickHouse在自助分析场景中的探索及实践，文章将从以下4个方面介绍：
 

转转平台主要对业务运营数据（埋点）进行分析，埋点数据包含在售商品的曝光、点击、展现等事件，覆盖场景数据量很大，且在部分分析场景需要支持精确去重。大数据量加上去重、数据分组等计算使得指标在统计过程中运算量较大。除此之外，在一些数据分析场景中需要计算留存率、漏斗转化等复杂的数据模型。

虽然在离线数仓的数仓分层和汇总层对通用指标做了预计算处理，但由于这些模型的分析维度通常是不确定的，因此预计算无法满足产品或者运营提出的个性化报表的需求，需分析师或数仓工程师进行sql开发，使得数据开发链路长交付慢，数据价值也随着时间的推移而减少。

作为分析平台，既需要保证数据时效性、架构的高可用，也要做到任意维度、任意指标的秒级响应。基于以上情况，需要一个即席查询的引擎来实现。

转转对OLAP引擎选型考量有三个方面：性能，灵活性，复杂性。

性能：

灵活性：

复杂性：

根据这三个方面的考量，调研了目前主流的几类开源OLAP引擎：

OLAP引擎主要分为两大类：

Kylin采用的技术是完全预聚合立方体，能提供较好的SQL支持以及join能力，查询速度基本上都是亚秒级响应。同时，Kylin有良好的web管理界面，可以监控和使用立方体。但当维度较多，交叉深度较深时，底层的数据会爆炸式的膨胀。而且Kylin的查询灵活性比较弱，这也是MOLAP引擎普遍的弱点。

Druid采用位图索引、字符串编码和预聚合技术，可以对数据进行实时摄入，支持高可用高并发的查询，但是对OLAP引擎的分析场景支持能力比较弱，join的能力不成熟，无法支持需要做精确去重计算的场景。

Impala支持窗口函数和UDF，查询性能比较好，但对内存的依赖较大，且Impala的元数据存储在Hive Metastore里，需要与Hadoop组件紧密的结合，对实时数据摄入一般要结合Kudu这类存储引擎做DML操作，多系统架构运维也比较复杂。

Presto可跨数据源做联邦查询，能支持多表的join，但在高并发的场景下性能较弱的。

ClickHouse单机性能很强，基于列式存储，能利用向量化引擎做到并行化计算，查询基本上是毫秒级或秒级的反馈，但ClickHouse没有完整的事务支持，对分布式表的join能力较弱。

Doris运维简单，扩缩容容易且支持事务，但Doris版本更新迭代较快且成熟度不够，也没有像ClickHouse自带的一些函数如漏斗、留存，不足以支撑转转的业务场景。

基于以上考量，最终选择了ClickHouse作为分析引擎。

ClickHouse是面向实时联机分析处理的基于列式存储的开源分析引擎，是俄罗斯于2016年开源的，底层开发语言为C++，可以支撑PB数据量级的分析。ClickHouse有以下特性：

ClickHouse的查询场景主要分为四大类：

转转高斯平台的核心功能主要包含两个部分：

下图展示了高斯平台的系统架构，总共分为四层：

①行为分析

②AB-TEST分析

在数据分析过程中常见的问题大都是和内存相关的。如上图所示，当内存使用量大于了单台服务器的内存上限，就会抛出该异常。

针对这个问题，需要对SQL语句和SQL查询的场景进行分析：

• 如果是在进行count和disticnt计算时内存不足，可以使用一些预估函数减少内存的使用量来提升查询速度；

• 如果SQL语句进行了group by或者是order by操作，可以配置max_bytes_before_external_group_by和max_bytes_before_external_sort这两个参数调整。

上图是实践的一些优化参数，主要是限制并发处理的请求数和限制内存相关的参数。

max_concurrent_queries：限制每秒的并发请求数，默认值100，转转调整参数值为150。需根据集群性能以及节点的数量来调整此参数值。

max_memory_usage：设置单个查询单台机器的最大内存使用量，建议设置值为总内存的80%，因为需要预留一些内存给系统os使用。

max_memory_usage_for_all_queries：设置单服务器上查询的最大内存量，建议设置为总内存的80%~90%。

max_memory_usage_for_user & max_bytes_before_external_sort：group by和order by使用超出内存的阈值后，预写磁盘进行group by或order by操作。

background_pool_size：后台线程池的大小，默认值为16，转转调整为32。这个线程池大小包含了后台merge的线程数，增大这个参数值是有利于提升merge速度的。

技术原理：在做用户画像数据和行为数据导入的时候，数据已经按照Join Key预分区了，相同的Join Key其实是在同一节点上，因此不需要去做两个分布式表跨节点的Join，只需要去Join本地表就行，执行过程中会把具体的查询逻辑改为本地表，Join本地表之后再汇总最后的计算结果，这样就能得到正确的结果。

服务平台化，故障规范化：提高业务易用性，提升业务治理，比如：资源的多租户隔离，异常用户的限流熔断，以及对ClickHouse精细化监控报警，包括一些慢查询监控；

ClickHouse容器化的部署：支持数据的存算分离，更好的弹性集群扩缩容，扩缩容后自动数据均衡；

服务架构智能化：针对部分业务场景的高并发查询，ClickHouse本身的支持高并发能力比较弱，引入Doris引擎。基于特定的业务场景去自适应的选择ClickHouse或者是Doris引擎；

ClickHouse内核级的优化：包括实时写入一致性保证、分布式事务支持、移除Zookeeper的服务依赖。目前Zookeeper在ClickHouse数据达到一定量级是存在瓶颈的，所以移除Zookeeper服务依赖是迫切和必然的。

在巨大的数据量面前，想追求极致的性能及全部场景适应性，必须在某些技术方案上进行取舍。ClickHouse从底层列式存储到上层向量化并行计算，都没有考虑存算分离、弹性扩展的技术方案，甚至于横向扩容数据需要手动re-balance。因此，如果要实现云上的可动态伸缩、存算分离，ClickHouse需要重构底层代码。