引言

极光开发者服务为移动 app 开发者提供各种丰富可靠高效的开发者产品服务，面对不同产品服务的业务数据分析统计诉求，如何在千亿级的海量数据中实现多维分析和 ad-hoc 即席查询，为开发者提供高效、精准的数据分析查询服务成为极光面临的问题。

极光大数据服务团队通过对 ClickHouse 的深入探索实践表明，ClickHouse 比较完美解决了查询瓶颈，单表十亿级别数据量级查询，95%可以在毫秒级别（ms）完成计算返回结果。

极光开发者服务数据分析需求

极光开发者服务包括推送、统计、认证、魔链、IM、短信等产品服务，随着业务发展，每天有上百万个 app 使用，为 14 亿级月活终端用户提供各类移动应用服务，每天产生千亿级记录，而且每个产品服务依据自身业务特点，对数据分析有不同要求，涵盖基础用户统计分析、推送统计分析、认证消耗分析、页面流分析、留存分析、终端分析、事件分析、用户行为路径分析、用户画像分析等业务分析模块，涉及的数据指标多达 500+，这对数据分析和 BI 指标统计提出了挑战。极光服务中典型的数据分析需求有如下几类：

极光推送产品的「消息实时统计」，开发者希望以小时为维度实时查看消息下发、送达和点击等数据，以判断消息下发进度。

极光推送产品的「消息转化漏斗」，开发者希望从 APP 应用维度和单条消息维度，分别查看推送消息的转化数据，同时希望可以支持平台、通道和消息类型等维度筛选。

极光推送产品的「消息折损分析」，开发者希望从 APP 应用维度和单条消息维度，分别查看消息折损的原因和类别，能够查看在不同消息发送阶段的折损数量。

极光运营增长产品的「精准人群计算与人群预测」，运营人员自定义条件规则圈选目标人群，人群需要例行计算出人群包用与运营触达服务。同时还希望使用极光 AI 服务预测潜在沉默人群、潜在高价值人群用于提前干预运营。

极光运营增长产品的「运营计划实时监控」，运营人员希望创建完成运营计划后，可以实时查看运营计划的用户消息触达、用户目标达成率等数据，以便于随时优化和干预运营计划，确保运营目标的达成。

极光运营增长产品的「营销分与智能标签」，运营人员基于可视化规则创建的营销分和智能标签，需要例行计算以便更新用户数据，用于支撑营销运营策略。

技术选型和演进

极光开发者服务数据分析的技术选型和演进主要分为 3 个阶段，第一阶段业务早期数据量较少，直接在 Mysql 数据库中存储就可以满足分析查询需求；第二阶段随着业务发展，数据规模越来越大，要借助 Hbase、Kylin 的一些 nosql 组件，对数据建模，实现多维度预计算；第三阶段数据持续增加和维度爆炸，预计算成本和可维护性越来越差，这时就需要一种支持海量数据存储、查询灵活、高效且运维成本较低的 OLAP 数据库。

经过对主流 OLAP 组件对比调研发现，ClickHouse 有三个特征满足极光开发者服务数据分析使用要求：

01、支持列式存储和数据压缩

为了实现支持单表百亿数据集中查询分析时，能够灵活选择各种维度组合并且秒级返回执行结果，ClickHouse 按列存储的特性便可以极大提升数据查询的效率，因为按列存储与按行存储相比，前者可以有效减少查询时所需扫描的数据量，如果数据按行存储，数据库首先会逐行扫描，并获取每行数据的所有字段，再从每一行数据中返回查询所需要的字段，导致会扫描所有的字段。如果数据按列组织，数据库可以直接获取想查询的列的数据，从而避免了多余的数据行扫描。

ClickHouse 采用的压缩算法可以将列的数据进行压缩处理，数据中的重复项越多，则压缩率越高；压缩率越高，则数据体量越小；而数据体量越小，则数据在网络中的传输越快，对网络带宽和磁盘 I/O 的压力也就会进一步地变小，并且支持 LZ4、ZSTD 压缩算法，其中 ZSTD 可以提供极高压缩比，节省大量存储空间。

02、MPP 架构

