1.4 MLOps需求层次

考虑机器学习系统的一种方法是考虑马斯洛的需求层次，如图1-2所示。金字塔的较低层反映了“生存”需求，人类的真实潜能在基本生存和情感需求得到满足之后才会出现。

同样的概念也适用于机器学习。ML系统是一个软件系统，当DevOps和数据工程最佳实践到位的话，软件系统能有效、可靠地运行。如果组织中DevOps的基本规则不存在或数据工程没有完全自动化，那该如何发挥机器学习的真正潜能？图1-3的机器学习需求层次不是一个明确指南，但是一个好的开始。

阻碍机器学习项目的主要因素之一是必要的DevOps基础。这个基础完成后，接下来是数据自动化，然后是平台自动化，最后是真正的ML自动化或MLOps。MLOps的巅峰是一个有效的机器学习系统。那些操作和构建机器学习应用程序的人是机器学习工程师或数据工程师。让我们从DevOps开始深入了解ML层次的每一步并确保你牢牢掌握如何实施它们。

1.4.1 实施DevOps

DevOps的基础是持续集成。没有自动化测试，DevOps没办法向前推进。对用现代工具创建的Python项目来说，持续集成相对比较容易。第一步是搭建Python项目的脚手架，如图1-4所示。

Python机器学习项目的运行环境大多在Linux操作系统上。因此，后续的Python项目结构直接用来实现机器学习项目。你阅读本节时，可以访问此源代码GitHub（https://oreil.ly/4dei0）上的示例来参考。具体包含如下组件：

Makefile

Makefile是基于Unix的操作系统中通过make系统运行的“配方”（recipe）。因此，Makefile是简化持续集成步骤的理想选择。Makefile是一个项目很好的起点，并且通常演化成需要被自动化的新片段。

如果你的项目使用Python虚拟环境，则在使用Makefile之前你需要对虚拟环境进行源代码配置，因为Makefile只运行命令。Python新手经常将Makefile与虚拟环境混淆。类似地，假设你使用Microsoft Visual Studio之类的代码编辑器。这种情况下，你需要告诉编辑器你的Python虚拟环境，这样它才能准确地提供语法高亮、代码校验和其他可用库。

Make install

此步骤通过make install命令安装软件。

Make lint

此步骤通过make lint命令检查语法错误。

Make test

此步骤通过make test命令运行测试。

requirements.txt

requirements.txt是Python默认安装工具pip中使用的约定。如果不同的包需要安装不同环境的话，一个项目可以包含一个或多个这种文件。

源代码和测试

Python脚手架的最后一部分是添加源代码文件和测试文件，如下所示。这些脚本保存在文件hello.py中：

接下来，使用pytest框架创建测试文件非常简单。这个脚本将在与hello.py相同目录的test_hello.py中，这样from hello import add能够正常工作：

Makefile、requirements.txt、hello.py和test_hello.py这4个文件都需要开始持续集成之旅，除非创建本地Python虚拟环境。为此，首先创建它：

请注意，通常有两种方法可以创建虚拟环境。首先，许多Linux发行版包含命令行工具virtualenv，它的功能与python3 -m venv相同。

接下来，运行source命令激活这个环境：

为什么要创建和使用Python虚拟环境？这个问题对Python新手来说十分普遍，这里有一个直观的回答。因为Python是一种解释型语言，它可以从操作系统的任何地方“抓取”库。Python虚拟环境把第三方包隔离到特定目录。还有很多其他工具也可以解决这个问题。它们有效地解决了同样的问题：Python库和解释器独立于特定项目。

设置好Python脚手架后，你可以执行以下本地持续集成步骤：

1.使用make install为项目安装库。

输出类似于图1-5［此例展示GitHub Codespaces（https://oreil.ly/xmqlm）中的运行］

2.运行make lint对项目进行代码校验：

3.运行make test来测试项目：

如果这个过程在本地生效，就可以直接将相同过程集成到远程SaaS构建服务器。具体选项包括一个云原生构建服务器（如AWS Code Build、GCP CloudBuild、Azure DevOps Pipelines）GitHub Actions，或者一个开源自托管构建服务器（如Jenkins）。

1.4.2 GitHub Actions持续集成环境配置

实现持续集成的最直接方法之一是将Python脚手架项目与GitHub Actions一起使用。为此，你可以在GitHub UI中选择“Actions”来创建一个新对象，或者在你创建的目录中生成一个新文件，如下所示：

GitHub Actions文件可以直接创建，如下就是一个例子。请注意，要根据Python项目解释要求配置确定的Python版本。在这个例子中，我想检查在Azure上运行的特定Python版本。持续集成的步骤很容易完成，因为困难是在前期生成Makefile：

当在GitHub上执行“push”事件时，GitHub Actions的概览如图1-6所示。

此步骤完成了设置持续集成的最后一部分。把机器学习项目自动推送到生产环境的持续部署是下一个逻辑步骤。这个步骤会利用持续交付流程和IaC（基础设施即代码）把代码部署到指定位置，如图1-7所示。

