Opal 机器学习平台：爱奇艺数智一体化实践

  01

综述

Opal 是爱奇艺大数据团队研发的机器学习平台，包含特征生产、样本构建、模型训练、模型部署在内的多环节 Bigdata + AI 开发服务，内置多种训练镜像、特征算子、效率工具，为用户提供低门槛、高性能的数智应用开发工程化能力，覆盖了推荐、广告、风控等多个业务场景，帮助业务提升特征迭代、模型训练效率，进而提升业务效果。

背景

近年来，机器学习、深度学习算法在推荐、广告、搜索、风控等业务场景中的占比越来越高，相关业务团队开发及部署算法模型的需求也日益旺盛。纵观整个机器学习的工程化落地过程，其实掺杂着很多与算法本身不是很相关，但是跟基础设施强相关且通用的事情，比如环境搭建、框架版本适配、模型部署、训练任务监控、任务调度、多租户、与大数据体系打通等。而对于算法工程师来说，即使他们能在算法、模型、数据探索等工作上发挥出更大的价值，也逃不过经常在工程化方面花费更多的时间和精力。这极大地影响了算法模型开发及上线的效率，进而阻碍了业务发展，在此背景下，以业务提效、链路整合为目标的大数据机器学习平台应运而生。

非一体化旧方案

在业务启动初期，各算法团队通过搭建脚手架快速推进业务模型上线，随着业务发展，每支团队会逐渐整合形成从原始数据清洗到样本构建，再到模型训练和部署上线的开发链路。但在实践过程中，我们发现不同团队的链路往往存在下面问题：

1.重复开发：业务链路中的数据处理需求跟大数据体系已有的能力重叠，许多中间环节存在重复建设的现象，浪费人力；

2.大数据处理能力弱：算法同学不一定具备大数据处理能力，依赖单机处理，处理速度有限，限制业务发展；

3.链路割裂、平台间协作困难：算法训练上下游环节重度依赖大数据，业务自行开发的工具与大数据现有体系割裂，相互之间难以进行透明高效的协作，极大影响业务开发效率；

4.关键环节工具缺失：链路中的部分关键环节（例如：指标采集）缺乏自动化手段，依赖手动统计，无法追溯，不够标准化。

我们把现存的架构称为半孤岛架构，不同于传统孤岛式架构，该架构中各业务团队并非从 0 到 1 独立构建自己的链路，而是会依赖部分公共的中台服务，但自有工具无法跨团队共享，中台服务之间无法紧密配合，整条链路仍处于类孤岛式的割裂状态。因此，随着业务发展，半孤岛架构不可避免的成为阻碍业务快速迭代最大的绊脚石。

        02

基于Opal的数智一体化方案

设计目标

当前机器学习流程大致有以上几个阶段：原始日志、特征加工、特征校验、样本构建、模型训练、A/B Test、模型部署、特征访问。平台设计之初就是围绕上述各环节建设服务，目标是能够向业务方提供一个一站式的、打通 Bigdata + AI 环节的大数据机器学习开发平台，帮助业务快速构建出所需的数智应用。具体功能如下：

1.特征管理：提供托管式的特征管理服务，避免用户重复开发，降低用户使用门槛；平台支持离线及在线特征生产、特征质量校验、样本构建、统一特征访问等功能；

2.模型管理：整合大数据工作流调度及资源管理框架，提供一站式的模型管理能力，避免用户穿梭在各个平台；平台提供单机及分布式模型训练、异构资源（CPU/GPU）调度、多训练框架支持（TensorFlow、PyTorch 等）、模型部署、A/B Test、跨集群数据读写等能力；

3.效率工具：借助开源工具（例如：JupyterLab），提供高效的数据科学探索能力；提供一键式开发环境部署、Adhoc 式大数据处理分析、多元模型探索等功能。

架构图

          03

核心功能介绍

特征生产

数据和特征决定了机器学习的上限，Opal 以特征组为核心提供托管式的特征生产能力，打通大数据链路，避免用户重复开发，降低用户使用门槛，该模块整体数据流程如下图所示：

用户通过拖拽各类不同的算子构建 DAG 图，实现从不同格式的数据源中加载原始日志，经过中间计算节点进行数据转换，最终将产出的特征写入目标节点所描述的存储系统中。Opal 目前支持各类常见的特征存储格式。

