ClickHouse在自助行为分析场景的实践应用

导读

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

• 自助剖析场景OLAP技能选型
• 高斯渠道自助剖析场景
• ClickHouse的优化实践
• ClickHouse未来的规划与展望

一、自助剖析场景OLAP技能选型

1.1 布景

转转渠道首要对业务运营数据（埋点）进行剖析，埋点数据包含在售产品的曝光、点击、展现等事件，覆盖场景数据量很大，且在部分剖析场景需求支撑准确去重。大数据量加上去重、数据分组等核算使得目标在核算过程中运算量较大。除此之外，在一些数据剖析场景中需求核算留存率、漏斗转化等杂乱的数据模型。

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

作为剖析渠道，既需求确保数据时效性、架构的高可用，也要做到任意维度、任意目标的秒级呼应。 依据以上状况，需求一个即席查询的引擎来完成。

1.2 OLAP选型考量

转转对OLAP引擎选型考量有三个方面：功用，灵敏性，杂乱性。

• 功用：

  • 数据量级（亿级/百亿级/千亿级等）
  • 数据核算反应时效性（毫秒级/秒级/分钟级）

• 灵敏性：

  • 能否支撑聚合成果或明细数据的查询，还是两者都支撑
  • 数据链路能否支撑离线数据和实时数据的摄取
  • 是否支撑高并发的即席查询

• 杂乱性：

  • 架构简略
  • 运用门槛低
  • 运维难度低
  • 扩展性强

依据这三个方面的考量，调研了现在干流的几类开源OLAP引擎：

OLAP引擎首要分为两大类：

• 依据预核算的MOLAP引擎的优势是对整个核算成果做了预核算，查询比较稳定，能够确保查询成果亚秒级或者是秒级呼应。但由于依靠预核算，查询的灵敏性比较弱，无法核算预核算外的数据，代表是Kylin和Druid。
• 依据MPP架构的ROLAP引擎能够支撑实时数据的摄入和实时剖析，查询场景灵敏，但查询稳定性较弱，取决于运算的数据量级和资源配比，依据MPP架构的OLAP一般都是依据内存的，代表是Impala和Presto。

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作为剖析引擎。

1.3 ClickHouse

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

• 具有完备的dbms功用，SQL支撑较为完善。
• 依据列式存储和数据压缩，支撑索引。
• 向量化引擎与SIMD进步CPU的运用率，多核多节点并行执行，可依据较大的数据集核算，供给亚秒级的查询呼应。
• 支撑数据复制和数据完好性。
• 多样化的表引擎。ClickHouse支撑Kafka、HDFS等外部数据查询引擎，以及MergeTree系列的引擎、Distribute分布式表引擎。

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

• 交互式报表查询：可依据ClickHouse构建用户行为特征宽表，关于多维度，多目标的核算能秒级给出核算反应。
• 用户画像系统：在ClickHouse里面构建用户特征宽表，支撑用户细查、人群圈选等。
• AB测试：运用ClickHouse的高效存储和它供给的一些自带的函数，如grouparray函数，能够做到秒级给出AB实验的效果数据。
• 监控系统：经过Flink实时收集业务目标、系统目标数据，写到ClickHouse，能够结合Grafana做目标显示。

二、高斯渠道自助剖析场景

2.1 系统介绍

转转高斯渠道的中心功用首要包含两个部分：

• 埋点数据办理：埋点元数据办理，埋点元数据质量监控和告警；
• 自助剖析：依据业务特点和多部分复合需求，供给多维度、多目标的穿插剖析才能，能够支撑用户画像标签挑选、人群圈选，AB TEST等剖析功用，全面支撑日常数据剖析需求。

2.2 系统架构

下图展现了高斯渠道的系统架构，总共分为四层：

数据收集层：数据来源首要是业务库和埋点数据。业务库数据存储在MySQL里，埋点数据通常是LOG日志。MySQL业务库的数据经过Flink-CDC实时抽取到Kafka；LOG日志由Flume Agent收集并分发到实时和离线两条通道，实时埋点日志会sink写入Kafka，离线的日志sink到HDFS。

