MLOps核心功能

机器学习系统是一个持续运行的系统，需要持续的循环数据流转才得以运转，其中就包括：特征生产、样本生产、模型训练、模型部署、线上预测、日志下发等关键模块持续运转才能正常运行，同时配套对应的数据质量、效果监控体系进行质量审查。

MLOps是一种将机器学习系统开发(Dev)和运营(Ops)结合在一起机器学习工程文化实践，践行MLOps意味着需要在机器学习系统构建的所有步骤支持自动化和监控化，包括代码、数据、模型持续集成、测试、部署和发布。MLOps****脱胎于DevOps，采用数据工程方式，解决机器学习数据要素研发/服务/运营问题

image.png

MLOps解决问题

MLOps继承了DevOps理念，差别在于数据是在机器学习系统中有着特殊地位，因此MLOps需要采用数据工程实现方式，解决机器学习研发和应用中的三方面问题。

• Feature/Label/Model数据要素从需求到服务全研发流程端到端问题？包括高效管理数据要素从需求、设计、开发、review、发布、监控等过程涉及信息流，实现各数据要素构建、部署、监控信息流一体化；高效选择和配置需要建模工具，构建和应用数据要素研发流水线，避免在多个存储系统、计算平台、调度平台之间来回切换带来的不必要损耗。

• Feature/Label/Model数据要素生命周期管理问题？建模数据要素生产出来首先会面临信息注册问题，比如你构建了哪些特征、特征的类型和存储库表是什么，如果涉及多地部署还需要知道对应的特征地区信息，构建模型时的特征选择， 要素引用问题，需要关注数据要素服务质量问题，包括数据要素用于服务前质量检测，比如样本和特征入模质量是否达标、Model性能检测和评分质量是否满足上线标准、Model和Feature部署前在线服务环境和特征工程逻. 辑和离线是否一致、线上真实使用特征数和离线引用特征数是否相同，如果不一致时如何高效进行排查中间环节问题，以及数据要素在服务中如何持续保证质量健康，尤其流式特征和在线学习模型；数据要素运营管理，例如特征下线、特征组变更，如何及时更新负责人；数据要素服务期终止，如何安全下线，类似特征下线导致模型配置还在生效的问题之前我的团队就遇到过，所以都是比较重要的；这些都是之前得到的经验，我们做特征服务切换时，就因为同一次请求新旧模型返回样本数据不一致，需要我们人工从几千样本特征的最终值进行链路反推，链路复杂难形成体系化的埋点，排查效率低下，至今我们还没有一个工具可以清晰的展示出，一次请求的数据处理的各个环节数据，来保证送给模型的数据是正确的；我们做的策略中控，也是想在ecpm计算链路能够形成策略透明及链路排查效率。

• 生产各数据要素的代码管理问题？研发数据模型的算法工程师开发代码偏好灵活和创新，如何便利有效辅助算法工程师 实现代码开发和代码生产一体化，降低灵活和创新引入的风险，避免用于生产代码和git仓库代码不一致和变更不规范风险；这算是一个比较高阶的功能，当然我们目前是采用离线、实时 的特征生产SDK来保证我们特征生产的规范化和安全保障，后续也在规划将特征生产做成平台功能，进一步把控特征生产质量和安全。

机器学习系统开发流程演进

一般团队在机器学习系统的开发中，都会经历几个阶段 算法工程师手动驱动、工具化开发、机器学习CI/CD流水线，我总结下我们团队的目前进展

1.算法工程师手动驱动

特点：

1. 手动开发、脚本驱动，灵活前期迭代快
2. 模型特征、样本、在线预测等模块数据一般通过共享文档记录

缺点：

1. 模型迭代慢，ML一些特征处理优化、算法新模型无法快速应用，不支持快速试验，算法迭代受到工程团队进度制约
2. 缺少主动监控，数据质量无法保障（这是最关键模块，团队进行数据质量监控之后发现很多特征、样本问题：包括特征制作错误、长期不更新、更新数据不一致、样本回传确实问题严重）
3. 没有形成统一的特征、样本、模型生产流程及工具，数据杂乱、存储效率低存储成本高、样本回传日志量冗余、特征数据冗余等多个问题，这里就不一一列举

