推荐系统架构治理( 五 ) _推荐系统

在计算引擎层面，集成了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以及依赖组件的定义。