推荐系统架构治理

1. 推荐系统业务现状

从图中我们可以看出，推荐系统大体可以分为三个阶段，最初的探索阶段，早在2010年左右，已经有了千人千面的说法，现在我们在学习推荐系统时，看一些文档或者资料，大都会拿亚马逊基于协同过滤的推荐、豆瓣基于标签的推荐系统做介绍，它们都是早期推荐系统应用在工业界的代表。到了第二阶段 ( 普及深入阶段 )，淘宝、京东以及一些垂直行业开始大范围尝试个性化推荐，此时，工程架构，算法策略层面都有了一些新的发展，比如一些大型推荐系统已经开始向实时特征，实时模型方向进行探索，以提升时效性，从而达到更好的推荐效果。到了第三个阶段 ( 规模化精细化阶段 )，进入移动互联网时代，推荐已经不仅限于PC端的单一场景推荐，出现了移动端及多场景的推荐需求。现今，从拼多多、快手、抖音的推荐，再到百度、头条的信息流推荐，推荐系统已经成为一个网站的灵魂，驱动着各种各样的业务场景，在这一阶段，智能化，工程化，标准化，注重开发效率和成本已成了技术探索的新方向。总体看来，推荐系统的发展趋势是一个从无到有，从有到精的过程，不管是工程，算法或者场景业务都有了深入的发展。

2. 业务趋势

推荐系统从业务方面来说，呈现四个趋势：

① 场景更丰富：早期做推荐的时候，推荐的开发门槛和成本很高，一个网站集中精力维护好一个场景，那时最经典的场景可能就是主页下方的"猜你喜欢"。到了现在，多端，多个资源位，更多的细分场景都会有推荐需求。举个例子，从进入页面的"猜你喜欢"，导航九宫格的推荐，再到列表页或下单页的"看了又看"，"买了又买"，乃至在一个资源位上多个时段都有个性化的需求。在技术层面上，过去一个系统支撑一个场景或者一种模式，或者为了简单，一个架构，一个数据流，一个模型勉强应付多个场景，已无法满足业务精细化运作的需要。现在，一个推荐系统需要支持很多的场景，不同的场景也需要有不同的数据流，业务逻辑，模型来深入刻画；另一方面，早期做推荐系统是一个门槛很高的事情，对工程、算法的要求比较高，且业务逻辑高度定制，很难标准化、低门槛的开发，而现在随着场景越来越丰富，推荐需求的旺盛增加，原来的工作模式已不能满足需要，推荐场景开发需要向灵活化，标准化，规模化发展。

② 运营更精细：从简单规则 ( 比如像置顶，置底，黑白名单过滤 ) 向复杂规则转变，通用规则向个性化规则转变；技术主导变为技术+业务联营。推荐系统的效果好坏不再全是技术主导，业务也利用内容物料，规则玩法等运营手段发挥重要的作用。

③ 服务更实时：早期推荐模型都是基于历史数据采用离线批量的方式构建，离线的特征，离线的模型，导致系统时效性差，用户实时或近实时行为的影响无法体现在推荐的结果中，用户体验不好。让用户能够更快感受到变化，批量非实时向流式实时闭环推荐发展是推荐效果提升的必然趋势。

④ 未来的重要趋势：系统更智能，更知心。早期的一些简单算法或者规则，被更丰富，更复杂的AI算法所替代。推荐系统与AI结合的越来越紧密。推荐系统已经成为AI赋能的重要场景之一，如何构建一套对AI友好的推荐系统，在技术上也是一个很大挑战。

3. 带来的技术挑战

① 当前推荐系统的基本架构

在前面所讲的业务大趋势下，推荐系统技术层面正面临一些挑战。我们先了解一下当前推荐系统的基本架构，一般分为五个板块：

• 数据流：推荐系统的特点就是高度和数据流相关，那么技术层面要解决数据怎么来，数据怎么用，数据怎么加工处理，正确性和时效性如何保证等问题。

• 离线板块：系统内涉及到一些数据加工，任务处理，模型生产，指标报表等离线任务，怎么协调这些任务有序高效进行，并获得正确有效的结果。

• 在线板块：推荐系统对外提供实时推荐的能力，涉及到诸多的在线处理过程和规则。如何在适应业务快速变化的同时保证可用性和性能是至关重要的。

• AI：当下推荐系统的重要组成部分，其包含整个AI模型生成到服务的全生命周期。如何从系统层面支撑AI全生命周期以及如何有机集成进系统是一个挑战。

