58 同城推荐系统架构设计与实现

主题

58 同城推荐系统架构设计与实现

一、推荐系统架构介绍

推荐系统是一个微庞大的工程、算法与业务综合的系统，其主要分为三大子系统：

1）线下推荐子系统；

2）线上推荐子系统；

3）效果评估子系统；

后文将重点讨论以上三大子系统的设计与实现。

二、线下推荐子系统

线下推荐子系统又主要分为线下挖掘模块、数据管理工具两大部分。

线下挖掘模块

线下挖掘模块，是各类线下挖掘算法实施的核心，它读取各种数据源，运用各种算法实施线下数据挖掘，产出初步的挖掘结果，并将挖掘结果以一定格式保存下来。典型的，实施这些挖掘策略的是一些跑在 hadoop 平台上的 job，并行实施策略，并将挖掘结果保存到 hadoop 上。

数据管理工具

数据管理工具，即 DataMgrTools，它是一个工具（或者服务），它能够接受一些管理命令，读取某些特定格式的线下数据，将这些数据实时或者周期性的打到线上的 redis 或者内存中，供线上服务读取。

数据管理工具是一个与业务无关的通用工具，它需要支持多种特定格式数据的上传，因为线下挖掘模块产出的数据可能存储在文件里，HDFS 上，数据库里，甚至是特定二进制数据。

该工具的实现要点是：定义好线下数据格式，线上数据格式，通过上下游 API 做数据的迁移和转换。

三、线上推荐子系统

线上推荐子系统主要分为展示服务、分流服务、推荐内核、策略 module 服务等几个部分。

展示服务

展示服务，或者说是接入服务，它是整个推荐系统线上部分的入口，即整个推荐系统的接入层，它向上游提供接口，供上游业务方调用。

展示服务是无状态的服务（线上子系统各个服务都是无状态的服务），可以任意水平扩展，该服务的实现要点是：定义好通用的接口格式。

分流服务

分流服务，它是推荐系统中一个非常有特色也非常重要的一个服务，它的作用是将上游过来的请求，按照不同的策略，以不同的比例，分流到不同的推荐算法实验平台（也就是下游的推荐内核）中去。

分流服务如何判断上游过来的一个请求分配到那个推荐算法实验平台呢？ 答案是通过策略和配置。从架构图中可以看到，几乎所有的服务都需要读取数据（data）和配置（conf），这些 data 可能是在线的动态变化的数据（例如：从 redis 中读取的数据），亦可能是相对静态的数据（例如：城市列表），conf 比较好理解，即一些配置（例如：所有请求 80% 流量必须走 A 算法实验平台）。通过这些策略和配置，配合请求带过来的参数，分流服务计算出流量分配到哪个实验平台。

该服务的实现要点是：实现通用的支持与或非关系的可配置的分流规则，与下游实验平台定义好通用的接口以实现将流量按需打往不同的实验平台。

策略服务

策略服务，又叫策略 module 服务，它实现了一个个推荐内核下游的推荐 module。在推荐内核执行各个推荐步骤时，每个步骤中都可能存在不同的算法 / 策略，这些算法 / 和策略可能需要调用一些和策略绑定比较紧密的 module 服务，它们并不是通用服务，而是相对专有的服务。

例如：排序 module 服务，需要有一套方便，高效，可扩展的排序服务。

该服务的实现要点是：实现一个通用的服务框架，让算法人员能够快速的生成 module 服务，并将自己的需求在 module 中实现，且能够在算法实验平台方便的进行 module 服务的调用。

四、效果评估子系统

效果评估子系统又分为推荐服务调用端、浏览器上报端、实施效果分析端 。

浏览器上报端

浏览器端 js，调用招聘服务时，能够在页面展现出推荐系统中推荐出来的结果，并且能够知道哪些推荐结果被点击了，且会将这些被展示的与被点击的信息进行上报。

实时效果分析端

浏览器 js 将被展示的推荐结果，与被点击的推荐结果进行上报后，有一个实时效果观察的平台，第一时间得知上线后推荐算法 / 推荐策略的效果。

五、总体架构图

综合前面章节所述，58 同城推荐系统总体架构图如上。

推荐系统是一个工程、算法和业务的综合性系统，上线了推荐系统，从此 58 同城正式进入了智能数据推荐的时代。

关于 -58 同城推荐业务

58 同城是一个用户与商户共依的平台，信息的推荐对 58 同城而言至关重要。以 58 同城的招聘业务线为例：在招聘用户端，为用户推荐更多很好的相关职位，能够增强用户的体验，也增加了 58 同城的 PV；在招聘商家端，为商户推荐更多更好的相关简历，能够增强商家的体验，促进简历的下载量，从而增加 58 同城的收入。

推荐业务如此重要，在技术层面，如何设计推荐系统的架构，是本文重点讨论的内容。