如何推荐引擎？（阿里推荐引擎概述总结）

一、阿里推荐引擎概述

推荐引擎（RecommendationEngine，以下简称RecEng，特指阿里云推荐引擎）是在阿里云计算环境下建立的一套推荐服务框架，目标是让广大中小互联网企业能够在这套框架上快速的搭建满足自身业务需求的推荐服务。

推荐服务通常由三部分组成：日志采集，推荐计算和产品对接。推荐服务首先需要采集产品中记录的用户行为日志到离线存储，然后在离线环境下利用推荐算法进行用户和物品的匹配计算，找出每个用户可能感兴趣的物品集合后，将这些预先计算好的结果推送到在线存储上，最终产品在有用户访问时通过在线API向推荐服务发起请求，获得该用户可能感兴趣的物品，完成推荐业务。

RecEng的核心是推荐算法的定制。RecEng为推荐业务定义了一套完整的规范，从输入，到计算，到输出，客户可以在这个框架下自定义算法和规则，以此满足各种行业的需求，包括电商，音乐，视频，社交，新闻，阅读等。同时，RecEng也提供了相应的方法供客户便捷的接入用户访问日志，以及自定义满足其自身业务需求的在线API。

二、费用

推荐引擎费用如下：

API调用次数加1（百万次／月），则每个月增加100元费用。

大数据计算服务MaxCompute费用分两种方式，分别是预付费（包年包月）和按量付费，具体如下：

三、使用步骤

3.1 创建MaxCompute项目

3.2 资源管理—-添加云计算资源

3.3 业务列表—-新建业务

此处的大数据计算资源就选择3.2添加的计算资源。

注：调用API接口时的bizCode值即是新建业务时填写的“业务code”。

业务列表页面展示已经添加的业务的列表。业务是推荐引擎中的基本管理单元，业务包含基本属性、数据和场景三类信息。

业务基本属性，包含业务code、业务名称、大数据计算资源和在线存储资源。业务code是业务的唯一标识，大数据计算资源是您在资源管理中配置的大数据计算服务MaxCompute资源，在线存储资源是系统内置的在线资源或您在资源管理中配置的表格存储TableStore资源。

数据，定义了所能使用的数据范围。例如商品推荐业务的数据范围是用户数据、商品数据和行为数据等，视频推荐业务的数据范围是用户数据、视频数据和行为数据等。在推荐业务中，数据是至关重要的一环，数据的质量决定了推荐效果的上限。

场景，是指在您的APP或网站中使用推荐功能的模块，这些模块直接触达您的用户提供推荐服务。例如在商品推荐业务中，商品详情页的下方要提供一个相关商品推荐模块，那么场景就可以描述为”详情页商品相关推荐“。场景主要负责算法的配置和API调用，测试环境下的场景用于开发测试，线上环境下的场景用于和您的业务系统对接。

3.4 配置业务数据

3.5 创建推荐场景

测试没问题可发布到线上：

线上的场景也可以下线进行测试。

注：调用推荐API时，参数scnCode即为此处新建场景时的“场景Code”字段。

四、数据规范

4.1 数据格式规范

推荐引擎的基础数据模型如下：

该数据模型总共包括了7张表，这些表有以下特点：

1、在MaxCompute（原来ODPS）中需要自己手工创建这些表；

2、表名没有固定要求，可以按照自己的习惯命名；

3、每张表的表结构必须符合推荐引擎的要求，列名、字段类型和分区格式需要和规范中保持一致（参考下面的表结构说明）；

4、每张表中填充的数据，必须符合推荐引擎的要求；

5、 每张表中是否都有记录取决于业务场景和业务数据现状，其中以下几张表中必须有数据：用户信息表、物品信息表、用户行为表；

6、对于业务数据中无法提供的字段可以填NULL；

7、每张表都必须是分区表，以’yyyyMMdd’格式的字符型字段ds作为分区字段；

8、除了行为表需要每日上传外，其他meta表如果不发生变化可以不导，推荐引擎会自动获取最近一个有数据的分区中的meta表数据进行算法计算。

9、如果未传可推荐物品表，则将物品表全量作为可推荐物品表，继承item_info 字段；

10、推荐引擎在对数据进行离线计算时，会产生数据结果数据和中间数据。其中中间数据的数据量大小取决于所使用的离线流程中的算法复杂度。例如一个标准的协同过滤算法其中间表数据量可能是原始数据输入表数据量的5到10倍。推荐引擎默认对中间数据保留一天。

4.2 日志埋点规范

推荐引擎的日志格式为标准的JSONObject。其中对于实时行为日志，可以使用日志API这个API进行上传，将每条日志put到demo中的logs中。

五、附录（阿里推荐引擎常用词语及解释）

• 客户/租户（org/tenant）

指RecEng的使用者，系统中由其阿里云账号代表。通常客户是一个组织，RecEng中常用org表示客户。

