优酷用户触达平台技术大揭秘

作者| 阿里文娱技术专家 曾辰

责编 | 李雪敬

出品 | CSDN（ID: CSDNnews）

 

前言

优酷在用户运营场景上，沉淀了丰富的用户运营及营销触达策略。为了保障用户的持续活跃，当用户进入产品生命周期的后半段（预流失/流失状态）就需要精准洞察用户，在恰当的时机，通过正确的渠道，向用户推送个性化的内容达到召回、转化及促活的目的。但当我们深挖这些用户触达运营场景时，发现如下问题： 

1）触达渠道建设成本高，PUSH、站内信、短信、微信公众号、支付宝生活号等触达场景接入各业务时，存在重复建设接入的问题；

2）过分关注单一触达方式在局部场景的应用，缺乏整体视角和统一机制，包括渠道间的联动及频次控制；

3）数据分析及沉淀能力薄弱，有单点数据，但缺少整体链路数据，同时触达策略无法复用等。

基于以上问题，我们打造了优酷统一触达平台， 它是基于用户行为分析和洞察一站式触达平台，打通了优酷业务域内人群、素材、渠道、触达策略全链路，支持触达AB实验迭代能力，提供全链路效果数据。 

触达平台目前整体架构大图及业务能力如下，除了支持主动触达矩阵外，还支持搜索、小喇叭等非标资源位的触达。除此之外，结合入口人群、策略编排及执行、数据回流构成了整个触达平台的链路。 

                       

平台架构实现

从平台架构大图中可以看到，架构核心主要包括入口层、策略层、通道层。人群及事件作为平台入口层，接入各类业务的能力，它控制了平台整体的起始调度执行；策略层是整个平台的中枢，提供触达策略的制定及执行；通道层整合了各个底层触达通道，它的核心是物料和数据源的能力。三层架构自上而下，共同组成了触达核心链路，下面针对各层的主要模块进行拆解。

一）人群及事件

统一触达平台作为触达业务的承接方，需要对接众多的业务触达需求，所以对平台的适配能力提出了很大的要求。而作为入口节点，承担了主要的职责。目前我们主要提供离线人群、业务事件适配，离线人群主要针对用户运营等场景，而事件主要用于实时系统通知及外部业务对接的触达能力。

离线人群

离线人群是通过人群标签圈选，通过数据接口导入人群数据，从而进行逐一的触达。离线人群处理最主要的挑战，是如何保障人群发送效率，在尽可能短的时间内完成发送。基于这个目标，我们采用阿里集团分布式任务调度服务的分布式调度能力，基于大人群分片，多层下溯，充分利用分布式的能力。

调度引擎也是基于任务调度的引擎。根据任务类型主要分为流程任务、等待任务；流程任务主要针对离线人群流程入口节点的调度，而等待任务是流程任务因在等待节点中断流程执行，在之后恢复执行的任务。目前支持多种调度策略，定时、立即发送，单次、周期任务，最终转化成调度表达式。流程任务的整体调度流程分3层：

1. 获取人群类型、人群数量以及分页等基本信息；
2. 分页获取人群用户列表，并完善用户账户信息；
3. 根据配置细分成更小的人群分片，分片信息暂存 nosql。 

人群任务及事件任务都支持流程等待，因为人群策略实现上略有差异，所以等待流程的实现也略有差异，但整体一致。任务暂存至 nosql 数据库，以任务需恢复时间时刻（分钟）为 key，等待任务的调度需要每分钟扫描以当前时刻为 key 的等待流程。

通过分布式的能力，能非常高效的完成人群的调度，但也因此引入了其他的问题，内存与线程等问题，最终，我们在发送效率及服务稳定性之间找到了一个平衡点。

1. 人群规模不可控，经常会有上亿的人群场景，人群信息预加载内存后，短时间对内存产生了极大的开销。为了解决这个问题，我们引入了 nosql 进行了人群信息的暂存，在子任务执行时，再预加载人群数据；
2. 人群任务触发时，执行引擎线程都是满负载运行；最初我们考虑运行效率，在触达渠道节点又引入了一层异步线程，但事与愿违，异步线程池的等待任务队列在短时间打满，并又占用大量内存，最终取消了异步发送逻辑。另一方面，除了渠道服务，触达的物料素材可能会依赖于外部数据源，在高并发服务调用下，对下流业务服务产生了极大的压力。为此，我们引入匀速器模式，针对各个业务提供的预设 qps 执行调用。

