打造工业级推荐系统（三）：推荐系统的工程实现与架构优化

导读：个性化推荐系统，简单来讲就是根据每一个人的偏好推荐他喜欢的物品。互联网发展到如今，推荐系统已经无处不在，在各行各业都获得广泛都应用。亚马逊号称 40% 的收入是来自个性化推荐系统的，淘宝的个性化推荐系统也带来很是大的收益，新闻媒体的个性化推荐系统典型的是今日头条，直播平台给用户推荐喜欢的主播，金融网站给用户推荐须要的理财产品，社交网络给用户推荐大 V 或者其余朋友……愈来愈多的公司将推荐系统做为产品的标配。

你们接触推荐系统的几率会愈来愈大。做为程序员，了解推荐系统也愈来愈必要，甚至能够主动选择“推荐系统算法工程师”的相关职位。那你们必定会关心推荐算法工程师须要哪些知识储备，以及做为一个推荐算法工程师，将来的发展道路怎样？

本文是做者计划的一系列文章中的一篇。做者在上篇文章《推荐系统介绍》中简单对推荐系统作了一个较全面的介绍，相信你们对推荐系统有了初步的了解。本篇文章做者会结合多年推荐系统开发的实践经验粗略介绍推荐系统的工程实现，简要说明要将推荐系统很好地落地到产品中须要考虑哪些问题及相应的思路、策略和建议，其中有大量关于设计哲学的思考，但愿对从事推荐算法工做或准备入行推荐系统的读者有所帮助。为了描述方便，本文主要基于视频推荐来说解，做者这几年也一直在从事视频推荐系统开发的工做，其余行业的推荐系统工程实现思路相似。本篇文章主要从总体上来介绍推荐系统工程实现，之后发布的系列文章会逐步介绍工程实现的各个细节实现原理与策略。

推荐系统与大数据

推荐系统是帮助人们解决信息获取问题的有效工具，对互联网产品而也用户数和信息总量一般都是巨大的，天天收集到的用户在产品上的交互行为也是海量的，这些大量的数据收集处理就涉及到大数据相关技术，因此推荐系统与大数据有自然的联系，要落地推荐系统每每须要企业具有一套完善的大数据分析平台。

推荐系统与大数据平台的依赖关系以下图。大数据平台包含数据中心和计算中心两大抽象，数据中心为推荐系统提供数据存储，包括训练推荐模型须要的数据，依赖的其余数据，以及推荐结果，而计算中心提供算力支持，支撑数据预处理、模型训练、模型推断 (即基于学习到的模型，为每一个用户推荐) 等。

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

大数据与人工智能具备千丝万缕的关系，互联网公司通常会构建本身的大数据与人工智能团队，构建大数据基础平台，基于大数据平台构建上层业务，包括商业智能 (BI), 推荐系统及其余人工智能业务，下图是典型的基于开源技术的视频互联网公司大数据与人工智能业务及相关的底层大数据支撑技术。

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

在产品中整合推荐系统是一个系统工程，怎么让推荐系统在产品中产生价值，真正帮助到用户，提高用户体验的同时为平台方提供更大的收益是一件有挑战的事情，整个推荐系统的业务流能够用下图来讲明，它是一个不断迭代优化的过程，是一个闭环系统。

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

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

先介绍一下构建一套完善的推荐系统涉及到的主要业务流程及核心模块，具体流程以下图，下面分别介绍各个模块：

1. 数据收集模块

构建推荐模型须要收集不少数据，包括用户行为数据，用户相关数据及推荐“标的物”相关数据。若是将推荐系统比喻为厨师作菜，那么这些数据是构建推荐算法模型的原材料。巧妇难为无米之炊, 要构建好的推荐算法收集到足够多的有价值的数据是很是关键和重要的。

2. ETL 模块

