Hologres+Flink流批一体首次落地4982亿背后的营销分析大屏

本文涉及的产品
实时数仓Hologres,5000CU*H 100GB 3个月
简介: 本篇将重点介绍Hologres在阿里巴巴淘宝营销活动分析场景的最佳实践,揭秘Flink+Hologres流批一体首次落地阿里双11营销分析大屏背后的技术考验。

概要:刚刚结束的2020天猫双11中,MaxCompute交互式分析(Hologres)+实时计算Flink搭建的云原生实时数仓首次在核心数据场景落地,为大数据平台创下一项新纪录。借此之际,我们将陆续推出云原生实时数仓双11实战系列内容,本篇将重点介绍Hologres在阿里巴巴淘宝营销活动分析场景的最佳实践,揭秘Flink+Hologres流批一体首次落地阿里双11营销分析大屏背后的技术考验。

一、背景介绍

在淘系业务运营中,大促是业务运营和用户增长中非常重要的场景,而营销活动分析产品作为大促期间用来服务决策、指导运营的核心数据产品,覆盖活动前、中、后全链路的分析,其中需要满足不同角色小二在不同阶段下,对数据时效性和数据灵活性的不同要求。

老版营销活动分析是基于常规的实时离线数据体系&FW的产品架构,在之前的各类大大小小的活动中,也暴露了比较多的问题,其中核心的问题可以归纳为三类:

  • 实时和离线数据不一致:相同口径的数据实时和离线不一致,包括数据逻辑口径不统一、数据接口不统一,由于实时和离线数据开发割裂(开发人员和接口),不仅仅增加了整体数据的运维成本,同时产品搭建层面的负担也大幅度提升。
  • 维护成本高:随着业务量的增加,原有数据库不能快速、灵活的支持复杂且多变的应用场景。常规的HBase、MySQL、ADB数据库,都只能单点满足海量数据、高并发存储点查、OLAP查询,因此面对极其复杂的业务,需要依赖多个数据库,整体维护成本和依赖成本会非常高。
  • 扩展性差:在FW框架下的产品搭建逻辑复杂度高、可扩展性都比较差,在活动期间维护的成本非常大

因此,如何能够快速应对频繁变动的业务诉求,以及更高效的处理活动期间的数据问题变得越来越重要,升级的新一代营销活动分析架构因而需要满足以下几个优点:
1. 实时数仓与离线数仓能够模型统一(实时离线逻辑统一)、接口统一(数据存储、取数统一),真正做到流批一体
2. 需要有更强大的数仓,既能够满足海量数据的并发写入查询,还能够满足业务的及时查询功能
3. 简化现有的产品搭建逻辑、降低产品实现复杂度

基于上诉背景,我们需要重构当前架构并寻找另外的替代产品来解决业务痛点。经过长时间的调用和尝试,最终我们选择了基于实时计算Flink+Hologres+FBI(阿里内部的一款可视化分析工具)的技术方案来实现天猫营销活动分析的架构重构。

二、 流批一体技术方案

通过深度剖析业务对数据的要求,以及多方位数据模型探索和数仓的调研,最终确定了营销活动分析产品重构的整体技术框架,如下图所示,其中的核心要点有:

  • 通过流批一体架构升级,实现了流批SQL逻辑&计算引擎层面统一
  • 通过Hologres实现了数据存储和查询的统一
  • 利用FBI产品能力,在降低搭建成本的同时满足业务的高灵活性,同时满足不同角色对于报表的需求

ae1.png

下面,我们将详细介绍整个技术方案中核心的几大技术方案:流批一体、Hologres、FBI

1. 流批一体技术框架

传统数仓架构图如下图所示,传统数仓架构核心问题:

  • 流批间的存储层割裂,集群、表、字段都是分开的,导致应用层对接时需要写不同的取数逻辑。
  • 流批间的处理逻辑不能复用,SQL标准不一样,计算引擎不一样,导致实时和离线需要分别开发,其实很多情况下,逻辑大同小异,但系统之前不能灵活转换,导致工作量重复
  • 计算层集群分开,实时和离线对资源的使用时间段高峰不一样,导致资源利用率不够高,波峰波谷非常明显

ae2.png

流批一体数仓架构图如下图所示,升级后的架构主要有以下核心点需要关注:

  • 首先,数仓DWD层虽然在存储介质上不同,但需要保证数据模型的等价,然后进行逻辑表封装(一个逻辑表映射两个物理表,即实时DWD和离线DWD),数据计算代码的撰写都是基于该逻辑表开发
  • 其次,基于逻辑表的代码开发、流、批计算模式的个性化配置、以及不同的调度策略等,需要有开发平台(Dataphin流批一体开发平台)作为支撑,形成便捷的开发、运维一体化
  • 最后,基于数据建模规范的存储层统一,不仅是模型规范统一,还是存储介质的统一,做到了无缝的衔接

