作者：兰乾 阿里巴巴搜索推荐高级开发工程师

一、业务背景

阿里巴巴搜索推荐作为淘系核心流量入口，数据量大，对接的业务场景繁多，且需求变化快，同时对数据的实时性和准确性要求都很高，尤其在各业务方大促KPI完成度监控，并支撑算法迭代即时效果监控加快迭代速度，同时也为算法在线模型提供实时训练样本，提升算法效果等方面有着迫切的需求，因此为了满足这些实时数据的需求，在搭建稳定的数据体系过程中，需要解决许多痛点：

1）数据量大，资源有限下，需做到数据生产基本无延迟，并且查询秒级内响应；
2）查询维度繁多，且不固定，随时可能新增维度，需要丰富的明细数据支撑，且具备高扩展性和灵活性；
3）原始日志信息有限，需动态补充满足个性化数据需求；
4）任务、场景多，数据输出格式需要统一化，降低维护和对接成本；
5）需求迭代快，Blink作业频繁变更启停，增加系统不稳定性，需要实现Blink作业变更配置化。

对于实时数据而言，实时性与正确性是最基本的要求，另外鉴于上面提到的痛点和需求，搜索推荐部门结合Blink、交互式查询引擎Hologres，不断优化数据研发架构，最终实现了集数据输出格式化、查询交互式/个性化、Blink任务模板化以及Blink作业变更配置化等功能为一体的大数据研发架构，如下图所示：

二、实现原理

2.1 如何实现数据输出的交互式、个性化、高扩展性

数据输出的交互式、个性化、高扩展性，我们主要结合了Hologres 行存表和列存表优势来实现。

要实现数据输出的交互式、个性化、高扩展性，依赖数据中丰富维度，比如商品、商家、用户的各种特征属性，或者某次用户行为下的特定场景属性等，这些维度(属性)有些是相对固定的基本属性，比如用户的城市、年龄、商品的类目等信息，但有些是有业务独立特征的个性化属性，比如特定的一批商品、特定的一些用户场景等，这些业务上个性化的属性，随时都在新增或删减，并且每个业务查询的维度是不同的，这样不仅需要搭建交互式的多维数据分析可视化输出，还需要能够灵活支持不同业务场景个性化的数据诉求。

个性化维度(属性)主要来源于两个地方，一个是数据采集阶段提取的动态化场景信息，如算法分桶信息等；另一个是原始日志中缺失的个性化信息，例如商品、商家、用户的个性化特征，这些个性化的动态特征最后都按不同的对象属性存储到Hologres列存表对应的多值字段中，例如商品、商家、用户、场景维度信息分别对应Hologres列存表中的多个多值字段：

1）原始日志动态化场景信息

随着不同业务的不同变化，每个业务服务端会将新增的业务信息(维度)下发移动客户端，上报日志中心， 数据研发工程师对应更改日志解析配置，搭配Blink作业变更配置化，就可以0代码发布实现新增维度的无痕提取与透出，对应的业务产品及算法即可在15分钟内查询到该新增维度下的实时数据，例如算法实验动态分桶效果分析等。

如下表1所示，将用户vs商品vs商家行为日志，如曝光、点击、成交、加购等明细日志分别存入各自Hologres列存表，几张Hologres列存表使用同一套schema，其中丰富的多值字段中存放一些从原始日志中提取的信息以及在Blink中关联商品(商家、用户)Hologres行存维表获取的补充信息，是支持交互式/个性化查询的核心字段，高可扩展性和灵活性即席多维分析核心字段。

按照 Who+What+When+ Where + How形式对表schema进行设计，其中How（何事，频次）按用户行为是曝光、点击还是成交加购拆分到不同的表中，行为发生频次则与Who+What+When+ Where 一同设计到表schema中，如下:

表1 用户vs商品vs商家行为日志->Hologres列存表

类型	字段	说明
基础信息字段	When（时间）: second_timestamp Who（人）: user What（货）: item,seller Where（场）: channel	人货场以及事件发生的时间信息
指标字段	How: count,number,amount	人货在场上行为发生的次数(如成交次数 、商品浏览次数)、其他指标(如成交金额、浏览时长等)
多值(维度)扩展字段	item_tags,user_tags,bts_tags,algo_tags ,scene_tags,debug_tags	存放一些日志中提取的信息以及维表关联获取的补充信息，是支持交互式/个性化查询的核心字段，高可扩展性和灵活性即席多维分析核心字段

2）维表关联提取动态个性化信息

