完整的推荐系统架构设计(精)

完整的推荐系统架构设计推荐系统是移动互联网时代非常成功的人工智能技术落地场景之一。

本文我们将从架构设计的角度回顾和讨论推荐系统的一些核心算法模块，重点从离线层、近线层和在线层三个架构层面讨论这些算法。

1 架构设计概述架构设计是一个很大的话题，本文这里只讨论和推荐系统相关的部分。

更具体地说，我们主要关注的是算法以及其他相关逻辑在时间和空间上的关系——这样一种逻辑上的架构关系。

下面介绍的是一些经过实践检验的架构层面的最佳实践，以及对这些最佳实践在不同应用场景下的分析。

除此之外，还希望能够通过把各种推荐算法放在架构的视角和场景下重新审视，让读者大家对算法间的关系有更深入的理解，从全局的角度看待推荐系统，而不是只看到一个个孤立的算法。

架构设计的本质之一是平衡和妥协。

一个推荐系统在不同的时期、不同的数据环境、不同的应用场景下会选择不同的架构，在选择时本质上是在平衡一些重要的点。

下面介绍几个常用的平衡点。

▊个性化 vs 复杂度个性化是推荐系统作为一个智能信息过滤系统的安身立命之本，从最早的热榜，到后来的公式规则，再到著名的协同过滤算法，最后到今天的大量使用机器学习算法，其主线之一就是为用户提供个性化程度越来越高的体验，让每个人看到的东西都尽量差异化，并且符合个人的喜好。

为了达到这一目的，系统的整体复杂度越来越高，具体表现为使用的算法越来越多、算法使用的数据量和数据维度越来越多、机器学习模型使用的特征越来越多，等等。

同时，为了更好地支持这些高复杂度算法的开发、迭代和调试，又衍生出了一系列对应的配套系统，进一步增加了整个系统的复杂度。

可以说整个推荐逻辑链条上的每一步都被不断地细化分析和优化，这些不同维度的优化横纵交织，构造出了一个整体复杂度非常高的系统。

从机器学习理论的角度来类比，如果把推荐系统整体看作一个巨大的以区分用户为目标的机器学习模型，则可以认为复杂度的增加对应着模型中特征维度的增加，这使得模型的VC维不断升高，对应着可分的用户数不断增加，进而提高了整个空间中用户的个性化程度。

这条通过不断提高系统复杂度来提升用户个性化体验的路线，也是近年来推荐系统发展的主线之一。

▊时效性 vs 计算量推荐系统中的时效性概念体现在实时服务的响应速度、实时数据的处理速度以及离线作业的运行速度等几个方面。

这几个速度从时效性角度影响着推荐系统的效果，整体上讲，运行速度越快，耗时越少，得到的效果越好。

这是因为响应速度越快，意味着对用户行为、物品信息变化的感知越快，感知后的处理速度越快，处理后结果的反馈就越快，最终体现到用户体验上，就是系统更懂用户，更快地对用户行为做出了反应，从而产生了更好的用户体验。

但这些时效性的优化，带来的是更大的计算量，计算量又对应着复杂的实现逻辑和更多的计算资源。

在设计得当的前提下，这样的付出通常是值得的。

时效性优化是推荐系统中非常重要的一类优化方法和优化思路，但由此带来的计算压力和系统设计的复杂度也是必须要面对的。

▊时间 vs 空间时间和空间之间的平衡关系可以说是计算机系统中最为本质的关系之一，在推荐系统中也不例外。

时间和空间这一对矛盾关系在推荐系统中的典型表现，主要体现在对缓存的使用上。

缓存通常用来存储一些计算代价较高以及相对静态变化较少的数据，例如用户的一些画像标签以及离线计算的相关性结果等。

但是随着越来越多的实时计算的引入，缓存的使用也越来越广泛，常常在生产者和消费者之间起到缓冲的作用，使得二者可以解耦，各自异步进行。