ae3.png

今年双11,实时计算Flink处理的流量洪峰创纪录地达到了每秒40亿条的记录,数据体量也达到了惊人的每秒7TB,基于Flink的流批一体数据应用在营销活动分析场景中崭露头角,并在稳定性、性能和效率方面都经受住了严苛的生产考验
整体Flink流和Flink 批任务在活动期间都表现了极强的稳定性,全程0链路容量、机器单点、网络带宽等问题的发生

2. Hologres流批一体落地

流批一体数据架构实现了整体的数据层面的统一,还需要选用一款产品让整体的存储统一,这款产品需要即支持高并发写入,又能够满足及时查询,同时还能够支持OLAP分析。

在老版本的架构中每个页面模块会涉及到一个或多个数据库的数据查询,如MySQL、HBase、ADB3.0(老版本HybridDB)等。由于HBase的高并发写入、高性能点查等特性,所以大多数实时数据就会放在Hbase中;而由于MySQL表管理便捷、查询简易等好处,维表数据、离线数据通常会选择存放在其中;另外,产品的一些模块涉及到的数据,具有数据量小、维度多等特征(如营销玩法数据),则会选择ADB作为OLAP多维分析的数据库。如此,就会存在两个痛点:实时数据与离线数据的割裂、多数据库多实例的杂乱管理。
新版营销活动分析产品的建设,一个目标是要做到存储统一,降低运维成本和提高研发效能;另外一个目标是高性能、高稳定、低成本。

我们通过与多方位的产品对标之后,选用了Hologres作为整个营销活动分析的统一产品。Hologres作为一款兼容PostgreSQL 11协议的一站式实时数仓,与大数据生态无缝打通,支持PB级数据高并发、低延时的分析处理,可以轻松而经济地使用现有BI工具对数据进行多维分析透视和业务探索,在这样复杂的业务场景中Hologres的优势就表现得极为突出了。

通过对整体营销活动分析个模块的深度分析,以及结合业务侧对数据时效性的要求,整体将营销活动分析的几大模块的数据制定了具体的实时链路方案:

  • 活动直播、预售、加购、流量监控等核心模块,我们选用了Hologres的实时点查能力,
  • 面对复杂多变的营销玩法场景,我们选用了Hologres的OLAP即时查询能力

针对营销活动分析需要的点查能力和OLAP分析能力,天猫营销活动分析分别建了dt-camp和dt-camp-olap库,其中dt_camp点查库由于需要将活动期间的一些历史数据长期存放用来做活动的对比,整体数据量级在近40TB;营销玩法的OLAP库中,存放的是玩法的一些明细数据,整体数据量级在近百TB,由于营销玩法对整体数据的准确度要求非常高,因此没有采用有损精度的查询方式,对整体数仓的查询性能提出了更高的要求。

为了提升Hologres的整体性能,针对营销活动分析数仓主要做了一下几类优化策略:

  1. 设置distribution key:对于count(distinct user_id)的情况将user_id设置为distribution key在Hologres中每一个shard做count distinct,避免大量的数据shuffle,大大提升查询性能。
  2. 尽量减少count distinct 次数:通过多层group by 操作转换SQL减少count distinct成本
  3. shard prunning:在一些场景中,查询会指定某个表的pk中的一些key进行查询,如果将这些场景的key组合设置为distribution key,可以在处理查询的时候就确定本次查询会命中那几个shard,减少RPC请求数,对于高QPS场景至关重要
  4. 生成最优的plan:营销活动分析有基于汇总数据的点查或者范围查询,有基于原始数据的OLAP查询,还有单表的聚合之后取topn的查询,对于不同的查询类型,Hologres能够根据收集的统计信息,生成最优的执行计划,保证查询的QPS和Latency
  5. 写入优化:营销活动分析的写入都是基于列存表UPDATE操作,该操作在hologres中会首先根据指定的pk找到对应的uniqueid,然后根据uniqueid找到对应的记录标记删除,然后再查询一条新纪录,这种情况如果能够设置一个递增的segment key,查询的时候就可以根据segment key快速定位到文件,提升根据pk定位到记录的速度,提升写入性能,营销活动分析系统压测时写入峰值可以达到800万每秒的更新
  6. 小文件合并:某些写入不是很频繁的表因为一段时间更新的key比较固定,这导致memory table flush的时候是一个比较小的文件,而Hologres默认的compaction策略并没有对这些文件做compaction,导致存在比较多的小文件,通过深入优化compaction参数,增加compaction的频率,减少小文件,对于查询性能有较明显的提升

Hologres在双十一期间表现,点查场景的写入峰值达几十万每秒,服务能力几百万每秒,OLAP写入峰值400万每秒,服务能力500万每秒。同时单点查询&OLAP查询几乎都能够满足单条查询小于ms的查询比例高达99.7%以上,因此在整个活动期间,Hologres整体表现非常平稳,能够很好的同时支持快速点查和快速OLAP分析。

3. FBI分析大屏

FBI作为阿里生态内的首选数据可视化平台,即能快速支持搭建各类报表进行数据分析,也能支持多种数据集的快速接入与扩展,还有支持各种分析型数据产品建设的高级功能【产品搭建】。
ae4.png

在FBI产品搭建的核心流程中,可以通过4个核心功能大幅降低搭建成本:

1)实时离线一体的“实时小时分钟模型”,自动实现实时数据的精确趋势和对比
针对营销活动定义的批流一体的底层数据,为了满足用户分析实时数据,实时对比,小时对比的灵活性,FBI抽象出一套实时离线一体的标准数据模型,创建该模型后就可以实现实时数据的精确对比,趋势分析自动路由分钟表,小时趋势直接路由到小时表的能力。
2)FBI原创的FAX函数,极简定义输出各种复杂指标
针对复杂的指标:如通道占比,类目占比,同比贡献度,活动累计成交额,上个版本中均是用sql套sql进行定义,不仅导致SQL长度保障,同时产品的稳定性和可维护性都大大降低。为了解决这类问题,FBI构建了一套易于学习和理解的分析DSL,名为 FAX函数(同比差额、贡献率、活动累计等20+分析函数),简单的一行语句可以定义出营销活动分析中用到的各种复杂指标。
3)通过分析能力配置化和专有逻辑插件化,大幅节约页面构建时间
产品页面构建是一个非常核心的环节,如何节约用户的配置,FBI的方法就是:
a、通用分析能力配置化:对于最常用到的交叉表、活动对比,日期变量传参等分析场景,抽象升级为简单的配置项,即可完成相应的同期对比和同比差额等分析。
b、专有逻辑插件化:对于活动参数,显示隐藏,结果排序等作用于区块的定制能力,可以通过数据插件的方式覆盖。
4、打造沉淀FBI的高保障体系,升级了发布管控,监控预警,变更提示等,支持1-5-10
ae5.png

三、测试端的保驾护航

为了进一步保障营销活动分析产品质量,测试端从明细->汇总->产品端都做了严格的数据比对和校验,同时针对大促的核心数据,进行了全方位的监控
ae6.png

在活动期间测试巡检功能大大提升了主动发现数据问题的能力,以及及时发现核心问题的能力,大大的提升了活动期间整个数据产品的质量和稳定性

四、业务反馈&价值

整个双十一期间,基于实时计算Flink+Hologres流批一体的营销活动分析产品不仅支持了天猫事业群上千+小二的人均上百PV高频访问,更实现了0 P1/P2故障的目标,同时整个产品在活动期间表现了相比往年更有优势的几大方面:

  • 丰富:实时数据在营销活动分析产品中大规模铺开,核心维度可以down到活动商品、商家标签分层等多个维度,同时加购和预售都新增了商家、商品维度的实时数据,更加友好的支持了业务侧进行商家的BD
  • 稳定:基于Hologres持续高稳定的输出,整体双十一期间不论是实时数据写入、还是数据的读取都表现出了极强的稳定性;同时工程端实时监控用户访问和数据响应效率,实时分析解决业务问题;产品巡检涵盖了产品的核心数据,进一步的保障了整个产品的稳定性
  • 高效:流批技术的应用,以及Hologres的统一对接,不仅大幅度的提升了活动期间的需求接入效率(今年双十一期间整体需求承接能力是去年的3倍),同时整体的提升了问题反馈和解决的时效(相比以往活动提升了3-4倍)

五、未来展望

虽然已经经历了一次大促大考验,但是技术的探索永无止境,我们需要不断的完善来应对更加复杂的业务场景:
1)Dataphin流批一体开发平台进一步完善,减少人工干预成本,同时进一步保证数据质量
2)Hologres资源隔离,读写资源隔离,更好地保证查询的SLA;打通Hologres与MaxCompute,支持元数据的互通,为产品元数据提供更高的保障;动态扩容,能够灵活应对峰值及日常的业务需要。
3)FBI产品工具,能够提升产品版本管理功能,同一页面支持多人编辑不覆盖,更加高效的支持产品搭建