• 基础设施：推荐系统是一个多领域交叉的综合应用，需要有众多的中间件、基础组件做支撑，如何管理和运维，减少依赖，有效利用是一个重要的命题。

上面说的五大板块，对照起来实际上就是这张示意图。虚线框是数据流，蓝色框是离线部分，黄色框是在线部分，绿色的是基础组件。相较于简化的示意图，在实际系统中，会变得更加复杂。比如就日志或数据收集这一部分，日志就可能因为来源，收集方式多样，导致开发，维护和管理的复杂度激增。各家公司的推荐系统涉及到大量的应用服务和中间件，它们的技术选型，实现方式，部署方式并不完全一致，但是整体逻辑结构却是可以映射到刚才提到的五个板块内。但是这样的架构存在什么问题呢？我们可以结合四个趋势来看，如果只针对性的支撑一个场景，这样是可以的，但是当场景变得更多，更精细，问题便出现了。比如"猜你喜欢"，"看了又看"，召回物料可能不一样，召回的算法逻辑可能不一样，精排模型可能不同，甚至整个处理流程也可能不一样，而它们却在一个代码模块中，各场景的逻辑必然会形成耦合，互相影响，继而影响系统稳定性。另一方面，因为板块割裂，很多领域逻辑分散在服务或中间件中，比如数据处理一般采用Azkaban/Airflow一类的中间件系统去调度处理任务，这就不可避免的将业务逻辑用大量的胶水代码封装在中间件系统中，如果一个开发者想要了解一个推荐系统的业务流程，就会变得非常困难。随着业务的不断发展，这一现象会加剧，大量的场景规则，服务，运营策略，算法模型越来越多，最终导致系统难以维护，变成谁都不敢动的“老古董”。

② 当前推荐系统面临的技术挑战

我简单的总结了一下，主要有四方面的挑战。

a. 开发运维部署迁移困难，曲线陡峭，效率低下。因为推荐系统等智能系统，都涉及到大量的基础组件和服务，各有特点，缺乏一体化的管理运维手段，如何把完整系统搭起来并管理，期间中间件或者服务出问题，都可能会导致系统不可用。这对于没有丰富的组件维护经验或者人力不足的团队来讲，是一个巨大挑战。

b. 这实际上是一个应用治理的问题，服务，流程，规则，策略，数据，产物繁多，组织管理困难。图中任何一个框是一种服务，也可能是若干个服务，这些服务之间的依赖不直观，很难管理。数据流逻辑繁琐复杂，系统有很多的离线数据流，在线的数据流，还会产生大量数据产物，缺乏标准化的管理，极易出错。不同场景的差异化难以组织，不同的服务，策略间相互影响，其中一个可能表现就是在一个服务模块代码中因为要处理不同场景的逻辑而产生大量if分支逻辑。从架构上讲，一个好的场景服务应该是纵向切分的，不同的场景是不同的系统，场景间互相隔离，但这又会导致系统资源浪费，管理上面也很麻烦。因此，需要采取更加系统化的方法去治理它。

c. 系统涉及到数据/在线/离线/AI各个领域，技术栈割裂，整个推荐流程需要大量的胶水代码来整合集成。而胶水代码的一个特点就是难以复用，不同人之间也难以维护。这样的割裂突出表现在以下三点：

• 众多领域技术，彼此割裂，难以集成

• 数据质量难以保证，效果也无法保证

• 定制性胶水代码驱动，无法复用，迁移

d. 大量重复程序化工作难以避免。在面临支持多个场景的情况下，表现很突出。落地一个新的场景，可能需要各个系统配合开发，部署，而且这个过程是高度重复和繁琐的，最终导致成本很高。这也是现在大一点的公司，为了效率和标准化，开始推动推荐系统中台化建设的一个原因，其目的是能够在一个平台上低成本的完成场景的快速开发和应用。

上述这些问题的表现都可以用一个字来总结，那就是"乱"。

4. 如何戡"乱"

那么我来讲一讲如何戡乱，首先我们深入分析一下乱的原因。

① "乱"的原因：

a. 智能系统特有的复杂性，涉及到庞大的服务依赖，数据依赖，知识依赖。推荐系统涉及到的服务模块很多，而一个服务又涉及多个依赖，整个服务的依赖关系就会很复杂，从而管理上就需要很大的成本。数据依赖层面，系统涉及到大量的原始摄取数据，中间加工数据，以及最终的结果服务数据，数据的质量对最终的推荐效果影响是至关重要的，而这种依赖又非常的隐含，极易出错还难以排查。最后，特别提出"知识依赖"这一概念，推荐系统一直以来在应用系统中以其技术复杂性著称，其在工程上，策略上，数据处理上，算法模型上，有很多模式经验及潜在技能门槛。但这些知识在系统中是隐性的，存在于架构师、专家的脑袋里面，并没有固化和沉淀到系统内。强依赖架构师凭借自己的认知和经验去构建，驱动整个系统流程。而正是因为是人来主导，那自然会随着人的水平的高低以及偏好，产生实现上的差异，难以沉淀和继承，后期持续演化也会很脆弱。

