摘要： 在4月27日2016云栖大会南京峰会上，阿里云算法专家、阿里云推荐引擎技术负责人郑重（卢梭）为大家分享了“21天搭建推荐系统”，这次分享得到了大家的积极反馈。因此，云栖社区邀请卢梭做客云栖社区，在6月16日晚8点在线再次分享《21天搭建推荐系统》。 在4月27日2016云栖大会南京峰会上，阿里云算法专家、阿里云推荐引擎技术负责人郑重（卢梭）为大家分享了《21天搭建推荐系统》议题，这次分享得到了大家的积极反馈。因此，云栖社区邀请卢梭做客云栖社区，在6月16日晚8点在线再次分享《21天搭建推荐系统》。本次活动已经顺利结束，持续近2个小时，在此感谢大家的支持和关注。 下面是本次活动视频、幻灯及内容整理。 点击图片看视频回顾 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、电商等）。 简单的总结一下：阿里云推荐引擎的特点是接入简单便捷，算法开放。 目标：让客户专注于推荐业务，不再被系统问题困扰。 方法：通用的推荐引擎，集中实现与业务无关的内容。 效果：推荐是个系统工程，算法很重要，但不是全部。 ——结束—— 原文：https://yq.aliyun.com/articles/39629

S A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z SASL [backcolor=transparent]Simple Authentication and Security Layer一种用来扩充 C/S 模式验证能力的机制。memcached 从 1.4.3 版本开始，支持 SASL 认证。由于云数据库 Memcache 版的多租户共享特性，也采用 SASL 作为鉴权机制。SASL 本质上是使用密码保证的缓存数据安全，建议采用强密码和定期修改密码的策略。云数据库 Memcache 将每 60s 自动进行一次鉴权。 SchedulerX 一款分布式任务调度产品。用户在应用中依赖 SchedulerX-Client，并在 SchedulerX 控制台创建定时任务，进行相应的参数配置后，启动该应用就可以接收到定时任务的周期调度。SchedulerX-Server 集群为调度触发提供高可用性和高稳定性的保证，并且可以实现对用户客户端机器集群进行分布式调度。 SDK [backcolor=transparent]Software Development Kit请参见 软件开发工具包。 SDN 请参见 软件自定义网络。 Shard MongoDB 集群中的分片。单个 shard 是由三节点的副本集组成，保证单个分片的高可用性，用户可以根据自己的应用性能及存储要求，购买多个 shard 来扩展读写性能及存储空间，实现一个分布式数据库系统。 SLA [backcolor=transparent]Service-Level Agreement服务的企业与客户之间就服务的品质、水准、性能等方面所达成的双方共同认可的协议或契约。 SRV 记录 一般是为 Microsoft 的活动目录设置时的应用。 SSH [backcolor=transparent]Secure Shell由 IETF 的网络工作小组（Network Working Group）所制定；SSH 为建立在应用层和传输层基础上的安全协议。 SSH 密钥对 [backcolor=transparent]SSH Key Pair是阿里云为您提供的新的远程登录 ECS 实例的认证方式。 设备标识 [backcolor=transparent]Device ID每个设备独一无二的标识，由业务方自己指定，例如每个传感器设备的序列号。需要保证全局唯一。 设备组名 [backcolor=transparent]Group ID用于指定一组逻辑功能完全一致的节点共用的组名，代表一类相同功能的设备。 身份凭证 [backcolor=transparent]Identity Credential用户登录账户需要进行的身份验证包括 Password、AccessKey、MFA-Key。 生产流 [backcolor=transparent]Production FlowMemcache 生产流是 Web 或 APP 的使用者通过 Memcache 的客户端对KV键值本身的操作，如增（Add）、删（Delete）、查（Get）、改（Replace、Set）等操作。 生产者实现服务 生产者将实现服务接口以提供具体实现，除了代码实现的工作之外，由于 HSF 是基于 Spring 框架来实现的，所以还需要再定义服务发布的 XML 文件。 伸缩触发任务 [backcolor=transparent]Scaling Trigger Task用于触发伸缩规则的任务，如定时任务、云监控的报警任务。 伸缩规则 [backcolor=transparent]Scaling Rule定义具体的扩展或收缩操作，例如加入或移出 N 个 ECS 实例。 伸缩活动 [backcolor=transparent]Scaling Activity伸缩规则成功触发后，就会产生一条伸缩活动。伸缩活动主要用来描述伸缩组内 ECS 实例的变化情况。 伸缩配置 [backcolor=transparent]Scaling Configuration定义用于弹性伸缩的 ECS 实例的配置信息。 伸缩组 [backcolor=transparent]Scaling Group一个具有相同应用场景的 ECS 实例的集合，定义了组内 ECS 实例数的最大值、最小值及其相关联的负载均衡实例和 RDS 实例等属性。 时间粒度 [backcolor=transparent]Time GranularityARMS 中的数据集都自带时间属性，其中时间粒度定义了用户在查询数据时所需要返回数据的时间粒度，如 1 天、2 小时、5 分钟等。 实例 [backcolor=transparent]Instance一个独立的资源实体，包含基本的资源要素。 实例 ID [backcolor=transparent]Instance ID实例对应一个用户空间，是使用云数据库的基本单位。云数据库对单个实例根据不同的容量规格有不同的连接数、带宽、CPU 处理能力等限制。用户可在控制台中看到自己购买的实例 ID 列表。云数据库实例分为主-从双节点实例和高性能集群实例两种。 视频点播 [backcolor=transparent]ApsaraVideo for VoD （VoD）是集音视频上传、自动化转码处理、媒体资源管理、分发加速于一体的一站式音视频点播解决方案。请参见 视频点播。 视频码率 [backcolor=transparent]Video Rate视频文件在单位时间内使用的数据流量，视频文件的码流越大，压缩比就越小，画面质量就越高。 视频直播 [backcolor=transparent]ApsaraVideo for Live是基于领先的内容接入与分发网络和大规模分布式实时流媒体转码技术打造的音视频直播平台，提供便捷接入、高清流畅、低延迟、高并发的音视频直播服务。请参见 视频直播。 视频帧率 [backcolor=transparent]FPS (Frames PerSecond)也称为帧速率。指每秒钟刷新的图片的帧数。每秒钟帧数 (FPS) 越多，所显示的动作就会越流畅。普通的帧率是 24 帧。 实时流媒体集群 [backcolor=transparent]Real-time Streaming Media Cluster一个具有负载均衡能力的可水平扩展集群，并且，借助弹性伸缩服务，该集群能够根据集群整体负载（负载均衡上所承载的视频流路数）的变化自动进行伸缩，以适应波动的业务访问压力，节约成本。 事务 [backcolor=transparent]Transaction指作为单个逻辑工作单元执行的一系列操作，要么完全执行，要么完全不执行。 事务边界 [backcolor=transparent]Transaction Boundary分布式事务需要进行开启，在执行结束后需要进行结束（提交或回滚），事务开启和关闭即划定了一个事务边界。 事务别名 [backcolor=transparent]Transaction Alias为客户应用中可自定义的标识部分，放在 @TxcTransaction 注解中用于标识运行中某块事务是否开启全局事务，此名称可以在控制台上看到。 事务发起者 [backcolor=transparent]Transaction Initiator即 GTS 客户端，通过事务协调者开启／提交分布式事务。 事务分支 [backcolor=transparent]Transaction Branch一个分布式事务可能包含多个分支，只有当所有的分支全部成功时，分布式事务才能成功，一个分支的失败将导致分布式事务的回滚。在 GTS 框架下，分支可能是一个分库上执行的 SQL 语句，或是一个手动模式分支。 事务分组 [backcolor=transparent]Transaction Group每个 GTS 应用都需要申请一个事务分组名称，这个唯一名称由客户指定的参数部分以及系统数据组成。 事务管理器 [backcolor=transparent]GTS Server即 GTS Server，负责分布式事务的推进，为客户端发起的分布式事务请求分配全局唯一的事务 ID，并记录资源管理器提交的事务分支的状态，最终负责全局事务的提交或回滚。 事务实例名 [backcolor=transparent]Transaction Instance Name是客户应用中开启事务的代码块的标识，可以帮助用户了解应用的哪部分代码开启了全局事务，此名称可以在控制台上看到。 事物数 每秒钟 SQL 语句执行次数和事务处理数，包括 Insert、Delete 和 Update 等操作。 事务消息 [backcolor=transparent]Transaction MessageMQ 提供类似 X/Open XA 的分布事务功能，通过 MQ 事务消息能达到分布式事务的最终一致。 授权策略 [backcolor=transparent]Authorization Policy授权策略是阿里云定义的描述权限的语言规范。请参见 策略语法结构。 授权对象 权限组规则的一个属性，代表一条权限组规则被应用的目标。在专有网络内，授权对象可以是一个单独的 IP 地址或一个网段；在经典网络内，授权对象只能是一个单独的 IP 地址（一般为 ECS 实例的内网 IP 地址）。 数据安全险 [backcolor=transparent]Data Security Insurance是众安保险针对阿里云用户推出的信息安全综合保险，若因黑客攻击导致用户云服务器上的数据泄露并造成经济损失，众安保险将为投保用户提供最高 100 万元人民币的现金赔偿，降低投保用户因黑客攻击意外事件带来的经济损失。请参见 数据安全险。 数据传输 [backcolor=transparent]Data Transmission （DTS）一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服务。支持关系型数据库、NoSQL、大数据(OLAP)等数据源间的数据传输。请参见 数据传输。 数据范围 订阅通道中存储的增量数据时间戳的范围，增量数据对应的时间戳是这条增量数据在 RDS 实例中应用完并写入事务日志的时间戳。默认情况下订阅通道中只保留最新一天的增量数据。数据传输服务会定期清理过期的增量数据，同时更新订阅通道的数据范围。 数据风控 是基于阿里大数据计算能力，通过业内领先的风险决策引擎，解决企业账号、活动、交易等关键业务环节存在的欺诈威胁，降低企业经济损失。请参见 数据风控。 数据更新 数据传输服务将数据库中的更新数据类型分为：数据更新和结构更新。数据更新是指只修改数据，但是不修改结构对象定义。例如 insert、update、delete 等。 数据管理 [backcolor=transparent]Data Management （DMS）一种集数据操作、对象管理、资源大盘、实例授权、安全审计、数据趋势、数据追踪、数据图表、性能与优化和服务器管理于一体的数据管理服务。支持 MySQL、SQL Server、PostgreSQL、MongoDB、Redis 等关系型数据库和 NoSQL 的数据库管理，同时还支持 Linux 服务器管理。请参见 数据管理。 数据集 [backcolor=transparent]Dataset数据集定义了监控任务中如何基于采集到的数据做聚合计算，持久化存储，以及 Open API 访问输出。 数据集成 [backcolor=transparent]Data Integration是阿里集团对外提供的稳定高效、弹性伸缩的数据同步平台，为阿里云各个云产品(包括 MaxCompute、Analytic DB、OSS、OTS、RDS 等)提供离线(批量)数据进出通道。请参见 数据集成。 数据集维度 [backcolor=transparent]Dataset Dimension维度是数据集在创建时被用于聚合的 Key 值，类似于数据库中 GroupBy 的列名，或者多维联机分析处理中的属性。数据集将根据设置的维度来对实时数据进行对应的聚合操作。 数据集指标 [backcolor=transparent]Dataset Indicator数据集中存储的具体指标，一般为数字类型，类似于多维联机分析处理中的值。ARMS 的指标一般对应于实时计算后的 Count、Max、Sum、Count Distinct 等值。 数据可视化 [backcolor=transparent]DataV专精于业务数据与地理信息融合的大数据可视化呈现，帮助非专业的工程师通过图形化的界面轻松搭建专业水准的可视化应用，满足您日常业务监控、调度、会展演示等多场景使用需求。请参见 数据可视化。 数据库审计服务 可针对数据库 SQL 注入、风险操作等数据库风险操作行为进行记录与告警。请参见 数据库审计服务。 数据盘 [backcolor=transparent]Data Disk仅包含数据的磁盘，不含操作系统。 数据清洗 [backcolor=transparent]Data Cleansing数据清洗是指对日志数据进行切分、静态 Join 等操作，最终转化标准的 Key-Value(KV) 格式的过程。 数据筛选 [backcolor=transparent]Data Screening在数据集中定义什么样的数据将被用于数据集计算。不满足筛选条件的数据在数据集中将被过滤。 数据生命周期 [backcolor=transparent]Time To Live数据的存活时间，属性列数据的版本号距离当前时间大于数据生命周期即为过期数据。 数据源 [backcolor=transparent]Data Source接入监控任务的实时数据来源，如 ECS 上的日志，Loghub、 MQ Topic 等。 水平拆分 [backcolor=transparent]Horizontal Sharding/Partitioning按照指定规则，将原本保存在一张表中的数据行，分散到多张表中，实现水平线性扩展。 顺序发布 [backcolor=transparent]Ordered Delivery of Messages对于指定的一个 Topic，客户端将按照一定的先后顺序进行发送消息。 顺序消费 [backcolor=transparent]Ordered Consumption of Messages对于指定的一个 Topic，按照一定的先后顺序进行接收消息，即先发送的消息一定会先被客户端接收到。 顺序消息 [backcolor=transparent]Ordered MessageMQ 提供的一种按照顺序进行发布和消费的消息类型, 分为全局顺序消息和分区顺序消息。 私网 [backcolor=transparent]Intranet一个使用与因特网同样技术的计算机网络，它通常建立在一个企业或组织的内部并为其成员提供信息的共享和交流等服务。 碎片化存储 [backcolor=transparent]Fragmented Storage将文件拆分成多个碎片多副本、多磁盘存储。 T A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z TCP [backcolor=transparent]Transmission Control Protocol请参见 传输控制协议。 Tengine 由淘宝网发起的 Web 服务器项目。它在 Nginx 的基础上，针对大访问量网站的需求，添加了很多高级功能和特性。 TPS 每秒钟 SQL 语句执行次数和事务处理数。 Transaction ID [backcolor=transparent]XID即 GTS 分布式事务的全局事务 ID，GTS 服务会为每一个分布式事务生成一个全局唯一的分布式事务 ID。由于其全局唯一性，我们可以通过 GTS 日志中的 XID 帮助排查问题。 态势感知 收集企业 20 种原始日志和网络空间威胁情报，利用机器学习还原已发生的攻击，并预测未发生的攻击。请参见 态势感知。 弹性公网 IP [backcolor=transparent]Elastic IP一种 NAT IP。它实际位于阿里云的公网网关上，通过 NAT 方式映射到了被绑定 ECS 实例的私网网卡上。因此，绑定了弹性公网 IP 的 ECS 实例可以直接使用这个 IP 进行公网通信，但是在网卡上并不能看到这个 IP 地址。 弹性伸缩 [backcolor=transparent]Auto Scaling根据用户的业务需求和策略，自动调整其弹性计算资源的管理服务。其能够在业务增长时自动增加 ECS 实例，并在业务下降时自动减少 ECS 实例。请参见 弹性伸缩。 弹性 Web 托管 阿里云推出的新一代建站主机，基于先进的容器技术架构，资源隔离性好，且具有攻击隔离能力，更稳定、安全，带配套控制面板，管理体验同虚机一样简单。请参见 弹性 Web 托管。 淘宝分布式数据层 [backcolor=transparent]Taobao Distributed Data Layer （TDDL）淘宝分布式数据库服务中间件产品，集中式配置的 JDBC DataSource实现，具有读写分离，动态数据库配置等功能。 同步初始化 在同步链路增量数据同步前，将同步对象的历史数据初始化到目标实例。 同步性能 每秒同步到目标实例的记录数，单位为 RPS。同步性能为数据同步售卖的规格定义。 同步延迟 同步到目标实例的最新数据在源库执行的时间戳，同源实例当前时间戳的差值。 通道沉默 当某一条报警发出后，如果这个指标 24 小时之内持续超过报警阈值，则 24 小时内不会再次触发报警。 透明数据加密 [backcolor=transparent]Transparent Data Encryption（TDE）对整个数据库，包括数据和日志文件执行实时 I/O 加密和解密的功能。TDE 对于连接到所选数据库的应用程序来说是完全透明的，它不需要对现有应用程序做任何改变。 推荐引擎 [backcolor=transparent]Recommendation Engine （RecEng）是在阿里云计算环境下建立的一套推荐服务框架，用于实时预测用户对物品偏好，支持您定制推荐算法，支持 A/B Test 效果对比。请参见 推荐引擎。 吞吐量 [backcolor=transparent]Throughput对网络、设备、端口、虚电路或其他设施，单位时间内成功地传送数据的数量。 U A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z UDP [backcolor=transparent]User Datagram Protocol请参见 用户数据报协议。 URL 转发 当您访问该域名的时候，自动跳转到预先设置好的地址上去。包括显性 URL 转发和隐形 URL 转发。 V A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z VLAN [backcolor=transparent]Virtual Local Area Network一种将局域网设备从逻辑上划分成一个网段，从而实现虚拟工作组的新兴数据交换技术。 VPC [backcolor=transparent]Virtual Private Cloud用户基于阿里云创建的自定义私有网络，不同的专有网络之间彻底逻辑隔离，用户可以在自己创建的专有网络内创建和管理云产品实例，比如 ECS、Intranet 负载均衡、RDS 等。请参见 VPC。 VPN [backcolor=transparent]Virtual Private Network在公用网络上建立专用网络的技术。 VXLAN [backcolor=transparent]Virtual Extensible LAN一种在 UDP 中封装 MAC 的简单机制，可以创建跨多个物理 IP 子网的虚拟 2 层子网。