为了尽可能地支持更多维度、更个性化和可扩展的查询，若想保留越多的维度特征信息，数据聚合度越高，特征信息损失越多，因此，在Blink作业中将【用户的明细日志】关联上Hologres行存表中商品、商家、用户等对象多种可动态扩展属性后, 并将属性作为多值字段直接写入 Hologres列存表 中，实现任意交叉维度的数据输出。

使用Hologres行存表，存储商品、商家、用户等对象的特征维度信息，每个对象一张Hologres行存表，如下表格2所示为商品的Hologres行存表部分字段, 商家、用户表基本逻辑一致：

表2 商品属性特征->Hologres行存表

字段	说明
item_id	商品id，行存表主键
cate_id等	类目等信息
tags	维度核心字段，商品扩展属性信息，多值，固定分隔符拆分不同属性值，对应数据查询的扩展维度，在blink作业中该字段会合入用户行为Hologres列存表中对应的多值字段item_tags中，最终输出到数据报表中的可查询维度

将海量商品、用户的特征信息存入对应的Hologres行存表，并将业务输入的个性化动态属性定时写入Hologres行存表预留字段，几十亿商品的特征信息仅耗时5分钟完成数据切换，结合Blink partition join 缓存机制，缓存命中率高达97%，使得千万级join qps 实际请求Hologres行存表时仅有几十万qps，行存表中tags信息通过Blink作业关联加工后，最终输出到Hologres列存表，作为查询维度供交互式分析使用。

2.2 如何实现Blink作业变更配置化

面对层出不穷的需求变化，但考虑到日志中存在无效信息，并未将日志中全部信息提取作为可查询维度，需要根据需求变化变更Blink SQL提取，加上Blink作业频繁启停也会增加运维成本，增加业务迭代的人工和时间成本。因此使用MaxCompute(原odps)小表存储日志过滤和解析配置，仅需变更配置内容，将新提取的信息自动写入到Hologres中指定多值字段中，无需变更Blink作业和Hologres表结构，该新增信息就可作为维度任意查询和输出。

由于Blink中需要通过发布及启停作业才能读取配置化的信息，继而完成对实时数据处理的变更，但是搜索推荐所有业务是共用一套Blink作业，且业务频繁变更，但如果因为个别业务频繁变动公共Blink作业，对实时数据体系影响较大，又考虑到搜索推荐实时数仓中选择使用明细数据，因此，在Blink作业中额外关联ODPS表(_存储数据解析及过滤配置，由于表极小，可全量缓存在Blink机器上_)，其中数据解析与过滤配置与存储用户行为日志的Hologres列存表schema是一一对应的，获取到作业所需的解析及过滤配置后，并将上游数据和解析配置同时作为入参输入到通用的日志处理UDTF中，并按表格1中用户vs商品vs商家行为日志->Hologres列存表的schema格式输出数据。**这样仅需变动ODPS表中存储的解析配置信息，即可无痕将从日志中额外提取的信息输出到Hologres列存表中对应的多值字段作为维度可查了。

表3 Blink任务数据解析及过滤配置->ODPS表

2.3 小结

目前搜索推荐大部分作业通过Blink开发产出的是实时明细数据，也就是说并非聚合数据，这样搭配交互式查询引擎Hologres，可以*维度查询，但对交互式查询引擎的要求较高; 若维度相对固定，可以做些轻度聚合后，数据输出到igraph,Hologres,Hbase等存储与查询引擎，可节省资源，但扩展性差，且新增维度需要修改Blink任务。

总的来说，基于__海量的明细用户日志__，__Hologres__高达几千万__QPS__的写入性能，以及灵活的__多值字段__设计，优秀的全局去重能力__，搭配动态维度无变更接入解决方案，使得__搜索推荐实时大数据在低开发成本、低运维、0沟通情况下，既保证了实时数据的实时性和准确性，又提升数据交互式即席分析的个性化、灵活性和高扩展性。

三、即席多维分析场景实战

接下来详细介绍如何通过Hologres和Blink实现1小时内无痕新增分析维度，接入即席多维分析实战场景中。

 3.1 原始日志动态化场景信息

例如需要添加实验桶信息，搜索推荐由于场景复杂，采用的复杂的交叉分桶模式，一次用户行为对应多个实验分桶，每时每刻都会有新增的实验分桶，服务端只需将新增的分桶信息下发客户端，通过数据采集之后，自动转换成Hologres列存表特定多值字段如algo_tags的值，该分桶对应实时数据则可即发即查，加快算法迭代周期。