1.4.3 DataOps和数据工程

ML需求层次的下一步是数据流的自动化。例如，想象一个只有一口井的城镇。日常生活很复杂，因为我们根据需求来安排水的流动路线，我们认为理所当然的事情可能无法正常工作，例如按需热水淋浴、按需洗碗或自动灌溉。同样，没有自动数据流的组织也不能可靠地做MLOps。

许多商业工具正在发展以执行DataOps。例如，由Airbnb设计、后来开源的Apache Airflow（https://oreil.ly/p55kD）可以调度和监控其数据处理任务。AWS的工具包括AWS Data Pipeline和AWS Glue。AWS Glue是一种无服务器ETL（提取、加载、转换）工具，它能检测数据源的模式，然后存储数据源的元数据。其他工具像AWS Athena和AWS QuickSight可以查询和可视化数据。

这里要考虑的一些要素有数据规模、信息变更频率、数据清洗程度。许多组织使用集中式数据湖作为所有数据工程活动的集中地。数据湖有助于构建自动化的原因是，它在I/O方面提供了“近乎无限”的规模，同时还具有高耐用性和可用性。

数据湖与基于云的对象存储系统（如Amazon S3）是同义的。数据湖允许数据“原地”处理而无须四处移动。数据湖通过近乎无限的容量和计算特征来实现这一目标。

当我在电影行业工作时，像《阿凡达》（https://oreil.ly/MSh29）这样的电影，数据量巨大，移动数据需要通过一个超级复杂的系统才能完成。现在有了云，这个问题就解决了。

图1-8展示了一个基于云数据湖的工作流。许多任务都在确定的位置执行，而无须移动数据。

专门的职位，例如数据工程师，可以把所有的时间都花在构建处理这些不同用例的系统上：

• 定期收集数据和运行作业。

• 处理流式数据。

• 无服务器和事件驱动的数据。

• 大数据作业。

• ML工程任务的数据和模型版本控制。

就像一个没有自来水的村庄不能使用自动洗碗机，一个没有数据自动化的组织无法使用先进的机器学习方法。因此，数据处理需要自动化和可操作化。此步骤使ML任务能够沿着该链条进行操作和自动化。

1.4.4 平台自动化

一旦有了自动化数据流，下一步就要考虑组织怎样使用高级平台构建机器学习解决方案。如果一个组织已经将数据收集到云平台的数据湖中，例如Amazon S3，那么将机器学习工作流绑定到Amazon SageMaker是很自然的。同样，如果一个组织使用谷歌，那么它可以通过谷歌AI平台或Azure使用Azure Marching Learning Studio。同样，如果一个组织使用Kubernetes而不是公有云，则Kubeflow（https://kubeflow.org）是合适的。

解决这些问题的一个比较好的平台示例如图1-9所示。AWS SageMaker为现实世界的机器学习问题编排了一个复杂的MLOps序列，包括启动虚拟机、读写S3、配置生产端点。在生产环境中执行没有自动化的基础设施步骤是鲁莽的。

ML平台解决了现实世界的重复性、可扩展性和可操作性问题。

1.4.5 MLOps

假设所有需求层次都已完成（DevOps、数据自动化和平台自动化）MLOps是可能的。记得之前说过使用DevOps方法自动化机器学习过程就是MLOps。构建机器学习系统的方法就是机器学习工程。

因此，MLOps是一种行为，就像DevOps是一种行为一样。如果有些人作为DevOps工程师工作，那么软件工程师就能使用DevOps最佳实践更频繁地执行任务。类似地，机器学习工程师就能使用MLOps最佳实践来创建机器学习系统。

DevOps和MLOps是最佳实践的结合吗

还记得本章前面描述的DevOps实践吗？MLOps建立在这些实践之上并将其扩展来直接处理机器学习系统问题。

阐明这些最佳实践的一种方法是考虑它们创建了具有稳健模型打包、验证和部署的可重复模型。此外，也增强了模型的解释性和性能监控能力。图1-10给出更多细节。

反馈循环包括以下内容：

基于可重用ML管道创建和重新训练模型

仅创建一次模型是不够的。数据会变，客户会变，建模人员也会变。该解决方案是版本化的可重用ML管道。

机器学习模型的持续交付

ML模型的持续交付类似于软件的持续交付。若所有步骤都实现了自动化，包括自动化基础设施，使用IaC，则模型在任何时间都可以部署到新的环境中，包括生产环境。

MLOps管道的审计跟踪

对机器学习模型进行审计至关重要。机器学习中有很多问题，包括安全性、偏见和准确性。因此，有用的审计跟踪功能是非常重要的，就像生产环境中软件工程项目的日志功能。此外，审计跟踪是反馈循环和实际问题的一部分，这样你可以不断改善问题的解决方法。

观察模型数据漂移以改进未来的模型

机器学习的独特性之一是模型的数据会产生“漂移”。两年前为客户工作的模型，今天很可能不再适用。通过监控数据漂移，即自上次模型训练后的数据变化增量，我们可以在生产环境出现问题之前避免准确性问题。