另外，平台提供语法解析及校验功能，用户在配置期间可实时观察到每个算子输出的字段详情，无需到提交任务阶段才发现错误，可降低用户调试时间。最后，我们提供了告警通知支持生产任务延迟及失败告警、多版本管理机制、重补跑等多个便捷的管理功能，方便用户进行任务运维。

特征校验

为了能够尽早地发现数据中的错误，避免将错误传递到下游消费系统，作为一站式平台，支持特征校验是尤为必要的。经多方调研对比，平台决定基于 Amazon 开源数据校验框架Deequ 实现了对特征的自动化校验。该框架具有如下特点：

1.提供声明式 API，用户可以根据自身数据集构建不同的检查规则；

2.自动完成将各种不同的检查进行聚合，可大幅度提高检查效率；

3.基于 Spark 支持大规模数据集的检查及增量式数据集的检查。

Deequ 基于声明式 API 提供了足够的灵活性，支持各种基础的校验操作，但同时存在如下缺陷：

1.使用门槛较高，用户需要学习其独特的语法编写规则；

2.没有与大数据平台集成，编写完成后用户需要手动将 ETL 任务提交至大数据集群运行，较为不便；

3.任务运行完成后，只会在日志中输出一个文本结果，不方便直观地查看运行结果；

4.只支持基础数值类型特征和字符串类型特征校验，无法覆盖所有类型。

Opal 结合具体业务痛点基于 Deequ 做了如下适配，形成了当前质量校验模块：

1.将质量校验任务绑定特征组，用户无需重复指定数据源；

2.集成爱奇艺大数据体系，支持多集群甚至跨集群任务提交；

3.扩展原生的校验规则，支持复杂特征类型的质量校验，例如原生的零值率检查只支持数值型，我们将其扩展支持数组、字典类型的特征；

4.封装 Deequ 原生的声明式API，提供 Web 配置页面，实现用户Zero Code 提交任务，降低使用门槛；

5.转换 Deequ 原始输出，根据校验规则不同提供不同的可视化方式，例如：柱状图、箱线图、折线图，方便用户查看特征校验结果；

6.对于例行化的任务，提供环比及同比结果比对，方便用户查看特征变化趋势。

样本构建

样本构建其本质也是一种数据的转换方式，与特征组的产出方式类似，可以说是一种特殊的特征组。其关系如图所示，通过将各种类型的特征组关联到用户 ID 及Item ID 上构造出训练样本数据集用于后续模型训练。

但由于其可以与模型特征对应的特殊性，平台将其独立出来，形成了当前的样本管理模块。并通过样本 ID 和可以与线上模型进行关联，这样做有以下两个好处：

1.一方面通过该模块查看模型关联的样本集，进而追溯上游特征组产出任务，方便特征不一致时进行 debug；

2.另一方面，根据特征查询对应样本集，进而查看线上模型引用情况，在特征下线时更有信心。

另外平台提供对训练样本的特征重要性评估（XGBoost、LR 等）、自动化特征校验、异常值告警等功能。

模型训练

与大数据体系集成

模型的输入输出往往依赖 HDFS，由于数据及计算规模庞大，爱奇艺大数据分散在多个 Hadoop 集群中，造成训练任务需要跨集群访问、跨集群 Kerberos 认证鉴权，我们通过对接爱奇艺自研的大数据文件系统 QBFS ( iQIYI Bigdata File System ) 实现了跨集群自动路由、鉴权等功能。

另外，训练任务需要提交至 YARN 集群，需要定时检测上游依赖，Opal 平台通过对接 Gear 定时工作流调度引擎实现了任务的启动、管理、监控报警等功能。

整体链路如下：

从单机到分布式训练

随着时间累计，一方面，训练数据逐渐增加，样本集离线存储大小从 GB 走向 TB，另一方面近年来模型结构逐渐复杂，模型参数量呈指数级上升，这使得在规定时间内，不可能在单机上完成模型训练，甚至普通的机器无法完成模型的加载。从技术上来说，要完成分布式训练，需要从两方面着手：

