引言

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