为减轻存储和计算压力，仅从原始日志中提取核心维度放入Hologres列存表多值字段，因此对于特定业务，新增的个性化场景信息，可以通过变更ODPS表中存放的数据解析配置，即可无痕将新增的个性化场景信息转换成维度添加到Hologres列存表对应多值字段中，例如在推荐中新增的红包业务，且需要将对应的红包信息转换成查询维度，在推荐仅维护一套Blink作业和Hologres表的情况下，基于统一的日志规范，无需任何变更，自动在推荐实时数仓中新增了红包场景数据，另外红包业务中携带的红包信息，则需要在ODPS表中解析配置里新加相应的提取逻辑，比如设置成将日志中红包唯一识别码的值放置到Hologres列存表的scene_tags字段中，则该红包识别码即可作为维度供业务查询分析使用，监控红包曝光等实时效果。

 3.2 维表关联提取动态个性化信息

面对海量的实时数据，如何快速精准地获取、监控我想要的数据呢？这就需要给数据带上所需的维度或特征信息，简单来说主要有以下几点：

1）原始数据日志在大部分情况下，缺失商品类目、行业，用户地域等基本属性；
2）除了使用通用的类目、行业等基本信息，还需要监控某些特定的商品、某些核心的商家、某些特殊的人群下的数据情况，是需要有对应的个性化属性的。
3）如果不关联上基本属性或个性化属性维度信息，就没办法直接过滤查询获取到对应维度下的数据，需要额外关联并二次加工才可获取，无法灵活查询，做不到任意个性化维度的交互式查询。

总结来说，不同业务场景对实时数据都会有不同的需求，需要监控或使用各种基本属性和个性化属性维度下实时数据，但如何满足各种各样个性化的实时数据需求呢？
如下图所示，搭建了维度特征管理平台Seahummer，支持商品、商家、用户等对象的标签特征管理，根据业务方配置的个性化属性，比如卖家分层、用户分层，以及各种自定义的业务属性等，关联到对应的商品/商家/用户上，最终产出对应MaxCompute(odps)维表，并导入Hologres行存表中，在Blink流作业里，关联对应Hologres行存表即可获取相应的基本属性和个性化属性，并标记到Hologres列存表实时数据上输出，这些属性最终以多值字段的形式存储在Hologres列存表中，作为查询维度呈现在可视化报表。

维度的增减，无需更改Blink作业，整体维度变更链路最慢小时内完成维表数据切换，目前业务方已能通过seahummer平台自助打标后，在通天塔数据门户（阿里巴巴内部的一款分析软件）中自助即席多维分析，涵盖1000+自定义维度信息，无需开发同学额外支持，解放人力，减少沟通成本。

1）对象——商品、商家、用户
2）标签数据来源——odps、excel
3）基本属性——商品/商家名称、类目、行业、BC类型，用户地域等
4）个性化属性——指定商品池、特殊人群、商家等
5）与Blink实时流作业打通——Blink流任务关联Hologres维表即可获取相应的基本属性和个性化属性

例如算法新上线了分桶实验，需要对特定商品或人群采取特定的算法策略，只需要对这些商品或用户通过维度特征管理平台Seahummer录入，对应标签则自动流入到相应商品或用户的Hologres行存表中的tags字段，并转换成了用户行为Hologres列存表中的item_tags或user_tags多值字段中，最后以自定义、可扩展查询维度的形式透出在可视化报表中；上述红包业务例子中，需要对重点目标人群倾斜部分曝光流量，这时候同理将重点目标人群打上标识，即可监控目标与非目标人群曝光流量对比，适时调整算法策略，完成业务目标。

四、业务价值

4.1自定义交互式即席多维查询

依托Hologres强大的多维分析能力，以及高并发、无延迟实时写入和全局去重能力，其中全局去重能力解决了在Blink作业异常情况下数据去重问题，保障了数据一致性。在日常及大促期间，承接了搜索推荐海量流量数据，支持搜索推荐算法AB实验实时效果分析，除了有对应的实时数据多维交互式可视化报表以外，还提供了实时数据服务，支持算法在线调用，自动调整算法策略，此外生产的实时数据流，还在Blink中用于算法实时模型训练，加快了算法迭代周期，达到任意查询维度结果秒级响应。

在支持算法AB实验即时查询分析的同时，还支持商家、商品、用户等对象各类属性及标签多维度下的*查询，比如用户年龄、城市等级分层等，以及通过维表或流量日志接入的可扩展的自定义标签及维度，极大地扩展了不同算法、产品、运营、分析师角色即时分析的*度和灵活性。

4.2某特定业务实时大屏

依托Hologres的多维分析能力，还可以针对某些特定独立业务搭建实时监控大屏，比如在该业务促销活动期间，监控对应的成交和KPI完成度，以及分析当前业务触达及消费的人群特征分布，用于即时调整运营策略，完成KPI。