b. 领域架构缺失 现有的框架都在解决局部问题，需要抽象出一层专门解决推荐场景应用开发领域自身的问题。比如Airflow是做离线任务调度领域的平台工具，Flink是做数据处理领域相关的框架，这两者都是各自领域很优秀的框架或平台，但是要解决推荐领域的问题，他们都只能解决其中部分子领域问题，缺失一个面向推荐领域的一体化平台或框架，其结果就是从业务问题直接穿透到子领域层，在实现上，缺乏抽象和隔离，使用胶水代码将下层服务拼接在一起完成逻辑实现。虽然子领域框架能够解决了一些局部问题，但它们之间如何协同，管理，以及在其之上更有序的解决推荐领域层面的业务问题成为了如何让架构更好服务场景业务的关键。所谓戡乱，就是需要形成一个中间推荐场景开发的领域层，承接服务依赖，数据依赖，知识依赖，并协调子领域服务更有效工作。

② 这一层应当如何做？

a. 统一的场景开发和管理接口。对于上层来讲，开发一个"看了又看"，"买了又买"等不同的场景，开发过程和接口应该是相似的，只需要面向这一层开发，无需关注下层细节。

b. 统一的底层架构和集成标准。下层非常复杂，涉及到众多子领域，作为开发者，常常在选型和集成上犯难，也无法将它们协调起来，那么我们需要这一层能够把复杂度给屏蔽掉，开发者面对的是统一的数据结构和接口规范，而无需关注具体的执行层选型和实现。

c. 领域内要素治理：

• 合适粒度的领域实体抽象及实现。在推荐服务中，有大大小小的服务，规则，策略及数据，我们称之为领域资源要素，它们需要有合适的领域抽象和粒度，粒度不能太大，也不能太小。是一个规则那么我们就用规则去承载，如果是一个服务，那么我们就应该用一个服务来承载。这样能够在提供灵活性的同时，控制整体复杂性

• 统一灵活的管理方式。我们需要针对领域要素有统一灵活的管理方式，领域的业务逻辑通过统一的编排管理方式来构建。

• 成熟可复用的单元。资源要素的载体是成熟可复用的单元，组件、策略等避免重新开发，产生重复的成本，应该通过复用让使用者更低成本使用。

有几个指导思想，来指导我们具体应该如何将这一层做好。

02

推荐系统"治理"的指导思想

1. "治理"的指导思想

① 声明式 ( Declarative )： 解决复杂系统，复杂流程管理的灵丹妙药。早期在没有k8s的时候，微服务运维管理是一个复杂的过程，需要人工编写很多的脚本完成应用的部署更新扩缩容等工作，使用者必须明确描述其所有操作细节。因为相对于声明式，这种过程命令式的运维脚本，需要使用的人要能够掌控过程执行所有细节，这对于大型复杂系统来讲是一个很大挑战。声明式编程的思想流行会使这样的工作大大简化，服务负责内部自身复杂运行逻辑，上层使用者只需要声明出自己的目标即可，系统自动帮你完成，无需关注其达成目标的具体过程。就像SQL一样，之所以大家用着觉得简单，其很大原因是SQL就是一个声明式的编程语言。这一思想已经逐步成为架构师解决复杂系统管理的推荐思路。比如，当下很热门的运维部署框架Ansible，运维人员只需要按要求编写安装部署剧本，系统就会自动安装和部署相应的服务。

② 框架平台：在目标定位上，是开发一款工具，还是开发一个框架平台，会直接影响到我们的系统设计决策。工具的特点是被集成，可以为使用者提供更灵活有效的手段解决具体问题，但对于使用者本身有比较高的要求，最终结果如何，高度依赖使用的方式。而对于框架来讲，将实现过程让渡给框架，开发者无需了解全过程，只需要按照框架提供的规范进行开发即可，这一定程度约束了开发者的行为，也降低了上手门槛，这实际上是依赖反转思想的体现。我们提到的知识依赖，就可以通过框架或平台把它们沉淀下来。而使用者自然会在框架的帮助下，使其开发的系统是相对可靠的。比如web开发框架Spring，亦或是持续集成平台Jenkins，它们的作用就是提供一个领域业务模式或流程，能够使得初学者只需要掌握平台或框架的使用便能在其领域达到一个比较高的水平，获得方法论指引，避免前人的错误。

