作者：爱奇艺技术 ，该文根据【i 技术会】现场演讲整理而成

在建设机器学习平台之前，爱奇艺已经拥有比较成熟的深度学习平台 Javis，但是 Javis 面向的用户比较高阶、专业的算法工程师，需要通过提交代码到专用计算集群上运行计算，使用门槛比较高。

另外，算法除了深度学习以外，机器学习，数据挖掘、数据分析等领域。对于有很多规模较小的业务，没有相对应的平台支持这些非深度学习，需要独立开发算法和工程平台来支撑落地。

这就是常说的造烟囱，每个业务要自己搭建算法平台，这很容易出现两个问题：一个是在算法方面，很多业务不是基于算法为核心打造业务，使用机器学习或许仅仅是用于辅助或优化业务，所以可能并没有很专业的算法人员对模型或者算法有比较深入的理解；另外一个问题，虽然有算法人员，但是对算法的落地其实还是要做一些工程方面的东西，对于不同业务来说属于重复造轮子。

此外对于爱奇艺的数据中台战略来说，智能服务是数据中台的必要功能。

从以上三点来看，建设机器学习平台就有了比较清晰的定位。

机器学习平台的服务的人群包括算法工程师、数据分析师，也包括业务研发工程师，我们希望通过构建高效的离线、实时预测服务，降低用户使用机器学习的成本，提高接入算法的效率，利用数据中台的优势促进数据和模型的规范和分享。

发展历程

简单介绍一下爱奇艺机器学习平台的发展历程。

1.0

截止目前主要是经历了三个大版本，第一版也是基于业务造烟囱的阶段。这一版由于围绕具体业务搭建服务，所以整个架构里面算法部分很少，但是在这一版本我们通过 Spark ML 调度算法的核心系统，实现了算法的异步分布式调度。上线后对算法接入的效率提升非常明显。

在第一版积累的技术经验基础上，我们发现当前通用机器学习平台的需求，于是迭代了第二版，实现面向通用需求的机器学习平台。

2.0

第二版里最显著的特征，是在用户层增加了可视化前端，可以通过拖拉拽的方式让用户组建自己的机器学习流程。用户通过自由拼搭算法组件，解决了通用化后百花齐放的流程需求。

另外一个重点是把调度服务独立出来。其中，实验调度子系统对任务状态进行监控，负责任务的调度，通过对任务心跳汇总，随时能了解任务集群全局的状态，当任务执行节点出现异常中断时，能第一时间重试或重新分发到其他节点，极大保证了服务的稳定性。

任务执行引擎是任务运行的核心。任务执行引擎接收实验调度服务推送来的任务，根据任务配置的内容从模型池获取模型资源、从数据管理子系统读写数据、执行脚本。由于任务执行引擎不绑定任何具体的算法框架，实现算法执行能轻松跨越不同算法框架和平台。

通过消息日志监控，自动收集调度各个算法和平台产生的日志信息和终端信息，并通过配置关键字的方式提取有用的信息和数据，在前端聚合展示，或实现某些功能的即时图表功能。

算法模型池也作为独立服务进行管理，专门负责离线和实时预测获取模型和同步模型。

系统舍弃了 v1 中的通过 Europa 调度 Spark 集群任务，以及自己维护的定时任务，接入爱奇艺的大数据平台 Babel 和定时任务调度服务平台 Gear。接入这两个平台以后一来实现了和数据中台的打通，二来实现了离线服务。

在算法的框架上，由于把执行引擎分离出来了，所以可以很轻松的加入更多的框架，在第二版里面除了 SparkML 里面常见的一些算法以外，还扩展了常用的像 XGBoost 和图类的算法。

3.0

3.0 的主要目标是完善功能版图，主要实现了在线预测的服务。针对用户提出的一些提高效率的需求，也提供了自动调参、增加参数服务器扩展了模型数据量的支持。另外由于用户有需求通过别的平台接入机器学习平台，所以也提供了 API 服务。

到目前为止，已经形成了一站式平台，基本覆盖了机器学习全流程。通过平台操作，用户可以从特征工程到模型训练、模型评估、在线和离线预测实现了整套机器学习的流程。通过把机器学习流程的数据源和数据目的接入整个大数据开发平台，完成了一整套的闭环。

系统经验

分享在实际过程中的一些经验。

1. 自动调参

当用户在具体做一个模型调优的时候，如果模型的参数设置不对的话，很影响模型的准确率。模型的参数也并不相同，像 LR、线性回归 4 个参数，多的像 XGBoost 暴露出 17 个参数，虽然不是每个参数都参与调参，但是总是会遇到一些排列组合。如果人工调参，参数组少则几十，多则上百种组合。比如 XGBoost，使用人力来调参基本不可想象。

目前的机器学习框架，普遍自带调参功能，比如 Spark ML，但是调参能力相当有限，因为只能做随机和全组合（穷举搜索）。使用 Spark 自带的调参方法，如果用户没有一点直觉经验排除调参区间，那就需要拼计算资源或者人品。

算法框架自带的调参系统还有另一个局限性，就是无法跨平台复用调参算法。因此我们设计一个系统层面的调参框架，可以调用 Spark、python 等不同算法框架，也可以不局限在算法框架语言限制内开发自己的调参算法。

我们的自动调参的系统从流程上来看比较简单。系统把调参分为多轮次迭代进行。传统调参算法比如随机调参、网格搜索调参只有一轮，高级的算法会有多轮调参，通过前一轮调参的评估结果适当缩小调参区间，最终把参数收敛到一个最优值。

