「构建企业级推荐系统系列」推荐系统的工程实现

作者 | gongyouliu

编辑 | auroral-L

我们在前面的文章中主要讲解了推荐算法相关的主题。在企业中要将推荐系统很好地落地到产品中，除了对算法原理的掌握，还必须要关注算法的工程实现，算法只有很好地工程化，才能真正产生业务价值。本文作者会结合多年推荐系统开发的实践经验粗略介绍推荐系统的工程实现， 简要说明要将推荐系统很好地落地到产品中需要考虑哪些工程问题及相应的思路、策略，其中有大量关于工程设计哲学的思考，希望对从事推荐算法工作或准备入行推荐系统的读者有所帮助。

本文主要从整体上来介绍推荐系统工程实现，给读者提供一些思路和策略性建议。为了描述方便，本文主要基于视频推荐来讲解，作者这几年也一直在从事视频推荐系统开发的工作，其他行业的推荐系统工程实现思路类似。

一、推荐系统与大数据

推荐系统是帮助人们解决信息获取问题的有效工具。对互联网产品来说，用户数和标的物总量通常都是巨大的，每天收集到的用户在产品上的交互行为数据也是海量的，这些大量的数据收集处理就涉及到大数据相关技术，所以推荐系统与大数据有天然的联系，要落地推荐系统往往需要企业具备一套完善的大数据分析平台。我们在上一篇中也详细介绍了推荐系统依赖的数据源及数据ETL、特征工程相关知识点，相信读者已经有所了解了。

推荐系统与大数据平台的依赖关系如下面图1。大数据平台包含数据中心和计算中心两大抽象。数据中心为推荐系统提供数据存储，包括训练推荐模型需要的数据、依赖的其他数据、以及推荐结果数据。而计算中心提供算力支持，支撑数据预处理、模型训练、模型推断(即基于学习到的模型，为每个用户进行个性化推荐)等。推荐系统属于面向终端用户的业务，借助数据中心和计算中心来完成为用户生成个性化推荐的任务。

 

图1：推荐系统在整个大数据平台的定位

     

大数据与人工智能具有千丝万缕的关系，互联网公司一般会构建自己的大数据与人工智能团队，构建大数据基础平台，基于大数据平台构建上层业务，包括商业智能(BI)、推荐系统及其他人工智能业务，下面图2是典型的基于大数据等相关开源技术的互联网视频公司大数据与人工智能业务及相关的底层支撑技术。

 

最底层DS是数据层，通过各种数据收集技术将多源的数据收集到大数据平台，存放到数仓体系中，为上层业务提供数据支撑。当前比较火的数据中台理念就是将数据服务化、业务化，利用数据赋能前台业务。中间层DC是大数据中心，为上层业务提供数据支撑及算力支持，同时会包含很多支撑组件让数据服务和计算可以更加稳定、可靠地为上层业务提供支持。最上层BIZ是业务层，包括商业智能、个性化推荐、搜索、广告、NLP、CV等各类大数据与AI业务，通过大数据和AI赋能产品，为用户提供数据化、智能化的服务，最终提升用户体验，增强企业的核心竞争力，利用数据与AI为企业创造更多的商业价值。

 

图2：大数据支撑下的人工智能技术体系(DS:数据源，DC:大数据中心，BIZ:上层业务)

   

推荐系统是众多前台业务中的一个非常有商业价值并得到行业一致追捧和认可的方向。在产品中整合推荐系统是一个系统工程， 怎么让推荐系统在产品中产生价值，真正帮助到用户，提升用户体验的同时为平台方提供更大的收益是一件有挑战的事情，整个推荐系统的业务流可以用下面图3来说明，它是一个不断迭代优化的过程(借助AB测试和指标体系)，是一个闭环系统。

 

图3：推荐系统业务流程

   

有了上面这些介绍， 相信读者对大数据与推荐系统的关系有了一个比较清楚的了解，下面会着重讲解推荐系统工程实现相关的知识。

二、推荐系统业务流及核心模块

推荐系统是一个复杂的体系工程，涉及到很多相关组件，我们先介绍一下构建一套完善的推荐系统涉及到的主要业务流程及核心模块， 具体流程如下面图4，下面分别介绍各个模块的功能：

 

图4：推荐系统业务流程和核心模块

 

1.数据收集模块