③ 组件化：其特点是标准化，复用性和灵活性。框架和它是依存关系，是它的契约，组件是按照契约去实现及被集成。

④ 低代码 ( LowCode )：特点是简单，快速。当下比较热门的概念，一个框架或者平台，不需要写代码或者少写代码就能够完成开发，是基于框架开发基础上的更进一步，能够将业务过程，核心逻辑封装成一些低代码的模块，这对于简单化业务过程，降低使用门槛有很大的帮助。

2. FlowEngine

基于上述的挑战及解决思路，第四范式研发了这样一个声明式的、低代码的、组件化的智能场景开发和管理的框架平台。在这个框架基础上可以快速开发和管理推荐等智能场景。

03

Flowengine架构

接下来简单介绍一下Flowengine架构，它位于场景业务服务和子领域执行层之间。它的出现其目的便是将我们缺失的领域层补充上。

1. 表现

Flowengine提供了一套声明式API，可用来创建，管理智能场景 ( 推荐 )，表现为以下方面：

• 场景沉淀，迁移，快速构建。在框架无状态的前提下，将应用逻辑，业务规则和服务依赖保存成一个方案文件，从而做到可以在不同的Flowengine平台下无痛迁移分享。

• 领域要素 ( 组件，JOB，FUNC等 ) 的管理，集成，更新。提供要素的开发，发布，集成，运行等全生命周期管理，使得其能够在明确的标准下被集成和管理。

• 业务逻辑编排 ( 批/流/在线pipeline )。场景业务逻辑是对领域要素的逻辑编排，这就使得其天然具备敏捷性，业务上也能做到垂直切分隔离，却共用相同的执行底层。在业务隔离和资源共享层面达成了统一。

• 预置核心组件及标准流程方案。简单的业务可以通过已有方案自动的生成推荐服务，达到开箱即用的目的。如果存在场景差异也可以在此基础上进行修改和完善，但修改过程仅仅发生在方案场景层面，从而有效的控制了修改风险蔓延，做到了框架与方案的分离，从而在易用性，规范性与灵活性，差异性上达成了统一，这个在传统架构上是一个不可调和的矛盾。

• 标准化的底层集成方式，上层简单，下层开放。标准化的底层集成方式，均采用业务组件或技术组件的方式集成，对上层呈现为可被pipeline编排的资源要素，使用者无需关注执行层差异。这样就保证了上层是接口简单，下层是开放的。

2. 构成与基本实现

简单说一下它的构成：

• Flowengine-Hub：用于存放方案，组件，FUNC/JOB等资源要素的仓库。

• EngineManager：用来管理和监控引擎并作为适配层屏蔽下层复杂度。

• EngineKernel：单个引擎的核心，用于管理当前引擎领域实体，业务流程，并提供运行环境及通信支持。

• Flowengine-Data：一个AI/BI为一体的数据服务，用于管理引擎数据、元数据及对外提供统一的数据流服务。

基本实现：

• 基于k8s微服务管理。从大的架构上看，Flowengine是一个CloudNative架构，通过利用k8s的能力，实现了引擎内微服务的管理及动态化。一个引擎是由一个或者多个微服务共同组成，运行组件的标准格式是在docker镜像基础上再封装而来，天然容器化友好。另外，在Docker和k8s的支撑下，框架对于基础环境的复杂性有了很好的适应能力。

• 在计算引擎层面，集成了Spark，Flink以及自研的模型训练 ( GDBT ) 等框架，通过进一步的集成优化，使得开发者无需关注这些框架的使用细节，通过统一的编程接口便能够完成开发。

• 批流一体的数据流管理及元数据管理，引入数据摄取，加工，服务三个过程，抽象出一，二，三级表的抽象表概念，开发者无需关注数据的存储和计算细节，采用统一的方式完成数据流开发，从而降低开发的复杂度及分散性。

• 业务编排框架。提供批，流，在线三大可视化业务编排能力，使得业务逻辑开发变成了无代码的拖拉拽操作。另一方面，通过集中的编排管理及任务分发，解决了场景业务逻辑散落在各个执行组件中的问题。在引擎层便能够管理业务全过程，这对于后期开发维护都大有帮助。

接下来我们介绍一下应用Flowengine之后的架构是什么样子的。

04

应用Flowengine后推荐的架构

1. 业务分解与技术映射

业务分解：如图，业务上一个推荐的场景大体是这样的，它包含在线的业务流程，这一个流程大体可以分为召回，过滤，粗排，精排等几个部分，这里通常会因为业务过程的变化而变化。另一块是数据处理及离线处理，这里会有数据怎么获取，加工，以及提供给在线服务使用的逻辑。它也会随着业务变化而变化。最后一部分，对于智能推荐，人工智能的作用举足轻重，它包含数据接入处理，特征工程，模型训练，模型服务等多个过程，这其中也包含了离线和在线等诸多服务模块。

技术映射：那么，对于上述分解出的三大业务部分，在Flowengine框架上如何映射呢？转化到Flowengine上面，我们用引擎的概念来映射，一个推荐场景就是一个引擎，如图，这个引擎我们可以起名叫reco-engine，这个引擎里存在一个在线编排的pipeline叫reco-func-pipeline，而它就具备把推荐服务流程通过编排表达出来形成在线服务能力。Flowengine-Data支持数据的接入，它提供数据的摄取和服务的能力，比如说是kafka数据引入，ES或者Mysql的服务输出，并提供数据表之间的处理能力，开发者只需要关注数据流本身的处理逻辑，而无需关注数据的存取和调度。而对于AI模型服务来讲，它也是一个引擎，在引擎内部便能完成AI模型从开发到部署的全流程。场景引擎reco-engine只需要在需要模型服务时调用该AI引擎的服务即可。这样我们一个推荐的场景就变成了一个主场景引擎及若干AI模型引擎构成，而它们的底层资源管理和调度都无需场景开发者关心。和我们之前讲的传统架构比，结构上清晰了许多，而这一切都归功于必要的领域层抽象。

2. 带来的价值

接下来我们总结一下应用了Flowengine之后带来的价值：

• 面向Flowengine声明业务过程，简单，统一。声明元数据，声明编排过程。我们不需要管理执行层的具体细节，使得复杂度大大降低，业务过程也变得更加标准化。

• 服务及中间件数量减少，资源消耗减少，维护方便。推荐系统因为业务上的发展，会增生很多小服务，这些服务管理麻烦，还占用资源。比如说推荐系统一般会一个兜底的服务，定期生成静态的推荐结果，用来在正常推荐响应失败时降级出推荐结果。在Flowengine的支持下，可以通过创建一个离线的pipeline解决这类需求，那么这样的小服务就可以避免。

• 逻辑分层，合适的拆分粒度。服务，策略，脚本，配置都能够合理安排，体现最小知识原则，其灵活性，复用性更强。

• 减少大量胶水代码和重复代码，串联流程基于编排框架，无需再自己管理流程，声明配置即可，低代码，效率高，好管理。开发方案和使用方案分离，分工会更加清晰，也便于经验及方法论传递。

• 场景纵向隔离，便于业务差异化发展，业务不能绑架技术，技术更不能绑架业务。在引擎层面做到相互隔离，一个引擎就是一个场景，开发，升级，变更都能够互不影响。

• 服务运维，环境迁移部署更便利，CloudNative架构，无状态设计，方案可导入导出。从解决思路上讲，Docker解决了单一服务的迁移问题，而Flowengine解决场景的迁移问题。

最后给大家做一些实例的展示。

05

实例演示

Flowengine支持页面、SDK和CLI多种操作方式。左侧是引擎Web管理界面和CLI截图。右侧是一个应用方案包结构，包含了应用的定义meta_info.yaml以及依赖组件的定义。

下图是Flowengine-data 的管理界面，可以管理数据表及数据摄取，加工，服务的处理过程。

最后是业务编排的操作界面。它包含离线编排，在线编排，流式编排。

06

总结

随着智能场景越来越多，原来项目式，单点式的场景开发维护，必然导致整体研发成本的爆炸性增加。正如十来年前，web应用的大发展，催生了大量优秀的web开发框架一样，智能场景应用的大发展也将会重演这样的历史。Flowengine正是我们在这一领域的探索，以我们对智能应用的架构理解，构建一套加速开发和运维过程的框架平台，跟进未来的发展趋势。

李瀚

第四范式 | 平台架构师

李瀚，第四范式先知平台架构师，十余年大型互联网推荐，搜索系统架构设计开发经验。负责业务产品的整体架构设计工作。目前重点聚焦在自研AI场景领域系统开发框架 ( FLowEngine ) 的设计研发及推荐，搜索等智能系统应用架构设计及落地。