这个阶段我们目前已经渡过，逐渐解决老流程的上述问题，具体总结我在之前特征工程1.0问题分析中进行过总结，当然不止文档总结的这些，还包括架构上的一些：例如特征一致性回传时机、特征回传冗余及存储占用太高、回传样本长期错误等问题

2.工具化开发

特点：

1. 上述各个关键流程采用固定SDK工具开发，统一开发工具，提前做好公共的监控等公用模块的开发，这样会大大提高开发、数据迁移、任务稳定、数据质量各个方向。例如我们这次需要进行特征集群的多地部署，我们只需要改动底层的入库SDK添加支持多集群的写入功能就可以应用在所有上百任务中，中间节省的人力和开发成本以及数据质量的保障是不可忽略的；目前形成的公共SDK包扩离线特征生产、实时特征生产、实时样本生产（在线学习），离线样本等模块
2. 配置化开发，但是还是基于离线进行，没有统一配置管理平台，前期借助七彩石等配置中心进行生产，基本可以进行敏捷开发
3. 监控体系逐渐健全，配套有特征、样本、模型效果监控，数据链路得到有效监控和保障

缺点：

1. 数据开发基于离线SDK开发，任务依托于各个平台spark、oceanus、us等，算法数据血缘没有被记录，无法保证特征处理链路的数据是否被正确处理及下发；各个模块计算任务也无法被有效管理及资源控制，溯源任务目前只能根据SDK注册的特征信息，手动寻找US上游任务，多系统之间来回跳转，这里只列举了特征元数据任务查找、包括特征处理环境、模型监控、特征处理环节都需要在各个系统之间来回跳转才能理清数据链路及血缘关系
2. 没有平台化，没有形成数据资产和上面第一条也有类似问题
3. 监控零散，没有形成体系及灵活配置，目前有：特征监控、样本监控、算法监控，分别分散在grafana、蓝鲸等各个平台，查看数据比较麻烦。算法监控还是传统的需求提出和定制开发，但是监控指标很多都可以固化，并且形成算子：例如模型的ctr、cvr、偏差、消耗、roi、分位统计等各个指标；例如样本、特征等都有共性的更新数量、最大值、最小值、分布、null值、方差等各个统计指标，可以根据算法需要进行方便的勾选相应的配置及没有一个平台可以从特征列表直接进入特征分析页面、样本分析、模型分析页面，没有形成体系

这个阶段我们基本渡过，但是还有部分流程在迁移中，例如特征服务还在迁移中

3.机器学习CI/CD流水线

特点：

1. 平台化，算法建模流程抽象流水线，研发、生产、运营一体化
2. 快速试验、持续训练
3. 模块化流水线组件（核心）
4. 组件代码CI/CD能力（高阶）

基本完成模型训练、模型部署流水线的串联，模型数据链路追踪

团队目标和定位

目标：

整合现有能力，采用数据工程实现方式，解决机器学习要素研发、服务、运营问题

定位：

算法建模工具平台

我们应该重点加强哪些模块？

在背景模块我们也大致列了我们目前的进度以及遇到的一些问题，这个模块主要是来看下MLOps涉及到的各个模块，我们主要来看下我们后续需要加强哪些模块，并且给出优先级及规划

image.png

一、流水线

流水线部分涉及两个方面

1. 模型训练：模型的训练可以理解为离线模型准备阶段，这个阶段需要进行样本的配置化选择，选择需要的样本进行建模，目前在算法模型训练时，如果采用目前样本回传线上处理之后的特征，将无法进行后续模型进行特征工程的试验，这是目前流程的弊端，因为算法的特征工程的实验会十分频繁和有价值，目前的流程只能进行模型层面的AB试验，进行另外一份的样本回传，解决这个问题的方案就是线上回传样本时回传处理之前的特征数据处理换到线下去做，这样就可以保证多个试验只需要一份样本，多个配置即可进行，但是这个方案有个弊端就是需要保障线下处理过程需要保证线上线下一致，需要进行工程改造，但是看来随着工程的优化及算法需要，这个方案需要逐渐提上议程；回到目前的方案的好处就是，充分保证线上线下的样本一致性，工程相对简单，回传给模型的数据是直接处理过后的；这里所以暂时没有加样本配置的步骤，样本选择完成后，需要对样本进行数据指标分析，保障样本数据分布和各项指标都ok，这块目前有工具在支持，接着是模型训练部分，模型训练在KP上，在KP上输入我们校验好的样本即可开启训练，训练完成后，需要有模型的离线指标报告，这块目前KP暂时没有页面化的工具，之后是模型部署，目前做法是IDC机器部署，缺乏IDC机器的管理，后续广州地区支持KP预测之后，可以考虑模型部署在KP,fsp系统只需要做好与KP的打通即可
2. 模型配置：模型配置服务于在线预测，我们目前可以在fsp平台进行 特征选择→ 特征组配置 → 模型配置 之后呢，需要离线进行所选特征的数据分析面板，用来评估模型建模的特征是否符合要求，目前fsp暂时是一个配置管理平台，模型部署 →试验指标打通，这里模型部署主要在KP平台，试验指标目前在TAB平台，上线的模型，可以直接进行一站式流程，效果直达，这里需要做好两个平台的打通

