01
1.特征管理：提供托管式的特征管理服务，避免用户重复开发，降低用户使用门槛；平台支持离线及在线特征生产、特征质量校验、样本构建、统一特征访问等功能；
2.模型管理：整合大数据工作流调度及资源管理框架，提供一站式的模型管理能力，避免用户穿梭在各个平台；平台提供单机及分布式模型训练、异构资源（CPU/GPU）调度、多训练框架支持（TensorFlow、PyTorch 等）、模型部署、A/B Test、跨集群数据读写等能力；
3.效率工具：借助开源工具（例如：JupyterLab），提供高效的数据科学探索能力；提供一键式开发环境部署、Adhoc 式大数据处理分析、多元模型探索等功能。
03
另外，平台提供语法解析及校验功能，用户在配置期间可实时观察到每个算子输出的字段详情，无需到提交任务阶段才发现错误，可降低用户调试时间。最后，我们提供了告警通知支持生产任务延迟及失败告警、多版本管理机制、重补跑等多个便捷的管理功能，方便用户进行任务运维。
为了能够尽早地发现数据中的错误，避免将错误传递到下游消费系统，作为一站式平台，支持特征校验是尤为必要的。经多方调研对比，平台决定基于 Amazon 开源数据校验框架Deequ 实现了对特征的自动化校验。该框架具有如下特点：
1.提供声明式 API，用户可以根据自身数据集构建不同的检查规则；
2.自动完成将各种不同的检查进行聚合，可大幅度提高检查效率；
3.基于 Spark 支持大规模数据集的检查及增量式数据集的检查。
Deequ 基于声明式 API 提供了足够的灵活性，支持各种基础的校验操作，但同时存在如下缺陷：
1.使用门槛较高，用户需要学习其独特的语法编写规则；
2.没有与大数据平台集成，编写完成后用户需要手动将 ETL 任务提交至大数据集群运行，较为不便；
3.任务运行完成后，只会在日志中输出一个文本结果，不方便直观地查看运行结果；
4.只支持基础数值类型特征和字符串类型特征校验，无法覆盖所有类型。
Opal 结合具体业务痛点基于 Deequ 做了如下适配，形成了当前质量校验模块：
1.将质量校验任务绑定特征组，用户无需重复指定数据源；
样本构建其本质也是一种数据的转换方式，与特征组的产出方式类似，可以说是一种特殊的特征组。其关系如图所示，通过将各种类型的特征组关联到用户 ID 及Item ID 上构造出训练样本数据集用于后续模型训练。
但由于其可以与模型特征对应的特殊性，平台将其独立出来，形成了当前的样本管理模块。并通过样本 ID 和可以与线上模型进行关联，这样做有以下两个好处：
1.一方面通过该模块查看模型关联的样本集，进而追溯上游特征组产出任务，方便特征不一致时进行 debug；
2.另一方面，根据特征查询对应样本集，进而查看线上模型引用情况，在特征下线时更有信心。
从单机到分布式训练
随着时间累计，一方面，训练数据逐渐增加，样本集离线存储大小从 GB 走向 TB，另一方面近年来模型结构逐渐复杂，模型参数量呈指数级上升，这使得在规定时间内，不可能在单机上完成模型训练，甚至普通的机器无法完成模型的加载。从技术上来说，要完成分布式训练，需要从两方面着手：
1.用户的代码需要能够感知分布式环境，不同的节点可以运行不同的任务
2.平台需要具有启动分区式训练任务的能力，为不同的节点分配不同的角色、资源申请、心跳机制、日志采集等
以 TensorFlow 类型训练任务为例，其官方支持 Estimator 框架，提供了高阶 API，底层封装了MonitoredSession，用户只需编写对应的 input_fn 处理输入数据以及通过model_fn 定义自己的模型结构，当 Estimator 启动时，通过TF_CONFIG 等环境变量决定是否单机运行还是分布式运行。由于其 Estimator API 清晰简单又不失灵活性，算法人员在定义模型时基本无需考虑分布式工程的细节，因此我们重点推广了该模式。目前平台中 80% 以上的TensorFlow 使用 Estimator 框架编写。
平台对用户完全屏蔽上述分布式训练细节，并以 "实验"为核心构建可视化模型开发页面，支持拖拽式构建机器学习工作流、灵活的调度策略（FIFO、LAST_ONLY等）、自动化指标采集、实验复制等功能。
可视化的机器学习工作流构建
如图所示，平台支持拖拽式机器学习实验构建，用户在 Web 上选择需要训练节点、配置好运行参数即可启动实验，相比之前基于命令行的启动方式，工作流的构建流程大幅度得到简化。
模型训练节点配置示例
在节点中配置代码的 Git 地址，选择适合的训练镜像版本，填上需要的资源配置就可以快速运行任务。
历史训练记录及指标对比
平台提供任务的历史运行记录，方便用户跟踪历史任务运行状况，同时可以进行训练指标的横向对比。
模型部署
当前平台本身不提供模型部署能力，而是对接 Jarvis 平台实现模型部署。该方案的整体架构如下：
A/B Test
模型部署后，下一步便是启用部分线上分桶流量测试，算法侧根据线上指标决定是否推全。目前平台不提供 A/B 实验的能力，用户需要借助公司内部专门的 A/B 实验平台进行测试。未来 Opal 计划对接A/B 实验平台，使得用户可以在 Opal 上完成分桶测试，并串联起模型、样本以及特征，完成整个流程的闭环。
在线访问
从功能上来说，该模块需要支持：第一，定时或实时将离线更新或实时计算产出的特征数据写入到线上 KV 存储库中，即特征的在线化；第二，提供接口服务，根据 key 从存储库中读取对应的特征值。
Opal 通过引入特征视图实现特征的在线化，并提供统一客户端 SDK 实现对线上特征的读取，用户无需关注底层特征写入的细节。整体流程如下图所示：
另外，业务通常需要对已有特征进行后置转换，例如对读出的特征值取对数或四则运算后再传给下游系统。为支持上述功能，平台提供了一套灵活高效的特征转换表达式。如下：
用户填写简单的配置就能启动 JupyterLab，平台会自动备份用户在使用过程中产出的一切数据。
平台在镜像中提供 Hadoop Client，方便用户访问大数据，另外支持用户将本机文件上传至 JupyterLab 工作空间、支持各类NoteBook Kernel 等。
支持使用 PySpark 进行 Adhoc 式的大数据分析
此外我们在 Lab 中集成了PySpark 组件，并对其进行改造，用户可以直接在 NoteBook 中提交分布式Spark 任务，进行 Adhoc 式的数据查询及分析。
04
原方案
在广告业务中，上游会持续为广告场景产出各类特征，例如：DMP 特征、BI 特征，数量众多，但特征质量良莠不齐，算法同学时间宝贵，需要具备快速筛选评估特征是否有用的能力。原方案存在如下缺点：
1.特征存储混乱：缺乏特征组概念，无法将特征统一组织起来；
2.特征拼接麻烦：需要用户开发自定义 JAR 包，提交到集群运行；
3.无法进行前置评估：每个特征都要经过完整的上线流程才能确定特征效果，导致评估周期长；
4.模型指标管理缺失：指标登记依赖手动登记，以 excel 为主，较为落后。
方案改造
在平台协助下，广告团队已基本完成基于 Opal 完成离线特征评估流程改造，离线特征评估迭代效率提升 3 倍，离线评估周期从 5 天缩短到1.5 天，实现评估需求从 1 个月到 0 积压，促进广告收入提升。
原方案
原流程中，风控团队根据特征的实时和离线属性拆封成两个完全不同的平台，风控运营同事在使用过程中存在如下痛点：
1.离线特征和实时特征业务配置存在割裂，增加风控运营同学配置特征成本；
2.风控团队需要维护各种缓存资源，升级维护代价大；
3.线上规则引擎访问时需要自己实现各种缓存客户端，开发成本高。
方案改造
新版风控平台基于 Opal 建立流批一体特征服务，整条链路时延大幅降低，生产提速 13 倍，引擎侧获取特征时延从 30ms 降低至 10ms，实时特征计算数据堆积降低 88%。运营人员开发及上线特征的速度变快，风控业务迭代效率得到提升，风险识别率整体增加 5.5%。
推荐中台 - 基于 Opal 特征生产提升特征效率
原方案
原方案中数据开发人员特征生产和特征校验两个流程无法统一，存在如下问题：
1.特征生产过程中存在较多中间子任务，会产出不必要的中间文件，影响整体特征计算效率；
2.特征校验依赖入口机人工编写校验代码，开发难度高，难以沉淀。
方案改造
05
未来，Opal 计划从以下几方面增强平台功能，助力业务取得更好的效果：
1.推动特征实时化：完善实时特征生产功能，提供实时特征质量校验功能，推动业务将部分离线特征转化为实时特征；
2.优化在线特征服务性能：通过引入 cache、优化编码格式等手段，进一步提高特征获取的性能；另外，通过优化特征在缓存数据库间的调度，避免热点特征对其他特征产生负面的性能影响；
3.实时化的模型训练：探索 online learning，提高模型更新速度；
4.隐私计算：通过引入联邦学习、多方安全计算等技术，实现初步的隐私计算能力。
