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

数据流：推荐系统的特点就是高度和数据流相关，那么技术层面要解决数据怎么来，数据怎么用，数据怎么加工处理，正确性和时效性如何保证等问题。
离线板块：系统内涉及到一些数据加工，任务处理，模型生产，指标报表等离线任务，怎么协调这些任务有序高效进行，并获得正确有效的结果。
在线板块：推荐系统对外提供实时推荐的能力，涉及到诸多的在线处理过程和规则。如何在适应业务快速变化的同时保证可用性和性能是至关重要的。
AI：当下推荐系统的重要组成部分，其包含整个AI模型生成到服务的全生命周期。如何从系统层面支撑AI全生命周期以及如何有机集成进系统是一个挑战。
基础设施：推荐系统是一个多领域交叉的综合应用，需要有众多的中间件、基础组件做支撑，如何管理和运维，减少依赖，有效利用是一个重要的命题。

文章插图

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

文章插图

我简单的总结了一下，主要有四方面的挑战。
a. 开发运维部署迁移困难，曲线陡峭，效率低下。因为推荐系统等智能系统，都涉及到大量的基础组件和服务，各有特点，缺乏一体化的管理运维手段，如何把完整系统搭起来并管理，期间中间件或者服务出问题，都可能会导致系统不可用。这对于没有丰富的组件维护经验或者人力不足的团队来讲，是一个巨大挑战。
【推荐系统架构治理】b. 这实际上是一个应用治理的问题，服务，流程，规则，策略，数据，产物繁多，组织管理困难。图中任何一个框是一种服务，也可能是若干个服务，这些服务之间的依赖不直观，很难管理。数据流逻辑繁琐复杂，系统有很多的离线数据流，在线的数据流，还会产生大量数据产物，缺乏标准化的管理，极易出错。不同场景的差异化难以组织，不同的服务，策略间相互影响，其中一个可能表现就是在一个服务模块代码中因为要处理不同场景的逻辑而产生大量if分支逻辑。从架构上讲，一个好的场景服务应该是纵向切分的，不同的场景是不同的系统，场景间互相隔离，但这又会导致系统资源浪费，管理上面也很麻烦。因此，需要采取更加系统化的方法去治理它。
c. 系统涉及到数据/在线/离线/AI各个领域，技术栈割裂，整个推荐流程需要大量的胶水代码来整合集成。而胶水代码的一个特点就是难以复用，不同人之间也难以维护。这样的割裂突出表现在以下三点：

众多领域技术，彼此割裂，难以集成
数据质量难以保证，效果也无法保证
定制性胶水代码驱动，无法复用，迁移

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