原标题:极光笔记 | 极光clickhouse千亿级数据分析实践之路

引言

极光开发者服务为移动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年,是中国领先的客户互动和营销科技服务商。成立之初,极光专注于为企业提供稳定高效的消息推送服务,凭借先发优势,已经成长为市场份额遥遥领先的移动消息推送服务商。随着企业对客户触达和营销增长需求的不断加强,极光前瞻性地推出了消息云和营销云等解决方案,帮助企业实现多渠道的客户触达和互动需求,以及人工智能和大数据驱动的营销科技应用,助力企业数字化转型。返回搜狐,查看更多

责任编辑:

作者 nasiapp

在线客服
官方客服
我们将24小时内回复。
12:01
您好,有任何疑问请与我们联系!

选择聊天工具: