正向拆解 mlops

这篇文章是 mlops 系列的开篇，所以作为第一篇文章，在讲 mlops 应该如何构建前，先对其做一下拆解。这样做的目的是不直接给出方案，而是从机器学习最基础的需求开始一步一步推导出 mlops 应该实现的设计。

黑盒系统

如果我们抛开已有的对 mlops 的所有设想，那么机器学习过程就像一个黑盒一样，这是最原始的状态，所有数据科学家、算法工程师各自构建自己的建模环境、建模流程甚至自己发布模型服务。这样的情况就是一个黑盒，我们不知道黑盒里有什么，我们很难复现、无法优化、无法流程化，也无法描述它。

输入输出

为了避免黑盒系统带来的弊端，很自然的我们想到这个系统可以有输入当然也有输出。所以输入输出的是什么呢？可以列举一下：

输入

• 数据集：这是最常见的，比如这个过程是训练模型，那么数据集一定是一种输入，数据集的类型有很多

• 命令参数：参数也是重要的输入，很多时候我们重复的执行一些任务，只是输入的参数不同而已， 比如超参搜索

• 环境变量: 与参数类似，只是配置的方式不同而已

• 文件：还有一些输入是文件但又不是数据集，比如在批量推理任务中，输入可能是一个要参与推理的模型文件

输出

• 数据集：与输入一样， 输出可能也是一个数据集， 比如在数据预处理任务中，输入是处理前的数据集， 而输出就是处理后的数据集，而这个输出在训练任务中又变成了输入数据集

• 模型文件：最常见的训练任务的输出就是模型文件， 而且模型文件的格式根据算法的不同而不同，数量也是不固定的

广义输出

还有一些输出并不是那么明显，但也同样很重要， 这些可以归为广义的输出

• 超参数：比如在一个训练任务中，最终得到的超参数也很重要

• 执行日志：任务的执行并不是想象中那么顺利， 大部分的任务在初次执行的时候会遇到报错，即使是执行过多次的任务在有些场景也可能报错， 如果记录输出日志对于排查问题很有用。

• 文件：有些时候输出是文件， 比如处理一批图片，其中有些图片模型无法处理，可能是一些之前没有遇到的异常情况，那将这些异常图片保存下来观察是有价值的，文件的类型有很多，也有可能是音频等格式

• 特殊对象：有些数据作为输出在格式上是比较特殊的， 比如输出一个 pandas Dataframe，比如输出 numpy 对象，比如 json，这些数据在序列化后可以看做一个文件，不同的是这些特殊格式的文件可以提供一些数据的预览

• 可视化数据：图表的本质也是数据，但这类数据更特殊一些， 一般我们不直接观察原始数据，而是观察这些原始数据绘制的图表， 这些数据的格式也比较多， 比如混淆矩阵， 曲线图等等

通过上面的分析，我们对这个黑盒已经有了更多的认知， 虽然大体还是一个黑盒，但我们已经可以从输入输出、已经一些过程输出数据着手开始设计这些系统了

在这样的系统中，需要做一些设计来帮助更好的构建这个机器学习过程，我们先提出这些问题，在后续的文章中再一一阐述

• 首先需要一个数据集系统： 用于管理、存储、提供下载、version 等功能， 这些数据集可能是有血缘关系的，数据集之间有关联关系， 比如一个是预处理前一个是预处理后。数据集如果做版本管理？数据集应该有哪些元数据？数据集如何存储？数据的格式有很多种， 比如表格数据、图片、音频、视频等。还有一些数据并不是直接在 mlops 平台内存储的， 可能是存储在外部平台，比如 hdfs 上， 这些数据应该用什么形式来维护呢？

• 命令参数：如何识别，传递命令参数？如何设计超参数搜索机制？

• 可视化：输出的数据哪些可以做可视化，这些数据应该如何采集

• 模型：模型文件有哪些类型？如何管理？如何存储？如何做版本管理？

• 日志等过程数据如何更简单的采集？如何自动采集？

等等

描述黑盒

上面我们在黑盒的输入输出层面上进行的拆解， 现在我们要对黑盒本身下手了。即使我们仍然将这个过程看作一个黑盒，在它的周边依然有一些东西可以拆解。

1. 比如这个黑盒应该是一些代码组成的， 那这些代码是否得到妥善的维护呢？因为这涉及到复现问题，所以一般来说需要将这些代码管理起来， 事实上的管理工具基本是 git 系统， 这样做的好处是我们虽然还是将它看做一个黑盒，但至少知道这个黑盒的代码在哪个仓库，哪个分支，甚至是哪个 commit

2. 黑盒如何启动， 黑盒至少有一个启动的入口， 比如一个 python 脚本， 那这个脚本的位置在哪

3. 黑盒的元数据：我们是在机器学习的范畴下讨论这个黑盒，那这个黑盒的类型是有限的， 这是一个用于训练、数据处理、批量推理、测试、超参搜索等等。此外记录黑盒的名称，描述等信息也可以帮助维护

4. 黑盒的执行环境：机器学习的运行环境是复现它的另外一个难题，针对这个问题，我们已经有了一套现成的解决方案就是容器技术，那么黑盒执行所需的镜像我们应当如何维护呢？

5. 黑盒的执行资源：这个黑盒要运行需要多少资源，CPU、memory、要不要用 GPU 等。平台又应该如何调度这些资源？

分拆黑盒

到现在为止我们还是不知道黑盒到底是什么，但并不妨碍我们拆分它，因为机器学习的过程是有章可循的，比如先预处理、然后训练、评估模型效果、保存一个最好的结果。

于是上面的大黑盒可以拆分为一些小黑盒的组合， 比如说这样：

我们暂时将这称为 pipeline， 可以发现一个 pipeline 由多个黑盒串联而成， 这样做的好处是首先让黑盒不再那么黑， 其实我们可以在不同的 pipeline 当中复用一些黑盒了

我们可以在不同的 pipeline 当中复用一些黑盒了，这个事情是有用的， 毕竟很多机器学习过程是相似的需要相同的逻辑， 那么 mlops 平台就可以恰当的提供一些黑盒实现给用户使用，而不需要重复开发了，这其实也体现了 mlops 的另一个特点就是提高效率。这些平台提供的黑盒可以称为组件，那应当提供哪些组件？这些组件怎么定位？怎么使用？

对于 pipeline 的设计，在后续的文章中再做展开

触发黑盒

到现在为止我们对黑盒的探索已经比较满意了，那么我们如何运行它呢？触发方式应该有哪些？

• 手动触发： 很好理解，配置完黑盒后可以手动触发

• 定时触发： 比如每天处理一次数据

• 条件触发： 可以有哪些条件呢？比如某个数据集有了新的版本就出发一次重新训练， 比如某些监控值低于预期就触发一次更新？等等，这样的触发机制有哪些应该如何设计呢？

同时平台有必要维护任务执行的状态，可能的状态有：pending、running、completed、aborted、failed