一 DPP整体架构

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

图1.0 DPP服务整体架构

　　平台特性

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

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

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

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

　　二 DPP引擎演进

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

　　固定编排 - DPP-Engine

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

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

图1.2-1 DPP-Engine层编排

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

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

　　灵活编排 - 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未来的可进一步发展的方向：

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

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

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

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

　　图化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>。

　　.

　　"},"attribs":{"0":"*0*1+o"}},"apool":{"numToAttrib":{"0":["author","7055482742607183876"],"1":["inlineCode","true"]},"nextNum":2}},"type":"text","referenceRecordMap":{},"extra":{"channel":"saas","isEqualBlockSelection":false,"pasteRandomId":"4ffb13ad-4b59-4b64-9ddc-3d7433124a0d","mention_page_title":{},"external_mention_url":{}},"isKeepQuoteContainer":false,"isFromCode":false,"selection":[{"id":130,"type":"text","selection":{"start":100,"end":124},"recordId":"V0xHdphHaoEgIpxOK21c6BB3nyf"}],"payloadMap":{},"isCut":false}" data-lark-record-format="docx/text" class="">

　　算子代码中:

　　通过注解 @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数据结构的使用，以进一步提升系统性能。 并且随着引擎及机器学习平台图化的推进，我们有可能也去端到端链路上实现“全图化”。用一张图描述一个业务的策略逻辑。