推荐系统提供web服务的2种方式( 二 ) _web服务

文章插图

图2：完整的推荐系统业务架构图

如前面所讲，虽然推荐web服务包含前端与后端的交互，前端与后端一般还会有CDN层和Nginx代理层，但本文我们着重关注的是后端真正提供Web服务接口模块及数据存储模块的实现方案，也即上图中红色模块怎么获取推荐结果的架构实现方案。该模块的实现方案可以多样，主流的实现方式有两种，我们在下面分三节来进行介绍。

二、推荐系统提供web服务的两种方式推荐系统提供web服务一般有两种方式，一种是事先计算型，另一种是实时装配型。在具体介绍之前，这里我先举一个比较形象的例子，让大家更好地理解这两种实现方式。

假设我们开了一家餐厅专门送外卖，餐厅提供10种不同的备选套餐。在午市或者晚市叫餐高峰时段，餐厅可以采用如下两种方案来准备套餐：第一种方案是事先将这10种套餐每种都做若干份，当有客户叫外卖时，将该客户叫的这个套餐(已经做好了)直接送出去；第二种方式是将这10种套餐需要的原材料都准备好，部分材料做成半成品(比如比较花时间的肉类)，当有用户叫餐时，将该套餐需要的原材料下锅快速做好再送出去。

通过上面非常简化的案例介绍，大家应该不难理解，上面提到的第一种准备套餐的方式就是“事先计算型”，事先将套餐做好，而第二种方式就是“实时装配型”，当用户叫餐时，临时做并快速做好。

现在让我们回到推荐web服务上，来介绍两种推荐web服务方案。事先计算型就是将用户的推荐结果事先计算好，放到数据库中存放起来，当该用户在使用产品过程中访问推荐模块时，推荐web服务模块直接将该用户计算好的推荐结果取出来，进行适当加工(比如过滤掉用户已经看过的视频)，将最终推荐结果展示给用户。实时装配型是将计算推荐结果需要的数据(一般是各种特征)提前准备好，当用户访问推荐模块时，推荐web服务通过简单的计算和组装(利用前面准备好的各种特征灌入推荐模型)，生成该用户的推荐结果，再将推荐结果返回给前端并展示给用户。

理解了这两种不同的web服务方式的基本原理，我们在接下来的两节中分别对它们的实现细节进行详细介绍，让读者更好地理解它们的特性及技术实现细节。

三、事先计算型web服务这一节我们来讲解推荐系统事先计算型web服务的架构实现与基本原理(参见下面图3) 。这种方式可能是业界比较多地采用的一种推荐web服务架构实现方式，作者所在公司的所有推荐服务基本都是采用的该模式。

文章插图

图3：事先计算型web服务架构(绿色虚线框中的模块即是图2中的红色模块的细化)

该模式最大的特点是事先将每个用户的推荐结果计算出来，存到数据库(一般是NoSQL，如Redis、CouchBase等NoSQL数据库，采用key-value的方式存储，key就是用户id，value就是给用户的推荐结果，如果是用Redis存，value的数据结构可以使Sorted Sets，这种数据结构比较适合推荐系统，Sorted Sets中的element可以是推荐的标的物id，score是标的物的预测评分或者预测概率值等，还可以根据Sorted Sets中的score进行分页筛选等操作)中，当有用户请求时，前端访问web接口服务器(前端会带上用户的唯一识别id进行HTTP请求，这样就知道是哪个用户，方便找到该用户的推荐结果)，web服务器从推荐结果库中获取该用户的推荐结果(推荐结果一般只存储给用户推荐的标的物id列表及部分需要的其他信息，比如算法标识，方便后面做AB测试，下面图4就是一种推荐结果存储的数据格式，其中id就是标的物的唯一识别id)，同时还需要访问标的物metadata数据库(一般存放在关系型数据库中)，将前端展示需要的其他信息(如标的物的名称、价格、缩略图等)拼接完整，最终以json的形式(下面图5就是视频推荐系统最终拼接好的json格式，互联网企业一般采用的数据交互协议，也可以是其他协议，google内部就采用protobuf协议)返回给前端展示给用户。