小迈科技 X Hologres:高可用的百亿级广告实时数仓建设

简介: 通过本文,我们将会介绍小迈科技如何通过Hologres搭建高可用的实时数仓。

通过本文,我们将会介绍小迈科技如何通过Hologres搭建高可用的实时数仓。


一、业务介绍

小迈科技成立于 2015 年 1 月,是一家致力以数字化领先为优势,实现业务高质量自增长的移动互联网科技公司。始终坚持以用户价值为中心,以数据为驱动,为用户开发丰富的工具应用 、休闲游戏 、益智 、运动等系列的移动应用 。以成为全球领先开发者增长服务平台为愿景及使命,小迈希望通过标准化的产品和服务赋能,为开发者提供全链路解决方案,以技术+服务全方位保驾护航,助燃产品持续增长,帮助工具和休闲游戏的开发者提升产品的成功率。

小迈科技累计开发 400 余款产品,累计用户下载安装量破七亿 ,日活500-1000w,数据量每天 100 亿+。围绕高质量APP、用户增长和商业化变现,公司通过大数据技术相继搭建了商业化变现、智能推广、财务管理等10+应用系统。但用户量指数级增长,业务团队对数据实时化、精细化的要求提升,大数据系统开始备受挑战,如何更好的通过数仓建设为业务增长赋能成为重要突破点。


二、小迈数仓发展历程:从神策到流批一体实时数仓

为了满足业务团队的数据需求,小迈大数据技术团队从业务发展早期就开始建设数仓系统,从传统的神策阶段过渡到离线数仓,再发展到如今稳定的流批一体实时数仓共经历了3个阶段,从业务和技术的挑战中,不断对数仓系统进行迭代优化,从而支撑业务快速增长。下面将会进一步介绍小迈的大数据平台发展历程:

1、神策阶段

在最原始的阶段,业务系统基于神策实现。APP数据直接接入神策,初期只能看到APP内的行为数据, 以及广告数据,分析能力有限,不够灵活,无法自定义处理,不能和第三方数据进行整合分析,无法满足业务进一步要求。但因为业务还是起步阶段,数据平台的建设以满足现有业务需求为主,如果业务有特殊需求,再单独搭建对应的分析系统。

2、离线数仓(引入MaxCompute)

随着公司业务的不断发展,服务的用户越来越多,数据量指数级增长,对应的业务系统越来越多,每个系统之前也是割裂的,并且系统稳定性开始面临巨大挑战。基于神策的局限性,业务开始引入阿里云的MaxCompute、DataWorks和某分布式数据库(以下简称某DB)搭建离线数仓。业务的主要流程:

  1. 通过JDBC的方式拉去神策罗盘服务器,并通过DataWorks将数据离线同步至MaxCompute;
  2. 在MaxCompute中通过数仓四层建模(ODS、DWD、DWS、ADS),结果数据通过DataWorks离线同步至某DB;
  3. 在某DB中对接业务系统的各种分析需求。

离线数仓的引入基本满足了整个公司各个角色的分析决策,但随着业务的不断发展,会出现以下问题:

  • 系统间通过神策系统以JDBC的方式拉取数据,过度依赖第三方神策,过于耦合,神策出问题的时候,整个计算流程无法继续,无法满足业务的敏捷分析需求。神策恢复之后,手动参与重新跑数据,浪费了许多人力。
  • 数据统计完之后,数据入库慢,大大影响了整个链路的跑数时间,而业务对数据计算的实时性要求越来越高,现阶段无法支撑。
  • 数据量呈现指数级别的增长,分析维度越来越多,结果数据基本达到了明细数据级别,现有的数据查询引擎某DB不足以支撑这么大数据的多维度分析,面临最大的挑战就是对百亿级规模的行为数据做低延迟、高QPS的查询分析。
  • 为了解决查询引擎不足以支撑大数据量查询的问题,因此数据做了很多的前置计算,造成计算冗余,成本上升。
  • 同时系统越来越多,导致运维成本、开发成本也随之线性增长,导致无法快速满足业务的各种诉求。

由于上面阐述的痛点,导致频繁出现的现象就是数据产出变慢,经常卡死,严重影响业务决策,经常被业务部门投诉,影响极其不好。基于此,技术部门迫切需要找到解决方案。

3、流批一体实时数仓(引入Hologres+Flink)

为了更好的解决业务诉求,第三阶段在原有基础上引入了阿里云的Hologres和Flink,并由Hologres替换某DB,搭建了流批一体的实时数仓。主要数据链路如下:

1、日志数据和业务数据Kafka通过DataWorks实时同步写入MaxCompute,实时落地ODS层;对于数据时效性要求较要的业务,直接写入Flink,Flink里面进行实时ETL处理,然后写入Hologres。

2、三方数据则是通过DataWorks离线同步至MaxCompute,在MaxCompute中进行数仓分层(ODS、DWD、DWS、ADS)建设,并将处理好的数据直接写入Hologres。

3、由Hologres存储实时和离线数据,并直接对接上层应用,承载业务系统的多种查询要求,实现流批一体的实时数仓。

小迈1.png


通过第三阶段Hologres+Flink+MaxCompute的流批一体实时数仓建设,已经成功支撑小迈科技的众多业务,包括数据化运营,BI,数据接口,业务中台等。新架构带来的好处有:

  • 数据结构化更清晰:对于不同层级的数据,它们的作用域不相同,每一个数据分层都有其作用域,这样业务在使用表的时候能更方便地定位和理解。
  • 数据血缘追踪:提供给业务使用的是一张业务表,但是这张业务表可能来源很多张表。如果有一张来源表出问题了,我们可以快速准确的定位到问题,并清楚每张表的作用范围。
  • 减少重复开发:数据分层规范化,开发一些通用的中间层数据,能够减少重复计算,提高单张业务表的使用率。
  • 简化复杂的问题:把一个复杂的业务分成多个步骤实现,每一层只处理单一的步骤,比较简单和容易理解。而且便于维护数据的准确性,当数据出现问题之后,可以不用修复所有的数据,只需要从有问题的步骤开始修复。有点类似Spark RDD的容错机制。
  • 减少业务的影响:业务可能会经常变化,这样做就不必改一次业务就需要重新接入数据。
  • 数据更加实时,业务决策更加迅速。
  • 数据与第三方进行解耦,稳健性更强。


三、为什么选择Hologres?

选择Hologres是我们从多个方面调研以及测试验证的结论。下面我们将结合业务从技术和使用场景两个方面讲述选择Hologres的原因。

1、支持高性能写入和极速复杂查询

最开始我们分别基于某DB和Hologres进行了性能验证,核心是针对查询 、写入进行验证, 因为离线数仓阶段,数据库最大的瓶颈就是查询性能和写入性能。

  • 查询性能: 基于目前实际的业务场景,包括简单及复杂 SQL进行查询性能验证,前期未做优化表现差不多,后面对Hologres的表设计和底层优化,我们验证出Hologres基本能有4倍左右的提升,后面也会跟阿里的同事一起做更多性能调优工作。
  • 写入性能:之前在某DB 的环境上,MaxCompute写入某DB的时间非常长(1 亿数据一个小时左右),特别是查询业务上来后, 写入性能有几倍的降速 ,甚至会宕机。而写入MaxCompute数据至Hologres的性能表现非常强悍, 1个亿的数据导入10多秒左右即可完成。

2、满足多个分析场景

结合MaxCompute+Hologres+Flink搭建的流批一体实时数仓,使得我们的系统应用场景更加丰富,主要包括:

  • 实时数仓: 由于Hologres 与 Flink 集成性好,通过实时的采集数据,Flink实时计算,直接将数据写到入 Hologres 中,就能实时构建实时大屏 、实时监控预警 、实时推荐 、实时训练等应用,快速响应业务需求。
  • MaxCompute加速查询:Hologres 可以直接通过外表的方式,对 MaxCompute 的数据进行查询,如果需要更高的性能,则可以将数据导入到 Hologres 中更高性能的查询处理。如果是前一种方式,则可以在数据不输出的情况下,对离线数据进行查询分析。
  • 自适应广告分析场景:Hologres有很多丰富的分析函数,比如留存分析函数和漏斗分析函数,这对广告业务的相关场景非常适用,无需我们二次开发,直接就能使用。


综上所述,无论从性能支撑还是使用场景都非常符合我们公司的业务需求。


四、百亿级用户行为分析最佳实践

用户行为是指用户在产品上产生的行为,通过对用户行为的分析,为提供下一步运营运策略提供辅助决策,同时也为产品迭代和发展提供方向。用户行为分析在互联网公司是非常普遍的一种场景,但大多数业务其核心痛点就是用户数据量大,计算逻辑复杂,导致计算性能不够好,往往不能及时拿到计算结果,从而影响下一步决策。

小迈在广告人群数据分析这个场景上,数据量约有上百亿,并且有很多的数亿行大表关联查询场景,之前的系统计算比较吃力,经常受到业务质疑。在现在的系统上,我们通过对Hologres中表的索引设计和性能调优,已经能达到非常明显的性能效果,下面我们具体介绍如何实现。

用户行为分析的流程如下:

1、MaxCompute中存放收入表income_dt_test,小时周期调度至Hologres结果表holo_ad_income_dt_test

2、Hologres存储用户行为表holo_dws_usr_label_df,通过Maxcompute周期性调度写入。

4、在Hologres中对两张表做关联Join计算,进行人群分析,示例分析SQL如下:

小迈2.png


结合业务场景对表和SQL做了如下优化操作:

1.因为用户收入表和用户行为表需要做关联查询,因此设置分布字段distribution_key,保证相同的记录会被分配到同一个shard上,尽最大可能减少shuffle,尽量Local Join,所以设置以下分布键,大大提高了关联查询的速度,

CALL set_table_property('holo_dws_usr_label_df','distribution_key','product_id,device_id');CALL set_table_property('holo_ad_income_dt_test','distribution_key','product_id,device_id');

2.因为报表筛选经常使用product_id、ad_id、position_id 三个字段,而bitmap_columns的使用场景就是等值查询,所以把这三个字段设置为bitmap_columns

CALL  SET_TABLE_PROPERTY('public.holo_ad_income_dt_test','bitmap_columns','"product_id:on","ad_id:on","position_id:on"');

3.粗略估算每天的增量数据在1亿左右,因此设置为分区表,提高查询速度,数据量较小的时候不太建议设置分区,否则会影响查询性能。

4.在用户数去重的时候,需要用到大量count(distinct a.device_id),但是会消耗很多的资源,因此我们改用APPROX_COUNT_DISTINCT (a.device_id) 方式,性能提升很多,但是会丢失一定的精度,通过参数

set hg_experimental_approx_count_distinct_precision=20调节精度。


通过对表结构和SQL的优化,我们的广告人群数据分析能够实现秒级响应,大大提升了计算效率,也能快速响应业务需求。


五、Hologres读写分离高可用实现

1、优化背景:读写不分离相互影响

随着迁移到Hologres的业务越来越多,写入任务的频率越来越高,在高峰期实例开始出现查询异常和写入任务报错的情况。具体原因主要有:

  1. 每天上午十点左右是离线(T+1)任务写入的高峰期,在这个时间段大量报表统计任务聚集,对Hologres写入操作占用资源很多。
  2. 其中部分写入任务的数据量特别大,天增量的结果数据达到了几亿条,写入时间长,持续占用资源。而又有部分结果表字段数太多,达到了一千多个,消耗资源较多。
  3. 写入的同时,有部分MaxCompute读取Hologres外表的任务,造成连接数使用上涨,影响其他任务。
  4. 出报表的时间段也是是业务进行查询的高峰期,大量写入的同时有大量的查询在同时执行,相互影响。
  5. 写入任务存在自动重试机制,每次oom、timeout或其它异常报错时,任务会自动重跑占用资源,导致大面积的写入任务异常越来越多。


2、优化手段:Hologres共享存储实例部署

在这种情况下,我们对Hologres实例做了一些调整和优化,配置了Hologres的共享存储多实例,把读和写分离,将一个读写实例调整为一个主实例读写以及一个只读从实例,两个实例共用一份存储:

  • 将业务分成不同模块,同时将报表后台、tableau、生产业务等模块的只读查询迁移到只读从实例
  • 同步任务和少量的读写任务保留在读写主实例,不同模块数据存放在不同的schema,方便管理。

调整前:

小迈3.png

调整后:

小迈4.png

与此同时我们还根据业务现状做了一些其他优化,包括:

1、大写入任务增加session级的超时时间设置:set statement_timeout = 'Xmin' ;

2、写入之前对外表和内表进行ANALYZE ,更新统计信息加速写入;

3、取消Hologres写入任务的自动重试机制,避免影响后续的其它写入任务;

4、减少非必要的MaxCompute读取Hologres外表数据的操作,降低连接数的使用;

5、某几个数据量特别大的表,错开写入和查询高峰期,调整为其它时间段写入;


3、优化效果:系统稳定性显著提升

通过Hologres的读写分离实例部署和相关写入优化后,写入任务不再对查询任务造成影响,报表等系统能提供稳定的查询服务,同时写入任务资源使用和分配也更合理,不再出现oom之类的写入异常,系统服务稳定性有较大的提升。

后续,我们将会尝试把不同模块业务拆分到不同的只读实例,进一步增强服务的稳定性,带给服务使用方更好的体验。

六、业务价值

通过Hologres+Flink+MaxCompute搭建的流批一体实时数仓平台,支撑了小迈多个应用场场景,包括监控大盘,DMP人群等智能投放,财务分析等。显著的业务收益有:

1、上层服务共享数据

数据共享之后就由平台统一对外输出服务,各个业务线无需自行重复开发,就能快速得到平台提供的数据支撑,减少了数据孤岛。

2、亿级复杂查询秒级响应

通过Hologres自身的优秀查询性能,再配合建表和SQL的优化手段,大大提高了报表的响应速度,即使是用户画像、行为分析等亿级大表复杂关联查询也能很快出结果,得到了业务的认可。