MPP ( Massively Parallel Processing)，即大规模并行处理，在数据库集群中，每个节点都有独立的磁盘存储系统和内存系统，业务数据根据数据库模型和应用特点划分到各个节点上，每台数据节点通过专用网络或者商业通用网络互相连接，彼此协同计算，作为整体提供数据库服务。ClickHouse 是一款 MPP(Massively Parallel Processing)架构的列式存储数据库，支持大规模并行处理，以多主对等的扁平架构，保证了海量数据在各个节点的分布式存储。并且充分发挥单节点性能，提供了极高的能效比。

03、高性能表引擎+向量执行+高效索引

为了高效的使用 CPU，数据不仅仅按列存储，同时还可利用 SIMD 指令进一步加速执行效率，这部分是 ClickHouse 优于大量同类 OLAP 产品的重要因素；

主键索引采用排序+稀疏索引结构，只要过滤条件在索引列中包含即可触发索引快速查询，即使作为过滤条件的数据不在索引中，由于各种并行处理机制 ClickHouse 全表扫描的速度也很快，列式存储用于减少不必要的字段读取，而索引则用于减少不必要的记录读取。ClickHouse 同时支持丰富的二级索引，支持跳表结构、Bloom Filter 等过滤功能，从而在查询时尽可能的减少不必要的记录读取，提高查询性能。

开发者服务数据分析架构

架构设计特点：

对比 Lambda 架构，采用 ZooKeeper 将实时和离线作为统一存储，很大程度上规避了 Lambda 架构上实时和离线分离维护复杂度高的问题，数据完整性、一致性、准确性、时效性得到极大提高；

对比 Kappa 架构，避免了重度依赖消息队列，数据查询和计算性能可靠稳定性得到保证；

支持 SQL 查询语法，配合 Native、Jdbc 多种服务接口，ZooKeeper 通过多项技术优化实现高效 OLAP 执行查询；

支持实时批量插入数据和离线文件导入，即满足现网实时流秒级 ad-hoc 即席查询，同时离线导入海量预计算指标数据文件，满足大时间范围指标快速查询，为业务提供最佳 SLA 上卷下钻查询服务；

提供丰富高效的数据结构类型和功能函数，满足快速开发实现各种业务数据分析场景；

组网设计

ClickHouse 不同于 Elasticsearch、HDFS 这类主从架构的分布式系统，它采用多主（无中心）架构，集群中的每个节点角色对等，客户端访问任意一个节点都能得到相同的效果。

ClickHouse 借助分片将数据进行横向切分，而分片依赖集群，每个集群由 1 到多个分片组成，每个分片对应了 ClickHouse 的 1 个服务节点；分片数量的上限取决于节点数量（1 个分片只能对应 1 个服务节点）。ClickHouse 提供了本地表与分布式表的概念；一张本地表等同于一个数据分片。而分布式表是张逻辑表，本身不存储任何数据，它是本地表的访问代理，其作用类似分库中间件。借助分布式表，能够代理访问多个数据分片，从而实现分布式查询。

ClickHouse 的数据副本一般通过 ReplicatedMergeTree 复制表系列引擎实现，副本之间借助 ZooKeeper 实现数据的一致性，在生产环境一般是分布式表提供查询服务，本地表提供写入功能，实现读写分离。

综上所述，生产环境高可用组网方式：

部署 ZooKeeper 集群，支持 ClickHouse 分布式 DDL 执行、ReplicatedMergeTree 表主备节点之间的状态同步功能；

部署 Chproxy 集群，为外部查询提供代理功能，提供多种能力：

将 ClickHouse 集群划分为多个逻辑集群，不同逻辑集群按需进行配置；

Chproxy 节点都是无状态模式，上层可以挂在负载均衡（loadbalancing），可做到 Chproxy 层面的高可用，也可横向扩展业务能力；

对逻辑用户进行查询、访问、安全等限制，并支持缓存结果；

ClickHouse 采用分布式表+集群分片方式，实现表存储高可用和负载均衡；

性能测试

选用了 ClickHouse 官方提供的一个测试方案：SSB(Star Schema Benchmark)

https://clickhouse.com/docs/en/getting-started/example-datasets/star-schema

测试服务器选取中等配置：

cpu:16 核 Intel(R)Xeon(R) Gold 6278C CPU @ 2.60GHz；

内存：32GB；