构建推荐模型需要收集很多数据，包括用户行为数据，用户相关数据、标的物相关数据等。如果将推荐系统比喻为厨师做菜，那么这些数据是构建推荐算法模型的各种食材和配料。巧妇难为无米之炊，要构建好的推荐算法，收集到足够多的有价值的数据是非常关键和重要的。上一篇文章已经对推荐系统相关的数据进行了全面的介绍，这里不再赘述。

 

2. ETL模块

收集到的原始数据一般是非结构化的，ETL模块的主要目的是从收集到的原始数据中提取关键字段(拿视频行业来说，用户id、时间、播放的节目、播放时长，播放路径等都是关键字段)，将数据转化为结构化的数据存储到数据仓库中。同时根据一定的规则或策略过滤掉脏数据，保证数据质量的高标准。在互联网公司中，用户行为数据跟用户规模呈正比，所以当用户规模很大时数据量非常大，一般采用HDFS、Hive、HBase等大数据分布式存储系统来存储数据。用户相关数据、标的物相关数据一般是结构化的数据，一般是通过后台管理模块将数据存储到MySQL、ProgreSQL等关系型数据库中或者快照到Hive表中。在《推荐系统之数据与特征工程》3.2节中对数据预处理进行了比较详细的介绍，这里不细说。

 

3. 特征工程模块

推荐系统采用各种机器学习算法来学习用户偏好，并基于用户偏好来为用户推荐标的物。这些推荐算法用于训练的数据应该是可以被数学模型所理解和处理的，一般是向量的形式，其中向量的每一个分量/维度就是一个特征，所以特征工程的目的就是将推荐算法需要的原始数据通过ETL后转换为推荐算法可以学习的特征。

 

当然，不是所有推荐算法都需要特征工程，比如，如果要做排行榜相关的热门推荐，只需要对数据做统计排序处理就可以了。最常用的基于物品的推荐和基于用户的协同过滤也只用到用户id，标的物id，用户对标的物的评分三个维度，也谈不上特征工程。像logistic回归等复杂一些的机器学习算法需要做特征工程，一般基于模型的推荐算法都需要特征工程。

 

特征工程是一个比较复杂的过程，要做好需要很多技巧、智慧、行业知识、经验等。在《推荐系统之数据与特征工程》这篇文章中对特征工程已经做了非常完整的介绍。

 

4. 推荐算法模块

推荐算法模块是整个推荐系统的核心之一，该模块的核心是根据具体业务及可利用的所有数据设计一套精准、易于工程实现、可以处理大规模数据的(分布式)机器学习算法，进而可以预测用户的兴趣偏好。这里一般涉及到模型训练、预测两个核心操作和模块。下面用一个图简单描述这两个过程，这也是机器学习的通用流程。对于推荐算法，我们在第二篇和第三篇中已经讲解了非常多了。

 

图5：推荐算法建模过程

    

好的推荐工程实现，希望尽量将这两个过程解耦合，尽量做到通用，方便用到各种推荐业务中，后面在推荐系统架构设计一节中会详细讲解具体的设计思路和设计哲学。

 

5. 推荐结果存储模块

在计算机工程中有所谓的“空间换时间”的说法，对于推荐系统来说，事先计算好每个用户的推荐， 将推荐结果存储下来， 可以更快的为用户提供推荐服务，及时响应用户的请求，提升用户体验(对于每天更新一次的推荐业务，这样做是非常合适的)。由于推荐系统会为每个用户生成推荐结果，并且每天都会(基本全量)更新用户的推荐结果，一般采用NoSQL数据库来存储，并且要求数据库可拓展，高可用，支持大规模并发读写。

 

当然，事先存储起来不一定是唯一的解决方案，我们会在后续文章会介绍另外一种为用户提供推荐服务的解决方案。但不管哪种方案，肯定要借助数据库将依赖的部分数据存储起来的，这样才能更好地为推荐服务提供数据支撑。

 

作者在最开始做推荐系统时由于没有经验，开始将推荐结果存储在MySQL中，当时遇到最大的问题是每天更新用户的推荐时，需要先找到用户存储的位置，再做替换，操作复杂，并且当用户规模大时，高并发读写，大数据量存储，MySQL也扛不住，现在最好的方式是采用CouchBase、Redis、HBase等可以横向扩容的NoSQL数据库，可以完全避开MySQL的缺点。

 

