亚马逊-Sagemaker-最佳实践-全-

亚马逊 Sagemaker 最佳实践（全）

原文：annas-archive.org/md5/9d568cbd02fd32e9134442b6a37bb9e8

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

Amazon SageMaker 是一个完全托管的 AWS 服务，它提供了构建、训练、部署和监控机器学习模型的能力。本书从对映射到机器学习过程各个阶段的 Amazon SageMaker 功能的高层次概述开始，以帮助建立正确的基础。你将学习有效的策略来应对数据科学挑战，例如大规模处理数据、数据准备、连接到大数据管道、识别数据偏差、运行 A/B 测试以及使用 Amazon SageMaker 进行模型可解释性。

随着你不断进步，你将了解如何应对大规模训练的挑战，包括如何在节省成本的同时使用大数据集，监控训练资源以识别瓶颈，加快长时间的训练任务，以及跟踪为共同目标训练的多个模型。继续前进，你将发现如何将 Amazon SageMaker 与其他 AWS 服务集成，以构建可靠、成本优化和自动化的机器学习应用。此外，你还将构建与 MLOps 原则集成的 ML 管道，并应用最佳实践来构建安全且性能卓越的解决方案。

到本书结束时，你将能够自信地应用 Amazon SageMaker 的广泛功能，以应对机器学习工作流程的全谱系。

本书面向的对象

本书面向的是负责使用 Amazon SageMaker 构建机器学习应用的高级数据科学家。需要具备 Amazon SageMaker、机器学习、深度学习以及使用 Jupyter Notebooks 和 Python 的经验。对与数据、安全和监控相关的 AWS 服务的了解将帮助你充分利用本书。

本书涵盖的内容

第一章，Amazon SageMaker 概述，提供了对映射到机器学习过程各个阶段的高层次概述的 Amazon SageMaker 功能。这为使用 SageMaker 功能处理数据科学挑战的最佳实践讨论奠定了基础。

第二章，数据科学环境，提供了技术要求的简要概述，并讨论了使用 Amazon SageMaker 设置必要的数据科学环境。这为本书其余部分构建和自动化机器学习解决方案奠定了基础。

第三章，使用 Amazon SageMaker Ground Truth 进行数据标注，从对大规模标注数据所涉及挑战的回顾开始——成本、时间、独特的标注需求、不准确性和偏见。讨论了使用 Amazon SageMaker Ground Truth 解决已识别挑战的最佳实践。

第四章, 使用 Amazon SageMaker Data Wrangler 和 Processing 进行大规模数据准备，首先回顾了大规模数据准备中涉及到的挑战——计算/内存资源限制、长处理时间，以及特征工程努力重复、偏差检测和了解特征重要性的挑战。随后讨论了 Amazon SageMaker 解决这些挑战的能力以及应用最佳实践。

第五章, 使用 Amazon SageMaker Feature Store 的集中特征仓库，提供了使用 Amazon SageMaker Feature Store 构建的集中特征仓库的最佳实践。讨论了摄取特征和提供特征访问以满足访问时间要求的技术。

第六章, 大规模训练和调优，提供了使用 Amazon SageMaker 在大数据集上训练和调优机器学习模型的最佳实践。讨论了诸如数据并行和模型并行分布式训练、自动模型调优以及将多个训练作业分组以识别最佳性能作业等技术。

第七章, 使用 Amazon SageMaker Debugger 分析训练作业，讨论了调试、监控和配置训练作业以检测长时间运行的非收敛作业和消除资源瓶颈的最佳实践。Amazon SageMaker Debugger 提供的监控和配置能力有助于提高训练时间并降低训练成本。

第八章, 使用模型注册表进行大规模模型管理，介绍了 SageMaker Model Registry 作为训练模型的集中目录。模型可以从注册表中部署，注册表中维护的元数据有助于了解单个模型的部署历史。模型注册表是解决模型部署自动化挑战（CI/CD）的重要组件。

第九章, 使用 Amazon SageMaker 端点生产变体更新生产模型，探讨了使用 Amazon SageMaker 端点生产变体以最小化对模型消费者的影响来更新生产模型所面临的挑战。将使用相同的生产变体来展示高级策略，如金丝雀部署、A/B 测试、蓝绿部署，这些策略在平衡成本与停机时间以及回滚的简便性方面取得了平衡。

第十章, 优化模型托管和推理成本，介绍了在 Amazon SageMaker 上优化托管和推理成本的最佳实践。讨论了多种部署策略，以满足不同推理流量需求下的计算需求和响应时间要求。

第十一章，使用 Amazon SageMaker Model Monitor 和 Clarify 监控生产模型，介绍了监控生产模型质量并接收关于模型质量退化的主动警报的最佳实践。你将学习如何使用 Amazon SageMaker Model Monitor 和 SageMaker Clarify 监控数据偏差、模型偏差、偏差漂移和特征归因漂移。

第十二章，机器学习自动化工作流程，将数据处理、训练、部署和模型管理集成到可以编排和集成到端到端解决方案的自动化工作流程中。

第十三章，使用 Amazon SageMaker 构建架构良好的机器学习解决方案，将 AWS 架构良好的框架提供的最佳实践应用于在 Amazon SageMaker 上构建机器学习解决方案。

第十四章，跨账户管理 SageMaker 功能，讨论了在涉及多个 AWS 账户的跨账户设置中使用 Amazon SageMaker 功能的最佳实践，这允许你更好地治理和管理机器学习开发生命周期中的机器学习活动。

为了充分利用这本书

你应该有一个 AWS 账户，并熟悉 AWS 和 Amazon SageMaker。你还应该熟悉基本的机器学习概念。代码示例是用 Python 编写的，通常在 Jupyter 笔记本中执行。你不需要在计算机上安装 Python 或其他软件。

为了设置你的数据科学环境，你还应该熟悉基础设施即代码和配置即代码的概念。如果你也熟悉 AWS CloudFormation，那将很有帮助，但这不是必需的。

如果你使用的是这本书的数字版，我们建议你亲自输入代码或从书的 GitHub 仓库（下一节中有一个链接）获取代码。这样做将帮助你避免与代码复制粘贴相关的任何潜在错误。

下载示例代码文件

你可以从 GitHub 上下载这本书的示例代码文件github.com/PacktPublishing/Amazon-SageMaker-Best-Practices。如果代码有更新，它将在 GitHub 仓库中更新。

我们还有其他来自我们丰富的书籍和视频目录的代码包，可在github.com/PacktPublishing/找到。查看它们吧！

下载彩色图像

我们还提供了一个包含本书中使用的截图和图表彩色图像的 PDF 文件。你可以从这里下载：

static.packt-cdn.com/downloads/9781801070522_ColorImages.pdf

使用的约定

在本书中使用了多种文本约定。

文本中的代码：表示文本中的代码词汇、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“要使用 Amazon SageMaker Debugger，您必须使用三个额外的配置参数增强Estimator：DebuggerHookConfig、Rules和ProfilerConfig。”

代码块应如下设置：

#Feature group name
weather_feature_group_name_offline = 'weather-feature-group-offline' + strftime('%d-%H-%M-%S', gmtime())

当我们希望您注意代码块中的特定部分时，相关的行或项目将以粗体显示：

@smp.step
def train_step(model, data, target):
       output = model(data)
       long_target = target.long()
       loss = F.nll_loss(output, long_target, reduction="mean")
       model.backward(loss)
       return output, loss
    return output, loss 

任何命令行输入或输出都应如下所示：

$ mkdir css
$ cd css

粗体：表示新术语、重要词汇或屏幕上看到的词汇。例如，菜单或对话框中的词汇以粗体显示。以下是一个示例：“请注意，当您在训练集群中使用多个实例时，所有实例应位于相同的可用区。”

小贴士或重要注意事项

看起来像这样。

联系我们

我们始终欢迎读者的反馈。

customercare@packtpub.com并在邮件主题中提及书名。

勘误表：尽管我们已经尽一切努力确保内容的准确性，但错误仍然可能发生。如果您在这本书中发现了错误，我们将非常感激您向我们报告。请访问www.packtpub.com/support/errata并填写表格。

copyright@packt.com并附上材料的链接。

如果您有兴趣成为作者：如果您在某个领域有专业知识，并且您有兴趣撰写或为书籍做出贡献，请访问authors.packtpub.com。

分享您的想法

一旦您阅读了Amazon SageMaker 最佳实践，我们很乐意听听您的想法！请访问packt.link/r/1-801-07052-0此书并分享您的反馈。

您的评论对我们和科技社区都很重要，并将帮助我们确保我们提供高质量的内容。

第一部分：大规模数据处理

本节通过概述亚马逊 SageMaker 的功能、回顾技术要求和在 AWS 上设置数据科学环境的见解，为本书的其余部分奠定基础。本节接着讨论了在标注和准备大量数据时遇到的挑战。您将学习如何应用适当的亚马逊 SageMaker 功能和相关服务从原始数据中提取特征，并持久化特征以供重用。此外，您还将学习如何将特征持久化到集中式仓库中，以便在多个机器学习项目中共享。

本节包括以下章节：

• 第一章, 亚马逊 SageMaker 概述

• 第二章, 数据科学环境

• 第三章, 使用亚马逊 SageMaker Ground Truth 进行数据标注

• 第四章, 使用亚马逊 SageMaker Data Wrangler 和 Processing 进行大规模数据准备

• 第五章, 使用亚马逊 SageMaker 特征存储的集中式特征仓库

第一章：Amazon SageMaker 概述

本章将提供 Amazon SageMaker 功能的高级概述，这些功能映射到机器学习（ML）过程的各个阶段。这将为基础讨论使用 SageMaker 功能的最佳实践，以处理各种数据科学挑战。

在本章中，我们将涵盖以下主要主题：

• 准备、构建、训练和调整、部署和管理机器学习模型

• 数据准备功能讨论

• 模型构建功能的特色游览

• 训练和调整功能的特色游览

• 模型管理和部署功能的特色游览

技术要求

所有包含编码练习的笔记本都将可在以下 GitHub 链接找到：

github.com/PacktPublishing/Amazon-SageMaker-Best-Practices

准备、构建、训练和调整、部署和管理机器学习模型

首先，让我们回顾一下机器学习生命周期。在本节结束时，您应该了解 SageMaker 的功能如何映射到机器学习生命周期的关键阶段。以下图表显示了机器学习生命周期的样子：

图 1.1 – 机器学习生命周期

如您所见，从高层次来看，机器学习生命周期有三个阶段：

• 在数据准备阶段，您收集和探索数据，标记真实数据集，并准备您的特征。特征工程反过来有几个步骤，包括数据归一化、编码和计算嵌入，具体取决于您选择的机器学习算法。

• 在模型训练阶段，您构建模型并调整它，直到达到与您的业务目标相符的合理验证分数。

• 在操作阶段，您测试您的模型在真实世界数据上的表现，部署它，并监控其表现。我们将在第十一章中更详细地介绍模型监控，使用 Amazon SageMaker 模型监控和 Clarify 监控生产模型。

此图故意简化了；在现实中，每个阶段可能有多个较小的步骤，整个生命周期是迭代的。您永远不会真正完成机器学习；随着您收集有关模型在生产中表现的数据，您可能会尝试通过收集更多数据、更改特征或调整模型来改进它。

那么，SageMaker 功能如何映射到机器学习生命周期？在我们回答这个问题之前，让我们看看 SageMaker 控制台（图 1.2）：

图 1.2 – SageMaker 控制台中的导航面板

控制台的外观经常变化，前面的截图显示了撰写时的当前外观。

这些功能组与机器学习生命周期相一致，如下所示：

![图 1.3 – 将 SageMaker 功能映射到机器学习生命周期]

图 1.3 – 将 SageMaker 功能映射到机器学习生命周期

SageMaker Studio 在这里没有显示，因为它是一个集成的工作台，为许多 SageMaker 功能提供用户界面。市场提供可以在整个生命周期中使用的数据和算法。

现在我们已经查看过控制台，让我们更深入地了解 SageMaker 在每个生命周期阶段的个别功能。

数据准备功能讨论

在本节中，我们将深入了解 SageMaker 的数据准备和特征工程功能。在本节结束时，你应该了解何时使用 SageMaker Ground Truth、Data Wrangler、Processing、Feature Store 和 Clarify。

SageMaker Ground Truth

获取用于分类、回归和其他任务的标记数据通常是机器学习项目的最大障碍，因为许多公司拥有大量数据，但尚未根据业务属性（如 异常 和 高终身价值）进行明确标记。SageMaker Ground Truth 通过定义标记工作流程并将标记任务分配给人工劳动力，帮助你系统地标记数据。

随着时间的推移，Ground Truth 可以学会如何自动标记数据，同时仍然将低置信度结果发送给人类进行审查。对于像 3D 点云这样的高级数据集，它们代表像形状坐标这样的数据点，Ground Truth 提供辅助标记功能，例如，一旦你标记了序列的开始和结束帧，就可以将边界框添加到中间帧。以下图表显示了应用于数据集的标签示例：

![图 1.4 – SageMaker Ground Truth 显示应用于情感评论的标签]

图 1.4 – SageMaker Ground Truth 显示应用于情感评论的标签

数据来源于 UCI 机器学习仓库 (archive.ics.uci.edu/ml/datasets/Sentiment+Labelled+Sentences)。为了抵消个别工人的偏见或错误，可以将数据对象发送给多个工人。在这个例子中，我们只有一个工人，所以没有使用置信度分数。

注意，你还可以在其他机器学习生命周期阶段使用 Ground Truth；例如，你可能用它来检查生产模型生成的标签。

SageMaker Data Wrangler

Data Wrangler 帮助你了解你的数据并执行特征工程。Data Wrangler 与存储在 S3 中的数据（可选通过 Athena 访问）和 Redshift 一起工作，并执行典型的可视化转换，如 相关性图 和 分类编码。你可以将一系列转换组合成数据流，并将该流导出到 MLOps 管道中。以下截图显示了数据集的 Data Wrangler 信息示例：

图 1.5 – Data Wrangler 显示有关数据集的摘要表信息

如果您想在 ML 生命周期的操作阶段分析用于生产推理的 ML 模型的数据，您也可以使用 Data Wrangler。

SageMaker Processing

SageMaker Processing 作业帮助您在数据集上运行数据处理和特征工程任务。通过提供包含您代码的自定义 Docker 镜像，或使用预构建的 Spark 或 sklearn 容器，您可以归一化和转换数据以准备您的特征。以下图显示了 SageMaker Processing 作业的逻辑流程：

图 1.6 – Spark 处理作业的概念概述。Spark 作业特别适合处理大型数据集

您还可以在模型训练阶段使用处理作业来评估 ML 模型的表现，以及在模型操作阶段检查数据和模型质量。

SageMaker 特征存储

SageMaker 特征存储 帮助您组织和共享您准备好的特征。使用特征存储通过让您重用特征而不是复制复杂的特征工程代码和已完成的计算来提高质量并节省时间。特征存储支持批量和流存储和检索。以下截图显示了特征组信息的示例：

图 1.7 – 特征存储显示一组相关特征的特性组

特征存储在模型操作阶段也有帮助，因为您可以快速查找复杂的特征向量，以帮助获得实时预测。

SageMaker Clarify

SageMaker Clarify 帮助您理解模型行为并从您的模型中计算偏差指标。它检查数据集中的不平衡，基于某些属性的模型给出不同的结果，以及由于数据漂移出现的不平衡。它还可以使用领先的解释性算法，如 SHAP，帮助您解释单个预测，以了解哪些特征驱动模型行为。以下图显示了数据集的类别不平衡分数示例，其中礼品卡类别的样本比其他类别多得多：

图 1.8 – Clarify 显示数据集中的类别不平衡分数。类别不平衡可能导致 ML 模型产生偏差结果

Clarify 可以在整个 ML 生命周期中使用，但考虑在生命周期的早期使用它来检测不平衡数据（具有许多一个类别的示例但另一个类别的示例很少的数据集）。

现在我们已经介绍了 SageMaker 在数据准备方面的几个功能，让我们继续介绍模型构建功能。

模型构建功能的特性之旅

在本节中，我们将深入了解 SageMaker 的模型构建功能。在本节结束时，您应该了解何时使用 SageMaker Studio 或 SageMaker 笔记本实例，以及如何在 SageMaker 的内置算法、框架和库与自带（BYO）方法之间进行选择。

SageMaker Studio

SageMaker Studio是一个集成开发环境（IDE），用于机器学习。它将 Jupyter 笔记本、实验管理和其他工具集成到一个统一的用户界面中。您可以使用 Git 或共享文件系统轻松地与其他团队成员共享笔记本和笔记本快照。以下截图显示了 SageMaker Studio 内置可视化示例之一：

![图 1.9 – SageMaker Studio 显示实验图

图 1.9 – SageMaker Studio 显示实验图

SageMaker Studio 可用于机器学习生命周期的所有阶段。

SageMaker 笔记本实例

如果您更喜欢传统的 Jupyter 或 JupyterLab 体验，并且不需要 Studio 提供的额外集成和协作工具，您可以使用常规的 SageMaker 笔记本实例。您选择笔记本实例的计算能力（即您是否需要 GPU 以及您需要多少存储），SageMaker 将配置环境，安装 Jupyter Notebook、JupyterLab 以及几个常见的 ML 框架和库。

笔记本实例还支持 Docker，以便您可以在本地使用 ML 代码构建和测试容器。最好的是，笔记本实例捆绑了超过 100 个示例笔记本。以下图显示了笔记本中 JupyterLab 界面的一个示例：

![图 1.10 – SageMaker 笔记本中的 JupyterLab 界面，显示示例笔记本列表

图 1.10 – SageMaker 笔记本中的 JupyterLab 界面，显示示例笔记本列表

与 SageMaker Studio 类似，您可以在笔记本实例中执行 ML 生命周期的几乎所有部分。

SageMaker 算法

SageMaker 为许多常见的机器学习（ML）用例提供了开源和专有算法。这些算法是良好的起点，因为它们针对性能进行了调整，通常支持分布式训练。以下表格列出了 SageMaker 为不同类型的 ML 问题提供的算法：

![图 1.11 – 适用于各种 ML 场景的 SageMaker 算法

图 1.11 – 适用于各种 ML 场景的 SageMaker 算法

带入自己的算法和脚本

如果你更喜欢编写自己的训练和推理代码，你可以使用支持的 ML、图或 RL 框架，或者将你的代码打包到 Docker 镜像中。如果你已经有一个模型代码库，或者需要为某个预建算法效果不佳的使用案例构建模型，BYO 方法效果很好。喜欢使用 R 的数据科学家喜欢使用这种方法。SageMaker 支持以下框架：

• 支持的机器学习框架：XGBoost, sklearn

• 支持的深度学习框架：TensorFlow, PyTorch, MXNet, Chainer

• 支持的强化学习框架：Ray RLLib, Coach

• 支持的图框架：Deep Graph Library

现在我们已经介绍了 SageMaker 在模型构建方面的几个功能，让我们继续介绍训练和调优功能。

训练和调优功能特色之旅

在本节中，我们将深入了解 SageMaker 的模型训练功能。在本节结束时，你应该了解 SageMaker 训练作业、自动驾驶和超参数优化（HPO）、SageMaker 调试器和 SageMaker 实验的基本知识。

SageMaker 训练作业

当你启动一个模型训练作业时，SageMaker 会为你管理一系列步骤。它会启动一个或多个训练实例，将训练数据从 S3 或其他支持的存储系统传输到实例，从 Docker 镜像仓库获取你的训练代码，并开始作业。它监控作业进度并从作业中收集模型工件和指标。以下截图显示了在训练作业中跟踪的超参数示例：

![图 1.12 – SageMaker 训练作业捕获的数据，例如输入超参数值]

![图 1.12 – SageMaker 训练作业捕获的数据，例如输入超参数值]

对于较大的训练数据集，SageMaker 管理分布式训练。它将从存储中分发数据子集到不同的训练实例，并在训练作业期间管理节点间的通信。具体细节取决于你使用的 ML 框架，但请注意，大多数支持的框架以及 SageMaker 内置的几个算法支持分布式训练。

自动驾驶

如果你正在处理表格数据并解决回归或分类问题，你可能发现你正在执行很多重复性工作。你可能已经选择了 XGBoost 作为高性能算法，总是对低基数分类特征进行 one-hot 编码，对数值特征进行归一化，等等。自动驾驶为你执行了许多这些常规步骤。在以下图中，你可以看到自动驾驶作业的逻辑步骤：

![图 1.13 – 自动驾驶流程]

![图 1.13 – 自动驾驶流程]

自动化流程可以节省你的时间，因为它会自动执行许多常规任务。它将运行正常的特征准备任务，尝试三种支持算法（线性学习器、XGBoost 和多层感知器），并运行超参数调整。即使你需要进一步优化输出，自动化的起点也是一个很好的地方，因为它会生成包含整个过程中使用的代码的笔记本。

HPO

一些机器学习算法接受数十个超参数作为输入。手动调整这些超参数会耗费大量时间。超参数优化（HPO）通过允许你定义你想要实验的超参数、工作范围以及你想要优化的指标来简化这个过程。以下截图显示了 HPO 作业的示例输出：

图 1.14 – 显示目标指标的超参数调整作业

SageMaker Debugger

在你的张量中，NaN 非常难以追踪，尤其是在分布式训练作业中。调试器可以有效地帮助你设置断点来查看问题所在。以下图显示了 SageMaker Debugger 捕获的训练和验证损失的示例：

图 1.15 – SageMaker Debugger 捕获的张量可视化

SageMaker Experiments

机器学习是一个迭代的过程。当你调整模型时，你可能需要尝试多个超参数、特征甚至算法的变体。系统地跟踪这项工作很重要，这样你就可以在以后重现你的结果。这就是 SageMaker Experiments 发挥作用的地方。它帮助你跟踪、组织和比较不同的试验。以下截图显示了 SageMaker Experiments 信息的示例：

图 1.16 – SageMaker Experiments 中的试验结果

现在我们已经介绍了 SageMaker 的几个训练和调整功能，让我们继续到模型管理和部署功能。

模型管理和部署功能特性浏览

在本节中，我们将深入了解 SageMaker 的模型托管和监控功能。在本节结束时，你应该了解 SageMaker 模型端点的基础知识以及使用 SageMaker Model Monitor。你还将了解如何使用 SageMaker Edge Manager 在边缘设备上部署模型。

模型监控器

在某些组织中，机器学习团队和运维团队之间的差距会导致真正的问题。运维团队可能不了解如何监控生产中的机器学习系统，而机器学习团队并不总是拥有深厚的运维专业知识。

模型监控试图解决这个问题：它将测量模型端点并收集用于推理的机器模型的输入和输出数据。然后它可以分析这些数据以查找数据漂移和其他质量问题，以及模型精度或质量问题。以下图表显示了一个用于推理端点的模型监控数据的示例：

![图 1.17 – 模型监控检查推理输入的数据质量

![图片 B17249_01_017.jpg]

图 1.17 – 模型监控检查推理输入的数据质量

模型端点

在某些情况下，您可能需要一次性获取大量推理，在这种情况下，SageMaker 提供批量推理功能。但如果您需要获取更接近实时性的推理，您可以将模型托管在 SageMaker 管理的端点上。SageMaker 处理端点的部署和扩展。同样重要的是，SageMaker 允许您在单个端点上托管多个模型。这对于 A/B 测试（即，您可以引导一部分流量到一个较新的模型）以及托管针对不同流量段调优的多个模型都很有用。

您还可以托管一个由多个容器连接在一起推理管道，如果您需要在执行推理之前预处理输入，这将非常方便。以下截图显示了一个具有两个模型的服务不同百分比流量的模型端点：

![图 1.18 – 单个推理端点后配置的多个模型

![图片 B17249_01_018.jpg]

图 1.18 – 单个推理端点后配置的多个模型

边缘管理器

在某些情况下，您需要在设备上而不是从云中获取模型推理。您可能需要一个更低的响应时间，这不允许对云进行 API 调用，或者您可能存在间歇性的网络连接问题。在视频用例中，并不总是可行地将数据流式传输到云中进行推理。在这种情况下，边缘管理器和相关的工具，如SageMaker Neo，可以帮助您编译针对设备优化的模型，部署它们，管理它们，并将操作指标返回到云。以下截图显示了一个由边缘管理器管理的虚拟设备示例：

![图 1.19 – 注册到边缘管理器设备编队的设备

![图片 B17249_01_019.jpg]

图 1.19 – 注册到边缘管理器设备编队的设备

在我们总结之前，让我们回顾一下为以下主要机器学习阶段提供的 SageMaker 能力：

• 对于数据准备：

![图 1.20 – SageMaker 的数据准备能力

![图片 B17249_01_20.jpg]

图 1.20 – SageMaker 的数据准备能力

• 对于操作：

![图 1.21 – SageMaker 的操作能力

![图片 B17249_01_021.jpg]

图 1.21 – SageMaker 的操作能力

• 对于模型训练：

![图 1.22 – SageMaker 的模型训练能力

![图片 B17249_01_22.jpg]

图 1.22 – SageMaker 的模型训练能力

通过这一点，我们来到了本章的结尾。

摘要

在本章中，您了解了如何将 SageMaker 的功能映射到机器学习生命周期的不同阶段。您快速浏览了 SageMaker 的重要功能。在下一章中，您将学习技术要求和将在整个过程中使用的用例。您还将了解如何设置用于扩展模型构建活动的托管数据科学环境。

第二章：数据科学环境

在本章中，我们将概述如何创建可扩展和可重复的托管数据科学环境，以用于模型构建活动。在本章中，您将简要了解机器 学习（ML）用例，包括本书各章节中将使用的数据集。

本章将涵盖以下主题：

• 机器学习用例和数据集

• 创建数据科学环境

技术要求

您需要 AWS 账户来运行本章中包含的示例。本书中包含的完整代码示例可在 GitHub 上找到：github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter02。您需要安装 Git 客户端才能访问它们（git-scm.com/）。章节中包含的部分代码用于强调特定的技术概念；然而，请参阅 GitHub 存储库以获取完成本章相关动手活动所需的完整代码。

机器学习用例和数据集

在本书中，我们将通过示例来展示适用于整个机器学习生命周期的最佳实践。为此，我们将专注于单个机器学习用例，并使用与机器学习用例相关的公开数据集。

本书我们将探讨的主要用例是预测空气质量读数。给定一个位置（气象站）和日期，我们将尝试预测特定类型空气质量测量值（例如，pm25 或 o3）。我们将将其视为回归问题，并探索 XGBoost 和基于神经网络的模型方法。

为此，我们将使用来自 OpenAQ（registry.opendata.aws/openaq/）的数据集，该数据集包含来自公共数据源的空气质量数据。我们将使用的数据集是realtime数据集（openaq-fetches.s3.amazonaws.com/index.html）和realtime-parquet-gzipped数据集（openaq-fetches.s3.amazonaws.com/index.html），其中包含多个站点的每日报告。

每日报告以 JSON 格式提供。每条记录包含以下内容：

• 时间戳（UTC 和本地时间）

• 参数 ID（pm25）

• 位置（站点 ID）

• 值（数值）

• 值的单位

• 城市

• 归因（站点网站链接）

• 平均周期（例如，1 小时）

• 坐标（纬/经）

• 国家代码

• 源名称（站点名称的简称）

• 源类型

• 移动（是/否）

现在让我们看看如何创建数据科学环境。

创建数据科学环境

在上一节中，我们介绍了通常可以单独使用或结合使用以实现端到端功能的 Amazon SageMaker 高级功能。在本节中，我们将专注于创建一致且可重复的受控数据科学环境，这些环境可以利用第一部分讨论的功能。

要使用 Amazon SageMaker 构建、训练和部署模型，ML 构建者需要访问跨越 ML 开发生命周期的选定的 AWS 资源。由于许多不同的人可能负责构建 ML 模型，因此术语 ML 构建者指的是任何负责模型构建的个人。这可能包括数据科学家、ML 工程师或数据分析师。

数据科学开发环境为 ML 构建者提供他们构建和训练模型所需的 AWS 资源。数据科学环境可能只是一个具有访问 Amazon SageMaker 以及与 Amazon SageMaker 常用的 AWS 服务（如 Amazon S3、AWS Glue 或 Amazon EMR）的 AWS 账户。虽然这对小型团队来说可能可行，但它不适合大型团队，也无法随着新项目的创建或新团队成员的加入提供可重复性。

Amazon SageMaker 提供了构建、训练和调整模型的核心选项，包括以下内容：

• API/SDK：可以使用 SageMaker API 启动训练和调整作业，该 API 可以通过高级 SageMaker Python SDK、低级 AWS SDKs，如 Python 的 boto3，或 AWS CLI 访问。

• Amazon SageMaker Studio：Amazon SageMaker Studio 作为集成工作台的一部分内置了笔记本，该工作台包括与其他 Amazon SageMaker 功能和功能可视化的原生集成。

• Amazon SageMaker 笔记本实例：SageMaker 笔记本实例提供了一个带有附加存储的计算实例，用于托管 Jupyter Notebook 应用程序。这些笔记本预先安装了软件包、库和内核。

本节将仅关注 Amazon SageMaker Studio 和 Amazon SageMaker 笔记本实例用于设置数据科学环境。类似的方法也可以用于从 SageMaker API 或 SDK 中使用，这些 API 或 SDK 来自 SageMaker 外部的数据科学环境。我们首先将强调两种常见的使用 基础设施即代码（IaC）/配置即代码（CaC）的方法，以及构建数据科学环境的一般目录。我们将在后面的章节中更详细地介绍每个选项。

为了创建可重复的数据科学沙盒环境机制，建议使用 IaC/CaC 来定义您要为沙盒环境实施的预期配置和控制。让我们看看这两个过程指的是什么：

• IaC 指的是使用代码而不是依赖手动设置来提供和管理基础设施的过程，这不仅速度慢，而且容易出错，并且在环境之间容易产生不一致性。

• Cac 指的是通过代码管理资源配置的过程。因为这一切都是通过代码定义的，所以它可以像源代码一样进行管理，并在不同环境中保持一致性。

通过提供数据科学环境的服务，例如专门为在 AWS 上集中创建和管理 IT 服务目录而构建的 AWS 服务目录，可以将 IaC/CaC 的使用进一步扩展。这些服务旨在通过集中创建和管理目录来提高操作效率。

图 2.1展示了设置受控数据科学环境最常见的方法。本节将详细讨论这些选项。至少，建议采用自动化方法，这包括以下图中选项 2 和 3：

图 2.1 – 创建数据科学沙盒环境的方法

对于 ML 构建者来说，手动配置和提供 AWS 服务的访问权限在扩展多个 ML 构建者和管理超出小型团队的治理时会产生挑战。

随着 AWS CloudFormation 或提供 IaC/CaC 功能的等效服务的引入，数据科学环境可以重复创建，并提供以下附加功能：

• 环境治理：AWS CloudFormation 允许您根据哪些资源被配置以及如何配置来定义您的数据科学环境的目标状态。这允许您强制执行配置，例如成本分配标签、加密存储或控制对预批准资源（如笔记本实例计算的具体实例类型）的访问。

• 一致性：随着 ML 构建者团队的扩大，有必要通过减少手动努力和增加一致性来提高操作效率。IaC/CaC 允许自动配置数据科学环境，并通过代码和自动化提供一致性。

• 改进的管理能力：AWS CloudFormation 不仅允许您自动构建数据科学环境，还允许您快速取消部署不再使用的环境。这种能力减少了环境蔓延，并确保您不会为不再使用的资源付费。

使用 IaC/CaC 来配置和管理数据科学环境通常足以确保 ML 构建者的一致性。然而，通过 IT 服务集中目录提供这些数据科学环境，可以增加额外的操作效率，例如减少手动审批、减少孤岛团队之间的交接，以及通过确保使用仅包含批准配置的环境来跨团队提供集中治理。

AWS 服务目录允许管理员通过 AWS CloudFormation 模板集中定义和管理一组经过批准的产品或配置。为管理用于创建数据科学环境的产品的投资组合添加 AWS 服务目录，可以提供比独立的 IaC/CaC 更多的功能，包括以下内容：

• 自助功能：仅使用 IaC/CaC 来配置和部署 AWS 资源，在请求得到批准、跟踪并最终由 AWS 管理员配置环境的过程中，往往会造成延迟。AWS 服务目录允许机器学习构建者或经批准的指定项目资源自动请求并配置一个根据您定义的标准预先配置的数据科学环境。

• 应用约束和访问控制：使用 AWS 服务目录，可以集中定义并一致地在团队间应用约束和访问控制。

• 服务管理：虽然 AWS 服务目录使用 AWS CloudFormation，但它还包含管理这些模板或产品生命周期（跨版本）的功能。

AWS 服务目录允许机器学习构建者或经批准的资源请求并实例化一个数据科学环境，使用 AWS 服务目录投资组合中包含的经批准产品。AWS 服务目录投资组合可以存在于单独的 AWS 账户中，并在 AWS 账户间共享，以建立公司或业务单元的标准，用于管理产品的配置和部署。投资组合中的产品包含预配置的模板，使用 IaC/CaC，这些模板应用于为机器学习构建者配置或实例化数据科学环境：

图 2.2 – AWS 服务目录 – 投资组合解剖结构

在本章的其余部分，我们将讨论通过 IaC/CaC 一致性地创建数据科学环境的考虑因素，以及允许您通过受管理的 IT 服务目录为多个团队提供这些环境的先进功能。这些内容将涵盖 Amazon SageMaker 笔记本实例以及 Amazon SageMaker Studio。首先，我们将介绍如何使用 IaC/CaC 创建可重复的数据科学环境。

通过 IaC/CaC 实现可重复性

使用 AWS CloudFormation 部署和配置 AWS 资源以及 SageMaker 模型构建活动所需的访问权限，允许团队创建一个可重复的模式，该模式可以在团队间共享，并用于一致性地创建数据科学环境。

CloudFormation 模板允许您以编程方式描述在模板作为堆栈启动时应配置的所需 AWS 资源、配置和依赖关系。构建用于数据科学环境的 AWS CloudFormation 模板时，关键考虑因素包括应配置哪些资源、如何配置它们以及 ML 构建者需要哪些权限来进行模型构建活动。

需要哪些资源？

AWS CloudFormation 允许您通过模板定义 AWS 服务，使用支持的资源和资源类型自动配置。以 Amazon SageMaker 为例，它是一个受支持的资源，SageMaker 笔记本实例是一个受支持的资源类型。CloudFormation 资源类型以一致的形式表示，如图 图 2.3 所示，无论您是构建 JSON 还是 YAML 格式的 CloudFormation 模板：

![图 2.3 – Amazon SageMaker 笔记本实例的 AWS CloudFormation 资源类型

图 2.3 – Amazon SageMaker 笔记本实例的 AWS CloudFormation 资源类型

这意味着团队可以通过 CloudFormation 模板自动配置和配置笔记本实例。然而，仅一个笔记本实例通常不足以满足数据科学环境的需求。对于基本环境，通常需要一个笔记本实例、一个 S3 存储桶以及一个 AWS IAM SageMaker 执行角色，以便在笔记本环境中执行 API 调用。

除了基本环境外，可能还需要在数据科学环境中配置其他资源。需要配置的其他资源可以分为几个关键类别：

• AWS::EMR::Cluster 资源类型。

• AWS::CodeCommit::Repository 资源类型。

  b. AWS::ECR::Repository 资源类型。

• 身份资源：此类别包括需要创建以使用 AWS 资源的所有其他策略或服务角色。例如，为了利用 AWS Step Functions 或数据科学 Python SDK 创建 ML 工作流程，需要创建一个服务级别的 IAM 执行角色。此角色的创建可以在您的 CloudFormation 模板中指定。该角色还应包括允许访问 AWS 服务以及将在您的 ML 工作流程中使用的操作的权限，例如 AWS Glue 用于数据准备和 Amazon SageMaker 用于训练作业。

应如何配置资源？

通过 CloudFormation 模板配置的资源包括一组属性，这些属性定义了资源应该如何配置。通过代码定义这些属性可以使您始终如一地配置符合预定义规范的资源。属性包括重要的配置选项，例如使用附加 VPC 的环境启动或实施加密等控制措施。CloudFormation 还允许在模板中定义 参数，并在启动 CloudFormation 堆栈时传递。

需要哪些权限？

在您确定了需要为您的数据科学环境配置的 AWS 资源和资源类型之后，您还需要确定能够访问笔记本环境和用于模型构建的底层 API 所必需的权限。

下文各节中讨论的亚马逊 SageMaker 笔记本实例与亚马逊 SageMaker Studio 之间存在一些差异；然而，在两种情况下，基本环境都需要一个 IAM SageMaker 执行角色。根据 CloudFormation 模板的意图，您需要考虑 SageMaker 执行角色将需要访问的附加允许的 AWS API 调用和操作。例如，如果您的数据科学团队使用 AWS Glue 进行数据准备活动，IAM SageMaker 执行角色需要允许访问相应的 AWS Glue API 操作。

在构建用于创建和持续执行数据科学环境中的控制的 AWS CloudFormation 模板之前，应考虑以下一些规划任务：

1. 首先，您应该确定应该一起配置的资源模式。

2. 其次，您应该确定那些资源应该如何配置。

3. 最后，您需要确定配置的资源需要具备的最小权限，以便它们能够无缝集成，以及 ML 构建者在那些配置环境中操作所需的权限。

通常，会构建几个模式，支持不同环境模式，这些模式可能适用于不同的用例或多个团队。以下各节包括针对亚马逊 SageMaker 笔记本实例和亚马逊 SageMaker Studio 的详细示例场景。对于任何一种场景，各节可以独立阅读，并且包含一些重复信息，以便它们可以独立存在。

亚马逊 SageMaker 笔记本实例

利用亚马逊 SageMaker 笔记本实例构建数据科学环境通常包括以下配置：

• （笔记本实例，必需）

• 一个 S3 存储桶（可选）

• （IAM 执行角色，如果使用现有角色则为可选）

• 任何其他由 ML 构建者团队标识为需要的资源

上文中提到的 Amazon S3 存储桶被视为可选，因为许多组织已经拥有用于数据科学模型构建活动的现有 S3 存储桶。在这些情况下，数据科学环境可能包括访问现有 S3 存储桶的权限。图 2.2 展示了一个基本的数据科学环境模板，该模板配置了一个 SageMaker 笔记本实例、一个 Amazon S3 存储桶，并创建了一个附加到笔记本实例的 SageMaker 执行角色。该模板可用于实例化多个环境：

图 2.4 – 基于笔记本实例的数据科学环境

以下来自 CloudFormation 模板的代码片段展示了可以用来快速部署数据科学环境的模式，这些控制项已由安全和行政团队预先批准并通过代码实现。在模板的第一个部分，我们确定了每次启动新模板时都可以配置的参数。参数允许您传递用于资源部署和配置的数据：

AWSTemplateFormatVersion: '2010-09-09'
Metadata:
License: Apache-2.0
Description: 'Example data science environment creating a new SageMaker Notebook Instance using an existing VPC.  This template also includes the creation of an Amazon S3 Bucket and IAM Role.  A lifecycle policy is also included to pull the dataset that will be used in future book chapters.'
Parameters: #These are configuration parameters that are passed in as input on stack creation
  NotebookInstanceName:
            AllowedPattern: '[A-Za-z0-9-]{1,63}'
            ConstraintDescription: Maximum of 63 alphanumeric characters. Can include hyphens but not spaces.
            Description: SageMaker Notebook instance name
            MaxLength: '63'
            MinLength: '1'
            Type: String
            Default: 'myNotebook'
NotebookInstanceType:
  VPCSubnetIds:
  VPCSecurityGroupIds:
  KMSKeyId:
  NotebookVolumeSize:

在模板的下一部分，我们确定了需要为您的数据科学环境配置和部署的资源。每个资源的属性确定了配置和控制项。这些控制项可能包括如下配置：确保附加到笔记本实例的存储卷已加密，并且笔记本实例已配置了附带的 VPC：

Resources:
  SageMakerRole:
           Type: AWS::IAM::Role
           Properties:
            AssumeRolePolicyDocument:
            Version: 2012-10-17
             Statement:
            - Effect: Allow
             Principal:
             Service:
                       - "sagemaker.amazonaws.com"
            Action:
            - "sts:AssumeRole"
           ManagedPolicyArns:
          - "arn:aws:iam::aws:policy/AmazonSageMakerFullAccess"
          - ...
  SageMakerLifecycleConfig:   
        ... 
  SageMakerNotebookInstance:
        ... 
 S3Bucket:
...

在此处模板片段中，我们要求输入一个预配置的 VPC 作为参数；然而，根据您的需求，您也可以在 CloudFormation 模板中包含创建新的 VPC。我们还包括笔记本实例类型和存储大小作为参数，这些参数可以在每次启动新模板时进行配置。对于不同的机器学习用例可能需要更改的配置是转换为可配置参数的良好候选，这些参数可以在启动堆栈时定义。

一旦模板上传到 Amazon S3 并验证，它就可以为每个所需的新数据科学环境重复启动。启动堆栈可以通过 AWS 控制台、AWS CLI 或 AWS SDK 完成。这通常是通过使用跨账户权限的行政账户完成的，以确保在定义和部署环境与使用部署环境的用户之间保持控制。

在 CloudFormation 堆栈完成后，机器学习构建者可以通过 AWS 控制台通过预配置的 Amazon SageMaker 笔记本实例访问他们的环境。要访问笔记本实例，ML 构建者的登录凭证必须具有发送CreatePresignedNotebookInstanceUrl API 请求的 IAM 权限。

Amazon SageMaker Studio

构建利用 Amazon SageMaker Studio 的数据科学环境包括以下部署：

• 在现有 Studio 域内的新用户（必需）

• 一个 S3 存储桶（可选）

• IAM 执行角色（如果使用现有角色则为可选）

• 任何其他由机器学习构建团队标识为所需的资源或配置

上文提到 Amazon S3 存储桶是可选的，因为许多组织已经拥有用于数据科学模型构建活动的现有 S3 存储桶。在这些情况下，数据科学环境可能包括访问现有 S3 存储桶的权限。图 2.5显示了基本的数据科学环境模板，该模板在 SageMaker Studio 中预置了新用户，Amazon S3 存储桶，并创建了一个附加到 Studio 域用户的 SageMaker 执行角色。该模板可用于实例化多个用户环境：

![Figure 2.5 – 基于 Amazon SageMaker Studio 的数据科学环境]

![img/B17249_02_05.jpg]

Figure 2.5 – 基于 Amazon SageMaker Studio 的数据科学环境

下面的 CloudFormation 模板显示了一个模式，可用于快速使用 Amazon SageMaker Studio 预置集成的数据科学工作台环境，为 ML 构建者提供对 Studio 笔记本以及 SageMaker Studio 内部其他集成功能的访问。同样，第一个部分包含参数，允许您定义如何预置和配置环境：

AWSTemplateFormatVersion: '2010-09-09'
Metadata:
  License: Apache-2.0
Description: 'Example data science environment creating a new SageMaker Studio User in an existing Studio Domain using an existing VPC.  This template also includes the creation of an Amazon S3 Bucket and IAM Role.'
Parameters:
  StudioDomainID:
            AllowedPattern: '[A-Za-z0-9-]{1,63}'
           Description: ID of the Studio Domain where user should be created (ex. d-xxxnxxnxxnxn)
           Default: d-xxxnxxnxxnxn
           Type: String
  Team:
             AllowedValues:
            - weatherproduct
            - weatherresearch  
            Description: Team name for user working in associated environment
            Default: weatherproduct
            Type: String
  UserProfileName:
           Description: User profile name
           AllowedPattern: '^a-zA-Z0-9{0,62}'
           Type: String
            Default: 'UserName'
  VPCSecurityGroupIds:
 ... 

在模板的下一部分，我们确定了需要为您的数据科学环境配置和预置的资源。同样，每个资源的属性确定了预置的配置和控制，如下所示：

Resources:
  StudioUser:
            Type: AWS::SageMaker::UserProfile
            Properties:
           DomainId: !Ref StudioDomainID
            Tags:
            - Key: "Environment"
             Value: "Development"
            - Key: "Team"
            Value: !Ref Team
            UserProfileName: !Ref UserProfileName
           UserSettings:
            ExecutionRole: !GetAtt SageMakerRole.Arn
           SecurityGroups: !Ref VPCSecurityGroupIds

  SageMakerRole:
          ... 
  S3Bucket:
      ... 

在 CloudFormation 模板中，我们正在向现有的 Studio 域添加新用户。一个AWS:SageMaker:Domain资源类型。创建 Studio 域是每个 AWS 账户和 AWS 区域的唯一活动，因此这被认为是创建 Studio 域内用户的前提条件。此外，一些受监管的工作负载强制执行每个 ML 构建者的账户级隔离，因此在这些情况下，您的 CloudFormation 模板可能包括 Studio 域的设置。然而，最常见的情况是每个 Studio 域有多个用户。

一旦构建并验证了模板，在将模板上传到 Amazon S3 并通过 AWS 控制台、AWS CLI 或 AWS SDK 启动堆栈后，它就准备好部署了。同样，这通常是通过使用跨账户权限从管理账户完成的，以确保在定义和预置环境的角色与使用预置环境的用户之间保持控制。

在 CloudFormation 堆栈完成后，ML 构建者可以通过 Studio IDE 使用 AWS IAM 登录凭据或通过 AWS SSO 凭据和生成的 Studio URL 访问 Studio 环境并创建笔记本。

提供和创建数据科学环境作为 IT 服务

创建一个包含数据科学环境的受管目录，是利用 IaC/CaC 的可重复性概念的一种方式，通过添加跨团队的中央受批准 IT 服务目录。这对于依赖中央 IT 或基础设施团队来提供 AWS 资源的大型公司或企业特别有用。使用 AWS 服务目录创建中央目录可以带来确保符合公司标准的额外好处，加速机器学习构建者快速访问数据科学环境的能力，管理目录中提供的产品版本，以及与第三方 IT 服务 管理（ITSM）软件集成以进行变更控制。

对于使用 Amazon SageMaker 进行模型构建，AWS 服务目录允许团队将上一节中讨论的 AWS CloudFormation 模板作为版本化的产品在中央产品组合中提供。这些产品的批准配置可以集中管理和治理。AWS 服务目录允许团队控制有权启动产品的用户，这意味着管理员还可以为机器学习构建者提供自助服务功能，以确保他们能够快速访问受管的数据科学环境：

图 2.6 – 使用 AWS 服务目录集中管理的数据科学环境

当产品被添加到组合中时，你可以选择性地添加产品约束。产品约束允许你添加关于机器学习构建者如何使用产品的控制。允许几种约束类型，包括启动、通知、模板、堆栈集和标签更新约束。这些约束类型可以应用于任何产品；然而，对于数据科学环境，启动和模板约束有独特的考虑因素。

启动约束允许你指定 AWS 服务目录为组合中的产品提供 AWS 资源时假设的 IAM 角色。这遵循了通过提供构建者对已配置资源的访问权限，但不允许构建者访问 AWS 服务目录之外的资源来授予最小权限的推荐做法。

对于数据科学环境，可以使用预先定义的 IAM 角色添加启动约束到组合中的产品，该角色用于提供资源。这意味着你不需要直接授予构建者创建新的 IAM 角色或与 AWS CloudFormation 一起工作的权限。

模板约束是一个 JSON 格式的文本文件，它定义了描述何时可以使用模板以及可以为 AWS CloudFormation 模板中定义的参数指定哪些值的规则。每个规则有两个属性：规则条件（可选）和断言（必需）。

规则条件确定规则何时生效，断言描述用户可以为特定参数指定的值。对于数据科学环境，可以通过断言使用模板约束来定义允许的配置，例如通过断言定义实例类型。您还可以向该断言添加规则条件，以限制特定环境中允许的实例。

通过创建包含为数据科学环境提供服务的管理产品的集中式投资组合，AWS 服务目录在使用 AWS CloudFormation 时提供了额外的优势。第一步是创建投资组合，可以通过 AWS CLI、AWS SDK 或 AWS 控制台完成，如下所示。

在 AWS 服务目录中创建投资组合

要创建投资组合，请执行以下步骤：

1. 从 AWS 服务目录服务中选择创建投资组合：

   图 2.7 – AWS 服务目录 – 创建新的投资组合

2. 在数据科学环境下输入以下内容以定义您的投资组合

3. 为 ML 构建者提供数据科学环境配置的批准产品服务目录投资组合

4. 所有者: 您的姓名

5. 点击创建按钮以创建投资组合。然后您将看到成功消息，表示投资组合可供添加产品。

随着产品添加到投资组合并配置，AWS 服务目录为管理员提供了查看所有配置的产品并执行管理任务（如识别用户资源分配）的可见性。ML 构建者也可以集中查看他们请求的所有配置的产品：

图 2.8 – 所有已配置产品的列表

SageMaker 笔记本实例和 SageMaker Studio 产品的独特方面主要在 CloudFormation 模板中处理。创建产品的总体步骤在这两种数据科学环境中是一致的。以下各节包括详细示例场景，扩展了为 Amazon SageMaker 笔记本实例和 Amazon SageMaker Studio 先前创建的 CloudFormation 模板。

Amazon SageMaker 笔记本实例

可以使用 AWS CLI、AWS SDK 或 AWS 控制台将新产品添加到 AWS 服务目录投资组合中。当新产品添加到投资组合中时，定义该环境的 CloudFormation 模板必须上传到 S3 存储桶并提供作为输入。在此示例中，将使用先前的 CloudFormation 模板，并添加其他在输入时所需的几个参数，如下所示：

1. 从创建的投资组合内部，选择上传新产品：

   图 2.9 – AWS 服务目录 – 将新产品上传到投资组合

2. 在https://…下。

重要提示

在已启动的堆栈上使用的模板的默认位置是 https://s3.<region>.amazonaws.com/cf-templates-<hash>-region/notebook-instance-environment.yaml，或者您可以直接将本章提供的 CloudFormation 模板上传到您选择的 S3 存储桶。

• release-1.0。

• 初始产品发布。

1. 支持详情部分包括有关支持联系人和支持信息的内容。对于每个指定的字段输入以下内容，未指定的字段留空：

2. 电子邮件联系：您的电子邮件地址 Your.email@mail.com。

3. 在按照前面步骤填写信息后，滚动到页面底部，选择 Review（审查），然后 Create Product（创建产品）。

4. 产品现在将在 数据科学环境组合的产品列表中可见。

在将产品添加到组合后，可以给产品添加约束。约束是可选的，但提供了额外的推荐实践执行，例如最小权限，以及执行最佳实践（如成本优化）的额外控制。为了执行最小权限，可以通过首先创建一个启动 IAM 角色，该角色将在 AWS 服务目录产品文档中提供的产品配置时假定，从而将启动约束添加到产品中：docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints-launch.html。

在此 IAM 策略中，您需要将产品配置的所有服务添加到操作列表中。因此，在这种情况下，以下 IAM 策略可能对您的需求过于宽泛，在这种情况下，您可以将角色限制为特定操作、条件和资源，以适应您的用例：

{

{
            "Version": "2012-10-17",
            "Statement": [
            {
            "Effect": "Allow",
             "Action": [
                         "s3:*"
            ],
           "Resource": "*",
            "Condition": {
                      "StringEquals": {
                     "s3:ExistingObjectTag/servicecatalog:provisioning": "true"
                     }
          }
          },
          {
          "Effect": "Allow",
           "Action": [
                        "...",
             ],
          "Resource": "*"
           }
           ]
}

在创建启动角色和指定权限的策略后，需要将该角色作为启动约束应用于产品，如下面的截图所示。应用启动约束的详细说明包含在现有的 AWS 产品文档中，docs.aws.amazon.com/servicecatalog/latest/adminguide/constraints-launch.html，在 应用启动约束 -> 将角色分配给产品 下。在将 IAM 角色应用于产品启动约束后，您将看到产品列表中列出的约束，如下面的截图所示：

图 2.10 – AWS 约束

启动约束告知服务目录，当最终用户启动产品时，假定 ServiceCatalog-DataScienceProducts 角色。此角色包含我们创建的、用于配置该产品的 CloudFormation 模板中所有资源的权限策略。

最后，我们将添加一个模板约束来限制最终用户可用的实例类型大小选项。这允许对可配置的实例类型实施成本控制。您可以选择实施多个约束，例如存储大小。模板约束的添加方式请参阅 AWS 产品文档：docs.aws.amazon.com/servicecatalog/latest/adminguide/catalogs_constraints_template-constraints.html。具体的模板约束 JSON 在以下代码块中列出，其中我们确定只有指定的实例类型被批准并可供使用：

{
  "Rules": {
            "Rule1": {
            "Assertions": [
            {
            "Assert": {
             "Fn::Contains": [
             [
                        "ml.t2.large",
                       "ml.t2.xlarge",
                         "ml.t3.large",
                         "ml.t3.xlarge"
           ],
            {
                      "Ref": "NotebookInstanceType"
             }
           ]
          },
          "AssertDescription": "Instance type should have approved types"
             }
            ]
           }
  }
}

在创建上述模板约束之后，您现在将在控制台中看到针对此产品的两个约束：

图 2.11 – AWS 服务目录 – 应用约束

产品随后将在数据科学环境组合中可用，并可以由机器学习构建者进行自助配置。

Amazon SageMaker Studio

在本节中，将使用创建 SageMaker Studio 中的数据科学环境的 CloudFormation 模板来在数据科学环境组合中创建一个新产品。再次强调，您可以使用 AWS CLI、AWS SDK 或 AWS 控制台将新产品添加到 AWS 服务目录组合中。当新产品添加到组合中时，定义该环境的 CloudFormation 模板必须上传到 S3 存储桶并提供作为输入。添加产品的步骤需要在服务目录中具有管理权限，并在管理视图中执行：

1. 在数据科学环境组合中，点击上传新产品。

2. 在基本 SageMaker Studio 环境

   注意：已启动堆栈上使用的模板的默认位置是https://s3.<region>.amazonaws.com/cf-templates-<hash>-region/studio-environment.yaml，或者您可以直接将本章提供的 CloudFormation 模板上传到您选择的 S3 存储桶。

   release-1.0。

   初始产品发布。

   对于支持详情，本节包括有关支持联系人和支持信息的内容。请输入以下内容，未指定的字段留空：

   电子邮件联系：您的电子邮件地址 Your.email@mail.com

3. 在按照前面步骤填写信息后，滚动到页面底部，选择审查，然后创建产品。

4. 该产品现在将在数据科学环境组合的产品列表中可见。

在将产品添加到组合后，可以添加约束到产品中。然后，您可以使用在笔记本实例产品步骤下执行的相同步骤添加启动约束，以强制执行最小权限，并根据您的用例添加模板约束。

在配置产品后，它们可以通过机器学习构建者进行自助配置。机器学习构建者必须在 AWS 控制台中授予对 AWS 服务目录最终用户视图的访问权限。请参阅以下文档以获取有关共享您的投资组合和授予最终用户访问权限的详细信息：docs.aws.amazon.com/servicecatalog/latest/adminguide/getstarted-deploy.html。

本节介绍了使用 IaC/CaC（AWS CloudFormation）和集中管理的 IT 服务目录（AWS 服务目录）来大规模创建数据科学环境的优势。

请前往 参考资料 部分，以找到阅读本节后可能有用的附加参考链接。

摘要

在本章中，你看到了如何将 SageMaker 功能映射到机器学习生命周期的不同阶段。你快速浏览了重要的 SageMaker 功能，并了解了如何设置自己的 SageMaker 环境。

本章进一步介绍了使用 IaC/CaC（AWS CloudFormation）以及集中管理的 IT 服务目录（AWS 服务目录）来大规模创建数据科学环境的优势。所讨论的方法提供了减少手动工作、提供一致性、加速对模型构建服务的访问以及在内置模型构建环境中实施治理控制的指导。

在下一章中，你将学习更多关于为机器学习项目标记数据的内容。

参考资料

在阅读本节之后，以下是一些可能对您有用的参考资料：

• Amazon SageMaker 笔记本实例：docs.aws.amazon.com/sagemaker/latest/dg/nbi.html

• Amazon SageMaker Studio 入门：

  docs.aws.amazon.com/sagemaker/latest/dg/gs-studio-onboard.html

• Amazon SageMaker Studio：

  aws.amazon.com/sagemaker/studio/ docs.aws.amazon.com/sagemaker/latest/dg/notebooks.html

• 笔记本比较：

  docs.aws.amazon.com/sagemaker/latest/dg/notebooks-comparison.html

• AWS 服务目录：

  aws.amazon.com/servicecatalog/

• AWS CloudFormation：

  aws.amazon.com/cloudformation/

第三章：使用 Amazon SageMaker Ground Truth 进行数据标注

在大多数公司中，最大的机器学习项目障碍之一是获取标注的训练数据。在我们合作的一家公司中，我们试图确定对消费者有影响的故障。客户从其应用程序堆栈的每一层都有大量数据，但他们无法就如何定义故障达成一致。故障是不是当负载均衡器宕机时？可能不是——我们在基础设施层有冗余。故障是不是当客户无法访问服务超过 10 分钟时？这可能太细粒度了；单个客户可能由于本地网络连接问题而出现问题。那么，我们究竟指的是什么故障？我们如何自动将我们的训练数据标注为故障或非故障？

在本章中，我们将回顾使用 SageMaker Ground Truth 进行数据标注。我们将涵盖与大数据集和潜在有偏见数据相关的一些常见挑战。

本章将涵盖以下主题：

• 在大规模数据标注中遇到的挑战

• 使用自定义标注工作流程解决独特的标注需求

• 使用主动学习来减少标注时间

• 安全性和权限

技术要求

您需要 AWS 账户来运行本章包含的示例。如果您尚未设置数据科学环境，请参阅第二章**，数据科学环境，其中提供了设置过程的概述。

书中包含的代码示例可在 GitHub 上找到，网址为github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter03。您需要安装 Git 客户端才能访问它们（git-scm.com/)。

本章的代码位于 GitHub 仓库的CH03文件夹中。

在大规模数据标注中遇到的挑战

除了在如何标注数据上达成共识的概念性挑战外，我们还需要考虑物流。SageMaker Ground Truth允许您将数据标注工作分配给人工劳动力。但您可能会面临以下额外挑战：

• 独特的标注逻辑：如果我们的标注案例需要自定义工作流程，我们需要在地面真实情况中对其进行建模。

• 标注质量：工人应用标签可能存在隐含偏见，这会影响结果。

• 成本和时间：标注数据需要一段时间的人力。如果您有一个非常大的数据集，您将消耗大量的人时。

• 安全性：鉴于您的数据可能敏感，您需要确保数据访问仅限于授权的工作人员。

  其他信息

  如果您需要了解地面真实情况的介绍，请参阅由 Julien Simon 撰写的《Learn Amazon SageMaker》的第二章。

为了将这些关注点聚焦起来，让我们考虑一下我们在上一章中介绍的天气数据。Ground Truth 没有内置的工作流程允许我们提示工作人员根据我们描述空气为 好 或 坏 的逻辑来标注天气数据。整个时间段的整个数据集大约为 499 GB；手动将每条记录标注为 好 或 坏 天气质量将花费一些时间。最后，我们的工作人员可能会有他们自己的隐含或无意识的偏见。

在一个严重雾霾的城市长大的工作人员可能对空气质量的感知与在一个非常干净的乡村地区长大的工作人员大不相同。在接下来的章节中，我们将讨论如何解决这些挑战。

使用自定义标注工作流程解决独特的标注需求

让我们从为我们的天气数据创建一个标注任务开始。我们希望将每个天气报告标注为 好 或 坏。为了帮助我们的工作人员完成这项工作，我们将制作一个精美的前端，在地图上显示气象站的位置并显示气象站的读数。我们需要一个自定义的工作流程，因为这种场景并没有完美地符合现有的 Ground Truth 模板。

我们需要设置以下内容：

• 由 Cognito 用户池支持的私有工作团队

• 一个列出我们想要标注的项目清单的清单文件

• 一个自定义的 Ground Truth 标注工作流程，由两个 Lambda 函数和一个 UI 模板组成

我们存储库 CH02 文件夹中的笔记本 LabelData.ipynb 演示了这些步骤。

一个私有的标注工作团队

虽然你可以使用公共工作团队，但大多数公司都会希望使用私有工作团队来标注自己的数据。设置私有工作团队的第一步是定义一个 Cognito 用户池，在实际用例中，它可能链接到另一个身份提供者，如 Active Directory。

我们将在 Cognito 中创建一个用户组；你可以使用组来创建不同类型标注工作的团队。最后，我们将定义一个与 Cognito 用户组链接的 SageMaker 工作团队。请注意，SageMaker 创建了一个标注域，我们必须将其设置为 Cognito 用户池客户端的回调 URL。

一旦工作团队设置完成，笔记本将添加一个示例工作人员。

笔记本中的 创建一个私有工作团队 部分为您执行了所有这些步骤：

• 创建一个 Cognito 用户池

• 为用户池创建一个 Cognito 客户端

• 为客户端创建一个身份池

• 创建一个用户组

• 将一个域分配给用户池

• 创建一个使用 Cognito 用户池和组的 SageMaker 工作团队

• 添加一个示例用户

一旦你执行了笔记本中的 创建一个私有工作团队 部分，你应该会看到一个定义好的私有工作团队，以及工作人员将使用的登录 URL。如果你继续向下滚动控制台的这一部分，你还会看到关于工作团队和分配给该团队的工作人员的信息，如图 图 3.1 所示：

图 3.1 – 在 SageMaker 控制台中显示的标记劳动力

列出需要标记的数据

我们需要创建一个清单文件，告诉 Ground Truth 如何找到我们想要标记的数据。在清单中，我们可以列出 S3 中的文件引用，或者直接提供文本数据。

回想一下，我们的源数据是 JSON 格式。每个源文件包含多个条目，看起来像这样：

{"date":{"utc":"2021-03-20T19:00:00.000Z","local":"2021-03-20T23:00:00+04:00"},"parameter":"pm25","value":32,"unit":"µg/m³","averagingPeriod":{"val
ue":1,"unit":"hours"},"location":"US Diplomatic Post: Dubai","city":"Dubai","country":"AE","coordinates":{"latitude":25.25848,"longitude":55.309166
},"attribution":[{"name":"EPA AirNow DOS","url":"http://airnow.gov/index.cfm?action=airnow.global_summary"}],"sourceName":"StateAir_Dubai","sourceT
ype":"government","mobile":false}

我们不能传递单个文件的链接，因为每个文件都包含多个需要标记的记录。相反，我们将在清单文件中直接总结每条记录。清单中的每一行将包含空气质量指标和位置：

{"source": "pm25,35.8,µg/m³,40.01,116.333"}

创建清单文件 笔记本部分将为记录集生成一个清单。由于您是唯一的工人，我们默认将记录数限制为 20（更多内容将在下一节中介绍）。

创建工作流程

为了创建自定义工作流程，我们需要以下内容：

• 一个可以接受清单中的一个条目并将变量注入 UI 的 Lambda 函数。在这种情况下，我们将简单地映射清单文本条目到一个度量标签，并与其地理位置一起显示。

• 一个 UI 模板，可以合理地显示给工人的数据。在这种情况下，我们有一个简单的 UI 模板，它展示了指标以及收集指标的地理位置地图。

  注意

  对于本书的目的，我们正在使用来自 OpenStreetMap 的地图瓦片。不要在生产用例中使用这些瓦片。相反，使用商业提供商，如 Google Maps 或 Here。

• 一个 Lambda 函数，用于合并多个工人的注释。由于我们的样本劳动力中只有一个工人，我们在这里简单地进行了透传。

笔记本部分 创建自定义工作流程 会引导你完成以下步骤：

• 定义工作流程和 Lambda 函数的 IAM 角色

• 将用户界面模板和 Lambda 处理代码上传到 S3

• 创建预处理和后处理 Lambda 函数

• 定义标记工作

一旦创建标记工作，您可以通过标记门户 URL（见 图 1.1）登录，使用笔记本中指定的用户名和密码。一旦打开工作，您将看到一个类似于 图 3.2 的 UI：

图 3.2 – 显示气象站位置的标记 UI。位置以当地语言显示

您将看到一个显示测量位置和实际测量的地图。您可以选择 好 或 坏 来指定您认为测量是否代表空气质量好或坏的一天。在您标记完所有指标后，您的作业将显示为完成，您将看到每个数据点的标签，如图 图 3.3 所示：

![图 3.3 – 完成的标记工作

图 3.3 – 完成的标记工作

我们将在下一章中描述如何使用标注输出。您将在与本章节相关的笔记本中看到标注输出的示例。

使用多个工作者提高标注质量

依赖于单一意见进行主观评估是危险的。在某些情况下，标注看起来很简单；在标注交通图片时区分汽车和飞机相当简单。但让我们回到我们的天气数据。如果我们根据一个不直观的测量值（如颗粒物水平 PM25）来标注空气质量为好或坏，我们可能会发现工作者的意见在很大程度上取决于我们给予他们的建议和他们的先入之见。如果一个工作者认为某个城市或国家有 脏空气，他们在模糊情况下可能会倾向于选择 坏 标签。而这些偏见有实际后果——一些政府对他们的空气质量差这一想法非常敏感！

解决这个问题的方法之一是使用多个工作者来标注每个项目，并 somehow 结合分数。在名为 Add another worker 的笔记本部分，我们将向我们的私人工作团队中添加第二个工作者。然后在 Launch labeling job for multiple workers 部分中，我们将创建一个新的标注任务。一旦新任务准备就绪，以两个工作者的身份登录并标注我们已选定的少量数据。

现在会发生什么？我们需要调整我们的后处理 Lambda 来巩固标注。我们可以使用各种策略来进行巩固。例如，我们可以使用多数投票方案，在平局的情况下将其分配给一个 混合 类别。在本章中，我们将简单地使用最新的标注作为胜者，因为我们只有两个工作者。

使用主动学习减少标注时间

现在我们已经建立了一个标注工作流程，我们需要考虑规模。如果我们的数据集有超过 5,000 条记录，那么 Ground Truth 很可能能够学会如何为我们进行标注。（您至少需要 1,250 个标注记录来进行自动标注，但至少 5,000 是一个很好的经验法则。）这将在以下图中以迭代过程的形式发生：

图 3.4 – 自动标注工作流程

当您使用自动标注创建标注任务时，Ground Truth 将选择输入数据的一个随机样本进行人工标注。如果至少 90% 的这些项目在无错误的情况下被标注，Ground Truth 将将标注数据分成训练集和验证集。它将训练一个模型并计算一个置信度分数，然后尝试标注剩余的数据。如果自动生成的标签低于置信度阈值，它将把它们转交给工作者进行人工审查。这个过程会重复进行，直到整个数据集都被标注。虽然这个过程很难模拟，但它提供了一个迭代方法，通过人工输入来改进自动标注。

作为本节的结束语，你可能想知道一个能够自动标注数据的模型与一个更通用的机器学习模型之间的区别。这里有一条很细的界限。请记住，我们用于地面真相（Ground Truth）的数据可能并不完全代表我们在生产中看到的数据。我们对于一个通用机器学习模型的目标是创建一个无需任何人工输入就能产生准确推断的模型。

安全和权限

虽然有些数据并不敏感，但大多数公司都不希望在标注过程中将数据暴露给公众。在本节中，我们将介绍数据访问控制、加密和数据标注工作的人力资源管理。

当使用地面真相（或任何其他云服务）时，你应该遵循最小权限访问原则。限制允许创建标注作业的用户，并限制允许使用非私有工作队伍创建标注作业的用户。在自定义标注作业中，明确提供 Lambda 函数的调用权限。限制标注作业的访问权限，仅限于适当的 S3 存储桶和前缀。

当你运行标注作业时，地面真相将始终在 S3 中加密输出。你可以使用 S3 管理的密钥或提供自己的 KMS 密钥。对于非敏感数据，默认的 S3 管理密钥就足够了。如果你有敏感数据，考虑为不同的数据集使用不同的 KMS 密钥，因为这提供了另一层安全性。你也可以使用 KMS 密钥来加密用于自动标注的实例上的存储卷。

在管理你的工作队伍时，你应该限制对已知良好 IP 地址范围（CIDR 块）的访问。你还应该使用工人跟踪功能来记录哪些工人正在访问数据。当使用 Cognito 进行身份验证时，利用强大的密码策略和多因素身份验证。在大多数情况下，大型公司更愿意使用他们自己的身份提供者进行工作队伍管理。

最后，请注意，你需要在涉及标注工作的 S3 存储桶中添加CORS（跨源资源共享）配置，如文档中所述（docs.aws.amazon.com/sagemaker/latest/dg/sms-cors-update.html）。

在我们进入总结之前，请看一下以下表格，它总结了数据标注的一些最佳实践：

图 3.5 – 数据标注最佳实践的总结

通过这样，我们现在来到了本章的结尾。

总结

在本章中，我们开始深入挖掘我们的天气数据集，重点关注数据标注的问题。我们学习了如何使用 SageMaker Ground Truth 结合人工审核和自动化来标注大量数据集，如何使用自定义工作流程来辅助标注过程，以及如何通过使用多种意见来对抗标注偏差。我们以确保标注过程安全的一些建议作为结束。

在下一章中，我们将探讨数据准备。我们将在整个数据集上运行特征工程处理作业。

第四章：使用 Amazon SageMaker Data Wrangler 和 Processing 进行大规模数据准备

到目前为止，我们已经确定了我们的数据集并探索了手动和自动标记。现在，我们需要将注意力转向为训练准备数据。数据科学家熟悉特征工程步骤，例如缩放数值特征、编码分类特征和降维。

作为动机，让我们考虑我们的天气数据集。如果我们的输入数据集不平衡或并不真正代表我们在生产中遇到的数据，会怎样呢？我们的模型可能不会像我们希望的那样准确，后果可能非常严重。一些面部识别系统在偏向白人脸的数据集上进行了训练，产生了令人不安的后果(sitn.hms.harvard.edu/flash/2020/racial-discrimination-in-face-recognition-technology/?web=1&wdLOR=cB09A9880-DF39-442C-A728-B00E70AF1CA9)。

我们需要了解哪些输入特征正在影响模型。这在商业角度和法律或监管角度都很重要。考虑一个预测应用程序操作中断的模型。了解中断发生的原因可能比预测中断发生的时间更有价值——问题是出在我们的应用程序中，还是由于一些外部因素，如网络故障？然后，在某些行业，如金融服务行业，如果我们不能证明模型没有违反歧视性贷款等规定，我们就不能使用该模型。

我们数据集的小版本（涵盖 1 个月）大约有 5 GB 的数据。我们可以在现代工作站上分析这个数据集而不会遇到太多困难。但完整的数据集，接近 500 GB，怎么办呢？如果我们想准备完整的数据集，我们需要与水平可扩展的集群计算框架合作。此外，如果我们使用低效的处理框架，编码分类变量等活动可能需要相当长的时间。

在本章中，我们将探讨在处理大型数据集时数据准备所面临的挑战，并检查SageMaker中帮助我们进行大规模特征工程的功能。

在本章中，我们将涵盖以下主题：

• 使用 Data Wrangler 进行可视数据准备

• 使用 Data Wrangler 进行偏差检测和可解释性

• 使用 SageMaker Processing 进行大规模数据准备

技术要求

运行本章中包含的示例需要 AWS 账户。如果您尚未设置数据科学环境，请参阅第二章**，数据科学环境，其中将指导您完成设置过程。

书中包含的代码示例可在 GitHub 上找到：github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter04。您需要安装 Git 客户端才能访问它们（git-scm.com/）。

本章的代码位于 GitHub 仓库的 CH04 文件夹中。

使用 Data Wrangler 进行可视数据准备

让我们从我们的 1 个月数据集开始小规模操作。在深入研究更可扩展的技术之前，使用小数据集熟悉数据是一个好方法。SageMaker Data Wrangler 以一种简单的方式为我们提供了构建数据流的方法，这是一系列由可视化界面驱动的数据准备步骤。

在本节的其余部分，我们将使用 Data Wrangler 检查和转换数据，然后将 Data Wrangler 步骤导出为可重用的流程。

数据检查

让我们从数据检查的 Data Wrangler 开始，在这里我们查看数据的属性并确定如何为模型训练做准备。首先在 SageMaker Studio 中添加一个新的流程；转到文件菜单，然后选择新建，再选择流程。在流程启动并连接到 Data Wrangler 后，我们需要导入我们的数据。以下截图显示了 Data Wrangler 中的数据导入步骤：

图 4.1 – 在 Data Wrangler 中导入数据源

由于我们的数据集由多个散布在日期分区文件夹中的小 JSON 文件组成，我们将使用 PrepareData.ipynb 笔记本，它将指导你创建一个 Glue 数据库和表，并在名为 Glue Catalog 的部分中注册分区。完成这些后，点击Athena开始导入小数据集。

在下一屏幕上，指定你在笔记本中创建的数据库。输入以下查询以导入一个月的数据：

select * from openaq where aggdate like '2019-01%'

以下截图显示了 Data Wrangler 中的导入步骤：

图 4.2 – Athena 导入到 Data Wrangler

运行查询并点击导入数据集。

现在我们准备进行一些分析和转换。点击数据流中最后一个框旁边的+符号，选择添加分析。你现在将有一个屏幕，你可以选择一个可用的分析，如下面的截图所示：

图 4.3 – 数据分析配置

从一个表摘要步骤开始，它显示了数值特征的某些统计属性，如下面的截图所示：

图 4.4 – 表摘要

接下来，让我们尝试一个散点图来帮助我们可视化测量值的分布。将 y 轴设置为 value，x 轴设置为 aggdate，按 country 着色，并按 parameter 分面。我们可以在以下预览图表中看到，二氧化氮的值随时间相对稳定，而一氧化碳的值在一些国家显示出更多的变化性：

图 4.5 – 通过日期显示测量值，按国家着色，并按参数分面的散点图

随意添加更多散点图或尝试直方图。我们将在“使用 Data Wrangler 和 Clarify 进行偏差检测和可解释性”部分探索偏差报告和快速模式。

现在我们已经进行了一些基本的数据检查，我们将继续进行数据转换。

数据转换

在本节中，我们将把原始数据格式转换为可用于模型训练的格式。回顾一下我们原始数据的基本格式：

{“date”:{“utc”:”2021-03-20T19:00:00.000Z”,”local”:”2021-03-20T23:00:00+04:00”},”parameter”:”pm25”,”value”:32,”unit”:”µg/m³”,”averagingPeriod”:{“val
ue”:1,”unit”:”hours”},”location”:”US Diplomatic Post:Dubai”,”city”:”Dubai”,”country”:”AE”,”coordinates”:{“latitude”:25.25848,”longitude”:55.309166
},”attribution”:[{“name”:”EPA AirNow DOS”,”url”:”http://airnow.gov/index.cfm?action=airnow.global_summary”}],”sourceName”:”StateAir_Dubai”,”sourceT
ype”:”government”,”mobile”:false}

我们将使用 Data Wrangler 执行以下步骤：

• 规模数值。

• 对分类值进行编码。

• 添加与日期相关的特征（例如，星期几，月份中的某一天）。

• 删除不需要的列（source name、coordinates、averaging period、attribution、units 和 location）。这些列要么是冗余的（例如，位置的重要部分在城市和国家列中），要么不能作为特征使用。

返回流程的 准备 部分，点击数据流面板中最后一个框旁边的 + 符号，并选择 添加转换。您将看到数据集的预览和可用转换的列表，如下所示：

图 4.6 – Data Wrangler 中的数据转换

对于我们的第一次转换，选择 sourcetype 作为列，将 输出样式 设置为 列，并为新列名添加前缀：

图 4.7 – Data Wrangler 中的独热编码

当您完成设置转换后，点击 预览，然后点击 添加 以添加转换。现在您可以添加额外的转换来删除不需要的列，缩放数值列，并特征化日期。如果您愿意，还可以提供自己的自定义代码。

导出流程

当我们想要快速探索数据集时，Data Wrangler 非常方便。但我们也可以将流程的结果导出到 Amazon SageMaker 特征存储库，生成 SageMaker 管道，创建 Data Wrangler 作业，或生成 Python 代码。我们现在不会使用这些功能，但请随意尝试它们。

使用 Data Wrangler 和 Clarify 进行偏差检测和可解释性

在我们对数据进行了初步的探索和准备之后，现在让我们对我们的输入数据进行一次合理性检查。虽然偏差可以意味着许多事情，但一个特定的症状是数据集中一种类型的数据样本比另一种类型多得多，这将影响我们模型的表现。我们将使用 Data Wrangler 来查看我们的输入数据是否不平衡，并了解哪些特征对我们模型最重要。

首先，向流程中添加一个分析。选择mobile列作为标签，1作为预测值。选择city列用于偏差分析，然后点击检查偏差。在这种情况下，我们想确定我们的数据集是否在某种程度上与城市不平衡，以及数据是否在移动站收集。如果来自移动源的数据质量低于非移动源，了解移动源在城市间的分布是否均匀将是有益的。

接下来，我们将检查特征重要性。特征重要性是模型可解释性的一个方面。我们想了解数据集中哪些部分对模型行为最重要。另一个方面，我们将在第十一章**，使用 Amazon SageMaker Model Monitor 和 Clarify 监控生产模型部分探讨，是了解哪些特征对特定推理做出了贡献。

在流程的最后一步添加另一个分析。选择value列（Data Wrangler 将推断这是一个回归问题）。预览并创建分析。您应该看到一个类似于以下屏幕截图的屏幕：

图 4.8 – Data Wrangler 生成的特征重要性

此分析生成一个随机森林模型，使用包含 30% 数据的测试集评估性能，并为每个特征计算一个Gini 重要性分数。如图 4.8 所示，城市和月份是最重要的特征。

到目前为止，我们已经使用 Data Wrangler 进行了视觉检查和转换。现在，我们将探讨如何使用 SageMaker Processing 处理更大的数据集。

使用 SageMaker Processing 进行大规模数据准备

现在，让我们将注意力转向准备整个数据集。由于有 500 GB，它太大，无法使用单个 EC2 实例上的 sklearn 进行处理。我们将编写一个使用 Spark ML 进行数据准备的 SageMaker 处理作业。（或者，您也可以使用 Dask，但在撰写本文时，SageMaker Processing 并未提供开箱即用的 Dask 容器。）

本章笔记本的Processing Job部分将指导您启动处理作业。请注意，我们将使用 15 个 EC2 实例的集群来运行作业（如果您需要提高限制，可以联系 AWS 支持）。

还请注意，到目前为止，我们一直在使用数据的未压缩 JSON 版本。这种包含数千个小 JSON 文件的格式对于 Spark 处理来说并不理想，因为OpenAQ数据集还包括一个gzip，它不是一个首选的压缩格式，因为它不可分割；如果您有选择，请使用 Snappy 压缩格式。

我们将使用我们数据的 gzip Parquet 版本进行较大的数据准备工作：

1. 首先，我们将定义processor类，使用7200秒（2 小时）。两小时足以处理 Parquet 数据集中的至少一张表。如果您想处理所有八张表，请将超时时间更改为 3 小时，并在preprocess.py脚本中进行调整：

   spark_processor = PySparkProcessor(
       base_job_name=”spark-preprocessor”,
       framework_version=”3.0”,
       role=role,
       instance_count=15,
       instance_type=”ml.m5.4xlarge”,
       max_runtime_in_seconds=7200,
   )
   

2. 接下来，我们将设置 Spark 配置，遵循 EMR 博客中定义的公式（aws.amazon.com/blogs/big-data/best-practices-for-successfully-managing-memory-for-apache-spark-applications-on-amazon-emr/)：

   configuration = [
       {
       “Classification”: “spark-defaults”,
       “Properties”: {“spark.executor.memory”: “18g”, 
           “spark.yarn.executor.memoryOverhead”: “3g”,
                      “spark.driver.memory”: “18g”,
             “spark.yarn.driver.memoryOverhead”: “3g”,
                      “spark.executor.cores”: “5”, 
                      “spark.driver.cores”: “5”,
                      “spark.executor.instances”: “44”,
                      “spark.default.parallelism”: “440”,
               “spark.dynamicAllocation.enabled”: “false”
                     },
       },
       {
       “Classification”: “yarn-site”,
       “Properties”: {“yarn.nodemanager.vmem-check-enabled”: “false”, 
         “yarn.nodemanager.mmem-check-enabled”: “false”},
       }
   ]
   

3. 最后，我们将启动作业。我们需要包含一个 JSON serde类：

   spark_processor.run(
       submit_app=”scripts/preprocess.py”,
       submit_jars=[“s3://crawler-public/json/serde/json-serde.jar”],
       arguments=['--s3_input_bucket', s3_bucket,
                 '--s3_input_key_prefix', s3_prefix_parquet,
                  '--s3_output_bucket', s3_bucket,
                '--s3_output_key_prefix', s3_output_prefix],
       spark_event_logs_s3_uri=”s3://{}/{}/spark_event_logs”.format(s3_bucket, 'sparklogs'),
       logs=True,
       configuration=configuration
   )
   

处理脚本CH04/scripts/preprocess.py会经过几个步骤，我们将在后续章节中解释。

加载数据集

我们将从 S3 加载一个或多个 Parquet 表集。如果您想处理多个，请修改get_tables函数以返回列表中的更多表名，如下所示：

# the helper function `get_tables` lists the tables we want to include
tables = get_tables()
df = spark.read.parquet( 
    f”s3://{args.s3_input_bucket}/” +
    f”{args.s3_input_key_prefix}/{tables[0]}/”)
for t in tables[1:]:
    df_new = spark.read.parquet( 
        f”s3://{args.s3_input_bucket}/” +
        f”{args.s3_input_key_prefix}/{t}/”)
    df = df.union(df_new)

处理脚本中的下一步是删除数据集中的不必要的列。

删除列

我们将重复在 Data Wrangler 中执行的大部分步骤，使用PySpark。我们需要删除一些我们不想要的列，如下所示：

df = df.drop('date_local') \     
.drop('unit') \
.drop('attribution') \
.drop('averagingperiod') \
.drop('coordinates')

转换数据类型

我们将mobile字段转换为整数：

df = df.withColumn(“ismobile”,col(“mobile”).cast(IntegerType())) \
.drop('mobile')

缩放数值字段

我们将使用 Spark ML 标准缩放器来转换value字段：

value_assembler = VectorAssembler(inputCols=[“value”], outputCol=”value_vec”)
value_scaler = StandardScaler(inputCol=”value_vec”, outputCol=”value_scaled”)
value_pipeline = Pipeline(stages=[value_assembler, value_scaler])
value_model = value_pipeline.fit(df)
xform_df = value_model.transform(df)

特征化日期

日期本身并不那么有用，因此我们将从中提取几个新特征，表示日期、月份、季度和年份：

xform_df = xform_df.withColumn('aggdt', 
               to_date(unix_timestamp(col('date_utc'), 
“yyyy-MM-dd'T'HH:mm:ss.SSSX”).cast(“timestamp”)))
xform_df = xform_df.withColumn('year',year(xform_df.aggdt)) \
        .withColumn('month',month(xform_df.aggdt)) \
        .withColumn('quarter',quarter(xform_df.aggdt))
xform_df = xform_df.withColumn(“day”, date_format(col(“aggdt”), “d”))

模拟空气质量标签

虽然我们在第三章**，使用 Amazon SageMaker Ground Truth 进行数据标注中使用了地面真实数据，但为了演示的目的，我们将使用一个简单的启发式方法来分配这些标签：

isBadAirUdf = udf(isBadAir, IntegerType())
xform_df = xform_df.withColumn('isBadAir', isBadAirUdf('value', 'parameter'))

编码分类变量

现在，我们将对分类特征进行编码。这些特征中的大多数都具有相当高的基数，因此我们将在这里执行顺序编码，并在训练过程中稍后学习嵌入。我们只将对参数使用独热编码，它只有七个可能的选择：

parameter_indexer = StringIndexer(inputCol=”parameter”, \
outputCol=”indexed_parameter”, handleInvalid='keep')
location_indexer = StringIndexer(inputCol=”location”, \
outputCol=”indexed_location”, handleInvalid='keep')
city_indexer = StringIndexer(inputCol=”city”, \ 
outputCol=”indexed_city”, handleInvalid='keep')
country_indexer = StringIndexer(inputCol=”country”, \
outputCol=”indexed_country”, handleInvalid='keep')
sourcename_indexer = StringIndexer(inputCol=”sourcename”, \
outputCol=”indexed_sourcename”, handleInvalid='keep')
sourcetype_indexer = StringIndexer(inputCol=”sourcetype”, \
outputCol=”indexed_sourcetype”, handleInvalid='keep')
enc_est = OneHotEncoder(inputCols=[“indexed_parameter”], \
outputCols=[“vec_parameter”])
enc_pipeline = Pipeline(stages=[parameter_indexer, location_indexer, 
        city_indexer, country_indexer, sourcename_indexer, 
        sourcetype_indexer, enc_est])
enc_model = enc_pipeline.fit(xform_df)
enc_df = enc_model.transform(xform_df)
param_cols = enc_df.schema.fields[17].metadata['ml_attr']['vals']

分割和保存数据集

在对数据集进行一些最后的清理后，我们可以将数据集分为训练集、验证集和测试集，并将它们保存到 S3：

(train_df, validation_df, test_df) = final_df.randomSplit([0.7, 0.2, 0.1])
train_df.write.option(“header”,True).csv('s3://' + \
os.path.join(args.s3_output_bucket, 
      args.s3_output_key_prefix, 'train/'))
validation_df.write.option(“header”,True).csv('s3://' + \
os.path.join(args.s3_output_bucket, 
      args.s3_output_key_prefix, 'validation/'))
test_df.write.option(“header”,True).csv('s3://' + \
os.path.join(args.s3_output_bucket, 
      args.s3_output_key_prefix, 'test/'))

在本节中，我们学习了如何使用 SageMaker Processing 作业在更大的数据集上使用 Apache Spark 进行数据准备。在实际应用中，许多数据集足够大，需要分布式处理框架，现在你了解了如何将 Spark 作业集成到你的 SageMaker 工作流程中。

摘要

在本章中，我们处理了一个大型（约 500 GB）数据集的特征工程问题。我们探讨了包括可扩展性、偏差和可解释性在内的挑战。我们了解了如何使用 SageMaker Data Wrangler、Clarify 和 Processing 作业来探索和准备数据。

虽然有多种使用这些工具的方法，但我们建议使用 Data Wrangler 进行小到中等规模数据集的交互式探索。对于处理整个大型数据集，切换到使用 Spark 框架的编程方式来利用并行处理。 （在撰写本文时，Data Wrangler 不支持在多个实例上运行，但你可以在多个实例上运行一个处理作业。）你始终可以将 Data Wrangler 流程导出作为起点。

如果你的数据集达到数个 TB，考虑直接在EMR或 Glue 上运行 Spark 作业，并使用 SageMaker Spark SDK 调用 SageMaker。EMR 和 Glue 对 Spark 运行时进行了优化，并与 S3 存储有更高效的集成。

到目前为止，我们的数据已经准备好用于模型训练。在下一章中，我们将探讨使用 Amazon SageMaker Feature Store 来帮助我们管理准备好的特征数据。

第五章：使用 Amazon SageMaker Feature Store 的集中式特征仓库

让我们从基本问题开始——什么是特征存储，为什么它是必要的？特征存储是一个持久化工程特征的仓库。特征工程需要花费大量时间，有时涉及多步骤的数据处理管道，这些管道需要数小时的计算时间。机器学习模型依赖于这些来自各种数据源的工程特征。特征存储通过减少将原始数据转换为特征所需的重复数据处理来加速这一过程。特征存储不仅允许你在模型构建活动中共享工程特征，还允许在使用工程特征进行推理时保持一致性。

Amazon SageMaker Feature Store 是一个具有存储、更新、检索和共享特征功能的托管仓库。SageMaker Feature Store 提供了在两种不同场景下重用工程特征的能力。首先，特征可以在单个机器学习项目的训练和推理阶段之间共享，从而实现一致的模型输入和减少训练-服务偏差。其次，SageMaker

特征存储也可以在多个机器学习项目中共享，从而提高数据科学家的生产力。

到本章结束时，您将能够使用 Amazon SageMaker Feature Store 的功能，并将最佳实践应用于解决减少数据处理时间和为近实时机器学习推理设计特征架构的挑战。

在本章中，我们将涵盖以下主要内容：

• Amazon SageMaker Feature Store 的基本概念

• 创建可重用特征以减少特征不一致性和推理延迟

• 为近实时机器学习预测设计解决方案

技术要求

您需要 AWS 账户才能运行本章中包含的示例。如果您尚未设置数据科学环境，请参阅第二章，数据科学环境，其中提供了设置过程的概述。

书中包含的代码示例可在 GitHub 上找到，网址为 github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter05。您需要安装 Git 客户端才能访问它们（git-scm.com/）。

Amazon SageMaker Feature Store 基础知识

在本节中，您将学习 Amazon SageMaker Feature Store 的基本术语和功能。Amazon SageMaker Feature Store 提供了一个集中式仓库，具有存储、更新、检索和共享特征的能力。可扩展的存储和近实时特征检索是 Amazon SageMaker Feature Store 的核心。利用 Amazon SageMaker Feature Store 涉及三个高级步骤，如下面的图所示：

图 5.1 – 使用 Amazon SageMaker 特征存储的高级步骤

让我们更详细地看看这些步骤中每一步涉及的内容。

创建特征组

在 Amazon SageMaker 特征存储中，特征存储在一个称为 RecordIdentifier 的集合中。属于每个特征组的每个记录都将使用与 RecordIdentifier 相同的特征。例如，为天气数据创建的特征存储的记录标识符可以是 parameter_id 或 location_id。将 RecordIdentifier 视为特征组的主键。使用这个主键，您可以查询特征组以快速查找特征。还重要的是要注意，特征组的每个记录至少必须包含一个 RecordIdentifier 和一个事件时间特征。当设置特征组时，事件时间特征由 EventTimeFeatureName 确定。当特征记录被摄入特征组时，SageMaker 为每个特征记录添加三个特征 – is_deleted、api_invocation 时间和 write_time –。is_deleted 用于管理记录的删除，api_invocation_time 是调用 API 将记录写入特征存储的时间，而 write_time 是特征记录持久化到离线存储的时间。

图 5.2 展示了特征存储的结构的高级视图：

图 5.2 – Amazon SageMaker 特征存储结构

虽然每个特征组都是独立管理和扩展的，但你可以在适当访问权限的情况下搜索和发现多个特征组中的特征。

当您使用 SageMaker 创建特征存储组时，可以选择启用离线存储、在线存储或两者都启用。当启用在线和离线存储时，服务将在线存储内容复制到 Amazon S3 中维护的离线存储。

以下代码块展示了创建特征存储的过程：

1. 首先定义特征组名称：

   #Feature group name
   weather_feature_group_name_offline = 'weather-feature-group-offline' + strftime('%d-%H-%M-%S', gmtime())
   

2. 然后，创建捕获特征名称和类型的特征定义：

   ##Create FeatureDefinitions
   fd_location=FeatureDefinition(feature_name='location', feature_type=FeatureTypeEnum('Integral'))
   fd_event_time=FeatureDefinition(feature_name='EventTime', feature_type=FeatureTypeEnum('Fractional'))
   …
   weather_feature_definitions = []
   weather_feature_definitions.append(fd_location)
   weather_feature_definitions.append(fd_event_time)
   …
   

3. 接下来，定义记录标识符特征：

   ##Define unique identifier
   record_identifier_feature_name = "location"
   

4. 最后，使用 create() API 创建特征组，默认情况下，它创建一个具有离线存储的特征组：

   #Create offline feature group
   weather_feature_group_offline =     \ 
       FeatureGroup(name=weather_feature_group_name_offline,
            feature_definitions=weather_feature_definitions,
                    sagemaker_session=sagemaker_session) 
   weather_feature_group_offline.create(
                s3_uri=f"s3://{s3_bucket_name}/{prefix}",
               record_identifier_name="location",
               event_time_feature_name="EventTime",
               role_arn=role
   )
   

5. 要启用在线存储以及离线存储，请使用 enable_online_store，如下面的代码所示：

   weather_feature_group_offline_online.create(
               s3_uri=f"s3://{s3_bucket_name}/{prefix}",
       record_identifier_name="location", 
              event_time_feature_name="EventTime",
              role_arn=role,
             enable_online_store=True
   )
   

6. 要创建仅启用在线存储的特征组，将 s3_uri 设置为 False，如下面的代码所示：

   weather_feature_group_online.create(
               s3_uri=False,
               record_identifier_name="location", 
              event_time_feature_name="EventTime",
              role_arn=role,
              enable_online_store=True
   )
   

注意，您还可以使用 SageMaker Studio 创建特征组。一旦使用 API 或 SageMaker Studio 创建了特征组，您就可以在 SageMaker Studio 中查看它们及其状态。图 5.3 展示了 SageMaker Studio 中的特征组列表：

图 5.3 – SageMaker Studio 中的特征组列表

为了总结特征组创建的讨论，以下表格总结了在线和离线特征存储之间的差异：

![图 5.4 – 在线和离线特征存储的比较

图 5.4 – 在线特征存储和离线特征存储的比较

现在您可以在特征存储中创建特征组了，让我们看看如何填充它们。

填充特征组

在创建特征组后，您将使用特征填充它们。您可以使用批量摄取或流式摄取将特征摄取到特征组中，如图 5.5 所示：

![图 5.5 – 将特征摄取到特征组中

图 5.5 – 将特征摄取到特征组中

要将特征摄取到特征存储中，您创建一个可以填充特征存储的特征管道。PutRecord API 调用是摄取特征的核心 SageMaker API。这适用于在线和离线特征存储，以及通过批量或流式方法摄取。

以下代码块显示了PutRecord API 的使用：

##Create a record to ingest into the feature group
record = []
event_time_feature = {'FeatureName': 'EventTime','ValueAsString': str(int(round(time.time())))}
location_feature =   {'FeatureName': 'location','ValueAsString': str('200.0')}
ismobile_feature =   {'FeatureName':   'ismobile','ValueAsString': str('0')}
value_feature ={'FeatureName': 'value','ValueAsString': str('34234.0')}

record.append(event_time_feature)
record.append(location_feature)
record.append(ismobile_feature)
record.append(value_feature)

response = sagemaker_fs_runtime_client.put_record(
       FeatureGroupName=weather_feature_group_online,
                                             Record=record)

您还可以使用包装 API，fg.ingest，它接受一个 pandas dataframe作为输入，并允许您配置多个工作进程和进程以并行摄取特征。以下代码块显示了如何使用ingest() API：

#Read csv directly from S3 into a dataframe
weather_df = pd.read_csv(s3_path)

#Ingest features into the feature group
weather_feature_group_offline.ingest(
          data_frame=weather_df, max_workers=3, wait=True
)

对于批量摄取，您可以使用作者特征（例如，使用PutRecord API 调用）。当将记录摄取到在线特征存储时，您仅维护给定记录标识符的最新特征值。如果特征组配置了在线和离线存储，则历史值仅在复制的离线存储中维护。图 5.6 概述了与在线和离线特征存储相关的摄取特征的方法：

![图 5.6 – 摄取特征存储记录

图 5.6 – 摄取特征存储记录

拥有摄取 API 在手，让我们看看一个通用的批量摄取架构。图 5.7 显示了使用Amazon SageMaker Processing进行批量摄取的架构：

![图 5.7 – 使用 SageMaker Processing 进行批量摄取

图 5.7 – 使用 SageMaker Processing 进行批量摄取

下面是批量摄取架构中涉及的高级步骤：

1. 大量原始数据存储在 S3 桶中。

2. Amazon SageMaker Processing 作业以原始数据作为输入，并应用特征工程技术到数据上。处理作业可以配置在实例的分布式集群上运行，以大规模处理数据。

3. 处理作业还使用PutRecord API 摄取到特征组的在线存储中的工程化特征。然后，特征自动复制到特征组的离线存储。

4. 离线存储中的特征可以用于训练其他模型，以及其他数据科学团队来解决各种其他用例。在线存储中的特征可以用于实时预测期间的特性查找。

注意，如果在此架构中使用的特征存储仅是离线的，处理作业可以直接使用PutRecord API 写入离线存储。

接下来，让我们看看可能的流式摄取架构，如图 5.8 所示。这应该看起来与批量摄取非常相似，除了不使用处理作业，而是使用单个计算实例或AWS Lambda 函数：

![图 5.8 – 使用 AWS Lambda 的流式摄取

图 5.8 – 使用 AWS Lambda 的流式摄取

流式摄取架构涉及以下高级步骤：

1. 原始数据落在 S3 存储桶中，这触发了 AWS Lambda 函数。

2. Lambda 函数通过PutRecord API 处理数据并将特征插入特征组的在线存储中。

3. 特征随后会自动复制到特征组的离线存储中。

4. 离线存储中的特征可以用于训练其他模型，以及其他数据科学团队来解决各种其他用例。在线存储中的特征可以用于实时预测期间的特性查找。

除了使用摄取 API 填充离线存储之外，您还可以直接填充底层 S3 存储桶。如果您不需要实时推理，并且有大量历史特征数据（数太字节甚至数百吉字节）想要迁移到离线特征存储以用于训练模型，您可以直接将它们上传到底层 S3 存储桶。为了有效地完成这项工作，了解离线存储桶的 S3 文件夹结构非常重要。离线存储中的特征组按照s3结构组织：

s3://<bucket-name>/<customer-prefix>/<account-id>/sagemaker/<aws-region>/offline-store/<feature-group-name>-<feature-group-creation-time>/data/year=<event-time-year>/month=<event-time-month>/day=<event-time-day>/hour=<event-time-hour>/<timestamp_of_latest_event_time_in_file>_<16-random-alphanumeric-digits>.parquet

还请注意，当您使用摄取 API 时，isdeleted、api_invocation_time和write-time特征会自动包含在特征记录中，但当你直接写入离线存储时，您负责包括它们。

从特征组检索特征

一旦特征组被填充，要从特征存储中检索特征，有两个 API 可用——get_record和batch_get_record。以下代码块展示了使用get_record API 从一个特征组中检索单个记录：

record_identifier_value = str('300')
response = sagemaker_fs_runtime_client.get_record
(FeatureGroupName=weather_feature_group_name_online,
RecordIdentifierValueAsString=record_identifier_value)
response
Response from the code block looks similar to the following figure:
{'ResponseMetadata': {'RequestId': '195debf2-3b10-4116-98c7-142dc13e9df3',
  'HTTPStatusCode': 200,
  'HTTPHeaders': {'x-amzn-requestid': '195debf2-3b10-4116-98c7-142dc13e9df3',
   'content-type': 'application/json',
   'content-length': '214',
   'date': 'Wed, 14 Jul 2021 04:27:11 GMT'},
  'RetryAttempts': 0},
 'Record': [{'FeatureName': 'value', 'ValueAsString': '4534.0'},
  {'FeatureName': 'ismobile', 'ValueAsString': '0'},
  {'FeatureName': 'location', 'ValueAsString': '300'},
  {'FeatureName': 'EventTime', 'ValueAsString': '1626236799'}]}

类似地，以下代码展示了使用batch_get_record API 从一个或多个特征组中检索多个记录：

record_identifier_values = ["200", "250", "300"]
response=sagemaker_fs_runtime_client.batch_get_record(
            Identifiers=[
           {"FeatureGroupName": weather_feature_group_name_online, "RecordIdentifiersValueAsString": record_identifier_values}
            ]
)
response

代码块的响应应该类似于以下响应：

{'ResponseMetadata': {'RequestId': '3c3e1f5f-3a65-4b54-aa18-8683c83962c5',
  'HTTPStatusCode': 200,
  'HTTPHeaders': {'x-amzn-requestid': '3c3e1f5f-3a65-4b54-aa18-8683c83962c5',
   'content-type': 'application/json',
   'content-length': '999',
   'date': 'Wed, 14 Jul 2021 04:29:47 GMT'},
  'RetryAttempts': 0},
 'Records': [{'FeatureGroupName': 'weather-feature-group-online-13-19-23-46',
   'RecordIdentifierValueAsString': '300',
   'Record': [{'FeatureName': 'value', 'ValueAsString': '4534.0'},
           {'FeatureName': 'ismobile', 'ValueAsString': '0'},
           {'FeatureName': 'location', 'ValueAsString': '300'},
          {'FeatureName': 'EventTime', 'ValueAsString': '1626236799'}]},
  {'FeatureGroupName': 'weather-feature-group-online-13-19-23-46',
   'RecordIdentifierValueAsString': '200',
   'Record': [{'FeatureName': 'value', 'ValueAsString': '34234.0'},
            {'FeatureName': 'ismobile', 'ValueAsString': '0'},
           {'FeatureName': 'location', 'ValueAsString': '200'},
          {'FeatureName': 'EventTime', 'ValueAsString': '1626236410'}]}],
 'Errors': [],
 'UnprocessedIdentifiers': []}

应该使用 get_record 和 batch_get_record API 与在线存储一起使用。此外，由于离线存储的底层存储是一个 S3 存储桶，你可以直接使用 Athena 或其他访问 S3 的方式来查询离线存储。以下代码展示了从支持离线存储的 S3 存储桶中直接检索所有特征记录的示例 Athena 查询：

weather_data_query = weather_feature_group.athena_query()
weather_table = weather_data_query.table_name

#Query string
query_string = 'SELECT * FROM "'+ weather_table + '"'
print('Running ' + query_string)

#run Athena query. The output is loaded to a Pandas dataframe.
weather_data_query.run(query_string=query_string, output_location='s3://'+s3_bucket_name+'/'+prefix+'/query_results/')
weather_data_query.wait()
dataset = weather_data_query.as_dataframe()

对于本书中使用的数据集，我们将使用两个特征组——位置和天气数据。位置特征组将使用 location_id 作为记录标识符，并捕获与位置相关的特征，例如城市名称。天气数据特征组也将使用 location_id 作为记录标识符，并捕获天气质量测量值，例如 pm25。这使我们能够在多个 ML 项目中使用特征组。

例如，来自位置和天气数据特征组的特征被用于回归模型，以预测给定位置的未来的天气测量值。另一方面，来自天气数据特征组的特征也可以用于聚类模型，以找到具有相似测量的站点。

重要提示

示例笔记本提供了创建特征组、将特征摄入特征组以及从特征组中检索特征的 Amazon SageMaker Feature Store 关键 API 的操作指南。为了看到所有功能存储功能在实际中的应用，我们建议你在 第二章，数据科学环境中设置的数据科学环境中执行示例笔记本：

gitlab.com/randydefauw/packt_book/-/blob/main/CH05/feature_store_apis.ipynb.

现在你已经学习了 SageMaker Feature Store 的功能，在接下来的两节中，你将学习如何使用这些功能来解决数据科学家和组织面临的功能设计挑战。

创建可重用特征以减少特征不一致性和推理延迟

数据科学家面临的一个挑战是，为了准备用于 ML 训练的特征，需要花费很长时间的数据处理时间——几个小时甚至几天。此外，在特征工程中应用的数据处理步骤需要在预测时间对推理请求进行应用，这增加了推理延迟。每个数据科学团队即使使用相同的原始数据为不同的模型，也需要花费这些数据处理时间。在本节中，我们将讨论使用 Amazon SageMaker Feature Store 解决这些挑战的最佳实践。

对于需要低延迟特征进行推理的使用案例，应配置在线特征存储，并且通常建议同时启用在线和离线特征存储。启用在线和离线存储的特征存储允许您在训练和推理阶段重用相同的特征值。这种配置减少了两个阶段之间的不一致性，并最小化了训练和推理偏差。在此模式下，为了填充存储，可以使用批量或流式方式将特征摄取到在线存储中。

当您将特征摄取到在线存储中时，SageMaker 会自动将特征值复制到离线存储中，并持续追加最新的值。重要的是要注意，对于在线特征存储，只维护最新的特征记录，并且 PutRecord API 总是作为 insert/upsert 处理。这是关键，因为如果您需要更新特征记录，那么执行此操作的过程是重新插入或覆盖现有记录。这是为了允许以尽可能低的延迟检索用于推理用例的特征。

虽然在线特征存储只维护最新的记录，但离线存储将提供特征值随时间变化的全历史记录。记录将保留在离线存储中，直到它们被明确删除。因此，您应该建立一个流程，使用为 S3 归档提供的标准机制来修剪离线特征存储中的不必要记录。

重要提示

来自 GitHub 仓库的示例笔记本展示了创建特征存储、摄取特征、检索特征以及进一步使用特征进行模型训练、部署模型和在使用推理期间从特征存储中获取特征的端到端流程：gitlab.com/randydefauw/packt_book/-/blob/main/CH04/feature_store_train_deploy_models.ipynb。

另一个最佳实践是为特征版本设置标准。随着特征的演变，跟踪特征版本非常重要。考虑在两个级别上进行版本控制——特征组的版本和特征组内特征的版本。当需要添加或删除特征定义时，例如特征模式发生变化时，您需要为特征组创建一个新的版本。

在本书出版时，特征组是不可变的。要添加或删除特征，你需要创建一个新的特征组。为了满足具有不同数量特征的多个版本的特征组的需求，建立并坚持命名约定。例如，你可以最初创建一个 weather-conditions-v1 特征组。当该特征组需要更新时，你可以创建一个新的 weather-conditions-v2 特征组。你也可以考虑在数据准备或使用上添加描述性标签，例如 weather-conditions-latest-v2 或 weather-conditions-stable-v2。你还可以对特征组进行标记以提供元数据。此外，你还应该建立支持多少个并发版本的标准以及何时弃用旧版本。

对于单个特征的版本控制，离线存储会保留特征组中所有特征值的记录。每个特征记录都需要有一个 eventTime，这支持通过日期访问特征版本。要从离线存储中检索特征的先前版本值，请使用具有特定时间戳的 Athena 查询，如下面的代码块所示：

#Query string with specific date/time
timestamp = int(round(time.time()))
time_based_query_string = f"""
SELECT *
FROM "{weather_table}"
where eventtime <= {timestamp} and city=1080.0
"""
# Run Athena query. The output is loaded to a Pandas dataframe.
weather_query.run(query_string=time_based_query_string, output_location='s3://'+s3_bucket_name+'/'+prefix+'/query_results/')
weather_query.wait()
dataset = weather_query.as_dataframe()

注意，你可以进一步微调 Athena 查询以包括 write-time 和 api_call_time 以提取非常具体的特征版本。请参阅参考文献部分，以获取有关 SageMaker Feature Store 中时间点查询的详细博客链接。

此外，当记录从在线存储中删除时，离线存储中的相应记录仅逻辑删除，这通常被称为墓碑。当你查询离线存储时，你可能会在结果中看到墓碑。使用记录的 is_deleted 特征从结果中过滤这些记录。

现在你已经创建了并填充了特征组，你的组织中的团队如何发现和重用这些特征？所有授权的 Amazon SageMaker Feature Store 用户都可以在 SageMaker Studio 环境中查看和浏览特征存储中的特征组列表。你也可以通过名称、描述、记录标识符、创建日期和标签来搜索特定的特征组，如图 图 5.9 所示：

图 5.9 – 搜索和发现特征组

你可以更进一步，查看特征组的特征定义，并如图 图 5.10 所示搜索特定特征：

图 5.10 – 搜索和发现特征

在下一节中，你将了解如何设计一个提供近实时预测的机器学习系统。

设计针对近实时机器学习预测的解决方案

有时机器学习应用需要高吞吐量更新特征和接近实时的更新特征访问。及时访问快速变化的特征对于这些应用预测的准确性至关重要。例如，考虑一个在呼叫中心中的机器学习应用，该应用预测如何将 incoming 客户电话路由到可用的代理。此应用需要了解客户的最新网页会话点击，以便做出准确的路由决策。如果您将客户的网页点击行为作为特征，则特征需要即时更新，并且应用需要接近实时地访问更新后的特征。同样，对于天气预报问题，您可能需要频繁捕获天气测量特征以进行准确的天气预报，并需要实时查找特征的能力。

让我们来看看设计一个满足高吞吐量写入和低延迟读取要求的可靠解决方案的一些最佳实践。从高层次来看，此解决方案将流式摄取与特征组中的流式预测相结合。我们将讨论应用于特征存储的摄取和服务的最佳实践。

对于摄取特征，选择批处理和流式摄取的决定应基于特征存储中的特征值需要多频繁更新以供下游训练或推理使用。虽然简单的机器模型可能需要来自单个特征组的特征，但如果您正在处理来自多个来源的数据，您将发现自己正在使用来自多个特征组的特征。其中一些特征需要定期更新（每小时、每天、每周），而其他特征必须以接近实时的方式流式传输。

特征更新频率和推理访问模式也应作为创建不同特征组和隔离特征的考虑因素。通过隔离需要在不同时间插入的特征，可以独立地提高流式特征的摄取吞吐量。然而，从多个特征组检索值会增加 API 调用的数量，并可能增加整体检索时间。

您的解决方案需要平衡特征隔离和检索性能。如果您的模型在推理时需要来自大量不同特征组的特征，设计解决方案以利用更大的特征组或并行从特征存储中检索以满足预测的近实时服务级别协议。例如，如果您的模型在推理时需要来自三个特征组的特征，您可以在合并这些数据用于模型推理之前并行发出三个 API 调用以获取特征记录数据。这可以通过执行通过 AWS 服务（如AWS Step Functions）的典型推理工作流程来完成。如果相同的特征组总是用于推理，您可能还想考虑将这些特征组合成一个单独的特征组。

图 5.11 展示了支持高吞吐量写入和低延迟读取的流式摄入和流式推理的端到端架构：

![图 5.11 – 实时特征摄入和检索的端到端架构

图 5.11 – 实时特征摄入和检索的端到端架构

在此架构中涉及到的步骤概述如下：

在摄入端：

1. 客户端应用程序收集并处理实时数据。对于流式应用程序，一个选项是使用Kinesis 数据流。为了摄入特征，客户端应用程序调用由 API 网关托管的摄入 API。

2. API 网关调用使用put_record API 将特征推送到在线特征存储的 lambda 函数。根据需要，lambda 函数还可以在将特征推送到特征存储之前对原始数据进行额外的处理。

在预测端：

1. 模型消耗客户端应用程序调用由 API 网关托管的预测 API。API 网关调用一个 lambda 函数，从在线特征存储中查找与推理请求相关的特征，并创建一个增强请求。

2. 增强请求被发送到 SageMaker 部署的端点。端点的预测会回传到客户端应用程序。

使用这些技术和最佳实践，您可以设计实时机器学习系统。

摘要

在本章中，您回顾了 Amazon SageMaker 特征存储的基本功能以及可用的 API。通过结合不同的功能，您学习了如何在单个机器学习项目的训练和推理阶段以及多个机器学习项目中重用工程化特征。最后，您结合了流式摄入和提供来设计近实时推理解决方案。在下一章中，您将使用这些工程化特征在规模上训练和调整机器学习模型。

参考文献

对于额外的阅读材料，请查阅以下参考文献：

• 使用 Amazon SageMaker 特征存储的流式摄入在近实时内做出基于机器学习的决策：

  使用 Amazon SageMaker Feature Store 进行流式摄取以在接近实时的情况下做出基于机器学习的决策

• Enable feature reuse across accounts and teams using Amazon SageMaker Feature Store:

  使用 Amazon SageMaker Feature Store 在账户和团队之间启用特征重用

• Build accurate ML training datasets using point-in-time queries with Amazon SageMaker Feature Store and Apache Spark:

  使用 Amazon SageMaker Feature Store 和 Apache Spark 通过时间点查询构建准确的机器学习训练数据集

• Ingesting historical feature data into Amazon SageMaker Feature Store:

  将历史特征数据摄取到 Amazon SageMaker Feature Store 中

第二部分：模型训练挑战

本节探讨了大规模训练的挑战，包括在使用大型数据集的同时节省成本，监控训练资源以识别瓶颈，加快长时间训练任务，以及跟踪为共同目标训练的多个模型。

本节包括以下章节：

• 第六章, 大规模训练和调优

• 第七章, 使用 Amazon SageMaker Debugger 分析训练作业配置

第六章：大规模训练和调整

机器学习（ML）实践者在进行大规模模型训练和调整时面临多重挑战。规模挑战以大量训练数据、增加的模型大小和模型架构复杂性为形式出现。此外，还需要运行大量调整作业以确定正确的超参数集，并跟踪针对特定机器学习目标使用不同算法进行的多个实验。规模挑战导致训练时间延长、资源受限和成本增加。这可能会降低团队的效率，并可能成为机器学习项目的瓶颈。

Amazon SageMaker提供了托管分布式训练和调整功能，以提高训练效率，并提供了在大规模下组织和跟踪机器学习实验的能力。SageMaker 通过使用管道模式将数据流式传输到算法中，以及通过托管 Spot Training 来降低训练成本，实现了这些技术。管道模式和托管 Spot Training 在 Julien Simon 所著的《学习 Amazon SageMaker：开发者与数据科学家构建、训练和部署机器学习模型的指南》中进行了详细讨论。

在本章中，我们将讨论分布式训练的高级主题、超参数调整的最佳实践以及如何在大规模下组织机器学习实验。到本章结束时，您将能够使用 Amazon SageMaker 的托管功能以经济高效的方式在大规模下进行训练和调整，并跟踪大量训练实验。

在本章中，我们将涵盖以下主要主题：

• 使用 SageMaker 分布式库进行大规模机器学习训练

• 使用 SageMaker 超参数调整进行自动化模型调整

• 使用 SageMaker Experiments 组织和跟踪训练作业

技术要求

您需要 AWS 账户才能运行本章包含的示例。如果您尚未设置数据科学环境，请参阅第二章**，数据科学环境，其中将指导您完成设置过程。

书中包含的代码示例可在 GitHub 上找到，网址为 https://github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter06。您需要安装 Git 客户端才能访问它们（git-scm.com/）。

使用 SageMaker 分布式库进行大规模机器学习训练

机器学习项目中常见的两个规模挑战是扩展训练数据和扩展模型大小。虽然增加训练数据量、模型大小和复杂性可能会使模型更准确，但单个计算节点、CPU 或 GPU 可以使用的最大数据量和模型大小是有限的。增加训练数据量和模型大小通常会导致更多的计算，因此即使使用像 p3 和 p4 这样的强大计算实例，训练作业完成的时间也会更长。

分布式训练是一种常用的技术，用于处理规模挑战时加速训练。训练负载可以分布在多个计算实例（节点）上，或者分布在单个计算实例上的多个 CPU 和 GPU（设备）上。分布式训练有两种策略——数据并行和模型并行。它们的名称很好地说明了每个策略所涉及的内容。在数据并行中，训练数据被分割到多个节点（或设备）上。在模型并行中，模型被分割到节点（或设备）上。

注意

混合精度训练是一种流行的技术，用于处理大规模训练并减少训练时间。通常用于配备 NVIDIA GPU 的计算实例，混合精度训练将网络权重从 FP32 表示转换为 FP16，计算梯度，将权重转换回 FP32，乘以学习率，并最终更新优化器权重。

在数据并行分布策略中，机器学习算法或基于神经网络的模型在所有设备上复制，每个设备处理一批数据。然后，将所有设备的结果合并。在模型并行分布策略中，模型（即神经网络）被分割到各个设备上。将训练数据批次发送到所有设备，以便模型的所有部分都能处理数据。以下图表显示了数据和模型并行的概述：

![图 6.1 – 分布策略

图 6.1 – 分布策略

数据并行和模型并行分布策略都伴随着自己的复杂性。在数据并行中，每个节点（或设备）在数据子集（称为小批量）上训练，并计算小梯度。然而，在节点内部，应该计算并与其他节点通信的小梯度平均值，这些梯度来自其他节点。这一步称为all reduce，它是随着训练集群扩展而增长的通信开销。

当模型并行处理解决模型无法适应单个设备内存的需求时，通过跨设备分割模型，将模型分割到多个 GPU 上可能会导致资源利用率不足。这是因为 GPU 上的训练本质上是顺序的，只有一个 GPU 正在积极处理数据，而其他 GPU 正在等待被激活。为了有效，模型并行处理应与管道执行调度相结合，以跨多个节点训练模型，从而最大化 GPU 利用率。现在你已经知道了两种不同的分布策略，你是如何在这两种策略之间进行选择的？

在数据并行处理和模型并行处理之间进行选择

在选择分布式策略实施时，请记住以下几点：

• 在多个节点上训练固有的会导致节点间通信开销。

• 此外，为了满足安全和监管要求，你可以选择通过启用容器间加密来保护节点间传输的数据。

• 启用容器间加密将进一步增加训练时间。

由于这些原因，如果训练模型可以适应单个设备或节点的内存，则使用数据并行处理。在模型由于大小或复杂性而无法适应内存的情况下，在决定模型并行处理之前，应进一步实验数据并行处理。

你可以通过以下方法来提高数据并行处理性能：

• 调整模型的超参数：调整诸如神经网络层数量或要使用的优化器等参数会显著影响模型的大小。

• 减少批量大小：通过逐步减少批量大小进行实验，直到模型适应内存。这个实验应该平衡模型的内存需求与最优批量大小。确保你不会因为使用大批量大小占用了大部分设备内存而最终得到一个次优的小批量大小。

• 减少模型输入大小：如果模型输入是表格形式，考虑嵌入降维的向量。同样，对于自然语言处理（NLP）模型，减少输入 NLP 序列长度，如果输入是图像，则降低图像分辨率。

• 使用混合精度：实验混合精度训练，在梯度计算期间使用 FP16 表示权重，以减少内存消耗。

以下流程图显示了在选择实施分布策略时应遵循的决策和实验顺序：

图 6.2 – 选择分布策略

当数据并行处理解决训练数据规模挑战时，模型并行处理则应对模型规模和复杂性的增加挑战。可以实施混合分布策略，包括数据和模型并行。图 6.3 将向您展示一个具有双向数据并行和四向模型并行的混合分布策略：

![Figure 6.3 – Hybrid distribution strategy

![img/B17249_06_03.jpg]

图 6.3 – 混合分布策略

扩展计算资源

这两种分布式训练策略都依赖于计算资源集群来分散训练负载。当扩展分布式集群以满足训练需求时，以下为推荐的最佳实践：

• 首先，进行垂直扩展。也就是说，在单个实例上从单个 GPU 扩展到多个 GPU。例如，假设您从一个具有单个 GPU 用于训练模型的 p3.2xlarge 实例开始，并发现自己需要更多的 GPU 来增加训练时间。将实例类型更改为具有八个 GPU 的 p3.16xlarge。这将导致训练时间几乎减少八倍，实现近线性的加速。将训练作业保持在单个扩展后的实例上，比使用多个实例同时保持低成本获得更好的性能。

• 接下来，从单个实例扩展到多个实例。当达到提供的实例类型极限，但仍需要进一步扩展训练时，则使用相同类型的多个实例，即从单个 p3.16xlarge 实例扩展到两个 p3.16xlarge 实例。这将使您获得双倍的计算能力，从单个实例上的 8 个 GPU 增加到两个实例上的 16 个 GPU。请注意，当您在训练集群中使用多个实例时，所有实例应位于相同的 us-west-2 区域，必须全部位于 us-west-2a 或全部位于 us-west-2b。您的训练数据也应位于同一区域，us-west-2。

当从单个实例迁移到多个实例时，建议您观察模型收敛情况，并在必要时增加批大小。由于您使用的批大小是在 GPU 之间分割的，每个 GPU 处理的批大小较低，这可能导致高错误率并破坏模型收敛。

例如，假设您从一个 p3.2xlarge 实例上的单个 GPU 开始，使用 64 的批大小，然后扩展到四个 p3dn.24xlarge 实例，这为您提供了 32 个 GPU。在此迁移之后，每个 GPU 只处理 2 个批次的任务，这很可能破坏您在原始训练中观察到的模型收敛。

SageMaker 分布式库

为了在训练作业中轻松实现数据和模型并行，SageMaker 提供了两个不同的分布式训练库。这些库通过软件和硬件技术的组合解决了节点间和 GPU 间通信开销的问题。为了实现分布式库并利用数据和模型并行，您需要修改训练脚本中的少量代码。

重要提示

在本书出版时，SageMaker 分布式库支持两个框架——TensorFlow和PyTorch。

虽然在本章中我们专注于 SageMaker 原生的分布式训练库，您也可以选择使用最受欢迎的开源分布式训练框架Horovod，或者使用 TensorFlow 和 PyTorch 等框架的本地分布式训练策略。请参阅参考文献部分的博客链接，了解如何在 SageMaker 上使用 Horovod 与 TensorFlow 的详细信息。

SageMaker 分布式数据并行库

让我们先深入了解 SageMaker 分布式数据并行库。

SageMaker 分布式数据并行库提供了在深度学习模型上实现接近线性扩展效率和快速训练时间的能力。该库通过两种方法解决了分布式集群中通信开销的挑战：

• 它自动执行负责开销的AllReduce操作。

• 它通过利用 AWS 的网络基础设施和 Amazon EC2 实例拓扑结构来优化节点间的通信。

SageMaker 数据并行可以在单节点多设备设置和多节点设置中使用。然而，它在训练包含两个或更多节点的集群时价值更为明显。在这个多节点集群中，作为库一部分实现的AllReduce操作为您提供了显著的性能提升。

要使用 SageMaker 训练作业中的分布式库，首先在构建estimator对象时启用您想要的策略。以下代码块展示了如何使用启用数据并行策略的PyTorch容器创建estimator对象：

from sagemaker.pytorch import PyTorch

pt_dist_estimator = PyTorch(
                entry_point="train_pytorch_dist.py",
               … 
              distribution={
                    "smdistributed": {"dataparallel": {"enabled": True}}
              }
)

此外，在这个例子中，训练脚本train_pytorch_dist还需要进行一些修改。接下来的几个代码块展示了需要修改的训练脚本：

1. 首先，导入并初始化 SageMaker 分布式库：

   import smdistributed.dataparallel.torch.distributed as dist
   from smdistributed.dataparallel.torch.parallel.distributed import DistributedDataParallel as DDP
   dist.init_process_group()
   

2. 接着，使用local_rank将每个 GPU 固定到单个 SageMaker 数据并行库进程，local_rank是在给定节点内进程的相对排名：

   torch.cuda.set_device(dist_get_local_rank())
   

3. 接着，调整每个工作器处理的批大小：

   batch_size //= dist.get_world_size()
   batch_size = max(batch_size, 1)
   

4. 接着，使用分布式库中的DDP类包装训练好的模型工件：

   model = DDP(model)
   

5. 最后，一旦所有修改都到位，只需在估计器上调用fit()方法即可启动训练，使用训练脚本：

   pt_dist_estimator.fit()
   

为了观察分布式训练的好处，我们在同一数据集上运行了两个不同的训练任务。这两个任务都在单个ml.p3.16xlarge上运行，第一个任务没有启用分布式训练，第二个任务启用了smdistributed dataparallel。在这个实验中，第一个任务耗时 12041 秒完成，第二个任务耗时 4179 秒完成，从而在训练时间上提高了 65.29%。

注意

在 GitHub 仓库中的笔记本中记录了启用和未启用smdistributed dataparallel的两种训练任务的比较：gitlab.com/randydefauw/packt_book/-/blob/main/CH05/train-distributed.ipynb。

SageMaker 分布式模型并行库

接下来，让我们看看 SageMaker 分布式模型并行库。这个库提供了训练大型、复杂的深度学习模型的能力，这可能会提高预测精度。该库自动且高效地将模型分割到多个 GPU 上，提供了手动和自动分区选项。它进一步通过构建高效的计算调度来协调训练，使得不同的节点可以同时为不同的数据样本执行前向和反向传递。

下面的代码块展示了使用启用模型并行的PyTorch容器创建一个estimator对象：

mpi_options = {
    "enabled": True,
   "processes_per_host": 4
  }

dist_options = {
    "modelparallel":{
       "enabled": True,
       "parameters": {
           "partitions": 4,  # we'll partition the model among the 4 GPUs 
           "microbatches": 8,  # Mini-batchs are split in micro-batch to increase parallelism
           "optimize": "memory" # The automatic model partitioning can optimize speed or memory
           }
       }
}
pt_model_dist_estimator = PyTorch(
    entry_point="train_pytorch_model_dist.py",
    ...
    distribution={"mpi": mpi_options, "smdistributed": dist_options}
)

与数据并行策略一样，训练脚本需要进行一些代码更改。重要的更改将在接下来的几个代码块中讨论：

1. 首先，导入并初始化 SageMaker 分布式库：

   import smdistributed.modelparallel.torch as smp
   smp.init()
   

2. 接下来，将模型工件包装在分布式库中的DistributedModel类中，并将优化器包装在DistributedOptimizer类中：

   model = smp.DistributedModel(model)
   optimizer = smp.DistributedOptimizer(optimizer)
   

3. 接下来，将前向和反向逻辑添加到一个函数中，并用smp.step进行装饰：

   @smp.step
   def train_step(model, data, target):
       output = model(data)
       long_target = target.long()
       loss = F.nll_loss(output, long_target, reduction="mean")
       model.backward(loss)
       return output, loss
   

4. 最后，在estimator对象上调用fit()方法以启动训练：

   pt_dist_estimator.fit()
   

   重要提示

   在 GitHub 仓库中提供了一个示例笔记本，它详细介绍了如何使用ModelParallel分布策略与 PyTorch 容器一起使用：gitlab.com/randydefauw/packt_book/-/blob/main/CH06/train.ipynb。

虽然 SageMaker 分布式模型并行库使得实现模型并行分布式训练变得容易，但要获得最佳的训练结果，请考虑以下最佳实践：

• 使用手动分区与自动分区：你可以使用手动或自动分区将模型分区到多个节点（或设备）。虽然两种方法都受支持，但你应该选择自动分区而不是手动方法。使用自动分区时，训练操作和共享相同参数的模块将自动放置在相同的设备上以确保正确性。使用手动方法时，你必须注意如何分割模型部分以及哪个部分应该放置在哪个设备上。这是一个耗时且容易出错的过程。

• 选择批次大小：模型并行库在大型批次大小下效率最高。如果你开始时使用较小的批次大小以将模型放入单个节点，然后决定在多个节点上实现模型并行，你应该相应地增加批次大小。模型并行可以节省大型模型的内存，允许使用大型批次大小进行训练。

• 选择微批次的数量和大小：模型并行库在每个节点或设备上顺序执行每个微批次。因此，微批次的大小应该足够大，以便充分利用每个 GPU。同时，随着微批次数量的增加，管道效率也会提高，因此平衡两者很重要。

最佳实践是从两个或四个微批次开始，并根据节点/设备的可用内存增加批次大小。然后尝试更大的批次大小，并增加微批次数量。随着微批次数量的增加，如果使用交错管道，更大的批次大小可能变得可行。

逐步训练

当在训练模型之前就已经有大量数据可用时，应该使用分布式训练策略。但是，当模型部署后，你收集了可能改进模型预测的新数据时会发生什么？在这种情况下，你可以从现有模型的工件开始，使用扩展的数据集逐步训练一个新的模型。

逐步训练可以在以下情况下节省训练时间、资源和成本：

• 一个现有模型表现不佳，并且有新的数据可用，这些数据有可能提高模型性能。

• 你希望将公开可用的模型作为你模型的起点，而无需从头开始训练。

• 你希望训练多个版本的模型，这些模型要么具有不同的超参数，要么使用不同的数据集。

• 你希望重新启动之前停止的训练作业，而无需再次从头开始。

此外，为了补充或替代加载现有模型权重和逐步训练，你可以在最近的数据上滑动窗口重新训练。

在本节中，您学习了如何使用 SageMaker 功能进行大量数据和复杂模型架构的训练。除了训练数据和模型架构之外，ML 训练的一个关键部分是调整 ML 算法的超参数。在下一节中，您将学习使用 SageMaker 进行大规模模型调优的最佳实践。

使用 SageMaker 超参数调优进行自动化模型调优

超参数调优（HPT）帮助您找到与您的 ML 算法或神经网络一起使用的正确参数，以找到模型的最佳版本。Amazon SageMaker 支持托管超参数调优，也称为 自动模型调优。在本节中，我们将讨论在 Amazon SageMaker 上配置超参数作业时应考虑的最佳实践。

要执行 SageMaker 超参数调优作业，您需要指定一组超参数、每个超参数要探索的值范围以及用于衡量模型性能的目标指标。自动调优会在您的训练数据集上执行多个训练作业，使用 ML 算法和超参数值，以目标指标衡量找到最佳性能的模型。

在下面的代码块中，我们将看到如何在 SageMaker 上创建一个 HPT 作业：

1. 首先，初始化您想要探索的每个超参数的名称和值范围：

   from sagemaker.tuner import (
    IntegerParameter,
    CategoricalParameter,
    ContinuousParameter,
    HyperparameterTuner, 
   ) 
   hyperparameter_ranges = { 
    "eta": ContinuousParameter(0, 1),
    "min_child_weight": ContinuousParameter(1, 10),
    "alpha": ContinuousParameter(0, 2), 
    "max_depth": IntegerParameter(1, 10)
   }
   

2. 接下来，配置 SageMaker estimator 对象：

   estimator_hpo = \ sagemaker.estimator.Estimator( 
   image_uri=xgboost_container, 
   hyperparameters=hyperparameters, 
   role=sagemaker.get_execution_role(), 
   instance_count=1, 
   instance_type='ml.m5.12xlarge', 
   volume_size=200, # 5 GB 
   output_path=output_path 
   ) 
   

3. 接下来，配置 HyperparameterTuner 对象：

   tuner = HyperparameterTuner(
                estimator_hpo, 
        objective_metric_name,
        hyperparameter_ranges, 
        max_jobs=10,
        max_parallel_jobs=2,
        objective_type = 'Minimize'
   )
   

4. 最后，在 tuner 对象上调用 fit() 方法：

   tuner.fit({'train': train_input, 
              'validation': validation_input})
   

一旦超参数作业完成，您可以在 图 6.4 中查看 SageMaker 执行的不同训练作业，以及每个作业的目标指标：

图 6.4 – SageMaker HPT 结果

您可以进一步深入了解每个训练作业，查看使用的超参数的确切值，如图 6.5 所示：

图 6.5 – 特定训练作业的超参数值

重要提示

在 GitHub 仓库中提供了一个示例笔记本，它提供了使用 SageMaker HPT 的完整教程，以及结果分析：gitlab.com/randydefauw/packt_book/-/blob/main/CH05/HPO.ipynb。

现在您已经了解了基础知识，让我们讨论在 Amazon SageMaker 上配置超参数作业时应考虑的一些最佳实践：

• 选择少量超参数：HPT 是一个计算密集型任务，其计算复杂性与您想要调整的超参数数量成正比。SageMaker 允许您为调优作业指定最多 20 个超参数进行优化，但将搜索范围限制在更小的数量可能会给您带来更好的结果。

• 为超参数选择小范围：同样，超参数的值范围可以显著影响超参数优化的成功。直观上，你可能想指定一个非常大的范围来探索超参数的所有可能值，但实际上，通过限制搜索到小范围的值，你会得到更好的结果。

• train_batch_size 超参数，而不是以线性方式探索一个范围，你可能只想评估两个值——128 和 256。在这种情况下，你将参数视为一个分类值。相比之下，如果你想探索 train_batch_size 超参数的范围，从最小阈值值 128 到最大阈值值 256，你将使用 Integer 类型。Integer 类型允许对范围进行更广泛的探索。

  如果你搜索的范围跨越几个数量级，你可以通过为 Integer 超参数选择对数尺度来优化搜索。最后，如果所有要探索的值的范围（从最低到最高）相对较小，请选择连续参数。例如，在 0.0001 和 0.0005 的范围内以线性尺度探索 learning_rate 超参数。

• 启用预热启动：SageMaker HPT 支持预热启动，它将重用先前调优作业的结果作为起点。配置你的 HPT 作业使用预热启动以限制新调优作业中要搜索的超参数组合。这导致调优作业更快。预热启动在你想更改先前作业的 HPT 范围或添加新超参数时特别有用。

• 启用早期停止以节省调优时间和成本：启用早期停止后，由 HPT 作业启动的个别训练作业将在目标指标没有显著改善时提前终止。在每个训练周期后，确定所有之前训练作业到同一周期的目标指标的运行平均值，并计算运行平均值的中间值。如果当前训练作业的目标指标值比中间值差，SageMaker 将停止当前训练作业。

  提前停止作业可以减少总体计算时间，从而降低作业成本。另一个好处是，早期停止有助于防止过拟合。

• MaxParallelTrainingJobs 参数。一方面，同时运行更多的 HPT 作业可以快速完成调优作业。另一方面，调优作业只能通过连续的实验轮次找到更好的超参数组合。从长远来看，一次执行一个训练作业可以获得最佳结果，同时计算时间最短。

  当 SageMaker HPO 使用默认的贝叶斯优化调优策略时，情况就是这样。然而，如果您对您的算法和数据集有经验，您也可以使用 SageMaker 原生支持的随机搜索策略，因为它可以实现并发，但不需要进行实验的串行轮次。

虽然在本节中我们专注于单个算法的最佳实践，但CreateHyperParameterTuningJob API 也可以通过提供指向不同算法的多个训练作业定义来调整多个算法。有关此 API 的详细说明，请参阅以下文章：docs.aws.amazon.com/sagemaker/latest/APIReference/API_CreateHyperParameterTuningJob.html。

在下一节中，您将学习如何跟踪与解决特定问题相关的所有机器学习实验。

使用 SageMaker Experiments 组织和跟踪训练作业

机器学习从业者面临的一个关键挑战是跟踪在模型达到预期结果之前需要执行的众多机器学习实验。对于单个机器学习项目来说，数据科学家通常需要定期训练几个不同的模型以寻找提高准确度的方法并不罕见。HPT 向这些实验添加了更多的训练任务。通常，实验有许多细节需要跟踪，如超参数、模型架构、训练算法、自定义脚本、指标、结果工件等。

在本节中，我们将讨论Amazon SageMaker Experiments，它允许您在机器学习生命周期的所有阶段组织、跟踪、可视化和比较机器学习模型，包括特征工程、模型训练、模型调优和模型部署。SageMaker Experiments 的功能可以跟踪模型血缘，让您能够排查生产问题并审计您的模型以满足合规性要求。

构成 Amazon SageMaker Experiments 的基本组件包括一个实验、一个试验、一个试验组件和一个跟踪器，如图 6.6 所示：

图 6.6 – Amazon SageMaker Experiments 概览

让我们看看每个组件：

• 实验: 实验封装了代表您试图解决的机器学习问题的所有相关组件。每个实验是一系列试验的集合，目标是确定产生最佳模型的试验。

• 试验: 试验代表了解决机器学习问题的一次尝试，它在一个实验中捕捉了端到端的机器学习过程。每个试验由几个试验组件组成。

• 试验组件: 试验组件代表给定试验中的特定步骤。例如，数据预处理步骤可以是其中一个试验组件，而模型训练可以是另一个试验组件。

• Tracker：Tracker 用于跟踪单个试验组件的元数据，包括所有参数、输入、输出、工件和指标。由于这些元数据被跟踪和持久化，你可以将最终模型工件与其来源链接起来。

在以下代码块中，我们将看到如何创建 SageMaker 实验：

1. 首先，创建一个实验：

   weather_experiment = Experiment.create(
       experiment_name=f"weather-experiment-{int(time.time())}",  
       description="Weather Data Prediction", 
       sagemaker_boto_client=sm)
   

2. 接下来，创建一个Tracker实例以跟踪训练阶段：

   with Tracker.create(display_name="Training", sagemaker_boto_client=sm) as tracker:
       # Log the location of the training dataset
       tracker.log_input(name="weather-training-dataset", 
     media_type="s3/uri", 
    value="s3://{}/{}/{}/".format(s3_bucket, s3_prefix, 'train')) 
   

   接下来，定义实验变量以定义你想要更改的内容，以了解你的目标是如何受到影响的。在这个例子中，我们将对XGBoostmodel的max_depth超参数的几个值进行实验。我们将创建一个试验来跟踪每个训练作业的运行。

   我们还将从之前创建的Tracker实例创建一个TrialComponent实例，并将其添加到Trial实例中。这将允许你捕获训练步骤的指标，如下所示：

   for i, max_depth in enumerate([2, 5]):
       # create trial
       trial_name = f"xgboost-training-job-trial-{max_depth}-max-depth-{int(time.time())}"
       xgboost_trial = Trial.create(
           trial_name=trial_name, 
           experiment_name=weather_experiment.experiment_name,
           sagemaker_boto_client=sm,
       )
       max_depth_trial_name_map[max_depth] = trial_name
   
       xgboost_training_job_name = "xgboost-training-job-{}".format(int(time.time()))
   
   

3. 当使用fit()方法运行训练作业时，将estimator与实验和试验关联起来：

   # Now associate the estimator with the Experiment and Trial
       estimator.fit(
           inputs={'training': train_input}, 
           job_name=xgboost_training_job_name,
           experiment_config={
               "TrialName": xgboost_trial.trial_name,
               "TrialComponentDisplayName": "Training",
           },
           wait=False,
       )
   

4. 最后，在实验完成后，让我们分析实验结果：

   trial_component_analytics = \ ExperimentAnalytics(sagemaker_session=sagemaker_session, experiment_name=experiment_name ) 
   trial_component_analytics.dataframe()
   

图 6.7 显示了作为实验一部分创建的所有试验组件列表：

![图 6.7 – 实验中的试验组件

图 6.7 – 实验中的试验组件

如你所见，SageMaker 实验为你提供了一种组织你向机器学习目标努力的方法，并允许你了解这些努力的几个重要方面。我们推荐的一个最佳实践是，每次你启动训练或调优作业时，都将其包裹在一个实验中。这样，你可以在没有任何额外成本的情况下获得对训练和调优作业的可见性。

重要注意事项

GitHub 仓库中提供了一个示例笔记本，提供了使用 SageMaker Experiments 的完整教程：gitlab.com/randydefauw/packt_book/-/blob/main/CH05/Experiments.ipynb。

摘要

在本章中，你学习了使用不同分布策略在规模上训练模型所需的高级技术。你进一步了解了超参数调优的最佳实践，以找到满足你目标的最佳模型版本。你学习了如何在典型的机器学习工作流程中组织和管理多个实验，并创建比较报告。

使用本章中讨论的 SageMaker 功能和最佳实践，你可以处理大规模机器学习，使你的组织摆脱实验阶段。你可以利用多年来收集的大量数据集，并朝着实现机器学习的全部好处迈进。在下一章中，你将继续通过使用Amazon SageMaker 调试器来分析训练作业来增强机器学习训练。

参考文献

如需阅读更多参考资料，请查阅以下内容：

• 学习 Amazon SageMaker：开发者与数据科学家构建、训练和部署机器学习模型的指南:

  https://www.amazon.com/Learn-Amazon-SageMaker-developers-scientists/dp/180020891X/ref=sr_1_1?dchild=1&keywords =Learn+Amazon+SageMaker+%3A+A+guide+to+building%2C+training%2C+and+deploying+machine+learning+models+for +developers+and+data+scientists&qid=1624801601&sr=8-1

• 在 Amazon SageMaker Pipe 模式下使用 Horovod 进行多 GPU 和分布式训练:

  aws.amazon.com/blogs/machine-learning/multi-gpu-and-distributed-training-using-horovod-in-amazon-sagemaker-pipe-mode/

• 使用 Amazon SageMaker Studio 和 Amazon Experiments SDK 简化建模:

  https://aws.amazon.com/blogs/machine-learning/streamline-modeling-with-amazon-sagemaker-studio-and-amazon-experiments-sdk

第七章：使用 Amazon SageMaker Debugger 分析训练作业

训练 机器学习（ML）模型涉及对多个算法进行实验，它们的超参数通常需要处理大量数据。训练出最优结果的模型是一项既耗时又耗计算的任务。提高训练时间可以提高生产力并降低整体训练成本。

如我们在第六章“大规模训练和调优”中讨论的，分布式训练通过使用可扩展的计算集群来显著提高训练时间。然而，监控训练基础设施以识别和调试资源瓶颈并非易事。一旦启动了训练作业，整个过程就变得不透明，你对模型训练过程几乎没有可见性。同样不简单的是实时监控以检测次优训练作业并在早期停止它们，以避免浪费训练时间和资源。

Amazon SageMaker Debugger 提供了对训练作业及其执行的基础设施的可见性。SageMaker Debugger 捕获的实时训练指标，如学习梯度和网络权重，为正在进行的训练作业提供了可见性，因此你可以对梯度消失和过拟合等条件采取行动。

Debugger 还监控并提供有关系统资源（如 CPU、GPU 和内存）的报告，为你提供资源利用率和瓶颈的见解。此外，如果你使用 TensorFlow 或 PyTorch 进行深度学习训练作业，Debugger 提供了框架指标的可视化，这些指标可用于加速你的训练作业。

到本章结束时，你将能够使用 Amazon SageMaker Debugger 的功能，并应用最佳实践来解决调试 ML 训练的典型挑战。这些挑战包括识别和应对次优训练、了解训练基础设施的资源利用率，以及优化训练框架参数。你还将学习如何通过应用 SageMaker Debugger 提供的详细建议来提高训练时间和成本。

在本章中，我们将涵盖以下主要主题：

• Amazon SageMaker Debugger 精要

• 使用内置和自定义规则实时监控训练作业

• 了解训练基础设施和训练框架

技术要求

你需要 AWS 账户来运行本章中包含的示例。如果你还没有为本书设置数据科学环境，请参阅第二章“数据科学环境”，其中将指导你完成设置过程。

本书包含的代码示例可在 GitHub 上找到 github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter07。要访问它们，您需要安装 Git 客户端 (git-scm.com/)。

Amazon SageMaker Debugger 基础知识

在本节中，你将了解 Amazon SageMaker Debugger 的基本术语和功能。使用 Debugger 与你的训练作业涉及三个高级步骤：

1. 配置训练作业以使用 SageMaker Debugger。

2. 分析收集到的张量和指标。

3. 采取行动。

以下图示说明了前面的要点：

![图 7.1 – Amazon SageMaker Debugger 概览

图 7.1 – Amazon SageMaker Debugger 概览

当我们深入到这些步骤中的每一个时，我们将介绍必要的术语。

配置训练作业以使用 SageMaker Debugger

第一步是配置训练作业以使用 Amazon SageMaker Debugger。到目前为止，你已经熟悉了使用 SageMaker SDK 中的 Estimator 对象来启动训练作业。要使用 Amazon SageMaker Debugger，你必须通过三个额外的配置参数增强 Estimator：DebuggerHookConfig、Rules 和 ProfilerConfig。

使用 DebuggerHookConfig，你可以指定要收集哪些调试指标以及将它们存储在哪里，如下面的代码块所示：

Estimator(
    …
    debugger_hook_config=DebuggerHookConfig(
        s3_output_path=bucket_path,  # Where the debug data is stored.
        collection_configs=[ # Organize data to collect into collections.
            CollectionConfig(
                name="metrics",
                parameters={
                    "save_interval": str(save_interval)
                }
            )
        ],
    ),
    ….
)

s3_output_path 是所有收集到的数据持久化的位置。如果未指定此位置，调试器将使用默认路径，s3://<output_path>/debug-output/，其中 <output_path> 是 SageMaker 训练作业的输出路径。CollectionConfig 列表允许您将调试数据或张量组织成集合，以便更容易分析。张量表示训练网络在训练过程中特定时间的状态。数据按照 save_interval 指定的间隔收集，save_interval 是训练运行中的步数。

你如何知道要收集哪些张量？SageMaker Debugger 随带一组内置集合来捕获常见的训练指标，如 weights、layers 和 outputs。你可以选择收集所有可用的张量或它们的子集。在先前的代码示例中，调试器正在收集 metrics 集合。

注意

对于内置集合的完整列表，请参阅 github.com/awslabs/sagemaker-debugger/blob/master/docs/api.md#collection。

你还可以创建一个自定义的指标集合来收集。在下面的代码块中，调试器捕获所有名称中包含 relu、tanh 或 weight 的指标：

# Use Debugger CollectionConfig to create a custom collection
collection_configs=[
        CollectionConfig(
            name="custom_collection",
            parameters={
                "include_regex": ".*relu |.*tanh | *weight ",
        })
]

注意

虽然收集所有张量可能很有吸引力，但这会导致收集大量数据，从而增加训练时间、训练成本和存储成本。在这种情况下，使用 ReductionConfig 允许您保存减少后的张量而不是保存完整的张量 (github.com/awslabs/sagemaker-debugger/blob/master/docs/api.md#collection)。

虽然 DebuggerHookConfig 允许您配置和保存张量，但规则会分析训练过程中捕获的张量以检查特定条件，例如 损失未减少。SageMaker Debugger 支持两种不同类型的规则：内置 和 自定义。SageMaker Debugger 随带一组内置规则，这些规则可以用 Python 检测并报告常见的训练问题，如过拟合、欠拟合和梯度消失。使用自定义规则，您可以在 Python 中编写自己的规则，以便 SageMaker Debugger 对收集到的张量进行评估。

例如，在下面的代码块中，调试器收集与 metrics 收集相关的张量，并评估张量以检测训练过程中的损失是否减少：

Estimator(
    …
    rules=[
        Rule.sagemaker(
            rule_configs.loss_not_decreasing(),
            rule_parameters={
                "collection_names": "metrics",
                "num_steps": str(save_interval * 2),
            },
        ),
    ],
)

最后，ProfilerConfig 允许您收集系统指标，例如 CPU、GPU、内存、I/O 以及您在训练作业中使用的框架的特定框架指标。对于系统指标，您必须指定要收集指标的时长间隔，而对于框架指标，您指定起始步数和步数，如下面的代码块所示：

Estimator(
    …
    profiler_config = ProfilerConfig(
        ## Monitoring interval in milliseconds
     system_monitor_interval_millis=500,       ## Start collecting metrics from step 2 and collect from the next 7 steps.
      framework_profile_params=FrameworkProfile(
    start_step=2, 
    num_steps=7
)     )

下表总结了 SageMaker 收集的张量和指标。它显示了不同类型的指标、每种类型的示例以及如何收集和使用它们：

![图 7.2 – SageMaker Debugger 收集的张量和指标

![img/011.jpg]

图 7.2 – SageMaker Debugger 收集的张量和指标

使用这些配置参数，SageMaker Debugger 收集了大量关于您的训练作业的信息。但您如何确保收集的数据是安全的？

最佳实践是对 S3 存储桶中的所有数据进行加密，无论是使用 AWS 提供的密钥还是您自己的具有 客户管理密钥（CMK）的密钥。此外，已配置的规则在隔离的调试器规则容器中执行。规则容器也在与训练作业相同的 VPC 中执行，并使用训练作业使用的 IAM 角色。

一旦您对调试器配置满意，就可以使用 estimator.fit() 启动训练。接下来，我们将分析调试器在训练作业期间收集的信息。

分析收集到的张量和指标

在训练过程中收集的所有张量和指标都保存在 S3 中。SageMaker 调试器使用trial对象来表示单个训练运行。trial对象由多个步骤组成，其中每个步骤代表单个批次的训练数据。在每一步中，收集到的张量具有特定的值。

要访问张量值，您从估计器获取张量的路径，创建一个试验，获取张量列表，找出您感兴趣的具体张量的数据所在的步骤，并查看张量的值。

通过从试验到单个张量值的路径，您可以手动查询张量值，如下面的代码块所示：

tensors_path = estimator.latest_job_debugger_artifacts_path()
print('S3 location of tensors is: ', tensors_path)
trial.tensor_names()
trial.tensor("feature_importance/cover/f1").values()

您可以通过在笔记本中使用自定义绘图代码进一步可视化收集到的张量值。以下图表显示了train-rmse和validation-rmse训练指标的可视化，这些指标是在训练过程中收集的：

![图 7.3 – 训练和验证错误

图 7.3 – 训练和验证错误

注意，您还可以在 SageMaker Studio 中查看可视化。此外，如果您已配置规则，调试器将自动分析张量以评估训练条件并触发云监控警报。同样，当您设置ProfileConfig参数时，将生成详细的分析报告并保存在 S3 中。接下来，让我们看看如何对规则结果采取行动。

采取行动

规则评估收集的张量数据。由于规则评估的状态在训练过程中发生变化，将触发 CloudWatch 事件。您可以为 CloudWatch 事件配置 CloudWatch 规则，以自动化对规则发现的问题的响应。

此外，您还可以使用调试器内置的操作来自动化响应。以下代码块显示了如何使用调试器内置规则和操作的组合来在训练过程中损失值没有持续降低时停止训练作业：

built_rules=[
        #Check for loss not decreasing during training and stop the training job.
        Rule.sagemaker(
            rule_configs.loss_not_decreasing(),
            actions = (rule_configs.StopTraining())
        )
]

另一方面，当您已配置ProfilerConfig参数时，将生成一个包含系统指标和框架指标详细分析的分析报告，并持久化存储在 S3 中。您可以从 S3 下载、审查并将建议应用于分析报告。

在接下来的两个部分中，您将学习如何自动化对规则评估的响应并实施分析报告中的建议。

使用内置和自定义规则实时监控训练作业

在本节中，您将使用调试器功能来监控带有内置和自定义规则的作业，以检测次优训练条件，例如LossNotDecreasing和ExplodingGradients。

SageMaker 提供了一套内置规则来识别常见的训练问题，例如class_imbalance、loss_no_decreasing和overfitting。

注意

SageMaker 内置规则的完整列表可以在此处访问：docs.aws.amazon.com/sagemaker/latest/dg/debugger-built-in-rules.html。

以下代码示例展示了如何使用 SageMaker Debugger 配置内置规则：

#Specify the rules you want to run
built_in_rules=[
        #Check for loss not decreasing during training and stop the training job.
        Rule.sagemaker(
            rule_configs.loss_not_decreasing(),

            actions = (rule_configs.StopTraining())
        ),
        #Check for overfit, overtraining and stalled training
        Rule.sagemaker(rule_configs.overfit()),  
   Rule.sagemaker(rule_configs.overtraining()),       
   Rule.sagemaker(rule_configs.stalled_training_rule())     
]
#Create an estimator and pass in the built_in rules.
pt_estimator = PyTorch(
    ...
    rules = built_in_rules
)

在调用 fit 之后，SageMaker 为每个配置的内置规则启动一个训练作业和一个处理作业。规则评估状态在 CloudWatch 的训练日志中以固定间隔可见。你还可以使用以下命令以编程方式查看规则执行的结果：

pt_estimator.latest_training_job.rule_job_summary()

已配置的内置规则的结果应类似于以下内容：

图 7.4 – 内置规则执行摘要

通过分析规则摘要，你可以看到LossNotDecreasing规则被触发，如RuleEvaluationStatus中的IssuesFound所示。由于配置的操作用于停止训练作业，你将注意到训练作业在执行所有 epoch 之前就已经停止。你还可以看到其他内置规则——Overfit、Overtraining和StalledTrainingRule——在训练过程中没有被触发。

内置规则由 AWS 管理，从而免去了你需要管理规则更新的麻烦。你只需将它们插入到估计器中即可。然而，你可能想监控内置规则中未包含的指标，在这种情况下，你必须配置自定义规则。自定义规则需要更多的工作。例如，假设你希望在训练过程中跟踪梯度是否变得过大。为了创建这个自定义规则，你必须扩展 SageMaker Debugger 提供的Rule接口。

注意

SageMaker 为规则提供了两套 Docker 镜像：一套用于评估内置规则，另一套用于评估自定义规则。这些 Docker 镜像的弹性容器注册库（ECR）URL 可在docs.aws.amazon.com/sagemaker/latest/dg/debugger-docker-images-rules.html找到。

在以下示例中，自定义规则将与使用gradients收集收集的张量一起工作。invoke_at_step方法提供了要执行的逻辑。在每一步中，梯度值的平均值与阈值进行比较。如果梯度值大于阈值，则触发规则，如下面的代码所示：

class CustomGradientRule(Rule):
    def __init__(self, base_trial, threshold=10.0):
        super().__init__(base_trial)
        self.threshold = float(threshold)
    def invoke_at_step(self, step):
        for tname in self.base_trial.tensor_names(collection="gradients"):
            t = self.base_trial.tensor(tname)
            abs_mean = t.reduction_value(step, "mean", abs=True)
            if abs_mean > self.threshold:
                return True
        return False

接下来，定义自定义规则，如下所示：

custom_rule = Rule.custom(
    name='CustomRule', # used to identify the rule
    # rule evaluator container image
image_uri='759209512951.dkr.ecr.us-west-2.amazonaws.com/sagemaker-debugger-rule-evaluator:latest',    instance_type='ml.t3.medium',     source='rules/my_custom_rule.py', # path to the rule source file
    rule_to_invoke='CustomGradientRule', # name of the class to invoke in the rule source file
    volume_size_in_gb=30, # EBS volume size required to be attached to the rule evaluation instance
    collections_to_save=[CollectionConfig("gradients")],
    # collections to be analyzed by the rule. since this is a first party collection we fetch it as above
    rule_parameters={
       #Threshold to compare the gradient value against
      "threshold": "20.0"     }
)

在估计器中配置自定义规则并调用fit方法，如下所示：

pt_estimator_custom = PyTorch(
    ….
    ## New parameter
    rules = [custom_rule]
)
estimator.fit(wait = False)

在调用 fit 之后，Amazon SageMaker 会为每个配置的客户规则启动一个训练作业和一个处理作业。规则评估状态会在 CloudWatch 的训练日志中以固定的时间间隔可见。类似于 built_in 规则的规则摘要，您可以使用以下代码查看自定义规则摘要：

pt_estimator.latest_training_job.rule_job_summary()

通过结合内置和自定义规则，您可以深入了解训练过程，并主动停止训练作业，而无需运行无效的训练作业直到完成。

重要提示

在以下 GitHub 仓库中提供了一个示例笔记本，该笔记本提供了使用 SageMaker 调试器的内置和自定义规则的全过程指南：gitlab.com/randydefauw/packt_book/-/blob/master/CH06/debugger/weather-prediction-debugger-rules.ipynb。

在本节中，您对训练过程有了深入了解，并根据内置和自定义规则检测到的问题改进了训练作业。在下一节中，您将学习如何深入了解用于训练作业的基础设施和框架。

深入了解训练基础设施和训练框架。

在本节中，您将学习如何了解训练基础设施和训练框架的资源利用率。您还将学习如何分析和实施 SageMaker 调试器深度分析功能提供的建议。

调试器分析器为您提供对在 SageMaker 上运行机器学习训练作业的基础设施利用情况的可见性。调试器自动监控系统资源，如 CPU、GPU、网络、I/O 和内存。此外，调试器收集针对训练框架的特定指标，如步骤持续时间、数据加载、预处理以及在 CPU 和 GPU 上的算子运行时间。您可以选择对整个训练作业进行分析，或者只对其部分进行分析以收集必要的框架指标。

除了收集系统和框架指标之外，在幕后，调试器会自动关联这些指标，这使得您能够轻松地识别可能存在的资源瓶颈并执行根本原因分析。

让我们通过我们的示例用例——使用 PyTorch 预测天气——来详细探讨这个问题。在这里，我们将探索系统指标、由分析器生成的框架指标，并查看实施分析器提出的建议。这种对训练作业的深度分析包括以下高级步骤：

1. 在启用调试器的情况下，使用 PyTorch 模型进行天气预测训练。

2. 分析和可视化由分析器生成的系统和框架指标。

3. 分析由 SageMaker 调试器生成的分析器报告。

4. 检查并实施分析器报告中的建议。

5. 比较训练作业。

让我们详细查看每个步骤。

训练用于天气预测的 PyTorch 模型

首先，我们将使用 PyTorch 框架训练一个深度学习模型。由于数据量庞大和深度学习框架，我们将在 GPU 实例上训练。我们将在两个ml.p3.2xlarge实例上训练。我们的基础设施配置将如下所示：

…
train_instance_type = "ml.p3.2xlarge" 
instance_count = 2

接下来，让我们定义ProfilerConfig，以便它可以收集系统和框架指标：

profiler_config = ProfilerConfig(
    system_monitor_interval_millis=500,
    framework_profile_params=FrameworkProfile(start_step=2, num_steps=7)
)

现在，我们必须通过使用基础设施和配置分析器作为参数来配置 PyTorch 估计器：

pt_estimator = PyTorch(
    entry_point="train_pytorch.py",
    source_dir="code",
    role=sagemaker.get_execution_role(),
    instance_count=instance_count,
    instance_type=train_instance_type,
    framework_version="1.6",
    py_version="py3",
    volume_size=1024,
    # Debugger-specific parameters
    profiler_config=profiler_config,
)

现在，让我们使用fit()方法开始训练作业：

estimator.fit(inputs, wait= False)

在下一节中，您将分析和可视化由调试器生成的指标。

分析和可视化由分析器生成的系统和框架指标

一旦训练作业开始，调试器开始收集系统和框架指标。在本节中，您将学习如何查询、分析和可视化收集到的指标。

首先，让我们看看如何手动分析收集到的指标。下面的代码块展示了如何查询系统指标：

#All collected metrics are persisted in S3.  Define path to the profiler artifacts
path = estimator.latest_job_profiler_artifacts_path()
#Create a reader for the system metrics
system_metrics_reader = S3SystemMetricsReader(path)
#Get the latest event
last_timestamp = system_metrics_reader.get_timestamp_of_latest_available_file()
events = system_metrics_reader.get_events(0, last_timestamp * 1000000)  # UTC time in microseconds
#Show the first system metric event collected
print(
    "Event name:",  events[0].name,
    "\nTimestamp:",  timestamp_to_utc(events[0].timestamp),
    "\nValue:", events[0].value,
)

上述代码块的结果如下，显示了特定时间一个训练实例的 GPU：

Event name: gpu2 
Timestamp: 2021-07-02 18:44:20 
Value: 0.0

0.0的值表示该 GPU 未被利用。

与系统指标类似，您也可以审查框架指标。下面的代码块展示了如何查询框架指标：

#Create a reader for the system metrics
framework_metrics_reader = S3AlgorithmMetricsReader(path)
framework_metrics_reader.refresh_event_file_list()
last_timestamp = framework_metrics_reader.get_timestamp_of_latest_available_file()
events = framework_metrics_reader.get_events(0, last_timestamp)
#We can inspect one of the recorded events to get the following:
print("Event name:", events[0].event_name, 
      "\nStart time:", timestamp_to_utc(events[0].start_time/1000000000), 
      "\nEnd time:", timestamp_to_utc(events[0].end_time/1000000000), 
      "\nDuration:", events[0].duration, "nanosecond")

上述代码块的结果如下，显示了特定时间的一个框架指标：

Event name: embeddings.0 
Start time: 1970-01-19 19:27:42 
End time: 1970-01-19 19:27:42 
Duration: 141298 nanosecond

一旦收集到指标，您可以使用笔记本中的热图或自定义图表来可视化它们。

重要提示

为了更丰富的热图可视化以及更深入的系统与框架指标分析，请查看以下笔记本：gitlab.com/randydefauw/packt_book/-/blob/master/CH06/weather-prediction-debugger-profiler.ipynb。

分析 SageMaker Debugger 生成的分析报告

在本节中，我们将下载并审查由调试器生成的分析报告。SageMaker Debugger 创建了一个详细的分析报告，并将其保存在 S3 桶中，路径为s3://<你的桶> /<作业名称>/profiler-output/。您可以直接从 S3 下载报告。在以下列表中，我们将审查下载报告的几个部分：

• 训练作业摘要

  报告的这一部分提供了训练作业的详细摘要，包括作业的开始和结束时间以及训练各个阶段的耗时。以下截图显示了训练作业摘要的示例：

图 7.5 – 分析报告的训练作业摘要

• 系统指标摘要

  本节报告显示了训练节点的资源利用率。以下截图显示了 CPU、GPU、内存利用率、I/O 等待时间以及发送和接收的数据量：

图 7.6 – 性能分析报告的系统指标摘要

• 框架指标摘要

  本节报告首先显示了训练作业在训练和验证阶段花费的时间，以及它等待的时间：

图 7.7 – 性能分析报告的框架指标摘要

• 规则摘要

  当训练作业运行时，调试器执行一系列规则来分析训练过程。本节性能分析报告总结了所有已评估的调试器规则，规则的描述，每个规则在训练期间被触发的次数，分析以及改进训练作业的建议。以下截图显示了以表格格式的规则摘要：

图 7.8 – 性能分析报告的规则摘要

除了直接查询和可视化指标，以及在你的笔记本中下载性能分析报告外，你还可以使用 SageMaker Studio，它提供了内置的可视化来分析性能分析洞察。

要在 Studio 中访问调试器，请按照以下步骤操作：

1. 在导航面板上，选择组件和注册表。

2. 选择实验和试验。

3. 选择你的训练作业（右键点击）。

4. 从打开的调试器选项卡中选择调试器洞察。

在调试器选项卡中，你会看到多个部分。其中一部分被称为训练作业摘要，如下面的截图所示。这个内置的可视化显示了训练作业的详细信息，如开始时间、结束时间、持续时间以及训练各个阶段的耗时。饼图可视化显示了训练作业在初始化、训练和最终化阶段所花费的相对时间：

图 7.9 – SageMaker Studio 中的调试器可视化

在本节中，我们从下载的性能分析报告中高屋建瓴地回顾了几个部分。要更详细地探索性能分析报告，请运行我们 Git 仓库中的笔记本。

分析和实施性能分析报告中的建议

既然我们已经从性能分析中获得了建议，让我们分析并实施一个建议，看看它是否能提高训练作业。

从前一个节段的规则摘要表中，我们可以看到在训练过程中触发次数最多的规则是 LowGPUUtilization。这个规则表明，由于阻塞调用，可能会出现瓶颈，建议更改分布式训练策略或增加批量大小。触发次数最多的下一个规则是 BatchSize，这表明由于批量大小较小，GPU 利用率可能较低。

根据这个规则的执行结果，分析器的建议是考虑在较小的实例类型上运行，并增加批量大小。让我们结合这两个最常触发的规则的分析器建议，运行两个具有不同设置的新的训练作业，并检查新训练作业的分析器报告，以查看是否有任何改进。

我们将使用相同的基础设施，()，但增加批量大小来运行第一个训练作业，如下面的代码块所示：

train_instance_type='ml.p3.2xlarge'
instance_count = 2
hyperparameters = {"batch_size": 1024}

对于下一个训练作业，我们将使用较小的训练实例，()，并增加批量大小：

training_job_name=
train_instance_type='ml.p2.8xlarge'
instance_count = 2
hyperparameters = {"batch_size": 1024}

使用这两种不同的配置，使用 estimator.fit() 运行两个不同的训练作业。一旦训练作业完成，下载并分析这两个分析器报告。

比较两个训练作业

到目前为止，我们总共有三个配置不同的已完成训练作业。在本节中，我们将比较原始训练作业与根据分析器建议配置的两个新训练作业。在比较这些作业时，我们将关注训练时间和产生的训练成本。以下表格显示了初始和修订的训练作业配置，以及训练时间、资源利用率和成本比较：

图 7.10 – 训练作业比较

首先，让我们比较原始的训练作业和使用了第一次修订训练配置的训练作业。在修订的训练配置中，批量大小从 64 增加到 1024。这种配置更改将训练时间减少了 17637 秒；即从 18262 秒减少到 895 秒。假设训练作业是在 us-west-2 区域运行的，写作时的 p3.2xlarge 成本为 $3.825。这导致成本节省了 26.67%。

同样，如果您比较第二次修订的训练配置，其中我们将批量大小和实例类型都更新到原始配置，训练时间增加了，但整体训练成本提高了 65.36%。如果您可以容忍训练时间的轻微增加，通过实施分析器的建议可以节省训练成本。

重要提示

在以下 GitHub 仓库中提供了一个使用 SageMaker Debugger 分析器的完整教程笔记本：gitlab.com/randydefauw/packt_book/-/blob/master/CH06/weather-prediction-debugger-profiler.ipynb.

本节讨论的结果来自使用完整数据集进行 PyTorch 训练。在笔记本中，你将有机会探索相同的功能，但使用的是更小的数据集。

在本节中，我们实施了几项分析器的建议，并看到了显著的训练改进。还有更多建议你可以进行实验。

此外，在本节中，我们专注于如何启用调试器启动估计器。你也可以使用estimator.enable_default_profiling()将分析器附加到正在运行的训练作业上。同样，要启用调试器内置的规则、系统监控和框架分析，并使用可定制的配置参数，请使用estimator.update_profiler()。

摘要

在本章中，你学习了如何使用 Amazon SageMaker Debugger 的功能来了解训练过程、训练基础设施和训练框架。这种可见性使你能够对典型的训练问题做出反应，例如过拟合、训练损失以及停止训练作业以避免完成，结果只得到次优模型。通过使用 Amazon SageMaker 深度分析器的建议，你学习了如何从训练时间和成本的角度改进训练作业。

使用本章讨论的调试器功能，你可以通过调整底层机器学习框架参数和训练基础设施配置来持续改进你的训练作业，以实现更快和成本效益更高的机器学习训练。在下一章中，你将学习如何大规模管理训练好的模型。

进一步阅读

对于额外的阅读材料，请查阅以下参考文献：

• 使用 Amazon SageMaker Debugger 的深度分析功能识别瓶颈、提高资源利用率并降低机器学习训练成本：

  aws.amazon.com/blogs/machine-learning/identify-bottlenecks-improve-resource-utilization-and-reduce-ml-training-costs-with-the-new-profiling-feature-in-amazon-sagemaker-debugger/

• 使用 Amazon SageMaker Debugger 进行机器学习可解释性：

  aws.amazon.com/blogs/machine-learning/ml-explainability-with-amazon-sagemaker-debugger/

第三部分：管理和监控模型

本节讨论了管理和监控大量模型、在生产中更新模型以最小化停机时间以及选择合适的部署策略以满足业务目标成本优化的挑战。

本节包含以下章节：

• 第八章, 使用模型注册表在规模上管理模型

• 第九章, 使用 Amazon SageMaker 端点生产变体更新生产模型

• 第十章, 优化模型托管和推理成本

• 第十一章, 使用 Amazon SageMaker 模型监控和 Clarify 监控生产模型

第八章：使用模型注册管理大规模模型

当您开始部署多个模型并管理多个模型版本时，如果不使用模型注册，确保遵循核心架构实践（如治理、可追溯性和可恢复性）是具有挑战性的。模型注册是一个包含特定于模型版本的元数据的中央存储库。它包括有关模型如何构建、该模型的表现以及模型部署位置和方式的信息。模型注册服务或解决方案通常包括额外的功能，例如审批流程和通知。

在本章中，我们将介绍模型注册的概念以及为什么模型注册对于管理大规模的多个模型很重要。我们还将概述在选择模型注册实现时需要考虑的因素，以便最好地满足您环境和操作需求。为此，我们将检查两个模型注册的示例实现。这些将是一个使用 AWS 服务的自定义构建的模型注册，以及 SageMaker 的实现（称为 SageMaker 模型注册）。

Amazon SageMaker 提供了一个内置的模型注册功能。这是一个完全管理的模型注册，针对在 Amazon SageMaker 中使用进行了优化。然而，如果 Amazon SageMaker 模型注册不符合您的需求，有几种常见的模式，利用自定义构建的模型注册或第三方解决方案，这些解决方案与 Amazon SageMaker 也兼容得很好。尽管有许多第三方模型注册可供使用，用于 SageMaker 训练的模型，但我们不会在本章中具体介绍它们。

在本章中，我们将涵盖以下主要主题：

• 使用模型注册

• 选择模型注册解决方案

• 使用 Amazon SageMaker 模型注册管理模型

技术要求

您需要有一个 AWS 账户来运行本章包含的示例。如果您尚未设置数据科学环境，请参阅第二章**，数据科学环境。该章节提供了设置过程的概述。

书中包含的代码示例可在以下 URL 的 GitHub 上找到：https://github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter08。您需要安装 Git 客户端才能访问它们（git-scm.com/）。

本章的代码位于 GitHub 仓库的CH08文件夹中。

使用模型注册

模型注册允许您集中跟踪每个模型版本的关键元数据。跟踪的元数据粒度通常取决于所选的实现（Amazon SageMaker 的模型注册、自定义解决方案或第三方解决方案）。

不论实现方式如何，需要考虑的关键元数据包括模型版本标识符以及每个已注册模型版本以下信息：

• 模型输入：这包括与模型输入及其版本相关的元数据。这可以包括诸如存储训练数据的 Amazon S3 存储桶名称、训练超参数以及用于训练的Amazon Elastic Container Registry（ECR）仓库或容器镜像等输入。

• 模型性能：这包括模型评估数据，如训练和验证指标。

• model.tar.gz）。

• 模型部署：这包括与模型部署相关的元数据。这包括诸如模型版本部署到的环境（们）或用于注册模型的推理代码等信息。

Amazon SageMaker 提供了多种训练模型的选择，包括内置算法、内置框架（即脚本模式）以及自带容器。根据选择的不同，训练模型所需的输入数量可能会有所不同。这可能会影响您选择跟踪的元数据。因此，确定您需要跟踪的元数据的最低要求，以满足您可能具有的任何监管或内部可追溯性要求，是非常重要的。

当评估粒度级别时，您需要跟踪您的用例。记住您的团队是如何使用 Amazon SageMaker 来构建模型的。图 8.1展示了在 SageMaker 的训练模型选项中跟踪时需要考虑的输入、指标和工件示例：

图 8.1 – 训练选项中的模型构建元数据

对于跟踪和存储模型部署数据，也存在类似的考虑。为模型部署跟踪的元数据应提供足够的信息，以便使用 Amazon SageMaker 打包模型进行部署，到实时端点，或使用批量转换。这也应允许某人轻松地识别给定模型版本部署的位置，以及它是如何打包进行部署和使用的。图 8.2展示了在 SageMaker 的模型部署选项中跟踪时需要考虑的输入、部署阶段和工件示例：

图 8.2 – 模型部署选项中的模型部署元数据

如果您要管理几个模型，您可以使用简单的方法（如电子表格）来跟踪上述信息。然而，当您开始扩展到 20、100 或数千个模型时，跟踪模型元数据的那种机制就不再可扩展了。集中存储和跟踪每个模型版本的元数据（如图8.1和8.2所示）提供了以下好处：

• 操作效率：模型注册库提供了对构建特定模型版本所使用的关键输入、输出工件以及与该版本对齐的部署阶段信息的跟踪和可见性。拥有这些元数据允许您快速了解模型是如何构建的，模型的表现如何，有关训练模型工件的信息，同时也提供了跟踪特定版本部署到哪些环境的能力。

• 可恢复性：为了能够恢复已部署的模型或回滚到之前的版本，您需要能够看到用于创建可部署工件或已部署模型的输入和输入版本。在系统或人为错误的情况下，您可以使用存储在模型注册库中的元数据，结合受保护的版本化输入，恢复到特定的时间点。例如，如果管理员意外删除了一个模型端点，应该能够轻松地识别用于重新创建该端点的工件。这可以通过存储在模型注册库中的元数据来识别，这些元数据指向版本化模型工件的位置，并结合版本化的推理容器镜像。

• 管道源和触发器：通常需要连接模型构建和模型部署环境。这在拥有中央部署团队的大型企业中很常见，或者在模型构建和模型部署角色分离的组织中很常见。模型注册库提供了一个机制来捕获对了解模型构建所需的最小元数据。然而，它也可以用于触发审批工作流和下游部署。

在下一节中，我们将介绍三种创建模型注册库的模式，以集中跟踪和管理大规模机器学习模型。我们将概述每个模式的考虑因素和高级架构，以便指导您找到适合您特定用例的正确匹配。

选择模型注册库解决方案

实现模型注册库有多种选项。虽然每种实现都提供不同的功能或能力，但提供中央存储库以跟踪关键元数据的概念在所有实现中基本保持一致。在本节中，我们将介绍创建模型注册库的一些常见模式，并讨论每个模式的考虑因素。本节中涵盖的模式包括以下内容：

• Amazon SageMaker 模型注册库

• 构建自定义模型注册库

• 利用第三方或开源软件（OSS）模型注册库

Amazon SageMaker 模型注册库

Amazon SageMaker 模型注册表是一项托管服务，允许您集中目录化模型、管理模型版本、将元数据与您的模型版本关联，并管理模型版本的批准状态。该服务持续发展，新增功能，因此本节中的信息以出版日期为准。始终建议您通过官方文档验证当前功能和能力，官方文档为 Amazon SageMaker 模型注册表 (docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html)。SageMaker 模型注册表针对与 Amazon SageMaker Pipelines 和项目一起使用进行了优化；然而，它也可以独立使用。

您可以通过编程方式与 SageMaker 的模型注册表进行交互，也可以在 Amazon SageMaker Studio 中进行。Studio 提供了版本管理的可视化界面和体验。Studio 界面还提供了额外的搜索功能。以下截图展示了这些功能：

图 8.3 – SageMaker Studio 的 SageMaker 模型注册表界面

当模型获得生产批准时，SageMaker 模型注册表还包括一个可以修改的批准状态。这可能是经过同行或指定的部署审批者审查模型元数据和指标，作为部署的最终质量关卡之后。在以下截图中，您可以看到批准状态字段如何与 Amazon SageMaker Pipelines 中的 MLOps 项目集成，以根据模型状态的变化创建自动触发器：

图 8.4 – SageMaker 模型注册表 – 批准状态

SageMaker 模型注册表的主要组件包括以下内容：

• 模型注册表：这是包含模型组的中央存储库，它存在于 AWS 账户和 AWS 区域级别。可以设置跨账户权限，以便从其他 AWS 账户与模型注册表进行交互。

• 模型组：模型组是一种逻辑分组。它们允许您跟踪与同一机器学习问题相关或分组的不同模型版本。

• 模型包：模型包是已注册的模型或模型的特定版本。

图 8.5 展示了主要组件，其中每个模型版本都是包含在模型注册表内模型组中的模型包：

图 8.5 – Amazon SageMaker 模型注册表组件和用法

在模型组内注册新的模型版本时，您可以使用 Python 的 AWS SDK（boto3）的create_model_package方法（boto3.amazonaws.com/v1/documentation/api/latest/reference/services/sagemaker.html#SageMaker.Client.create_model_package），或者在使用 Amazon SageMaker Pipelines 中的RegisterModel步骤（sagemaker.readthedocs.io/en/stable/workflows/pipelines/sagemaker.workflow.pipelines.html#pipeline）在模型构建管道内创建一个步骤。了解您如何注册模型对于理解您如何在 SageMaker 管道之外使用 SageMaker 模型注册非常重要。这同样对于理解您如何将 SageMaker 模型注册集成到您可能已经使用的其他工作流程工具选项中也很重要。

可以将模型注册为版本化或非版本化。版本化的模型包是模型组的一部分，而非版本化的模型包不是模型组的一部分。使用模型组或版本化模型的优点在于能够逻辑上分组和管理相关的模型，以及提供自动版本化与特定机器学习（ML）问题相关的模型的能力。建议使用带有已注册版本化模型的模型组来注册您的模型。这是默认设置。

已注册的模型具有特定的元数据，可以与该版本关联。元数据由 API 请求参数定义和配置。在高级别上，API 接受并关联以下关键元数据作为输入：

• 推理规范：一系列参数，提供有关托管模型进行推理的详细信息和指导。传递的信息包括如 Amazon ECR 数据等信息。这包含推理代码镜像、包含训练模型实体的 Amazon S3 存储桶，以及托管模型进行实时推理或批量推理时支持的实例类型。例如，如果模型需要 GPU 进行推理，这可以在注册表中捕获。

• 模型指标：跨评估类别的模型评估指标，例如模型中的统计偏差或模型质量。

• 验证规范：有关用于验证模型包的 SageMaker 批量转换作业（如果适用）的信息。

• 算法规范：关于创建模型所使用的算法的详细信息，以及包含训练模型实体的 Amazon S3 存储桶。

• CodeCommit 提交 ID、源作者、SageMaker Pipelines 项目 ID 以及 CodeCommit 仓库的名称。虽然它们在 Amazon SageMaker Pipelines 之外的使用没有限制，但它们是直接指向 SageMaker Pipelines 项目资源的指针。

• 模型批准状态：此参数用于指示模型是否获准部署。此参数可用于管理工作流程。在 SageMaker Pipelines 项目的情况下，基于此字段的状况，自动工作流程触发器会自动设置。如果模型状态更改为批准，则可以触发下游部署工作流程。

Amazon SageMaker 的模型注册库是全托管的，这意味着没有服务器需要管理。它还原生集成到 SageMaker Pipelines 中，提供直接在模型构建管道中将模型注册库作为原生步骤集成的功能。它是通过使用 RegisterModel 步骤来实现的。

例如，如果您构建了一个包含数据预处理、训练和模型评估的自动化步骤的模型构建管道，您可以添加一个条件步骤来验证评估指标。如果评估指标高于指定的阈值（例如，准确率 > 90%），则可以配置管道以自动注册您的模型。

SageMaker 的模型注册库也原生集成到 SageMaker Pipelines 项目中。项目允许您自动配置 MLOps 管道和利用模型注册库的模板。SageMaker 项目可用于自动设置模型包组，以及可以用来触发预配置的下游部署管道的批准工作流程。

重要提示

在第十二章“机器学习自动化工作流程”中更详细地介绍了 Amazon SageMaker Pipelines。模型注册库是 SageMaker Pipelines 中的一个组件，但可以独立于 SageMaker Pipelines 使用。

传递给 CreateModelPackage API 的许多参数针对 Amazon SageMaker 使用和与其他 Amazon SageMaker 功能的集成进行了定制。例如，可以与模型指标相关联的数据与使用 Amazon SageMaker Clarify、模型统计偏差指标、Amazon SageMaker Model Monitor 和数据质量约束指标等特征产生的指标有直接关联。在另一个例子中，验证规范专门针对 SageMaker 批量转换作业运行以评估 SageMaker 模型包。

在本节中，我们回顾了 Amazon SageMaker 模型注册库的高级架构和用法，以便与其他选项进行比较，这些选项将在下一节中介绍。本章涵盖了多个选项。这是为了支持各种用例，并帮助您为您的特定用例选择正确的选项。

构建自定义模型注册库

模型注册表也可以使用 AWS 服务构建。构建自定义注册表需要更多努力来构建解决方案、设置 AWS 服务之间的集成、设置 ML 管道集成，然后管理解决方案。然而，自定义注册表也提供了完全自定义注册表以满足特定于您的用例的需求的能力。这可能包括跟踪更细粒度元数据的特定要求，或支持多个 ML 服务/平台的要求。在本节中，我们将回顾使用 AWS 服务创建自定义模型注册表的一个模式。

图 8.6中所示的模式说明了使用 Amazon DynamoDB 构建的简单模型注册表。可以使用设计模式通过分区键将模型分组分开来存储模型元数据。您还可以考虑如果更喜欢表级隔离，为不同的团队或业务单元建立一个新的表的设计模式。还应使用AWS 身份和访问管理（IAM）设置控制，以控制对 DynamoDB 特定表的访问，以及设置特定主键以对谁可以访问特定的模型分组进行控制：

![图 8.6 – 使用 AWS 服务的自定义模型注册表

图 8.6 – 使用 AWS 服务的自定义模型注册表

基于 DynamoDB 的模型注册表架构为每个模型版本存储的元数据提供了灵活性。例如，您可能希望跟踪与 Amazon S3 存储桶中对象相对应的数据版本。一个自定义构建的模型注册表提供了定义和调整架构的灵活性，以满足您对可追溯性或更细粒度元数据跟踪的个别需求。

通过 Amazon DynamoDB API（PutItem）或通过自定义构建的 API 与自定义构建的模型注册表进行交互。使用简单的PutItem API 通常适用于较小的团队或执行端到端任务（如模型构建、模型部署和在生产环境中运行）的团队。然而，在许多情况下，模型注册表作为共享服务（或 ML 平台组件）的一部分构建，为多个团队和用例提供服务。在这种情况下，建议构建一个包含类似控制和验证的 API，就像在托管服务（如 SageMaker 的模型注册表）中看到的那样。

要将自定义构建的模型注册表扩展以包括工作流任务，例如根据更改的属性触发模型部署管道，解决方案需要扩展以设置检测更改的触发器，然后执行您想要调用的任何下游过程。为此，您可以使用 DynamoDB Streams 和 AWS Lambda 触发器。

在本节中，我们介绍了使用 AWS 服务创建自定义模型注册表的高级实现模式。此示例在注册表架构、收集的数据点和定义预期用途方面提供了完全的灵活性。

例如，您可能有一些团队正在使用 Amazon SageMaker 功能，而其他团队则在使用其他服务，甚至是在本地构建模型。构建自定义注册库也允许您根据现有的多账户策略，将模型注册库放置在您选择的 AWS 账户中，并根据使用情况调整模式。

讨论的模式还利用了 AWS 管理的服务，如 DynamoDB 和 API Gateway，这意味着仍然没有服务器需要管理。然而，这并不是一个打包的解决方案。因此，需要设置和配置这些服务。可能需要编写接口代码，设置服务之间的集成，并管理解决方案。

利用第三方或开源模型注册库

接下来，我们将简要介绍使用第三方或开源模型注册库的方法。由于可供选择的项目很多，本节将侧重于高级考虑因素，而不是深入探讨任何特定实现。常见的实现，如 MLflow，已经提供了与 Amazon SageMaker 集成的现有文档。在实施第三方/开源实现并与 Amazon SageMaker 集成时，应利用这些资源。

在考虑第三方或开源实现时，在评估您的选项时需要考虑以下几个问题：

• 实现是否要求您管理底层服务器，这意味着您需要承担一些额外的运营开销，以确保服务器得到修补、监控、扩展和设置，使用的是现成的架构？

• 实现是否提供与 Amazon SageMaker 集成的原生集成，使其易于集成？

• 为了与 Amazon SageMaker 集成，您需要设置和管理哪些额外的凭证？

使用第三方或开源选项可能会在设置、集成和持续管理方面增加一些额外的开销。然而，许多这些实现提供了强大的功能、接口和可扩展性，这可能会根据您的 ML 环境和用例而受到青睐。

在本节中，我们讨论了三种用于与 Amazon SageMaker 模型一起使用的模型注册库实现的常见模式。根据您的需求，每种模式都可以是一个有效的选择。因此，讨论了每个模式的关键考虑因素，以提供一般性指导，以便选择最佳实现。

通常情况下，建议根据您自己的需求选择提供所需功能的选项，并结合提供最低开发和运营开销的选项。在下一节中，我们将重点深入探讨 Amazon SageMaker 模型注册库的技术细节。

使用 Amazon SageMaker 模型注册库管理模型

在名为“Amazon SageMaker 模型注册表”的部分中包含了 Amazon SageMaker 模型注册表的介绍。这是为了解释在选择模型注册表实现时需要考虑的总体架构和功能。在本节中，我们将通过介绍设置和使用 SageMaker 模型注册表的过程和最佳实践指南来深入了解 Amazon SageMaker 模型注册表。

SageMaker 的模型注册表包括模型注册表、模型组和模型包。每个模型组包含与相同机器学习问题相关的模型版本或模型包。每个模型包代表模型的特定版本，并包含与该版本相关的元数据。在与 SageMaker 模型注册表交互时使用 SageMaker 模型注册表 API，并且可以通过以下任何一种方式调用这些 API：

• create-model-package-group或create-model-package命令。

• (boto3): 这使用方法与模型注册表进行交互，例如create_model_package_group或create_model_package方法。

• Amazon SageMaker Studio：这使用 SageMaker Studio 中的点击式界面（如图 8.7 所示）来创建模型包组。

• RegisterModelstep。

图 8.7展示了使用 Studio UI 创建模型包组的过程：

![图 8.7 – 使用 SageMaker Studio 创建新的模型组

图 8.7 – 使用 SageMaker Studio 创建新的模型组

虽然你可以使用列出的任何方法与模型注册表进行交互，但在本章中，我们将介绍使用 AWS Python SDK（boto3）与模型注册表进行交互，以展示一个不依赖于 Amazon SageMaker Studio 或 Amazon SageMaker Pipelines 的低级别抽象。

在本节中，你了解了 SageMaker 模型注册表的主要组件，以及你可以通过编程方式或通过 Studio UI 与模型注册表进行交互的不同方式。

创建模型包组

模型包组包含一组模型包或模型版本。创建模型包组不是注册模型包的要求；然而，为了在机器学习用例中管理你的模型版本，建议使用模型包组。模型包组可以包含一个或多个模型包。

创建一个模型包组涉及一种方法，该方法在输入时仅接受少量参数进行配置，如下所示：

import time
model_package_group_name = "air-quality-" + str(round(time.time()))
model_package_group_input_dict = {
"ModelPackageGroupName" : model_package_group_name,
"ModelPackageGroupDescription" : "model package group for air quality models",
"Tags": [
            {
            "Key": "MLProject",
             "Value": "weather"
              }
]  
}
create_model_pacakge_group_response = sm_client.create_model_package_group(**model_package_group_input_dict)
print('ModelPackageGroup Arn : {}'.format(create_model_pacakge_group_response['ModelPackageGroupArn']))

上述代码用于创建一个模型包组，然后可以由机器学习构建者使用，以及与机器学习管道一起注册模型包（版本）以进行部署。配置模型包组只需要一个模型包组名称，以及可选的描述和任何你想要与模型组关联的标签。

创建模型包组时的建议包括以下内容：

• 建立模型包组的命名标准：随着模型包组数量的增加，拥有清晰的命名标准可以帮助轻松识别和搜索相关的模型包组。一些考虑因素可能包括团队标识符和/或项目标识符。由于通常有多个团队在模型上工作，团队标识符可以帮助轻松地对特定团队的模型进行分类和搜索。在整体解决方案中使用多个模型也很常见。在这种情况下，拥有一种将特定项目或解决方案相关的模型分组的方法是非常有价值的。这可以通过建立命名约定以及标签来实现。

• MLProject使用weather的值创建。在这种情况下，让我们假设一个天气团队负责构建与天气相关的模型，并且只有属于天气团队的团队成员应该能够查看带有此标签的模型包组。资源标签可以用来建立访问的条件策略。

创建模型包

模型包是一个可以存在于模型包组之外（称为未版本化）或存在于模型包组内（称为版本化）的模型版本。模型包组之外的模型包被称为未版本化，因为它没有使用模型包组的版本化功能。建议使用模型包组注册模型包，以自动管理模型版本，并在模型版本数量增加时提高可管理性。

重要提示

Amazon SageMaker 有两个名为CreateModel API 的概念。这是使用 Amazon SageMaker 部署模型所必需的，并在Amazon SageMaker 文档中讨论（docs.aws.amazon.com/sagemaker/latest/dg/sagemaker-mkt-model-pkg-model.html）。第二个例子，也是我们在本章中提到的例子，是使用CreateModelPackage API 创建的专门针对 Amazon SageMaker 模型注册表的模型包。

CreateModelPackage API 在输入时接受多个参数。高级参数类别已在标题为Amazon SageMaker 模型注册表的章节中介绍过，因此在本节中，我们将包括一个示例，使用这些参数然后通过我们的示例用例注册一个模型。在第十二章 机器学习自动化工作流程中，我们将在 ML 管道的上下文中再次讨论模型注册表，以展示如何将模型注册表集成到您的自动化工作流程中。现在，我们将专注于注册模型包，以表明它已通过管道工作流程之外的初始模型验证。

在这种情况下，模型已经训练完毕，我们已经评估了训练指标。一旦我们的模型达到评估指标所确定的最低阈值，我们就可以准备注册模型包了。使用 AWS Python SDK (boto3)，我们将注册模型包，如下面的代码所示：

modelpackage_inference_specification =  {
            "InferenceSpecification": {
            "Containers": [
            {
             "Image": xgboost_container,
             "ModelDataUrl": model_url
             }
             ],
             "SupportedContentTypes": [ "text/csv" ],
              "SupportedResponseMIMETypes": [ "text/csv" ],
  }
}
create_model_package_input_dict = {
            "ModelPackageGroupName" : model_package_group_name,
           "ModelPackageDescription" : "Model to predict air quality ratings using XGBoost",
            "ModelApprovalStatus" : "PendingManualApproval"
}
create_model_package_input_dict.update(modelpackage_inference_specification)
create_mode_package_response = sm_client.create_model_package(**create_model_package_input_dict)
model_package_arn = create_mode_package_response["ModelPackageArn"]
print('ModelPackage Version ARN : {}'.format(model_package_arn))

ModelPackageGroupName 是必需的，用于将模型包与模型包组关联。这允许您利用之前讨论过的自动版本控制功能。

可以使用 list_model_packages 方法以及 Amazon SageMaker Studio 来查看模型包。要列出模型包，请使用以下代码：

sm_client.list_model_packages(ModelPackageGroupName=model_package_group_name)

创建模型包时的建议包括以下内容：

• 创建版本化包：在创建模型包时指定模型包组，以便将模型包与模型组关联。这允许自动进行版本控制和将用例分组，以便于管理。

• 在对已注册模型进行同行评审后，可以选择使用 ApprovalStatus 来表明该模型已达到最低标准或符合特定标准。

• 保护模型注册表中引用的输入/工件：模型注册表中的详细信息可用于重新创建或回滚已部署的模型；然而，这些资源需要受到未经授权的访问或意外删除的保护。例如，如果管理员意外删除了 SageMaker 端点，它仍然可以很容易地使用模型注册表中标识的资源重新创建。这包括包含模型工件的 S3 对象、包含推理代码的 S3 对象（可选）以及 ECR 推理镜像。如果这些输入中的任何一个不可用或无法保证，则可能无法重新创建该端点。因此，元数据提供了所需的信息，但仍需要采取额外步骤来保护输入和工件。

• 考虑标签以添加额外元数据：SageMaker 的模型注册表中的元数据固定在 API 中定义的输入参数。然而，可以使用标签来补充额外的元数据。在此处推荐使用标签的示例可能是捕获模型工件等资源的 S3 版本，以便在工件跟踪中包含更多粒度。

• MLProject 使用 weather 的值创建。在这种情况下，假设一个天气团队负责构建与天气相关的模型，并且只有该团队成员应该能够注册新模型到该模型包组或其他使用此标签创建的模型包组。资源标签可以用来建立访问条件策略，以便在特定的模型包组内创建模型包。资源标签可以用来建立访问条件策略。

在本节中，我们详细介绍了使用本章提供的示例代码创建模型包组和将模型包注册到该模型包组的步骤。我们还概述了在创建自己的模型包组和模型包时需要考虑的建议。第十二章，机器学习自动化工作流程，将扩展本章涵盖的信息，包括将 Amazon SageMaker 的模型注册集成到 MLOps 流程中。

摘要

在本章中，我们讨论了模型注册以及利用模型注册在规模上管理 Amazon SageMaker 模型的优势。涵盖了模型注册实现的常见模式，包括 Amazon SageMaker 的模型注册、使用 AWS 服务构建自定义模型注册以及利用第三方或开源模型注册实现。根据您的用例和需求，每个选项都是一个有效的选择。然而，我们也强调了在选择最适合您需求的实现时需要考虑的一些因素。

最后，我们深入探讨了 Amazon SageMaker 的模型注册功能，涵盖了创建模型包组和通过创建模型包注册模型的具体建议。

在下一章中，我们将介绍使用 Amazon SageMaker 端点生产变体进行生产模型的实时测试和更新的内容。

第九章：使用 Amazon SageMaker 端点生产变体更新生产模型

由于各种原因，需要更新已部署的生产模型，例如获取新的训练数据、尝试新的算法和超参数，或者模型预测性能随时间恶化。每次在生产中用新版本更新模型时，都存在模型在更新期间不可用以及模型质量比之前版本差的风险。即使在开发和 QA 环境中经过仔细评估后，新模型也需要额外的测试、验证和监控，以确保它们在生产中正常工作。

当将模型的新版本部署到生产环境中时，你应该仔细考虑降低部署风险并最小化模型消费者停机时间。积极规划不成功的模型更新并回滚到先前的有效模型也很重要。理想情况下，用新模型替换现有模型不应导致模型消费者服务中断。模型消费者可能是你组织内部的或外部的面向客户的程序。

本章将探讨使用Amazon SageMaker 端点生产变体更新生产模型，同时尽量减少对模型消费者造成干扰的挑战。你将学习如何使用 SageMaker 端点生产变体来实现标准部署和高级模型部署策略，如A/B 测试、蓝/绿、金丝雀和影子部署，这些策略在成本与模型停机时间和回滚便捷性之间取得平衡。

到本章结束时，你将能够实施多种部署策略来更新生产机器学习模型。你将学习何时以及如何使用实时生产流量来测试新的模型版本。你还将了解在选择适合你用例的正确部署策略时，如何平衡成本、可用性和降低风险的最佳实践。

在本章中，我们将涵盖以下主要主题：

• Amazon SageMaker 端点生产变体的基本概念

• 使用 Amazon SageMaker 端点生产变体更新 ML 模型的部署策略

• 选择合适的部署策略

技术要求

你需要有一个AWS账户来运行本章包含的示例。如果你还没有设置数据科学环境，请参阅第二章**，数据科学环境，其中提供了设置过程的说明。

书中包含的代码示例可在 GitHub 上找到，网址为github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter09。你需要安装 Git 客户端才能访问它们（git-scm.com/)。

Amazon SageMaker 端点生产变体的基本概念

在本节中，您将回顾使用 SageMaker 端点生产变体部署和更新机器学习模型的基本知识。您可以使用两种方式通过 SageMaker 部署机器学习模型：使用实时端点进行低延迟的实时预测或批量转换，用于对大量推理请求进行异步预测。生产变体可以应用于实时端点。

部署实时端点涉及两个步骤：

1. 创建端点配置

   端点配置标识一个或多个生产变体。每个生产变体指示一个模型和基础设施，用于在之上部署模型。

2. 创建指向端点配置的端点

   端点创建结果是一个 HTTPS 端点，模型消费者可以使用它来调用模型。

下图显示了具有生产变体的两种不同的端点配置。model_1 部署在 ml.m4.xlarge 实例上；所有推理流量都由这个单一模型提供服务。model_1 和 model_2 分别部署在 ml.m4.xlarge 和 ml.m4.2xlarge 上。由于它们具有相同的 initial_weight 配置，这两个模型对推理请求的处理是平等的：

图 9.1 – 具有生产变体的端点配置

当一个端点配置了多个生产变体时，您如何知道哪个模型正在处理推理请求？有两种方法可以确定这一点：

• 首先，生产变体的 initial_weight 参数决定了由该变体指定的模型处理的请求的相对百分比。

• 其次，推理请求可能还包括要调用的模型变体。

下图显示了调用端点的这两种方式

图 9.2 – 调用 SageMaker 端点的两种方式

由于 SageMaker 端点正在处理推理流量，因此它们使用 EndpointName 和 VariantName 维度进行监控，以监控每个不同端点的特定生产变体的指标。Invocations 指标捕获发送到模型的请求数量，如生产变体所示。您可以使用此指标来监控由单个端点部署的不同模型服务的请求数量。

以下图表显示了为配置了两个生产变体的端点捕获的 Invocations 指标比较。第一个图表显示了当初始权重设置为 1 和 1 时每个生产变体的调用次数。在这种情况下，每个变体服务的请求数量相似。第二个图表显示了具有初始权重 2 和 1 的相同指标。如您所见，变体 1 服务的请求数量是变体 2 服务请求数量的两倍：

图 9.3 – SageMaker 端点生产变体的调用次数

虽然 Invocations 指标直观易懂，但还有其他 CloudWatch 指标，如 Latency 和 Overhead，可用于监控、比较和对比多个端点和单个端点的多个生产变体。

注意

有关 Amazon SageMaker 的完整 CloudWatch 指标列表，请参阅 docs.aws.amazon.com/sagemaker/latest/dg/monitoring-cloudwatch.html#cloudwatch-metrics-endpoint-invocation。

与生产变体类似，SageMaker 多模型端点（MME）也允许我们在单个端点上托管多个模型。如果是这种情况，生产变体与多模型端点有何不同？

在 MME 中，所有模型都托管在相同的计算基础设施上。然而，当创建端点时，并非所有模型都加载到容器内存中。相反，当进行推理请求时，模型被加载到内存中。每个推理请求必须指定要调用的模型。如果调用的模型尚未在内存中，则从 S3 存储桶将其加载到内存中。根据调用模式，最近未调用的模型可能不在内存中。这可能导致在处理请求时延迟增加。当您有大量不常访问且可以容忍略微增加延迟的类似 ML 模型时，单个 MME 可以以显著低廉的成本处理推理流量。

另一方面，使用生产变体时，每个模型都托管在完全不同的计算基础设施上，所有模型都随时可用，无需在需要时加载到容器内存中。每个推理请求可能或可能不指定要调用的变体。如果未指定要调用的变体，则每个变体服务的推理请求数量取决于生产变体的 initial_weight 参数。在模型部署的上下文中，使用生产变体来测试使用不同数据集、算法和 ML 框架训练的不同版本的 ML 模型，或者测试模型在不同实例类型上的性能。

在下一节中，您将学习如何在不同部署策略中使用 Production Variants。当我们讨论这些不同的部署策略时，我们将关注使用 Production Variants 更新作为实时 SageMaker 端点部署的现有生产模型所需的内容。

使用 SageMaker Endpoint Production Variants 更新 ML 模型的部署策略

在本节中，我们将深入探讨多种您可以采用的部署策略，以使用 SageMaker Endpoint Production Variants 更新生产模型。虽然一些部署策略易于实施且成本效益高，但其他策略在降低部署风险的同时增加了复杂性。我们将深入探讨五种不同的策略，包括标准、A/B、蓝绿、金丝雀和影子部署，并讨论每种方法中涉及的各个步骤。

标准部署

这种策略是部署和更新生产中模型的最直接方法。在标准模型部署中，始终只有一个活动的 SageMaker 端点，并且端点配置为单个生产变体，这意味着只有单个模型部署在端点后面。所有推理流量都由单个模型处理。端点配置类似于 variant1，在单个 ml.m5.xlarge 实例上托管 model_name_1 并处理所有推理流量，如 initial_weight=1 所示：

### Create production variant
from sagemaker.session import production_variant
variant1 = production_variant(model_name=model_name_1,
                              instance_type="ml.m5.xlarge",
                              initial_instance_count=1,
                              variant_name='VariantA',
                              initial_weight=1)

下面的代码块展示了如何从生产变体创建端点。endpoint_from_production_variants 自动创建与 endpoint_name 同名的 endpoint_configuration：

### Create the endpoint with a production variants
from sagemaker.session import Session
#Variable for endpoint name
endpoint_name=f"abtest-{datetime.now():%Y-%m-%d-%H-%M-%S}"
smsession = Session()
smsession.endpoint_from_production_variants(
            name=endpoint_name,
           production_variants=[variant1]
)

要使用模型的新版本更新端点，创建一个新的端点配置，指定新模型和部署模型的基础设施。然后，使用新的端点配置更新端点。以下代码块展示了更新端点以使用新模型版本的代码：

#Create production variant 2
variant2 = production_variant(model_name=model_name_2,
                              instance_type="ml.m5.xlarge",
                                   initial_instance_count=1,
                                   variant_name='Variant2',
                                   initial_weight=1)

#Create a new endpoint configuration
endpoint_config_new =f"abtest-b-config-{datetime.now():%Y-%m-%d-%H-%M-%S}"

smsession.create_endpoint_config_from_existing (
            existing_config_name=endpoint_name,
            new_config_name=endpoint_config_new,
            new_production_variants=[variant2]
)
##Update the endpoint to point to the new endpoint configuration
smsession.update_endpoint(
  endpoint_name=endpoint_name, endpoint_config_name=endpoint_config_new, wait=False)

SageMaker 自动创建和管理新生产变体所需的基础设施，并在没有任何停机时间的情况下将流量路由到新模型。现在所有推理流量都由新模型处理。以下图表显示了更新已部署模型的步骤：

![图 9.4 – 使用 SageMaker Endpoint Production Variants 的标准部署

图 9.4 – 使用 SageMaker Endpoint Production Variants 的标准部署

要回滚，只需使用原始端点配置更新端点，如 步骤 1 所示。如您所见，推理流量始终由模型的旧版本或新版本提供。

此方法的一个好处是，它是一种简单直接地使用新模型更新端点的方法。当端点更新为新端点配置时，SageMaker 将推理请求切换到新模型，同时保持端点处于 InService 状态。这意味着模型消费者不会体验到任何服务中断。这也是更新实时端点的经济高效策略，因为您只为托管单个模型的设施付费。

另一方面，模型评估和测试发生在非生产环境，如 QA 或预生产环境，并使用测试数据。由于新模型在生产环境中未经测试，它将在生产环境中首次面对新基础设施上的生产数据量和实时流量。这可能导致不可预见的问题，无论是模型托管的基础设施还是模型的质量。

注意

在评估模型处于预生产环境时，建议您进行负载测试，以验证模型在迁移到生产环境之前能否以可接受的延迟处理流量。

请参阅aws.amazon.com/blogs/machine-learning/load-test-and-optimize-an-amazon-sagemaker-endpoint-using-automatic-scaling/，了解如何使用自动扩展和 serverless-artillery 加载测试端点。

如果模型消费者能够容忍风险和失败，例如可以重新执行预测的内部应用程序，请使用标准部署。例如，预测员工流动性的内部模型是标准部署的良好候选者。

由于一次只能有一个模型处理推理请求，因此此策略不适用于比较不同的模型。如果您正在尝试不同的特征、多个算法或超参数，您希望能够在生产环境中比较这些模型。下一个部署策略有助于满足这一需求。

A/B 部署

在标准部署中，您在生产环境中有一个单一的端点，没有测试或评估模型在生产环境中的范围。另一方面，A/B 部署策略专注于实验和探索，例如比较同一功能的不同版本的性能。

在此场景中，端点配置使用两个生产变体：一个用于模型 A，另一个用于模型 B。为了对两个模型进行公平的比较，两个生产变体的 initial_weight 应该相同，以便两个模型处理相同数量的推理流量。此外，请确保实例类型和实例数量也相同。这种初始设置是必要的，以确保模型的任何版本都不会受到流量模式或底层计算能力差异的影响。

以下代码块显示了如何创建和更新用于 A/B 部署的端点。

首先，创建生产变体 A：

#Create production variant A
variantA = production_variant(model_name=model_name_1,
                                  instance_type="ml.m5.xlarge",
                                  initial_instance_count=1,
                                    variant_name='VariantA',
                                    initial_weight=1)

然后，创建一个只有一个生产变体的端点，它最初服务于生产流量：

#Variable for endpoint name
endpoint_name=f"abtest-{datetime.now():%Y-%m-%d-%H-%M-%S}"
#Create an endpoint with a single production variant
smsession.endpoint_from_production_variants(
            name=endpoint_name,
            production_variants=[variantA]
)

当您准备好测试模型的下一个版本时，创建另一个生产变体并更新端点，使其包括两个生产变体：

#Create production variant B
variantB = production_variant(model_name=model_name_2,
                                  instance_type="ml.m5.xlarge",
                                  initial_instance_count=1,
                                  variant_name='VariantB',
                                  initial_weight=1)

##Next update the endpoint to include both production variants
endpoint_config_new =f"abtest-new-config-{datetime.now():%Y-%m-%d-%H-%M-%S}"

smsession.create_endpoint_config_from_existing (
            existing_config_name=endpoint_name,
            new_config_name=endpoint_config_new,
            new_production_variants=[variantA,variantB]  ## Two production variants
)

##Update the endpoint
smsession.update_endpoint(endpoint_name=endpoint_name, endpoint_config_name=endpoint_config_new, wait=False)

要调用端点，请使用invoke_endpoint() API，如下所示。使用invoke_endpoint() API 的结果包括为每个特定请求服务的变体名称：

result = smrt.invoke_endpoint(EndpointName=endpoint_name,
                                  ContentType="text/csv",
                                 Body=test_string)
rbody = \ StreamingBody(raw_stream=result['Body'],content_length=int(result['ResponseMetadata']['HTTPHeaders']['content-length']))
print(f"Result from {result['InvokedProductionVariant']} = {rbody.read().decode('utf-8')}")

端点输出的结果应类似于以下内容：

Result from VariantA = 0.17167794704437256
Result from VariantB = 0.14226064085960388
Result from VariantA = 0.10094326734542847
Result from VariantA = 0.17167794704437256
Result from VariantB = 0.050961822271347046
Result from VariantB = -0.2118145227432251
Result from VariantB = 0.16735368967056274
Result from VariantA = 0.17314249277114868
Result from VariantB = 0.16769883036613464
Result from VariantA = 0.17314249277114868

您可以从变体 B收集和检查结果。您还可以进一步探索变体 B的 CloudWatch 指标，如Amazon SageMaker 端点生产变体基本概念部分所述。一旦您对变体 B的性能满意，逐渐将平衡转移到新模型（40/60，20/80），直到新模型处理所有实时流量。以下代码块显示了如何将 60%的实时流量路由到变体 B：

#Update the product variant weight to route 60% of traffic to VariantB
sm.update_endpoint_weights_and_capacities(
           EndpointName=endpoint_name,
           DesiredWeightsAndCapacities=[
          {"DesiredWeight": 4, "VariantName": variantA["VariantName"]},
          {"DesiredWeight": 6, "VariantName": variantB["VariantName"]},
          ],
)

或者，您可以选择一次性将端点更新为将所有实时流量路由到变体 B，如下所示：

##Update the endpoint to point to VariantB
endpoint_config_new =f"abtest-b-config-{datetime.now():%Y-%m-%d-%H-%M-%S}"

smsession.create_endpoint_config_from_existing (
            existing_config_name=endpoint_name,
            new_config_name=endpoint_config_new,
            new_production_variants=[variantB]
)
##Update the endpoint
smsession.update_endpoint(endpoint_name=endpoint_name, endpoint_config_name=endpoint_config_new, wait=False)

以下图表显示了更新已部署模型所涉及的步骤。要回滚，只需使用代表步骤 1 的原始端点配置更新端点：

图 9.5 – 使用 SageMaker 端点生产变体的 A/B 部署

这种策略的好处是它易于理解，SageMaker 通过管理流量路由使实施此策略变得简单。由于新模型在生产中使用了更高比例的实时流量和新的基础设施，因此模型在更新期间对模型消费者不可用或模型质量比上一个版本更差的风险降低。这解决了典型的部署问题：模型在开发/测试环境中运行完美，所以我不知道为什么在生产中会失败。然而，由于有两个生产变体在一段时间内处于活动状态，随着您为两套基础设施资源付费，成本也会增加。

注意

一种相对较新的 A/B 测试类型正在获得人气，称为多臂老丨虎丨机（MAB）。MAB 是一种基于机器学习的方法，它从测试期间收集的数据中学习。通过结合探索和利用，MAB 可以比传统的 A/B 测试更快地将流量动态转移到性能更好的模型变体。

请参考aws.amazon.com/blogs/machine-learning/power-contextual-bandits-using-continual-learning-with-amazon-sagemaker-rl/了解如何使用 Amazon SageMaker RL 实现多臂老丨虎丨机（MAB）来向用户推荐个性化内容。

当前的 A/B 测试策略在实验和探索方面很有帮助，但当你需要发布模型的主要变更时怎么办？有没有办法进一步降低风险？蓝/绿部署可以帮助解决这个问题。

蓝绿部署

蓝/绿部署策略涉及两个相同的 生产环境，一个包含当前模型，另一个包含你想要更新的下一个版本的模型。当其中一个环境，比如蓝色环境，正在服务实时流量时，下一个版本的模型在绿色环境中进行测试。在生产环境中进行模型测试时，只使用测试或合成数据。新的模型版本应该针对功能、业务和流量负载要求进行测试。

一旦你对一定期限内的测试结果感到满意，就用新的（绿色）端点配置更新实时端点。使用实时推理流量再次验证测试，如果在这个测试期间发现任何问题，就将流量路由回蓝色端点配置。过了一段时间，如果新模型没有问题，就可以继续删除蓝色端点配置。

以下图表显示了更新已部署模型的步骤：

图 9.6 – 使用 SageMaker 端点生产变体的蓝/绿部署

这种方法的优点是在向实时流量提供服务之前，新模型在生产环境中进行了评估。模型本身以及托管模型的底层基础设施都得到了评估，从而降低了风险。然而，由于有两个相同的 生产环境活跃了一段时间，与之前讨论的策略相比，这种选项的成本可能会翻倍。此外，这种选项也失去了 SageMaker 管理路由逻辑的优势。

在这个策略中，虽然模型在生产环境中进行评估，但测试仍然涉及合成流量。合成数据可以模拟生产量，但反映实时数据模式并不简单。如果你想要使用实时流量测试新模型，金丝雀部署策略允许你这样做。

金丝雀部署

在金丝雀部署中，设置与蓝/绿部署非常相似，有两个不同的生产环境分别托管旧模型和新模型。然而，您不是使用新模型的新合成测试数据，而是使用一部分实时流量。最初，模型消费者的一小部分推理流量将由新模型提供服务。其余的推理请求继续使用之前的版本。在测试阶段，使用新模型指定的用户组应保持不变，这需要粘性。当您对新模型满意时，逐渐增加发送到新模型的请求数量，直到所有实时流量都由新模型提供服务。最后，可以删除旧模型。

与我们之前讨论的其他策略不同，SageMaker 没有实现两个不同环境之间的切换。为了使环境切换对模型消费者完全透明，必须在消费者和端点之间使用一个切换组件。切换组件的例子包括负载均衡器、DNS 路由器等。

以下图表显示了使用此策略更新已部署模型的步骤：

![图 9.7 – 使用 SageMaker 端点生产变体的金丝雀部署

![img/B17249_09_07.jpg]

图 9.7 – 使用 SageMaker 端点生产变体的金丝雀部署

与蓝/绿部署一样，这种方法的优点是，由于新模型在生产环境中进行测试，因此降低了模型消费者的风险。此外，模型逐渐暴露于实时流量，而不是突然切换。但此策略确实需要您管理逐渐增加新模型流量的逻辑。此外，由于两个相同的生产环境在一段时间内都是活跃的，因此此选项的成本也显著更高。

影子部署

在影子部署中，设置再次与金丝雀部署非常相似，即两个不同的生产环境分别托管旧模型和新模型，推理流量被发送到两者。然而，只有来自旧模型的响应被发送回模型消费者。

发送到旧模型的流量被收集并也发送到新模型，可以是立即或延迟后。在生产流量同时发送到新旧模型的情况下，新模型的输出仅被捕获和存储以供分析，不会发送给模型消费者。新模型应与实际流量进行功能、业务和流量负载测试。以下图表显示了使用此策略更新已部署模型的步骤：

![图 9.8 – 使用 SageMaker 端点生产变体的影子部署

![img/B17249_09_08.jpg]

图 9.8 – 使用 SageMaker 端点生产变体的影子部署

与金丝雀部署类似，这种方法的优点在于，随着新模型在生产环境中进行测试，模型消费者面临的所有风险都得到了降低。

注意

在以下 GitHub 仓库中提供了一个演示端到端 A/B 部署策略的示例笔记本。您可以使用它作为实施其他部署策略的起点：gitlab.com/randydefauw/packt_book/-/blob/main/CH09/a_b_deployment_with_production_variants.ipynb。

现在您已经了解了可以使用多种部署策略来更新生产模型，在下一节中，我们将讨论如何选择策略以满足您的特定需求。

选择合适的部署策略

如您至今所见，机器模型的初始部署只是使其对消费者可用的一步。模型的新版本会定期构建。在将新模型提供给消费者之前，应仔细评估模型质量和托管模型所需的基础设施。在选择初始部署和持续更新模型的部署策略时，需要考虑多个因素。例如，由于预算和资源限制，并非所有模型都可以在生产环境中进行测试。同样，一些模型消费者可以容忍模型在一定时期内不可用。

本节将总结您可以使用来部署和更新实时 SageMaker 端点的部署策略。您将了解每种策略的优缺点，以及何时应该使用它们。

选择标准部署

模型消费者不是业务或收入关键，且具有风险容忍度。例如，一家公司的内部员工流失预测模型不是时间敏感的，可以在出现错误时重新执行：

图 9.9 – 标准部署的优缺点

选择 A/B 部署

您应该使用 A/B 部署来探索不同超参数集对模型质量、新的或不同的训练数据集切片以及不同的特征工程技术的影响：

图 9.10 – A/B 部署的优缺点

选择蓝绿部署

您应该使用此部署与关键任务模型消费者，如对模型停机敏感的电子商务应用程序：

图 9.11 – 蓝绿部署的优缺点

选择金丝雀部署

您应该使用此部署与关键任务模型消费者，如不具有风险容忍度的金融服务模型：

![图 9.12 – Canary 部署的优缺点]

选择影子部署

你应该使用此部署与关键任务模型消费者，如金融服务模型，这些模型不耐受风险：

![图 9.13 – 影子部署的优缺点]

![图片 B17249_09_13.jpg]

图 9.13 – 影子部署的优缺点

你应该使用前面小节中讨论的权衡来选择一个合适的模型策略，以便于实施、可接受的模型停机时间、消费者的风险承受能力和你必须考虑以满足你需求的成本。

摘要

在本章中，我们回顾了我们应该更新生产机器学习模型的原因。你学习了如何使用生产变体通过单个 SageMaker 端点托管多个模型。然后你了解了多种部署策略，这些策略平衡了模型更新的成本和风险与实施和回滚的简便性。你还学习了涉及的各种步骤和用于标准、A/B、蓝绿、金丝雀和影子部署的配置。

本章以对每种部署策略的优缺点和适用性的比较结束。利用这次讨论作为指导，你现在可以选择一个合适的策略来更新你的生产模型，以确保它们满足你的模型可用性和模型质量要求。

在下一章中，我们将继续讨论模型的部署，并了解优化模型托管和基础设施成本。

![图片 B17249_09_06.jpg]

第十章：优化模型托管和推理成本

更强大的计算机（特别是图形处理单元，或GPU）和强大的机器学习（ML）框架，如 TensorFlow 的引入，导致了机器学习能力的一个代际飞跃。作为机器学习从业者，我们的视野现在包括优化这些新功能的使用，以最大化我们投入的时间和金钱所获得的价值。

在本章中，您将学习如何使用多种部署策略来满足您的训练和推理需求。您将学习何时提前获取和存储推理，何时按需获取，如何扩展推理服务以满足波动需求，以及如何使用多个模型进行模型测试。

在本章中，我们将涵盖以下主题：

• 实时推理与批量推理

• 在单个推理端点后面部署多个模型

• 扩展推理端点以满足推理流量需求

• 使用弹性推理进行深度学习模型

• 使用 SageMaker Neo 优化模型

技术要求

您需要一个 AWS 账户来运行本章包含的示例。如果您尚未设置数据科学环境，请参阅第二章**，数据科学环境，该章节将指导您完成设置过程。

书中包含的代码示例可在 GitHub 上找到，网址为github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter10。您需要安装 Git 客户端才能访问它们（git-scm.com/)。

本章的代码位于 GitHub 仓库的CH10文件夹中。

实时推理与批量推理

SageMaker 提供了两种获取推理的方法：

• 实时推理允许您从实时推理端点以非常低的延迟获取单个推理或少量推理。

• 批量推理允许您从批量处理作业中获取大量推理。

批量推理更高效且更具成本效益。只要您的推理需求允许，就使用它。我们将首先探讨批量推理，然后转向实时推理。

批量推理

在许多情况下，我们可以提前进行推理并将它们存储起来以供以后使用。例如，如果您想为电子商务网站上的用户生成产品推荐，这些推荐可能基于用户的先前购买以及您希望第二天推广的产品。您可以在夜间生成这些推荐并将它们存储起来，以便电子商务网站在用户浏览网站时调用。

存储批量推理有多种选择。由于以下原因，Amazon DynamoDB 是常见的选择，例如：

• 它很快。您可以在几毫秒内查找单个值。

• 它是可扩展的。您可以在低成本下存储数百万个值。

• 对于 DynamoDB 来说，最佳访问模式是通过高基数主键查找值。这非常适合许多推断使用模式，例如，当我们想要查找为单个用户存储的推荐时。

根据您的访问模式，您可以使用其他数据存储，包括 DocumentDB 和 Aurora。

在 GitHub 仓库的CH10文件夹中，您会找到optimize.ipynb笔记本。该仓库的实时和批量推断部分会指导您使用简单的 XGBoost 模型进行批量推断和实时推断。以下代码允许您运行批量推断作业：

batch_input = "s3://{}/{}/{}/".format(s3_bucket, s3_prefix, 'test')
batch_output = "s3://{}/{}/{}/".format(s3_bucket, "xgboost-sample", 'xform')
transformer = estimator.transformer(instance_count=1, 
instance_type='ml.m5.4xlarge', output_path=batch_output, max_payload=3)
transformer.transform(data=batch_input, data_type='S3Prefix', 
content_type=content_type, split_type='Line')

这个作业大约需要 3 分钟来运行。

实时推断

当您将 SageMaker 模型部署到实时推断端点时，SageMaker 会将模型工件和您的推断代码（打包在 Docker 镜像中）部署到一个或多个推断实例。现在您有一个用于推断的实时 API 端点，并且可以根据需要从其他软件服务中调用它。

只要推断端点（实例）在运行，您就需要为其付费。在以下情况下使用实时推断：

• 推断依赖于上下文。例如，如果您想推荐一部视频观看，推断可能取决于用户刚刚看完的节目。如果您有一个大型视频目录，您无法提前生成所有可能的推荐排列。

• 您可能需要为新事件提供推断。例如，如果您试图将信用卡交易分类为欺诈或非欺诈，您需要等待您的用户实际尝试交易。

以下代码部署了一个推断端点：

from sagemaker.deserializers import JSONDeserializer
from sagemaker.serializers import CSVSerializer
predictor = estimator.deploy(initial_instance_count=1,
                            instance_type='ml.m5.2xlarge',
                            serializer=CSVSerializer(),
                            deserializer=JSONDeserializer()
                             )

一旦端点上线，我们可以使用我们刚刚部署的端点来获取推断：

result = predictor.predict(csv_payload)
print(result)

使用我们简单的 XGBoost 模型，一个推断大约需要 30 毫秒来完成。

成本比较

考虑这样一个场景，我们想要预测我们所有气象站第二天测量的数据，并在交互式网站上提供查询。我们大约有 11,000 个独特的气象站和每个站点的 7 个不同的预测参数。

使用ml.m5.2xlarge实例类型的实时端点，我们每小时支付 0.538 美元，或大约每月 387 美元。使用批量推断，我们每小时支付 1.075 美元用于ml.m5.4xlarge实例。每天运行作业需要 3 分钟，每月需要 90 分钟。这大约是 1.61 美元。

如果您不需要上下文相关的实时预测，批量推断方法通常更具成本效益。从 NoSQL 数据库中提供预测是一个更好的选择。

在单个推断端点后面部署多个模型

SageMaker 推理端点是实际包含负载均衡器和一个或多个推理容器实例的逻辑实体。你可以在单个端点后面部署同一模型的多个版本或完全不同的模型。在本节中，我们将探讨这两个用例。

同一模型的多个版本

SageMaker 端点允许你托管多个模型，这些模型为传入请求提供不同百分比的流量。这种能力支持常见的持续集成（CI）和持续交付（CD）实践，如金丝雀和蓝绿部署。虽然这些实践相似，但它们的目的略有不同，如以下所述：

• 金丝雀部署意味着你让模型的新版本承载一小部分流量，这样你就可以在流量的一小部分上测试模型的新版本，直到你对它的工作效果满意。

• 蓝绿部署意味着你同时运行模型的两个版本，保留一个较老的版本以便在新的版本出现问题时快速切换。

实际上，这些都是主题的变体。在 SageMaker 中，你指定每个模型变体处理的流量量。对于金丝雀部署，你可能会从新模型版本的小部分（通常为 1-5%）开始。对于蓝绿部署，你会使用 100%的新版本，但如果出现问题，会切换回 0%。

完成这些部署模式还有其他方法。例如，你可以使用两个推理端点，并使用 DNS（Route 53）、负载均衡器或全球加速器来处理流量整形。但通过 SageMaker 管理流量可以简化你的运营负担并降低成本，因为你不需要运行两个端点。

在笔记本的A/B 测试部分，我们将创建模型的另一个版本，并创建一个新的端点，该端点使用这两个模型：

1. 我们将首先通过以下方式训练模型的一个新版本，并改变超参数（最大树深度从5变为10）：

   hyperparameters_v2 = {
           "max_depth":"10",
           "eta":"0.2",
           "gamma":"4",
           "min_child_weight":"6",
           "subsample":"0.7",
           "objective":"reg:squarederror",
           "num_round":"5"}
   estimator_v2 = \ sagemaker.estimator.Estimator(image_uri=xgboost_container, 
                       hyperparameters=hyperparameters,
                       role=sagemaker.get_execution_role(),
                       instance_count=1, 
                       instance_type='ml.m5.12xlarge', 
                       volume_size=200, # 5 GB 
                       output_path=output_path)
   predictor_v2 = estimator_v2.deploy(initial_instance_count=1,
                              instance_type='ml.m5.2xlarge',
                               serializer=CSVSerializer(),
                             deserializer=JSONDeserializer()
                                )
   

2. 接下来，我们为每个模型版本定义端点变体。这里最重要的参数是initial_weight，它指定了应该有多少流量流向每个模型版本。通过将两个版本都设置为1，流量将在这两个版本之间平均分配。对于 A/B 测试，你可能从现有版本的权重为20，新版本的权重为1开始：

   model1 = predictor._model_names[0]
   model2 = predictor_v2._model_names[0]
   from sagemaker.session import production_variant
   variant1 = production_variant(model_name=model1,
                               instance_type="ml.m5.xlarge",
                                 initial_instance_count=1,
                                 variant_name='Variant1',
                                 initial_weight=1)
   variant2 = production_variant(model_name=model2,
                               instance_type="ml.m5.xlarge",
                                 initial_instance_count=1,
                                 variant_name='Variant2',
                                 initial_weight=1)
   

3. 现在，我们使用以下两种模型变体部署一个新的模型：

   from sagemaker.session import Session
   smsession = Session()
   smsession.endpoint_from_production_variants(
       name='mmendpoint',
       production_variants=[variant1, variant2]
   )
   

4. 最后，我们可以测试新的端点：

   from sagemaker.deserializers import JSONDeserializer
   from sagemaker.serializers import CSVSerializer
   import boto3
   from botocore.response import StreamingBody
   smrt = boto3.Session().client("sagemaker-runtime")
   for tl in t_lines[0:50]:
       result = smrt.invoke_endpoint(EndpointName='mmendpoint',
            ContentType="text/csv", Body=tl.strip())
       rbody = StreamingBody( \
   raw_stream=result['Body'], \
   content_length= \
   int(result['ResponseMetadata']['HTTPHeaders']['content-length']))
       print(f"Result from {result['InvokedProductionVariant']} = " + \
   f"{rbody.read().decode('utf-8')}")
   

   你会看到类似以下输出的内容：

   Result from Variant2 = 0.16384175419807434
   Result from Variant1 = 0.16383948922157288
   Result from Variant1 = 0.16383948922157288
   Result from Variant2 = 0.16384175419807434
   Result from Variant1 = 0.16384175419807434
   Result from Variant2 = 0.16384661197662354
   

注意，流量会根据我们指定的权重在模型的两个版本之间切换。在生产环境中，你应该在 CI/CD 或 MLOps 自动化工具中自动化模型端点的更新。

多个模型

在其他情况下，你可能需要运行完全不同的模型。例如，你可能希望有一个模型为美国提供天气推断，另一个模型为德国提供天气推断。你可以构建对这两个国家之间的差异敏感的模型。你可以在同一个端点后面托管这两个模型，并根据传入的请求将流量引导到它们。

或者，对于 A/B 测试，你可能希望控制哪些流量流向你的新模型版本，而不是让负载均衡器执行随机的加权分布。如果你有一个应用服务器可以识别哪些消费者应该使用新的模型版本，你可以将流量引导到推理端点后面的特定模型。

在“单个端点中的多个模型”笔记本部分，我们将通过创建针对不同空气质量参数优化的模型的示例来演示。当我们需要预测时，我们指定我们想要的参数类型，端点将我们的请求引导到适当的模型。这个用例非常现实；可能很难使用相同的模型同时预测颗粒物（PM25）和臭氧（O3）：

1. 首先，我们将通过创建 Spark 处理作业来准备只包含单个参数数据的新数据集：

   spark_processor.run(
       submit_app="scripts/preprocess_param.py",
       submit_jars=["s3://crawler-public/json/serde/json-serde.jar"],
       arguments=['--s3_input_bucket', s3_bucket,
                 '--s3_input_key_prefix', s3_prefix_parquet,
                  '--s3_output_bucket', s3_bucket,
                  '--s3_output_key_prefix', f"{s3_output_prefix}/o3",
                  '--parameter', 'o3',],
       spark_event_logs_s3_uri="s3://{}/{}/spark_event_logs".format(s3_bucket, 'sparklogs'),
       logs=True,
       configuration=configuration
   )
   

   我们将对PM25和O3重复前面的步骤。

2. 现在，我们将根据单个参数训练集训练新的 XGBoost 模型，如下所示：

   estimator_o3 = sagemaker.estimator.Estimator(image_uri=xgboost_container, 
                       hyperparameters=hyperparameters,
                       role=sagemaker.get_execution_role(),
                       instance_count=1, 
                       instance_type='ml.m5.12xlarge', 
                       volume_size=200,  
                       output_path=output_path)
   content_type = "csv"
   train_input = TrainingInput("s3://{}/{}/{}/{}/".format(s3_bucket, s3_output_prefix, 'o3', 'train'), content_type=content_type)
   validation_input = TrainingInput("s3://{}/{}/{}/{}/".format(s3_bucket, s3_output_prefix, 'o3', 'validation'), content_type=content_type)
   # execute the XGBoost training job
   estimator_o3.fit({'train': train_input, 'validation': validation_input})
   

3. 接下来，我们定义多模型类：

   model = estimator_o3.create_model(role=sagemaker.get_execution_role(), image_uri=xgboost_container)
   from sagemaker.multidatamodel import MultiDataModel
   model_data_prefix = f's3://{s3_bucket}/{m_prefix}/mma/'
   model_name = 'xgboost-mma'
   mme = MultiDataModel(name=model_name,
                        model_data_prefix=model_data_prefix,
                        model=model) 
   

4. 接下来，我们将部署多模型端点：

   predictor = mme.deploy(initial_instance_count=1,
                          instance_type='ml.m5.2xlarge',
                          endpoint_name=model_name,
                         serializer=CSVSerializer(),
                       deserializer=JSONDeserializer())
   

5. 到目前为止，端点实际上没有任何模型在其后面。我们需要在下一步添加它们：

   for est in [estimator_o3, estimator_pm25]:
       artifact_path = \ est.latest_training_job.describe()['ModelArtifacts']['S3ModelArtifacts']
       m_name = artifact_path.split('/')[4]+'.tar.gz'
   
       # This is copying over the model artifact to the S3 location for the MME.
       mme.add_model(model_data_source=artifact_path, model_data_path=m_name)
   
   list(mme.list_models())
   

6. 我们已经准备好测试端点。下载两个测试文件，每个参数一个：

   s3.download_file(s3_bucket, f"{s3_output_prefix}/pm25/test/part-00120-81a51ddd-c8b5-47d0-9431-0a5da6158754-c000.csv", 'pm25.csv')
   s3.download_file(s3_bucket, f"{s3_output_prefix}/o3/test/part-00214-ae1a5b74-e187-4b62-ae4a-385afcbaa766-c000.csv", 'o3.csv')
   

7. 读取文件并获取推断，指定我们想要使用的模型：

   with open('pm25.csv', 'r') as TF:
       pm_lines = TF.readlines()
   with open('o3.csv', 'r') as TF:
       o_lines = TF.readlines()
   for tl in pm_lines[0:5]:
       result = predictor.predict(data = tl.strip(), target_model='pm25.tar.gz')
       print(result)
   for tl in o_lines[0:5]:
       result = predictor.predict(data = tl.strip(), target_model='o3.tar.gz')
       print(result)
   

现在我们已经看到了如何部署多个模型进行测试或其他目的，让我们转向处理波动流量需求。

扩展推理端点以满足推理流量需求

当我们需要实时推理端点时，处理能力需求可能会根据传入流量而变化。例如，如果我们为移动应用程序提供空气质量推断，使用量可能会根据一天中的时间而波动。如果我们为峰值负载配置推理端点，我们将在非峰值时段支付过多。如果我们为较小的负载配置推理端点，我们可能在峰值时段遇到性能瓶颈。我们可以使用推理端点自动扩展来调整容量以满足需求。

有两种扩展类型，垂直扩展和水平扩展。垂直扩展意味着我们调整单个端点实例的大小。水平扩展意味着我们调整端点实例的数量。我们更喜欢水平扩展，因为它对最终用户的影响较小；负载均衡器可以在不影响最终用户的情况下重新分配流量。

配置 SageMaker 推理端点自动扩展有四个步骤：

• 设置最小和最大实例数量。

• 选择缩放指标。

• 设置缩放策略。

• 设置冷却时间。

虽然您可以使用 API 自动设置自动缩放，但在这个部分，我们将通过控制台中的步骤进行说明。首先，前往 SageMaker 控制台的端点部分，如下面的截图所示：

![图 10.1 – SageMaker 控制台中的端点列表]

![img/B17249_10_01.jpg]

![图 10.1 – SageMaker 控制台中的端点列表]

选择您的端点之一，在名为端点运行时设置的部分，选择配置自动缩放：

![图 10.2 – 端点运行时设置]

![img/B17249_10_02.jpg]

![图 10.2 – 端点运行时设置]

现在，让我们详细了解推理端点的设置。

设置最小和最大容量

您可以为端点使用的最小和最大实例数量设置边界。这些边界可以帮助您防止需求激增导致的不预期成本。如果您预计会有周期性的峰值，请在达到推理端点之前在您的应用程序中构建一个断路器来减轻负载。以下截图显示了控制台中的这些设置：

![图 10.3 – 设置最小和最大容量]

![img/B17249_10_03.jpg]

![图 10.3 – 设置最小和最大容量]

如果您的负载高度可变，您可以从小型实例类型开始，并积极地进行扩展。这可以防止您为不需要的大型实例类型付费。

选择缩放指标

我们需要决定何时触发缩放操作。我们通过指定 CloudWatch 指标来完成此操作。默认情况下，SageMaker 提供了两个有用的指标：

• InvocationsPerInstance报告在一段时间内发送到每个端点实例的推理请求数量。

• ModelLatency是响应推理请求的微秒数。

我们建议将ModelLatency作为自动缩放的指标，因为它报告了最终用户的使用体验。设置该指标的实际值将取决于您的需求和一段时间内端点性能的观察。例如，您可能会发现，如果推理结果通过几个其他服务（这些服务在结果到达最终用户之前增加了自己的延迟），超过 100 毫秒的延迟会导致用户体验下降。

设置缩放策略

您可以选择目标跟踪和步进缩放。目标跟踪策略更有用，并试图调整容量以保持某些目标指标在给定边界内。步进缩放策略更高级，以增量步骤增加容量。

设置冷却时间

冷却时间是指端点在开始下一次缩放操作之前等待的时间。如果您让端点即时响应，您可能会过于频繁地进行缩放。一般来说，积极地进行扩展，保守地进行缩减。

以下截图展示了如果你使用默认的缩放策略，如何配置目标指标值和冷却期：

图 10.4 – 设置目标指标值和冷却期

接下来，让我们看看为深度学习模型提供的另一种优化技术。

使用 Elastic Inference 进行深度学习模型

如果你检查机器学习的整体成本，你可能会惊讶地发现，你每月的大部分成本来自实时推理端点。训练作业虽然可能资源密集，但运行一段时间后会终止。托管笔记本实例可以在非工作时间关闭。但推理端点每天 24 小时，每周 7 天都在运行。如果你使用深度学习模型，推理端点的成本会更加明显，因为具有专用 GPU 容量的实例比其他类似实例更昂贵。

当你从深度学习模型获取推理时，你不需要像训练期间那样多的 GPU 容量。Elastic Inference 允许你将部分 GPU 容量附加到常规 EC2 实例或Elastic Container Service (ECS) 容器。因此，你可以以较低的成本快速获得深度学习推理。

笔记本中的 Elastic Inference 部分展示了如何将 Elastic Inference 加速器附加到端点，如下面的代码块所示：

predictor_ei = predictor.deploy(initial_instance_count = 1, instance_type = 'ml.m5.xlarge', 
                    serializer=CSVSerializer(),
                    deserializer=JSONDeserializer(),
                    accelerator_type='ml.eia2.medium')

考虑一个我们需要一些 GPU 容量进行推理的情况。让我们考虑实例类型的三个选项并比较成本。假设我们每月运行端点 720 小时。下表比较了不同推理选项的月度成本，使用的是撰写时的公布价格：

图 10.5 – 推理成本比较

你需要查看你的具体用例，并找出最佳的 RAM、CPU、网络吞吐量和 GPU 容量组合，以最低的成本满足你的性能需求。如果你的推理完全受 GPU 限制，Inferentia 实例可能会给你提供最佳的性能价格比。如果你需要更多一些的 GPU 计算资源，P2/P3 系列将工作得很好。如果你需要的整体容量非常小，Elastic Inference 提供了最便宜的 GPU 选项。

在下一节中，我们将介绍针对特定硬件部署的模型的另一种优化技术。

使用 SageMaker Neo 优化模型

在上一节中，我们看到了 Elastic Inference 如何降低深度学习模型的推理成本。同样，SageMaker Neo 允许你通过为特定平台编译训练好的 ML 模型以获得更好的性能来提高推理性能并降低成本。虽然这有助于一般情况，但在你尝试在低功耗边缘设备上运行推理时尤其有效。

为了使用 SageMaker Neo，您只需使用支持框架中的训练模型启动一个编译作业。当编译作业完成后，您可以将工件部署到 SageMaker 端点或使用Greengrass IoT 平台部署到边缘设备。

笔记本中的使用 SageMaker Neo 进行模型优化部分演示了如何编译我们的 XGBoost 模型以在托管端点使用：

1. 首先，我们需要获取输入记录的长度（特征数量）：

   ncols = len(t_lines[0].split(','))
   

2. 现在，我们将编译我们的一个训练模型。我们需要指定目标平台，在这个例子中，它只是一个标准的ml_m5系列：

   import sagemaker
   from sagemaker.model import Model
   n_prefix = 'xgboost-sample-neo'
   n_output_path = 's3://{}/{}/{}/output'.format(s3_bucket, n_prefix, 'xgboost-neo')
   m1 = Model(xgboost_container,model_data=estimator\    .latest_training_job.describe()['ModelArtifacts']['S3ModelArtifacts'], 
              role=sagemaker.get_execution_role())
   neo_model = m1.compile('ml_m5', 
              {'data':[1, ncols]}, 
              n_output_path, 
              sagemaker.get_execution_role(), 
              framework='xgboost', 
              framework_version='latest',
              job_name = 'neojob')
   

3. 一旦编译作业完成，我们可以按照以下方式部署编译后的模型：

   neo_predictor = neo_model.deploy(initial_instance_count = 1, instance_type = 'ml.m5.xlarge', 
                       serializer=CSVSerializer(),
                       deserializer=JSONDeserializer(),
                       endpoint_name='neo_endpoint')
   

4. 让我们测试端点以查看是否可以看到速度提升：

   for tl in t_lines[0:5]:
       result = smrt.invoke_endpoint(EndpointName='neo_endpoint',
                       ContentType="text/csv",
                       Body=tl.strip())
       rbody = \ StreamingBody(raw_stream=result['Body'],content_length=int(result['ResponseMetadata']['HTTPHeaders']['content-length']))
       print(f"Result from {result['InvokedProductionVariant']} = {rbody.read().decode('utf-8')}")
   

发送了几次调用请求后，让我们检查 CloudWatch 度量。回到编译端点的控制台页面，在监控部分点击查看调用度量，如下面的截图所示：

![图 10.6 – 端点控制台中的监控部分

![img/B17249_10_06.jpg]

图 10.6 – 端点控制台中的监控部分

现在，您将看到 CloudWatch 度量控制台，如下面的截图所示。在此，选择ModelLatency和OverheadLatency度量：

![图 10.7 – CloudWatch 度量控制台

![img/B17249_10_07.jpg]

图 10.7 – CloudWatch 度量控制台

在我的简单测试中，模型的延迟在常规 XGBoost 端点上是 10 毫秒，在用 Neo 编译后下降到 9 毫秒。如果您在低功耗设备上使用深度学习模型，编译模型的冲击将更为显著。

摘要

在本章中，我们探讨了多种提高推理性能和降低推理成本的方法。这些方法包括尽可能使用批量推理，在单个推理端点后面部署多个模型以降低成本并帮助进行高级金丝雀或蓝/绿部署，扩展推理端点以满足需求，以及使用 Elastic Inference 和 SageMaker Neo 以更低的成本提供更好的推理性能。

在下一章中，我们将讨论监控以及 ML 的其他重要操作方面。

第十一章：使用 Amazon SageMaker Model Monitor 和 Clarify 监控生产模型

监控生产机器学习（ML）模型是确保模型持续满足业务需求的关键步骤。除了托管模型的底层基础设施外，还有其他重要的 ML 模型方面需要定期监控。随着时间的推移，模型老化，与用于训练模型的相比，实际推理数据分布可能会发生变化。例如，零售行业的消费者购买模式可能会改变，金融行业的抵押贷款利率等经济条件可能会改变。

训练数据和实时推理数据集之间的这种逐渐偏差可能会对模型预测产生重大影响。模型质量指标，如准确性，也可能随着时间的推移而下降。模型质量的下降会对业务结果产生负面影响。监管要求，如确保 ML 模型无偏见且可解释，为模型监控增添了另一个角度。对这些方面的全面监控生产模型，让您能够主动识别生产模型是否需要更新。更新生产模型需要重新训练和部署资源。更新生产模型涉及的成本应与有效服务模型消费者的机会成本进行权衡。

本章通过使用两个托管服务——Amazon SageMaker Model Monitor和Amazon SageMaker Clarify，来解决监控生产模型的挑战。这些托管服务消除了构建自定义工具以监控模型和检测何时需要采取纠正措施的需求。在本章结束时，您将能够监控生产模型的数据漂移、模型质量、模型偏差和模型可解释性。您还将进一步了解如何在监控过程中自动修复检测到的问题。

在本章中，我们将涵盖以下主要内容：

• Amazon SageMaker Model Monitor 和 Amazon SageMaker Clarify 的基本概念

• 监控 ML 模型的全栈架构

• 监控 ML 模型的最佳实践

技术要求

您需要 AWS 账户才能运行本章包含的示例。如果您尚未设置数据科学环境，请参阅第二章，数据科学环境，其中将指导您完成设置过程。

书中包含的代码示例可在 GitHub 上找到，网址为github.com/PacktPublishing/Amazon-SageMaker-Best-Practices/tree/main/Chapter11。您需要安装 Git 客户端才能访问它们（git-scm.com/)。

Amazon SageMaker Model Monitor 和 Amazon SageMaker Clarify 的基本概念

在本节中，让我们回顾两个 SageMaker 功能提供的功能：Model Monitor 和 Clarify。

Amazon SageMaker Model Monitor 提供了监控作为 SageMaker 实时端点部署的模型的数据漂移和模型质量的功能。Amazon SageMaker Clarify 提供了监控部署模型是否存在偏差和特征归因漂移的功能。通过结合这两个功能，您可以监控在 SageMaker 上部署的机器学习模型的以下四个不同方面：

• 数据漂移：如果部署的模型提供的实时推理流量数据在统计上与模型训练时所用的训练数据不同，模型预测的准确性将开始下降。通过结合训练数据基线和定期监控来比较传入的推理请求与基线数据，SageMaker Model Monitor 检测数据漂移。Model Monitor 进一步生成与 Amazon CloudWatch 集成的数据漂移指标。使用这些 CloudWatch 警报，您可以生成数据漂移检测警报。

• 模型质量：监控模型质量涉及将模型预测的标签与实际标签（也称为真实推理标签）进行比较。Model Monitor 定期将来自实时推理的数据与真实标签合并，以比较模型质量漂移与使用训练数据生成的基线。与数据漂移指标类似，模型质量指标集成到 CloudWatch 中，因此如果模型质量低于阈值，可以生成警报。

• 偏差漂移：在实时推理流量数据和训练数据之间存在统计上显著的漂移也可能导致模型在一段时间内出现偏差。即使检测并解决了在训练和部署模型之前训练数据中的偏差，这也可能发生。SageMaker Clarify 持续监控部署的模型是否存在偏差，并生成与 CloudWatch 指标集成的偏差指标。

• 特征归因漂移：除了在部署的模型中引入偏差外，实时推理数据分布的漂移也可能导致特征归因值的变化。特征归因根据使用该数据集训练的模型中各个特征的相对重要性，使用重要性分数对数据集的各个特征进行排名。特征重要性分数提供了一种通过提供对哪些特征在预测中起作用的洞察来解释模型预测的方法。SageMaker Clarify 将训练数据中的特征归因或特征排名与实时推理流量数据中的特征归因或特征排名进行比较。与其他类型的监控类似，特征归因漂移指标被生成并集成到 CloudWatch 中。

使用 SageMaker Model Monitor 或 SageMaker Clarify 监控机器学习模型涉及以下四个高级步骤，如下所示图示：

![图 11.1 – 模型监控的高级步骤

图 11.1 – 模型监控的高级步骤

让我们更详细地看看这些步骤中涉及的内容：

1. 启用数据捕获：第一步是在实时端点上启用数据捕获。启用数据捕获后，SageMaker 端点的输入和输出将被捕获并保存在 Amazon 简单存储服务（S3）中。捕获的输入包括实时推理流量请求，捕获的输出包括部署的模型的预测。这是所有四种类型监控的共同步骤：数据漂移、模型质量、偏差漂移和特征归因漂移监控。

2. 生成基线：在这个步骤中，分析训练或验证数据以生成基线。生成的基线将在下一步中用于与实时推理流量进行比较。基线生成过程计算分析数据的指标，并为指标提出约束。生成的基线对于监控类型是唯一的。

3. 安排和执行监控作业：为了持续监控实时端点，下一步是创建一个预定义间隔执行的监控计划。一旦监控计划就绪，SageMaker Processing 作业将自动启动，以特定间隔分析从端点捕获的数据。对于监控作业的每次执行，处理作业将比较捕获的实时流量数据与基线。如果在某个时间段内捕获的实时流量数据生成的指标超出了基线建议的约束范围，将生成违规。计划中的监控作业还会为每次执行生成监控报告，这些报告保存在 S3 桶中。此外，还会生成 CloudWatch 指标，这些指标的具体指标取决于监控的类型。

4. 分析和采取行动：由监控作业生成的报告可以直接从 S3 下载或在 SageMaker Studio 环境中可视化。在 Studio 环境中，您还可以可视化监控作业的详细信息，并创建比较基线指标与监控作业计算的指标的图表。

为了修复发现的问题，您可以使用监控作业发出的 CloudWatch 指标。具体的指标取决于监控作业的类型。您可以根据基线作业建议的阈值值配置 CloudWatch 警报，CloudWatch 警报允许您自动响应监控作业生成的违规和指标。

现在您已经知道了可以监控 ML 模型的哪些方面，监控涉及的步骤以及如何应对发现的问题，您就可以构建一个满足您业务需求的监控解决方案。在下一节中，您将学习如何为不同类型的监控构建端到端模型监控架构。

监控机器学习模型的端到端架构

在本节中，您将组合监控的四个高级步骤，以构建数据漂移、模型质量、偏差漂移和特征归因漂移监控的端到端架构。除了架构之外，您还将深入了解适用于每种监控类型的各个步骤的独特方面。

对于所有四种类型的监控，第一步和最后一步——启用数据捕获和分析监控结果——保持不变。我们将详细讨论第一种监控类型——数据漂移监控的这两个步骤。对于其他三种类型的监控，我们只会简要提及。

数据漂移监控

您监控生产模型以检测数据漂移，以确保部署的模型所服务的实时推理流量的分布不会偏离用于训练模型的数据集的分布。以下图表显示了用于数据漂移监控的端到端架构：

让我们深入了解构成此端到端架构的四个高级步骤：

1. 为部署的端点启用数据捕获：第一步是部署一个启用数据捕获的 SageMaker 端点。如以下示例代码所示，配置数据捕获包括指定要捕获的推理流量的百分比和保存捕获流量的 S3 位置：

   from sagemaker.model_monitor import DataCaptureConfig
   data_capture_config = DataCaptureConfig(
   enable_capture=True, 
   sampling_percentage=100,  destination_s3_uri=s3_capture_upload_path
   )
   

   部署模型时，通过以下方式创建端点，并传入数据捕获配置：

   predictor = model.deploy(initial_instance_count=1,
                   instance_type='ml.m4.xlarge',
                   endpoint_name=endpoint_name,
                  data_capture_config = data_capture_config)
   

   以下代码显示了捕获的数据样本。如您所见，端点请求和响应以及事件元数据都被捕获了：

   {
     "captureData": {
       "endpointInput": {
         "observedContentType": "text/csv",
         "mode": "INPUT",
        "data": "0,2020,12,4,31,0,19.0,0.0,6.0,0.0,0.0,0.0,0.0,0.0,0.0,1.0\n",
         "encoding": "CSV"
       },
       "endpointOutput": {
         "observedContentType": "text/csv; charset=utf-8",
         "mode": "OUTPUT",
         "data": "-4.902510643005371",
         "encoding": "CSV"
       }
     },
     "eventMetadata": {
       "eventId": "e68592ca-948c-44dd-a764-608934e49534",
       "inferenceTime": "2021-06-28T18:41:16Z"
     },
     "eventVersion": "0"
   }
   

2. 使用DefaultModelMonitor来配置执行处理作业的基础设施和最大运行时间。以下是一个示例代码：

   from sagemaker.model_monitor import DefaultModelMonitor
   from sagemaker.model_monitor.dataset_format import DatasetFormat
   my_default_monitor = DefaultModelMonitor(
       role=role,
       instance_count=1,
       instance_type="ml.m5.xlarge",
       volume_size_in_gb=20,
       max_runtime_in_seconds=3600,
   )
   

   使用DefaultModelMonitor上的suggest_baseline方法来配置并启动基线作业。要配置基线作业，指定基线数据的位置以及您希望将基线结果保存到 S3 的位置，如下所示：

   my_default_monitor.suggest_baseline(
       baseline_dataset=baseline_data_uri + "/training-dataset-with-header.csv",
       dataset_format=DatasetFormat.csv(header=True),
       output_s3_uri=baseline_results_uri,
       wait=True
   )
   

   基线作业会在您指定的 S3 位置生成两个文件——statistics.json和constraints.json。statistics.json文件包括对训练数据的元数据分析——例如数值特征的求和、平均值、最小值和最大值以及文本特征的唯一计数。

   注意

   此基线作业使用 SageMaker 提供的名为sagemaker-model-monitor-analyzer的容器来分析训练数据集。这个基于 Spark 的容器使用开源的constraints.json文件捕获用于监控目的的统计阈值。约束还包括条件，例如是否应将特定特征视为字符串而不是整数，或者是否特定字段不应为空。以下截图显示了基线作业生成的约束样本，表明value特征应始终被视为字符串：

   ![Figure 11.5 – 数据漂移基线作业生成的约束]

   ![img/B17249_11_05.jpg]

   图 11.5 – 数据漂移基线作业生成的约束

   生成的约束还表明了每个特征的完整性，这代表了在推理流量中可以非空值的百分比。在这个例子中，由于所有特征的完整性都是1.0，因此在推理流量中这些特征的任何值都不能为空。此外，根据num_constraints.is_non_negative的建议，没有任何整数和小数特征可以为空。

   生成的约束是基线作业在分析训练数据后提供的建议。您可以根据您对特定用例的领域知识选择覆盖约束文件。您可以在单个字段级别覆盖建议的约束，或者覆盖整个文件。在constraints.json文件中，您还会看到emit_metrics : Enabled条目。这表明在监控期间将发出 CloudWatch 指标。

3. 完整性和基线漂移。完整性指标表示在特定区间内给定特征可以 null 的值的百分比。基线漂移指标表示特征在特定区间内相对于基线的漂移程度。此外，对于数值特征，在区间内观察到的其他一些指标是最大值、最小值、总和、样本计数和平均计数。

   对于这些指标中的任何一个，您都可以根据约束文件中建议的阈值值配置 CloudWatch 警报。如果在给定区间内观察到的推理流量中的特征值违反了阈值值，则会触发警报。

4. 分析和采取行动：最后一步是对监控结果进行分析并采取行动。如前所述的高层次监控步骤讨论中提到，您可以从 S3 下载监控报告并在您的笔记本环境中分析它们，或者使用 Studio 查看监控细节。例如，将违规报告下载到笔记本环境中并查看报告内容，显示的结果类似于以下截图：

![Figure 11.7 – 数据漂移监控作业生成的违规]

![img/B17249_11_07.jpg]

图 11.7 – 数据漂移监控作业生成的违规

您可以根据您的业务和运营需求决定对这些警报采取什么行动。您可以根据 CloudWatch 警报触发的响应自动执行操作，如更新模型、更新您的训练数据以及重新训练和更新模型。

重要提示

GitHub 仓库 gitlab.com/randydefauw/packt_book/-/blob/main/CH10/data_drift_monitoring/WeatherPredictionDataDriftModelMonitoring.ipynb 中提供了一个示例笔记本，该笔记本提供了使用 SageMaker Model Monitor 进行数据漂移监控的完整教程。

模型质量漂移监控

您监控生产模型的性能，以确保生产模型的性能持续满足您的需求。模型质量根据底层机器学习问题的类型通过不同的指标来衡量。例如，对于分类问题，准确率或召回率是好的指标，均方根误差（RMSE）是用于回归问题的指标。

监控模型质量漂移的端到端架构如下所示：

图 11.8 – 模型质量监控：端到端架构

架构与数据漂移监控非常相似，但增加了一个步骤，将实际推理真实标签与模型预测合并到一个 S3 存储桶中。让我们深入了解这个端到端架构中的四个高级步骤：

1. 为部署的端点启用数据捕获：第一步是部署一个启用数据捕获的 SageMaker 端点，并在 S3 存储桶中捕获模型做出的预测。

2. probability（概率）、prediction（预测）和 label（标签）。其中 probability 是模型返回的值，prediction 是基于阈值值从概率推断出来的。label 代表验证集的真实标签：

   with open(f"test_data/{validate_dataset}", "w") as baseline_file:
       baseline_file.write("probability,prediction,label\n")  # Header of the file
       for tl in t_lines[1:300]:
           #Remove the first column since it is the label
           test_list = tl.split(",")
           label = test_list.pop(0)
           test_string = ','.join([str(elem) for elem in test_list])
   
           result = smrt.invoke_endpoint(EndpointName=endpoint_name,
            ContentType="text/csv", Body=test_string)   
           rbody = StreamingBody(raw_stream=result['Body'],content_length=int(result['ResponseMetadata']['HTTPHeaders']['content-length']))
           prediction = rbody.read().decode('utf-8')
           baseline_file.write(f"{prediction},{prediction},{label}\n")
           #print(f"label {label} ; prediction {prediction} ")
           print(".", end="", flush=True)
           sleep(0.5)
   

   对于模型质量监控，您使用 ModelQualityMonitor 配置基础设施以执行处理作业和最大运行时间，如下所示：

   # Create the model quality monitoring object
   model_quality_monitor = ModelQualityMonitor(
       role=role,
       instance_count=1,
       instance_type="ml.m5.xlarge",
       volume_size_in_gb=20,
       max_runtime_in_seconds=1800,
       sagemaker_session=session,
   )
   

   使用 suggest_baseline 方法配置并启动基线作业。要配置基线作业，指定基线数据的位置以及您希望将基线结果保存到 S3 的位置，如下所示：

   cut the baseline suggestion job.
   # You will specify problem type, in this case Binary Classification, and provide other requirtributes.
   job = model_quality_monitor.suggest_baseline(
       job_name=baseline_job_name,
       baseline_dataset=baseline_dataset_uri,
       dataset_format=DatasetFormat.csv(header=True),
       output_s3_uri=baseline_results_uri,
       problem_type="Regression",
       inference_attribute="prediction",
       probability_attribute="probability",
       ground_truth_attribute="label",
   )
   job.wait(logs=False)
   

   基线作业生成了两个文件 – statistics.json 和 constraints.json – 保存在您指定的 S3 位置。

   以下图显示了基线作业生成的统计信息：

   

   

   图 11.9 – 模型质量基线作业生成的统计信息

   类似地，以下图也显示了基线作业生成的统计信息：

   

   图 11.10 – 模型质量基线作业生成的约束

   如您在 图 11.10 中所见，生成的约束之一是针对 rmse 模型的。它建议，如果生产模型的 rmse 值在任何时间间隔内大于 3.87145，则表明模型质量正在下降。如果基线作业建议的任何约束对于您的需求来说过于严格或过于宽松，您可以修改约束文件。

3. confusion_matrix、recall 和 precision。

   注意

   要查看生成的完整指标列表，请查阅 SageMaker 文档 docs.aws.amazon.com/sagemaker/latest/dg/model-monitor-model-quality-metrics.html。

   对于这些指标中的任何一个，您可以根据约束文件中建议的阈值值配置 CloudWatch 警报。如果在给定时间间隔内观察到的推理流量中的模型预测违反了阈值值，则会触发 CloudWatch 警报。

4. 分析和采取行动：最后，为了分析和采取监控结果，类似于草稿偏差监控结果，您可以直接从 S3 访问监控报告，在您的笔记本或 Studio 环境中可视化它们，并最终自动化对触发的 CloudWatch 警报的响应。

   重要提示

   GitHub 仓库 gitlab.com/randydefauw/packt_book/-/blob/master/CH10/model_quality_monitoring/WeatherPredictionModelQualityMonitoring.ipynb 中提供了一个示例笔记本，它详细介绍了如何使用 SageMaker Model Monitor 进行质量模型监控。

偏差漂移监控

偏差的概念与数据集的个体特征相关。偏差通常用于测量敏感特征，称为方面，以确定数据集中是否存在任何特定特征或一组特征值被不成比例地表示。Amazon Clarify 提供了检测和监控预训练数据集和部署模型中偏差的能力。以下图表显示了用于监控部署模型偏差漂移的端到端架构：

图 11.11 – 偏差漂移和特征归因监控：端到端架构

让我们深入了解这个端到端架构中涉及的四个高级步骤：

1. 为部署的端点启用数据捕获：偏差漂移监控的第一步与其他类型的监控相同——在部署 SageMaker 端点时启用数据捕获。

2. DataConfig。以下是一个示例代码：

   model_bias_data_config = DataConfig(
       s3_data_input_path=validation_dataset,
       s3_output_path=model_bias_baselining_job_result_uri,
       label=label_header,
       headers=all_headers,
       dataset_type='CSV'
   )
   

   BiasConfig 捕获了被认为是偏差的敏感特征及其阈值值的详细信息。在以下代码中，我们正在监控 "City" 特征的偏差漂移：

   model_bias_config = BiasConfig(
       label_values_or_threshold=[1],
       facet_name="City",
       facet_values_or_threshold=[100],
   )
   

   要计算偏差指标，需要一个部署的模型来执行推理。ModelConfig 捕获此模型的相关信息如下：

   model_config = ModelConfig(
       model_name=model_name,
       instance_count=endpoint_instance_count,
       instance_type=endpoint_instance_type,
       content_type=dataset_type,
       accept_type=dataset_type,
   )
   

   最后，ModelPredictedLabelConfig 指示如何从模型输出中提取预测标签。例如，以下示例代码指示如果模型返回的概率高于 0.8，则预测为 1：

   model_predicted_label_config = ModelPredictedLabelConfig(
       probability_threshold=0.8,
   )
   

   拥有 DataConfig、BiasConfig、ModelConfig 和 ModelPredictedLabelConfig，您就可以创建并启动基线作业了。以下是一个示例代码：

   model_bias_monitor = ModelBiasMonitor(
       role=role,
       sagemaker_session=sagemaker_session,
       max_runtime_in_seconds=1800,
   )
   model_bias_monitor.suggest_baseline(
       model_config=model_config,
       data_config=model_bias_data_config,
       bias_config=model_bias_config,
       model_predicted_label_config=model_predicted_label_config,
   )
   

   在基线作业执行期间，SageMaker 创建一个临时端点，称为影子端点。基线作业在验证数据集上运行预测，计算偏差指标，并建议对这些指标的限制。一旦计算了偏差指标，影子端点将被删除。

   基线作业执行结果生成一个约束文件，显示计算的偏差指标值以及建议的阈值。以下显示了生成的约束样本：

   {
       "version": "1.0",
       "post_training_bias_metrics": {
           "label": "value",
           "facets": {
               "city": [
                   {
                    "value_or_threshold": "(100.0, 2278.0]",
                       "metrics": [
                           {
                               "name": "AD",
                  "description": "Accuracy Difference (AD)",
                               "value": 0.008775168751768203
                           },
                          ...
               ]
    },
           "label_value_or_threshold": "(1.0, 130.24536736711912]"
       }
   

3. 安排和执行模型质量监控作业：下一步是安排偏差漂移监控作业。在此步骤中，将监控的模型偏差与上一步生成的基线进行比较。SageMaker 将根据您指定的计划定期使用 SageMaker Processing 执行偏差漂移监控作业。偏差漂移监控作业生成监控报告和违反约束，以及 CloudWatch 指标。

4. 分析和采取行动：最后，分析和采取行动与之前的监控类型相似。

该架构端到端流程的实现提供在笔记本中。请查看笔记本和执行结果，以查看生成的偏差指标。

重要提示

在 GitHub 仓库 gitlab.com/randydefauw/packt_book/-/blob/master/CH10/bias_drift_monitoring/WeatherPredictionBiasDriftMonitoring.ipynb 中提供了一个示例笔记本，该笔记本详细介绍了如何使用 SageMaker Model Monitor 进行质量模型监控。

特征归因漂移监控

特征归因根据使用该数据集训练的模型中各个特征的相对重要性对数据集的各个特征进行排名，使用重要性分数。特征重要性分数提供了一种解释模型预测的方法，通过提供有关哪些特征在做出预测中起作用的见解。通过对模型的持续监控，您可以确定实时推理流量的特征归因何时开始偏离训练数据集的特征归因。

监控特征归因漂移的端到端流程与之前在图 11.11中显示的偏差漂移监控流程相同。让我们深入了解涉及此端到端架构的四个高级步骤：

1. 启用部署端点的数据捕获：特征归因漂移监控的第一步与其他类型的监控相同——在部署 SageMaker 端点时启用数据捕获。

2. DataConfig和ModelConfig，它们捕获数据和模型细节，与偏差漂移监控相同。

   然而，您将需要配置SHAPConfig来捕获敏感特征，而不是使用BiasConfig，SHAPConfig捕获要使用的基线数据集、在 Kernel SHAP 算法中使用样本的数量以及确定全局 SHAP 值的方法。以下是一个示例代码：

   # Here use the mean value of test dataset as SHAP baseline
   test_dataframe = pd.read_csv(test_dataset, header=None)
   shap_baseline = [list(test_dataframe.mean())]
   shap_config = SHAPConfig(
       baseline=shap_baseline,
       num_samples=100,
       agg_method="mean_abs",
       save_local_shap_values=False,
   )
   

   对于特征归因漂移监控，您使用ModelExplainabilityMonitor配置基础设施以执行处理作业和最大运行时间，如下面的代码所示。ModelExplainabilityMonitor使用特征重要性分数解释模型预测并检测特征归因漂移：

   model_explainability_monitor = ModelExplainabilityMonitor(
       role=role,
       sagemaker_session=sagemaker_session,
       max_runtime_in_seconds=1800,
   )
   

   拥有不同配置对象后，你现在可以启动基线作业，如下所示：

   model_explainability_monitor.suggest_baseline(
       data_config=model_explainability_data_config,
       model_config=model_config,
       explainability_config=shap_config,
   

   基线作业执行结果生成一个约束文件，显示计算的特征重要性值以及建议的阈值。以下是生成的约束示例：

   {
       "version": "1.0",
       "explanations": {
           "kernel_shap": {
               "label0": {
                   "global_shap_values": {
                       "ismobile": 0.00404293281766823,
                       "year": 0.006527703849451637,
                        ...
                        "co": 0.03389338421306029
                   },
                   "expected_value": 0.17167794704437256
               }
           }
       }
   }
   

3. 安排并执行模型质量监控作业：安排特征归因监控作业的下一步与安排偏差漂移监控作业类似。

4. https://gitlab.com/randydefauw/packt_book/-/blob/master/CH10/bias_drift_monitoring/WeatherPredictionFeatureAttributionDriftMonitoring .ipynb].

现在让我们总结四种不同监控类型的详细信息。以下表格显示了迄今为止讨论的监控类型的总结，并关注每种监控类型的独特方面：

![图 11.12 – 模型监控概要

![img/B17249_Table-02.jpg]

图 11.12 – 模型监控概要

现在您可以使用 SageMaker Clarify 和 Model Monitor 构建用于监控部署模型不同方面的端到端架构，在下一节中，您将了解使用这些功能的最佳实践以及一些限制。

监控机器学习模型的最佳实践

本节讨论了使用 SageMaker Model Monitor 和 SageMaker Clarify 监控模型的最佳实践，考虑到这些功能的底层操作以及本书出版时的某些限制：

• 选择正确的数据格式：Model Monitor 和 Clarify 只能监控表格数据的漂移。因此，请确保您的训练数据是表格格式。对于其他数据格式，您将不得不构建自定义监控容器。

• 选择实时端点作为模型部署模式：Model Monitor 和 Clarify 支持对单个模型实时端点的监控。不支持对用于批量转换或多模型端点的模型进行监控。因此，请确保您想要监控的模型以单个模型实时端点的方式部署。此外，如果模型是推理管道的一部分，则整个管道都会被监控，而不是管道中构成的单个模型。

• 选择采样数据捕获 - 采样百分比：当您在实时端点上启用数据捕获时，需要注意的一个配置参数是 采样百分比，它表示捕获了多少比例的实时流量。选择此指标值取决于您的用例。这是在保存推理流量量和模型监控的有效性之间的一种权衡。如果此参数的值接近 100，则存储的信息更多，导致更高的存储成本，以及更多用于监控作业分析的数据，从而导致较长的执行时间。另一方面，更高的采样百分比会导致捕获更多与基线进行比较的推理流量模式。

  如果您的生产模型在动态环境中运行，例如零售或金融服务，在这些环境中消费者行为或环境因素经常变化，影响模型预测，最佳实践是使用 100% 的采样百分比。

• 选择用于基线生成的数据集：对于生成基线，通常使用训练数据集是一个很好的选择。在生成基线时，请注意，训练数据集中的第一列被认为是标签。除了标签之外，确保推理流量中的特征数量和顺序与训练数据集相匹配。

  此外，对于偏差漂移和特征归因漂移，基线生成过程会启动一个影子端点来收集预测。因此，在执行基线作业时，请考虑您 AWS 账户中活动端点的数量限制。

• 选择监控计划执行频率：如你所见，监控作业是周期性执行的，最小间隔长度为 1 小时。这个最小间隔是必要的，因为需要收集足够的推理流量来与基线进行比较。在确定监控执行频率时，你应该根据模型所服务的推理流量选择这个间隔。例如，作为繁忙的电子商务网站部署的一部分的模型可能需要处理更高的流量量，因此每隔几个小时运行一次监控作业将给你快速检测数据和模型质量问题的机会。然而，每次执行监控作业都会增加你的模型监控成本。因此，监控作业计划应考虑在稳健地检测模型问题和监控成本之间的权衡。

  注意

  监控作业的预定时间和执行之间可能会有 0-20 分钟的延迟。

• ModelQualityJobInput参数的StartOffset和EndOffset字段。StartOffset指定从开始时间减去的时间，EndOffset指定从监控作业结束时间减去的时间。偏移量格式为-P#D、-P#M或-P#H，其中D、M和H分别代表天、分钟和小时，#是数字。例如，StartOffset的-P7H值将导致监控作业在预定时间后 7 小时开始。

  此外，确保监控计划的节奏是这样的，任何给定的执行应在后续执行开始之前完成，以便每个间隔内都能完成真实合并作业和监控作业。

• 自动化修复操作：虽然监控解决方案可以主动检测数据和模型问题，但没有适当的行动计划来处理这些问题，你无法确保模型持续满足你的业务需求。为了最大限度地利用生成的模型监控警报的好处，尽可能自动化你需要执行的操作。例如，自动化发送给运维和数据科学团队的有关可能的数据和模型问题的通知。同样，自动化收集或导入新的训练数据，并在非生产环境（如开发/测试和预发布）中触发模型的重新训练和测试。

• sagemaker-model-monitor-analyzer提供了本章迄今为止我们已经审查过的功能。这个基于 Spark 的容器是在开源 Deequ 框架上构建的，提供了一系列功能，例如生成统计数据、建议约束、验证约束与基线，以及发出 CloudWatch 指标。

  在可能的情况下，选择使用此内置容器，因为 SageMaker 承担了确保、管理和更新此容器以添加新功能的负担。您可以通过提供自己的预处理和后处理脚本来扩展此容器的功能。例如，您可以使用自定义预处理脚本来对数据进行小幅度修改，例如将数组转换为基线作业所需的扁平化 JSON。同样，您可以对监控结果进行后处理以进行更改。

  除了使用 SageMaker 提供的容器外，您还可以使用自己的容器进行自定义监控。自定义容器允许您构建自己的监控计划以及生成自定义统计信息、约束和违规的自己的逻辑，同时还有自定义的 CloudWatch 指标。在创建自定义容器时，您应遵循 SageMaker 发布的输入和输出合约。此外，您将负责注册、管理和更新此自定义容器。

• 在监控工作流程中包含人工审查：对于一些关键机器学习应用，例如，例如，一个金融贷款审批应用，通常需要将人工审查人员纳入监控循环。特别是在机器学习模型返回置信度低的预测时，专家需要确保预测的有效性。Amazon A2I 允许您配置自定义监控工作流程，以包含人工专家审查 SageMaker 模型的预测。请参阅 参考文献 部分，以获取有关使用 SageMaker 和 Amazon A2I 配置自定义人工在环工作流程的详细博客链接。

使用本节讨论的最佳实践来创建最适合您的业务和组织要求的模型监控配置。

摘要

在本章中，您学习了监控在生产中部署的机器学习模型的重要性以及需要监控的模型的不同方面。您深入研究了多个端到端架构，以使用 SageMaker Model Monitor 和 SageMaker Clarify 构建持续监控、自动响应检测到的数据和模型问题。您学习了如何使用生成的各种指标和报告来深入了解您的数据和模型。

最后，我们以讨论配置模型监控的最佳实践作为总结。利用本章讨论的概念，您可以构建一个全面的监控解决方案，以满足您的性能和监管要求，而无需使用各种不同的第三方工具来监控模型的不同方面。

在下一章中，我们将介绍端到端机器学习工作流程，该工作流程将 ML 过程中涉及的各个单独步骤连接起来。

参考文献

对于额外的阅读材料，请查阅以下参考文献：

• 使用 Amazon SageMaker Model Monitor 自动监控您的机器学习模型，并通过 Amazon A2I 将预测发送到人工审查工作流程：

  使用 Amazon SageMaker 模型监控自动监控您的机器学习模型，并通过 Amazon A2I 将预测发送到人工审查工作流程

第四部分：自动化和实施机器学习

在本节中，我们将根据安全性、可靠性、性能和成本优化的最佳实践，构建自动化工作流程和端到端机器学习解决方案的 MLOps 管道。

本节包含以下章节：

• 第十二章，机器学习自动化工作流程

• 第十三章，使用 Amazon SageMaker 构建良好架构的机器学习

• 第十四章，跨账户管理 SageMaker 功能

第十二章：机器学习自动化工作流程

对于部署到生产环境中的机器学习（ML）模型，建立一致且可重复的过程来重新训练、部署和操作这些模型非常重要。随着在生产环境中运行的 ML 模型数量的增加，这一点变得越来越重要。机器学习开发生命周期（ML 生命周期）在实施 ML 工作流程时带来了一些独特的挑战。这一点将在本章中讨论。我们还将讨论常见的模式，不仅自动化 ML 工作流程，而且为 ML 管道实施持续集成（CI）和持续交付/部署（CD）实践。

尽管我们将在本章中涵盖自动化 ML 工作流程和构建 ML 的 CI/CD 管道的各种选项，但我们特别关注使用 Amazon SageMaker Pipelines 和 Amazon SageMaker 项目进行详细实现模式。SageMaker Pipelines 专为包括自动化构建模型所需的步骤的活动而设计，例如数据准备、模型训练和模型评估任务。SageMaker 项目通过将 CI/CD 实践纳入您的 ML 管道来构建在 SageMaker Pipelines 的基础上。SageMaker 项目利用 SageMaker Pipelines 结合 SageMaker 模型注册表构建端到端 ML 管道，这些管道还纳入了 CI/CD 实践，如源代码控制、版本管理和自动化部署。

本章将涵盖以下主题：

• 自动化 SageMaker ML 工作流程的考虑因素

• 使用 Amazon SageMaker Pipelines 构建 ML 工作流程

• 使用 Amazon SageMaker 项目创建 CI/CD ML 管道

自动化 SageMaker ML 工作流程的考虑因素

在本节中，我们将回顾一个典型的 ML 工作流程，包括模型构建和部署活动的基本步骤。理解每个步骤的关键 SageMaker 输入和工件对于构建自动化工作流程非常重要，无论您选择使用哪种自动化或工作流程工具。

此信息已在第八章中介绍，使用模型注册表按比例管理模型。因此，如果您尚未阅读该章节，建议在继续阅读本章之前先阅读。我们将在此基础上构建信息，并涵盖构建 SageMaker 工作流程的自动化工作流程和 CI/CD 管道的高级考虑因素和指导。我们还将简要介绍在构建自动化工作流程和 CI/CD ML 管道时常用的 AWS 原生服务选项。

典型的 ML 工作流程

一个机器学习工作流程包含构建机器学习模型所需的全部步骤，随后是部署和在生产环境中运行该模型所需的步骤。图 12.1展示了包含模型构建和模型部署步骤的典型机器学习工作流程。工作流程中的每一步通常都有多个相关任务。例如，数据准备可能包括将数据转换成与你的机器学习算法一致格式的多个任务。

当我们考虑自动化端到端的机器学习工作流程时，我们寻求自动化步骤中包含的任务，以及如何编排步骤的顺序和时机到一个端到端的管道中。因此，了解每一步的关键输入以及步骤的预期输出或工件对于构建端到端管道至关重要。

此外，模型开发是一个迭代的过程。因此，可能需要多次实验才能找到一个满足模型性能标准的候选模型。因此，在找到可以注册到模型注册表的候选模型之前，通常会在数据科学沙盒环境中继续进行实验。这表明模型已准备好部署到一个或多个目标环境进行进一步测试，然后部署到生产环境。

参考以下图例，了解典型工作流程的示例：

![图 12.1 – 典型机器学习工作流程

图 12.1 – 典型机器学习工作流程

模型部署后，还可能需要额外的任务来将模型与现有的客户端应用程序集成。还可能需要创建一个更复杂的推理工作流程，该工作流程包括多个模型和推理所需的任务。最后，仍需要执行操作该模型的任务。尽管操作步骤位于最后，但需要考虑在早期过程中执行该模型持续运行所需的活动。这是为了确保在自动化工作流程中包含所有必要的任务，以及确保关键指标被捕获并可供关键角色使用。此外，这还允许你根据需要设置警报。这包括以下活动：

• 模型监控：这包括确保您的模型性能随时间不退化的任务。此主题在第十一章，使用 Amazon SageMaker 模型监控和 Clarify 监控生产模型中详细说明。然而，在构建您的自动化部署工作流时，考虑可能需要在管道中包含和自动化的额外任务是很重要的。例如，SageMaker 模型监控对于数据漂移需要诸如基准测试您的训练数据、在您的端点上启用数据捕获以及安排 SageMaker 监控作业等任务。所有这些任务都应自动化并包含在您的自动化工作流中。您还可以利用带有Amazon 增强 AI（Amazon A2I）的人工审核来检查低置信度预测，这些预测可以与 SageMaker 模型监控一起实施，或作为其补充。

• 系统监控：系统监控包括捕获和警报对托管您的模型以及支持已部署机器学习解决方案的其他资源至关重要的指标。例如，Amazon SageMaker 将自动捕获端点的关键指标，例如 CPU/GPU 利用率或调用次数。在 Amazon CloudWatch 中设置阈值和创建警报有助于确保托管模型的资源以及其他解决方案组件的整体健康。

• 模型重新训练：为了设置自动模型重新训练，应在模型构建步骤中执行的任务被捕获为可以作为模型构建管道一部分执行的代码。此管道将包括每个步骤内所有任务的自动化，以及这些步骤的编排。

• 管道监控：如果您为模型构建和模型部署活动设置了自动化管道，那么在您的管道上实施监控也很关键，以确保在管道中的步骤失败时您会收到通知。

我们已经覆盖了机器学习工作流中的通用步骤。然而，由于许多因素，每个自动化工作流和 CI/CD 管道都可能有所不同。在下一节中，我们将讨论一些在机器学习用例中常见的考虑因素。

构建 SageMaker 工作流和 CI/CD 管道的考虑和指导

在机器学习工作流中执行的任务可能因用例而异；然而，当为您的机器学习用例构建自动化工作流时，以下高级实践是推荐的：

• 实施模型注册表：模型注册表有助于连接模型构建实验阶段和将模型部署到更高级环境之间的步骤。模型注册表捕获关键元数据，如模型指标。它还确保您能够跟踪关键输入和工件以实现可追溯性，以及管理跨环境的多个模型版本。

• 版本输入和工件：能够回滚或重新创建特定模型版本或可部署工件的能力取决于知道创建该资源所使用的输入和工件的具体版本。例如，要重新创建 SageMaker 端点，你需要知道关键版本信息，例如模型工件和推理容器镜像。这些输入和工件应免受意外删除的保护。它们还应通过端到端管道进行跟踪，以便能够自信地作为自动化工作流程的一部分重新创建资源。

自动化工作流程和 CI/CD 管道中的 AWS 原生选项

在本章中，我们主要关注 SageMaker 原生选项用于创建自动化工作流程，以及在端到端管道中叠加 CI/CD 实践。然而，还有其他选项也可以用于创建包含 SageMaker 任务的自动化工作流程，这些任务用于模型构建和模型部署。还有第三方选项包含与 SageMaker 的操作符或集成。然而，这些内容在本书中并未涉及。

首先，我们将介绍一些可以用于构建包含 SageMaker 任务的自动化工作流程的 AWS 服务和功能：

• AWS Step Functions：AWS Step Functions (aws.amazon.com/step-functions/?step-functions.sort-by=item.additionalFields.postDateTime&step-functions.sort-order=desc) 允许你创建包含与多个 AWS 服务集成的自动化无服务器工作流程，同时赋予你将第三方任务集成到工作流程中的能力。AWS Step Functions 还具有对 SageMaker 任务的本地支持，例如 SageMaker 处理作业、SageMaker 训练作业和 SageMaker 托管选项。

  此外，ML 构建者可以选择利用 AWS Step Functions 数据科学 SDK (docs.aws.amazon.com/step-functions/latest/dg/concepts-python-sdk.html)，使用 Python 而不是通过 Amazon States 语言来创建 ML 工作流程。Amazon States 语言是 AWS Step Functions 的原生管道语法。AWS Step Functions 提供了跨 AWS 服务的可扩展性，具有与在 ML 工作流程中最常使用的 AWS 服务（如 AWS Lambda、Amazon EMR 或 AWS Glue）的本地集成。

• Amazon Managed Workflows for Apache Airflow：Amazon Managed Workflows for Apache Airflow (aws.amazon.com/managed-workflows-for-apache-airflow/) 允许您通过与其他常用 AWS 服务（如 SageMaker）的本地集成来创建自动化的机器学习工作流程。许多组织和团队已经使用或投资了 Airflow，因此这项服务提供了一种方式，通过使用包括与 SageMaker 的本地集成在内的托管服务来利用这些现有投资。

• Amazon SageMaker Operators for Kubernetes：SageMaker Operators for Kubernetes (docs.aws.amazon.com/sagemaker/latest/dg/amazon-sagemaker-operators-for-kubernetes.html) 允许团队使用 Kubernetes API 和命令行 Kubernetes 工具（如 kubectl）原生地创建 SageMaker 任务。

• Amazon SageMaker Components for Kubeflow Pipelines：SageMaker Components for Kubeflow Pipelines 允许团队继续利用 Kubeflow 进行工作流程编排，同时提供与 SageMaker 的集成，以便您可以在托管环境中创建和运行 SageMaker 作业，而无需直接在您的 Kubernetes 集群上运行。这对于利用端到端托管的 SageMaker 功能很有用，同时也适用于您不希望在集群上直接执行这些任务的情况。

接下来，我们将介绍一些 AWS 服务和功能，这些服务可以用于将 CI/CD 实践集成到您的机器学习管道中。这些服务不仅限于机器学习，还可以替代提供类似功能的第三方工具：

• AWS CodeCommit：AWS CodeCommit (aws.amazon.com/codecommit/) 是一个基于 Git 的私有源代码仓库。对于机器学习管道，AWS CodeCommit 可以存储任何相关的源代码，例如 基础设施即代码（IaC）和配置即代码（CaC），数据处理代码，训练代码，模型评估代码，管道代码和模型部署代码。您的存储库结构可能有所不同，但通常建议至少将模型构建和模型部署代码分开。

• AWS CodeBuild：AWS CodeBuild (aws.amazon.com/codebuild/) 是一个完全托管的构建服务，可用于多种用途。这包括编译源代码，运行测试，以及作为管道的一部分运行自定义脚本。对于机器学习管道，AWS CodeBuild 可以用于测试通过自定义脚本和打包 AWS CloudFormation 模板等任务。

• AWS CodePipeline：AWS CodePipeline (aws.amazon.com/codepipeline/) 是一个完全托管的 CD 服务，可用于编排您的 ML 管道步骤。AWS CodePipeline 可用于编排模型构建任务和模型部署任务的步骤。

前面的 AWS 服务列表可用于为您的 ML 管道融入 CI/CD 实践。您还可以选择用 GitHub、BitBucket 或 Jenkins 等第三方选项替换上述服务。

在本节中，我们讨论了在自动化关键步骤的任务以及提供整体编排以自动化这些步骤的背景下，一个高级 ML 工作流程。我们还讨论了构建您的 ML 工作流程时的一些关键考虑因素。我们回顾了创建自动化 ML 工作流程的 AWS 原生选项。然后我们查看可用于融入 CI/CD 实践的 AWS 服务。

所有这些，以及许多第三方选项，都是选择自动化 SageMaker 工作流程的正确工具时的有效选项。决定使用前面提到的服务自定义构建工作流程，或者决定用第三方选项替换上述服务，通常来自个人偏好或组织标准或要求利用现有工具。

在本章剩余部分，我们将重点关注 SageMaker 原生能力，用于自动化您的 ML 工作流程并融入 CI/CD 实践。

使用 Amazon SageMaker Pipelines 构建 ML 工作流程

模型构建工作流程涵盖了开发模型时执行的所有步骤，包括数据准备、模型训练、模型调优和模型部署。在这种情况下，模型部署可以包括评估您的模型所需的任务，以及不需要部署到更高环境的批量用例。SageMaker Pipelines 是一个完全托管的托管服务，允许您使用 SageMaker Python SDK 创建自动化的模型构建工作流程。

SageMaker Pipelines 包含用于执行 SageMaker 任务（如 SageMaker Processing 用于数据预处理和 SageMaker Training 用于模型训练）的内置步骤类型 (docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-steps.html)。Pipelines 还包括控制您的管道如何工作的步骤。例如，管道可以包括条件步骤，用于评估前一个步骤的输出，以确定是否继续到管道中的下一个步骤。

要包括执行其他 AWS 服务或非 AWS 任务的步骤，您必须使用 回调步骤。如果您在管道中使用另一个 AWS 服务执行任务，这将非常有用。一个例子是如果您正在使用 AWS Glue 进行数据预处理。图 12.2 在先前的流程图的基础上，表明 SageMaker Pipelines 在端到端工作流程中的位置，以及为每个模型构建工作流程步骤提供支持的 SageMaker 功能示例：

![图 12.2 – SageMaker 管道模型构建工作流程

图 12.2 – SageMaker 管道模型构建工作流程

在本节中，您将为您的机器学习用例构建一个 SageMaker 管道。该管道将包括数据准备、模型训练和模型评估所需的全部步骤。由于我们不需要 SageMaker 的每个功能来构建我们的管道，您将只使用以下图中注明的功能：

![图 12.3 – SageMaker 管道示例管道

图 12.3 – SageMaker 管道示例管道

对于您 SageMaker 管道中的每个步骤，您首先需要配置您将执行的任务（例如，训练作业），然后配置该任务的 SageMaker Pipelines 步骤。配置完所有步骤后，将步骤链接在一起，然后执行管道。以下各节将指导您构建用于示例用例的 SageMaker 管道。

构建您的 SageMaker 管道

在本节中，我们将介绍配置您 SageMaker 管道中每个步骤所需的步骤，以及如何将这些步骤链接在一起，并最终执行您的模型构建管道。对于您管道中的每个步骤，您需要遵循以下两个步骤：

1. 配置 SageMaker 作业。

2. 配置 SageMaker Pipelines 步骤。

图 12.4 展示了我们构建管道将使用的步骤：

![图 12.4 – 使用 SageMaker 步骤的管道用例

图 12.4 – 使用 SageMaker 步骤的管道用例

我们将从数据准备步骤开始，在此步骤中，我们将使用 SageMaker Processing 将我们的原始数据转换为算法期望的格式。

数据准备步骤

在此步骤中，您将配置用于将您的数据转换为算法期望格式的 SageMaker 处理作业。为此，我们将使用来自 第四章，使用 Amazon SageMaker Data Wrangler 和 Processing 进行大规模数据准备 的相同配置：

1. 首先，我们将配置 SageMaker 处理作业，如下所示：

   from sagemaker.spark.processing import PySparkProcessor 
   spark_processor = PySparkProcessor( 
       base_job_name="spark-preprocessor", 
       framework_version="3.0", 
       role=role, 
       instance_count=15, 
       instance_type="ml.m5.4xlarge", 
       max_runtime_in_seconds=7200, ) 
   configuration = [ 
       { 
       "Classification": "spark-defaults", 
       "Properties": {"spark.executor.memory": "18g",
                 "spark.yarn.executor.memoryOverhead": "3g", 
                      "spark.driver.memory": "18g", 
                   "spark.yarn.driver.memoryOverhead": "3g", 
                      "spark.executor.cores": "5", 
                      "spark.driver.cores": "5", 
                    "spark.executor.instances": "44",      
                    "spark.default.parallelism": "440", 
                  "spark.dynamicAllocation.enabled": "false" 
                   }, 
        }, 
        { 
        "Classification": "yarn-site", 
         "Properties": {"yarn.nodemanager.vmem-check-enabled": "false", 
         "yarn.nodemanager.mmem-check-enabled": "false"}, 
         } 
   ]
   

2. 接下来，我们将配置用于执行你的数据准备任务的 SageMaker Pipelines 步骤。为此，我们将使用内置的处理步骤（docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-steps.html#step-type-processing），它告诉管道这个步骤将是一个 SageMaker 处理作业。图 12.5 展示了 ProcessingStep 用于数据预处理所期望的高级输入和输出/工件：

图 12.5 – 数据准备管道步骤

我们之前已经配置了处理器，因此现在我们将使用该处理器（结合 图 12.4 中显示的其他输入）来设置我们的管道步骤，如下所示：

1. 首先，我们将启用步骤缓存。步骤缓存会告诉 SageMaker 检查是否有之前使用相同参数调用过的步骤的执行。这样，它就可以使用成功运行的先前步骤值，而不是重新执行具有完全相同参数的步骤。你应该考虑使用步骤缓存来避免不必要的任务和成本。例如，如果你的管道中的第二个步骤（模型训练）失败，你可以在该步骤没有变化的情况下重新启动管道，而不需要重新执行数据准备步骤，如下所示：

   from sagemaker.workflow.steps import CacheConfig
   cache_config = CacheConfig(enable_caching=True, expire_after="T360m")
   

2. 接下来，我们将使用 get_run_args 方法定义运行时参数。在这种情况下，我们正在传递之前配置的 Spark 处理器，结合标识输入（原始天气数据）、输出（训练、测试和验证数据集）以及数据预处理脚本作为输入接受的其他参数。数据预处理脚本 preprocess.py 是用于 第四章，使用 Amazon SageMaker Data Wrangler 和 Processing 进行大规模数据准备 中使用的处理脚本的略微修改版本。请参考以下脚本：

   from sagemaker.processing import ProcessingInput, ProcessingOutput
   run_args = pyspark_processor.get_run_args(
       "preprocess.py",
       submit_jars=["s3://crawler-public/json/serde/json-serde.jar"],
       spark_event_logs_s3_uri=spark_event_logs_s3_uri,
       configuration=configuration,
       outputs=[ \ 
           ProcessingOutput(output_name="validation", destination=validation_data_out, source="/opt/ml/processing/validation"),
           ProcessingOutput(output_name="train", destination=train_data_out, source="/opt/ml/processing/train"),
           ProcessingOutput(output_name="test", destination=test_data_out, source="/opt/ml/processing/test"),
        ],
       arguments=[
           '--s3_input_bucket', s3_bucket,
           '--s3_input_key_prefix', s3_prefix_parquet,
           '--s3_output_bucket', s3_bucket,
           '--s3_output_key_prefix', s3_output_prefix+'/prepared-data/'+timestamp
       ]
   )
   

3. 接下来，我们将使用运行时参数来配置实际的数据预处理任务所用的 SageMaker Pipelines 步骤。你会注意到我们正在使用之前配置的所有参数来构建作为管道一部分执行的步骤：

   from sagemaker.workflow.steps import ProcessingStep
   step_process = ProcessingStep(
       name="DataPreparation",
       processor=pyspark_processor,
       inputs=run_args.inputs,
       outputs=run_args.outputs,
       job_arguments=run_args.arguments,
       code="modelbuild/pipelines/preprocess.py",
   )
   

模型构建步骤

在这个步骤中，你将配置用于训练你的模型的 SageMaker 训练作业。你将使用数据准备步骤生成的训练数据，结合你的训练代码和配置参数。

重要提示

虽然我们在这个章节中没有具体介绍，但需要注意的是，SageMaker Pipelines 现在已与 SageMaker Experiments 集成，允许你捕获额外的指标，并在 SageMaker Pipelines 中查看相应的图表。

对于此，我们将使用来自 第六章，大规模训练和调优 的相同配置。请参考以下步骤：

1. 首先，我们将配置 SageMaker 训练作业，如下所示：

   # initialize hyperparameters
   hyperparameters = {
           "max_depth":"5",
           "eta":"0.2",
           "gamma":"4",
           "min_child_weight":"6",
           "subsample":"0.7",
           "objective":"reg:squarederror",
           "num_round":"5"}
   # set an output path where the trained model will be saved
   m_prefix = 'pipeline/model'
   output_path = 's3://{}/{}/{}/output'.format(s3_bucket, m_prefix, 'xgboost')
   # this line automatically looks for the XGBoost image URI and builds an XGBoost container.
   # specify the repo_version depending on your preference.
   image_uri = sagemaker.image_uris.retrieve("xgboost", region, "1.2-1")
   # construct a SageMaker estimator that calls the xgboost-container
   xgb_estimator = sagemaker.estimator.Estimator(image_uri=image_uri, 
                            hyperparameters=hyperparameters,
                        role=sagemaker.get_execution_role(),
                            instance_count=1, 
                            instance_type='ml.m5.12xlarge', 
                            volume_size=200, # 5 GB 
                            output_path=output_path)
   

2. 接下来，我们将配置用于执行您的模型训练任务的 SageMaker Pipelines 步骤。为此，我们将使用内置的 training step (docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-steps.html#step-type-training)。这告诉 Pipelines 此步骤将是一个 SageMaker 训练作业。图 12.6 展示了 Training step 预期的高级别输入和输出/工件：

![Figure 12.6 – Model build pipeline step]

![img/B17249_12_06.jpg]

图 12.6 – 模型构建管道步骤

我们之前已配置了估算器，因此现在我们将使用该估算器结合 图 12.6 中显示的其他输入来设置我们的 Pipelines 步骤：

from sagemaker.inputs import TrainingInput
from sagemaker.workflow.steps import TrainingStep
step_train = TrainingStep(
    name="ModelTrain",
    estimator=xgb_estimator,
    cache_config=cache_config,
    inputs={
        "train": TrainingInput(
            s3_data=step_process.properties.ProcessingOutputConfig.Outputs["train"].S3Output.S3Uri,
            content_type="text/csv",
        ),
        "validation": TrainingInput(
            s3_data=step_process.properties.ProcessingOutputConfig.Outputs["validation"].S3Output.S3Uri,
            content_type="text/csv",
        ),
    },
)

模型评估步骤

在此步骤中，您将配置一个用于评估您训练的模型（使用从训练步骤生成的模型工件以及您的处理代码和配置）的 SageMaker 处理作业：

1. 首先，我们将从 ScriptProcessor 开始配置 SageMaker 处理作业。我们将使用它来执行一个简单的评估脚本，如下所示：

   from sagemaker.processing import ScriptProcessor
   script_eval = ScriptProcessor(
       image_uri=image_uri,
       command=["python3"],
       instance_type=processing_instance_type,
       instance_count=1,
       base_job_name="script-weather-eval",
       role=role,
   )
   

2. 接下来，我们将配置用于执行您的模型评估任务的 SageMaker Pipelines 步骤。为此，我们将使用内置的 Processing step (docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-steps.html#step-type-processing)。这告诉 Pipelines 此步骤将是一个 SageMaker 处理作业。图 12.7 展示了用于模型评估的 Processing step 预期的高级别输入和输出/工件：

![Figure 12.7 – Model evaluation pipeline step]

![img/B17249_12_07.jpg]

图 12.7 – 模型评估管道步骤

我们之前已配置了处理器，因此现在我们将使用该处理器结合 图 12.7 中显示的其他输入来设置我们的 Pipelines 步骤。为此，我们首先将设置用于存储处理作业输出（在这种情况下，模型评估指标）的属性文件。然后，我们将配置 ProcessingStep 定义，如下所示：

from sagemaker.workflow.properties import PropertyFile
evaluation_report = PropertyFile(
    name="EvaluationReport", output_name="evaluation", path="evaluation.json"
)
step_eval = ProcessingStep(
    name="WeatherEval",
    processor=script_eval,
    cache_config = cache_config,
    inputs=[
        ProcessingInput(
            source=step_train.properties.ModelArtifacts.S3ModelArtifacts,
            destination="/opt/ml/processing/model",
        ),
        ProcessingInput(
          source=step_process.properties.ProcessingOutputConfig.Outputs["test"].S3Output.S3Uri,  destination="/opt/ml/processing/test",
        ),
    ],
    outputs=[
        ProcessingOutput(output_name="evaluation", source="/opt/ml/processing/evaluation"),
    ],
    code="modelbuild/pipelines/evaluation.py",
    property_files=[evaluation_report],
)

条件步骤

在此步骤中，您将配置一个内置的条件步骤，该步骤将根据您之前模型评估步骤的结果确定是否继续执行管道中的下一个步骤。设置条件步骤需要一系列条件或必须为真的项目。这结合了根据该条件执行步骤的指令列表。图 12.8 阐述了条件步骤所需的输入和输出：

![Figure 12.8 – Conditional pipeline step]

![img/B17249_12_08.jpg]

图 12.8 – Conditional pipeline 步骤

在这种情况下，我们将使用if_steps参数设置一个条件。在这种情况下，如果条件为真，则下一步将是注册模型然后创建打包模型的模型。您可以可选地指定else_steps以指示条件不为真时要执行的下一步。在这种情况下，如果条件不为真，我们将简单地终止管道：

from sagemaker.workflow.conditions import ConditionLessThanOrEqualTo
from sagemaker.workflow.condition_step import (
    ConditionStep,
    JsonGet
)
cond_lte = ConditionLessThanOrEqualTo(
    left=JsonGet(
        step=step_eval,
        property_file=evaluation_report,
        json_path="regression_metrics.mse.value"
    ),
    right=6.0
)
step_cond = ConditionStep(
    name="MSECondition",
    conditions=[cond_lte],
    if_steps=[step_register, step_create_model],
    else_steps=[]
)

注册模型步骤

在这个最后一步，您将打包模型并配置一个内置的注册模型步骤（docs.aws.amazon.com/sagemaker/latest/dg/build-and-manage-steps.html#step-type-register-model），该步骤将您的模型注册到 SageMaker 模型注册库中的模型包组。如图 12.9 所示，我们将用于注册模型的输入包含有关打包模型的信息，例如模型版本、估计器和模型工件在 S3 上的位置。这些信息与模型指标和推理规范等附加信息结合使用，用于注册模型版本：

图 12.9 – 条件管道步骤

此步骤将使用管道中先前步骤的数据来注册模型并集中存储有关此特定模型版本的键信息。此外，您将看到approval_status参数。此参数可用于触发下游部署过程（这些将在 SageMaker 项目中更详细地讨论）：

from sagemaker.model_metrics import MetricsSource, ModelMetrics
from sagemaker.workflow.step_collections import RegisterModel
model_metrics = ModelMetrics(
    model_statistics=MetricsSource(
        s3_uri="{}/evaluation.json".format(
step_eval.arguments["ProcessingOutputConfig"]["Outputs"][0]["S3Output"]["S3Uri"]
        ),
        content_type="application/json",
    )
)
step_register = RegisterModel(
    name="RegisterModel",
    estimator=xgb_train,
    model_data=step_train.properties.ModelArtifacts.S3ModelArtifacts,
    content_types=["text/csv"],
    response_types=["text/csv"],
    inference_instances=["ml.t2.medium", "ml.m5.xlarge"],
    transform_instances=["ml.m5.xlarge"],
    model_package_group_name=model_package_group_name,
    approval_status=model_approval_status,
    model_metrics=model_metrics,
)

创建管道

在前面的步骤中，我们配置了作为模型构建管道一部分的任务和步骤。我们现在需要将这些步骤链接起来以创建 SageMaker 管道。

在配置管道步骤和创建 SageMaker 管道时，识别可能随管道执行而变化的参数以及可能更动态的参数非常重要。例如，处理或训练的实例类型可能是您希望在每次执行管道时都能更改的内容，而不直接修改您的管道代码。这就是参数在执行时动态传递参数变得重要的地方。这允许您根据不同的环境或随着数据增长来更改配置（例如更改实例类型参数）。

以下代码显示了将先前配置的管道步骤链接起来，以及确定我们希望在每次执行中能够传递的参数：

from sagemaker.workflow.pipeline import Pipeline
pipeline_name = f"WeatherPipeline"
pipeline = Pipeline(
    name=pipeline_name,
    parameters=[
        processing_instance_type,
        processing_instance_count,
        training_instance_type,
        model_approval_status,
        input_data
    ],
    steps=[step_process, step_train, step_eval, step_cond],
)

执行管道

现在我们已经定义和配置了步骤和管道本身，我们希望能够执行管道。为此，您需要执行几个步骤。这些步骤需要在每次管道执行时执行。管道可以通过多种方式启动：

• 在笔记本中编程（如本章示例笔记本所示）

• 在 SageMaker Studio UI 中的“Pipelines”下

• 通过其他资源编程方式

• 通过由事件或计划触发的 EventBridge 源

在本节中，我们将关注从你的示例笔记本执行你的 pipeline 所需的步骤。首先，你需要将 pipeline 定义提交给 SageMaker Pipelines 服务。这是通过一个 upsert 完成的，该 upsert 将 IAM 角色作为参数传递。请注意，如果不存在，upsert 将创建 pipeline 定义，如果存在，则更新 pipeline。此外，传递的角色由 SageMaker Pipelines 用于创建和启动步骤中定义的所有任务。因此，你需要确保该角色具有你 pipeline 所需的 API 权限。最佳实践是只包括实际需要的 API 权限，以避免过度授权的角色。

在以下代码中，你需要加载 pipeline 定义，然后通过 upsert 提交该定义：

import json
json.loads(pipeline.definition())
pipeline.upsert(role_arn=role)

一旦提交了 pipeline 定义，你就可以使用以下代码开始 pipeline：

execution = pipeline.start()

有多种方法可以检查你的 pipeline 步骤的状态和进度。你可以在 Studio 控制台中查看你的 pipeline，并点击每个步骤以获取每个步骤的元数据，包括步骤日志。此外，你可以通过编程方式检查 pipeline 执行的状态。为此，你可以运行 execution.describe() 来查看 pipeline 执行状态，或运行 execution.list_steps() 来查看执行状态和每个步骤。

在模型构建活动中，从笔记本中临时运行你的 pipeline 通常是可以接受的。然而，当你准备将模型部署到生产环境时，在那个阶段找到最一致和可重复的触发或安排模型构建 pipeline 以进行模型重新训练的方式是很常见的。

要做到这一点，你可以利用 SageMaker Pipelines 和 Amazon EventBridge 之间的集成（docs.aws.amazon.com/sagemaker/latest/dg/pipeline-eventbridge.html）。这种集成允许你通过事件规则触发你的 SageMaker pipeline 的执行。这些规则可以基于事件，例如 AWS Glue 作业的完成，或者它们可以是计划好的。

Pipeline 推荐实践

在本节中，我们介绍了如何使用你的示例天气用例设置 SageMaker pipeline。随着你构建自己的 pipeline，它们在所需配置和应包含的步骤方面可能会有所不同。然而，以下一般性建议适用于所有用例（适用时突出显示独特考虑因素）：

1. SageMaker Pipelines 内置了支持各种 SageMaker 作业的步骤，并能够利用回调进行自定义步骤。与 SageMaker 步骤的内置集成简化了管道的构建和管理。因此，建议在可能的情况下，使用 SageMaker 原生步骤来处理您的管道中的任务。

2. 使用运行时参数对于在执行或环境中更可能变化的作业参数，例如运行训练或处理作业的 ML 实例的大小或数量。这允许你在启动管道执行时传递值，而不是每次都修改你的管道代码。

3. 启用步骤缓存以利用消除管道中不必要的步骤执行的优势。这将降低成本，并在前一个管道步骤已成功执行且参数相同的情况下减少管道时间。

在本节中，我们介绍了使用 SageMaker Pipelines 自动化模型构建 ML 工作流程。在下一节中，我们将介绍创建一个超越自动化并包含 CI/CD 实践的端到端 ML 管道。

使用 Amazon SageMaker Projects 创建 CI/CD 管道

在本节中，我们将讨论使用 Amazon SageMaker Projects 将 CI/CD 实践纳入您的 ML 管道。SageMaker Projects 是一种服务，它结合使用 SageMaker Pipelines 和 SageMaker 模型注册，以及 CI/CD 工具，来自动提供和配置 CI/CD 管道。图 12.10 说明了 SageMaker Projects 的核心组件。使用 Projects，您具有 CD 管道的优势、源代码版本控制和管道执行的自动触发：

图 12.10 – SageMaker 项目

项目通过内置的 SageMaker MLOps 项目模板或通过创建您自己组织的 MLOps 模板提供。底层模板通过 AWS 服务目录、SageMaker Studio 提供，并包含预配置 CI/CD 管道的 CloudFormation 模板。由于项目依赖于 CloudFormation 来提供管道，这确保了 IaC/CaC 实践的实践，能够一致且可靠地创建 CI/CD ML 管道。

SageMaker 内置了三种核心类型的 MLOps 项目模板。图 12.11 展示了这三种主要类型：1. 构建和训练管道，2. 部署管道，3. 构建、训练和部署管道。

参考以下图示：

图 12.11 – SageMaker 项目

首先，有一个构建和训练模板。这个模板涵盖了数据准备、特征工程、模型训练和评估所需的任务。当您在 SageMaker 上执行模型构建活动但将模型部署到其他地方时，此模板非常有用。如果您只有批量用例，此模板也很有用。在这种情况下，项目将自动提供和初始化一个模型构建管道的源代码存储库，设置对该代码存储库更改的管道触发器，并在模型注册表中创建一个模型组。然后，您需要负责进入并修改该管道代码以匹配您的用例。

第二，有一个模型部署模板。当您希望标准化 SageMaker 以进行托管时，此模板非常有用。在这种情况下，项目将自动提供和初始化一个模型部署管道的源代码存储库，该存储库基于从模型注册表中拉取的触发器和信息部署到 SageMaker 端点。

最后，有一些端到端的模板涵盖了所有阶段，包括构建、训练和部署。这些模板涵盖了 AWS 开发者服务（AWS CodePipeline、AWS CodeCommit、AWS CodeBuild），或者允许选择利用第三方源代码存储库（GitHub、GitHub Enterprise、BitBucket 或 Jenkins）进行编排。在这种情况下，项目将自动提供和初始化模型构建和模型部署活动的源代码。项目还将设置模型构建和模型部署活动的触发器。再次强调，您需要负责进入并修改初始代码以满足您的用例。

在本节中，我们研究了 SageMaker 项目。我们得出结论，这是一个可以将 CI/CD 实践纳入您的 ML 管道的服务。现在，我们将介绍使用 SageMaker 项目时的一些推荐实践。

SageMaker 项目推荐实践

在上一节中，我们介绍了 SageMaker 项目，作为通过使用自动提供和配置所需集成的一站式 AWS 服务来将 CI/CD 实践纳入您的 ML 管道的方法。现在，我们将介绍使用 SageMaker 项目时的一些一般推荐实践。

当您使用 SageMaker 项目时，针对您的用例的定制可能因在内置 MLOps 项目模板中定制代码或创建您自己的完全定制的 MLOps 项目模板而异。因此，为了满足您组织和用例的要求，管道之间可能会有很多差异。然而，有一些通用的建议适用于所有用例，如下所述：

• 在满足您的要求时，请使用内置的 MLOps 项目模板。

• 当您有独特的要求，例如额外的部署质量门时，请创建定制的 MLOps 项目模板。

• 在创建自定义 MLOps 项目模板时，通常更容易以用于内置 MLOps 项目模板的 AWS CloudFormation 模板作为起点，然后相应地进行修改。所有内置的 MLOps 项目模板都在 AWS 服务目录中可用且可见。

在本节中，我们介绍了如何使用 SageMaker 项目将 CI/CD 实践添加到您的自动化工作流程中。我们还讨论了可用的 MLOps 项目模板选项。最后，我们讨论了使用 SageMaker 项目时的额外考虑因素和最佳实践。

摘要

在本章中，我们首先介绍了自动化 SageMaker 工作流程的一般性考虑因素。然后，我们讨论了如何通过使用 SageMaker Pipelines 自动化 SageMaker 模型构建工作流程，特别是通过使用 SageMaker Pipelines。为了说明 SageMaker Pipeline 的使用，我们强调了构建针对天气用例的管道所需的步骤。最后，我们讨论了如何通过使用 SageMaker 项目来整合 CI/CD 实践，从而增强自动化模型构建工作流程，除了 SageMaker Pipelines 提供的自动化功能之外。

在下一章中，我们将讨论 AWS Well-Architected 架构，特别是探讨每个 Well-Architected 柱石的最佳实践如何映射到 SageMaker 工作负载。

第十三章：使用 Amazon SageMaker 进行架构良好的机器学习

在云中运行工作负载时，您希望确保工作负载的架构正确，以便充分利用云所能提供的一切。AWS 架构良好框架可以帮助您做到这一点，通过提供一种正式的方法来学习适用于部署到 AWS 的任何工作负载的五个关键支柱的最佳实践。这些支柱是运营卓越、安全性、可靠性、性能效率和成本优化。

该框架提供了在初始开发和持续更新工作负载过程中如何改进架构以及如何在支柱之间进行权衡的指导。虽然您可以使用架构良好框架从一般技术角度评估您的负载，但在构建机器学习（ML）应用程序时，拥有针对 ML 五个支柱的特定指导将非常有益。AWS 机器学习透镜提供了这种专注的指导，您可以使用它来比较和衡量您的 AWS 上机器学习工作负载与最佳实践的差距。

重要提示

要深入了解架构良好框架和机器学习透镜，请查阅 AWS 提供的以下两篇白皮书：docs.aws.amazon.com/wellarchitected/latest/framework/wellarchitected-framework.pdf 和 docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/wellarchitected-machine-learning-lens.pdf。

到目前为止，本书中我们已经讨论了如何使用不同的 Amazon SageMaker 功能跨越机器学习工作负载的所有阶段。在本章中，我们将学习如何结合通用架构良好框架和机器学习透镜的指导，并将其应用于基于 SageMaker 构建的端到端机器学习工作负载。

请注意，本章不介绍任何新的 SageMaker 功能，而是深入探讨如何将您已知的技能应用于构建一个架构良好的机器学习工作负载。您将了解 SageMaker 的具体功能如何与其他 AWS 服务结合，在五个支柱中发挥作用，其中一些功能在多个支柱中扮演关键角色。

在本章中，我们将涵盖以下主要主题：

• 运营机器学习工作负载的最佳实践

• 保护机器学习工作负载的最佳实践

• 构建可靠机器学习工作负载的最佳实践

• 构建高性能机器学习工作负载的最佳实践

• 构建成本优化的机器学习工作负载的最佳实践

运营机器学习工作负载的最佳实践

许多组织从构建模型来解决一个或多个业务问题的几个实验开始他们的机器学习之旅。通常，云平台，如 SageMaker，通过提供无缝访问弹性计算基础设施和内置对各种机器学习框架和算法的支持，使这种实验变得容易。一旦这些实验证明成功，下一步自然的步骤就是将模型投入生产。通常，在这个时候，组织希望从研发阶段转向机器学习的运营。

MLOps 的概念最近越来越受欢迎。在非常高的层面上，MLOps 涉及将人员、流程和技术结合起来，将机器学习工作负载集成到发布管理、CI/CD 和运营中。在不深入 MLOps 的所有细节的情况下，在本节中，我们将讨论使用技术来运营机器学习工作负载的最佳实践。我们还将讨论哪些 SageMaker 功能在运营机器学习工作负载的各个方面发挥作用。

现在让我们在以下部分中查看在 AWS 上运营机器学习工作负载的最佳实践。

确保可重复性

为了成功地将端到端机器学习系统投入运营，您必须首先通过版本化的数据、代码和工件来确保其可重复性。最佳实践是版本化创建模型所使用的所有输入，包括训练数据、数据准备代码、算法实现代码、参数和超参数，以及所有训练模型工件。版本化策略还涉及在模型更新阶段提供帮助，并在模型更新失败或更新的模型不符合您的要求时，允许轻松回滚到特定的已知有效版本。

跟踪机器学习工件

使用不同的算法和超参数对每个算法进行迭代开发，会导致许多训练实验和多个模型版本的产生。跟踪这些实验和结果模型，以及每个模型的血统，对于满足审计和合规要求非常重要。模型血统还有助于在模型性能下降的情况下进行根本原因分析。

虽然您当然可以构建定制的跟踪解决方案，但最佳实践是使用如 SageMaker Experiments 之类的托管服务。Experiments 允许您跟踪、组织、可视化和比较机器学习模型在整个机器学习生命周期中的所有阶段，包括特征工程、模型训练、模型调优和模型部署。使用 SageMaker Experiments，您可以轻松选择部署或更新特定版本的模型。Experiments 还为您提供了模型血统功能。有关 SageMaker Experiments 功能的详细讨论，请参阅第六章的“Amazon SageMaker Experiments”部分，“大规模训练和调优”。

此外，您还可以使用 Amazon SageMaker ML Lineage Tracking 功能，该功能跟踪从数据准备到模型部署的 ML 工作流程的各个步骤的信息。通过跟踪的信息，您可以重现工作流程步骤，跟踪模型和数据集的谱系，并建立模型治理和审计标准。

自动化部署流程

自动化流程将最小化将训练好的机器学习模型从开发、预发布等低级环境移动到生产环境时的人工干预。目标是创建一个编码化的部署流程，使用基础设施即代码和配置即代码，并将手动和自动的质量关卡纳入流程中。手动质量关卡可以确保在模型被提升到生产环境之前，不存在诸如安全暴露等运营问题。另一方面，自动质量关卡可以用来评估模型指标，如精确度、召回率或准确度。流程可以实现一致的部署，并提供在多个环境中以最小的人工干预可靠地重新创建机器学习相关资源的能力。

使用 Amazon SageMaker Pipelines，您可以构建自动化的模型工作流程。您可以将机器学习生命周期的每个步骤作为一个流程步骤来开发和部署模型，并监控流程。您可以进一步管理每个步骤之间的依赖关系，构建正确的顺序，并自动执行步骤。将 CI/CD 实践引入机器学习工作负载的服务是 SageMaker Projects。此服务帮助您将模型从概念转移到生产。此外，您可以通过结合使用 SageMaker Projects 和 SageMaker Pipelines，通过在机器学习生命周期的每个步骤自动跟踪代码、数据集和模型版本，轻松满足治理和审计标准。这使您能够回溯并重新播放模型生成步骤，解决问题，并可靠地跟踪模型的规模级谱系。有关自动化工作流程和 MLOps 的详细讨论，请参阅第十二章**，机器学习自动化工作流程。

监控生产模型

对部署的模型进行持续监控是使机器学习工作负载投入运营的关键步骤，因为模型的表现和有效性可能会随时间退化。确保模型持续满足您的业务需求，首先从识别衡量模型相关指标和业务指标的指标开始。确保在监控过程中早期定义并收集所有对模型评估您的业务关键绩效指标至关重要的指标。

一旦确定了指标，为了确保部署的模型持续保持高质量，使用 Amazon SageMaker Model Monitor 功能及其与 CloudWatch 的集成，主动检测问题、发出警报并自动化修复操作。除了检测模型质量下降外，你还可以监控数据漂移、偏差漂移和特征归因漂移，以满足你的可靠性、监管和模型可解释性要求。

由于模型监控而触发的 CloudWatch 警报可用于自动化以下活动：使当前模型无效、回滚到较旧模型版本或根据新的真实数据重新训练新模型。生产模型的更新应考虑引入更改的风险、重新训练的成本以及在生产中拥有较新模型可能带来的潜在价值。有关模型监控的详细讨论，请参阅第十一章**，使用 Amazon SageMaker Model Monitor 和 Clarify 进行生产模型监控。

重要提示

虽然本节重点介绍了用于操作 ML 工作负载的 SageMaker 原生方法，但请注意，可以使用 SageMaker API 和其他 AWS 服务（如 CodePipeline、Step Functions、Lambda 和 SageMaker Data Science SDK）的组合来构建类似的自动化管道。在 github.com/aws-samples/mlops-amazon-sagemaker-devops-with-ml 上记录了多个 MLOps 架构和示例代码。

以下表格总结了适用于操作 ML 工作负载的各种 AWS 服务和功能：

![图 13.1 – 用于操作 ML 工作负载的 AWS 服务

图 13.1 – 用于操作 ML 工作负载的 AWS 服务

在下一节中，你将了解 SageMaker 如何与其他 AWS 服务集成，以实现安全的 ML 工作负载。

保护 ML 工作负载的最佳实践

在保护 ML 工作负载时，你应该考虑基础设施和网络安全、身份验证和授权、加密数据和模型工件、日志记录和审计以及满足监管要求。在本节中，我们将讨论使用 SageMaker 和相关 AWS 服务组合来保护 ML 工作负载的最佳实践。

现在让我们在以下章节中查看在 AWS 上保护 ML 工作负载的最佳实践。

隔离 ML 环境

要构建安全的机器学习工作负载，您需要一个隔离的计算和网络环境。为了在 SageMaker 上实现这一点，请在虚拟 私有 云（VPC）中部署所有资源，例如笔记本、工作室域、训练作业、处理作业和端点。VPC 提供了一个隔离的环境，其中所有 SageMaker 组件之间的流量都在网络内部流动。您可以通过使用包含 VPC 内子网允许的入站和出站流量的规则的网络安全组，添加另一层隔离，从而进一步隔离您的机器学习资源。

即使您在没有 VPC 的情况下使用 SageMaker，所有资源也在由 AWS 管理的单租户 EC2 实例的环境中运行，这确保了您的机器学习环境与其他客户隔离。然而，在 VPC 中部署机器学习资源，例如训练容器，允许您使用 VPC Flow Logs 监控这些资源的进出网络流量。此外，您可以使用 VPC 端点和 AWS PrivateLink 来启用 SageMaker 与其他 AWS 服务（如 S3 或 CloudWatch）之间的通信。这保持了 AWS 网络内各种服务之间所有流量的流动，同时不会将流量暴露给公共互联网。

禁用互联网和 root 访问

默认情况下，SageMaker 笔记本实例已启用互联网访问，以便您下载外部库并自定义工作环境。此外，这些笔记本启用了 root 访问，这使您能够利用外部库。

在低级沙盒和开发环境中，仅使用这些默认设置来找出最佳工作笔记本环境。在其他所有非生产环境和生产环境中，请在自己的 VPC 中启动 SageMaker 资源，并关闭 root 访问以防止下载和安装未经授权的软件。在隔离您的环境之前，将所有必要的库导入到私有仓库，例如 AWS CodeArtifact。这允许您无缝下载特定版本的库，而无需访问互联网。

此外，使用编码化的生命周期配置来自动设置笔记本环境。同样，由 SageMaker 管理的训练和部署推理容器默认启用互联网访问。在启动训练和推理资源时，使用VPCConfig和EnableNetworkIsolation标志来保护这些资源免受外部网络流量的影响。在这种情况下，所有数据和模型工件的上传和下载都通过您的 VPC 路由。同时，训练和推理容器保持与网络的隔离，并且无法访问 VPC 内或互联网上的任何资源。

强制执行身份验证和授权

实施一个强大的机制来确定谁可以访问机器学习资源（身份验证）以及认证用户可以访问哪些资源（授权）。SageMaker 与 AWS IAM 服务原生集成，该服务用于管理对所有 AWS 服务和资源的访问。IAM 允许您使用 IAM 用户、组、角色和策略定义细粒度的访问控制。您可以使用基于身份的策略组合来实现最小权限访问，以指定 IAM 用户、角色或组可以执行的操作，以及基于资源的策略来指定谁可以访问资源以及他们可以在其上执行哪些操作。

在设计这些 IAM 策略时，可能会倾向于从开放性较高的 IAM 策略开始，并怀有随着实施过程逐步收紧策略的良好意图。然而，最佳实践是从严格的策略开始，仅授予最小必需的访问权限，并在需要时添加额外的权限。定期审查和精炼策略，以确保不会授予不必要的权限。IAM 服务提供了访问顾问功能，该功能显示各种 AWS 服务最后一次被不同的实体（如 IAM 组、用户、角色和策略）访问的时间。使用这些信息来精炼策略。所有服务 API 调用也由 CloudTrail 记录，您可以使用 CloudTrail 历史记录来确定基于使用模式可以删除哪些权限。

保护数据和模型工件

IAM 策略也可以用于 S3 中数据和模型的访问控制。此外，您还可以使用名为 Amazon Macie 的安全服务来保护并分类 S3 中的数据。Macie 内部使用机器学习来自动发现、分类和保护敏感数据。它自动识别敏感数据，如个人身份信息（PII）或知识产权（IP），提供对数据访问和移动模式的可视性。Macie 持续监控数据访问模式中的异常，并主动生成关于未经授权的访问和数据泄露的警报。

下一个重要的安全方面是确保机器学习系统的数据和模型工件的安全，无论是在静止状态还是在传输过程中。为了在 VPC 内部传输过程中保护数据，请使用传输层安全（TLS）。为了在静止状态下保护数据，最佳实践是使用加密来阻止恶意行为者读取您的数据和模型工件。您可以使用客户端或服务器端加密。SageMaker 内置了加密功能，可以保护静止状态和传输过程中的训练数据和模型工件。例如，在启动训练作业时，您可以指定要使用的加密密钥。您可以选择使用 SageMaker 管理的密钥、AWS 管理的密钥或您自己的客户管理的密钥。

记录、监控和审计

SageMaker 与 CloudWatch 和 CloudTrail 原生集成。你可以在 CloudWatch 中捕获 SageMaker 训练、处理和推理的日志，这可以进一步用于故障排除。所有 SageMaker（以及其他 AWS 服务）的 API 调用都由 CloudTrail 记录，允许你追踪哪个 IAM 用户、AWS 账户或源 IP 地址执行了 API 调用，以及调用发生的时间。

满足监管要求

对于许多组织来说，机器学习解决方案需要符合监管标准，并通过各国和行业差异很大的合规认证。Amazon SageMaker 符合广泛的合规计划，包括 PCI、HIPAA、SOC 1/2/3、FedRAMP 和 ISO 9001/27001/27017/27018。

以下表格总结了适用于保护机器学习工作负载的各种 AWS 服务：

图 13.2 – 用于保护机器学习工作负载的 AWS 服务

在下一节中，你将了解 SageMaker 如何与其他 AWS 服务集成，以构建可靠的机器学习工作负载。

可靠机器学习工作负载的最佳实践

对于一个可靠系统，有两个核心考虑因素：

• 首先，能够从计划内和计划外的中断中恢复

• 第二，能够满足不可预测的流量需求增加

理想情况下，系统应在不影响下游应用程序和最终用户的情况下实现这两点。在本节中，我们将讨论使用 SageMaker 和相关 AWS 服务构建可靠机器学习工作负载的最佳实践。

让我们现在看看以下章节中关于在 AWS 上保护机器学习工作负载的一些最佳实践。

从故障中恢复

对于机器学习工作负载，优雅地恢复的能力应该是构成迭代机器学习过程的各个步骤的一部分。故障可能发生在数据存储、数据处理、模型训练或模型托管中，这可能是从系统故障到人为错误的各种事件的结果。

对于 SageMaker 上的机器学习，所有数据（以及模型工件）通常都保存在 S3 中。这确保了机器学习数据与计算处理的解耦。为了防止数据意外丢失，最佳实践是使用 IAM 和 S3 策略的组合来确保基于最小权限的数据访问。此外，使用 S3 版本控制和对象标记来启用数据（以及模型工件）的版本控制和可追溯性，以便在发生故障时易于恢复或重建。

接下来，考虑机器学习训练的可靠性，这通常是一个漫长且耗时的过程。看到运行数小时甚至数天的训练作业并不罕见。如果这些长时间运行的训练作业因断电、操作系统故障或其他意外错误而中断，能够可靠地从作业停止的地方继续进行至关重要。在这种情况下应使用机器学习检查点。在 SageMaker 上，一些内置算法和所有支持的深度学习框架在启动训练作业时提供启用检查点的功能。当您启用检查点时，SageMaker 会自动在训练过程中保存模型状态的快照。这使得您可以从最后一个保存的检查点可靠地重新启动训练作业。

跟踪模型来源

假设您的训练过程顺利进行，并且您已将训练好的模型工件保存在一个 S3 桶中。如果由于人为错误（例如，您的团队中有人不小心删除了它）而丢失了这个模型工件，会发生什么？在一个可靠的机器学习系统中，您需要能够使用与原始模型相同的数据、代码版本和参数来重新创建此模型。因此，在训练过程中跟踪所有这些方面非常重要。使用 SageMaker 实验，您可以跟踪创建模型的所有步骤和工件，以便您可以根据需要轻松地重新创建模型。使用 SageMaker 实验跟踪的另一个好处是能够对生产中的问题进行故障排除，以确保可靠运行。

除了依赖实验来重新创建模型工件的具体版本外，还应结合使用 IAM 和 S3 策略，以确保基于最小权限的访问，以最大限度地降低意外删除模型工件的风险。实施诸如要求对模型工件删除进行多因素认证以及根据您组织的灾难恢复策略存储工件副本等措施。

自动化部署管道

为了确保所有导致模型部署的步骤都得到一致执行，请使用具有访问控制的 CI/CD 管道来强制执行最小权限访问。部署自动化与手动和自动质量门相结合，确保在部署之前所有更改都可以有效地与依赖系统进行验证。Amazon SageMaker Pipelines 具有将 CI/CD 实践应用于机器学习工作负载以改进可靠性的能力。使用 SageMaker Pipelines 编码 CI/CD 管道为您提供了处理模型端点意外删除的额外能力。采用基础设施即代码（IaC）方法，可以重新创建端点。这需要对您的数据、代码、算法、超参数、模型工件、容器镜像等实施良好的版本控制策略。对一切进行版本控制，并记录您的版本控制策略。有关 SageMaker Pipelines 功能的详细讨论，请参阅第十二章**，机器学习自动化工作流程中的Amazon SageMaker Pipelines部分。

此外，遵循训练一次，部署到任何地方的策略。由于训练过程和结果的去耦合性质，您可以在多个环境中共享训练好的模型工件。这可以防止在多个环境中重新训练并引入对模型的不期望变化。

处理意外的流量模式

模型部署后，您必须确保部署的模型在服务推理请求时的可靠性。模型应能够处理推理流量的峰值，并继续以符合业务要求的质量运行。

为了处理流量峰值，请使用启用自动扩展的 SageMaker 实时端点部署模型。启用自动扩展后，SageMaker 会根据推理流量的动态变化自动增加（和减少）托管模型背后的计算能力。SageMaker 提供的自动扩展是水平扩展，这意味着它会添加新实例或删除现有实例来处理推理流量的变化。

部署模型的持续监控

为了确保部署的模型持续保持高质量，请使用 Amazon SageMaker Model Monitor 的功能及其与 CloudWatch 的集成，以主动检测问题、发出警报，并在生产模型未按预期表现时自动执行修复操作。除了模型质量外，您还可以监控数据漂移、偏差漂移和特征归因漂移，以满足您的可靠性、监管和模型可解释性要求。确保定义并监控所有对模型评估至关重要的指标，以符合您的业务关键绩效指标（KPIs）。有关模型监控的详细讨论，请参阅第十一章**，使用 Amazon SageMaker Model Monitor 和 Clarify 监控生产模型。

更新模型的新版本

最后，您必须考虑如何可靠地更新生产模型。SageMaker 端点生产变体可用于实现多种部署策略，如 A/B、蓝绿、金丝雀和影子部署。高级部署策略及其详细实现将在第九章**，使用 Amazon SageMaker 端点生产变体更新生产模型中讨论。根据模型消费者的风险容忍度和停机时间，选择合适的部署策略。

以下表格总结了适用于构建可靠机器学习工作负载的各种 AWS 服务：

图 13.3 – 用于可靠机器学习工作负载的 AWS 服务功能

在下一节中，您将了解 SageMaker 如何与其他 AWS 服务集成，以构建可靠、性能高效的工作负载。

构建高性能机器学习工作负载的最佳实践

由于机器学习工作负载的计算和时间密集型特性，选择适合工作负载每个单独阶段的最高性能资源非常重要。计算、内存和网络带宽需求是机器学习过程每个阶段的独特需求。除了基础设施的性能外，模型性能（如通过准确率等指标衡量）也非常重要。在本节中，我们将讨论在 SageMaker 上构建机器学习工作负载时应应用的最佳实践。

现在让我们在以下章节中查看在 AWS 上构建高性能机器学习工作负载的最佳实践。

机器学习资源的合理配置

SageMaker 支持多种机器学习实例类型，这些实例类型具有不同的 CPU、GPU、FPGA、内存、存储和网络容量组合。每个实例类型反过来又支持多个实例大小。因此，您有一系列选择来满足您特定的需求。最佳实践是为数据处理、构建、训练和托管您的机器学习模型选择不同的计算资源配置。这是由 SageMaker 的解耦特性实现的，它允许您为不同的 API 选择不同的实例类型和大小。例如，您可以选择ml.c5.medium作为笔记本实例的工作环境，使用四个ml.p3.large GPU 实例的集群进行训练，最后在两个附加了弹性推理的ml.m5.4xlarge实例上托管训练好的模型。此外，在 SageMaker Studio 环境中，您可以在不中断您的工作的情况下无缝更改笔记本实例类型。

当你有选择不同计算选项的灵活性来应对不同的机器学习阶段时，你如何选择具体的实例类型和大小呢？这取决于你对工作负载的理解和实验。例如，如果你知道你选择的训练框架和算法将需要 GPU 支持，请选择一个用于训练的 GPU 集群。虽然使用 GPU 进行所有训练可能很有吸引力，但传统的算法可能由于涉及到的通信开销而在 GPU 上运行不佳。一些内置算法，如 XGBoost，实现了针对 CPU 计算优化的开源算法。SageMaker 还提供了针对 TensorFlow 和 PyTorch 等框架的优化版本，这些版本包括针对 Amazon EC2 实例家族的高性能训练优化。

监控资源利用率

一旦你做出了初始的实例选择并启动了训练，SageMaker 训练作业会发出用于资源利用率的 CloudWatch 指标，你可以使用这些指标来改进下一次的训练运行。此外，当你为训练作业启用调试器时，SageMaker 调试器提供了对训练作业及其执行的基础设施的可见性。调试器还监控并报告系统资源，如 CPU、GPU 和内存，为你提供资源低利用率瓶颈的见解。如果你使用 TensorFlow 或 PyTorch 进行深度学习训练作业，调试器为你提供了框架指标的视图，这些指标可以用来加速你的训练作业。有关调试器功能的详细讨论，请参阅第七章**，使用 Amazon SageMaker 调试器分析训练作业性能*。

调整托管基础设施的大小

一旦模型训练完成并准备好部署到用于实时端点的实例，考虑一下你的目标性能。目标性能是每个周期要服务的请求数量和每个请求期望的延迟的组合，例如，每分钟 10,000 个请求，最大响应时间为 1 毫秒。一旦你有了目标性能的概念，在非生产环境中进行负载测试，以确定用于托管模型的实例类型、实例大小和实例数量。推荐的最佳实践是，为了高可用性，在两个可用区部署至少两个实例的端点。

一旦你决定了要使用的实例类型，就从满足你的稳定状态流量所需的最小实例数量开始，并利用 SageMaker 托管服务的自动扩展功能。使用自动扩展，SageMaker 可以根据你配置的利用率和请求流量阈值自动调整推理容量。为了满足你的性能要求，通过更新端点配置来调整容量，而无需停机。

此外，您还可以使用 Amazon Inf1 实例扩展深度学习模型的托管基础设施，这些实例非常适合搜索、推荐引擎和计算机视觉等应用，且成本较低。

虽然实时端点提供了对 SageMaker 上部署的模型的访问，但由于延迟要求，某些工作负载可能需要在边缘进行推理，例如用于确定制造工厂中缺陷产品部件的模型。在这种情况下，模型需要部署在制造工厂内的摄像头中。对于此类用例，请使用 SageMaker Neo 和 SageMaker Edge Manager 来优化、部署和管理边缘模型。

重要提示

虽然实时端点和边缘部署的模型提供同步预测，但批量转换用于异步推理，对较长的响应时间有更大的容忍度。使用实验来确定合适的实例类型、大小和实例数量，同时考虑到作业完成时间。

持续监控已部署模型

一旦模型开始主动处理推理流量，请使用 SageMaker 模型监控器来持续监控机器学习模型的数据漂移、模型质量性能、特征重要性漂移和偏差漂移。在幕后，模型监控器使用分布式处理作业。与批量处理一样，使用实验和负载测试来确定完成每个计划监控作业执行所需的处理作业资源。有关模型监控器的详细讨论，请参阅第十一章**，使用 Amazon SageMaker 模型监控器和 Clarify 监控生产模型。

以下表格总结了各种 SageMaker 功能及其在构建高性能机器学习工作负载中的应用：

图 13.4 – AWS 服务能力，用于构建高性能机器学习工作负载。

在下一节中，您将了解 SageMaker 如何与其他 AWS 服务集成以构建成本优化工作负载。

成本优化机器学习工作负载的最佳实践

对于许多组织来说，不采用如机器学习等颠覆性技术所失去的机会成本超过了机器学习的成本。通过实施一些最佳实践，这些组织可以从他们的机器学习投资中获得最佳回报。在本节中，我们将讨论适用于 SageMaker 上成本优化机器学习工作负载的最佳实践。

现在让我们看看在 AWS 上构建成本优化机器学习工作负载的最佳实践。

优化数据标注成本

用于机器学习训练的数据标注，通常在机器学习过程的初期进行，可能非常繁琐、容易出错且耗时。大规模标注消耗大量工作时间，这使得这项任务也变得成本高昂。为了优化数据标注的成本，请使用 SageMaker Ground Truth。Ground Truth 通过结合人力和主动学习提供大规模数据标注的能力。当启用主动学习时，只有当模型无法自信地完成标注任务时，标注任务才会路由给人类。然后，人工标注的数据被用来训练模型以提高准确性。因此，随着标注工作的进行，需要人工标注的数据越来越少。这导致工作完成速度加快，成本降低。有关 Ground Truth 功能的详细讨论，请参阅第三章**，使用 Amazon SageMaker Ground Truth 进行数据标注。

使用 AWS Marketplace 中的模型降低实验成本

机器学习本质上是迭代的和实验性的。每次都需要运行多个算法，每个算法都有不同的超参数集，这会导致在确定满足您需求的模型之前，需要执行多个训练任务。所有这些训练在时间和成本上都会累积。

实验的一个很大部分是研究和重用现成的预训练模型，这些模型可能符合您的需求。AWS Marketplace for ML 为您提供了由 AWS 审核的供应商提供的数据集和模型目录。您可以订阅满足您需求的模型，并可能节省开发自己模型所需的时间和成本。如果您最终开发了自己的模型，您可以使用市场将您的模型货币化，使其可供他人使用。

使用 AutoML 减少实验时间

如果市场中的模型不符合您的需求，或者您的组织有购买而非构建的政策，首先检查您的数据集和用例是否适合 AutoPilot。在撰写本书时，AutoPilot 支持表格数据以及分类和回归问题。AutoPilot 自动分析数据集，并构建多个模型，这些模型具有不同的算法和超参数组合，并最终选择最佳算法。这节省了时间和成本。此外，该服务通过两个笔记本提供透明度——一个数据准备笔记本和一个模型候选选择笔记本，这些笔记本详细说明了 AutoPilot 执行的幕后步骤。因此，即使您最终没有使用 AutoPilot 构建和推荐的模型，您也可以将这些笔记本作为您自己实验的起点，并使用您的业务领域知识进行修改。

然而，在本书出版时，AutoPilot 仅支持使用表格数据进行的回归和分类。对于其他数据类型和问题，您将不得不构建和训练自己的模型。

使用小数据集进行本地迭代

在机器学习实验过程中，首先在 SageMaker 笔记本的本地环境中使用较小的数据集进行迭代。一旦解决了代码错误和数据问题等细节，您可以使用 SageMaker 管理的完整数据集和分布式训练集群进行扩展。这种分阶段的方法将使您以更低的成本更快地迭代。SageMaker SDK 通过支持训练 API 中的instance-type = "local"来简化这一过程，这样您就可以在本地环境或分布式集群上重用相同的代码。请注意，在发布时，本地模式仅在 SageMaker 笔记本实例中工作，不在 Studio 环境中。

调整训练基础设施

当您准备启动分布式训练集群时，选择集群中正确的实例数量和类型非常重要。对于不支持分布式训练的内置或自定义算法，您的集群将始终只有一个实例。对于支持分布式训练的算法和框架，利用如第六章中讨论的数据并行性和模型并行性，以更快地完成训练，从而降低整体训练成本。

虽然有各种不同容量配置的实例类型可供选择，但根据所使用的机器学习算法，正确调整训练实例的大小非常重要。例如，简单的算法可能无法在更大的实例类型上更快地训练，因为它们无法利用硬件并行性。更糟糕的是，由于高 GPU 通信开销，它们甚至可能训练得更慢。成本优化的最佳实践是从小实例开始，首先通过向训练集群添加更多实例进行扩展，然后升级到更强大的实例。然而，如果您正在使用深度学习框架和分布式训练，最佳实践是在扩展之前将单个实例上的 GPU/CPUs 数量升级更多，因为涉及的网络安全 I/O 可能会对训练性能产生负面影响。

除了选择正确的基础设施外，您还可以使用优化版本的机器学习框架，从而实现更快的训练。SageMaker 提供了包括 TensorFlow、Chainer、Keras 和 Theano 在内的多个开源机器学习框架的优化版本。这些流行框架的 SageMaker 版本针对所有 SageMaker 机器学习实例的高性能进行了优化。

优化超参数调优成本

超参数调整也是一个成本高昂的任务，需要使用复杂的搜索和算法。最佳实践是依赖由托管 SageMaker 自动模型调优提供的自动化模型调优功能，也称为超参数调整（HPT）。自动模型调优通过运行多个训练作业来找到最佳模型版本，这些作业使用您指定的算法和超参数范围。HPT 然后选择导致最佳模型（根据您指定的目标指标衡量）的超参数值。在幕后，HPT 使用可以在有限数量的训练作业中确定最佳超参数的 ML 技术。

您可以使用预热启动模式进一步加快 HPT 作业的速度。使用预热启动，您不再需要从头开始启动 HPT 作业；相反，您可以根据一个或多个父作业创建一个新的 HPT 作业。这允许您重用父作业中进行的训练作业作为先验知识。预热启动可以帮助您减少与模型调优相关的时耗和成本。

使用管理式 Spot 训练节省训练成本

SageMaker 管理式 Spot 训练将 Spot 实例的成本节省结构应用于超参数调整和训练。管理式 Spot 训练功能利用检查点功能，以便轻松恢复训练作业。由于您不必再次从头开始运行训练，这降低了您的整体训练成本。

利用调试器的洞察和建议

当谈到在 SageMaker 上的深度学习时，使用 GPU 进行训练非常强大，但训练成本可能会迅速增加。SageMaker Debugger 提供了对正在使用的 ML 框架和底层计算资源的深度学习训练洞察。深度分析功能为您提供改进训练性能和减少资源浪费的建议。有关调试器功能的详细讨论，请参阅第七章**，使用 Amazon SageMaker Debugger 分析训练作业*。

使用 SavingsPlan 节省 ML 基础设施成本

一旦您在 AWS 账户中启用 SavingsPlan，它将在您选择的时间范围内分析您的 ML 资源使用情况——过去 7 天、30 天或最多 60 天。然后，该服务推荐合适的计划以优化成本。您还可以从三种不同的选项中选择预付费选项：无前期费用、部分前期（50% 或更多）或全部前期。一旦您配置了这些选项，SavingsPlan 将为您提供如何优化月度支出的详细信息。此外，它还建议一个每小时使用承诺，以最大化您的节省。这些计划涵盖了所有 ML 实例系列、笔记本实例、Studio 实例、训练实例、批量转换实例、实时端点实例、Data Wrangler 实例和 SageMaker Processing 实例，从而帮助优化 ML 工作负载各个阶段的成本。

虽然 Managed Spot Training 和 SavingsPlan 都是节省成本的方法，但它们并不适合结合使用。在使用 SavingsPlan 时，无论是否完全使用，你都需要为承诺的每小时付费。最佳实践是分别使用 SavingsPlan 和 Managed Spot Training。例如，使用 SavingsPlan 来处理可预测的稳定状态重复训练工作负载，而使用 Managed Spot Training 来处理新的训练工作负载和原型设计，在这些情况下，你还没有明确的月度成本概念。

优化推理成本

推理成本通常占机器学习成本的大部分。推理成本在第十章“优化模型托管和推理成本”中进行了详细讨论，该章节详细介绍了几种提高推理性能同时降低推理成本的方法。这些方法包括尽可能使用批量推理，在单个推理端点后面部署多个模型以降低成本并帮助进行高级金丝雀或蓝/绿部署，根据需求扩展推理端点，以及使用 EI 和 SageMaker Neo 以较低的成本提供更好的推理性能。

停止或终止资源

确保你在完成工作后终止或至少停止机器学习资源。虽然训练、超参数调整、批量推理和处理作业的实例将由 SageMaker 管理并自动删除，但你负责笔记本实例、端点和监控计划。停止或删除这些资源，以避免使用自动化脚本（基于空闲时间或计划）停止资源而产生不必要的成本。

以下表格总结了各种 SageMaker 功能及其在构建成本优化的机器学习工作负载中的应用：

![图 13.5 – AWS 服务能力，用于成本优化的机器学习工作负载

![图 13.5 – AWS 服务能力，用于成本优化的机器学习工作负载

图 13.5 – AWS 服务能力，用于成本优化的机器学习工作负载

本节总结了在 AWS 上构建良好架构的机器学习工作负载的最佳实践讨论。

摘要

在本章中，你回顾了构成 Well-Architected 框架的五个支柱——运营卓越、安全性、可靠性、性能和成本优化。然后你深入研究了这些支柱的最佳实践，目的是将这些最佳实践应用于机器学习工作负载。你学习了如何使用 SageMaker 功能与相关 AWS 服务一起构建 AWS 上的良好架构的机器学习工作负载。

当你设计你的机器学习应用时，你通常必须在根据你组织的优先级进行权衡的支柱之间做出权衡。例如，当你开始使用机器学习时，成本优化可能不是你首先考虑的，但建立操作标准可能很重要。然而，随着机器学习工作负载数量的增加，成本优化可能成为一个重要的考虑因素。通过应用你在本章中学到的最佳实践，你可以设计和实施满足你组织需求的机器学习应用，并定期评估你的应用与最佳实践。

在下一章中，你将应用所有这些最佳实践，并了解如何在多个反映现实世界的 AWS 环境中进行操作。

AWS 服务/功能	您应该如何使用它来保护机器学习
IAM	通过 IAM 用户、组、角色和政策实现身份验证、授权和访问控制。
IAM 访问顾问/CloudWatch 事件历史	通过识别优化 IAM 策略的机会。
CloudWatch/CloudTrail	通过收集日志、实施监控和审计。
VPC	通过提供基础设施和网络隔离。
VPC 端点	通过路由流量通过 AWS 网络并避免暴露于公共互联网。
私有链接	通过路由流量通过 AWS 网络并避免暴露于公共互联网。

第十四章：跨账户管理 SageMaker 功能

AWS 发布了关于工作负载管理和治理的最佳实践。这些实践涉及许多领域，例如成本优化、安全性、合规性，以及确保在 AWS 上扩展的工作负载的运营效率。在构建、部署和运营利用 Amazon SageMaker 功能的工作负载时，多账户模式是常见的架构考虑因素之一。

在本节中，我们不会涵盖关于 AWS 账户间 AWS 工作负载治理的既定建议和考虑因素。相反，我们将特别关注一些关于在 AWS 账户间使用 AWS 功能的考虑因素。有关选择正确账户策略的一般建议，请参阅AWS 管理和治理服务（[aws.amazon.com/products/management-and-governance/](https://aws.amazon.com/products/management-and-governance/））和AWS 多账户着陆区策略 – AWS Control Tower（https://docs.aws.amazon.com/controltower/latest/userguide/aws-multi-account-landing-zone.html）。

多账户策略的概念建立在AWS Well-Architected Framework之上，拥有多个 AWS 账户可以使您更好地治理和管理在Amazon SageMaker上跨机器学习开发生命周期（ML 生命周期）的机器学习活动。使用多个 AWS 账户的好处已在通用工作负载中进行了记录。

在本章中，我们将讨论以下与跨多个 AWS 账户管理 SageMaker 功能相关的话题：

• 检查 AWS 多账户环境的概述

• 理解使用多个 AWS 账户与 Amazon SageMaker 一起使用的优势

• 使用 Amazon SageMaker 检查多账户考虑因素

检查 AWS 多账户环境的概述

存在许多有效的多账户策略变体。多账户实现可以根据客户在组织和技术方面的需求而有所不同。为了本章的目的，我们将关注一个基本的多账户策略，专注于与使用 Amazon SageMaker 的机器学习工作负载最相关的账户。我们不会明确指出账户（如安全或日志记录），因为它们已经在 AWS 治理实践中得到了很好的定义。图 14.1展示了我们将用于讨论本章概念的通用、高级账户。

![Figure 14.1 – Example of AWS accounts and SageMaker features

![img/B17249_14_01.jpg]

图 14.1 – AWS 账户和 SageMaker 功能的示例

以图 14.1为例，以下 AWS 账户可以作为端到端 ML 生命周期的一部分使用。请记住，账户命名和资源放置在实现中可能会有很大差异。每个账户都从高层次进行描述，以便更多地关注账户目的而不是命名标准本身：

1. 共享服务账户：此账户可以命名为许多不同的名称，也被称为DevOps或应用程序管理账户。在本章中，我们将此账户称为通常包括用于管理端到端管道和持续管理工作负载的服务和工具的账户。

2. 数据平台/数据湖：此账户作为数据集的中心存储库，包括用于模型构建活动的原始和精选数据集。

3. 数据科学账户：此账户（或账户）代表模型开发活动执行的环境。

4. 测试账户：此账户代表模型将被测试的环境。此账户通常包括集成和性能测试。

5. 生产账户：此账户代表托管支持实时应用程序和工作负载的模型的环境。此账户通常具有最高级别的控制和限制。

6. 服务目录主账户：此账户的目的是维护一个中心枢纽，可以提供通过AWS 服务目录的产品，并用于在 spoke 账户中一致地配置资源，例如数据科学账户。spoke 账户是已被授予从主账户管理的投资组合访问权限的 AWS 账户。

再次强调，这些账户是潜在账户结构的概述，并不包括符合您自身环境要求的每个有效变体。在下一节中，我们将讨论使用多个 AWS 账户的具体好处，特别是它们与在 ML 生命周期中使用 Amazon SageMaker 的关系。

理解使用多个 AWS 账户与 Amazon SageMaker 的好处

在本节中，我们将介绍使用多个 AWS 账户的一般、高层次的好处。我们还将讨论使用 Amazon SageMaker 横跨 ML 生命周期时的特定考虑因素：

• 好处 #1：实施特定的安全控制

  使用多个 AWS 账户允许客户实施针对工作负载、环境或数据的特定安全控制。例如，某些工作负载可能有独特的安全要求（如 PCI 合规性）并需要额外的控制。使用多个账户允许您在 AWS 账户级别保持细粒度的控制，这些控制是隔离和可审计的。

  对于机器学习生命周期中包含的模型构建活动，使用多个 AWS 账户允许您创建和管理包含特定于机器学习的控制以及您安全要求的数据科学环境。在机器学习中，数据科学家需要访问实时生产数据。通常，在数据科学家获得访问权限之前，这些数据应该被清除任何敏感数据。然而，也存在数据科学家可能需要访问这些敏感数据的情况。通过将可以访问敏感数据的数据科学环境和无法访问敏感数据的数据科学环境分开，您能够在账户级别实施控制，并在账户级别进行审计。

  对于机器学习生命周期中包含的模型部署活动，您将希望确保您的模型在处理实时流量或提供关键推理数据时得到管理和控制。这适用于任何其他生产应用程序。您希望确保可用性。就像您不会在开发人员拥有广泛访问权限的同一账户中实施实时网络应用程序一样，对于服务于实时生产工作负载的机器学习工作负载也是如此。

  例如，一个SageMaker 端点服务于生产应用程序应该托管在一个已经实施所有控制和限制访问权限的 AWS 账户中（您希望这种情况适用于任何其他生产工作负载）。这确保了端点不会在可能具有较少控制和更广泛访问权限的下级账户中意外删除。

• 好处 #2：支持多个团队的需求

  大型组织和企业通常在寻找可扩展的机制来支持不同团队的资源需求和责任。在业务线之间，通常会有独立的 AWS 账户。机器学习工作负载也是如此。这里的一个例子包括数据科学环境（如第2 章**，数据科学环境）中所述，每个团队可能对构建机器学习模型的环境有不同的要求。在这种情况下，通常会有多个数据科学环境支持多个团队，同时也支持团队之间和团队内部的需求。

检查使用 Amazon SageMaker 的多账户考虑因素

在本节中，我们将讨论使用 Amazon SageMaker 的多账户考虑因素。我们首先将查看一个通用参考架构，然后讨论在机器学习生命周期中针对特定 SageMaker 功能的一些考虑因素。

图 14.2 展示了一个多账户结构示例，将关键 SageMaker 特性和其他常见 AWS 服务映射到它们通常使用的账户中。这不是一个一刀切的观点，因为可能还有其他 AWS 服务或第三方工具正在执行 AWS 服务所执行的一个或多个功能。例如，您的模型注册库可能是SageMaker 模型注册库，或者它可能是Amazon DynamoDB或MLflow等工具：

图 14.2 – AWS 账户间服务使用示例

AWS 或等效的支持 ML 生命周期映射到阶段、模型构建或模型部署。这是与之前提到的通过账户实施安全控制的益处相结合的，以及支持每个账户内操作的不同角色和人物的需求。账户的命名和结构可能在多账户实现中有所不同。因此，在以下列表中，我们描述了每个账户的目的，了解这些可能在不同实现中有所不同：

• 共享服务账户或 DevOps 账户通常用于集中管理跨多个账户和环境的工具。在这种情况下，您可以看到一些常见服务，例如用于管理 SageMaker 兼容图像进行训练和推理的Amazon Elastic Container Registry。您还经常找到使持续集成（CI）/ 持续交付或部署（CD）实践成为可能的开发者工具。

• 有自动化和编排跨账户机器学习工作流程步骤所需的工具。这些工具可能包括原生AWS 开发者工具或第三方工具，如GitHub或Jenkins。在此账户中使用的工具和服务需要跨账户身份和访问管理（IAM）权限策略。最后，您需要创建用于监控机器学习工作负载健康状况的集中式仪表板。这些共享仪表板通常放置在共享服务账户、基础设施账户或特定于环境或工作负载的账户中，例如生产环境。

• 数据平台，或数据湖账户，包含使用原生服务构建的数据湖，例如AWS Lake Formation或自定义数据湖。此账户也是放置用于跨团队存储特征的集中式特征存储的常见选项。

• 数据科学账户主要用于模型构建活动，因此这包括执行数据理解、特征工程、跨实验的模型训练和模型评估所需的所有活动。此账户需要访问执行这些模型构建活动所需的 SageMaker 功能，包括Amazon SageMaker Studio、SageMaker 训练作业、SageMaker Processing 作业和SageMaker Data Wrangler等功能。

• 除了模型构建所需的常见功能外，当您使用SageMaker 项目时，此账户还会配置额外的 AWS 服务。默认情况下，SageMaker 项目会自动配置 AWS 开发者工具和 AWS 服务目录产品，用于在您用于模型构建活动的账户中内置 MLOps 项目模板。

• 工作负载或环境特定的账户，如测试和生产，用于托管实时模型。这些账户也通常托管使用模型更广泛解决方案。从 SageMaker 的角度来看，这些账户中使用的功能通常专注于模型部署和操作活动。

• 最后，您可能还有一个AWS 服务目录主账户或基础设施账户，其中包含可以跨多个团队共享的产品组合。这被称为中心账户。它可以用来为数据科学环境或带有 SageMaker 项目的自定义 MLOps 项目模板创建和管理产品中央目录。

一些 AWS 功能非常特定于所需它们的人和组织以及机器学习生命周期中的阶段。例如，SageMaker 训练作业通常由数据科学家在模型构建活动中使用，或作为自动化模型重新训练工作流的一部分所需。然而，有一些 AWS 服务跨越机器学习生命周期的多个阶段，需要一些独特的考虑。这些将在下一节中进一步探讨。

SageMaker 功能的考虑因素

在尝试在多账户策略中实施 SageMaker 的一些功能时，需要考虑几个额外的因素，特别是因为这些功能被用于整个机器学习生命周期中。例如，SageMaker Processing、SageMaker 训练作业和 SageMaker 托管等功能的考虑因素通常与生命周期中的特定阶段相关。因此，它们在账户间的位置在图 14.3中进行了说明。在本节中，我们将介绍一些跨越机器学习生命周期并需要作为您的多账户策略一部分额外考虑的 SageMaker 功能。

Amazon SageMaker Pipelines

SageMaker Pipelines 允许您使用 Amazon SageMaker Python SDK 编写机器学习管道。管道包括专注于数据准备（通过 SageMaker Processing）、模型训练（通过 SageMaker 训练作业）和模型部署（通过 SageMaker 批量转换）的 SageMaker 原生步骤。CallbackStep 用于与其他 AWS 服务或第三方任务集成。最后，Pipelines 包含用于管道功能的内置步骤，例如条件步骤。SageMaker Pipelines 中的所有当前功能都专注于批量推理的模型构建和模型部署。因此，我们将探讨两种在使用 SageMaker Pipelines 时需要考虑跨账户的常见模式。

在第一种模式中，我们将讨论一个端到端管道场景，其中您使用 SageMaker 托管部署模型进行实时推理。在这种情况下，您可以在您的数据科学账户中使用 SageMaker Pipelines 创建一个管道，用于自动化模型构建活动。这些活动包括数据准备、模型训练、模型评估以及用于模型注册的条件步骤。一旦模型通过评估并注册，它就可以用作触发下游部署到您的账户（如测试或生产）的触发器，这些账户将托管和集成已部署的端点。此相同的管道可用于您的重新训练工作流程。

在这种情况下，可以使用跨账户资源策略将模型部署到更高环境，如图 14.3 所示。跨账户资源策略是为 SageMaker 模型注册中的模型组创建的。该模型组包含模型版本、推理图像的 Amazon ECR 存储库以及模型实体的 S3 位置。可以创建包含这三个资源的跨账户资源策略，然后允许您将数据科学环境中创建的模型部署到您的应用程序或工作负载环境中（如测试或生产）。

参考以下图：

图 14.3 – 将在数据科学账户中训练的模型部署到跨账户资源策略

在第二种模式中，我们将讨论一个端到端管道场景，其中您使用 SageMaker 托管部署模型进行批量推理。在这种情况下，您可以在您的数据科学账户中使用 SageMaker Pipelines 创建一个管道，用于自动化模型构建活动。这些活动包括数据准备、模型训练、模型评估、用于模型注册的条件步骤以及批量转换步骤。在这种情况下，根据您的用例和需求，有两种选择：

• 在数据科学账户中运行你的端到端管道：如果你使用批量转换来验证你的模型，或者运行没有生产级可用性要求的批量作业，这个选项是有效的。

• 在工作负载账户中运行你的端到端管道：如果你使用批量转换来部署具有生产级可用性要求或需要与高级环境中系统集成的模型，这个选项是有效的。

Amazon SageMaker 项目

Amazon SageMaker 项目通过结合 CI/CD 实践（如源和版本控制）以及将自动化部署管道集成到一个或多个目标环境中，在 SageMaker 管道的基础上构建。当考虑将 SageMaker 项目与多个 AWS 账户集成时，以下是一些关键点需要理解：

• 当你为你的 Studio 域或域用户启用项目模板时，项目启用的账户将是用于通过 AWS 服务目录提供的内置 MLOps 项目模板的账户。如果你构建自定义的 MLOps 项目模板，你仍然可以使用中心辐射模型来管理你的组合和产品在服务目录主账户中。

• 所有内置的 MLOps 项目模板都将配置以下资源在同一账户中，其中项目被启用：AWS CodePipeline、AWS CodeBuild、AWS CodeCommit和Amazon EventBridge。这很重要，因为一些组织假设或要求这些服务通过共享服务账户（或等效的）集中配置和管理。

• 内置的 MLOps 项目模板将部署你的 SageMaker 端点到项目启用的同一账户。此行为可以被修改。然而，模型注册仍然存在于数据科学账户中。

Amazon SageMaker 特征存储

Amazon SageMaker 特征存储允许创建和共享特征，无论是用于模型构建活动还是模型推理。由于特征存储可以用于模型构建活动，也可以作为模型推理的依赖项，因此确保特征在团队之间保持一致，并在需要时始终可用是很重要的。

当你创建一个特征存储时，它将在你创建它的账户中实例化。然而，当需要集中特征以在团队之间共享，或使用特征存储进行实时推理时，这可能不是最佳选择。如果你在你的数据科学账户中创建特征存储，那么该账户可能为更广泛的角色集提供了更少的控制和更多的访问权限。这为支持生产应用程序带来了风险。

与特征存储相关的两种常见跨账户模式有助于在团队之间促进特征共享和一致性，同时允许在需要时为团队或组织特定的特征存储提供灵活性。

在第一种模式中，如图 14.4所示，在单独的 AWS 账户中创建了一个中央特征存储，可以通过 IAM 跨账户角色进行特征的人口和消费。对于特征的人口，这通常是通过一个自动化的特征管道以固定频率收集数据来完成的。然而，也可以从数据科学环境为更静态的特征进行操作。特征可以用于推理以及模型构建活动。模型构建活动通常使用跨账户权限从离线特征存储中消耗特征：

图 14.4 – 中央特征存储模式

在第二种模式中，类似于图 14.4，有一个中央特征存储用于共享可能对跨团队普遍或有用的特征，同时也有灵活性，允许各个团队在各自的 AWS 账户中创建自己的特征存储。这种模式有助于促进在中央存储中共享常见特征的能力，同时允许特定团队或应用程序的工作负载或特定应用的特征在仅需要访问这些特征的特定团队或应用程序的账户中得到保护。

Amazon SageMaker Data Wrangler

Amazon SageMaker Data Wrangler 允许数据科学家在机器学习生命周期中的模型构建阶段探索和准备数据。由于数据整理器是专门为特征工程和数据准备而构建的，因此最常与数据整理器一起工作的角色是ML 构建者。大多数模型构建活动将在一个或多个数据科学账户内进行；然而，通常需要一种方式来安全地从数据平台或数据湖账户访问数据，以进行这些模型构建活动。

图 14.5 展示了从使用数据科学账户（其中使用数据整理器）到数据平台/数据湖账户（数据通常存储在此处）启用跨账户访问的常见模式。在这种情况下，我们使用 AWS Lake Formation 来构建我们的安全数据湖。当使用其他技术构建数据湖时，这些概念同样适用；然而，实现方式可能不同：

图 14.5 – SageMaker Data Wrangler 的跨账户访问

使用数据整理器，您可以使用 AWS IAM 启用跨账户权限。为此，您需要在数据科学账户中为数据整理器设置跨账户权限，以便访问存储在您的数据平台/数据湖账户中的数据表。这是通过 Lake Formation 权限实现的。这种设置允许您仍然为数据科学家提供数据集的访问权限，同时还可以利用 Lake Formation 提供的安全控制功能。

例如，您可以选择仅共享特定的表，甚至仅共享存储在您的数据湖中的特定表的列。表是通过 AWS Resource Access Manager 共享的。这为在 AWS 账户间共享 Lake Formation 表提供了一种方式。这使用户能够访问次要账户中的共享表。这些共享表可以直接在 Lake Formation 中访问，但它们也作为数据源，通过 Amazon Athena，在您的 Data Wrangler UI 中可用。

摘要

在本章中，我们讨论了使用多个账户来管理和操作使用 Amazon SageMaker 的机器学习工作负载在 ML 生命周期中的好处。我们还探讨了 ML 生命周期中账户隔离的常见模式。最后，我们专门关注了在账户间最常使用的 SageMaker 功能，以及您在设计和构建端到端机器学习解决方案时应注意的考虑因素。

本章总结了本书内容，其中涵盖了 SageMaker 在数据准备、模型训练和操作等机器学习生命周期特征方面的最佳实践。在本书中，我们讨论了您在创建自己的项目时可以借鉴的最佳实践和考虑因素。我们使用了一个示例用例，即使用开放天气数据，在本书的各章节中展示这些概念。这样做的目的是让您能够亲身体验所讨论的概念和实践。我们希望您能够将这些实践应用到自己的项目中，同时从 Amazon SageMaker 提供的整体功能和能力中受益。

参考资料

请参阅以下参考资料，了解 AWS 在治理和多账户策略方面的最佳实践，以及与 SageMaker 功能相关的具体信息：

• 在您的 AWS 环境中建立最佳实践：aws.amazon.com/organizations/getting-started/best-practices/

• AWS Control Tower – AWS 服务用于建立和管理多个 AWS 账户：aws.amazon.com/controltower/

• SageMaker – 将模型部署到不同的 AWS 账户：aws.amazon.com/premiumsupport/knowledge-center/sagemaker-cross-account-model/

• SageMaker Data Wrangler – 启用跨账户访问：aws.amazon.com/blogs/machine-learning/enable-cross-account-access-for-amazon-sagemaker-data-wrangler-using-aws-lake-formation/

• SageMaker Pipelines – 多账户部署：aws.amazon.com/blogs/machine-learning/multi-account-model-deployment-with-amazon-sagemaker-pipelines/

• SageMaker 特征存储：aws.amazon.com/blogs/machine-learning/enable-feature-reuse-across-accounts-and-teams-using-amazon-sagemaker-feature-store/