例如实时用户兴趣计算这一逻辑，如果没有将之前计算的兴趣缓存起来，那么在每次需要用户兴趣时都要实时计算一次，并要求在较短的时间内返回结果，这对计算性能提出了较高的要求。

但如果中间有一层缓存作为缓冲，则需求方可以直接从缓存中取来结果使用。

这在结果的实时性和新鲜度上虽然做了一定的妥协，但却能给性能提升带来极大的帮助。

这样就将生产和消费隔离开来，生产者可以根据具体情况选择生产的方式和速度。

当然，仍然可以努力提高生产速度，生产速度越快，缓存给时效性带来的损失就越小，消费者不做任何改动就可以享受到这一提升效果。

所以说，这种利用缓存来解耦系统，带来性能上的提升以及开发的便利，也是在推荐系统架构设计中需要掌握的一种通用的思路。

上面介绍的一些基本性原则贯穿着推荐系统架构设计的方方面面，是一些具有较高通用性的思路，掌握这些思路，可以产生出很多具体的设计和方法；反过来，每一种设计技巧或方法，也都可以映射到一个或几个这样的高层次抽象原则上来。

这种自顶向下的思维学习方法对于推荐系统的架构设计是非常重要的，并且可以推广到很多其他系统的设计中。

2 系统边界和外部依赖架构设计的第一步是确定系统的边界。

所谓边界，就是区分什么是这个系统要负责的，也就是边界内的部分，以及什么是这个模型要依赖的，也就是边界外的部分。

划分清楚边界，意味着确定了功能的边界以及团队的边界，能够让后期的工作都专注于核心功能的设计和实现。

反之，如果系统边界没有清晰的定义，可能会在开发过程中无意识地侵入其他系统中，形成冗余甚至矛盾，或者默认某些功能别人会开发而将其忽略掉。

无论哪种情况，都会影响系统的开发乃至最终的运转。

系统边界的确定，简单来说，就是在输入方面确定需要别人给我提供什么，而在输出方面确定我要给别人提供什么。

在输入方面，就是判断什么输入是需要别人提供给我的，要把握的主要原则包括：这个数据或服务是否与我的业务强相关在推荐业务中用到的每个东西，并不是都与推荐业务强相关，例如电商推荐系统中的商品信息，只有与推荐业务强相关的服务才应该被纳入推荐系统的边界中。

•这个数据或服务除了我的业务在使用，是否还有其他业务也在使用例如上面说到的商品信息服务，除了推荐系统在使用，其他子系统也在广泛使用，那么显然它应该是一个外部依赖。

也有例外情况，例如推荐系统要用到一些其他系统都用不到的商品信息，这时候，虽然理论上应该升级商品信息服务来支持推荐系统，但由于其他地方都用不到这些信息，因此很多时候可能需要推荐系统的负责团队来实现这样一个定制化服务。

依照此原则，下图展示了推荐系统的主要外部依赖。

▊1、数据依赖推荐系统作为一个典型的数据算法系统，数据是其最重要的依赖。

这里面主要包括用户行为数据和物品数据两大类，前面介绍的各种算法几乎都是以这两种数据作为输入进行计算的。

这些数据除了为推荐系统所用，它们也是搜索、展示等其他重要系统的输入数据，所以作为通用的公共数据和服务，显然不应该在推荐系统的边界内部，而应该是外部依赖。

需要特别指出的是，虽然有专门的团队负责行为数据的收集，但是收集到的数据是否符合推荐系统的期望却不是一件可以想当然的事情。

例如，对于结果展示的定义，数据收集团队认为前端请求到了结果就是展示，但对于推荐系统来说，只有用户真正看见了才是真实的展示。

其中的原因在于数据收集团队并不直接使用数据，那么他们就无法保证数据的正确性，这时就需要具体使用数据的业务方，在这里是推荐团队，来和他们一起确认数据收集的逻辑是正确的。

如果数据收集的逻辑不正确，后面的算法逻辑就是在做无用功。

花在确保数据正确上的精力和资源，几乎总是有收益的。