推荐结果一般不是在模型推断阶段直接写入推荐存储数据库，较好的方式是通过一个数据管道(如kafka)来解耦，让整个系统更加模块化，易于维护拓展。

 

6.Web服务模块

该模块是推荐系统直接服务用户的模块，该模块的主要作用是当用户在UI上触达推荐系统时，触发推荐接口服务，为用户提供个性化推荐，该模块的稳定性、响应时长直接影响到用户体验。跟上面的推荐存储模块类似，Web服务模块也需要支持高并发访问、水平可拓展、亚秒级(一般200ms之内)响应延迟。

 

我们在后续文章会讲解优质的推荐web服务需要关注哪些点，具体怎么做，怎么衡量web服务的质量等相关知识，也会讲解推荐web服务相关的知识。

 

 

下图是作者公司相似影片推荐算法的一个简化版业务流向图，供大家与上面的模块对照参考：

 图6：相似影片业务流

三、推荐系统支撑模块

推荐系统想要很好地、稳定地发挥价值，需要一些支撑组件来辅助，这些支撑组件虽然不是推荐系统的核心模块，但却是推荐业务稳定运行必不可少的部分，主要包括如下4大支撑模块(见下面图7)，下面分别简述各个模块的作用和价值。

图7：推荐系统核心支撑模块

 

1. 评估模块

推荐评估模块的主要作用是评估整个推荐系统的质量及价值产出。一般来说可以从两个维度来评估。

1. 离线评估：主要是评估训练好的推荐模型的质量，模型在上线服务之前需要评估该模型的准确度，一般是将训练数据分为训练集和测试集，训练集用于训练模型，而测试集用来评估模型的预测误差。除了评估推荐模型外，推荐web服务性能、是否能够应对大规模数据运算等都需要事先考虑。我们在《推荐系统评估》中对推荐系统各个维度进行了介绍，这里不再赘述。

2. 在线评估：模型上线提供推荐服务过程中评估一些真实的用户体验指标、转化指标，比如转化率、购买率、点击率、播放时长等。线上评估一般会结合AB测试，先放一部分量，如果效果达到期望再逐步拓展到所有用户，避免模型线上效果不好严重影响用户体验和收益指标等。我们在《推荐系统的商业价值》中对推荐系统各个维度的业务价值进行了介绍，这里不再细说。

 

2. 调度模块

一个推荐业务要产生价值，所有依赖的任务都要正常运行。推荐业务可以抽象为有向无环图(下面的18.4节“推荐系统架构设计”中会讲到将推荐业务抽象为有向无环图)，因此需要按照该有向图的依赖关系依次执行每个任务， 这些任务的依赖关系就需要借助合适的调度系统(比如Azkaban、Airflow等)来实现，早期作者采用Linux的Crontab来调度，当任务量多的时候就不那么方便了，Crontab也无法很好解决任务依赖关系。

 

3.监控模块

监控模块解决的是当推荐业务(依赖的)任务由于各种原因调度失败、运行报错时可以及时告警，及时发现问题。在出现问题时通过邮件或者短信通知运维或者业务的维护者或者可以在后台自动拉起服务重新执行(这要求你的业务是幂等的)。

 

我们可以对服务的各种状态做监控，可以事先根据业务需要定义一些监控变量(比如文件大小、状态变量的值、日期时间等)，当这些状态变量无值或者值超过事先定义的阈值范围时及时告警。

 

监控模块的主要目的是保证推荐业务的稳定性，时时刻刻为用户提供一致的、高质量的个性化推荐服务。监控模块的开发和设计一般需要运维人员来配合实施。

 

4. 审查模块

审查模块是对推荐系统结果数据格式的正确性、有效性进行检查，避免错误产生，一般的处理策略是根据业务定义一些审查用例(类似测试用例)，在推荐任务执行前或者执行阶段对运算过程做check，发现问题及时告警。举两个例子，如果你的DAU是100万，每天大约要为这么多用户生成个性化推荐结果，但是由于代码中存在一些比较隐秘的bug，只计算了20万用户的个性化推荐，从监控是无法发现问题的，如果增加推荐的用户数量跟DAU的比例控制在1附近这个审查项，就可以避免出现问题。又比如，在推荐结果插入数据库过程中，开发人员升级了新的算法，不小心将数据格式写错(如Json格式不合法)，如果不加审查，会导致最终插入的数据格式错误，导致推荐接口返回错误或者挂掉，对用户体验有极大负面影响。

 