消息事件

消息事件的实时性、业务数据能力，正好是离线人群的补充。消息事件也是触达平台对外部业务提供的较为便捷的对接入口。同时，我们通过消息事件将会员触达系统、人群导入等内部的链路拉通。通过事件方式接入，消息的触达时机由业务侧控制，触达平台业务通过等待节点对消息发送时机做干预。

为了能支持各类业务方，也为了减少业务方的对接成本，触达平台对接入消息不做任何协议约束；完全依赖触达平台的事件适配能力。业务方只需要提供消息topic及tag，以及消息体样例。为了解决消息的适配，触达平台的事件管理主要提供了以下能力：

1. 消息过滤器，通过 MVEL 表达式提取目标消息；
2. 目标字段映射，规范触达内部的消息格式；
3. 占位符及参数表达式，消息数据加工；

通过以上3个能力，基本解决了消息统一适配的问题。通过 MVEL 表达式，可以灵活的支持各类业务需求的配置。总结下，消息事件的处理就是如下的流程：

上面提到，离线人群的缺点是无法携带业务内容，这对一些千人千面的触达需求不能很好的支持。而业务消息在一些营销场景下也不能很好的支持，基于此我们引入了 ODPS 数据导入的能力。它有离线人群的业务特性，又有事件消息的业务能力，而且技术实现上统一将导入转化成消息事件，使其与消息处理逻辑保持一致。目前导入是针对一些特有的业务场景，使用频次会较低，但其自由度较高。导入人群实现方案结合了离线人群以及事件人群的能力，能在满足业务诉求的同时能有较高的发送效率。

二）策略执行引擎

策略即触达业务逻辑，作为统一触达平台，我们希望通过编排来替代原先需要硬编码的业务逻辑。触达平台通过一种有向无环图的形式，来形象的表述这种策略。当然上面讲的人群及事件、以及后续会着重解析的物料模块都是策略的一部分。但这一部分，主要来分析下整体的图形策略编排、以及策略执行引擎。

首先，需要明确节点、边的定义，通过对触达关键链路的拆解，明确了下如下节点和边的搭建规范。 

按照规范，我们产出了如下触达策略。实现层面，我们用 node，edge 两个列表进行存储，通过首尾相连，组成一个 Graph。节点以及条件边都有对应类型的控制器实现，通过解析后的 Graph，依次执行对应控制器。

在执行阶段，执行引擎根据策略编排规范，逐一执行各个节点。当然，前置数据预处理、调度逻辑已经在人群、事件入口已完成。执行引擎执行顺序如下：

1. 接收人群分区任务、事件消息任务以及等待任务；
2. 获取流程对应节点流程图；
3. 执行上下文数据预处理，并进行执行引擎数据收集；
4. 定位首个执行节点，等待任务需要从上一次终端节点下一个节点开始执行；
5. 执行首个节点对应控制器；
6. 节点执行结束，获取后续节点列表，并逐一执行；
7. 节点中断或所有节点执行完成，更新相关计数，退出执行引擎。

执行引擎的职责比较明确，需要保证触达任务高效稳定的执行。主动触达场景对执行引擎的执行效率没那么大的要求，只是针对大人群的触达，因为耗时较久，目前主要的瓶颈还是下流服务。对执行引擎主要性能要求，来源于被动触达场景，因为面向C端，对RT及RT稳定性有很大的要求。这块将是后续执行引擎优化的重点，同时对任务间的资源隔离也是需要着重考虑的点。

三）物料及数据源

触达平台的物料，泛指渠道节点依赖的素材。物料基于渠道模板配置，且支持事件、自定义数据源的占位符渲染能力。模板能力相对简单，但在物料模块实现上需要对模板进行对应的支持，所以模板的实现应该较为的通用，便于后续模板的扩展及改动。物料的渲染是对预设占位符的变量能力的替换，从而实现不同用户触达消息的个性化能力。目前我们已支持事件占位符、数据源占位符。

1. 事件占位符只针对事件流程，可以对事件消息体内容进行逻辑加工处理，产出我们需要的占位符变量；
2. 数据源占位符相对通用，不局限于流程类型，对定义的数据源结果进行二次加工产出需要的占位符变量。这个的数据源一般是一个外部的服务，需要预先确认服务，方法，以及入参出参的映射。