• 用户（user）

指客户的用户，即RecEng使用者的用户。推荐是一个2C的服务，使用推荐服务的客户必然有其自己的用户，RecEng使用者的用户简称为“用户”，系统中常用user表示用户。

• 物品（item）

指被推荐给用户的内容，可以是商品，也可以是歌曲，视频等其他内容，系统中常用item表示物品。

• 业务（biz）

业务针对数据集定义，定义了算法所能使用的数据范围。一个客户在RecEng上可以有多个业务，不同的业务必然有不同的数据集。RecEng要求每个业务提供四类数据（不要求全部提供）：用户数据，物品数据，用户行为数据，推荐效果数据。每一组这样的数据就构成一个业务。系统中常用biz表示业务。

比如某客户A有两类被推荐的物品，分别是视频和歌曲，于是客户A可以在RecEng上建立两个业务M和N，其中M的物品数据为视频，N的物品数据为歌曲，其他的数据（指用户数据，用户行为数据等）可以都相同。在这种方案下，业务M和N的数据是独立的，即业务M虽然能看到用户对于歌曲的行为，但是业务M中不包含歌曲的物品数据，所以会丢弃用户对于歌曲的行为；如果业务M中某用户只对歌曲有行为，对视频没有行为，业务M也会丢弃这类用户。反之对业务N亦然。

一个业务最好只推荐一类物品。多类物品的推荐在后续的行业模板会有支持，需要引入板块(plate)的概念，一份业务数据可以生成多个板块的数据集，场景绑定某个板块进行推荐算法计算。

• 场景（scn）

场景指的是推荐的上下文，每个场景都会输出一个API，场景由推荐时可用的参数决定。有两种场景最为常见，分别是首页推荐场景和详情页推荐场景。顾名思义，在执行首页推荐时，可用的参数只有用户信息；而在执行详情页推荐时，可用的参数除了用户信息，还包括当前详情页上所展示的物品信息。系统中常用scn表示场景。

一个业务可以包含多个场景，即对于某个业务A，它包含多个首页场景也是完全可以的。

事实上，回到场景的原始定义，场景只是由推荐的上下文决定，客户完全可以根据自己的需求建立全新的场景，比如针对搜索关键词的推荐场景，这时可用的参数除了用户信息，还有用户所输入的关键词。

• 流程（flow）

算法流程指数据端到端的处理流程，一部分流程属于业务范畴，如数据导入流程，效果计算流程，数据质量分计算流程；一部分属于场景，比如场景算法流程。从数据源类型和产出来划分，又分为离线流程，近线流程，在线流程。

• 离线流程

一般情况下，离线流程的输入和输出都是MaxCompute（原ODPS）表，所以离线数据规范其实上是一组MaxCompute表的格式规范，包括接入数据、中间数据和输出数据三类数据的格式规范。接入数据指客户离线提供的用户、物品、日志等数据，中间数据是在离线算法流程中产生的各种中间性质的结果数据表，输出数据是指推荐结果数据表，该结果最终将会被导入到在线存储中，供在线计算模块使用。

• 近线流程

推荐引擎的的近线流程主要处理用户行为发生变化、推荐物品发生更新时，对离线推荐结果进行更新。不像离线算法，天然以MaxCompute（原ODPS）表作为输入和输出，近线程序的输入数据可以来自多个数据源，如在线的表格存储（原OTS），以及用户的API请求，又或者是程序中的变量；输出可以是程序变量，或者写回在线存储，或者返回给用户。出于安全性考虑，推荐引擎提供了一组SDK供客户自定义在线代码读写在线存储（Table Store），不允许直接访问，所以需要定义每类在线存储的别名和格式。对于需要频繁使用的在线数据，无论其来自在线存储还是用户的API请求，RecEng会预先读好，保存在在线程序的变量中，客户自定义代码可以直接读写这些变量中的数据。

• 在线流程

推荐引擎的的在线流程负责的任务是推荐API接收到API请求时，实时对离线和近线修正产生的推荐结果进行过滤、排重、补足等处理；后者主要处理用户行为发生变化、推荐物品发生更新时，对离线推荐结果进行更新

一个场景只包含一个离线流程和一个近线流程，可以包含多个在线流程，用于支持A/BTest。

• 算法策略（Algorithm Strategy）

算法策略定义了一套离线/近线流程。并且透出相关的算法参数，帮助客户构建自己的算法流程。一个场景可以配置多个算法策略，最终会合并执行，产出一系列推荐候选集和过滤集，在线流程通过引用这些候选集来完成个性化推荐。

• 作业/任务（task）

作业指运行中的离线流程实例，作业和离线流程的关系完全等同于进程和程序的关系。每个作业都是不可重入的，即对每个离线流程，同一时间只允许运行一份实例。作业直接存在上下游关系，如果上游作业失败，下游任务也会被取消。