审查模块跟上面的监控模块不一样，监控模块是监控推荐业务本身及依赖的业务是否正常运行，而审查模块时对业务细节及逻辑层面的检查，避免业务逻辑出错导致影响推荐业务的正常运转，最终影响用户体验和业务指标。

 

四、推荐系统架构设计

作者在早期构建推荐系统时由于经验不足，而业务又比较多，当时的策略是每个算法工程师负责几个推荐业务(一个推荐业务对应一个推荐产品形态)，由于每个人只对自己的业务负责，所以开发基本是独立的，每个人只关注自己的算法实现，虽然用到的算法很多都是一样的，但前期在开发过程中没有将通用的模块抽象出来，每个开发人员从ETL、算法训练、预测到推荐结果存储都是独立的，并且每个人在实现过程中整合了自己的一些优化逻辑，一竿子插到底，导致资源(计算资源、存储资源、人力资源)利用率不高，开发效率低下，代码也极难复用。

 

经过几年的摸索，作者所在团队构建了一套通用的算法组件Doraemon框架(就像机器猫的小口袋，永远有解决问题的工具)，尽量做到代码的复用、资源的节省，大大提升了开发效率。开发过程的蜕变，可以用下面的图8简单说明，从图中读者也可以对Doraemon架构落地后推荐业务前后开发的变化有个大致的了解。

 

图8：Doraemon框架前后开发方式对比

作者构建Doraemon框架的初衷是希望构建推荐业务就像搭积木一样(见下面图9)，可以快速构建一套推荐算法体系，快速上线业务。算法或者处理逻辑就像一块一块的积木，而算法依赖的、输出的数据(及数据结构)就是不同积木之间能否衔接的“接口”。本着这种简单朴素的思想，下面作者详细说说构建这套体系的思路和策略。

图9：构建推荐业务应该像搭积木一样简单(图片来源于网络)

     

为了支撑更多类型的推荐业务，减少系统的耦合，便于发现和追踪问题，节省人力成本，方便算法快速上线和迭代，需要设计比较好的推荐系统架构，而好的推荐系统架构应该具备6大原则：通用性、模块化、组件化、一致性、可拓展性、抽象性。下面分别对上述6大原则做简要说明，阐述清楚它们的目标和意义。

 

• 通用性

所谓通用，就是该架构具备包容的能力，业务上的任何推荐产品都可以用这一套架构来涵盖和实现。对于多条相似的产品线，也可以采用同样的一套架构来满足。

 

• 模块化

模块化的目的在于将一个业务按照其功能做拆分，分成相互独立的模块，以便于每个模块只包含与其功能相关的内容，模块之间通过一致性的协议调用(在Doraemon框架中两个模块是通过数据交互协议来衔接的)。将一个大的系统模块化之后，每个模块都可以被高度复用。模块化的目的是为了复用， 模块化后，各个模块可以方便重复使用到不同推荐业务逻辑、甚至不同的产品线中。

 

• 组件化

组件化就是基于方便维护的目的，将一个大的软件系统拆分成多个独立的组件，主要目的就是减少耦合。一个独立的组件可以是一个软件包、web服务、web资源或者是封装了一些函数的模块(18.2节和18.3节各个模块可以算作是不同的组件)。这样，独立出来的组件可以单独维护和升级而不会影响到其他的组件。组件化的目的是为了解耦，把系统拆分成多个组件，确定各个组件边界和责任，便于独立升级和维护，组件可插拔，通过组件的拼接和增减提供更完整的服务能力。

 

组件化和模块化比较类似，目标分别是为了更好的解耦和重用，就像搭积木一样构建复杂系统。一个组件可以进一步分为多个模块，组件化是从业务功能的角度进行的划分，是更宏观的视角，而模块化是从软件实现层面进行的划分，是偏微观的视角。

 

• 一致性

指模块的数据输入输出采用统一的数据交互协议，做到整个系统一致。对于Doraemon框架，我们是基于Spark进行二次开发和封装的，所有模块之间的数据交互都基于DataFrame进行，比较一致和统一。

 

• 可拓展性

系统具备支撑大数据量，高并发的能力，并且容易在该系统中增添新的模块，提供更丰富的能力，让业务更加完备自治。

 

• 抽象性

将相似的操作和流程抽象为统一的操作，主要目的是简化系统设计，让系统更加简洁通用。针对推荐系统借用数学中的概念抽象如下：

 

操作/算法抽象：我们先对数据处理或者算法做一个抽象，将利用输入数据通过“操作”得到输出的的过程抽象为“算子”，按照这个抽象，ETL、机器学习训练模型、机器学习推断都是算子。其中输入输出可以是数据或者模型。

 

图10：算法或者操作的算子抽象

 

业务抽象：任何一个推荐业务可以抽象为由数据/模型为节点，算子为边的“有向无环图”。下面图11是作者团队实现的一个利用深度学习做电影猜你喜欢的推荐业务流程， 整个流程是由各个算子通过依赖关系链接起来的，整个算法实现就是一个有向无环图。

 

图11：推荐业务的有向无环图抽象

   

根据Doraemon系统的设计哲学及上面描述的推荐系统的核心模块， 结合业内一般将推荐系统分为召回(将用户可能会喜欢的标的物取出来)和排序(将取出的标的物按照用户喜好程度降序排列，最喜欢的排在前面)两个过程，推荐系统可以根据如下方式进行设计。

1. 基础组件：业务枚举类型、常量、路径处理、配置文件解析等。

2. 数据读入组件：包括从HDFS、数据仓库、HBase、MySQL等相关数据库读取数据的操作，将这些操作封装成通用操作，方便所有业务线统一调用。

3. 数据流出组件：类似数据读入组件，将推荐结果插入最终存储(如Redis，CouchBase等)的操作封装成算子，我们一般是将推荐结果流入Kafka，利用Kafka作为数据管道，最终再从Kafka将数据插入推荐存储服务，这样做的目的是将推断过程跟数据存储服务解耦。

4. 算法组件：这是整个推荐系统的核心。在工程实现过程中，我们将推荐系统中涉及到的算子抽象为3个接口：AlgParameters(算子依赖的参数集合，如模型的超参等)、 Algorithm/AlgorithmEx (具体的算法实现，如果算法依赖模型，采用AlgorithmEx，比如利用模型做推断)、Model(算法训练好的模型，包括模型的导入、导出等接口)。所有的算子实现上面3个接口的抽象方法就可以了。下图给出了这3个接口包含的具体方法以及Spark mllib中的矩阵分解基于该抽象的实现。在作者公司的推荐业务实践中，发现上述抽象很合理，基本推荐业务涉及到的所有算子(ETL、模型训练、模型推荐、排序框架、数据过滤、具体业务逻辑等)都可以采用该方式很好地抽象。

 

图12：Doraemon中算子的抽象及矩阵分解算法基于Doraemon框架的算子实现

   

1. 评估组件：主要是包括算法训练过程的离线评估等。

2. 其他支撑组件：比如AB测试等，都可以整合到Doraemon框架中。 

 

这里要特别说一下数据(模型)，数据作为算子的输入输出，一定要定义严格的范式(具备固定的数据结构，比如矩阵分解训练依赖的数据有三列，一列用户id，一列标的物id，一列用户对物品的评分)， Spark的DataFrame可以很好的支撑各种数据类型，前面也讲过，Doraemon中数据交互的格式就采用的DataFrame。数据格式定义好后，在算子读入或者输出时，可以对类型做校验，可以很好的避免很多由于业务开发疏忽导致的问题。这有点类似强类型编程语言，在编译过程就可以检查出类型错误。我们将上面的6类组件封装成一个Doraemon的lib库，供具体的推荐业务使用。

 

基于大数据的数据中心和计算中心的抽象，我们将所有推荐业务中涉及到的数据和算子分别放入数据仓库和算子仓库(其实就是一个由算法封装成的jar包，即Doraemon.jar)，开发推荐业务时根据推荐算法的业务流程从这两个仓库中拿出对应的“积木”来组装业务, 参考下面图13。

 

图13：基于Doraemon框架的算法组件化开发方式

   

基于上面的设计原则，推荐业务可以抽象为“数据流”和“算子流”两个流的相互交织，利用Doraemon框架构建一个完善的推荐业务流程如下面图14。

 

图14：基于Doraemon框架开发的视频推荐业务，数据流与算子流相互交织，非常清晰

 

另外，如果公司做产品线的拓展，比如今日头条拓展新产品抖音、西瓜视频、火山小视频等，可以基于推荐算法范式实现很多推荐业务(比如猜你喜欢、相似影片、热门推荐等)，将这些业务封装到一个DoraemonBiz.jar的jar包中(DoraemonBiz.jar是基于具体的推荐业务，利用Doraemon.jar中的算子组装成的业务单元，是直接可以用于推荐业务产品化的)。这样这些能力就可以直接平移到新的产品线，赋能新业务。这种操作就是二次封装，具有极大的威力，下面给一个形象的图示来说明这种二次赋能的逻辑，让读者更好理解这种思想。

 

图15：通过二次封装，构建推荐业务单元，赋能到新产品矩阵

   

从上面的介绍，相信大家已经感受到了Doraemon框架的威力了，有了这套框架，我们可以高效地开发算法，快速地构建推荐业务了。如果需要开发新的算子，我们可以将这些新算法实现并封装到Doraemon.jar中，如果需要开发新的推荐产品形态，我们可以基于Doraemon中的算子组装成新的推荐业务，并封装到DoraemonBiz.jar中。通过这种方式，我们可以不断拓展Doraemon的能力，让Doraemon成长为具备更多技能(算子及业务能力)的巨人！

五、推荐系统工程实现的设计哲学

要为推荐系统设计一套好用、高效的工程框架并不容易，往往需要踩过很多坑，通过多年经验的积累才能深刻领悟。前面在“推荐系统架构设计”一节已经说了很多构建Doraemon框架的设计原则， 本节试图从整个推荐业务工程实现的角度给出一些可供参考的设计哲学， 以便读者可以更好地将推荐系统落地到业务中。

1.什么是好的推荐系统工程实现？

对于这个问题也没有标准的答案，不同的人有不同的理解，对于不同行业可能也会有一些差别。就作者个人来说，我认为好的工程实现需要满足如下几个原则：

(1) 别人很容易理解你的逻辑，毕竟代码是给人看的，是为了更好地进行知识的积淀和传承；

(2) 按照业务流/数据流来组织代码结构，推荐系统是一种数据化的应用，并且跟业务关系紧密，按照数据流/业务流来组织是最容易理解的；

(3) 便于debug，推荐系统作为一项工程技术，出问题和故障是不可避免的，业务实现易于发现问题真的非常重要；

(4) 保证数据存储结构、代码模块、业务逻辑的一致性，便于学习、理解和问题排查；

 

2. 设计好的推荐系统工程实现的原则？

下面这5条原则，是作者在推荐系统工程实现方面的经验总结，我们的Doraemon框架也是采用这一原则来开发的。

(1) 尽量将逻辑拆解为独立的小单元；

(2) 代码单元的输入输出定义清晰；

(3) 设置合适的交互出入口；

(4) 确定通用一致的数据交互格式；

(5) 数据存储、业务功能点、代码单元保持一一对应；

 

3. 什么算好的推荐系统工程实现？

推荐系统是典型的数据服务系统，按照数据流来组织工程实现模块是非常自然的，推荐系统包括数据的读取、数据预处理、模型构建、模型推断、结果存储等pipeline模块，我们需要对于推荐系统整体架构有比较清晰的理解，需要知道哪些模块是最核心的，模块之间是怎么衔接的。具体来说，设计好的推荐系统工程架构，我们需要做好如下几点。

(1) 确定思考问题的主线：根据数据流或者业务流来组织模块；

(2) 厘清推荐系统业务流或者数据流的架构(最好可以画出架构图)；

(3) 确定核心功能模块；

(4) 根据核心功能模块组织代码目录结构和数据存储结构；

(5) 定义清晰明确的接口及数据格式；

(6) 尽量文档化所有的模块及功能点；

   

下面图16是作者团队开发的深度学习猜你喜欢推荐系统(基于Tensorflow开发，YouTube深度学习推荐系统在作者公司的实现)的业务流程图，对应的代码组织结构和对应的数据在本地文件系统中的存储结构，基本按照上述设计原则来做，看起来很清晰，方便理解和问题排查。

 

图16：业务流、数据存储、代码工程结构保持对应

六、近实时个性化推荐

推荐系统在实际业务实现时一般是T+1推荐(每天更新一次推荐，今天利用昨天之前的数据计算用户的推荐结果)。随着移动互联网的深入发展，特别是今日头条和快手等新闻、短视频APP的流行，越来越多的公司将T+1和实时策略相结合(比如采用流行的lambda架构，下图是一个采用lambda架构的推荐架构图，供参考)将推荐系统做到了近实时推荐，根据用户的兴趣变化实时为用户提供个性化推荐。像新闻、短视频这类满足用户碎片化时间需求的产品，做到实时个性化可以极大提升用户体验，这样可以更好地满足用户需求，提升用户在产品上的停留时间。

实时个性化推荐的设计思路本质上跟上面讲解的没有什么两样。但是，实时推荐需要对数据进行实时处理、实时为用户推荐，对数据处理速度、性能、架构等方面提出了更高的要求。

 

图17：实时推荐系统的lambda架构

七、推荐系统业务落地需要关注的问题

推荐系统要想很好的落地到产品中产生业务价值，除了算法实现、核心模块和支撑模块构建外，还有很多方面需要考虑，下面简单描述一下其它需要考虑的点，这些点都是非常重要的，深入理解这些问题，对真正发挥出推荐系统的价值有非常大的帮助。

1. 二八定律：你的产品可能包含很多推荐模块，但是在投入精力迭代优化过程中，需要将核心精力放到用户触点多的产品(位置好，更容易曝光给用户的推荐产品)上，因为这些产品形态占整个推荐价值产出的绝大部分。这个道理看起来谁都懂，但在实际工作中一直坚守这个原则，还是很难的；

2. “高大上”的算法与工程可实现性、易用性之间的平衡：刚从事推荐算法开发的工程师会觉得算法的价值是巨大的，一个“高大上”的算法可以让产品一飞冲天。殊不知很多在顶级会议上发表的绝大多数“高大上”的算法遇到工业级海量数据、大规模的分布式计算场景难以在工程上落地。有用的推荐算法一定是易于工程实现的，跟公司当前的技术架构、人员能力、可用资源是匹配的；

3. 推荐系统冷启动：冷启动是推荐系统非常重要的一块，特别是对新产品，这块设计策略好不好直接影响用户体验，冷启动有很多实现方案，我们在《推荐系统冷启动》这篇文章已经做过完整的介绍；

4. 推荐系统UI设计和交互逻辑：好的产品UI和交互逻辑有时比好的算法更管用，推荐算法工程师一定要有这种意识，平时在做推荐系统时，也要往这方面多思考，当前的UI及交互是否合理，是否还有更好的方式，多参考或者咨询一下设计师的思路想法，多体验一下竞品，往往你会有新的收获。这里给大家举一个电视猫产品的例子(见下面图18)， 好的UI交互可以极大提升用户体验和点击。我们会在后续文章中专门介绍这方面的知识。

图18：好的UI和交互的价值甚至比好的算法大很多

 

1. 推荐系统的价值度量：让推荐系统发挥价值，首先要度量出推荐系统的价值。我们需要将推荐系统的价值量化出来，只有量化出推荐系统的价值，推荐工程师的价值才能够被公司认可，老板才愿意在推荐系统上投入更多的资源。关于这一块我们已经在《推荐系统的商业价值》这篇文章中进行过详细的介绍，这里不再赘述。

八、推荐系统的技术选型

根据18.1节推荐系统与大数据的描述， 推荐业务落地依赖大数据技术， 推荐系统的中间过程和结果的存储需要依赖数据库， 推荐系统接口实现需要依赖web服务框架。这些方面需要的软件和技术在前面基本都有简单介绍，也都有开源的软件供选择，对创业公司来说，没有资源和人力去自研相关技术，选择合适的开源技术是最好最有效的方案。本节详细描述一下推荐系统算法开发所依赖的机器学习软件选型，方便大家在工程实践中参考选择。

由于推荐系统落地强依赖于大数据相关技术，而最流行的开源大数据技术基于Hadoop生态系统，所以推荐算法技术选型要围绕大数据生态系统来发展，需要无缝地将大数据和人工智能结合起来。

 

基于大数据生态系统有很多机器学习软件可以用来开发推荐系统，比如Apache旗下的工具Spark MLlib、Flink-ML、 Mahout、SystemML。以及可以运行在Hadoop生态系统上的DeepLearning4J(Java深度学习软件)、 TonY（Tensorflow on YARN，LinkedIn开源的）、CaffeOnSpark(雅虎开源的)、BigDL(基于Spark上的深度学习，Intel开源的)等。

 