收集到的原始数据通常是非结构化的，ETL 模块的主要目的是从收集到的原始数据中提取关键字段 (拿视频行业来讲，用户 id，时间，播放的节目，播放时长，播放路径等都是关键字段)，将数据转化为结构化的数据存储到数据仓库中。同时根据必定的规则或策略过滤掉脏数据，保证数据质量的高标准。在互联网公司中，用户行为数据跟用户规模呈正比，因此当用户规模很大时数据量很是大，通常采用 HDFS、Hive、HBase 等大数据分布式存储系统来存储数据。

用户相关数据及推荐“标的物”相关数据通常是结构化的数据，通常是经过后台管理模块将数据存储到 MySQL、ProgreSQL 等关系型数据库中。

3. 特征工程模块

推荐系统采用各类机器学习算法来学习用户偏好，并基于用户偏好来为用户推荐“标的物”, 而这些推荐算法用于训练的数据是能够“被数学所描述”的，通常是向量的形式，其中向量的每个份量 / 维度就是一个特征，因此特征工程的目的就是将推荐算法须要的，以及上述 ETL 后的数据转换为推荐算法能够学习的特征。

固然，不是全部推荐算法都须要特征工程，好比，若是要作排行榜相关的热门推荐，只须要对数据作统计排序处理就能够了。最经常使用的基于物品的推荐和基于用户的推荐也只用到用户 id，标的物 id，用户对标的物的评分三个维度，也谈不上特征工程。像 logistic 回归等复杂一些的机器学习算法须要作特征工程，通常基于模型的推荐算法都须要特征工程。

特征工程是一个比较复杂的过程，要作好须要不少技巧、智慧、行业知识、经验等，在这篇文章中做者不做详细介绍。

4. 推荐算法模块

推荐算法模块是整个推荐系统的核心之一，该模块的核心是根据具体业务及可利用的全部数据设计一套精准、易于工程实现、能够处理大规模数据的 (分布式) 机器学习算法，进而能够预测用户的兴趣偏好。这里通常涉及到模型训练、预测两个核心操做。下面用一个图简单描述这两个过程，这也是机器学习的通用流程。

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

5. 推荐结果存储模块

做者在最开始作推荐系统时因为没有经验，开始将推荐结果存储在 Mysql 中，当时遇到最大的问题是天天更新用户的推荐时，须要先找到用户存储的位置，再作替换，操做复杂，而且当用户规模大时，高并发读写，大数据量存储，Mysql 也扛不住，如今最好的方式是采用 CouchBase，Redis 等能够横向扩容的数据库，能够彻底避开 MySQL 的缺点。

在计算机工程中有“空间换时间”的说法，对于推荐系统来讲，就是先计算好每一个用户的推荐，将推荐结果存储下来，经过预先将推荐结果存下来，能够更快的为用户提供推荐服务, 提高用户体验。因为推荐系统会为每一个用户生成推荐结果, 而且天天都会 (基本全量) 更新用户的推荐结果，通常采用 NoSql 数据库来存储，而且要求数据库可拓展，高可用，支持大规模并发读写。

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

6. Web 服务模块

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

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

类似影片业务流

推荐系统支撑模块

推荐系统想要很好的稳定的发挥价值，须要一些支撑业务来辅助，这些支撑业务虽然不是推荐系统的核心模块，但倒是推荐业务稳定运行必不可少的部分，主要包括以下 4 大支撑模块，下面分别简述各个模块的做用和价值。

推荐系统核心支撑模块

1. 评估模块

推荐评估模块的主要做用是评估整个推荐系统的质量及价值产出。通常来讲能够从两个维度来评估。

• 离线评估：主要是评估训练好的推荐模型的“质量”，模型在上线服务以前须要评估该模型的准确度，通常是将训练数据分为训练集和测试集，训练集用于训练模型，而测试集用来评估模型的预测偏差。

• 在线评估：模型上线提供推荐服务过程当中来评估一些真实的转化指标，好比转化率、购买率、点击率、播放时长等。线上评估通常会结合 AB 测试，先放一部份量，若是效果达到指望再逐步拓展到全部用户，避免模型线上效果很差严重影响用户体验和收益指标等。

2. 调度模块

