指南公司每天都会产生海量的数据，根据业务需求生成各种分析报告，但是海量的数据加上复杂的数据模型和个性化的分析维度，传统的离线预计算方式难以灵活支持。因此，需要引入满足实时多维分析场景的计算引擎框架，以支撑业务精细化运营场景。本文将分享ClickHouse在自助分析场景的探索与实践。文章将从以下四个方面进行介绍：自助分析场景OLAP技术选型Gaussian平台自助分析场景ClickHouse优化实践ClickHouse未来规划及展望1.自助分析场景OLAP技术选型1.1背景转转平台主要分析业务运营数据（埋点）。埋点数据包括在售商品的曝光、点击、展示等事件。覆盖场景数据量大，部分分析场景需要支持精准去重。数据量大加上去重、数据分组等计算，使得统计过程中指标的计算量更大。此外，在一些数据分析场景中，需要计算留存率、漏斗转化等复杂的数据模型。虽然一般指标在离线数仓的数仓层和汇总层进行了预计算，但由于这些模型的分析维度通常是不确定的，预计算无法满足产品或运营提出的个性化报表需求，需要分析师或数据仓库工程师开发SQL，导致数据开发环节长，交付慢，数据价值随时间递减。作为分析平台，不仅要保证数据的及时性和架构的高可用，还要在任何维度、任何指标上做到秒级响应。基于以上情况，需要一个ad-hoc查询引擎来实现。1.2OLAP选择的考虑因素OLAP引擎的选择主要考虑三个方面：性能、灵活性和复杂性。性能：数据级别（亿/百亿/千亿等）数据计算反馈时效性（毫秒/秒/分钟）灵活性：是否可以支持聚合结果或详细数据查询，或两者都支持数据链接可以支持离线数据和实时数据的摄取是否支持高并发即席查询复杂度：架构简单，运维难度低，可扩展性低几种开源OLAP引擎：OLAP引擎主要分为两类：优势基于预计算的MOLAP引擎的优点在于它对整个计算结果进行预计算，查询比较稳定，可以保证查询结果的亚秒级或秒级响应。但由于依赖预计算，查询的灵活性相对较弱，无法统计预计算以外的数据。代表是麒麟和德鲁伊。基于MPP架构的ROLAP引擎可以支持实时数据采集和实时分析。查询场景灵活，但查询稳定性较弱，取决于操作的数据量级和资源配比。基于MPP架构的OLAP一般都是基于内存的。对，代表就是Impala和Presto。Kylin使用的技术是完全预聚合的cube，可以提供更好的SQL支持和join能力，查询速度基本是亚秒级响应。同时，Kylin有很好的web管理界面，可以监控和使用cube。但是当维度很多，交集深度很深的时候，底层的数据就会爆发式的膨胀。而且，Kylin的查询灵活性比较弱，这也是MOLAP引擎的通病。Druid使用位图索引、字符串编码和预聚合技术，可以实时摄取数据，支持高可用和高并发查询。但对OLAP引擎分析场景的支持能力较弱，加入能力不成熟，无法支持。需要精确去重计算的场景。Impala支持窗口函数和UDF。查询性能相对较好，但对内存依赖较大，Impala的元数据存储在HiveMetastore中，需要与Hadoop组件紧密结合。对于实时数据的摄取，一般使用Kudu。存储引擎进行DML操作，多系统架构的运维也比较复杂。Presto可以跨数据源进行联合查询，支持多表join，但在高并发场景下性能较弱。ClickHouse具有很强的单机性能。基于列式存储，可以使用向量化引擎实现并行计算。查询基本上是毫秒级或秒级反馈。但是ClickHouse没有完整的事务支持，对分布式表的join能力比较弱。虚弱的。Doris易于运维，易于扩缩容，支持事务。但是Doris版本更新快，不够成熟，没有ClickHouse自带的漏斗，留存等功能，不足以支持业务场景。基于以上考虑，最终选择ClickHouse作为分析引擎。1.3ClickHouseClickHouse是一个开源的基于列式存储的实时在线分析处理的分析引擎。2016年在俄罗斯开通，底层开发语言为C++，可支持PB数据级分析。ClickHouse具有以下特点：具有完整的dbms功能和比较完善的SQL支持。基于列式存储和数据压缩，支持索引。矢量化引擎和SIMD提高CPU利用率，可基于大数据集进行多核多节点并行计算，提供亚秒级查询响应。支持数据复制和数据完整性。多样化的表引擎。ClickHouse支持Kafka、HDFS等外部数据查询引擎，以及MergeTree系列引擎和Distribute分布式表引擎。ClickHouse的查询场景主要分为四类：交互式报表查询：可以基于ClickHouse构建用户行为特征的宽表，秒级给出计算反馈，进行多维度、多指标的计算。用户画像系统：在ClickHouse中构建广泛的用户特征表，支持用户详细搜索、分组选择等。AB实验的数据可以秒级给出。监控系统：通过Flink实时采集业务指标和系统指标数据，写入ClickHouse，结合Grafana进行指标展示。2.高斯平台自助分析场景2.1系统介绍高斯平台核心功能主要包括两部分：埋点数据管理：埋点元数据管理、埋点元数据质量监控与告警；自助分析：基于业务特点和多部门复合需求，提供多维度、多指标交叉分析能力，可支持用户画像标签选择、人群圈选择、ABTEST等分析功能，全面支持日常数据分析需求。2.2系统架构下图为Goss平台的系统架构，分为四层：数据采集层：数据源主要是业务库和嵌入式数据。业务数据库数据存储在MySQL中，嵌入的数据通常是LOG。MySQL业务数据库的数据通过Flink-CDC实时抽取到Kafka；LOG日志由FlumeAgent收集，分发到实时和离线通道。数据存储层：主要存储来自数据采集层的数据。Kafka和HDFS用于存储。ClickHouse基于底层数据清洗和数据访问实现了宽表存储。数据服务层：对外封装HTTP服务，由外部系统调用，内部提供基于SQL的客户端工具。数据应用层：主要是基于ClickHouse的高斯自助分析平台和用户画像平台两个产品。高斯分析平台可为用户进行事件分析，计算PV、UV等指标，以及留存、LTV、漏斗分析、行为分析等。用户画像平台提供人群选择、用户审核等功能。2.3ClickHouse在高斯平台的业务场景（1）行为分析业务背景：在App线上活动的特殊页面，业务方想查看活动页面上线后点击各个坑的效果。技术实现：采用ClickHouse的物化视图、聚合表引擎、明细表引擎。ClickHouse的物化视图可以做实时的数据累加计算，POPULATE关键字决定了物化视图的更新策略。在创建物化视图时使用POPULATE关键字时，物化视图的计算会在底层表的历史数据上进行。技术实现：采用ClickHouse的物化视图、聚合表引擎、明细表引擎。ClickHouse的物化视图可以做实时的数据累加计算，POPULATE关键字决定了物化视图的更新策略。在创建物化视图时使用POPULATE关键字时，物化视图的计算会在底层表的历史数据上进行。（2）AB-TEST分析业务背景：AB-TEST早期使用传统的T+1天数据，但T+1天数据已经不能满足业务需求。技术方案：Flink实时消费Kafka，自定义Sink（支持配置自定义Flush批量大小和时间）到ClickHouse，使用ClickHouse计算实时指标。3.ClickHouse的优化实践3.1内存优化数据分析过程中常见的问题大多与内存有关。如上图所示，当内存使用量超过单台服务器的内存限制时，就会抛出这个异常。解决这个问题需要分析SQL语句和SQL查询的场景：如果在计算count和disticnt时内存不足，可以使用一些估计函数来降低内存占用，提高查询速度；如果SQL语句是groupedBy或者orderby操作，可以配置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：groupby和orderby使用超过内存阈值后，预写磁盘进行groupby或orderby操作。background_pool_size：后台线程池的大小，默认值为16，调整为32。这个线程池大小包含了后台合并线程的数量。增大该参数值有利于提高合并速度。3.3亿级数据JOIN技术原理：在导入用户画像数据和行为数据时，数据已经按照JoinKey进行了预分区，同一个JoinKey其实是在同一个节点上，不需要创建两张分布式表跨节点join，只需要join本地表即可。在执行过程中，具体的查询逻辑会更改到本地表中。加入本地表后，会对最终的计算结果进行汇总，从而得到正确的结果。4.ClickHouse未来规划与展望4.1ClickHouse应用实践痛点ClickHouse的高并发能力特别弱，官方推荐QPS在100/秒左右。当有高并发查询时，ClickHouse的性能会明显下降。ClickHouse不支持事务性DDL和其他分布式事务。复制表引擎的数据同步状态和分片的元数据管理都强烈依赖于Zookeeper。一些应用场景需要实时的行级数据更新和删除操作，而ClickHouse缺乏完备的操作支持。ClickHouse缺乏自动重平衡机制，数据迁移需要在扩缩容时手动平衡。4.2未来规划与展望服务平台化与故障标准化。提高业务易用性和业务治理，比如资源的多租户隔离，异常用户的限流和熔断，ClickHouse的细粒度监控和告警，包括一些慢查询监控。ClickHouse容器化部署。支持数据的存储和计算分离，更好的弹性集群扩缩容，扩容后数据自动均衡。智能服务架构。针对一些业务场景的高并发查询，ClickHouse对高并发的支持能力比较弱，引入了Doris引擎。根据具体业务场景自适应选择ClickHouse或Doris引擎。ClickHouse内核级优化。包括实时写一致性保证、分布式事务支持、去除Zookeeper服务依赖。目前Zookeeper在ClickHouse数据达到一定程度时会出现瓶颈，因此解除Zookeeper服务依赖是当务之急，也是必然的。五、总结本文主要分享：OLAP分析技术生态迁移自助分析平台底层架构原理ClickHouse调优方案落地实践ClickHouse应用痛点及未来规划与展望面对庞大的数据量，我想追求极致性能和整体场景适应性在一些技术方案中必须要进行权衡。从底层的列式存储到上层的向量化并行计算，ClickHouse没有考虑存储计算分离和弹性扩展的技术方案，甚至数据的横向扩展都需要人工重新平衡。因此，如果要在云端实现动态扩展和存储计算分离，ClickHouse需要对底层代码进行重构。未来，转转会持续优化痛点，为大家输出更多的技术实践。原文地址：https://mp.weixin.qq.com/s/TQQqgF15Dct9w_86Rsbijg
