简介： 自建实时数仓到底难在哪里？实时数仓应该怎么建？阿里巴巴搜寻团队告诉您答案
作者：张照亮（士恒）阿里巴巴搜寻事业部高级技术专家
- 业务背景
========
阿里巴巴电商搜寻举荐实时数据仓库承载了阿里巴巴团体淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景，提供了包含实时大屏、实时报表、实时算法训练、实时 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 的计算和存储能力，将计算结果长久化存储。
原文链接
本文为阿里云原创内容，未经容许不得转载。