下面是本次活动视频、幻灯及内容整理。
PDF下载地址：https://oss-cn-hangzhou.aliyuncs.com/yqfiles/48f666836fdef5c4039eaf9c56817910.pdf
正文内容
大数据有三个非常经典的应用：计算广告、搜索、推荐。每一种应用最核心的地方都离不开三个字——个性化。广告不用说了，计算广告的基本要求就是要精准，为广告选择对其感兴趣的目标受众；搜索可以理解为对搜索关键词的个性化；而推荐，则需要在用户和物品之间建立兴趣关系。推荐的业态比较复杂，有类似淘宝天猫这样的真正意义上大数据场景，也有很多中小网站、应用，数据量其实并不是很大。阿里云推荐引擎（https://data.aliyun.com/product/re）的初衷，是为了帮助阿里云的客户、创业者、中小网站，让他们能够更好的运营自己的产品或网站。
推荐系统一般包括展现子系统、日志子系统和算法子系统三个部分，三者互为一体。
推荐系统
“展现”部分不仅要负担展现，还是数据采集的窗口，用户在展现系统的所有行为通过日志录入，采集到的数据经过算法子系统的计算，可以得到用户的偏好或者个性化兴趣，然后回过头来指导“展现”部分怎样做的更聚焦。
阿里云推荐引擎（RecEng）是推荐系统的一部分，主要实现的是算法子系统，需要和其他子系统配合工作。
使用阿里云推荐引擎分为两大阶段
第一阶段：基本功能的搭建
Day1. 环境准备
环境准备
环境准备分为两部分。图中左侧为云上资源的准备，我们需要拥有阿里公有云账号，然后开通云监控服务（可选）和阿里云数加服务（必选）；开通数加账号后，大数据计算服务(MaxCompute，原名ODPS)和大数据开发Data IDE就默认开通了(Data IDE相当于MaxCompute的可视化包装)，最后开通推荐引擎。未来客户在推荐引擎中用到的数据，以及相关离线计算，都在客户自己的MaxCompute项目中完成。右侧为客户侧的准备，前端的展现，以及日志的采集和管理都需要客户自己完成，通过推荐引擎提供的API与推荐引擎进行交互。通常情况下，客户侧的后台相关功能会集中在推荐服务器中实现，这也是阿里云推荐引擎墙裂建议的方案。推荐服务器可以是客户自己的物理机，也可以是阿里云的虚拟机ECS，都是可以的。
Day2-3. 数据准备
DT时代的基本要求是数据要能够“存、通、用”。采集日志，并将其上传到公共云实现了数据“存”的过程；推荐引擎负责解决数据的“通”和“用”。“用”比较好理解，“通”则指的是所有进入推荐引擎的数据必须满足推荐引擎所定义的格式规范。推荐有三类数据：用户数据、物品数据和行为数据，我们定义了这三种表的格式规范，比较简单，具体细节可以参考https://help.aliyun.com/document_detail/shujia/RE/dataspec/datauploadspec.html。
那么，如何把数据传到公共云上来呢？目前主要有两种方法，一是利用集成在MaxCompute console中的Tunnel命令，该命令的缺点只能上传文本格式数据；另一种方法是定制DataX上传，DataX作为连接各种数据库中间的节点，它除了可以作为文本上传，还可以把各种数据库打通。DataX的缺点是目前只能在Linux环境下运行。
当然，未必每一个业务的数据都满足规范的要求，所以还需要做一些格式转换。Data IDE提供了比较友好的格式转换界面，还可以把配置好的任务设置为定时任务，每天定时调度；也可以在MaxCompute console下直接执行格式转换的SQL脚本，再利用系统的crontab命令实现定时任务。
Day4-5. 基本配置和离线计算
环境和数据都准备好了之后，接下来需要进入阿里云推荐引擎产品，真正开始使用推荐引擎了。不过在此之前，还需要对产品中的一些关键概念进行必要的说明。
第一个概念是业务。在阿里云推荐引擎中，业务指的是一组可被用来进行推荐算法计算的完备数据集，包括物品表、行为表、用户表这三张表。也可以简单的认为这三张表就构成了一个业务。
第二个概念是场景，所谓场景就是推荐的上下文。换句话说，就是在进行推荐时有哪些可用的参数。比如在进行首页推荐的时候，可用的参数只有用户的ID；在进行详情页推荐的时候，可用的参数除了用户ID，还可以由详情页上展示的物品ID，这样首页推荐和详情页推荐就是两个推荐的场景。一个业务可以包括多个场景。
第三个概念是算法流程，算法流程指的是数据端到端的处理流程，从客户的输入数据开始，到产出最终结果为止。推荐算法流程从属于场景，一个场景可以包含多个算法流程。每个推荐算法流程都包括两部分，离线计算流程和在线计算流程。离线计算流程负责从原始的业务数据（用户、物品、行为）开始，计算用户对物品的兴趣，输出本场景下用户可能会感兴趣的物品集合；在线计算流程实时接受推荐请求，从离线计算流程得到的物品集合中根据业务规则挑选出最合适的若干个物品返回给请求方。一个场景包含多个推荐算法流程这种设定使得我们在做效果对比变的比较容易，后面会介绍A/B Testing，在A/B Testing中，每个推荐算法流程都是一个可被效果指标度量的最小单元。在做完A/B Testing之后，通常只会在一个场景下保留一个效果最好的推荐算法流程。
产品里的配置都比较简单，配置业务基本信息、配置业务依赖的云资源、配置业务数据表，接着配置场景、配置API参数，最后配置算法流程，阿里云推荐引擎提供了两个默认的推荐算法流程模板，分别针对首页场景和详细页场景，图为首页场景的离线计算流程模板，图中每一个节点就是一个算法，最终产出离线计算结果。
Day6-8. 推荐API集成
推荐API集成
到了这一步，云端推荐引擎里的推荐算法逻辑已经配置完成，剩下的事情就是把系统串起来，让推荐引擎和日志、展示两个子系统结合起来，成为推荐系统。阿里云推荐引擎提供了一组API，这里要做的就是把这些API集成到推荐服务器中。
首先需要把离线数据传上来，可以用前面提到的方法，Tunnel啊，DataX啊，都可以，但是一定要是定时任务，我们总不能每天都去手工执行数据上传。上传完成之后首先调用数据预处理API，对数据做一些预处理；然后调用离线计算API，启动离线计算。待离线计算完成后，通过推荐API就可以实时获取用户的推荐结果了。在离线计算的过程中，还可以通过查看计算任务状态API实时获取计算任务的状态，便于及时发现异常。
上图也展示了我们对推荐服务器的一些基本建议。诸如数据上传、启动离线计算这些功能建议由一个相对独立的数据管理组件来负责；而实时性要求比较高的推荐结果获取建议由专门的推荐管理组件来负责。推荐管理组件和数据管理组件为什么要有一个交互呢？这是因为从推荐引擎返回的结果中可能只包括了物品的ID，展示时不能只展示一个ID，还有很多材料，这些东西可以放在推荐服务器中，由数据管理模块负责管理。UI可以提供人工管理数据的界面，比如新录入了一个物品，或者某个物品卖完了要下线，需要做实时修正时就可以用到了。
这些工作都完成之后，一个具备最基本功能的推荐系统就可以运行起来了。
第二阶段：高级功能的搭建
Day9-11. 效果报表
Trace ID的生命周期
推荐系统run起来了之后，也意味着我们从系统搭建阶段进入了运营阶段。运营阶段最关心的就是效果，度量效果的东西，就是指标。用户在访问网站或者应用时会留下很多行为日志，在度量推荐系统的效果时，我们只关心和推荐有关的行为。为了和其他无关的行为区分开来，阿里云推荐引擎在每次推荐API的返回结果中都附带有一个Trace ID（这次推荐API返回的所有物品共享这一个Trace ID），客户需要按照一定的规范把这些Trace ID埋入日志，这样才能利用阿里云推荐引擎提供的效果报表功能。
Trace ID的埋点有三个原则：其一是在推荐列表展示时，需要把对应的Trace ID埋入推荐列表中所有物品的链接里；其二是如果用户点击了包含有Trace ID的物品链接，需要把这个Trace ID带入下一个页面，且要在新页面中所有该物品的链接里都埋入这个Trace ID；其三是如果用户点击了不含Trace ID的物品，或点击了包含有其他Trace ID的物品链接，之前的Trace ID失效。
完成了Trace ID的埋点，就可以使用阿里云推荐引擎的效果报表功能了，首先需要按照以下步骤在阿里云推荐引擎中进行配置：
1. 定义/选择效果算法。系统默认提供了一些用于计算效果指标的算法，如统计PV，UV，计算不同行为的转化率等，客户也可以开发自定义效果算法，开发完成后注册到推荐引擎即可
2. 定义效果指标。效果算法不针对具体的行为类型，而定义效果指标则需要明确行为类型，比如浏览的PV，点击的UV等
3. 选择效果指标，定义效果指标计算任务。有可能不是所有定义出来的效果指标都有必要计算出来，阿里云推荐引擎允许客户做一次筛选，推荐引擎会针对客户的筛选结果自动生成指标计算任务。
4. 定制效果报表。就是选择效果指标的展示方式，饼图折线图之类的，比较简单。
最后，按照惯例，需要在推荐服务器中把启动效果计算任务的API集成进来，每天定时启动，自动生成每日的效果报表。
Day12-15. 优化
优化的目标可以有很多种，对于业务来讲，最关心的莫过于提升各种转换率指标。前面的效果指标为我们提供了转换率的度量方法，以此为基础，通过A/B Testing来比较不同推荐算法流程的转换效果，从中选择最优的结果。到了这一步，问题就归结为如果去构造不同的推荐算法流程，这样我们才能够进行比较和选择。
算法流程
前面已经介绍过，推荐算法流程分为离线和在线两部分，上图进一步给出了离线、在线算法流程的内部细节，图中的曲边矩形表示数据（集），矩形表示算法（集）。具体每个节点的技术细节就不展开了，重点想说明的是阿里云推荐引擎中每个算法，对其输入和输出的数据，都有明确的格式要求，客户可以根据业务需求按照规范要求自行实现。对于任何满足输入输出数据格式规范的算法，在算法流程中都是可以互相替换的，这样可以构造出不同的算法流程，从而进行对比和优化。
Day16-20. 实时修正
阿里云推荐引擎支持两类实时修正，分别通过数据修正API和实时的用户行为日志提交到推荐引擎。数据修正API一般用来解决物品的实时变更需求，比如有新物品上线，或者老物品下架，需要及时调整；利用用户行为日志的修正一般用来调整用户的兴趣偏好，根据用户实时行为进行更有针对性的推荐。阿里云推荐引擎会提供默认的修正算法，客户也可以根据业务需求自己定义。
按照惯例，如果要使用实时修正功能，需要在推荐系统中接入相应的API：数据更新API和实时日志API。
Day21. 监控和告警
最后是监控和报警。开通云监控后，我们还需要做一些配置，首先配置自定义监控项（按照文档配置即可），可得到该监控项的云监控code，把云监控code注册到推荐引擎。然后添加监控人员报警组和设置报警规则。监控默认对于任务计算失败或者数据异常给出告警。阿里云推荐引擎会对每一张数据表上都挂有一个数据质检算法，用于检查表中数据是否合格。数据是否合格取决于所使用的算法，如果客户有自定义算法，可以自己编写相应的数据质检算法，并挂载到对应的数据表上。
未来工作和总结
阿里云推荐引擎还有很多需要完善和优化的地方，接下来我们将着重于以下两点：
- 简化基于规则的推荐：很多客户数据量不是很大，算法起到的作用很有限，一定要能够适应到小客户的需求，方便客户发现数据中的规则，结合业务和运营积累的知识，将其应用在推荐系统中。
- 提供更多的算法：实现更多的推荐算法，针对行业的算法模板（视频、音频、O2O、电商等）。
简单的总结一下：阿里云推荐引擎的特点是接入简单便捷，算法开放。
- 目标：让客户专注于推荐业务，不再被系统问题困扰。
- 方法：通用的推荐引擎，集中实现与业务无关的内容。
- 效果：推荐是个系统工程，算法很重要，但不是全部。
——结束——