二、数据

数据这块整体包括特征源表、特征数据、样本数据、数据校验部分，没有多余可以介绍的

三、代码

代码管控会是MLOps中比较高阶的功能，可以做到特征生产、样本生产、算法生产、质量监控（特征、样本、算法等）几个模块的代码管控，通过CI/CD的能力，来解决生产各数据要素的代码管理问题。这块我觉得不是我们目前的重点，我们目前还有更重要的模块进行建设

四、模型

模型部分相对比较固定，目前借用KP平台能力，涉及到支持更多的模型库，高效的模型训练的研究、模型训练部署一体化管理、模型预测性能提升工程，模型预测这块了解到团队有研究，但是可能成果和可实际投入使用的希望不大，目前还是采用原生tensorServing提升空间很大，对于降低预测时延、提高预测qps有很大帮助，目前的预测性能会给后续模型复杂度、特征丰富度带来阻力，目前所有关于模型训练加速、部署、预测都是采用KP平台相关技术，这块技术快速提升会对业务帮助很大，需要重点关注!!

五、监控

监控模块目前主要包括几个方面，特征、样本监控、算法效果监控、模型监控，其中特征和样本的监控具体指标就不一一列举，告警的难点在于如何定义告警指标及规则，一般需要借助环比、同比进行组合规则才能实现比较准确的告警，需要将告警进行分级：致命告警、一般告警，选择好的指标做到真正有意义的告警，而不是做一堆无用告警占用大家注意力，这才是搭建好一个监控系统关键，如何搭建一个好的监控系统这里推荐一篇文章《无效告警优化实践总结》：https://mp.weixin.qq.com/s?__biz=MzAxNDEwNjk5OQ==&mid=2650437277&idx=1&sn=330e3756eed2430b3df3afd9cf9965c4&chksm=8396be85b4e13793c9f62b772e2953abd3f3f2f9dedf7d9015e9f7a2b5a7c60256d46808903e&mpshare=1&scene=1&srcid=1013uRBrEO9KkJejBTjCzpXW&sharer_sharetime=1634116543582&sharer_shareid=208f3a65b9fed33103a4e3ffc4932068&version=4.0.3.6007&platform=win#rd

模型监控部分指模型训练部分监控，暂时由算法同学自行监控，部分功能借助KP能力，但是尚未有可以

整体总结下目前还有以下几个问题：

指标分散：算法效果监控这部分目前也基本已经搭建完成，有离线、实时多种类型报表，基本能符合目前的监控需求，但是目前监控指标比较分散有：TAB试验指标、Idata离线指标、蓝鲸、grafana 四个平台的指标统计，分散在各个业务模块，没有统一的入口进行效果直达，不同业务模块同学也无法查看其他模块效果指标，需要进行整合

定制化开发：目前各个模块监控基本都由各自模块同学负责搭建，开发需要进行需求定制化开发，但是目前监控的各个模块指标通用性比较强，只需要一个平台可以进行配置化指标生产，这样会大大减少数据开发人员工作以及指标上线效率；举个例子：对于特征、样本算法同学可以自行选择需要监控的指标，进而产生报表，算法也是一样ctr、cvr、消耗、ecpm等 百分位统计等都是可以通过固定的配置实现，从而实现监控自治

六、工具集

