共计 4266 个字符，预计需要花费 11 分钟才能阅读完成。
简介： 本文重点介绍 Hologres 如何落地阿里巴巴飞猪实时数仓场景，并助力飞猪双 11 实时数据大屏 3 秒起跳，全程 0 故障。
摘要：刚刚完结的 2020 天猫双 11 中，MaxCompute 交互式剖析（下称 Hologres）+ 实时计算 Flink 搭建的云原生实时数仓首次在外围数据场景落地，为大数据平台创下一项新纪录。借此之际，咱们将陆续推出云原生实时数仓双 11 实战系列内容，本文重点介绍 Hologres 如何落地阿里巴巴飞猪实时数仓场景，并助力飞猪双 11 实时数据大屏 3 秒起跳，全程 0 故障。
往年双十一较以往最大的变动就是流动的整体节奏从原来“单节”调整为往年的“双节”，天然地造成两波流量顶峰，大屏和营销数据的统计周期变长，指标维度变得更多，同时团体 GMV 媒体大屏首次间接复用飞猪大屏链路数据，所以如何保障团体 GMV 媒体大屏、飞猪数据大屏以及双十一整体数据的实时、精确、稳固是一个比拟大的挑战。
本次双十一飞猪实时大屏零点 3 秒起跳，全程 0 故障，顺利护航阿里巴巴团体媒体大屏，做到了指标准确、服务稳固、反馈实时。
而这所有都离不开大屏背地实时数据全链路的技术升级和保障。飞猪实时数据整体架构如下图所示：
上面将会介绍，为了实现快、准、稳的双 11 实时数据大屏，业务针对实时数据全链路做了哪些降级改良和优化。
一、公共层加固，抵挡洪峰流量
抵挡双十一流量洪峰，首先发力的是实时数据公共层。通过近两年的迭代欠缺，多端、多源的实时数据公共层曾经实现了日志、交易、营销互动、服务域的全域笼罩，作业吞吐和资源效率也在一直的晋升，本次双十一为了安稳通过流量双峰，对其进行了多轮的全链路的压测和进一步的夯实加固：
1）维表迁徙，扩散热点依赖
维表是实时公共层的外围逻辑和物理依赖，热点维表在大促时可能就是服务的危险点和瓶颈。飞猪商品表是各类实时作业依赖最多的 Hbase 维表，其中包含大促时流量暴涨的飞猪淘宝端流量公共层作业。去年通过对淘系 PV 流量提取的深度逻辑优化，将该维表的日常 QPS 由几十 w 升高到了几 w，但随着后续点击公共层以及其余业务作业的一直新增依赖，日常 QPS 很快升到了 5w+，大促压测时一路飙升到十多 w，且维表所在的 Hbase 集群比拟老旧且为公共集群，大促稳定性危险较大。所以 将飞猪商品表及其他大流量公共层依赖维表都迁徙到性能更佳的 lindorm 集群，将其余非核心的应用层维表持续保留原有 habse 集群，扩散大促洪峰时对维表的压力。
2）作业隔离，避免资源挤压
实时作业的资源耗费也合乎二八原理，小局部的作业耗费了大部分的计算资源。飞猪淘系的曝光作业双十一大促时至多须要 1000+CU 保障资源，PV 公共层工作须要 600CU，整个流量公共层 9 个作业至多须要集群一半以上的资源来进行保障。为避免洪峰袭来是单队列内的多个大作业资源超用（大流量时作业耗费会超出配置资源）时产生挤压，影响吞吐，将大作业扩散不同资源队列。同样对于各个类目标交易公共层工作也会扩散在各个资源队列，避免繁多集群突发极其异样，导致指标数据跌 0。
3）双十一性能体现
双十一期间，实时公共层顺利抵挡淘系源头较日常交易流量 250 倍和日志流量 3 倍，整体流量公共层最高约几千万条 / 秒的洪峰冲击，淘系交易公共层工作无任何时延，流量公共层分钟级时延并很快消退。
二、架构降级，提效开发
双十一大促的外围三个阶段预售、预热、正式，正式阶段最重要的事件就是付尾款。本次双十一业务侧比拟大的变动就是付尾款由原来的一天变成了三天，导致去年的对于尾款的营销数据都无奈复用。除了要保留之前大盘、类目、天、小时等多维度尾款领取相干的指标，还须要新增商品、商家粒度的尾款，同时因为尾款周期变长，为了业务更高效的催尾款，长期可能须要新增更多维度的数据（尾款的最初一天就接到了须要拉取未领取尾款订单明细的需要）。所以为了应答本次双十一尾款数据指标长周期、多维度、易变动的挑战，将大屏和营销数据的数据架构由预计算模式降级为预计算 + 批流一体的即席查问混合模式，整体的开发效率至多晋升 1 倍以上，且能够不便的适应需要变更。
1）新的营销数据架构：
- 即席查问局部：Hologres+Flink 流批一体的数据架构，应用了 Hologres 的分区表和即时查问能力。将公共层的实时明细数据写入当日分区，离线侧公共层明细数据由 MaxCompute 间接导入笼罩 Hologres 次日笼罩分区（对于准确性和稳定性非严苛的场景，能够抉择都去掉离线 merge 的步骤），同时写入时留神配置主键笼罩，避免实时工作异样时，能够回刷。各位维度的指标计算，间接在 Hologres 中通过 sql 聚合，即时返回查问后果，十分不便的适应统计指标的需要变更。
- 预计算局部：保留了之前比拟成熟的 Flink+Hbase+Onservice 的计算、存储和服务架构。次要通过 Flink 实时聚合指标，并写入 Hbase，onservice 做查问服务和链路切换。高可用和稳定性场景，构建主备链路，可能还会配合离线指标数据回流，修复实时链路可能呈现的异样和误差。
2）简略高效的指标计算
由 Hologress 搭建的即席查问服务，除了架构简略高效，指标计算更是简略到令人发指，极大的解放了实时指标数据的开发效率。
对于尾款领取局部，有一个很惯例，但如果通过 Flink SQL 来实现就会比拟鸡肋或者代价较大的指标，就是从零点到各小时累计尾款领取金额或领取率。flink 的 group by 实质是分组聚合，能够很不便对小时数据分组聚合，然而很难对从 0 - 2 点，0- 3 点，0- 4 点这类累计数据构建分组来进行计算，只能构建 0 点到以后小时 max(hour)的数据分组做聚合。带来的问题就是，一旦数据出错须要回刷，只会更新最初一个小时的数据，两头的小时累计状况都无奈更新。
而对于通过 Hologres 的即时查问的引擎来说，只须要对小时聚合之后再来一个窗口函数，一个统计 sql 搞定，极大的晋升了开发效率。示例如下：
select stat_date,stat_hour,cnt,gmv _-- 小时数据_
,sum(cnt) over(partition by stat_date order by stat_hour asc) as acc_cnt _-- 小时累计数据_
,sum(gmv) over(partition by stat_date order by stat_hour asc) as acc_gmv
from(select stat_date,stat_hour,count(*) cnt,sum(gmv) as gmv
from
dwd_trip_xxxx_pay_ri
where stat_date in('20201101','20201102')
group by stat_date,stat_hour
) a ;三、链路和工作优化，保障稳固
1）主备双链 3 备份
阿里巴巴团体 GMV 媒体大屏始终由团体 DT 团队自主把控，往年双十一的团体大屏，为了保障口径的统一和完整性，首次间接复用飞猪实时链路数据，所以对大屏指标计算和链路的稳定性和时效提出了更高的要求。
为了保证系统高可用，各个类目标交易从源头数据库的 DRC 同步到交易明细公共层别离构建张北、南通集群主备双链路，对于应用层的 GMV 统计工作和 Hbase 后果存储在双链的根底上又减少上海集群的备份。整体的链路架构如下：
同时，配合全链路的实时工作异样监控和报警，出现异常时能够做到链路秒级切换，零碎 SLA 达到 99.99% 以上。
2）零点 3s 起跳优化
为了保障零点 3s 起跳，对工作的全链路数据处理细节优化。
- 源头局部优化了 DRC 同步后 binlog 的 TT 写入，将源 TT 的多 queue 缩减为单 queue，缩小数据距离时延。晚期的开发没有正确评估各类目交易数据流量状况，而将 TT 的 queue 数设置过大，导致单 queue 内流量很小，TT 采集时默认的 cache size 和频次，导致数据数据的距离时延很大，从而放大了整体链路的时延。TT 多 queue 缩容后，数据距离时延根本降落至秒级以内。
- 两头局部优化各类目标交易公共层的解决逻辑，消减逻辑解决时延。初版的 TTP 交易 (国内机票、火车票等) 公共层，为了更多维的复用齐全模拟了离线公共层的解决，将简单且时延较大的航段信息关联到一起，导致整个工作的解决时延达十几秒。为了准确均衡时延和复用性，将旧有的多流 join 后对立输入，改为多级 join 输入，将 gmv 的解决时延升高到 3s 以内。整体流程如下：
- 工作节点局部，调整参数配置，升高缓冲和 IO 解决时延。公共层和 GMV 统计局部，调整 miniBatch 的 allowLatency、cache size，TT 输入的 flush interval，Hbase 输入的 flushsize 等等
3）TopN 优化
TopN 始终实时营销剖析常见的统计场景，因为其自身就是热点统计，所以比拟容易呈现数据歪斜、性能和稳定性问题。双十一预售开始后，会场、商家、商品的曝光流量的 TopN 作业就开始陆续的呈现背压，作业 checkpoint 超时失败，时延微小且易 failover，统计数据根本不可用状态。初期判断为流量上涨，作业吞吐不够，调大资源和并发根本无任何成果，背压仍集中在 rank 的节点而资源短缺。认真排查发现 rank 节点执行算法堕落为性能较差的 RetractRank 算法，之前 group by 后再 row_number()倒排后取 topN 的逻辑，无奈主动优化成 UnaryUpdateRank 算法，性能急降（起因为 UnaryUpdateRank 算子有准确性危险在外部 Flink3.7.3 版本被下线）。屡次调整和测试之后，确定无奈通过配置优化问题，最终通过多重逻辑优化进行化解。
- 将会场分类的曝光、商家商品的工作进行逻辑拆分为两个工作，避免商品或商家逻辑 rank 节点数据歪斜，导致整体数据出不来。
- 先做了一级聚合计算 UV，缩小 TOP 排序数据数据量，再做二级聚合优化为 UpdateFastRank 算法，最终 checkpoint 秒级，回溯聚合一天曝光数据只须要 10 分钟。
- 当然还有一种策略是做二级 TopN，先
- 原文链接
本文为阿里云原创内容，未经容许不得转载。
数据大屏始终是实时场景高要求的代表，每次双十一业务带来的考验和挑战，都会对整个实时数据体系和链路带来新的冲破。同时，飞猪的实时数据不仅仅只是止点亮媒体大屏，提效营销剖析和会场经营，由实时公共层和特色层、实时营销剖析、实时标签和 RTUS 服务形成的实时数据体系，正在全方位、多维度地附能搜寻、举荐、营销、触达和用户经营等外围业务。
作者简介：王伟（花名炎辰），阿里巴巴飞猪技术部高级数据工程师。