数据存储层：首要是对数据收集层过来的数据进行存储，存储选用的是Kafka和HDFS，ClickHouse依据底层数据清洗和数据接入，完成宽表存储。

数据服务层：对外统一封装的HTTP服务，由外部系统调用，对内供给了SQL化的客户端工具。

数据使用层：首要是依据ClickHouse的高斯自助剖析渠道和用户画像渠道两大产品。高斯剖析渠道能够关于用户去做事件剖析，核算PV、UV等目标以及留存、LTV、漏斗剖析、行为剖析等，用户画像渠道供给了人群的圈选、用户细查等功用。

2.3 ClickHouse在高斯渠道的业务场景

1、行为剖析

业务布景：App上线活动专题页，业务方想检查活动页面上线后各个坑位的点击的效果。

技能完成：选用ClickHouse的物化视图、聚合表引擎，以及明细表引擎。ClickHouse的物化视图能够做实时的数据累加核算，POPULATE关键词决议物化视图的更新战略。在创建物化视图时运用POPULATE关键词会对底层表的历史数据做物化视图的核算。

2、AB-TEST剖析

业务布景：转转前期AB-TEST选用传统的T+1日数据，但T+1日数据已无法满意业务需求。

技能计划：Flink实时消费Kafka，自定义Sink（支撑装备自定义Flush批次巨细、时间）到ClickHouse，运用ClickHouse做实时目标的核算。

三、ClickHouse的优化实践

3.1 内存优化

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

针对这个问题，需求对SQL句子和SQL查询的场景进行剖析:

• 如果是在进行count和disticnt核算时内存不足，能够运用一些预估函数削减内存的运用量来进步查询速度；
• 如果SQL句子进行了group by或者是order by操作，能够装备max_bytes_before_external_group_by和max_bytes_before_external_sort这两个参数调整。

3.2 功用调优参数

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

• 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速度的。

3.3 亿级数据JOIN

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

四、ClickHouse未来的规划与展望

4.1 ClickHouse使用实践痛点

• ClickHouse的高并发才能特别弱，官方的建议的QPS是每秒100左右。高并发查询时，ClickHouse功用下降比较显着。
• ClickHouse不支撑业务性的DDL和其他的分布式业务，复制表引擎的数据同步的状态和分片的元数据办理都强依靠于Zookeeper。
• 部分使用场景需求做到实时的行级数据update和delete操作，ClickHouse短少完好的操作支撑。
• ClickHouse短少自动的re-balance机制，扩缩容时数据迁移需手动均衡。

4.2 未来规划及展望

• 服务渠道化，故障规范化。进步业务易用性，进步业务管理，比如：资源的多租户隔离，反常用户的限流熔断，以及对ClickHouse精细化监控报警，包括一些慢查询监控。

• ClickHouse容器化的布置。支撑数据的存算别离，更好的弹性集群扩缩容，扩缩容后自动数据均衡。

• 服务架构智能化。针对部分业务场景的高并发查询，ClickHouse自身的支撑高并发才能比较弱，引入Doris引擎。依据特定的业务场景去自适应的挑选ClickHouse或者是Doris引擎。

• ClickHouse内核级的优化。包括实时写入一致性确保、分布式业务支撑、移除Zookeeper的服务依靠。现在Zookeeper在ClickHouse数据到达一定量级是存在瓶颈的，所以移除Zookeeper服务依靠是火急和必定的。

五、总结

本文首要共享了:

• OLAP剖析范畴技能生态
• 转转自助剖析渠道的底层架构原理
• ClickHouse在落地实践过程中的调优计划
• ClickHouse使用痛点及未来规划和展望

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

未来转转会针对痛点进行继续优化，输出更多的技能实践给我们。

关于作者

王鹏哲，转转数据智能部高档数据研发工程师，负责公司高斯自助剖析渠道及实时数据系统建造。

坚信”不为失败找借口，只为成功找办法”。

转转研发中心及业界小伙伴们的技能学习交流渠道，定时共享一线的实战经验及业界前沿的技能话题。

关注大众号「转转技能」（综合性）、「大转转FE」（专心于FE）、「转转QA」（专心于QA），更多干货实践，欢迎交流共享~