1.用户的代码需要能够感知分布式环境，不同的节点可以运行不同的任务

2.平台需要具有启动分区式训练任务的能力，为不同的节点分配不同的角色、资源申请、心跳机制、日志采集等

以 TensorFlow 类型训练任务为例，其官方支持 Estimator 框架，提供了高阶 API，底层封装了MonitoredSession，用户只需编写对应的 input_fn 处理输入数据以及通过model_fn 定义自己的模型结构，当 Estimator 启动时，通过TF_CONFIG 等环境变量决定是否单机运行还是分布式运行。由于其 Estimator API 清晰简单又不失灵活性，算法人员在定义模型时基本无需考虑分布式工程的细节，因此我们重点推广了该模式。目前平台中 80% 以上的TensorFlow 使用 Estimator 框架编写。

另一方面是平台需要能够有能力分布式运行任务，需要能够解决资源申请、角色分配、各节点通信、错误容忍等问题，我们支持两种训练模式：

1.基于开源机器学习作业协调框架 TonY (Tensorflow on YARN) 实现分布式训练，TonY是 Linkedin 于2019 年开源的框架可以将机器学习作业运行在 Hadoop 平台上，Opal通过改造 TonY 将其与爱奇艺任务调度引擎及资源管理平台集成实现通用分布式机器学习任务的调度

2.与爱奇艺自研的 Jarvis 深度学习平台（支持GPU 训练、推理等）打通，支持用户通过 Opal 提交训练任务到Jarvis，并通过 Opal 来管理模型训练任务、与特征生产等上下游环节打通

整体框架如下：

平台对用户完全屏蔽上述分布式训练细节，并以 "实验"为核心构建可视化模型开发页面，支持拖拽式构建机器学习工作流、灵活的调度策略（FIFO、LAST_ONLY等）、自动化指标采集、实验复制等功能。

可视化的机器学习工作流构建

如图所示，平台支持拖拽式机器学习实验构建，用户在 Web 上选择需要训练节点、配置好运行参数即可启动实验，相比之前基于命令行的启动方式，工作流的构建流程大幅度得到简化。

模型训练节点配置示例

在节点中配置代码的 Git 地址，选择适合的训练镜像版本，填上需要的资源配置就可以快速运行任务。

历史训练记录及指标对比

平台提供任务的历史运行记录，方便用户跟踪历史任务运行状况，同时可以进行训练指标的横向对比。

模型部署

当前平台本身不提供模型部署能力，而是对接 Jarvis 平台实现模型部署。该方案的整体架构如下：

A/B Test

模型部署后，下一步便是启用部分线上分桶流量测试，算法侧根据线上指标决定是否推全。目前平台不提供 A/B 实验的能力，用户需要借助公司内部专门的 A/B 实验平台进行测试。未来 Opal 计划对接A/B 实验平台，使得用户可以在 Opal 上完成分桶测试，并串联起模型、样本以及特征，完成整个流程的闭环。

在线访问

从功能上来说，该模块需要支持：第一，定时或实时将离线更新或实时计算产出的特征数据写入到线上 KV 存储库中，即特征的在线化；第二，提供接口服务，根据 key 从存储库中读取对应的特征值。

Opal 通过引入特征视图实现特征的在线化，并提供统一客户端 SDK 实现对线上特征的读取，用户无需关注底层特征写入的细节。整体流程如下图所示：

另外，业务通常需要对已有特征进行后置转换，例如对读出的特征值取对数或四则运算后再传给下游系统。为支持上述功能，平台提供了一套灵活高效的特征转换表达式。如下：

效率工具

在算法和数据分析人员的日常工作中，需要经常对数据或模型进行探索，本地环境的搭建及维护可能会对算法同学造成困惑，进而阻碍其日常工作开展。

JupyterLab 是一款基于 Web 的IDE 开发环境，支持交互式分析、代码执行、图表展示等诸多功能，经多方对比，Opal 决定基于JupyterLab 建设云端环境能力，过去一年多团队完成了对原生的 JupyterLab 的多项改造工作：支持工作空间自动保存及恢复、跨集群访问、大数据分析等功能，大幅度降低了业务同学在环境搭建、大数据访问过程中遇到的困难。

支持工作空间保存及恢复