GPU SRIOV原理 谈起GPU SRIOV那么这个世界上就只有两款产品：S7150和MI25。都出自AMD，当然AMD的产品规划应该是早已安排到几年以后了，未来将看到更多的GPU SRIOV产品的升级换代。S7150针对的是图形渲染的客户群体，而MI25则针对机器学习，AI的用户群体。本文以围绕S7150为主。因为S7150的SRIOV实例在各大公有云市场上都有售卖，而MI25目前看来尚未普及（受限于AMD ROCm生态环境的完备性）。 两个术语：SRIOV的PF，VF （专业人士请自动忽略这部分介绍） PF ：宿主机上的主设备，宿主机上的GPU驱动安装在PF上。PF的驱动是管理者。它就是一个完备的设备驱动，与一般的GPU驱动的区别在于它管理了所有VF设备的生命和调度周期。比如下图的07:00.0便是PF设备 VF ：也是一个PCI设备，如下图中的07:02.0和07:02.1。QEMU在启动过程中通过VFIO模块把VF 作为PCI直通设备交由虚拟机，而虚拟机上的操作系统会安装相应的驱动到这个直通的VF PCI 设备上（07:02.0）。VF设备占用了部分GPU资源。比如下图中一个PF上面划分出了两个VF，那么很有可能跑在VF上面的虚拟机GPU图形渲染性能宏观上是PF的1/2。 上图是一个带有4个S7150的服务器，并且每个S7150 SRIOV虚拟出2个vGPU。 GPU SRIOV的本质 SRIOV的本质是把一个PCI卡资源（PF）拆分成多个小份（VF），这些VF依然是符合PCI规范的endpoint设备。由于VF都带有自己的Bus/Slot/Function号，IOMMU/VTD在收到这些VF的DMA请求的过程中可以顺利查找IOMMU2ndTranslation Table从而实现GPA到HPA的地址转换。这一点与GVT-g和Nvidia的GRID vGPU有本质上的区别。GVT-g与Nvidia GRID vGPU并不依赖IOMMU。其分片虚拟化的方案是在宿主机端实现地址转换和安全检查。应该说安全性上SRIOV方法要优于GVT-g和GRID vGPU，因为SRIOV多了一层IOMMU的地址访问保护。SRIOV代价就是性能上大概有5%左右的损失（当然mdev分片虚拟化的MMIO trap的代价更大）。由于SRIOV的优越性和其安全性，不排除后续其他GPU厂商也会推出GPU SRIOV的方案。 关于SRIOV 更多的思考 SRIOV也有其不利的地方比如在Scalable的方面没有优势。尤其是GPU SRIOV，我们看到的最多可以开启到16个VM。设想如果有客户想要几百个VM，并都想要带有GPU图形处理能力（但是每个VM对图形渲染的要求都很低），那么SRIOV的方案就不适用了。如果有一种新的方案可以让一个GPU的资源在更小的维度上细分那就完美了。事实上业界已经有这方面的考虑并付诸实践了。 GPU SRIOV内部功能模块 （吃瓜群众可以跳过） 由于没有GPU SRIOV HW的spec与Data Sheet，我们仅能按照一般的常用的方式来猜测GPU SRIOV内部功能模块（纯属虚构，如有雷同概不负责）。 GPU的资源管理涉及到vGPU基本上三块内容是一定会有的：Display，安全检查，资源调度。 Display管理 GPU PF需要管理分配给某个VF的FrameBuffer大小，以及管理Display相关的虚拟化。Display的虚拟化一般分为Local Display和Remote Display。比如XenClient就是用的Display Local Virtualization，属于本地虚拟化过程。此过程相当于把显示器硬件单元完全交由当前虚拟机控制。在云计算行业，Display更多的是采用Remote Display的方式。我们后续会讲到行业中Remote Display的问题所在。 VF 安全检查 GPU PF或者GPU SRIOV模块需要承担一部分的VF的地址审核（Address Audit）和安全检查，GPU SRIOV的硬件逻辑会保证暴露出的VF Register List并确保不包含特权Register信息，比如针对GPU微处理器和FW的Registers操作，针对电源管理部分的Registers也不会导出到VF中。而VM对所有VF的MMIO读写最终会映射到PF的MMIO地址空间上，并在PF的类似微处理器等地方实现VF设备的部分MMIO模拟。 另外一部分的安全检查则是PF需要确保不同VF直接对GPU FrameBuffer的访问隔离。这部分很有可能需要PF针对不同的VF建立GPU的Pagetable，或者Screen所有的VF提交的GPU BatchBuffer。 VF调度 AMD GPU SRIOV从硬件的角度看就是一个对GPU资源的分时复用的过程。因此其运行方式也是与GPU分片虚拟化类似。SRIOV的调度信息后续重点介绍。 GPU SRIOV的调度系统 分时复用 VF的调度是GPU虚拟化中的重点，涉及到如何服务VM，和如何确保GPU资源的公平分片。 GPU SRIOV也是一个分时复用的策略。GPU分时复用与CPU在进程间的分时复用是一样的概念。一个简单的调度就是把一个GPU的时间按照特定时间段分片，每个VM拿到特定的时间片。在这些时间片段中，这个VM享用GPU的硬件的全部资源。目前所有的GPU虚拟化方案都是采用了分时复用的方法。但不同的GPU虚拟化方案在时间片的切片中会采用不同的方法。有些方案会在一个GPU Context的当前BatchBuffer/CMDBuffer 执行结束之后启动调度，并把GPU交由下一个时间片的所有者。而有些方案则会严格要求在特定时间片结束的时候切换，强行打断当前GPU的执行，并交予下一个时间片的所有者。这种方式确保GPU资源被平均分摊到不同VM。AMD的GPU SRIOV采用的后一种方式。后续我们会看到如何在一个客户机VM内部去窥探这些调度细节。 调度开销 然而GPU的调度不同于CPU的地方是GPU上下文的切换会天然的慢很多。一个CPU Core的进程切换在硬件的配合下或许在几个ns之内就完成了。而GPU则高达几百ns（比如0.2ms-0.5ms）。这带来的问题就是GPU调度不能类似CPU一样可以频繁的操作。举一个例子：GPU按照1ms的时间片做调度，那么其中每次调度0.5ms的时间花在了上下文的切换上，只有1ms的时间真正用于服务。GPU资源被极大浪费。客户理论上也只能拿到66%的GPU资源。 S7150的调度细节 接下来我们来看一下作为首款GPU SRIOV方案的S7150是如何调度的。由于S7150是中断驱动的结构，所以通过查看虚拟机内部GPU中断的分布情况就可大致判断出GPU SRIOV对这个虚拟机的调度策略。 对于Windows的客户机，我们可以在内部安装Windows Performance kit，并检测"GPU activity"的活动。 对于Linux的客户机，则更简单，直接查看GPU驱动的trace event。当然我们要感谢AMD在提供给Linux内核的SRIOV VF驱动上没有去掉trace event。这让我们有机会可以在VM内部查看到SRIOV的调度细节。（不知道这算不算一种偷窥？） 我们在阿里云上随便开启一台GA1的1/2实例。 并选择Ubuntu（预装AMD驱动）作为系统镜像; 在Console下查看所有的GPU相关的trace如下表： 很不错，我们发现有两个GPU驱动分发workload的event：amd_sched_job与amd_sched_process_job。 在VNC中开启一个GPU Workload以后（比如Glxgears或者Glmark，当然我们需要先开启x11vnc），我们通过下面Command来采集GPU数据。 trace-cmd record –e gpu_sched … 等待几秒中ctrl+c终止采集。 trace-cmd report > results.log 查看我们抓取这两个event的事件并记录下来几个有趣的瞬间： 所有的log在一段时间内是连续的，然后断开一段时间，然后又连续的workload提交。 截图上的小红框是我们需要关注的间隔时间。摘取如下表： 事件时间ns间隔 1437.8038881437.8101596.271ms无GPU活动1437.8163781437.8227206.342ms无GPU活动1437.8291051437.8351276.022ms无GPU活动1437.8415871437.8475065.919ms无GPU活动 很明显在上述时间窗口期内当前VM的GPU被暂停了，并被切换至服务其他VM。因此当前VM的GPU workload会积压在驱动层次。 我们把所有的event在图表上打点后就可以发现，对于一个1/2GPU实例的VM来说，它占用的GPU资源是基本上以6ms为时间片单位做切换的。 作图如下： 估算vGPU的调度效率 我们假设每次vGPU的调度需要平均用到0.2ms，而调度的时间片段是6ms，而从上图的结果来看，AMD GPU SRIOV是采用严格时间片调度策略。6ms一旦时间用完，则马上切换至下一个VM（哪怕当前只有一个VM，也会被切走）。所以1/2实例的S7150的调度效率可以达到：96.7%如果有两个这样的VM同时满负荷运行，加起来的图形渲染能力可达到GPU直通虚拟化的96.7%以上。 实测结果如下： 1/2vGPU+ 1/2vGPU = 97.4% (vs GPU直通性能) 每一个vGPU可以达到直通GPU性能的48.x%，整体性能可以达到97.4%，与我们的预估非常接近。 更多的关于GPU虚拟化调度的思考 不得不说AMD S7150在vGPU调度上是非常成功的。AMD的GPU硬件设计保证了可以在任何当前GPU Batch Buffer的执行过程中可以被安全的抢占（GPU Workload Preemption），并切换上下文到一个新的Workload。有了这样卓越的硬件设计，才使得PF驱动在软件层面的调度算法可以如此从容有序。6ms强制调度保证了多VM在共享GPU资源的情况下不会饥饿不会过度占用。调度开销极小（2-3%）。而且这样的设计在VM数量不多的情况下可以进一步调整时间片的大小比如12ms，则GPU的利用率会更进一步提高。那么为什么不能采用100ms调度呢？因为Windows内核对"GPU activity"的活动有监视。任何GPU CMD在2秒内没有响应，Windows就会发起Timeout Detected Recover（TDR），重置GPU驱动。设想如果你有16个VM，调度时间片为100ms的情况下，平均一个VM轮转到GPU资源的最小间隔就有1.6s。加上其他由于PF驱动被Linux内核调度的延迟，很有可能触发Windows Guest内部的TDR。 不知不觉把GPU虚拟化的调度都在这章里讨论过了。很好，专门介绍GPU调度的章节可以省下来了。