阿里巴巴电商搜索推荐实时数仓演进之路
简介： 自建实时数仓到底难在哪里？实时数仓应该怎么建？阿里巴巴搜索团队告诉您答案算法
做者：张照亮（士恒）阿里巴巴搜索事业部高级技术专家架构
- 业务背景
========并发
阿里巴巴电商搜索推荐实时数据仓库承载了阿里巴巴集团淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景，提供了包括实时大屏、实时报表、实时算法训练、实时A/B实验看板等多种数据应用支持。运维
数据的价值
咱们认为数据处于阿里巴巴搜索推荐的大脑位置，这体如今算法迭代、产品运营和老板决策等多个方面。那么数据是怎样在搜索推荐业务场景中流转的呢？首先是信息采集，用户在使用手机淘宝的搜索和推荐功能时，会触发到服务端上的埋点信息；接下来会通过离线和实时的ETL加工，再装载到产品引擎里面；而后咱们会基于引擎来构建分析系统，帮助算法、产品作分析决策；造成一次决策以后，会有一些新的内容上线，用户能够看到算法模型产出的一些业务形态；这样就产生了一轮新的数据采集、加工、装载和分析的过程。这样一来就能够利用数据造成一个完整的业务链路，其中每一个环节都很是重要。函数
搜索推荐典型场景
实时数据在电商搜索推荐中有多种不一样的应用场景，如实时分析、算法应用和精细化人群运营等。
1）实时分析和算法应用场景
在实时分析和算法应用场景中，咱们利用实时数据仓库搭建分析报表、实时大屏、训练算法模型以及打造其余类型的数据产品。实时数据的需求搜索推荐场景下主要有如下特色：高并发
- 数据量大：单日PB级存储
- 单表总条数：_千亿+_
- QPS高：峰值写入RPS 6500W+
- 峰值查询QPS：_200+_
- 数据灵活性要求高，分析场景多样化，固定条件高频分析、非固定条件多维查询
2）精细化人群运营场景
在电商运营中，常常会有针对不一样人群采用不一样运营策略的需求。传统方式使用离线数据对人群进行活动投放，但通常须要到次日才能看到前一日的活动运营效果。为了更高效地观测、提高运营效果，实时的人群投放、人群画像成为必不可少的需求。
实时数仓将会把实时数据以实时大屏、实时报表的形式，为活动运营提供实时的人群行为效果数据，如不一样地区、不一样年龄段人群的实时UV、实时成交额等。此外，还须要将实时数据与离线数据进行关联对比计算，提供实时的环比、同比数据。工具
2.典型实时数仓诉求
综合以上背景，在实时数仓建设的过程当中，咱们总结了如下几类典型的实时数仓诉求：性能
分组横截面
例如分行业指标展现，一般是在SQL中用group by进行查询；测试
多维过滤
场景过滤、用户过滤、商品过滤、商家过滤等，一般使用array字段进行属性值的过滤；阿里云
聚合
基于明细数据聚合计算实时指标，如SUM、COUNT_DISTINCT计算等；
A/B Test
经过解析日志埋点中的分桶字段，计算测试桶与基准桶之间的实时Gap数据；
指定Key
在排查问题或观测核心商家指标时，常常须要指定商家ID、商品ID查询实时指标，须要基于明细实时表中的id字段过滤后进行聚合计算；
流批一体
因为实时数仓仅保留最近2天的数据，在面对计算同比、环比等需求时，就须要读取离线数据与实时数据进行关联计算，这样产品/运营在看上层报表展示时就能直观看到今年实时数据和去年同期的对比表现。
- 实时数仓架构
==========
基于上诉典型实时数仓诉求，咱们抽象出了以下图所示的典型实时数仓架构。
实时采集的业务日志通过实时计算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提供高并发的数据实时写入和实时查询。
- 基于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，知足业务高并发实时更新需求。
- 将来展望
========
咱们但愿将来基于Hologres引擎持续改进现有的实时数仓，主要的方向主要有：
1）实时表JOIN
Hologres现阶段支持百亿级表与亿级表之间的JOIN，秒级查询响应。基于这个特性，指望将本来须要在数据处理阶段由Flink实时做业完成的维表关联工做，能够改成在查询Hologres阶段实时JOIN计算。例如表1是明细数据表，表2是用户维表，在查询阶段的JOIN能够经过筛选用户维表，而后与明细数据表关联，达到筛选过滤数据的目的。这样的改进将带来几个好处：
1）减小Hologres中的数据存储量，避免实时表中存储大量的数据冗余（如：同一个商品ID的数据会重复存储）；
2）提高实时数据中维度属性的时效性，在查询阶段实时JOIN维表数据后进行计算，可使得咱们在经过维度筛选数据的时候，始终是用的最新的维度属性。
2）持久化存储
咱们将来将探索如何将经常使用维度的实时数据，利用Hologres的计算和存储能力，将计算结果持久化存储。
原文连接本文为阿里云原创内容，未经容许不得转载。