随着人工智能第三次浪潮的到来，以Tensorflow，Pytorch，MXNet等为代表的深度学习工具得到工业界的大量采用，Tensorflow上有关于推荐系统、排序框架的模块和源代码，可供学习参考，通过简单修改可以直接用于推荐业务中。这一块我们在《深度学习在推荐系统中的应用》第4节中已经做过介绍。

 

另外像xgboost、scikit-learn、H2O、gensim等框架也是非常流行实用的框架，可以用于实际工程项目中。国内也有很多开源的机器学习框架，腾讯开源的Angel(基于参数服务器的分布式机器学习平台，可以直接运行在yarn上)，百度开源的PaddlePaddle(深度学框架)，阿里开源的Euler(图深度学习框架)，X-DeepLearning(深度学习框架)，也值得大家学习参考。

 

作者所在公司主要采用Spark Mllib、Tensorflow、gensim等框架来实现推荐系统算法的开发，基本可以满足推荐系统各个业务的需要。其中以Spark Mllib为主，我们的Doraemon框架也是基于Spark二次封装实现的。Tensorflow、gensim只是作为部分业务的补充。

 

至于开发语言，Hadoop生态圈基本采用Java/Scala，深度学习生态圈基本采用Python(Tensorflow、Pytorch都采用python作为用户使用软件的开发语言，但它们的底层还是用C++开发的)，所以采用Java/Scala、Python作为开发语言有很多开源框架可供选择，相关的生态系统也很完善。

 

大数据系统目前业界事实的标准只有Hadoop生态系统一个，这个是任何一个toC的互联网公司必须要使用的技术。如果推荐业务采用Python系的框架，那么需要面对的问题是怎么打通python系框架和大数据框架之间的鸿沟，我们在《深度学习在推荐系统中的应用》这篇文章6.3节给出了两个可能的工程实现方案，读者可以参考。

 

随着大数据、云计算、深度学习驱动的人工智能浪潮的发展，越来越多的顶级科技公司开源出很多好用的、有价值的机器学习软件工具， 可以直接用于工程中，也算是创业公司的福音。

九、推荐系统工程的未来发展

随着移动互联网、物联网的发展，5G技术的商用，未来推荐系统一定是互联网公司产品的标配技术和标准解决方案，推荐系统会被越来越多的公司采用，用户也会越来越依赖推荐系统来做出选择。

 

在工程实现上， 推荐系统会越来越依赖实时推荐技术更快地响应用户的兴趣(需求)变化，给用户提供强感知的推荐服务，最终提升用户体验，增加公司收益。

 

未来一定会有专门的开源的推荐引擎出现，并且是提供一站式服务，让搭建推荐系统成本越来越低(现在也有少量的开源推荐项目，但是基本是偏学术研究的，还不能真正方便地用于工程中)。同时随着人工智能的发展，越来越多的云计算公司会提供推荐系统的PAAS或者SAAS服务(现在就有很多创业公司提供推荐服务，只不过做的还不够完善)， 创业公司可以直接购买推荐系统云服务，让搭建推荐系统不再是技术壁垒，到那时推荐系统的价值将会大放异彩！

 

当推荐系统云服务成熟时，不是每个创业公司都需要推荐算法开发工程师了，只要你理解推荐算法原理，知道怎么将推荐系统引进产品中创造价值，就可以直接采购推荐云服务来构建推荐产品。就像李开复博士最新的畅销书《AI未来》中所说的，很多工作会被AI取代，所以推荐算法工程师也要有危机意识，要不断培养对业务的敏感度，对业务的理解。真到那个时候，也可以做一个推荐算法商业策略师。

总结

本文讲解了推荐系统工程实现方面的知识，介绍了推荐系统与大数据的关系，推荐系统包含的核心模块和支撑模块及其作用与价值，特别是对推荐系统架构设计和工程实现哲学进行了详细介绍。作者公司打造的Doraemon框架可以作为读者构建推荐系统架构的参考。我们在最后几部分，讲解了近实时个性化推荐、推荐系统业务落地需要关注的一些问题、技术选型及推荐系统工程实现上未来可能的发展与变化。

 

本文所讲内容是作者多年推荐系统学习、实践经验的总结，希望能够帮助到从事推荐系统开发的读者，让读者在工程实现上少走弯路。