工具集模块是我们数据工程的关键模块，它是MLOps的零件，是骨头，没有它无法构建完善的MLOps系统

数据同步工具：

1. 离线特征、实时特征生产：离线和实时特征生产部分，需要将原始的数据源表、实时日志，转化成用户特征同步到feature-store并且注册元数据信息，其中如何高效、统一的进行离线、实时特征生产是一个数据工程的问题，目前团队抽象出离线、实时特征生产框架，可以进行批量特征生产，并埋入监控埋点，数据质量得到质的提升。
2. 离线、实时样本拼接：样本拼接即将特征、label进行拼接形成样本，虽然是一个基础的操作，但是需要将百亿特征数据和数亿标签数据进行实时拼接即离线拼接却不是一件简单的事情，目前样本拼接我们借助Flink进行实时样本拼接，开发了在线学习引擎，解决了多版本数据链路重复问题以及样本拼接性能问题，实现离线配置化样本拼接生产，积累了比较多的Flink调优经验；离线拼接目前暂时借助TDW进行，CTR模块因为点击日志上报快，可以进行小时级离线拼接，痛点不是很大，但是cvr由于转化比较慢，需要进行3天转化周期的数据，所以在拼接时间上会比较长，需要6-7个小时，这块我们有后续优化的打算。

关于统一特征工程、样本工程、特征在线服务都是每个推荐场景必须持续优化的模块，这样才能保障算法高效迭代，https://km.woa.com/group/46147/articles/show/507858 《下一代广告系统技术全景及设计思路》这篇文章也列出了其模块

image.png

测试工具：

1. 样本回溯：样本回溯，在推荐场景中非常常见，例如某个样本线上处理错误，但是对模型的效果影响又比较大，如果因为线上问题导致样本回传错误，导致缺乏大量训练样本，就会导致模型无法进行正常离线训练，进而影响线上效果，如果持续时间比较长，模型需要等待14天样本积累时间，进而导致迭代效率缓慢。这时候样本回溯的能力就比较重要，需要能够根据原始tdw源数据，离线拼接行为日志，重新回填问题特征，进而实现样本修复，这个能力目前当前架构还无法满足，上面也提到目前样本特征是处理完成之后进行回传的，后续离线补录无法复用线上处理逻辑，并且线上线下的上下文会有些许不同，例如也会造成离线补录和在线处理会有些许不同，例如时间特征等。所以如果后续需要支持样本回溯，必须实现样本特征处理后置化、线上线下一致化才能保障样本回溯。
2. 特征处理回放：如1所说，目前样本特征是在进模型之前直接处理好，并且回传的样本也是处理之后的，目前排查一个特征的处理回放需要从回传样本查起，查看特征所在模型特征组及索引位置，才能查看其处理函数，对应的是哪个原始特征，然后根据tdw数据校验与redis数据是否一致，然后再离线使用线上处理函数进行回放进行对比线上是否处理或者回传错误，我们希望有个工具可以快速根据提供hive源数据，排查出 redis数据是否一致、处理过程之后及回传数据的正确性，提高算法数据排查效率
3. 特征查询：在模型上线阶段，我们需要进行特征一致性测试，即hive源表数据是否和redis数据一致，以及缺乏一个工具可以提供设备ID、创意ID等关键字快速查出redis的特征值，来判断特征数据是否正确等场景，这个工具在2里面也会用到，对我们链路排查非常重要
4. 线上线下一致性：根据历史请求回传数据重新回填模型，对比历史打分，判断线上模型打分与当时模型打分是否一致，来判断是否出现模型部署有误。目前没有这块的工具，可以根据算法需求来定制开发

质量&试验:

1. 特征校验、样本校验：特征校验和样本校验刚才已经在监控中有提及，其中的问题也有指出，这块后续我们会持续优化
2. 试验工具（TAB）：试验平台TAB，目前负责AB试验的分发，但是一直有一个核心的问题，分层试验功能优先需要支持，目前算法的试验迭代缺乏整体的调控人，多个模块迭代效果重叠，试验效果不置信，需要团队重点解决

MetaFeatureStore项目介绍

项目走读

自建平台功能示例

特征管理功能：

image.png

特征注册

image.png

特征查询

image.png

处理回放

image.png

模型配置管理

image.png

统一样本配置

image.png

流水线

image.png

image.png