阿里巴巴电商搜索推荐实时数仓演进之路
分享嘉宾：张照亮 阿里巴巴 高级技术专家
编辑整理：郑银秋
出品平台：DataFunTalk
导读： 今天分享的内容是阿里搜索推荐数据平台研发团队在实时数仓的一些探索，围绕着团队在数仓上基于Flink + Hologres的演进过程及最佳实践。
01 业务背景
阿里巴巴电商搜索推荐实时数据仓库承载了阿里巴巴集团淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景，提供了包括实时大屏、实时报表、实时算法训练、实时A/B实验看板等多种数据应用支持。
1. 数据的价值
我们认为数据处于阿里巴巴搜索推荐的大脑位置，这体现在算法迭代、产品运营和老板决策等多个方面。那么数据是怎样在搜索推荐业务场景中流转的呢？首先是信息采集，用户在使用手机淘宝的搜索和推荐功能时，会触发到服务端上的埋点信息；接下来会经过离线和实时的ETL加工，再装载到产品引擎里面；然后我们会基于引擎来构建分析系统，帮助算法、产品做分析决策；形成一次决策之后，会有一些新的内容上线，用户可以看到算法模型产出的一些业务形态；这样就产生了一轮新的数据采集、加工、装载和分析的过程。这样一来就可以利用数据形成一个完整的业务链路，其中每个环节都非常重要。
2. 搜索推荐典型场景
实时数据在电商搜索推荐中有多种不同的应用场景，如实时分析、算法应用和精细化人群运营等。
① 实时分析和算法应用场景
在实时分析和算法应用场景中，我们利用实时数据仓库搭建分析报表、实时大屏、训练算法模型以及打造其他类型的数据产品。实时数据的需求搜索推荐场景下主要有以下特点：
- 数据量大：单日PB级存储
- 单表总条数：千亿+
- QPS高：峰值写入RPS 6500W+
- 峰值查询QPS：200+
- 数据灵活性要求高，分析场景多样化，固定条件高频分析、非固定条件多维查询
② 精细化人群运营场景
在电商运营中，经常会有针对不同人群采用不同运营策略的需求。传统方式使用离线数据对人群进行活动投放，但一般需要到第二天才能看到前一日的活动运营效果。为了更高效地观测、提升运营效果，实时的人群投放、人群画像成为必不可少的需求。
实时数仓将会把实时数据以实时大屏、实时报表的形式，为活动运营提供实时的人群行为效果数据，如不同地区、不同年龄段人群的实时UV、实时成交额等。此外，还需要将实时数据与离线数据进行关联对比计算，提供实时的环比、同比数据。
02 典型实时数仓诉求
综合以上背景，在实时数仓建设的过程中，我们总结了以下几类典型的实时数仓诉求：
- 分组横截面
例如分行业指标展示，通常是在SQL中用group by进行查询；
- 多维过滤
场景过滤、用户过滤、商品过滤、商家过滤等，通常使用array字段进行属性值的过滤；
- 聚合
基于明细数据聚合计算实时指标，如SUM、COUNT_DISTINCT计算等；
- A/B Test
通过解析日志埋点中的分桶字段，计算测试桶与基准桶之间的实时Gap数据；
- 指定Key
在排查问题或观测核心商家指标时，经常需要指定商家ID、商品ID查询实时指标，需要基于明细实时表中的id字段过滤后进行聚合计算；
- 流批一体
由于实时数仓仅保留最近2天的数据，在面对计算同比、环比等需求时，就需要读取离线数据与实时数据进行关联计算，这样产品/运营在看上层报表展现时就能直观看到今年实时数据和去年同期的对比表现。
03 实时数仓架构
基于上诉典型实时数仓诉求，我们抽象出了如下图所示的典型实时数仓架构。
实时采集的业务日志经过实时计算Flink清洗过滤，将结果写到OLAP引擎里面，OLAP引擎既要支持多维的交互式查询、还要支持KV查询和流批一体查询，来满足我们各种各样的业务诉求，同时OLAP引擎还需要对接上层构建的各种业务应用，提供在线服务。
基于这个典型的实时架构，下面则是我们搜索推荐场景下的实时架构演进过程。
1. 实时数仓架构 1.0版
首先是实时数仓架构1.0版，如下图所示，这个版本主要是由3个板块组成：
数据采集
在数据采集层，我们将上游实时采集的数据分为用户行为日志和商品维表、商家维表、用户维表等，为什么会有维表呢？因为每个业务在埋点时不会将所有信息全部埋在日志里面，如果所有信息都由用户行为日志承载，灵活性将会特别差，所以维表在业务上担任信息扩展的角色。
采集的用户行为日志将会实时写入实时计算Flink，用户维表、商品维表等维表数据统一归档至MaxCompute中，在初步计算后将会通过数据同步工具（DataX）同步至批处理引擎中。
数据处理
在数据处理层中，流处理部分，由Flink对实时写入的用户行为日志数据做初步处理，具体的处理包括数据解析、清洗、过滤、关联维表等。
批处理部分，为了在数据查询和服务中根据属性查询、筛选数据，需要在Flink作业中将用户的实时行为和维表做关联计算，这就需要批处理系统能够支持高QPS查询，当时搜索业务的单表QPS最高达6500万，经过多方调研，选择了HBase作为维表的批处理引擎。
Flink作业中基于用户ID、商品ID、商家ID等关联HBase维表中的属性数据，输出一张包含多个维度列的实时宽表，再输出到OLAP引擎。为了简化Flink实时作业，降低实时计算的压力，我们没有在Flink中使用窗口函数做指标的聚合工作，只是对实时日志简单过滤、关联后直接输明细数据到下游，这就要求下游引擎需要提既要支持KV查询、OLAP多维交互式查询，还要支持流批一体查询。
数据查询和服务
在第一版架构中我们使用的是Lightning引擎来承载Flink输出的实时明细数据，并基于Lightning实现查询流批一体，再对上层应用提供统一的实时数据查询服务。
但是Lightning的局限性也是非常明显的：第一是查询方式是非SQL类型不够友好，若是写SQL需要二次封装。第二是Lightning采用的是公共集群，多用户资源不隔离，当需要查询大量数据时，容易出现性能波动和资源排队等问题，使得查询耗时较久，在实际业务场景使用中有一定的限制。
2. 实时数仓架构 2.0版
基于Lightning的限制，我们希望能找到一款替代产品，它的能力要在Lightning之上，支撑OLAP的交互式查询以及高QPS的维表校验查询。于是在2.0版的实时数仓架构中，我们开始接入Hologres。
最开始，我们只是用Hologres替代Lightning提供KV、OLAP查询能力，解决了Lightning所带来的局限性。这样的架构看起来很好，但因为还需要经过HBase存储维表，随着数据量的增长，数据导入至HBase的时间也越长，实际上浪费了大量资源，并且随着线上服务实时性要求增加，HBase的弊端也越来越明显。
而Hologres的核心能力之一是加速离线数据，尤其是针对MaxCompute的数据，在底层与其资源打通，能加速查询。所以我们就萌生了将Hologres替代HBase的想法，以Hologres为统一的存储，数据也无需再导入导出，保证了一份数据一份存储。
于是，最终的实时数仓架构2.0版如下：
- 数据处理阶段直接将用户维表、商品维表、商家维表以行存模式存储到Hologres中，以此替代Hbase存储。Flink中的作业可以直接读取Hologres的维表，与行为日志进行关联。
- 在数据查询和服务阶段，我们将Flink处理输出的实时明细数据统一存储至Hologres，由Hologres提供高并发的数据实时写入和实时查询。
04 基于Hologres的最佳实践
实时数仓2.0版本因为Hologres的接入，既精简了架构，节约了资源，也真正实现了流批一体。这个架构也一直使用至今，下面是Hologres基于此架构在搜索推荐具体多个业务场景中的最佳实践。
1. 行存最佳实践
Hologres支持行存和列存两种存储模式，行存对于key-value查询场景比较友好，适合基于primary key的点查和 scan，可以将行存模式的表看作是一张类似于Hbase的表，用不同的表存储不同实体的维度信息。在Flink实时作业中可以高效地从Hologres行存表中读取维表数据，与实时流中的实体进行关联。
2. 列存最佳实践
Hologres中默认表的存储模式是列存，列存对于OLAP场景较为友好，适合各种复杂查询。
基于Hologres的列存模式，我们搭建了搜索、推荐业务的实时数据查询看板，在实时看板上可以支持数十个不同维度的实时筛选过滤。在最高峰值每秒写入条数（RPS）超过500万的同时仍然可以秒级查询多个维度筛选下的聚合指标结果。
同时Hologres表支持设置表数据TTL的属性，一般我们将一张实时表的生命周期设置为48小时，超过48小时的数据会被自动删除，在实时看板中支持用户对最近两天内的实时数据进行查询，避免了不必要的资源浪费。
3. 流批一体最佳实践
Hologres不仅支持基于实时明细的数据的即席分析查询，也支持直接加速查询MaxCompute离线表，因此我们利用这一特性，实现流批一体的查询（实时离线联邦分析）。
在天猫大促活动中，我们利用Hologres的联邦分析能力搭建了核心商家的目标完成率、去年同期对比看板，为运营算法决策提供了有效的数据支撑。
其中目标完成率看板开发借助实时离线联邦分析变得更为简单，即通过Hologres实时查询大促当天的指标，并用实时表的当天指标除以离线表中设定的目标指标，从而让运营能够看到实时更新的核心商家当天目标的完成情况。
去年同期对比实时看板的计算逻辑也是类似的，可以在SQL中将实时表与去年的离线表JOIN后进行关键指标的同比计算。
所有的计算都可以在Hologres中完成，通过SQL表达计算逻辑即可，无需额外的数据开发工作，一份数据一套代码，降低开发运维难度，真正实现流批一体。
4. 高并发实时Update
在一些场景下，我们不仅需要向OLAP引擎实时增量写入数据，还需要对写入的数据进行更新操作（update）。
例如，在订单成交归因时，Flink实时作业会将订单提交数据流与进度点击数据流进行双流JOIN，并且在还需要取订单提交前的最后一次点击事件进行关联。当有多条点击事件先后到达时，我们就需要更新订单归因明细数据，此时需要利用Hologres的update支持，通过数据的主键更新原有数据，保证成交归因的数据准确性。在实践中Hologres的update写入峰值能达50W，满足业务高并发实时更新需求。
05 未来展望
我们希望未来基于Hologres引擎持续改进现有的实时数仓，主要的方向主要有：
1. 实时表JOIN
Hologres现阶段支持百亿级表与亿级表之间的JOIN，秒级查询响应。基于这个特性，期望将原本需要在数据处理阶段由Flink实时作业完成的维表关联工作，可以改为在查询Hologres阶段实时JOIN计算。例如表1是明细数据表，表2是用户维表，在查询阶段的JOIN可以通过筛选用户维表，然后与明细数据表关联，达到筛选过滤数据的目的。这样的改进将带来几个好处：
- 减少Hologres中的数据存储量，避免实时表中存储大量的数据冗余（如：同一个商品ID的数据会重复存储）；
- 提升实时数据中维度属性的时效性，在查询阶段实时JOIN维表数据后进行计算，可以使得我们在通过维度筛选数据的时候，始终用的是最新的维度属性。
2. 持久化存储
我们未来将探索如何将常用维度的实时数据，利用Hologres的计算和存储能力，将计算结果持久化存储。
今天的分享就到这里，谢谢大家。
