一、DPP 整体架构

DPP 依赖于算法平台的引擎服务（FeatureServer，召回引擎, 精排打分），提供“开箱即用”的召回，粗排，精排服务。采用“热加载技术”解决算法平台的工程和算法同学策略迭代效率问题，支持策略随时发布，让他们可以专注于业务逻辑，即可拥有稳定的推荐在线服务。

图 1.0 DPP 服务整体架构

平台特性

1. 快速迭代：通过系统解耦，实现算法、策略的快速迭代。

2. 效果分析自动化：打通数据平台，BI 数据分析标准化。

3. 灵活实验：通过分层实验平台，支持多层多实验的灵活配置。

4. 诊断方便：落地各子流程中间结果，支持算法、策略的细化分析；提供方便的监控告警，运维，时光机等问题排查工具。

二、DPP 引擎演进

DPP 编排引擎的迭代分为了 3 个阶段：固定编排，灵活编排，图化 DAG 编排；均是在策略迭代过程中，围绕着“迭代效率”提升的不断进化。下面分别介绍下各阶段引擎产生的背景及其方案。

2.1 固定编排 - DPP-Engine

推荐业务一般都可以抽象为“召回->融合->粗排->精排->干预”等固定的几个阶段，每个阶段通常是有不同的算法或工程同学进行开发和维护，为了提升迭代效率，通过对推荐流程的抽象，将各阶段的逻辑抽象为“组件"+"配置”，整体的流程同样是一个配置，统一由“编排引擎”进行调度，同时提供统一的埋点/日志等。让工程或算法同学可以关注在自己的业务模块和对应的逻辑，而框架侧也可以做统一的优化和升级。

DPP-Engine 就是在此基础上，将业务策略抽象为“初始层->召回层->融合层->粗排层->精排层->干预层”这 6 层, 有 DPP 负责串行调度这 6 层，每一层有若干个组件组成，各层将结果进行合并后传递到下一层（也就是 List）。

图 1.2-1 DPP-Engine 层编排

通过分层，DPP-Engine 较好的支持了业务的快速迭代，业务“各层”的开发同学可以独立迭代。但是随着场景的增多，对“灵活”编排有了更多的需求，比如不固定 6 层，层内可有自己的"编排"等。

其次对于 DPP 平台同学来说，DPP-Engine 嵌入在 DPP 系统内, 不利于引擎的迭代和维护。

2.2 灵活编排 - BizEngine

BizEngine 根据策略同学提供的组件及其编排流程，负责执行和调度，包括组件间的并发。它在推荐系统链路中的位置如下图：

图 1.3-1 DPP 系统(BizEngine)

目前在 BizEngine 看来，“组件”是策略开发的最小粒度，策略同学在 DPP-后台中可以在场景维度划分桶（小流量桶, 分层桶），在桶可以配置不同的层编排，默认为 6 层：INIT 层->召回层->融合层->粗排层->精排层->干预层。分别在层内可以配置不同的组件。一次请求中，BizEngine 负责按层进行调度（层与层之间为串行调度），层内的组件根据组件间的依赖进行串行或者并发调度。

图 1.3-2 编排管理及其配置协议

用户请求到 DPP 后, 会通过 AB 分流得到该请求（用户）命中的所有实验（包括桶，层，实验），DPP 解析命中配置后，可以构建出 BizEngine 需要的入参-编排配置（桶配置+实验配置+组件配置），它会根据层及组件的配置构建出执行的层 Stages，按组件维度提交到各线程池进行同步或异步的调度，流程可参考下图：

图 1.3-3 BizEngine 的组件调度和执行

从上图可以看到我们是按层进行串行调度的，“分层”是按推荐的业务策略逻辑来分的，符合工程算法同学的分工和职责，特别是算法同学通常有各自负责的领域（召回模型，粗排模型，精排模型，干预），按层划分和进行实验可以有效提高迭代效率，做到相互之间不影响。“组件”则是 BizEngine 层内调度的单元，但是目前组件的粒度可大可小，比如社区的部分场景，他们在组件内拆分了更细粒度的 Steps，并且独立于组件进行调度（依赖 DPP 场景线程池或自定义线程池），因此策略代码即负责了策略的逻辑, 还需要负责策略逻辑单元（Step）的调度。由此可以看出 BizEngine 未来的可进一步发展的方向：

1. 按层进行串行调度，即便层与层组件之间为串行，也需要按层调度，存在一定开销。

2. BizEngine 的线程调度和策略内自定义调度的冲突，线程池资源难于实现高效利用。

3. “组件粒度”问题：目前看策略同学实现的组件对 BizEngine 来说是“逻辑黑盒”，里面可能是 CPU，也可能是 IO，也可能是一个发起并发任务的模块，可能涉及自定义的线程池资源。

4. 随着业务不断迭代, 策略组件的迁移和重构成本逐渐上升；缺少“组件”/“代码”共享及发现的机制，不利于我们通过“组件复用”的方式去提升迭代效率。

2.3 图化 DAG - DagEngine

