作者：George Novack
翻译：Bach（才云）
校对：星空下的文仔（才云）、bot（才云）
K8sMeetup
为什么要应用机器学习流水线
当初，机器学习流水线（Machine Learning Pipeline）被大家给予了极大的关注，它旨在自动化和协调训练机器学习模型所波及的各个步骤，然而，很多人也不分明将机器学习工作流程建模为主动流水线到底有什么益处。
当训练新的 ML 模型时，大多数据科学家和 ML 工程师会开发一些新的 Python 脚本或 interactive notebook，以进行数据提取和预处理，来构建用于训练模型的数据集；而后创立几个其余脚本或 notebook 来尝试不同类型的模型或机器学习框架；最初收集、调试指标，评估每个模型在测试数据集上的运行状况，来确定要部署到生产中的模型。
手动机器学习工作流程
显然，这是对真正机器学习工作流程的适度简化，而且 这种通用办法须要大量的人工参加，并且除了最后开发该办法的工程师之外，其他人都无奈轻易重复使用。
由此，咱们应用机器学习流水线来解决这些问题。与其将数据筹备、模型训练、模型验证和模型部署视为特定模型中的繁多代码库，不如将其视为一系列独立的模块化步骤，让每个步骤都专一于具体任务。
机器学习流水线
将机器学习工作流程建模为机器学习流水线有很多益处：
- 自动化：通过打消手动干涉的需要，咱们能够安顿流水线依照需要从新训练模型，从而确保模型可能适应随工夫变动的训练数据。
- 重复使用：因为流水线的步骤与流水线自身是离开的，所以咱们能够轻松地在多个流水线中重复使用单个步骤。
- 重复性：任何数据科学家或工程师都能够通过手动工作流程从新运行流水线，这样就很分明须要以什么程序运行不同的脚本或 notebook。
- 环境解耦：通过放弃机器学习流水线的步骤解耦，咱们能够在不同类型的环境中运行不同的步骤。例如，某些数据筹备步骤可能须要在大型计算机集群上运行，而模型部署步骤则可能在单个计算机上运行。
K8sMeetup
什么是 Kubeflow
Kubeflow 是一个基于 Kubernetes 的开源平台，旨在简化机器学习零碎的开发和部署。Kubeflow 在官网文档中被称为“Kubernetes 机器学习工具包”，它由几个组件（component）组成，这些组件逾越了机器学习开发生命周期的各个步骤，包含了 notebook developent environment、超参数调试、性能治理、模型服务以及 ML Pipelines。
Kubeflow 地方仪表板
在本文中，咱们只关注 Kubeflow 的 Pipelines 组件。
K8sMeetup
环境
本文抉择在裸机上运行的 Kubernetes 集群，但实际上咱们能够在装置 Kubeflow 的任何 Kubernetes 集群上运行示例代码。
本地惟一须要的依赖项是 Kubeflow Pipelines SDK，咱们能够应用 pip 装置 SDK：pip install kfp。
K8sMeetup
Kubeflow Pipelines
Kubeflow 中的流水线由一个或多个组件（component）组成，它们代表流水线中的各个步骤。每个组件都在其本人的 Docker 容器中运行，这意味着流水线中的每个步骤都具备本人的一组依赖关系，与其余组件无关。
对于开发的每个组件，咱们创立一个独自的 Docker 镜像，该镜像会接管输出、执行操作、进行输入。另外，咱们要有一个独自的 Python 脚本，pipeline.py 脚本会从每个 Docker 镜像创立 Pipelines 组件，而后应用这些组件结构流水线（Pipeline）。咱们总共创立四个组件：
- preprocess-data：该组件将从
sklearn.datasets中加载Boston Housing数据集，而后将其拆分为训练集和测试集。 - train-model：该组件将训练模型，以应用“Boston Housing”数据集来预测 Boston 屋宇的中位数。
- test-model：该组件会在测试数据集上计算并输入模型的均方误差。
- deploy-model：在本文中，咱们不会专一于模型的部署和服务，因而该组件将仅记录一条音讯，指出它正在部署模型。理论状况下，这可能是将任何模型部署到 QA 或生产环境的通用组件。
ML 流水线视图
K8sMeetup
Preprocess Data 组件
第一个 Pipelines 组件用 sklearn.datasets 加载 Boston Housing 数据集。咱们应用 Sci-kit Learn 的 train_test_split 函数将此数据集分为训练集和测试集，而后用 np.save 将数据集保留到磁盘，以便当前的组件重复使用。
到目前为止，咱们只有一个简略的 Python 脚本。当初，咱们须要创立一个执行该脚本的 Docker 镜像，这里编写一个 Dockerfile 来创立镜像：
从 python:3.7-slim 根底镜像开始，咱们应用 pip 装置必须的软件包，将预处理的 Python 脚本从本地计算机复制到容器，而后将 preprocess.py 脚本指定为容器 Entrypoint，这样在容器启动时，脚本就会执行。
K8sMeetup
构建流水线
当初，咱们着手构建流水线，首先要确保能够从 Kubernetes 集群拜访上文构建的 Docker 镜像。本文应用 GitHub Actions 构建镜像并将其推送到 Docker Hub。
当初定义一个组件，每个组件都要定义为一个返回 ContainerOp 类型的对象（object）。此类型来自咱们先前装置的 kfp SDK。这是流水线中第一个组件的组件定义：
请留神，对于 image 参数，咱们传递了上文 Dockerfile 定义的 Docker 镜像的名称，对于 file_outputs 参数，指定了 Python 脚本组件保留到磁盘的四个 .npy 文件的文件门路。通过将这四个文件指定为“File Output”，咱们能够将它们用于流水线中的其余组件。
留神：在组件中对文件门路进行硬编码不是一个很好的做法，就如下面的代码中那样，这要求创立组件定义的人员要理解无关组件实现的特定细节。这会让组件承受文件门路作为命令行参数更加洁净，定义组件的人员也能够齐全管制输入文件的地位。
定义了第一个组件后，咱们创立一个应用 preprocess-data 组件的流水线：
流水线由一个注解 @dsl.pipeline 润饰的 Python 函数定义。在函数内，咱们能够像应用其余任何函数一样应用组件。为了运行流水线，咱们创立一个 kfp.Client 对象，再调用 create_run_from_pipeline_func 函数，并传入定义流水线的函数。
如果执行该脚本，而后导航到 Kubeflow 地方仪表板流水线局部的“Experiment”视图，咱们就能看到流水线的执行状况。在流水线的图形视图中单击该组件，咱们还能够看到来自 preprocess-data 组件的四个文件输入。
Kubeflow 流水线用户界面
因而，咱们能够运行流水线并在 GUI 中进行可视化，然而只有一个步骤的流水线并没什么意思，上面咱们来创立其余的组件。
K8sMeetup
其余组件
对于 train-model 组件，咱们创立一个简略的 Python 脚本，该脚本应用 Sci-kit Learn 来训练回归模型。这相似于预处理器组件的 Python 脚本，其中最大的区别是，这里用 argparse 来承受训练数据的文件门路以作为命令行参数。
这个 Dockerfile 与咱们用于第一个组件的十分类似，从根底镜像开始，装置必要的软件包，将 Python 脚本复制到容器中，而后执行脚本。
其余两个组件 test-model 和 deploy-model 遵循着雷同的模式。实际上，它们与咱们曾经实现的两个组件十分像，这里就不再赘述。如果大家有趣味，能够在以下 GitHub 存储库中找到该流水线的所有代码：https : //github.com/gnovack/kubeflow-pipelines
就像之前的 preprocess-data 组件一样，咱们将从这三个组件中构建 Docker 镜像并将其推送到 Docker Hub：
- train-model: gnovack/boston_pipeline_train
- test-model: gnovack/boston_pipeline_test
- deploy-model: gnovack/boston_pipeline_deploy
K8sMeetup
残缺的流水线
当初是时候创立残缺的机器学习流水线了。首先，咱们为 train-model、test-model 和 deploy-model 组件创立组件定义。
该 train-model 组件的定义与之前的 preprocess-data 组件的定义之间的惟一次要区别是，train-model 承受两个参数，x_train 和 y_train，其将作为命令行参数传递给容器并进行解析，这会在应用 argparse 模块的组件实现中。
这里 test-model 和 deploy-model 组件定义为：
定义了四个 Pipelines 组件后，咱们当初从新拜访 boston_pipeline 函数，并将所有组件一起应用。
这里有几点要留神：
- 在第 6 行，当咱们调用
preprocess_op()函数时，将函数的输入存储在名为_preprocess_op的变量中。要拜访 preprocess-data 组件的输入，咱们应用_preprocess_op.outputs['NAME_OF_OUTPUT']。 - 默认状况下，当咱们从组件拜访
file_outputs时，咱们获取的是文件内容而不是文件门路。在本文中，因为这些不是纯文本文件，因而咱们不能仅将文件内容作为命令行参数传递到 Docker 容器组件中。要拜访文件门路，咱们须要应用dsl.InputArgumentPath()并传入组件输入。
当初，如果咱们运行创立的流水线并导航到 Kubeflow 地方仪表板中的“Pipelines UI”，咱们能够看到流水线图中显示的所有四个组件。
K8sMeetup
论断
在本文中，咱们创立了一个非常简单的机器学习流水线，该流水线能够加载一些数据、训练模型、在保留数据集上对其进行评估、对其进行“deploy”。通过应用 Kubeflow Pipelines，咱们可能将该工作流中的每个步骤封装到 Pipelines 组件中，每个组件都在各自独立的 Docker 容器环境中运行。这种封装促成了机器学习工作流程中各步骤之间的涣散耦合，并为未来流水线中组件的重复使用提供了可能性。
本文简略介绍了 Kubeflow Pipelines 的性能，心愿可能帮忙大家理解组件（component）的基础知识，以及如何应用它们创立和运行流水线。
原文链接：https://towardsdatascience.co…