简介： 本文重点介绍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_gmvfrom(  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服务形成的实时数据体系，正在全方位、多维度地附能搜寻、举荐、营销、触达和用户经营等外围业务。

作者简介：王伟（花名炎辰），阿里巴巴飞猪技术部高级数据工程师 。