关于jquery:HologresFlink流批一体首次落地4982亿背后的营销分析大屏

26次阅读

共计 5441 个字符,预计需要花费 14 分钟才能阅读完成。

简介: 本篇将重点介绍 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 产品能力,在升高搭建老本的同时满足业务的高灵活性,同时满足不同角色对于报表的需要


**
上面,咱们将具体介绍整个技术计划中外围的几大技术计划:流批一体、Hologres、FBI

1. 流批一体技术框架

传统数仓架构图如下图所示,传统数仓架构外围问题:

  • 流批间的存储层割裂,集群、表、字段都是离开的,导致应用层对接时须要写不同的取数逻辑。
  • 流批间的解决逻辑不能复用,SQL 规范不一样,计算引擎不一样,导致实时和离线须要别离开发,其实很多状况下,逻辑大同小异,但零碎之前不能灵便转换,导致工作量反复
  • 计算层集群离开,实时和离线对资源的应用时间段顶峰不一样,导致资源利用率不够高,波峰波谷非常明显


流批一体数仓架构图如下图所示,降级后的架构次要有以下外围点须要关注:

  • 首先,数仓 DWD 层尽管在存储介质上不同,但须要保障数据模型的等价,而后进行逻辑表封装(一个逻辑表映射两个物理表,即实时 DWD 和离线 DWD),数据计算代码的撰写都是基于该逻辑表开发
  • 其次,基于逻辑表的代码开发、流、批计算模式的个性化配置、以及不同的调度策略等,须要有开发平台(Dataphin 流批对立开发平台)作为撑持,造成便捷的开发、运维一体化
  • 最初,基于 OneData 标准的存储层对立,不仅是模型标准对立,还是存储介质的对立,做到了无缝的连接

往年双 11,实时计算 Flink 解决的流量洪峰创纪录地达到了每秒 40 亿条的记录,数据体量也达到了惊人的每秒 7TB,基于 Flink 的流批一体数据利用在营销流动剖析场景中锋芒毕露,并在稳定性、性能和效率方面都禁受住了严苛的生产考验
整体 Flink 流和 Flink batch 工作在流动期间都体现了极强的稳定性,全程 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 定位到记录的速度,晋升写入性能,营销流动剖析零碎压测时写入峰值能够达到 800W/ s 的更新
  6. 小文件合并:某些写入不是很频繁的表因为一段时间更新的 key 比拟固定,这导致 memory table flush 的时候是一个比拟小的文件,而 Hologres 默认的 compaction 策略并没有对这些文件做 compaction,导致存在比拟多的小文件,通过深刻优化 compaction 参数,减少 compaction 的频率,缩小小文件,对于查问性能有较显著的晋升

Hologres 在双十一期间体现,点查场景的写入峰值达几十 w /s,服务能力几百 w /s,OLAP 写入峰值 400w/s,服务能力 500w/s。同时单点查问 &OLAP 查问简直都可能满足单条查问小于 ms 的查问比例高达 99.7% 以上,因而在整个流动期间,Hologres 整体体现十分安稳,可能很好的同时反对疾速点查和疾速 OLAP 剖析。

3. FBI 剖析大屏

FBI 作为阿里生态内的首选数据可视化平台,即能疾速反对搭建各类报表进行数据分析,也能反对多种数据集的疾速接入与扩大,还有反对各种剖析型数据产品建设的高级性能【产品搭建】。

在 FBI 产品搭建的外围流程中,能够通过 4 个外围性能大幅升高搭建老本:

1)实时离线一体的“实时小时分钟模型”,主动实现实时数据的准确趋势和比照
针对营销流动定义的批流一体的底层数据,为了满足用户剖析实时数据,实时比照,小时比照的灵活性,FBI 形象出一套实时离线一体的规范数据模型,创立该模型后就能够实现实时数据的准确比照,趋势剖析主动路由分钟表,小时趋势间接路由到小时表的能力。
2)FBI 原创的 FAX 函数,极简定义输入各种简单指标
针对简单的指标:如通道占比,类目占比,同比贡献度,流动累计成交额,上个版本中均是用 sql 套 sql 进行定义,不仅导致 SQL 长度保障,同时产品的稳定性和可维护性都大大降低。为了解决这类问题,FBI 构建了一套易于学习和了解的剖析 DSL,名为 FAX 函数(同比差额、贡献率、流动累计等 20+ 剖析函数),简略的一行语句能够定义出营销流动剖析中用到的各种简单指标。
3)通过剖析能力配置化和专有逻辑插件化,大幅节约页面构建工夫
产品页面构建是一个十分外围的环节,如何节约用户的配置,FBI 的办法就是:
a、通用剖析能力配置化:对于最罕用到的穿插表、流动比照,日期变量传参等剖析场景,形象降级为简略的配置项,即可实现相应的同期比照和同比差额等剖析。
b、专有逻辑插件化:对于流动参数,显示暗藏,后果排序等作用于区块的定制能力,能够通过数据插件的形式笼罩。
4、打造积淀 FBI 的高保障体系,降级了公布管控,监控预警,变更提醒等,反对 1 -5-10

三、测试端的保驾护航

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

在流动期间测试巡检性能大大晋升了被动发现数据问题的能力,以及及时发现外围问题的能力,大大的晋升了流动期间整个数据产品的品质和稳定性

四、业务反馈 & 价值

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

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

五、将来瞻望

尽管曾经经验了一次大促大考验,然而技术的摸索永无止境,咱们须要一直的欠缺来应答更加简单的业务场景:
1)Dataphin 流批一体的产品进一步欠缺,缩小人工干预老本,同时进一步保证数据品质
2)Hologres 资源隔离,读写资源隔离,更好地保障查问的 SLA;买通 Hologres 与 MaxCompute,反对元数据的互通,为产品元数据提供更高的保障;动静扩容,可能灵便应答峰值及日常的业务须要。
3)FBI 产品工具,可能晋升产品版本治理性能,同一页面反对多人编辑不笼罩,更加高效的反对产品搭建

原文链接
本文为阿里云原创内容,未经容许不得转载。

正文完
 0