简介： 自建实时数仓到底难在哪里？实时数仓应该怎么建？阿里巴巴搜寻团队告诉您答案

作者：张照亮（士恒）阿里巴巴搜寻事业部高级技术专家

业务背景

========

阿里巴巴电商搜寻举荐实时数据仓库承载了阿里巴巴团体淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景，提供了包含实时大屏、实时报表、实时算法训练、实时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的计算和存储能力，将计算结果长久化存储。

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