超高速云盘（350MB/s）：500GB；

数据盘采用 ext4 文件系统，ioscheduler 采用 deadline 方式；

使用 dbgen 生产 6 亿数据，导入 test 库中：

测试结果如下：

扫描 6 亿数据执行查询分析 SQL，时间消耗保持在 10 秒以下，性能已经非常出众，满足产品业务要求。

经验分享

ZooKeeper 集群生产环境建议采用 3.6.x 以上版本，集群采用 5 节点，配置文件使用 ClickHouse 推荐配置参数，采用 supervisor 保活，尽量保证 ZooKeeper 集群运行稳定可靠；

生产环境建议采用高配置服务器，推荐内存和存储空间（压缩后）比 1:50，存储采用 ssd，对比机械硬盘读写可以提高 10 倍以上，如果考虑成本可以采用 zstd 压缩和冷热数据分级存储；

Hive 导入 ClickHouse，推荐使用 Apache Seatunnel，开发简单稳定高效；

离线预决算指标结果文件导出为 Parquet 格式，并且按照 ClickHouse 表分区方式拆分文件，文件内数据按照 orderby 字段排序，满足 TB 级别数据 1 小时导入；

实时写入批量建议大于 20 万条，并且按照表分区拆分，数据按照 orderby 字段排序，这样导入效率极高，减少分区排序消耗；

推荐生产环境分布式表提供查询服务，本地表提供写入功能，实现读写分离；

不同用户账号查询并发数使用 max_concurrent_queries_for_user 实现控制，避免出现某个账号占用所有查询资源，其他账号无法得到资源保证；

建议增加 groupby 或者 sort 的磁盘溢出功能，配置 max_bytes_before_external_group_by 和 max_bytes_before_external_sort 参数，提高查询稳定性；

数据去重查询建议采用 ReplacingMergeTree+Final 查询，实现数据精准去重；

数据更新不同场景可以采用不同方案，单条更新可以参考数据去重实现方式，批量更新可以采用先删后写方式实现，这里要注意删除采用同步删除并且设置 insert_deduplicate=0；

启动字典表和低基数字典功能，可以提高维度字典关联速度和减少存储；

物化视图和 projection 可以实现多种维度排序组合加速查询，但是需要更多空间和消耗部分服务器性能，简单理解为空间换时间；

udf 实现支持 3 种方式，推荐选择 2：

lambda 语法内建 udf，实现简单，但是功能受限；

配置

user_defined_executable_functions_config，导入外部程序实现 udf 功能，通过开发独立脚本或者程序实现复杂处理功能；

修改源码，直接加入 udf 函数，需要较高人力成本投入，运维复杂高；

维度变化较少的指标，建议使用预计算实现历史数据计算，这样可以提高查询效率，如果出现查询 OOM 情况，在没有办法增加资源情况下，建议缩短查询范围，分解为多次查询再聚合结果；

尽量避免大表之间 JOIN，如果确实无法避免，可以考虑采用分区分桶实现，本地化 JOIN 结果再聚合，避免全局 JOIN 内存不足；

数据迁移可以按照分区方式导出为 native 格式文件，采用离线加载方式导入；

ClickHouse、ZooKeeper、Chproxy 可以通过 Prometheus+Grafana 实现监控告警。

ClickHouse 集群监控：

ZooKeeper 集群监控：

Chproxy 集群监控：

未来规划

ClickHouse 集群维护开发工具，提高集群扩缩容、数据迁移等操作效率；

ClickHouse-keeper 代替 ZooKeeper，简化组网部署，提高服务稳定性和可维护性；

ClickHouse 采用 RBAC 实现精细化访问控制；

ClickHouse 容器化+存算分离探索。

关于极光

极光（Aurora Mobile，纳斯达克股票代码：JG）成立于 2011 年，是中国领先的客户互动和营销科技服务商。成立之初，极光专注于为企业提供稳定高效的消息推送服务，凭借先发优势，已经成长为市场份额遥遥领先的移动消息推送服务商。随着企业对客户触达和营销增长需求的不断加强，极光前瞻性地推出了消息云和营销云等解决方案，帮助企业实现多渠道的客户触达和互动需求，以及人工智能和大数据驱动的营销科技应用，助力企业数字化转型。