数据源难点及实现

物料渲染阶段，相对较为复杂的是数据源占位符的渲染，有以下难点：

1. 数据源入参不足

    事件、导入人群，因人群本身就携带了业务参数，使用相对方便，一般数据源入参都能映射到人群消息变量上；离线人群本身只携带了用户id，所以在很多业务场景使用数据源能力会受限，非常受到限制；

   实现方案

   a) 任务配置环节，通过与其他平台的交互，引入对应的业务入参，业务参数在任务级别是静态的，通过数据源调用在实现消息个性化；

   b) 通过ODPS业务数据表导入，人群信息同时携带业务信息；借助ODPS的开发能力以及数据动态更新能力，能覆盖各类负载的触达需求。

2. 复杂业务配置受限

   数据源能力目前仅支持在物料占位符上，一个数据源配置一个服务调用，对需要多个服务组合调用场景并不能很好的支持；目前需要通过硬编码的形式再产出一个新的服务

   实现方案

   a) 将数据源的能力扩展至前置节点中，通过串行编排，实现数据源链式执行的能力；

   b) 支持数据源之间的联动，通过上下文传递数据源占位符等信息，作为后续节点的输入。

3. 高并发场景

   离线人群使用阿里分布式调度服务MapReduce模型，事件人群直接是对消息队列的消息消费。在流程执行中，对物料模块会产生极大的压力，数据源服务提供方的RT参差不齐

   实现方案

   a) 基于入口节点的高并发执行场景，数据源不适合异步化，异步执行在高并发场景时会使数据源任务场景大量的堆积，最终会产生大量的内存压力；

   b) 权衡整体的平台负载及触达性能，我们采用了数据源的同步调用，针对多数据源场景进行并发调用以提高整体的执行效率。

数据能力

基于触达平台化的背景，必须提供一套可复用的数据能力，来适配未来各类的业务的数据需求。在明确了触达转化链路上的曝光、点击、转化等各个指标项后，我们通过统一的埋点，拉通整体的数据回流链路，真正提供平台化的数据能力。

数据回流

触达平台定义 utrace 用于关联整个触达营销业务链路，一个 utrace 可以追溯到触达营销计划，触达渠道，内容素材，实验分桶，算法相关信息，以及其他统计维度的字段。在执行投放任务时，自动化营销平台基于上述字段生成 utrace。最终，通过 utrace，将渠道侧的曝光、点击数据，收银台的到访，下单进行统一串联，关联触达计划、实验分桶等。

总结及展望

目前，优酷统一触达平台能力基本完善，通过人群圈选、事件消息对接各类触达业务的能力；通过策略编排，结合实时条件边、数据源自定义等能力，能够承接复杂触达编排业务场景。在系统性能方面，目前平台承接了大量业务事件消息链路，执行引擎能在毫秒级别完成策略的执行，真正做到实时触达；同时每日执行的人群任务，能在小时级别内完成千万级别人群的触达，同时支持多任务并发执行，真正做到高效触达。在系统稳定方面，为了避免任务间相互影响，我们通过执行线程预分配进行隔离，保证各业务链路的稳定性。同时利用限流的匀速器模式，保证资源及外部数据源的平稳执行，减少流量尖刺等带来的系统异常。

未来，我们在技术层面对平台的建设，主要是两个方向：

第一，  建设全域触达矩阵，拉通主动触达场景的编排能力。主动触达不同被动触达，因为直接面向C端用户，需要有更高的系统稳定性，以及更短的响应时间，这对平台策略执行引擎提出了更大的要求

第二，  支持状态跃迁的策略能力。需要引入状态机机制，对用户状态进行生命周期式的管理，这对平台的架构会是一个很大的挑战。

更多精彩推荐
☞实用小技能 | 用 Word 和 Excel 自制一个题库自判断答题系统！
☞中国数据库产业的“高地战事”
☞融资 2000 万美元后，他竟将核心代码全开源，这……能行吗？
☞Get了！用Python制作数据预测集成工具 | 附代码
☞学会这10大高性能开发技术，轻松躲过裁员名单！
☞小心！你可能玩了假的DeFi
点分享
点点赞
点在看