3、系统读写分离稳定性强

通过Hologres共享存储实例部署的方式,让业务实现了读写分离,同时也只用了一份存储,既保证了系统的稳定性,同时也不会带来额外的成本压力。


作者:

李云,小迈高级数据仓库开发工程师,数据仓库负责人

雷文,小迈数仓开发工程师;


了解Hologres:https://www.aliyun.com/product/bigdata/hologram

合集.png

相关实践学习
基于Hologres+PAI+计算巢,5分钟搭建企业级AI问答知识库
本场景采用阿里云人工智能平台PAI、Hologres向量计算和计算巢,搭建企业级AI问答知识库。通过本教程的操作,5分钟即可拉起大模型(PAI)、向量计算(Hologres)与WebUI资源,可直接进行对话问答。
相关文章
|
19天前
|
存储 JSON BI
友盟+Hologres:千亿级多维分析平台建设实践
Hologres 在友盟+统计分析、营销等多个产品线使用,很好地满足了用户行为分析、人群圈选与洞察场景的多维度分析、灵活下钻、快速人群预估和圈选等分析需求,提供客户更流畅的数据查询和分析体验。
|
3月前
|
存储 分布式计算 MaxCompute
Hologres RoaringBitmap实践:千亿级画像数据秒级分析
Hologres RoaringBitmap实践:千亿级画像数据秒级分析
369 1
|
4月前
|
SQL 运维 分布式计算
StreamX 在联通数科万亿级实时计算中的生产实践
摘要: 本文源自 StreamX 在联通数科实时计算服务中的生产实践,作者是联通数科大数据负责人穆纯进及其团队,主要内容为: 1. 联通数科实时计算能力要求 2. 实时计算面临的挑战 3. StreamX 在联通数科的深度实践 4. 借助开源、反哺开源
|
6月前
|
存储 分布式计算 MaxCompute
Hologres RoaringBitmap实践,千亿级画像数据秒级分析
本文将会分享Hologres RoaringBitmap 方案在画像分析的应用实践,实现更快更准的画像分析。
|
7月前
|
存储 SQL 分布式计算
云原生数仓AnalyticDB MySQL如何支撑淘系十万亿级数据的实时湖仓一体分析?
数据银行是阿里巴巴集团官方打造的品牌商消费者运营商业数据产品,为品牌商客户提供丰富的消费者分析能力。由于数据银行的消费者数据产品的定位需要在一份海量消费者数据之上实现不同延时要求和计算要求的分析场景,我们基于阿里云AnalyticDB MySQL最新发布的实时湖仓能力,将数据仓库和数据湖割裂的体系进行融合,高性价比的支撑了上万品牌商的分析场景,在10PB+和十万亿级数据规模下,将天级别的数据延迟改善成实时无缝的处理和查询,满足实时数据处理和秒级复杂分析需求(30+张表Join),同时整体成本下降20%+,平稳扛住了2022年双11大促的业务峰值压力。
|
存储 SQL 运维
网易游戏实时 HTAP 计费风控平台建设
在网易互娱计费数据中心开发计费实时风控需求的实践中,基于 Flink 和 TiDB,在实时计算、非结构化存储、HTAP 实践等技术领域做了大量的探索,积淀了不少业界前沿的实践经验,本次演讲旨在与分享和讨论其中的关键技术和最佳实践。
网易游戏实时 HTAP 计费风控平台建设
|
存储 分布式计算 算法
云原生数仓AnalyticDB如何支撑淘系十万亿级数据的实时湖仓一体分析?
数据银行是阿里官方打造的品牌商消费者运营商业数据产品。
云原生数仓AnalyticDB如何支撑淘系十万亿级数据的实时湖仓一体分析?
|
SQL 存储 关系型数据库
PolarDB IMCI助力聚水潭数据中台极致体验,实现百亿级订单实时分析
聚水潭成立于2014年,以电商SaaS ERP切入市场,凭借出色的产品和服务,快速获得市场领先地位。
PolarDB IMCI助力聚水潭数据中台极致体验,实现百亿级订单实时分析
|
SQL 存储 运维
诺亚财富 X Hologres : 统一OLAP分析引擎,全面打造金融数字化分析平台
本文将会介绍诺亚财富从自建CDH迁移上阿里云,统一OLAP分析引擎,打造金融数字化分析平台的最佳实践
1954 0
诺亚财富 X Hologres : 统一OLAP分析引擎,全面打造金融数字化分析平台
|
存储 SQL 分布式计算
小迈科技 X Hologres:高可用的百亿级广告实时数仓建设
通过本文,我们将会介绍小迈科技如何通过Hologres搭建高可用的实时数仓。
小迈科技 X Hologres:高可用的百亿级广告实时数仓建设

相关产品

  • 实时数仓 Hologres