引言
极光开发者服务为挪动 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/e… 测试服务器选取中等配置：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 年，是中国当先的客户互动和营销科技服务商。成立之初，极光专一于为企业提供稳固高效的音讯推送服务，凭借先发劣势，曾经成长为市场份额遥遥领先的挪动音讯推送服务商。随着企业对客户触达和营销增长需要的不断加强，极光前瞻性地推出了音讯云和营销云等解决方案，帮忙企业实现多渠道的客户触达和互动需要，以及人工智能和大数据驱动的营销科技利用，助力企业数字化转型。