相关实践学习
AnalyticDB MySQL海量数据秒级分析体验
快速上手AnalyticDB MySQL,玩转SQL开发等功能!本教程介绍如何在AnalyticDB MySQL中,一键加载内置数据集,并基于自动生成的查询脚本,运行复杂查询语句,秒级生成查询结果。
阿里云云原生数据仓库AnalyticDB MySQL版 使用教程
云原生数据仓库AnalyticDB MySQL版是一种支持高并发低延时查询的新一代云原生数据仓库,高度兼容MySQL协议以及SQL:92、SQL:99、SQL:2003标准,可以对海量数据进行即时的多维分析透视和业务探索,快速构建企业云上数据仓库。 了解产品 https://www.aliyun.com/product/ApsaraDB/ads
相关文章
|
1月前
|
SQL 消息中间件 分布式计算
大数据-124 - Flink State 01篇 状态原理和原理剖析:状态类型 执行分析
大数据-124 - Flink State 01篇 状态原理和原理剖析:状态类型 执行分析
67 5
|
3月前
|
消息中间件 监控 数据挖掘
基于RabbitMQ与Apache Flink构建实时分析系统
【8月更文第28天】本文将介绍如何利用RabbitMQ作为数据源,结合Apache Flink进行实时数据分析。我们将构建一个简单的实时分析系统,该系统能够接收来自不同来源的数据,对数据进行实时处理,并将结果输出到另一个队列或存储系统中。
241 2
|
2月前
|
消息中间件 资源调度 API
Apache Flink 流批融合技术介绍
本文源自阿里云高级研发工程师周云峰在Apache Asia Community OverCode 2024的分享,内容涵盖从“流批一体”到“流批融合”的演进、技术解决方案及社区进展。流批一体已在API、算子和引擎层面实现统一,但用户仍需手动配置作业模式。流批融合旨在通过动态调整优化策略,自动适应不同场景需求。文章详细介绍了如何通过量化指标(如isProcessingBacklog和isInsertOnly)实现这一目标,并展示了针对不同场景的具体优化措施。此外,还概述了社区当前进展及未来规划,包括将优化方案推向Flink社区、动态调整算子流程结构等。
405 31
Apache Flink 流批融合技术介绍
|
5月前
|
分布式计算 Serverless 调度
EMR Serverless Spark:结合实时计算 Flink 基于 Paimon 实现流批一体
本文演示了使用实时计算 Flink 版和 Serverless Spark 产品快速构建 Paimon 数据湖分析的流程,包括数据入湖 OSS、交互式查询,以及离线Compact。Serverless Spark完全兼容Paimon,通过内置的DLF的元数据实现了和其余云产品如实时计算Flink版的元数据互通,形成了完整的流批一体的解决方案。同时支持灵活的作业运行方式和参数配置,能够满足实时分析、生产调度等多项需求。
60805 107
|
1月前
|
消息中间件 druid Kafka
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
从Apache Flink到Kafka再到Druid的实时数据传输,用于分析/决策
78 0
|
3月前
|
消息中间件 数据挖掘 Kafka
揭秘数据洪流中的救世主:Confluent与Flink的实时分析奇迹!
【8月更文挑战第9天】在现代数据处理中,实时数据分析至关重要。Confluent Platform与Apache Flink的组合提供了一套高效的数据流处理方案。Confluent Platform基于Apache Kafka构建,负责数据的收集、传输及管理;而Flink则擅长实时处理这些数据流,进行复杂分析。首先需配置Confluent Platform,包括设置Zookeeper、Kafka brokers及相关服务。
81 1
|
5月前
|
SQL 搜索推荐 OLAP
Flink 流批一体场景应用及落地情况
本文由阿里云 Flink 团队苏轩楠老师撰写,旨在介绍 Flink 流批一体在几个常见场景下的应用。
68028 11
Flink 流批一体场景应用及落地情况
|
5月前
|
消息中间件 分布式计算 Kafka
深度分析:Apache Flink及其在大数据处理中的应用
Apache Flink是低延迟、高吞吐量的流处理框架,以其状态管理和事件时间处理能力脱颖而出。与Apache Spark Streaming相比,Flink在实时性上更强,但Spark生态系统更丰富。Apache Storm在低延迟上有优势,而Kafka Streams适合轻量级流处理。选型考虑延迟、状态管理、生态系统和运维成本。Flink适用于实时数据分析、复杂事件处理等场景,使用时注意资源配置、状态管理和窗口操作的优化。
|
6月前
EDM营销平台有哪些?Top5平台分析
探索五大热门EDM营销平台:蜂邮EDM以其丰富功能备受喜爱;Constant Contact以用户友好体验著称;Sendinblue结合短信营销与广告管理,适合中小企业;GetResponse提供营销自动化解决方案,适合各类企业;AokSend以其历史底蕴和分析工具吸引用户。各平台特色各异,企业可根据需求选择。
|
6月前
|
算法 数据可视化 数据挖掘
聚类建模对智能助眠灯市场营销分析
聚类建模对智能助眠灯市场营销分析

热门文章

最新文章

相关产品

  • 实时数仓 Hologres
  • 下一篇
    无影云桌面