为什么需要做图化?

那为什么要去做“图化”/“DAG”呢？其实要真正要回答的是:  如何应对上面看到的挑战？如何解决 BizEngine 目前发展碰到的问题？

从业界搜推领域可以看到不约而同地在推进“图化”/“DAG”。 从 TensorFlow 广泛采用之后，我们已经习惯把计算和数据通过采用算子（Operation）和数据（Tensor）的方式来表达，可以很好的表达搜索推荐的“召回/融合/粗排/精排/过滤”等逻辑，图化使得大家可以使用一套“模型”语言去描述业务逻辑。DAG 引擎也可以在不同的系统有具体不同的实现，处理业务定制支持或者性能优化等。

通过图（DAG）来描述我们的业务逻辑，也带来这些好处：为算法的开发提供统一的接口，采用算子级别的复用，减少相似算子的重复开发；通过图化的架构，达到流程的灵活定制；算子执行的并行化和异步化可降低 RT，提升性能。

图化架构

图化是要将业务逻辑抽象为一个 DAG 图，图的节点是算子，边是数据流。不同的算子构成子图，用于逻辑高一层的封装，子图的输出可以被其他子图或者算子引用。图化后，策略同学的开发任务变成了开发算子，抽象业务领的数据模型。不用再关心“并行化异步化”逻辑，交由 DAG 引擎进行调度。“算子”要求我们以较小粒度支持，通过数据实现节点的依赖。

图化定义了新的业务编排框架，对策略同学来说是“新的开发模式”，可分为 3 个部分：一个是我们会定义算子/图/子图的标准接口和协议，策略同学实现这些接口，构建业务的逻辑图；二是 DAG 引擎，负责逻辑图的解析，算子的调度，保证性能和稳定性；三是产品化，DAG Debug 助手支持算子/图/子图的开发调试，后台侧提供算子/子图/图的可视化管理。整体架构参考下图：

图 4.0.0 - DPP 图化框架

图 4.0.1 - DagEngine

图化核心设计和协议

1.算子

• 算子接口定义 Processor<O>

public interface Processor<O> {    /**     * 执行逻辑     *     * @param computeContext 执行上下文信息     * @return 返回执行结果     */    DataFrame<O> run(ComputeContext computeContext, DataFrame... inputs);}

• 算子注解 @DagProcessor

通过注解可对算子进行描述和提供运行时信息:

@Documented@Retention(RetentionPolicy.RUNTIME)@Target({ElementType.TYPE})public @interface DagProcessor {    /**     * 标记IO/CPU, 影响DagEngine的调度     * @return     */    String type() default "IO";    /**     * 算子描述     *     * @return String     */    String desc() default "";    /**     * 用于标识该算子会输出的一些中间值, 可用于做运行时的依赖校验     * 可理解为是算子OP的side effects     */    String sideValues() default "";}

• 依赖配置 @ConfigAnno)

算子通过注解(@ConfigAnno) 一是声明算子需要的配置(通过 DPP-后台实验配置进行配置), 二是运行时 DAG 引擎会对注解的值进行注入.

• 依赖数据 @DependsDataAnno

算子节点上游的数据，通过接口参数也会透传过来(DataFrame 数组)，算子内可以通过 dataFame.getName()获取数据的唯一标识(请求 session 内唯一)。

算子的返回作为该算子的输出数据，通过 name 可以获取, 比如 @DependsDataAnno(name = "某一路的输出"，desc = "recall1")。

写策略逻辑过程中的中间变量是我们必不可少的，算子可以通过注解 @DagProcessor#sideValues 声明会输出那些数据(names)，通过 name 可以获取。

比如依赖了同一个算子(多个实例)，它的输出 name 是一样的，下游获取需要通过这个优先级决定。

Note：@DagProcessor#sideValues 可能作为必须的，只有 sideValues 声明了的数据，才可以被依赖算子引用，这有助于我们管理和防止依赖不存在的数据。

Note：算子获取 sideValue 时有多相同 name 的数据时，通过配置指定算子优先级。

2.图/子图

• 图/子图/配置文件

图分为图和子图，一个场景可以有多个图，可按垂直桶制定不同的图；子图定位为业务逻辑模版，可以将若干个独立算子组装为具有特定业务含义的“子图”，子图和算子一样可在场景大“图”中进行配置，即运行时可有多个“实例”，实现逻辑的复用和配置化。

图或子图通过“配置文件”文件来描述，考虑到可读性和是否支持注释等特性，确定选用 yaml 来定义。

• 协议

子图

## 子图(定位为逻辑模版, 包含: 若干个算子及其依赖关系, 子图的配置及其默认值## Note: 子图的配置实际为算子的配置, 在算子中引用name: 'Recall子图1' ## 场景全局唯一type: 'subgraph' ## 标记图为"子图"configs: ## 子图包含配置项( 指定默认值 )  - name: 'configKey1' ##     value: '默认值Value, 可为string, json等, xx'  # - 其他配置及其默认值  # ...nodes: ## 子图包含的所有算子, 通过dpends指定依赖.  ## 比如一路召回  - name: 'fistRecallOp1'    op: 'com.dag.demo.recrecall.FirstRecallOP'    depends: []    # 指定子图中该算子的默认值    configs:    - name: 'configKey1'      value: 'fistRecallOp1s value'  - name: 'otherRecall1'    op: 'com.dag.demo.recrecall.OtherRecallOP'    depends: ['fistRecallOp1']

