原文发布于 Nicolas Jomeau – 经作者同意转载
大多数数据科学项目无法通过 PoC 阶段，因此永远无法产生任何商业价值。Gartner 在 2019 年估计，“到 2022 年，只有 20% 的分析洞察能够带来商业成果”。造成这种情况的主要原因无疑是数据科学家通常缺乏关于如何将他们的解决方案部署到生产环境、如何将其与现有系统和工作流程集成以及如何操作和维护它们的清晰愿景。这就是 MLOps 的用武之地，它被认为是解决机器学习解决方案工业化相关所有问题的答案。
通过将 DevOps 原则与常见的数据科学工作相结合，MLOps 旨在提高机器学习生命周期的自动化水平，以改善实验阶段的复现性和透明度，实现 ML 模型在生产环境中的可靠高效部署，并使其可观测。虽然存在许多集成的 ML 平台，例如Dataiku、DataRobot 或Azure MLOps，我在 ELCA 的实习专注于探索各种开源解决方案来解决这个问题。
根据 ThoughtWorks 的研究，一个好的 MLOps 基础设施应具备多种功能：
- 快速实验周期：数据科学家可以快速尝试新的数据处理技术、模型架构或参数，并将结果（模型产物和指标）记录到一处，以便轻松进行实验之间的基准测试。
- 持续集成：自动化管道确保 ML 代码通过单元测试，并且训练的模型性能达到最低阈值，同时遵守产品接口，以避免重大变更。
- 持续部署：只需一次点击（如果不是零次），即可打包、测试并立即将模型部署到生产环境。如果是对先前部署模型的更新，则对用户是透明的，无需停机即可完成更新。
- 监控：一旦部署，模型性能和数据漂移指标会持续监控，以便及早发现异常并自动发出警报，如果模型或基础设施需要更新。
- 可伸缩性：基础设施根据模型的负载进行伸缩，以避免花费过多并浪费昂贵的计算资源，或花费过少导致性能下降的风险。
基础设施
在部署满足上述功能的工具之前，必须选择一个平台来支持它们。我们旨在将整个项目部署在 ELCA 的基础设施上，同时支持资源共享和伸缩，因此 ELCA 的 OpenShift（RedHat 打包的 Kubernetes 分发版）成为这项工作的合适工具。
使用 OpenShift（或其他基于 Kubernetes 的容器化解决方案）本身就允许我们通过控制部署的服务器数量（通过自动伸缩 Pods）来覆盖可伸缩性，并通过使用滚动更新确保部署新模型时不停机来覆盖部分持续部署功能。
为了满足我们保存数据集和训练模型的存储需求，我们使用 MinIO S3 对象存储服务器。MinIO 与 Amazon S3 API 完全兼容，因此可以轻松替换为其他托管解决方案（Google GCP、Amazon S3、Azure 等），或者本身部署在其他云提供商上。
配置好 MLOps 基础设施后，我们可以开始逐个添加我们解决方案的构建块，以处理数据、训练模型、部署和更新模型，并最终监控部署。
工具
特征工程、机器学习和实验跟踪
对于实际的 ML 工作，我们决定使用 ClearML 平台（v1.0），这是一个集编排、数据版本控制、实验跟踪和模型仓库于一体的解决方案。只需在您的 Python 代码中添加 2 行额外的代码，您就可以让 ClearML 存储版本化的数据、跟踪指标（及其关联的图表），并将生成的模型二进制文件（pickle、h5 等）保存到 S3 服务器上，并带有一个唯一的实验名称/ID。然后，只需提及此 ID，任何其他 Python 脚本都可以重用这些数据。
在 ClearML 术语中，一个脚本被称为一个任务，并且可以访问 ClearML 服务器上的所有数据和元数据。这意味着可以通过让任务观察其他任务来添加某种形式的自动化，例如，测试和验证它们的输出（生成的模型是否足够好），或者监控新添加的数据（并触发另一个数据处理任务）。
最后，您可以选择任务执行的位置：本地或远程服务器。这允许细粒度的资源管理，并受益于特定任务的专用硬件（例如用于深度学习的 GPU）。结合监控任务，可以按需部署云提供商的专用虚拟实例来运行特定任务，从而加快工作速度，同时最大限度地减少硬件开销。
持续集成和部署
生成令人满意的模型后，我们必须将其打包成一个可用于部署的应用程序。这一步使用了任何 DevOps 工程师都耳熟能详的两种工具：Jenkins 和 Docker。
Jenkins 是一种自动化工具，旨在促进任务自动化（显然！）。在这个项目中，我们使用它来运行一系列动作：对 MLOps 代码进行单元测试，验证我们要部署的模型是否通过性能检查，使用模型创建一个服务器来运行推理，将服务器打包成 Docker 镜像，在专用环境中运行服务器以执行自动化集成测试，最后触发 OpenShift 的滚动更新。如果其中任何一步失败，整个过程将中止。这确保不会部署有问题的服务器，并最大限度地降低出错的风险。
服务器是一个简单的 FastAPI Web 服务器，它加载模型并暴露 Web API 来运行推理。我们选择 FastAPI 是因为它允许我们完全控制服务器行为并轻松添加新功能。例如，一个设计选择是采用模块化方法来构建服务器。除了仅仅包含一个 ML 模型，我们可以添加模块来执行额外的预处理（Web 输入的格式与训练时使用的格式不同）、异常值检测或特定功能监控。正如没有免费的午餐，高度可定制性是以较低的计算效率为代价的，与 Seldon 或 BentoML 等 MLOps 工具相比（这些工具支持批量推理、使用 gRPC 而非 HTTP、自动 GPU 加速）。
监控
但仅仅通过 Web API 部署模型是不够的！为了确保它按预期工作，我们需要可监控性。监控有两种形式：日志（文本）或指标（数字），描述服务器上发生的事件。由于我们主要关注性能指标（推理时间、资源使用、数据/预测分布），前一种监控类型可以移除。
我们为本项目选择的最知名的指标日志记录工具组合是 Prometheus/Grafana 技术栈。它允许我们管理指标的收集/聚合以及显示。每个部署的 ML 服务器在接收到请求时都会存储指标，Prometheus 从 Web 端点收集这些指标。使用 PromQL 查询语言，可以过滤和聚合指标以获取更详细的信息（请求速率、服务器推理分析等）。Grafana 连接到 Prometheus 数据库之上，根据这些指标创建实时交互式可视化图表。
这两种工具都提供了在满足某些条件时自动报警的功能。我们使用了 Grafana 的报警系统，因为它通过 Web UI 配置方便，并且提供了许多可用的报警通道：运营 ML 项目的人员可以通过 Slack 机器人即时接收任何警报，而其他服务（例如状态页或自动伸缩器）可以依赖 Kafka 消息。
总结
借助 Kubernetes，整个基础设施可以通过少量自动化脚本部署，并在几分钟内准备就绪。
数据科学家的常见工作流程是将数据加载到 ClearML 上，使用 Python 代码或更高级的方式（SQL、Spark 等）处理这些数据，训练模型（带有一些用于自动模型验证的指标）以及 ML 服务器的一些模块。这些模型/模块中的每一个都带有唯一的 ID 存储在 ClearML 服务器上。
找到一个好的模型后，项目经理可以通过启动 Jenkins 作业来决定部署或更新当前的 ML 服务器。该作业首先对代码运行单元测试，下载模型和模块，使用模型验证器完成的标记验证它们的正确性，最后将它们与 FastAPI 打包成 Docker 镜像，推送到 ELCA 的仓库（jFrog Artifactory）。然后将镜像部署到测试环境，对抗一些查询进行测试以验证 API 的正确性，最后使用滚动更新部署到生产环境，以确保零停机时间。
结论
通过使用开源技术，我们能够通过 DevOps 创建和自动化一个管理 ML 模型完整生命周期的系统：从初始训练到服务，包括监控和再训练。我们在这次实习中遇到的最大挑战是 MLOps 领域的不断变化。尽管随着时间推移可能会有所变化，但许多工具尚未成熟，可能需要在几个月后再次测试它们。