系统读取用户设置的参数区间后，根据用户的需求把区间划分为多个子区间，并在每个子区间随机采样参数作为首次调参的组合，并通过任务分发服务下发给执行引擎，调度对应的算法框架训练和评估。训练任务结束后，执行引擎把评估结果返回给调参服务。

收集到当前轮次所有评估结果后，调参服务调起算法计算下一轮的调参空间，并调整下一轮的取样个数，再次下发给执行引擎测试，循环往复，直到达到最大轮次限制或收敛程度。

我们可以把整个调参流程看做是一个大型的模型训练过程，通过结果反馈不断找到极值的过程。从这种思路出发，可以加入很多适用的算法作为调参算法。

目前机器学习平台除了支持随机算法和网格搜索的算法，也实现了贝叶斯优化以及自研的遗传算法。测试发现自研的算法调参效率远优于传统默认的算法。

2. 数据规模的支持

系统初期只支持 SparkML 框架，正常训练万级别的数据集几分钟能训练完成，但是当用户数据集只有几十到几百数量级时，任务也需要跑几分钟，相对于单机的 python 秒级训练完成的时间来说相当慢。其中一个原因是任务提交到 Spark 集群上需要等待资源分配。真正训练时间短，但其他的准备时间也让用户觉得很慢。所以我们在后续版本把 python 的单机的引擎也引用进来。当数据量小的时候用户可以直接在单机上做这种操作。

另一方面，在训练亿级以上的数据量时传统的 SparkML 训练相当慢甚至崩溃失败。这是因为 Spark 对超大规模的模型的训练并不擅长，Spark 训练模型分多轮迭代，每一轮需要所有的执行器的任务做完后才汇总参数，根据木桶原理，整个 Spark 任务会受到最慢的 worker 运行时间影响。

另外，所有的执行器会通过广播的方式对参数进行共享，对于大规模参数量的模型来说相当占网络带宽，也会导致系统使用率效果非常低。

解决方案是通过参数服务器的方式解决，参数服务器本身原理上对分布式的训练进行了一些改良，并不是等所有的执行器跑完，等一部分跑完超过一个预值强行终止了。为了提高整个集群的效率牺牲了一些部分的收敛的速度，另外取消了广播机制来传递参数，把参数放在独立的叫做参数服务器里面，通过读取，这样子也节省了网络的消耗。

爱奇艺的机器学习平台在设计之初就支持跨算法框架调度。我们调研了多种开源的参数服务器，最终集成了腾讯的 Angel 参数服务器，并对一些典型模型做了测试。测试证明，在训练亿级以上规模的模型时，参数服务器的训练效率相对 Spark 有明显提升 50% 以上的速度。

3. 模型的管理平台和算法调度

不论是 Sklearn，还是 Spark ML 的模型预测，从代码角度来看，预测功能是不同模型内部的方法。不存在通用的预测方法兼容所有的模型。对于开发人员自己写代码的时候没问题，但如果做一个通用化的平台，需要考虑统一的预测组件来处理所有的模型预测，并有一定的扩展性，通过一个预测组件兼容不同算法框架的模型。

和预测组件类似的另一个问题是，不同算法模型，甚至跨框架的模型，如何都能统一部署到在线预测的服务中去？

以上 2 个问题可以通过自定义模型文件解决。模型训练完后，在默认模型文件输出的同时，也输出自定义文件和 PMML 文件。PMML 是一套有标准的模型定义语言，可用于跨平台的读取模型，适合用于离线训练 + 在线预测的场景。另外，在自定义文件里可以输出更多平台有用的信息，比如模型评估分数、模型类型、模型训练的相关表和字段名、模型参数、训练上下文等等。

在模型接入预测组件时，预测组件读取自定义文件，获取到模型的所在框架和模型类型，并通过对应的模型框架加载模型文件即可。

在在线预测中，通过读取到训练的上下文，可以把模型训练上游所需的预处理过程一并加载到在线预测过程中，减轻用户单独预处理过程的负担。

4. 在线预测系统搭建

在线预测系统对不同用户的需求场景提供不同的调用方式。

本地模式是在线预测平台把模型信息整体自动封装在服务 jar 包中，提供给用户轻量级调用；云模式是在线预测服务平台结合 docker 服务，生成一组计算集群。云模式支持 HTTP 服务与 RPC 服务。在 HTTP 服务中，系统通过 consul 服务申请动态域名，并通过自动发现服务关联 docker 服务。用户仅需通过服务提供的域名访问，无需了解后端部署流程。

RPC 服务是基于 Dubbo 实现。模型预测服务被 Dubbo 封装后通过 docker 连接 zookeeper 实现服务发现。用户端仅需通过客户端连接指定的连接字即可访问服务。

离线预测平台是基于流程的发布，在线预测则是基于模型和模型上下文信息进行发布。模型管理平台中使用推模式和拉模式两种方式部署在线服务。拉模式为用户主动更新服务的模式；而推模式为模型在模型管理平台中更新后被动更新的方式。通过两种方式的结合，在线服务覆盖所有模型更新场景。

案例介绍

反作弊业务是一个独立的业务系统，管理反作弊相关业务逻辑和业务数据。反作弊平台定义和构建了不同反作弊识别过滤场景，并自动拆解成工作流在数据中台中具体运维。涉及到算法相关的流程，通过数据中台转到机器学习平台处理，处理后的结果也会回到数据中台。

下图中包括了流量反作弊所有的场景和相关算法，包括常见的监督算法，监督算法，黑白样本，然后聚类算法，异常检测算法，此外，还有基于团伙的同类的算法，和一些深度学习的算法。

每天大概能过滤大概千万级以上的日志，在线预测峰值的时候是要超过能达到万级的 KPS，所有拥有这么一个平台，效率提升大致在 80% 以上。