图

## 图(场景逻辑描述, 包含若干个算子或子图, 及其他们的依赖关系, 图的配置及其默认值(Note: 图的配置实际为算子的配置, 在算子中引用)name: '场景图Name' ## 场景全局唯一type: 'graph'configs: ## 图包含配置项( 指定默认值 )  - name: 'configKey1'    value: '默认值Value, 可为string, json等'  # - 其他配置及其默认值  # ...nodes: ## 图包含的所有算子或子图, 通过dpends指定依赖.  ## 比如一路召回  - name: 'fistRecallOp1'    op: 'com.dag.demo.recrecall.FirstRecallOP'    depends: []  - name: 'otherRecall1'    op: 'com.dag.demo.recrecall.OtherRecallOP'    depends: ['fistRecallOp1']  ## 子图1( 为`Recall子图1`的实例 )  - name: 'someRecallComplex1'    op: '$Recall子图1' ## 依赖该子图    configs: ## 子图包含配置项( 指定默认值 )      - name: 'configKey1'         value: 'fistRecallOp1s value'        ## 覆盖这两个算子的默认值        targets: ['recallGroup1', 'dssmRandomBatchRecall']      ## todo 修改op的配置      ##     depends: ['fistRecallOp1']  ## 子图2( 为`Recall子图1`的实例 )  - name: 'someRecallComplex1'    op: '$Recall子图1' ## 依赖该子图    depends: ['fistRecallOp1']

3.算子配置如何获取? 如何配置?

图通过算子(子图)+数据依赖的 DAG 描述了业务的逻辑关系，配置的作用就是影响逻辑如何生效。这些配置通过“实验/AB”来决定，不同的实验就是对图或算子的不同配置。

• 默认值

配置的默认值通过两种方式指定：1/ 算子变量的默认值（代码方式）；2/ 图或者子图的 Confgis#key#defaultValue

• 运行时的值

算子某个配置在运行时的值，是通过该次请求命中的所有实验进行配置融合和覆盖后得到的。

• 如何配置?

实验配置中:

需要考虑配置 key 在子图和算子中的 name 作为前缀，规则为<subGraph'sName>.<op'sName>.<key'sName>，若算子不在子图中（即, 直接配置在主图中），那么配置为_.<op'sName>.<key'sName>。

算子代码中:

通过注解 @ConfigAnno(key = "key'sName")来获取对的 key'sName 的值. 运行时 DAG 引擎负责识别<subGraph'sName> 和<op'sName>。

配置支持 json 和 dto 对象绑定，DAG 运行时实现缓存和校验指定 Json 配置和类的映射，@ConfigAnno(key = "somepojo.value"，isJson = true，clazz = SomePojo.class)，DAG 引擎负责反序列化。

图化相关特性/结果

• DPP 图化落地广告/社区等场景。

• 图桶推全 SOP 流程: 通过引入"分支"概念，图桶推全变为合入 Master，待推全各桶由各 Owner 自行合并 Master。支持一分支绑定多桶。简化了场景编排迭代流程。

• 图编辑可视化: 支持算子及其依赖的表单化修改，提升修改效率和易用性。

三、总结

DPP 编排引擎经历了固定编排，灵活编排到图化 DAG 编排三个阶段，持续提升策略迭代效率。

图化 DAG 编排在我们落地的一些场景中显著提升了性能，同时新的开发模式要求策略同学关注算子级别的实现，减少对调度逻辑的关注。在产品侧 DPP-后台提供了产品化工具支持本地调试和可视化管理。

未来我们可以进一步探索图化 DAG 编排在更多业务场景中的应用，尤其是需要高性能和灵活定制的场景。其次加强算子复用机制和标准化建设，降低组件迁移与重构成本, 持续优化 DagEngine 的高性能特性，如 DataFrame 数据结构的使用，以进一步提升系统性能。 并且随着引擎及机器学习平台图化的推进，我们有可能也去端到端链路上实现“全图化”。用一张图描述一个业务的策略逻辑。

往期回顾

1.Cursor 在前端需求开发工作流中的应用｜得物技术

2.得物 iOS 启动优化之 Building Closure

3.分布式数据一致性场景与方案处理分析｜得物技术

4.从对话到自主行动：AI应用如何从 Chat 进化为 Agent？开源项目源码深度揭秘｜得物技术

5.得物技术部算法项目管理实践分享

文 / 在东

关注得物技术，每周一、三更新技术干货

要是觉得文章对你有帮助的话，欢迎评论转发点赞～

未经得物技术许可严禁转载，否则依法追究法律责任。