▊2、平台工具依赖推荐系统是一个计算密集型的系统，需要对各种形态的数据做各种计算处理，在此过程中，需要一整套计算平台工具的支持，典型的如机器学习平台、实时计算平台、离线计算平台、其他平台工具等。

在一个较为理想的环境中，这些平台工具都是由专门的团队来构建和维护的。

而在一些场景下，推荐系统可能是整个组织中最早使用这些技术的系统，推荐业务也还没有重要和庞大到需要老板专门配备一个平台团队为之服务的程度，在这种情况下，其中的一些平台工具就需要推荐系统的团队自己负责来构建和维护了。

为了简化逻辑，下面我们假设这些平台工具都是独立于推荐系统存在的，属于推荐系统的外部依赖。

在对外输出方面，系统边界的划定会根据公司组织的不同有所差异。

例如，在一些公司中，推荐团队负责的是与推荐相关的整个系统，在输出方面的体现就是从算法逻辑到结果展示，这时候系统的边界就要延伸到最终的结果展示。

而在另外一些公司中，前端展示是由一个大团队统一负责的，这时候推荐系统只需要给出要展示的物品ID和相关展示信息即可，前端团队会负责统一展示这些物品信息。

这两种模式没有绝对的好坏之分，重要的是要与整个技术团队的规划和架构相统一。

在本书中，为了叙述简便，我们不讨论前端展示涉及的内容，只专注于推荐结果的生产逻辑。

推荐系统的效果和性能在一定程度上取决于这些依赖系统，所以在寻求推荐系统的优化目标时，目光不能只看到推荐系统本身，很多时候这些依赖系统也是重要的效果提升来源。

例如，物品信息的变更如果能被更快地通知到推荐系统，那么推荐系统的时效性就会更好，给到用户的结果也就会更好；再如，用户行为数据收集的准确性能有所提高的话，对应的相关性算法的准确性也会随之提高。

在有些情况下，外部系统升级会比优化算法有更大的效果提升。

当然，推荐系统的问题也可能来自这些外部的依赖系统。

例如，前端渲染展示速度的延迟会导致用户点击率的显著下降，因为这会让用户失去耐心。

所以，当推荐系统指标出现下降时，不光要从内部找问题，也要把思路拓展到系统外部，从全局的角度去找问题。

综合来讲，外部依赖的存在启发我们要从全链条、全系统的角度来看问题，找问题，以及设计优化方法。

3 离线层、在线层和近线层架构架构设计有很多不同的切入方式，最简单也是最常用的一种方式就是先决定某个模块或逻辑是运行在离线层、在线层还是近线层。

这三层的对比如下。

任何使用非实时数据、提供非实时服务的逻辑模块，都可以被定义为离线模块。

其典型代表是离线的协同过滤算法，以及一些离线的标签挖掘类算法。

离线层通常用来进行大数据量的计算，由于计算是离线进行的，因此用到的数据也都是非实时数据，最终会产出一份非实时的离线数据，供下游进一步处理使用。

与离线层相对的是在线层，也常被称为服务层，这一层的核心功能是对外提供服务，实时处理调用方的请求。

这一层的典型代表是推荐系统的对外服务接口，接受实时调用并返回结果。

在线层提供的服务是实时的，但用到的数据却不一定局限于实时数据，也可以使用离线计算好的各种数据，例如相关性数据或标签数据等，但前提是这些数据已经以对实时友好的形态被存储起来。

近线层则处于离线层和在线层的中间位置，是一个比较奇妙的层。

这一层的典型特点就是：使用实时数据（也会使用非实时数据），但不提供实时服务，而是提供一种近实时的服务。

所谓近实时指的是越快越好，但并不强求像在线层一样在几十毫秒内给出结果，因为通常在近线层计算的结果会写入缓存系统，供在线层读取，做了一层隔离，因此对时效性无强要求。

其典型代表是我们前面讲过的实时协同过滤算法，该算法通过用户的实时行为计算最新的相关性结果，但这些计算结果并不是实时提供给用户的，而是要等到用户发起请求时才会把最新的结果提供给他使用。