网站做qq链接代码,网页设计作业怎么打包,静态网站建设的主要技术,商务网站的建设阶段包括简介#xff1a; 自建实时数仓到底难在哪里#xff1f;实时数仓应该怎么建#xff1f;阿里巴巴搜索团队告诉您答案
作者#xff1a;张照亮#xff08;士恒#xff09;阿里巴巴搜索事业部高级技术专家
1. 业务背景
阿里巴巴电商搜索推荐实时数据仓库承载了阿里巴巴集团…简介 自建实时数仓到底难在哪里实时数仓应该怎么建阿里巴巴搜索团队告诉您答案
作者张照亮士恒阿里巴巴搜索事业部高级技术专家
1. 业务背景
阿里巴巴电商搜索推荐实时数据仓库承载了阿里巴巴集团淘宝、淘宝特价版、饿了么等多个电商业务的实时数仓场景提供了包括实时大屏、实时报表、实时算法训练、实时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天的数据在面对计算同比、环比等需求时就需要读取离线数据与实时数据进行关联计算这样产品/运营在看上层报表展现时就能直观看到今年实时数据和去年同期的对比表现。
3. 实时数仓架构
基于上诉典型实时数仓诉求我们抽象出了如下图所示的典型实时数仓架构。 实时采集的业务日志经过实时计算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提供高并发的数据实时写入和实时查询。
4. 基于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满足业务高并发实时更新需求。
5. 未来展望
我们希望未来基于Hologres引擎持续改进现有的实时数仓主要的方向主要有
1实时表JOIN Hologres现阶段支持百亿级表与亿级表之间的JOIN秒级查询响应。基于这个特性期望将原本需要在数据处理阶段由Flink实时作业完成的维表关联工作可以改为在查询Hologres阶段实时JOIN计算。例如表1是明细数据表表2是用户维表在查询阶段的JOIN可以通过筛选用户维表然后与明细数据表关联达到筛选过滤数据的目的。这样的改进将带来几个好处 1减少Hologres中的数据存储量避免实时表中存储大量的数据冗余如同一个商品ID的数据会重复存储 2提升实时数据中维度属性的时效性在查询阶段实时JOIN维表数据后进行计算可以使得我们在通过维度筛选数据的时候始终是用的最新的维度属性。
2持久化存储 我们未来将探索如何将常用维度的实时数据利用Hologres的计算和存储能力将计算结果持久化存储。 原文链接 本文为阿里云原创内容未经允许不得转载。