用户填写简单的配置就能启动 JupyterLab，平台会自动备份用户在使用过程中产出的一切数据。

集成 Hadoop Client 访问大数据

平台在镜像中提供 Hadoop Client，方便用户访问大数据，另外支持用户将本机文件上传至 JupyterLab 工作空间、支持各类NoteBook Kernel 等。

预置常用训练框架，支持多元化算法探索

镜像中集成了数据科学家日常工作中所需的常用 Python 工具包，如：TensorFlow、TFX、Pandas、Scikit-learn、NumPy、SciPy等，如下图所示，启动 JupyterLab 后，用户可快速进行算法模型的验证。

支持使用 PySpark 进行 Adhoc 式的大数据分析

此外我们在 Lab 中集成了PySpark 组件，并对其进行改造，用户可以直接在 NoteBook 中提交分布式Spark 任务，进行 Adhoc 式的数据查询及分析。

     04

 业务实践

以下是 Opal 在爱奇艺部分业务场景的实践效果，后续我们会陆续推出系列文章详细介绍这些业务基于 Opal 平台的改造过程。

广告算法团队 - 基于 Opal 改造离线评估链路

原方案

在广告业务中，上游会持续为广告场景产出各类特征，例如：DMP 特征、BI 特征，数量众多，但特征质量良莠不齐，算法同学时间宝贵，需要具备快速筛选评估特征是否有用的能力。原方案存在如下缺点：

1.特征存储混乱：缺乏特征组概念，无法将特征统一组织起来；

2.特征拼接麻烦：需要用户开发自定义 JAR 包，提交到集群运行；

3.无法进行前置评估：每个特征都要经过完整的上线流程才能确定特征效果，导致评估周期长；

4.模型指标管理缺失：指标登记依赖手动登记，以 excel 为主，较为落后。

方案改造

在平台协助下，广告团队已基本完成基于 Opal 完成离线特征评估流程改造，离线特征评估迭代效率提升 3 倍，离线评估周期从 5 天缩短到1.5 天，实现评估需求从 1 个月到 0 积压，促进广告收入提升。

风控团队 - 基于 Opal 完成流批一体式特征平台升级

原方案

原流程中，风控团队根据特征的实时和离线属性拆封成两个完全不同的平台，风控运营同事在使用过程中存在如下痛点：

1.离线特征和实时特征业务配置存在割裂，增加风控运营同学配置特征成本；

2.风控团队需要维护各种缓存资源，升级维护代价大；

3.线上规则引擎访问时需要自己实现各种缓存客户端，开发成本高。

方案改造

新版风控平台基于 Opal 建立流批一体特征服务，整条链路时延大幅降低，生产提速 13 倍，引擎侧获取特征时延从 30ms 降低至 10ms，实时特征计算数据堆积降低 88%。运营人员开发及上线特征的速度变快，风控业务迭代效率得到提升，风险识别率整体增加 5.5%。

推荐中台 - 基于 Opal 特征生产提升特征效率

原方案

原方案中数据开发人员特征生产和特征校验两个流程无法统一，存在如下问题：

1.特征生产过程中存在较多中间子任务，会产出不必要的中间文件，影响整体特征计算效率；

2.特征校验依赖入口机人工编写校验代码，开发难度高，难以沉淀。

方案改造

经过改造，数据开发人员在平台上实现了一站式特征生产及校验。基于 Opal 的推荐中台特征模块上线后，特征生产提速 0.4 - 1 倍，特征验证环节节省 20% - 50% 人力，通过质量校验模块提升了特征质量。

      05

未来规划

未来，Opal 计划从以下几方面增强平台功能，助力业务取得更好的效果：

1.**推动特征实时化：**完善实时特征生产功能，提供实时特征质量校验功能，推动业务将部分离线特征转化为实时特征；

2.**优化在线特征服务性能：**通过引入 cache、优化编码格式等手段，进一步提高特征获取的性能；另外，通过优化特征在缓存数据库间的调度，避免热点特征对其他特征产生负面的性能影响；

3.**实时化的模型训练：**探索 online learning，提高模型更新速度；

4.**隐私计算：**通过引入联邦学习、多方安全计算等技术，实现初步的隐私计算能力。