一个推荐业务要产生价值，全部依赖的任务都要正常运行。推荐业务能够抽象为有向无环图 (第六节推荐系统架构设计会讲到将推荐业务抽象为有向无环图)，所以须要按照该有向图的依赖关系依次执行每一个任务，这些任务的依赖关系就须要借助合适的调度系统 (好比 Azkaban) 来实现，早期咱们采用 Crontab 来调度，当任务量多的时候就不那么方便了，Crontab 也没法很好解决任务依赖关系。

3. 监控模块

监控模块解决的是当推荐业务 (依赖的) 任务因为各类缘由调度失败时能够及时告警，经过邮件或者短信通知运维或者业务的维护者，及时发现问题，或者能够在后台自动拉起服务。同时能够对服务的各类其余状态作监控，好比文件大小、状态变量的值、日期时间等与业务正常执行相关的状态变量，不正常时及时发现问题。

4. 审查模块

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

推荐系统范式

推荐系统的目的是为用户推荐可能喜欢的标的物, 这个过程涉及到用户、标的物两个重要要素，咱们能够根据这两个要素的不一样组合产生不一样的推荐形态，即所谓的不一样“范式 (paradigm)”(数学专业的同窗不难理解范式，若是很差理解能够将范式当作具有某种类似性质的对象的集合)，根据我本身构建推荐系统的经验能够将推荐系统总结为以下 5 种范式，这 5 中范式能够应用到产品的各类推荐场景中，后面会拿视频 APP 举例说明具体的应用场景。

• 范式 1：彻底个性化范式：为每一个用户提供个性化的内容，每一个用户推荐结果都不一样；

常见的猜你喜欢就是这类推荐，能够用于进入首页的综合类猜你喜欢推荐，进入各个频道 (如电影) 页的猜你喜欢推荐。下图是电视猫首页兴趣推荐，就是为每一个用户提供不同的个性化推荐；

• 范式 2：群组个性化范式：首先将用户分组 (根据用户的兴趣，将兴趣类似的归为一组)，每组用户提供一个个性化的推荐列表，同一组的用户推荐列表同样，不一样组的用户推荐列表不同；

这里举一个在做者公司利用范式 2 作推荐的例子，咱们在频道页三级列表中，会根据用户的兴趣对列表作个性化重排序，让与用户更匹配的节目放到前面，提高节目转化，可是在实现时，为了节省存储空间，先对用户聚类，同一类用户兴趣类似，对这一类用户，列表的排序是同样的，可是不一样类的用户的列表是彻底不同的。见下图的战争风云 tab，右边展现的节目集合总量不变，只是在不一样组的用户看到的排序不同，排序是根据与用户的兴趣匹配度高低来降序排列的。

• 范式 3：非个性化范式：为全部用户提供彻底同样的推荐；

好比各种排行榜业务，既能够做为首页上的一个独立的推荐模块，方便用户发现新热内容，也能够做为猜你喜欢推荐新用户冷启动的默认推荐，下图是搜索模块当用户未输入搜索关键词时给出的热门内容，也是采用该范式的例子；

• 范式 4：标的物关联标的物范式：为每一个标的物关联一组标的物，做为用户在访问标的物详情页时的推荐，每一个用户都是相同的标的物；

当用户浏览一个电影时，能够经过关联类似的电影, 为用户提供更多的选择空间 (下图就是电视猫电影详情页关联的类似影片)；还能够当用户播放一个节目退出时，推荐用户可能还喜欢的其余节目；针对短视频，能够将类似节目作成连播推荐列表，用户播放当前节目直接连播类似节目，提高节目分发和用户体验；

• 范式 5：笛卡尔积范式：每一个用户跟每一个标的物的组合产生的推荐都不相同，不一样用户在同一个视频的详情页看到的推荐结果都不同；

该范式跟 4 相似，只不过不一样用户在同一个节目获得的关联节目不同，会结合用户的兴趣，给出更匹配用户兴趣的关联节目；

因为每一个用户跟每一个标的物的组合推荐结果都不同, 每每用户数和标的物的数量都是巨大的, 没有足够的资源事先将全部的组合的推荐结果先计算存储下来，通常是在用户触发推荐时实时计算推荐结果呈现给用户，计算过程也要尽可能简单，在亚秒级就能够算完，好比利用用户的播放历史，过滤掉用户已经看过的关联节目；

下面给一个简单的图示来讲明这 5 种范式，让读者有一个直观形象的理解。

推荐算法的 5 种范式

总之，推荐系统不是孤立存在的对象，它必定是要整合到具体的业务中，在合适的产品交互流程中触达用户，经过用户触发推荐行为。因此，推荐系统要应用到产品中须要嵌入到用户使用产品的各个流程 (页面) 中。当用户访问首页时，能够经过综合推荐（范式 1）来给用户提供个性化推荐内容，当用户访问详情页，能够经过类似影片（范式 4）提供类似标的物推荐，当用户进入搜索页还没有输入搜索内容时，能够经过热门推荐给用户推送新热节目 (范式 3)。这样到处都有推荐，才会使产品显得更加智能。全部这些产品形态基本均可以用上面介绍的 5 种范式来归纳。

推荐系统架构设计

做者在早期构建推荐系统时因为经验不足，而业务又比较多，当时的策略是每一个算法工程师负责几个推荐业务 (一个推荐业务对应一个推荐产品形态)，因为每一个人只对本身的业务负责，因此开发基本是独立的，每一个人只关注本身的算法实现，虽然用到的算法是同样的，但前期在开发过程当中没有将通用的模块抽象出来，每一个开发人员从 ETL、算法训练、预测到插入数据库都是独立的，而且每一个人在实现过程当中整合了本身的一些优化逻辑，一竿子插到底，致使资源 (计算资源，存储资源，人力资源) 利用率不高，开发效率低下。通过几年的摸索，做者在团队内部构建了一套通用的算法组件 Doraemon 框架 (就像机器猫的小口袋，有不少工具供你们方便构建推荐业务)，尽可能作到资源的节省，大大提高了开发效率。开发过程的蜕变，能够用下面的图示简单说明，从中读者也能够对 Doraemon 架构落地先后的推荐业务开发变化有个大体的了解。

Doraemon 框架先后开发方式对比

做者构建 Doraemon 框架的初衷是但愿构建推荐业务就像搭积木同样 (见下图)，能够快速构建一套算法体系，快速上线业务。算法或者处理逻辑就像一块一块的积木，而算法依赖的数据 (及数据结构) 就是不一样积木之间是否能够衔接的“接口”。

本着上面朴素的思想，下面做者详细说说构建这套体系的思路和策略。

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

1. 通用性：所谓通用，就是该架构具有包容的能力，业务上的任何推荐产品均可以用这一套架构来涵盖和实现。

2. 模块化：模块化的目的在于将一个业务按照其功能作拆分，分红相互独立的模块，以便于每一个模块只包含与其功能相关的内容，模块之间经过一致性的协议调用。将一个大的系统模块化以后，每一个模块均可以被高度复用。模块化的目的是为了重用，模块化后能够方便重复使用和插拨到不一样平台，不一样推荐业务逻辑中。

3. 组件化：组件化就是基于可重用的目的，将一个大的软件系统拆分红多个独立的组件，主要目的就是减小耦合。一个独立的组件能够是一个软件包、web 服务、web 资源或者是封装了一些函数的模块。这样，独立出来的组件能够单独维护和升级而不会影响到其余的组件。组件化的目的是为了解耦，把系统拆分红多个组件，分离组件边界和责任，便于独立升级和维护，组件可插拔，经过组件的拼接和增减提供更丰富的能力。

组件化和模块化比较相似，目标分别是为了更好的解耦和重用，就像搭积木同样构建复杂系统。

4. 一致性：指模块的数据输入输出采用统一的数据交互协议，作到整个系统一致。

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

6. 抽象性：将类似的操做和流程抽象为统一的操做，主要目的是简化系统设计，让系统更加简洁通用。针对推荐系统采用数学上的概念抽象以下：

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

算法或者操做的算子抽象

业务抽象：任何一个推荐业务能够抽象为由数据 / 模型为节点，算子为边的“有向无环图”。下图是深度学习的算法处理流程，整个算法实现就是一个有向无环图。

下图是咱们作的一个利用深度学习作电影猜你喜欢的推荐业务流程，整个流程是由各个算子经过依赖关系连接起来的，就像一个有向无环图。

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

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

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

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

3. 数据流出组件：相似数据读入组件，将推荐结果插入最终存储 (如 Redis，CouchBase 等) 的操做封装成算子，咱们通常是将推荐结果流入 Kafka，利用 Kafka 做为数据管道，最终再从 Kafka 将数据插入推荐存储服务器；

4. 算法组件：这个是整个推荐系统的核心。在工程实现过程当中，咱们将推荐系统中涉及到的算子抽象为 3 个接口， AlgParameters(算子依赖的参数集合)、 Algorithm/AlgorithmEx (具体的算法实现，若是算法依赖模型，采用 AlgorithmEx，好比利用模型作推断)、Model(算法训练后的模型，包括模型的导入、导出等接口)。全部的算子实现实现上面 3 个接口的抽象方法。下图给出了这 3 个接口包含的具体方法以及 Spark mllib 中的矩阵分解基于该抽象的实现。

在咱们的业务实践中，发现上述抽象很合理，基本推荐业务涉及到的全部算子 (ETL、模型训练、模型推荐、排序框架、数据过滤，具体业务逻辑等) 均可以采用该方式很好的抽象。

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

6. 其余支撑组件：好比 AB 测试等，均可以整合到 Doraemon 框架中；

这里要特别说一下数据 (模型)，数据做为算子的输入输出，必定要定义严格的范式 (具有固定的数据结构，好比矩阵分解训练依赖的数据有三列，一列用户 id，一列物品 id，一列用户对物品的评分)，Spark 的 DataFrame 能够很好的支撑各类数据类型。数据格式定义好后，在算子读入或者输出时，能够对类型作校验，能够很好的避免不少因为业务开发疏忽致使的问题。这有点相似强类型编程语言，在编译过程 (相似算子) 能够检查出类型错误。

咱们将上面的 6 类组件封装成一个 Doraemon 的 lib 库，供具体的推荐业务使用。

基于大数据的数据中心和计算中心的抽象, 咱们将全部推荐业务中涉及到的数据和算子分别放入数据仓库和算子仓库, 开发推荐业务时根据推荐算法的业务流程从这两个仓库中拿出对应的“积木”来组装业务, 参考下图。

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

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

基于 Doraemon 框架开发的推荐业务，数据流与算子流相互交织，很是清晰

另外，若是公司作产品线的拓展，好比今日头条拓展新产品抖音、西瓜视频、火山小视频等，能够基于上面所提到的“推荐算法的范式”实现不少推荐业务 (好比猜你喜欢、类似影片、热门推荐等)，将这些业务封装到一个 DoraemonBiz.jar 的 jar 包，这样这些能力能够直接平移到新的产品线，赋能新业务。这种操做就是二次封装，具备极大的威力，下面给一个形象的图示来讲明这种二次赋能的逻辑，让你们更好理解这种思想。

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

从上面的介绍，相信你们已经感觉到了 Doraemon 框架的威力了，有了这套框架，咱们能够高效的开发算法了，若是有新的技术突破，咱们能够将这些新算法实现并封装到 Doraemon 框架中，不断拓展 Doraemon 的能力，让 Doraemon 成长为具有更多技能 (算子) 的巨人！

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

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

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

我的认为好的工程实现须要知足以下几个原则：

• 别人很容易理解你的逻辑；

• 按照业务流 / 数据流来组织代码结构；

• 便于 debug；

• 保证数据存储、代码模块、业务逻辑的一致性；

2. 设计好的推荐系统工程架构的原则？

• 尽可能将逻辑拆解为独立的小单元；

• 代码单元的输入输出定义清晰；

• 设置合适的交互出入口；

• 肯定通用一致的数据交互格式；

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

3. 怎么设计好的推荐系统工程架构？

• 肯定思考问题的主线：数据流 or 业务流；

• 画出业务流或者数据流的架构图；

• 肯定核心功能模块；

• 根据核心功能模块组织代码目录结构，数据存储结构；

• 定义清晰明确的数据格式；

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

业务流，数据存储，代码工程结构保持对应

近实时个性化推荐

推荐系统在实际业务实现时通常是 T+1 推荐 (天天更新一次推荐，今天利用昨天以前的数据计算用户的推荐结果)，随着移动互联网的深刻发展，特别是今日头条和快手等新闻，短视频 APP 的流行，愈来愈多的公司将 T+1 和实时策略相结合 (好比采用流行的 lambda 架构，下图是一个采用 lambda 架构的推荐架构图，供参考) 将推荐系统作到了近实时推荐, 根据用户的兴趣变化实时为用户提供个性化推荐。像新闻、短视频这类知足用户碎片化时间需求的产品，作到实时个性化能够极大提高用户体验，这样能够更好地知足用户需求，提高用户在产品的停留时间。这里咱们只是简单的介绍了一下实时个性化推荐，我在后续的系列文章中会详细讲解实时推荐系统。

推荐系统的 lambda 架构

推荐系统业务落地须要关注的问题

推荐系统要想很好的落地产生价值，除了算法实现、核心模块和支撑模块构建外, 还有不少方面须要考虑，下面简单描述一下其余须要考虑的点, 这些点都是很是重要的, 深刻理解这些问题，对真正发挥出推荐系统的价值有很是大的帮助。

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

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

3. 推荐系统冷启动：冷启动是推荐系统很是重要的一块，特别是对新产品，这块设计策略好很差直接影响用户体验, 冷启动有不少实现方案，做者之后会单独介绍冷启动的实现策略；

4. 推荐系统的解释：给用户提供一个推荐理由有时会达到事半功倍的效果，可以提高用户体验，促进用户的点击购买。推荐理由又是很难作的，主要是由于如今不少推荐算法 (特别是深度学习算法) 可解释性不强，给你作出了推荐可能很精准，可是整个系统没法给你解释为何给你推荐。拿推荐系统给你推荐了电影 A 来讲明，咱们能够从其余的途径来作解释， 好比“由于你喜欢 B”(电影 B 跟 A 有必定的类似性)，“今天是国庆节，为你推荐 A”，“今天是雨天，为你推荐 A”，“跟你兴趣类似的人都喜欢 A”等等，只要能够挖掘出用户的行为，场景 (时间，空间，上下文等)，跟推荐的电影的某种联系，这种联系均可以做为推荐解释的理由，没必要拘泥于必定要从推荐算法原理中寻找解释；

5. 推荐系统 UI 设计和交互逻辑：好的产品 UI 和交互逻辑有时比好的算法更管用，推荐算法工程师必定要有这种意识，平时在作推荐系统时，也要往这方面多思考，当前的 UI 及交互是否合理，是否还有更好的方式，多参考或者咨询一下设计师的思路想法，多体验一下竞品，每每你会有新的收获。我不是这方面的专家，这里只给你们举一个电视猫产品的例子 (见下图)， 好的 UI 交互能够极大提高用户体验和点击。

好的 UI 和交互的价值甚至比好的算法大不少

6. 推荐系统的价值度量：让推荐系统发挥价值，首先要度量出推荐系统的价值，咱们须要将推荐系统的价值量化出来，只有量化出推荐系统的价值，推荐工程师的价值才可以被公司承认，老板才愿意在推荐系统上投入资源。这里我简单说一下推荐系统的价值产出方式 (拿视频推荐举例说明)。

（1）推荐系统能够提高用户体验和留存，让用户更快更便捷找到想看的电影，减小找片时间：能够统计出推荐产生的播放量，总播放时长，人均播放时长，这些数值指标跟大盘的平均指标对比，能够体现推荐系统的优点，推荐系统的这些指标在大盘的占比也能够衡量推荐系统所占的份量；

（2）推荐系统能够创造收益：经过精准推荐会员节目，用户经过推荐的会员节目购买会员能够产生会员收益；在推荐的节目上作贴片广告，用户播放推荐的节目让广告曝光，能够产生广告收益；这两块收益须要量化出来，体现出推荐系统支撑商业变现的能力；

推荐系统的技术选型

根据第二节推荐系统与大数据的描述，推荐业务落地依赖大数据技术， 推荐系统的中间过程和结果的存储须要依赖数据库，推荐系统接口实现须要依赖 web 服务器。这些方面须要的软件和技术在前面基本都有简单介绍，也都有开源的软件供选择，对创业公司来讲，没有资源和人力去自研相关技术，选择合适的开源技术是最好最有效的方案。

本节详细描述一下推荐系统算法开发所依赖的机器学习软件选型, 方便你们在工程实践中参考选择。

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

基于大数据生态系统有不少机器学习软件能够用来开发推荐系统，好比 Apache 旗下的工具 SparkMLlib、Flink-ML、Mahout、Storm、SystemML。以及能够运行在 Hadoop 生态系统上的 DeepLearning4J(Java 深度学习软件)，TonY（TensorflowonYARN，LinkedIn 开源的），CaffeOnSpark(雅虎开源的)，BigDL(基于 Spark 上的深度学习，Intel 开源的) 等。

随着人工智能第三次浪潮的到来，以 Tensorflow，Pytorch，MXNet 等为表明的深度学习工具获得工业界的大量采用,Tensorflow 上有关于推荐系统、排序框架的模块和源代码，可供学习参考，经过简单修改能够直接用于推荐业务中。

另外像 xgboost,scikit-learn，H2O，gensim 等框架也是很是流行实用的框架，能够用于实际工程项目中。

国内也有不少开源的机器学习框架，腾讯开源的 Angel(基于参数服务器的分布式机器学习平台，能够直接运行在 yarn 上)，百度开源的 PaddlePaddle(深度学框架)，阿里开源的 Euler(图深度学习框架)，X-DeepLearning(深度学习框架)，也值得你们学习参考。

做者所在公司主要采用 SparkMllib，Tensorflow，gensim 等框架来实现推荐系统算法的开发。

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

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

推荐系统的将来发展

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

在工程实现上，推荐系统会愈来愈采用实时推荐技术来更快的响应用户的兴趣 (需求) 变化，给用户强感知，提高用户体验，增长公司收益。

我的以为将来会有专门的开源的推荐引擎出现，而且是提供一站式服务，让搭建推荐系统成本愈来愈低。同时随着人工智能的发展，愈来愈多的云计算公司会提供推荐系统的 PAAS 或者 SAS 服务 (如今就有不少创业公司提供推荐服务, 只不过还作的不够完善)，创业公司能够直接购买推荐系统云服务，让搭建推荐系统再也不是技术壁垒，到那时推荐系统的价值将会大放异彩！到那时, 不是每一个创业公司都须要推荐算法开发工程师了，只要你理解推荐算法原理, 知道怎么将推荐系统引进产品中创造价值, 就能够直接采购推荐云服务。就像李开复博士最新的畅销书《AI 将来》中所说的，不少工做会被 AI 取代，因此推荐算法工程师也要有危机意识，要不断培养对业务的敏感度，对业务的理解，短时间是没法被机器取代的，到时候说不定能够作一个推荐算法商业策略师。

小结

本文是做者多年推荐系统学习、实践经验的总结，但愿可以帮助到即将入行推荐系统开发的读者或者推荐系统开发人员，让你们少走弯路。因为做者才疏学浅，虽殚精竭虑，不当之处在所不免，欢迎你们评判指正，以便做者有所提升！

做者介绍：gongyouliu，有近 10 年大数据与 ai 相关项目经验，有 9 年推荐系统研究及实践经验，目前负责电视猫大数据与人工智能团队。喜欢读书，暴走，写做。业余维护“大数据与人工智能”公众号，ID：ai-big-data，持续输出推荐系统相关文章。我的微信：liuq4360