AWS-应用机器学习与高性能计算-全-

AWS 应用机器学习与高性能计算（全）

原文：annas-archive.org/md5/f0e3669000f461b1b15efc00e448b120

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

应用机器学习（ML）和高性能计算（HPC）对于解决世界上最复杂的问题至关重要，包括基因组学、自动驾驶汽车、计算流体动力学和数值优化。由于这些应用需要高计算能力，HPC 曾经只被能够负担得起的大型组织使用。现在，它对所有人开放，从个人研究小组到初创公司和大型企业，都可以使用亚马逊网络服务（AWS）云技术。

本书提供了对基本概念的完整分步解释，并辅以实际示例。您将从探索 AWS 上可扩展 HPC 的几乎无限的基础设施和快速网络开始，包括相关工具和技术的概述。您将学习如何使用 AWS 上的 HPC 开发大规模 ML 应用，您将了解各种架构组件，并学习性能优化，通过实际应用解决各个领域的现实世界用例。

到本书结束时，您将能够遵循行业最佳实践，解决应用生命周期中遇到的关键痛点，使用 AWS 上的高性能计算（HPC）构建和部署您自己的大规模机器学习（ML）应用。

本书面向对象

本书是为机器学习（ML）、人工智能（AI）、数值优化和基因组学等领域的研究人员、工程师、架构师和管理人员设计的，这些领域需要 HPC。本书非常适合以下角色的人员：

数据和人工智能科学家
人工智能/机器学习工程师
人工智能/机器学习产品经理
人工智能产品所有者
人工智能/机器学习研究人员

通常，任何具备 Python 基础知识的人工智能/机器学习爱好者都将能够阅读、理解和应用从本书中获得的知识。

本书涵盖内容

第一章，高性能计算基础，介绍了 HPC 的概念，强调了 HPC 与实际场景相关的重要性。然后我们讨论了 HPC 的技术进步以及您如何使用它来解决具有无限容量、最先进的计算能力和云的弹性等复杂商业问题，同时优化成本，以实现更快的创新和获得竞争优势。

第二章，数据管理和传输，深入探讨了数据管理和传输。在云上运行高性能计算（HPC）应用的第一步是将所需数据移动到云上。因此，本章重点介绍了数据迁移的不同方面，包括企业可能面临的挑战和关键痛点，以及 AWS 数据迁移服务如何帮助解决这些问题，同时遵循最佳实践并保持数据完整性、一致性和安全性。

第三章, 计算和网络，解释了当你将数据存储在云端后，你需要了解 AWS 提供的计算选项以及它们之间的差异，以便根据你的业务需求选择最佳选项。此外，为了扩展和保障你的高性能计算（HPC）应用，我们接着深入到网络部分，解释私有 VPC、低延迟网络以及优化实例间通信性能的概念。

第四章, 数据存储，解释了在开始使用高性能计算（HPC）进行机器学习之前，了解临时和永久存储需求的数据存储选项和存储成本是很重要的。本章深入探讨了 AWS 生态系统中的各种存储服务，以帮助你为不同的任务选择合适的工具。

第五章, 数据分析，教你如何使用 AWS 探索数据、收集指标、执行数据相关性分析，并处理大量数据，以确保在使用它进行机器学习模型训练之前数据的质量。

第六章, 机器学习模型的分布式训练，展示了如何通过利用分布式数据并行和模型并行概念，使用大量数据实现大型机器学习模型的实施。

第七章, 大规模部署机器学习模型，讨论了模型部署和推理。我们将从 AWS 上托管部署的含义开始，然后讨论合适的部署选项，接着是各种推理选项（批量、异步和实时）。然后我们将讨论 AWS 基础设施上模型端点的可靠性和可用性，以及不同版本模型的蓝/绿部署选项。

第八章, 优化和管理边缘部署的机器学习模型，探讨了边缘设备上的机器学习模型。我们将从边缘计算简介开始，然后讨论我们需要考虑的机器学习模型优化因素。你还将了解边缘部署的架构设计。

第九章, 实时推理的性能优化，讨论了用于机器学习模型的一些关键性能指标，减少大型模型内存占用足迹的技术，选择合适的机器（实例类型）部署模型，负载测试以及模型性能调优。

第十章，数据可视化，涵盖了 Amazon SageMaker Data Wrangler 工具，该工具使数据科学、机器学习和分析领域的用户能够构建深入的数据可视化，而无需编写大量代码。此外，我们还将简要介绍 AWS 的图形优化实例，因为这些实例可以用于创建动态实时数据可视化，以及其他高性能计算应用，如游戏流和机器学习。

第十一章，计算流体动力学，介绍了计算流体动力学（CFD）领域，该领域使用数值分析来解决流体流动问题。CFD 在许多行业中都有广泛的应用，如汽车行业、石油和天然气以及制造业。我们将讨论如何在 AWS 上使用 CFD 求解器处理大规模问题，以及最近的机器学习进展如何帮助加速 CFD 应用。

第十二章，基因组学，介绍了基因组学领域，以及 AWS 如何帮助客户处理大规模基因组学应用，这些应用通常使用大量数据集。我们还讨论了存储和分析此类数据的典型架构，以及当前机器学习在基因组学中的应用，随后是一个蛋白质结构分析的示例。

第十三章，自动驾驶汽车，讨论了自动驾驶汽车（AVs）以及在不同自动化级别上安全高效地操作车辆所使用的技术。如今，公司使用来自传感器和摄像头的大规模集群中的皮字节级数据来执行深度神经网络（DNN）训练。具体来说，我们将讨论支持 AV 开发的服务、大规模数据处理架构以及使用 DNN 训练 AV 模型的应用。

第十四章，数值优化，介绍了数值优化是什么，以及为什么解决我们在这个领域可能遇到的大规模问题是重要的。我们将讨论该领域的一些常见用例和可用于解决这些用例的高性能计算。我们还将讨论机器学习在数值优化中的应用。

为了充分利用这本书

为了跟随本书中的文本和示例，建议您具备 Python 和高性能计算的基础知识，以及数据分析、机器学习和人工智能的中级理解。此外，您应该能够访问以下技术工具，以便处理代码和实验示例：

软件/硬件要求	操作系统要求
网络浏览器（Chrome、Firefox 或 Safari）	Windows、Linux 或 macOS
AWS 账户

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

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS。如果代码有更新，它将在 GitHub 仓库中更新。

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

下载彩色图像

我们还提供了一份包含本书中使用的截图和图表彩色图像的 PDF 文件。您可以从这里下载：packt.link/SqXiF。

使用的约定

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

文本中的代码：表示文本中的代码单词、数据库表名、文件夹名、文件名、文件扩展名、路径名、虚拟 URL、用户输入和 Twitter 昵称。以下是一个示例：“下一步是使用模型对象的deploy()方法创建 HTTPS 端点。”

代码块按照以下方式设置：

import numpy as np
import json
with open("horse_cart.jpg", "rb") as f:
    payload = f.read()
    payload = bytearray(payload)

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

smp_options = {
    "enabled":True,
    "parameters": {
        "partitions": 1,
        "placement_strategy": "spread",
        "pipeline": "interleaved",
        "optimize": "speed",
        "ddp": True,
    }
}

任何命令行输入或输出都按照以下方式编写：

$ sudo tail –f /greengrass/v2/logs/com.greengrass.SageMakerEdgeManager.ImageClassification.log

粗体：表示新术语、重要单词或您在屏幕上看到的单词。例如，菜单或对话框中的单词以粗体显示。以下是一个示例：“在配置组件页面，选择aws.greengrass.SageMakerEdgeManager组件，并选择配置组件。”

小贴士或重要注意事项

看起来是这样的。

联系我们

我们欢迎读者的反馈。

一般反馈：如果您对本书的任何方面有疑问，请通过 mailto:customercare@packtpub.com 给我们发邮件，并在邮件的主题中提及书名。

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

盗版：如果您在互联网上遇到任何形式的我们作品的非法副本，如果您能提供位置地址或网站名称，我们将不胜感激。请通过 mailto:copyright@packt.com 与我们联系，并提供材料的链接。

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

分享您的想法

一旦您阅读了《在 AWS 上应用机器学习和高性能计算》，我们非常乐意听到您的想法！请点击此处直接进入此书的亚马逊评论页面并分享您的反馈。

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

下载此书的免费 PDF 副本

感谢您购买此书！

您喜欢在旅途中阅读，但无法携带您的印刷书籍到任何地方吗？您的电子书购买是否与您选择的设备不兼容？

别担心，现在，随着每本 Packt 书籍，您都可以免费获得该书的 DRM 免费 PDF 版本。

在任何地方、任何设备上阅读。直接从您最喜欢的技术书籍中搜索、复制和粘贴代码到您的应用程序中。

优惠远不止这些，您还可以获得独家折扣、时事通讯和每日免费内容的每日电子邮件。

按照以下简单步骤获取优惠：

扫描下面的二维码或访问以下链接

packt.link/free-ebook/978-1-80323-701-5

提交您的购买证明
就这些了！我们将直接将您的免费 PDF 和其他优惠发送到您的电子邮件。

第一部分：介绍高性能计算

第一部分的目标是介绍高性能计算（HPC）的概念和可能性艺术，最重要的是，让您了解曾经仅限于大型企业、政府机构或学术机构的内容，现在也触手可及，以及行业如何利用它来推动创新。

本部分包括以下章节：

第一章，高性能计算基础
第二章，数据管理和传输
第三章，计算和网络
第四章，数据存储

第一章：高性能计算（HPC）基础

高性能计算（HPC）影响着你生活的方方面面，从你的早晨咖啡到开车去办公室，了解天气预报，接种疫苗，观看的电影，乘坐的航班，玩的游戏，以及许多其他方面。我们中的许多行为都留下了数字足迹，导致产生了大量数据。为了处理这些数据，我们需要大量的处理能力。高性能计算（HPC），也称为加速计算，将来自节点集群的计算能力聚合起来，并将工作分配给各种相互连接的处理器，从而实现比使用单一计算机或机器所能达到的更高的性能，如图图 1.1所示。这有助于解决复杂的科学和工程问题，在药物发现、飞行模拟、供应链优化、金融风险评估等关键业务应用中：

图 1.1 – HPC

例如，药物发现是一个数据密集型过程，涉及大量的计算来模拟病毒蛋白与人类蛋白的结合。这是一个极其昂贵的过程，可能需要数周或数月才能完成。通过将机器学习（ML）与加速计算相结合，研究人员可以以更高的速度和精度模拟药物与蛋白的相互作用。这导致实验速度加快，显著缩短了上市时间。

在本章中，我们将学习高性能计算（HPC）的基本原理和重要性，随后介绍该领域的技术进步。我们将了解限制因素以及开发者如何从云的弹性中受益，同时优化成本以更快地创新，从而获得竞争优势。

本章将涵盖以下主题：

我们为什么需要高性能计算（HPC）？
原地高性能计算（HPC）的限制
在云上执行高性能计算（HPC）的好处
利用高性能计算（HPC）推动各行业创新

我们为什么需要高性能计算（HPC）？

根据 Statista 的数据，全球数据的增长速度预计将迅速增加，并在 2020 年达到 64.2 泽字节。到 2025 年，数据量预计将增长到超过 180 泽字节。由于 COVID-19 大流行，2020 年的数据增长达到了新高，因为更多的人开始在线学习并远程在家工作。随着数据的持续增加，能够分析和处理数据的需求也在增加。这就是高性能计算发挥作用的地方。它帮助组织超越现有能力，并利用先进的计算技术探索可能性。如今，曾经仅限于大型企业和学术界的高性能计算应用正在各行各业中流行。这些行业包括材料科学、制造业、产品质量改进、基因组学、数值优化、计算流体动力学等。随着云基础设施使更多组织无论规模大小都能访问高性能计算，其应用列表将继续增加，同时优化成本，帮助更快地进行创新并获得竞争优势。

在我们更深入地探讨在云上执行高性能计算之前，让我们了解在本地运行高性能计算应用的局限性，以及我们如何通过使用云提供的专业高性能计算服务来克服这些局限性。

本地高性能计算的局限性

高性能计算应用通常基于大量数据训练的复杂模型，这需要高性能硬件，如图形处理单元（GPU）以及在不同机器间分配工作负载的软件。一些应用可能需要并行处理，而其他应用可能需要低延迟和高吞吐量的网络。同样，游戏和视频分析等应用可能需要使用快速输入/输出子系统以及 GPU 来加速性能。在本地满足所有不同类型的高性能计算应用在成本和维护方面可能令人望而却步。

一些已知的挑战包括但不限于以下内容：

高额前期资本投资
长采购周期
在整个生命周期内维护基础设施
技术更新
预测年度预算和容量需求

由于上述限制，规划一个高性能计算系统可能是一个艰巨的过程，其投资回报率（ROI）可能难以证明。这可能会成为创新的障碍，导致增长缓慢、效率降低、机会丧失以及可扩展性和弹性有限。让我们详细了解这些影响。

创新障碍

本地基础设施的约束可能会限制系统设计，使其更多地关注硬件的可用性，而不是业务用例。如果你的一些新想法没有得到现有基础设施的支持，你可能会考虑不到这些想法，从而阻碍你的创造力和组织内的创新。

效率降低

一旦你完成了系统各个组件的开发，你可能不得不在优先级队列中等待很长时间来测试你的作业，这可能会花费数周时间，即使运行时间只需要几个小时。本地基础设施旨在利用昂贵的硬件，通常会导致非常复杂的作业执行优先级策略，从而降低你的生产力和创新能力。

错过的机会

为了充分利用最新技术，组织必须更新他们的硬件。以前，典型的三年更新周期足以保持最新状态，以满足高性能计算工作负载的需求。然而，由于技术进步迅速和创新步伐加快，组织需要更频繁地更新其基础设施，否则可能会对收入产生更大的下游业务影响。例如，人工智能（AI）、机器学习（ML）、数据可视化、金融市场风险分析等技术正在推动本地基础设施的极限。此外，由于云的出现，许多这些技术都是云原生，在云上运行时在大数据集上提供更高的性能，尤其是在使用临时数据的工作负载中。

可扩展性和弹性有限

高性能计算应用严重依赖于容器、GPU 和无服务器技术等基础设施元素，这些元素在本地环境中并不容易获得，并且通常有一个漫长的采购和预算审批流程。此外，维护这些环境，确保它们得到充分利用，甚至升级操作系统或软件包，都需要技能和专用资源。在相同的硬件上部署不同类型的高性能计算应用在可扩展性和灵活性方面非常有限，并且不能为你提供完成工作的正确工具。

既然我们已经了解了在本地进行高性能计算的限制，那么让我们看看我们如何通过在云上运行高性能计算工作负载来克服这些限制。

在云上运行高性能计算（HPC）的好处

在云上几乎拥有无限容量，您可以超越本地高性能计算的限制。您可以根据业务用例重新构想新的方法，更快地进行实验，并从大量数据中获得洞察，而无需进行昂贵的本地升级和漫长的采购周期。您可以在云上运行复杂的模拟和深度学习模型，并利用可扩展的计算能力、高性能存储和高吞吐量网络，快速从想法过渡到市场。总之，它使您能够推动创新，在分布式团队之间协作，提高运营效率，并优化性能和成本。让我们更深入地了解这些益处的每一个。

推动创新

将高性能计算（HPC）工作负载迁移到云端，有助于您打破创新的障碍，开启无限可能的大门。您可以快速失败并前进，尝试成千上万的实验，并基于数据进行商业决策。我最喜欢的益处是，一旦您解决了问题，它就会得到解决，您在系统升级或技术更新后无需重新审视。它消除了返工和硬件维护，让您专注于业务用例，并使您能够快速设计、开发和测试新产品。云提供的弹性，允许您根据需求扩展和缩减基础设施。此外，基于云的服务提供原生功能，这可以减轻负担，让您无需自己编写和管理所有实用程序库，即可采用经过测试和验证的高性能计算（HPC）应用程序。

使分布式团队之间能够安全协作

云上的 HPC 工作负载允许您与团队在全球范围内共享设计、数据、可视化和其他工件，而无需复制或传播敏感数据。例如，构建数字孪生（物理对象的实时数字对应物）有助于预测性维护。它可以实时获取对象的状态，并监控和诊断对象（资产）以优化其性能和利用率。要构建数字孪生，需要跨团队技能集，这些技能可能位于远程位置以从各种物联网传感器捕获数据，进行广泛的假设分析，并精心构建模拟模型以开发物理对象的准确表示。云提供了一个协作平台，不同团队可以在近乎实时的情况下与模拟模型互动，而无需移动或复制数据到不同的位置，并确保符合快速变化的行业法规。此外，您可以使用云提供的本地功能和服务的功能，例如 AWS IoT TwinMaker，它可以使用来自多个来源的现有数据，创建物理系统的虚拟副本，并将 3D 模型结合起来，更快、更轻松地为您提供运营的整体视图。云上 HPC 技术的广泛全球存在，允许您与不同地理区域的远程团队合作，而无需在安全性和成本之间做出权衡。

提高运营效率

运营效率意味着您能够支持工作负载的开发和执行，获得洞察力，并持续改进支持您应用程序的流程。设计原则和最佳实践包括自动化流程、进行频繁且可逆的更改、经常优化您的操作，以及能够预测和从故障中恢复。将您的 HPC 应用程序部署在云上，您就能做到这一点，因为您可以将基础设施作为代码进行版本控制，类似于您的应用程序代码，并将其与您的持续集成和持续交付（CI/CD）管道集成。此外，通过按需访问无限的计算能力，您将不再需要长时间排队等待作业运行。您可以跳过等待，专注于解决业务关键问题，为您提供适合工作的正确工具。

优化性能

性能优化涉及高效使用资源的能力，以及能够随着应用程序的变化或发展而维护它们。一些最佳实践包括使实施对您的团队更容易，尽可能使用无服务器架构，以及能够更快地进行实验。例如，开发机器学习模型并将其集成到您的应用程序中需要特殊的专业知识，这可以通过使用云提供商提供的现成模型来缓解，例如 AWS 的 AI 和机器学习堆栈中的服务。此外，您可以利用专门为 HPC 设计的计算、存储和网络服务，消除专用硬件的长期采购周期。您可以快速进行基准测试或负载测试，并使用这些数据来优化您的作业，而无需担心成本，因为您只需为在云端使用资源的时间付费。我们将在第五章数据分析和第六章**机器学习模型的分布式训练中更深入地了解这个概念。

优化成本

成本优化是一个持续的过程，涉及在整个应用程序生命周期内监控和改进资源利用率。通过采用按需付费的消费模式，并根据业务需求增加或减少使用量，您可以实现潜在的节省成本。您可以在几分钟内快速部署和取消部署 HPC 集群，而不是几天或几周。这使得您能够快速获取所需资源。您可以通过计算实现的企业价值和交付成本来衡量整体效率。有了这些数据，您不仅可以做出明智的决策，还可以了解通过增加应用程序的功能和降低成本所获得的收益。

在云端运行高性能计算（HPC）可以帮助您克服与传统的本地基础设施相关的限制：固定容量、漫长的采购周期、技术过时、高额的前期资本投资、维护硬件以及应用定期的操作系统（OS）和软件更新。云端为您提供几乎无限的 HPC 容量，使用最新的技术来促进创新，这有助于您根据业务需求而不是可用硬件来设计您的架构，最小化作业队列的需求，并在优化成本的同时提高运营和性能效率。

接下来，让我们看看不同行业如自动驾驶汽车（AVs）、制造业、媒体和娱乐、生命科学和金融服务如何通过 HPC 工作负载推动创新。

利用 HPC 推动跨行业创新

每个行业和类型的 HPC 应用都面临着不同类型的挑战。云供应商如 AWS 提供的 HPC 解决方案帮助所有公司，无论其规模大小，这导致了强化学习、数字孪生、供应链优化和自动驾驶汽车等新兴 HPC 应用的兴起。

让我们来看看生命科学和医疗保健、自动驾驶汽车和供应链优化中的一些用例。

生命科学和医疗保健

在生命科学和医疗保健领域，几乎每分钟都会捕捉到大量敏感且有意义的数据。利用 HPC 技术，我们可以利用这些数据，通过对关键疾病进行有意义的洞察来拯救生命，减少测试实验室样本、药物发现等所需的时间，以及满足核心安全和合规要求。

以下是一些在医疗保健和生命科学领域的新兴应用。

基因组学

您可以使用 AWS 提供的云服务来安全地存储和共享基因组数据，这有助于您构建和运行预测或实时应用程序，从而加速从基因组数据到基因组洞察的过程。这有助于显著减少数据处理时间，并对诸如癌症和阿尔茨海默病等关键疾病进行因果分析。

成像

通过使用计算机视觉和数据集成服务，您可以提高图像分析并促进长期数据保留。例如，通过使用机器学习分析 MRI 或 X 射线扫描，放射学公司可以提高运营效率，并为他们的患者快速生成实验室报告。AWS 为成像提供的一些技术包括 Amazon EC2 GPU 实例、AWS Batch、AWS ParallelCluster、AWS DataSync 和 Amazon SageMaker，我们将在后续章节中详细讨论。

计算化学和基于结构的药物设计

结合最先进的蛋白质分类深度学习模型、蛋白质结构解决方案的进步以及描述 3D 分子模型的算法，并利用高性能计算资源，您可以将上市时间大幅缩短。例如，诺华公司在 AWS 云上完成的一个项目中，他们能够在不到一周的时间内对 1000 万个化合物进行针对常见癌症目标的筛选，根据他们的内部计算，如果他们在内部进行类似的实验，那么将需要大约 4000 万美元的投资。通过在云上使用 AWS 服务和功能运行此实验，他们能够利用他们 39 年的计算化学数据和知识。此外，进行实验仅花费了 9 小时和 4232 美元，从而提高了他们的创新和实验速度。他们成功地从 1000 万个化合物中筛选出了三个。

现在我们已经了解了一些在生命科学和医疗保健领域的应用，让我们来讨论一下汽车和交通行业是如何利用高性能计算（HPC）来构建自动驾驶汽车的。

自动驾驶汽车

深度学习模型（如强化学习、目标检测和图像分割）的进步，以及计算技术的技术进步，以及在边缘设备上部署模型，为自动驾驶汽车铺平了道路。为了设计和构建自动驾驶汽车，系统的所有组件都必须协同工作，包括规划、感知和控制系统。这还要求收集和处理大量数据，并利用这些数据创建反馈循环，以便车辆可以根据道路上交通的实时变化调整其状态。这需要具有高 I/O 性能、网络、专门的硬件协处理器（如 GPU 或现场可编程门阵列（FPGA）），以及分析和深度学习框架。此外，在自动驾驶汽车甚至开始在真实道路上测试之前，它必须经过数百万英里的模拟，以证明其安全性能，因为环境的高维度复杂且耗时。通过使用 AWS 云的几乎无限的计算和存储能力、对高级深度学习框架的支持以及专门构建的服务，你可以加快上市时间。例如，2017 年，美国交通公司 Lyft 推出了其自动驾驶部门。为了提高其系统的性能和安全性，它使用从其自动驾驶车队收集的 PB 级数据，每年执行数百万次模拟，这涉及到大量的计算能力。为了以更低的成本运行这些模拟，他们决定利用 AWS 云上未使用的计算能力，通过使用 Amazon EC2 Spot Instances，这不仅帮助他们增加了运行此类规模模拟的能力，还帮助他们提高了容量。

接下来，让我们了解供应链优化及其流程！

供应链优化

供应链是全球性的制造商、分销商、供应商、物流和电子商务零售商的网络，它们共同工作，以确保产品从工厂到客户门口的运输无延误且无损。通过使这些网络中的信息流动，你可以自动化决策，无需任何人为干预。需要考虑的关键属性包括实时库存预测、端到端可见性，以及以无与伦比的效率跟踪和追溯整个生产过程的能力。你的团队将不再需要处理与供应链决策相关的琐碎细节。通过自动化和机器学习，你可以解决产品流动中的瓶颈。例如，在流行病或自然灾害发生时，你可以迅速将货物转移到替代的运输路线，而不会影响其准时交付。

这里有一些使用机器学习来改进供应链流程的例子：

需求预测：您可以将时间序列与额外的相关数据相结合，例如假日、天气和人口事件，并使用如 DeepAR 之类的深度学习模型来获得更准确的结果。这将帮助您应对多变的需求并避免过度配置。
库存管理：您可以使用机器学习模型自动化库存管理，以确定库存水平并通过防止过剩库存来降低成本。此外，您还可以在供应链过程中使用机器学习模型进行异常检测，这可以帮助您优化库存管理，并更积极地解决潜在问题，例如，通过提前使用优化的路线将库存转移到正确的位置。
通过自动产品质量检查提高效率：通过使用计算机视觉模型，您可以在早期阶段更快地识别产品缺陷，并提高一致性和准确性，从而使客户能够及时收到高质量的产品。这减少了因产品质量问题而导致的客户退货和保险索赔，从而节省了成本和时间。

上述讨论的所有供应链优化组件都需要作为工作流程的一部分协同工作，因此需要低延迟和高吞吐量，以便及时将最优质量的产品送到客户家门口。使用云服务构建工作流程为您提供了更大的弹性、可伸缩性，并在优化的成本下运行。此外，通过本地专用服务，您可以消除繁重的工作，并缩短上市时间。

摘要

在本章中，我们首先了解了高性能计算的基本原理及其在处理大量数据以获得有意义的见解方面的重要性。然后，我们讨论了在本地运行高性能计算工作负载的限制，因为不同类型的高性能计算应用程序将具有不同的硬件和软件要求，这在家中采购既耗时又昂贵。此外，它将阻碍创新，因为开发人员和工程师受限于资源的可用性，而不是应用程序的要求。然后，我们讨论了在云上拥有高性能计算工作负载如何帮助克服这些限制，并促进全球团队的协作，打破创新的障碍，改进架构设计，并优化性能和成本。云基础设施使得高性能计算应用程序所需的专用硬件更加易于获取，这导致了该领域在众多行业中的创新。因此，在最后一节中，我们讨论了一些高性能计算中的新兴工作负载，例如在生命科学和医疗保健、供应链优化和自动驾驶汽车中，以及一些现实世界的例子。

在下一章中，我们将深入了解数据管理和传输，这是在云上运行高性能计算工作负载的第一步。

进一步阅读

您可以通过以下链接获取有关本章主题的更多信息：

第二章：数据管理和传输

在第一章《高性能计算基础》中，我们介绍了 HPC 应用的概念、为什么我们需要 HPC 以及它在不同行业的应用案例。在我们开始开发 HPC 应用之前，我们需要将所需数据迁移到云端。在本章中，我们将揭示管理和传输数据到云端的一些挑战以及缓解这些挑战的方法。我们将深入了解AWS 在线和离线数据传输服务，使用这些服务您可以安全地将数据传输到 AWS 云端，同时保持数据完整性和一致性。我们将涵盖不同的数据传输场景，并提供如何为每个场景选择正确服务的指导。

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

数据管理的重要性
将数据迁移到云端的挑战
如何安全地将大量数据传输到云端
AWS 在线数据传输服务
AWS 离线数据传输服务

这些主题将帮助您了解如何以最小的干扰、成本和时间将千兆字节（GB）、兆字节（TB）或拍字节（PB）的数据传输到云端。

让我们开始了解数据管理及其在 HPC 应用中的作用。

数据管理的重要性

数据管理是有效捕捉、存储和整理公司内不同应用程序创建的数据的过程，以确保在需要时数据准确、一致且可用。它包括制定管理您端到端数据生命周期的政策和程序。以下是一些特定于高性能计算（HPC）应用的数据生命周期元素，因此建立数据管理政策至关重要：

清洗和转换原始数据以执行详细的无误分析。
设计和构建数据管道以自动将数据从一个系统传输到另一个系统。
提取、转换和加载（ETL）数据到适当的数据存储系统，例如数据库、数据仓库、对象存储或文件系统，这些系统来自不同的数据源。
构建数据目录以存储元数据，使其更容易找到和跟踪数据血缘。
遵循您数据治理模型中概述的政策和程序。这也包括遵守数据被捕获和存储的国家联邦和地区当局的合规要求。例如，如果您是美国加利福尼亚州的一家医疗保健组织，您将需要遵守联邦和州的数据隐私法，包括健康保险可携带性和问责制法案（HIPAA）和加利福尼亚州的健康数据隐私法，即医疗信息保密法案（CMIA）。此外，您还需要遵守加利福尼亚消费者隐私法案（CCPA），该法案自 2020 年 1 月 1 日起生效，与医疗数据相关。如果您在欧洲，您将必须遵守欧盟的通用数据保护条例（GDPR）规定的数据指南。
在数据静止或传输过程中保护您的数据不受未经授权的访问。

现在我们已经了解了数据管理在 HPC 应用程序中的重要性，让我们看看将大量数据传输到云中的挑战。

将数据迁移到云中的挑战

为了开始在云上构建高性能计算（HPC）应用程序，您需要在云上拥有数据，并且还需要考虑您数据生命周期的各个方面，以便能够有效地管理数据。一种方法是编写用于传输数据的自定义代码，这将耗时且可能涉及以下挑战：

保留文件的权限和元数据。
确保数据传输不会影响其他现有应用程序的性能、可用性和可伸缩性，尤其是在在线数据传输（通过网络传输数据）的情况下。
在非工作时间安排数据传输，以确保不会阻碍其他应用程序。
在结构化数据方面，您可能需要考虑模式转换和数据库迁移。
维护数据完整性和验证传输。
监控数据传输的状态，能够查找先前传输的历史记录，并实施重试机制以确保传输成功。
确保没有重复项——一旦数据已传输，系统不应再次触发传输。
在传输过程中保护数据，这包括在传输中和静止时加密数据。
确保数据完整到达且未被损坏。您需要一个机制来检查到达目的地的数据与从源读取的数据匹配，以验证数据一致性。
最后但同样重要的是，您将不得不管理、版本控制和优化您的数据复制脚本。

AWS 提供的数据传输和迁移服务可以帮助你在不编写和管理代码的情况下安全地将数据传输到云端，帮助你克服上述挑战。为了根据你的业务需求选择正确的服务，你首先需要构建一个数据传输策略。我们将在本章的下一节讨论 AWS 数据传输服务。让我们首先了解在构建你的策略时需要考虑的项目。

简而言之，你的数据传输策略需要考虑以下因素，以便以最小的干扰、时间和成本来迁移数据：

你在开发 HPC 应用时需要哪种类型的数据——例如，结构化数据、非结构化数据（如图像和 PDF 文档），或者两者的组合？
对于非结构化数据，你目前使用哪种文件系统来存储文件？是在网络附加存储（NAS）还是存储区域网络（SAN）上？
目前购买了多少存储空间可用，根据你数据增长的速度，在计划购买更多存储之前，这些存储空间还能使用多久？
对于结构化数据，你使用哪种数据库？
你是否受限于数据库许可证？如果是，它们何时到期，许可证的成本是多少？
你需要将多少数据传输到云端？
使用这些数据的其他应用有哪些？
这些应用是否需要本地访问数据？如果数据迁移到云端，现有的应用会有任何性能影响吗？
你的网络带宽是多少？是否足够用于网络数据传输？
你需要多快地将数据迁移到云端？

根据这些问题的答案，你可以制定你的数据策略，并选择合适的 AWS 服务，帮助你轻松地迁移数据并减轻前面提到的挑战。为了更好地理解，让我们转到下一个主题，看看如何通过一个简单的示例来安全地将大量数据传输到云端。

如何安全地将大量数据传输到云端

为了理解这个主题，让我们从一个简单的例子开始，您想要构建和训练一个计算机视觉深度学习模型来检测您的制造生产线上的产品缺陷。您在每个生产线上安装了摄像头，每天可以捕获数百张图片。每张图片的大小可以达到 5 MB，您大约有 1 TB 的数据，目前存储在本地 NAS 文件系统中，您希望使用这些数据来训练您的机器学习模型。您大约有 1 Gbps 的网络带宽，需要在 2-4 周内开始训练模型。如果数据移动到云中，不会对其他应用程序产生影响，并且构建计算机视觉模型不需要结构化数据。让我们将以下信息重新组织成以下结构，这将成为您的数据策略文档的一部分：

目标: 将 1 TB 的图像数据传输到云中，其中文件大小可以达到 5 MB。需要自动化数据传输，每晚复制大约 10 GB 的图片到云中。此外，在复制数据到云中时需要保留元数据和文件权限。
时间表: 2-4 周
数据类型: 非结构化数据 – JPG 或 PNG 格式的图像文件
依赖项: 无
对现有应用程序的影响: 无
网络带宽: 1 Gbps
现有存储类型: 网络附加存储
数据传输目的: 使用多个 GPU 在计算机视觉深度学习模型上执行分布式训练
数据目的地: 亚马逊 S3，它是 AWS 上存储大量数据的最高效、最安全且最具成本效益的对象存储
敏感数据: 无，但数据不应可供公众访问
本地数据访问: 不需要

由于您有 5 TB 的数据，最大文件大小为 5 MB，需要安全地传输到亚马逊 S3，您可以使用 AWS DataSync 服务。这是一个 AWS 在线数据传输服务，通过使用虚拟专用云（VPC）端点迁移数据，以避免您的数据通过公开互联网。我们将在本章后面的部分详细讨论所有 AWS 数据传输服务。

下面的架构图直观地展示了数据传输的过程：

图 2.1 – 使用 AWS DataSync 和 VPC 端点进行数据传输

AWS DataSync 代理在您的本地存储（在这种情况下为 NAS）和 AWS 之间传输数据。您在本地网络中的虚拟机（VM）上部署代理，其中您的数据源位于。采用这种方法，您可以在使用网络文件系统（NFS）和服务器消息块（SMB）协议传输数据时最小化网络开销。

让我们在下一节更深入地了解 AWS DataSync。

AWS 在线数据传输服务

在线数据传输服务是 AWS 为通过互联网在本地系统与 AWS 云之间传输数据而构建的即用型解决方案。它们包括以下服务：

AWS DataSync
AWS Transfer Family
Amazon S3 转加速
Amazon Kinesis
AWS Snowcone

让我们详细了解一下这些服务，以了解我们可以使用相关服务的场景。

AWS DataSync

AWS DataSync 帮助您以快速、安全的方式克服从本地到 AWS 存储服务以及 AWS 存储服务之间传输数据的挑战。它还使您能够自动化或安排数据传输以优化网络带宽的使用，这可能与其他应用程序共享。您可以监控数据传输任务，添加数据完整性检查以确保数据传输成功，并验证数据在传输过程中未被损坏，同时保留文件权限和相关元数据。DataSync 提供与多个文件系统的集成，并允许您在以下资源之间传输数据：

本地文件服务器和对象存储：
- NFS 文件服务器
- SMB 文件服务器
- Hadoop 分布式文件系统 (HDFS)
- 自管理对象存储
AWS 存储服务：
- Snow Family Devices
- Amazon Simple Storage Service (Amazon S3) 存储桶
- Amazon Elastic File System (EFS)
- Amazon FSx for Windows File Server
- Amazon FSx for Lustre 文件系统

重要提示

我们将在 第四章，数据存储 中详细讨论 AWS 存储服务。

用例

如前所述，AWS DataSync 用于通过网络传输数据到云。现在让我们看看一些可以使用 DataSync 的具体用例：

混合云工作负载，其中数据由本地应用程序生成，需要将数据从本地移动到 AWS 云进行处理，以及从 AWS 云返回本地。这可能包括医疗保健、制造、生命科学中的高性能计算应用、金融服务中的大数据分析以及研究目的。
将数据快速通过网络迁移到 AWS 存储服务，如 Amazon S3，您需要确保数据安全且完整地到达。DataSync 默认启用了传输过程中的加密和数据完整性。您还可以选择启用额外的数据验证检查，以比较源数据和目标数据。
数据归档，您希望将不常访问的数据（冷数据）直接存入 AWS 云中持久和长期存储，例如 Amazon S3 Glacier 或 S3 Glacier Deep Archive。这有助于您释放本地存储容量并降低成本。
安排数据传输作业，在一天中的特定时间自动重复启动，以优化网络带宽使用，这可能与其他应用程序共享。例如，在生命科学领域，你可能希望每天上传由本地应用程序生成的基因组数据，以进行数据处理和训练机器学习模型。你可以使用 DataSync 安排数据传输任务，并根据需要监控它们。

AWS DataSync 的工作原理

我们将使用架构图来展示 DataSync 如何将本地自管理存储系统与 AWS 存储服务以及 AWS 存储资源之间的数据传输。

我们将从本地存储到 AWS 存储服务开始。

从本地到 AWS 存储服务的数据传输

图 2.2中的架构图描述了从本地到 AWS 存储资源的数据传输：

图 2.2 – 使用 AWS DataSync 从本地到 AWS 存储服务进行数据传输

DataSync 代理是一个虚拟机，它从本地存储读取数据并将数据写入。你可以使用 DataSync 控制台或 API 配置和激活你的代理。这个过程将你的代理与你的 AWS 账户关联起来。一旦代理被激活，你就可以从控制台或 API 创建数据传输任务以启动数据传输。DataSync 在传输过程中加密并执行数据完整性检查，以确保数据安全传输。你还可以启用额外的检查来验证复制到目标的数据与在源处读取的数据相同。此外，你还可以监控你的数据传输任务。DataSync 传输数据所需的时间取决于你的网络带宽、数据量以及网络流量。然而，单个数据传输任务能够利用 10-Gbps 的网络链路。

AWS 存储资源之间的数据传输

让我们深入了解一下，使用 AWS DataSync 在 AWS 存储资源之间进行数据传输。

图 2.3中的架构图描述了在同一 AWS 账户中使用 DataSync 在 AWS 存储资源之间进行的数据传输。相同的架构也适用于同一区域内的数据传输以及跨区域传输：

图 2.3 – 使用 AWS DataSync 在 AWS 存储资源之间进行数据传输

如架构图所示，DataSync 在同一个账户的 AWS 资源之间传输数据时不使用代理。然而，如果你想在不同 AWS 账户之间传输数据，那么你需要在 AWS 区域中设置并激活 DataSync Amazon EC2 代理。

总结来说，您可以使用 AWS DataSync 进行从本地到 AWS 存储服务的在线数据传输，以及 AWS 存储资源之间的数据传输。AWS DataSync 快速、安全且经济高效地传输数据，同时确保数据完整性和一致性，无需编写和管理数据复制脚本。

现在，让我们继续介绍另一个 AWS 数据传输服务——AWS Transfer Family，它用于扩展您定期进行的商业对商业文件传输到 Amazon S3 和 Amazon EFS。

AWS Transfer Family

文件传输协议，如文件传输协议（FTP）、安全文件传输协议（SFTP）和安全文件传输协议（FTPS），在包括金融服务、医疗保健、制造业和零售在内的不同行业的商业对商业数据交换工作流程中普遍使用。AWS Transfer Family 有助于扩展和迁移这些文件工作流程到 AWS 云。它使用 FTP、SFTP 和 FTPS 协议进行数据传输。它使您能够将文件传输到和从 Amazon EFS 和 Amazon S3。

用例

正如讨论的那样，AWS Transfer Family 使用 FTP、SFTP 和 FTPS 等协议，在商业对商业环境中进行数据交换工作流程。那么，让我们了解一些使用 AWS Transfer Family 将数据传输到和从 Amazon S3 和 Amazon EFS 的常见用例：

在您的组织内部或与第三方供应商之间安全地传输文件。一些行业，包括金融服务、生命科学和医疗保健，由于数据的敏感性和遵守如支付卡行业数据安全标准（PCI DSS）、HIPAA 或 GDPR 等法规的必要性，必须确保有安全的文件传输工作流程。
为了向您的客户分发基于订阅的内容。例如，BluTV 是土耳其一家著名的基于订阅的视频点播服务，它在全球范围内可用，并为土耳其语和阿拉伯语观众提供服务。之前，他们自行管理云上的 SFTP 设置，遇到了很多问题，例如管理用于将 S3 挂载到 Amazon EC2 的开源项目，以及需要额外资源时的扩展问题。在将他们的设置迁移到完全管理的 AWS Transfer Family SFTP 之后，他们不再需要监控文件传输，管理开源项目，或为未使用的资源付费。
在 AWS 上建立一个数据仓库（也称为数据湖），用于存储来自不同数据源和第三方（如供应商或合作伙伴）的结构化和非结构化数据。例如，FINRA，一个由美国政府授权的非营利组织，负责监管美国股票经纪人，它在 Amazon S3 上有一个数据湖作为其数据的主要来源。FINRA 使用 AWS Transfer Family 的 SFTP 服务来减轻运营负担，同时保持与现有身份验证系统连接，以便在将 SFTP 服务迁移到 AWS 的过程中避免任何中断。

既然我们已经讨论了一些 AWS Transfer Family 的用例，让我们看看它是如何工作的。

AWS Transfer Family 的工作原理

图 2.4 中的架构展示了如何使用 AWS Transfer Family 将文件从本地文件服务器传输到 Amazon S3 或 Amazon EFS，然后可以用于下游文件处理工作流程，例如内容分发、机器学习和数据分析：

图 2.4 – 使用 AWS Transfer Family 的文件传输工作流程

您可以配置任何标准文件传输协议客户端，例如 WinSCP、FileZilla 或 OpenSSH，使用 AWS Transfer Family 首先传输到 Amazon S3 或 EFS。它将首先根据您配置的身份提供者类型对用户进行身份验证，一旦用户通过身份验证，它将启动文件传输。

到目前为止，我们已经看到了如何使用 AWS DataSync 和 AWS Transfer Family 通过网络传输数据，并了解了它们的用例以及这些服务如何以经济高效的方式在安全传输数据的同时减少运营负担。现在让我们看看如何使用 Amazon S3 传输加速来加速数据传输到 S3。

Amazon S3 传输加速

Amazon S3 传输加速（S3TA）是 Amazon S3 存储桶中的一个功能，允许您在长距离上加速数据传输到 S3 存储桶，无论互联网流量如何，无需任何特殊客户端或专有网络协议。您可以使用传输加速功能将到和从 Amazon S3 的传输速度提高 50-500%。

一些用例包括以下内容：

从分布式位置到基于 Amazon S3 构建的数据湖（集中式数据存储库）的大文件，如实验室图像或媒体，进行时间敏感的传输。
具有文件上传或下载功能的 Web 或移动应用程序，其中用户地理位置分散，且距离目标 S3 存储桶较远。S3TA 可以加速这种远程文件传输，并帮助您提供更好的用户体验。

它使用 Amazon CloudFront 的全球分布式边缘位置、AWS 骨干网络和网络协议优化来路由流量，这加快了传输速度，减少了互联网流量的可变性，并有助于在逻辑上缩短远程应用程序到 S3 的距离。

重要提示

使用 Amazon S3 传输加速会有额外费用。

我们已经讨论了使用在线数据传输服务，如 AWS DataSync、AWS Transfer Family 和 S3TA，通过网络将数据从本地存储传输到 AWS 存储资源。可能存在一些场景，您希望将实时流数据传输到 AWS 云，例如，来自物联网传感器的遥测数据、用于在线流媒体应用的视频等。为此，我们将更深入地介绍 Amazon Kinesis，这是一个由 AWS 构建的完全管理的流服务。

Amazon Kinesis

Amazon Kinesis是一个完全管理的服务，用于在任何规模上实时收集、处理和分析流数据。流数据可以包括应用程序日志、音频、视频、网站点击流或物联网传感器数据，用于深度学习、机器学习、分析和其他应用。它允许您在数据到达时实时执行数据分析，而不是等待所有数据传输完成后再进行处理。

Amazon Kinesis 包括以下服务：

Kinesis 视频流：当您需要从连接的设备安全地将视频流传输到 AWS 进行应用，如处理、分析或机器学习以实时驱动洞察时使用。它具有内置的自动扩展机制，用于提供从数百万个设备接收视频流所需的基础设施。它自动加密静态数据和传输中的数据。它使用 Amazon S3 作为其底层存储，允许您可靠地存储和检索数据。这有助于您通过将其与其他完全管理的 AWS 服务集成或使用 AWS 上流行的开源机器学习框架来开发实时计算机视觉应用。图 2.5展示了如何使用 Kinesis 视频流收集、处理和存储来自媒体设备的视频流，用于机器学习、分析和回放，并与其他媒体应用集成：

图 2.5 – 捕获、处理和存储用于机器学习、分析和回放的视频流

Kinesis Data Streams：这是一个全托管的无服务器服务，用于以经济高效的方式在任何规模上安全地传输数据。您可以通过调整您的容量每秒传输数吉字节的数据，或者以按需模式使用它来自动扩展和配置底层基础设施，以满足应用程序所需的容量。它具有与其他 AWS 服务内置的集成，并且您只需为使用的部分付费。图 2.6 展示了如何使用 Kinesis Data Streams 从不同的来源摄取、处理和存储生成的流数据，以实时获得洞察：

图 2.6 – 将来自不同来源的数据捕获到 Amazon Kinesis Data Streams

Kinesis Data Firehose：用于将数据安全地流式传输到基于 Amazon S3 构建的数据湖或数据仓库，如 Amazon Redshift，以进行进一步处理或分析，无需构建数据处理管道。让我们看看使用 Kinesis Data Firehose 的一些好处：
- 它使您能够通过安全地提取、转换和加载流数据来轻松创建交付流，无需管理底层基础设施。
- 它具有内置的自扩展功能，可以提供流应用程序所需的资源，无需任何持续管理。
- 它使您能够使用内置或自定义转换来转换原始流数据。它支持将数据转换为不同的格式，如 Apache Parquet，并且可以动态分区数据，而无需构建任何自定义处理逻辑。
- 您可以使用 Kinesis Firehose 中的机器学习模型来增强您的数据流，在数据传输到目的地时进行分析和推理。它通过实时监控和创建警报来提供增强的网络安全性，当使用 安全信息和事件管理（SIEM）工具检测到潜在威胁时。
- 您可以连接到 30 多个 AWS 服务和流式传输目的地，这些服务与 Kinesis Data Firehose 完全集成。

图 2.7 展示了如何使用 Amazon Kinesis Data Firehose 进行 ETL 用例，而无需编写长行代码或管理大规模的自身基础设施：

图 2.7 – 使用 Amazon Kinesis Data Firehose 进行 ETL

Kinesis Data Analytics：此功能用于实时处理数据流，使用无服务器和完全管理的Apache Flink或 SQL，从数据源如 Amazon S3、Amazon Kinesis Data Streams 和Amazon Managed Apache Kafka（MSK）（用于摄取和处理流数据）。它还可以用于从基于过去数据趋势的长时间运行的有状态计算中触发实时操作，如异常检测。它具有内置的自适应扩展机制，以匹配您的输入数据流的体积和吞吐量。您只需为使用的部分付费；与之相关的没有最低费用或设置成本。它可以帮助您实时了解数据，例如，通过为您的游戏应用程序构建排行榜，分析传感器数据，日志分析，Web 点击流分析，构建流式 ETL 应用程序，或持续生成指标以了解数据趋势。

图 2.8展示了典型的 Kinesis Data Analytics 应用程序的工作方式。它有三个主要组件：

一个用于执行实时分析的数据流输入源
Amazon Kinesis Data Analytics Studio Notebook，用于使用 SQL 查询和 Python 或 Scala 程序分析流数据
最后，它将处理后的结果存储在目标服务或应用程序上，例如 Amazon Redshift 或 Amazon DynamoDB（NoSQL 数据库）和 Amazon Kinesis Data Streams：

图 2.8 – 使用 Amazon Kinesis Data Analytics 实时处理流数据

在本节中，我们讨论了如何使用 Amazon Kinesis 将流数据传输和传输到 AWS 存储。有一些用例，如边缘计算和边缘存储，您可以使用AWS Snowcone，这是一种用于边缘计算、存储和数据传输的便携、坚固且安全的设备。接下来，让我们看看如何从 AWS Snowcone 在线传输数据到 AWS。

AWS Snowcone

AWS Snowcone 是一种小型、坚固且便携的设备，用于运行边缘计算工作负载、边缘存储和数据传输。该设备重约 4.5 磅（2.1 千克），具有多层安全和加密。它有 8 TB 的存储空间，而 AWS Snowcone 的固态硬盘（SSD）版本提供 14 TB。Snowcone 的一些常见用例如下：

医疗物联网，用于从紧急医疗车辆向医院传输关键和敏感数据，以加快数据处理速度并减少响应时间，更好地服务患者。然后，您可以安全地将数据传输到 AWS 云。
工业物联网，用于捕获传感器或机器数据，因为它可以承受工厂地板上发现的极端温度、振动和湿度，而传统的边缘设备可能无法工作。
从自动驾驶汽车和无人机捕获和存储传感器数据。

您可以使用 AWS DataSync，如 AWS DataSync 部分所述，通过网络从各种 AWS Snowcone 设备传输千兆字节的数据。

当您需要通过网络将高达千兆字节的数据传输到 AWS 时，AWS 在线数据传输服务非常有用。数据传输所需的时间取决于您的可用网络带宽和互联网流量。当您需要从偏远地点传输数据，或者当您的网络带宽被现有应用程序大量使用时，您就需要一个替代机制来离线传输数据。让我们在下一节中讨论 AWS 离线数据传输服务。

AWS 离线数据传输服务

为了以安全且经济高效的方式通过离线方法传输高达千兆字节的数据，您可以使用 AWS Snow Family 设备。有时，您的应用程序可能需要在边缘进行增强性能，您希望在数据源附近处理和分析数据，以便提供实时有意义的见解。这意味着您需要 AWS 云之外的 AWS 管理的硬件和软件服务。AWS Snow Family 可以帮助您在数据中心外以及网络连接有限的偏远地点运行操作。

它包括以下设备：

AWS Snowcone：在 AWS 在线数据传输服务 部分中，我们介绍了 Snowcone 的使用方法，并讨论了如何使用 AWS DataSync 在边缘收集和存储数据，然后将其传输到 AWS 云。在网络带宽有限的情况下，您还可以通过将设备发送到 AWS 设施来进行离线数据传输。它包括一个电子墨水运输标签，这也有助于跟踪。
AWS Snowball：此设备用于数据迁移和边缘计算。它提供两种选择：
- Snowball Edge 计算优化版拥有 42 TB 的块存储或与 Amazon S3 兼容的存储，配备 52 个 vCPU 和可选的 GPU，用于边缘计算用例，如机器学习、视频分析和在具有间歇性网络连接的环境中的大数据处理，例如工业和交通用例，或在国防或军事应用中发现的极端偏远地区。
- Snowball Edge 存储优化版拥有 80 TB 的可用块存储或与 Amazon S3 兼容的对象存储，配备 40 个 vCPU 以在边缘进行计算。它主要用于本地存储或大规模离线数据传输到 AWS 云。
AWS Snowmobile 用于在 45 英尺长的运输集装箱中迁移高达 100 PB 的数据，该集装箱具有防篡改、防水和多层逻辑和物理安全性的温度控制功能。它非常适合需要传输埃字节或数百个佩字节数据的使用场景，这可能是由于数据中心关闭而发生的。您需要从 AWS Snow Family 控制台订购它，并且它作为网络附加的数据存储到达您的现场，连接到您的本地网络以执行高速数据传输。一旦数据被移动到设备上，它将被运回 AWS 设施，然后数据被上传到指定的 Amazon S3 存储桶。为确保数据在传输过程中的安全性以及数据成功交付到 AWS 设施，它配备了灭火、加密、专用安全人员、GPS 跟踪、警报监控、24/7 视频监控和护送安全车辆。

既然我们已经了解了 AWS 提供的各种离线数据传输选项，让我们了解订购设备的过程。

从 AWS Snow Family 订购设备的流程

要订购 AWS Snowmobile，您需要联系 AWS 销售支持。对于 Snowcone 或 Snowball 设备，您可以按照以下步骤操作：

图 2.9 – AWS Snow Family 控制台

点击阅读订购 AWS Snow Family 设备的橙色按钮，这将打开另一个屏幕，如图 图 2.10 所示。这将为您提供创建订购设备工作的步骤：

图 2.10 – AWS Snow Family – 创建新工作

点击下一步进入步骤 2，开始导入到 S3 作业，如图 图 2.11 所示：

图 2.11 – 开始导入到 S3 作业

仔细阅读说明，勾选确认框，然后点击下一步进入步骤 3，选择您的运输偏好，如图 图 2.12 所示：

图 2.12 – 选择您的运输偏好

填写您的运输详情，选择您首选的运输速度，然后点击下一步进入步骤 4，选择您的工作详情，如图 图 2.13 所示。请确保输入有效的地址，因为如果您的地址不正确，将会收到错误信息：

图 2.13 – 选择您的工作详情

在此屏幕上，您可以选择您的 Snow 设备、电源、Snowcone 的无线选项、S3 存储桶、使用 EC2 实例进行计算，以及安装经过 AWS IoT Greengrass 验证的 AMI 的选项。

请注意，S3 存储桶将显示为您的设备上的目录，并且这些目录中的数据将被传输回 S3。如果您已选择 AWS IoT Greengrass AMI 在设备上运行 IoT 工作负载，您还需要选择远程设备管理选项，以便使用 OpsHub 或 Snowball Client 远程打开和管理设备。

重要提示

在步骤 4中提到的所有选项在图 2.13 – 选择您的作业详情中均未显示，但将在您的控制台屏幕上显示。

在填写完作业详情后，点击下一步按钮进入步骤 5，选择您的安全首选项，如图 2.14 所示：

图 2.14 – 选择您的安全首选项

在此屏幕上选择您作业的权限和加密设置，这将帮助您在数据传输过程中保护您的数据，然后点击下一步进入步骤 6，选择您的通知首选项，如图 2.15 所示：

图 2.15 – 选择您的通知首选项

要接收关于工作状态变化的电子邮件通知，您可以选择现有的简单通知服务（SNS）主题或创建一个新的 SNS 主题。点击下一步进入步骤 7，审查并创建您的作业，如图 2.16 所示：

图 2.16 – 审查并创建您的作业

您可以审查从步骤 1到步骤 7输入的所有详细信息，然后点击创建作业按钮。
作业创建完成后，将带您进入作业屏幕，如图 2.17 所示，在那里您可以查看作业的详细信息，包括状态：

图 2.17 – Snow Family 作业

重要提示

在操作下拉菜单中，您还有取消作业、编辑作业名称和克隆作业的选项。

在本节中，我们了解了 AWS Snow Family 设备，这些设备可以根据我们的应用需求、网络连接、可用带宽和数据源的位置离线传输数据。我们还讨论了如何使用这些设备不仅用于数据传输，还用于边缘计算。

关于这个话题最常问的问题之一是，我们如何根据网络速度和可用带宽来计算将数据移动到云中的时间？为此，AWS 提供了一个基于最佳情况的简单公式，如下所示：

例如，如果我们有一个 1.544 Mbps 的网络连接，并且我们想要将 1 TB 的数据移动到和从 AWS 云中，那么理论上在 80%的网络利用率下通过您的网络连接传输所需的最短时间是 82 天。

重要提示

请注意，此公式仅提供高级估计；实际所需时间可能会根据网络流量和可用带宽的变化而有所不同。

现在让我们简要地回顾一下本章中我们讨论的所有主题。

摘要

在本章中，我们讨论了数据管理的各个方面，包括数据治理以及符合数据所在国家联邦和地区当局的法律要求。我们还讨论了为了在云上构建高性能计算（HPC）应用，我们需要在云上拥有数据，并探讨了将此数据转移到云上的挑战。为了减轻这些挑战，我们可以使用托管的 AWS 数据传输服务，并且为了选择适用于您应用程序的服务，我们讨论了构建数据策略的要素。

然后，我们通过一个示例说明了如何将 PB 级数据转移到云上，以便理解数据传输策略中涉及的概念。最后，我们深入探讨了基于您的网络带宽、连接性、应用程序类型、数据传输速度和数据源位置，针对在线和离线数据传输的各种 AWS 数据传输服务。现在，我们了解了将数据传输到云上的机制、涉及的挑战以及如何减轻这些挑战，在下一章中，我们将专注于了解 AWS 为运行 HPC 应用程序提供的各种计算选项，以及如何根据应用程序需求进行优化。

进一步阅读

以下是本章的一些额外资源：

迁移 PB 级数据: aws.amazon.com/getting-started/projects/migrate-petabyte-scale-data/
AWS 上 HPC 简介: d1.awsstatic.com/whitepapers/Intro_to_HPC_on_AWS.pdf
数据管理 versus 数据治理: www.tableau.com/learn/articles/data-management-vs-data-governance
什么是 DataSync？: docs.aws.amazon.com/datasync/latest/userguide/what-is-datasync.html
S3 转速加速: aws.amazon.com/s3/transfer-acceleration/
AWS 转移家族客户: aws.amazon.com/aws-transfer-family/customers/
Kinesis 数据流: aws.amazon.com/kinesis/data-streams/
Kinesis 视频流: aws.amazon.com/kinesis/video-streams/
Kinesis 数据分析: aws.amazon.com/kinesis/data-analytics/
AWS Snowcone: aws.amazon.com/snowcone
AWS Snow Family: aws.amazon.com/snow/
云数据迁移: aws.amazon.com/cloud-data-migration/

第三章：计算和网络

许多大型和小型组织在 AWS 上运行工作负载，使用 AWS 计算服务。在这里，AWS 计算指的是 AWS 上的一组服务，帮助您构建和部署自己的解决方案和服务；这可以包括网站、数据分析引擎、机器学习（ML）、高性能计算（HPC）等多种多样的工作负载。作为最早发布的服务之一，Amazon Elastic Compute Cloud（EC2）有时与术语计算同义使用，并为您的各种工作负载提供广泛的实例类型、处理器、内存和存储配置。

除了 EC2 之外，适合某些特定类型工作负载的计算服务还包括 Amazon 弹性容器服务（ECS）、弹性 Kubernetes 服务（EKS）、Batch、Lambda、Wavelength 和 Outposts。AWS 上的网络指的是基础网络服务，包括 Amazon 虚拟私有云（VPC）、AWS Transit Gateway 和 AWS PrivateLink。这些服务以及各种计算服务，使您能够在全球范围内构建最安全、性能最高的网络化系统解决方案。AWS 计算和网络概念是两个广泛的主题，对于理解以下章节中将要讨论的许多概念非常重要。

计算和网络也是 HPC 的两个重要支柱，与上一章讨论的数据管理一样。HPC 的每个应用通常都针对高水平的分布式计算进行优化，这依赖于网络。

在本章中，您将了解 AWS 提供的不同计算和网络服务，这些服务如何用于不同类型的计算工作负载，以及最后，AWS 上 HPC 类型工作负载的最佳实践，这超出了 AWS Well-Architected Framework 的范围。

具体来说，在本章中，我们将涵盖以下主题：

介绍 AWS 计算生态系统
AWS 上的网络
选择适合 HPC 工作负载的正确计算资源
HPC 工作负载的最佳实践

介绍 AWS 计算生态系统

计算是您将在本书内外阅读的每个 HPC 应用的基础。在 AWS 和其他云服务中，计算指的是一组提供执行计算或某些业务逻辑基本构建块的服务。这可以包括从基本数据计算到机器学习（ML）的各种应用。

在 AWS 上衡量计算能力的基准单位（无论我们讨论的是哪种服务）如下：

处理单元 - 这可以衡量为中央处理单元（CPUs）、虚拟中央处理单元（vCPUs）或图形处理单元（GPUs）的数量
内存 - 这是应用程序请求或分配的总内存，以字节为单位

典型的 HPC 应用访问多个实例，因此可以利用池化的计算和内存资源来处理更大的工作负载。

为客户提供计算资源以在 AWS 上构建应用程序的基础服务称为 Amazon EC2。Amazon EC2 为客户提供约 500 种实例类型的选择（根据撰写本书时的公开文档）。然后，客户可以为他们的业务应用程序定制合适的实例类型组合。

Amazon EC2 提供五种类型的实例：

通用型实例
计算优化实例
加速计算实例
内存优化实例
存储优化实例

列出的每种实例类型实际上都是一个实例系列，如图 3.1 所示：

图 3.1 – Amazon EC2 实例类型

在下一节中，我们将突出介绍这些实例类型的一些重要事实。

通用型实例

通用型实例可用于各种工作负载。它们具有计算、内存和存储之间的平衡，适合大多数典型的 AWS 客户应用程序。在 AWS 上，有几种类型的通用型实例：

T 型实例：T 型实例，例如 T2 实例，是可爆增实例，为低计算和内存占用工作负载提供基本计算能力。以下图示展示了适合 T 型实例的典型工作负载可能的样子——大部分时间都低于基线 CPU 利用率，偶尔需要爆增超过这个基线。对于非可爆增实例，应用程序所有者需要为爆增 CPU 级别进行过度配置，因此即使利用率很低，也需要支付更多费用。对于可爆增 T 型实例，当利用率低于基线（基线以下的白色区域）时，会累积信用，这些信用可以在应用程序遇到更高负载时使用；请参见以下图中灰色填充的区域：

图 3.2 – AWS 上可爆增 T 型实例的 CPU 利用率与时间对比

M 型实例：M 型实例（如 M4、M5 和 M6）可用于需要计算、内存和网络平衡的各种工作负载，包括但不限于 Web 和应用程序服务器，以及小型到中型数据库工作负载。M5 和 M6 实例的特殊版本适用于某些工作负载。例如，M5zn 实例类型可用于需要极高单线程性能的应用程序，如高性能计算、模拟和游戏。
A 型实例：A1 实例用于运行基于高级精简指令集机器或ARM的应用程序，例如由 AWS Graviton ARM 处理器提供动力的微服务和 Web 服务器。
Mac 型实例：Mac1 实例由苹果的 Mac Mini 电脑供电，提供非常高的网络和存储带宽。它们通常用于构建和测试适用于 iPhone、Mac 等设备的苹果应用。

在下一节中，我们将讨论 AWS 上的计算优化实例。

计算优化实例

本书将描述的许多 HPC 应用都利用了 AWS 上高性能、计算优化的实例类型。

存在几种类型的计算优化实例：

C5 实例：C5 和 C5n 实例提供低成本、高性能的计算，适用于典型的 HPC、游戏、批处理和建模。C5 实例使用英特尔 Xeon 处理器（第一代和第二代），在单个核心上提供超过 3.4GHz 的时钟速度。C5a 实例还提供 AMD 处理器，以更低成本实现高性能。C5n 实例非常适合 HPC 应用，因为它们支持弹性布线适配器（EFA）并可实现高达每秒 100 吉比特的网络吞吐量。有关 EFA 的更多信息，请访问aws.amazon.com/hpc/efa/。
C6 实例：C6g 实例是基于 AWS Graviton 处理器的 ARM 架构实例。它们非常适合运行高性能计算（HPC）工作负载、广告服务和游戏服务器。C6g 实例提供基于本地非易失性内存表达式（NVMe）的高性能、低延迟 SSD 存储，网络速度可达每秒 100 吉比特，并支持 EFA。另一方面，C6i 类实例基于英特尔 Xeon 处理器，每个实例可提供高达 128 个 vCPU，适用于典型的 HPC 工作负载。
HPC 实例：HPC6a 实例类型由第三代 AMD 处理器提供动力，以实现典型 HPC 工作负载的成本性能比。这些实例类型还提供 96 个 CPU 核心和 384GB 的 RAM，适用于内存密集型应用。HPC6a 实例还支持基于 EFA 的网络，吞吐量可达每秒 100 吉比特。

在下一节中，我们将讨论 AWS 上的加速计算实例。

加速计算实例

加速计算实例使用如 GPU 这样的协处理器来加速工作负载的性能，例如用于机器学习、深度学习和图形处理的浮点数计算。

加速计算实例使用以下基于硬件的计算加速器：

GPU
现场可编程门阵列（FPGA）
AWS Inferentia

GPU

GPU 最初用于 3D 图形，但现在被用作各种应用的通用协处理器，如 HPC 和深度学习。HPC 应用计算和带宽密集。AWS 上提供了多种类型的 NVIDIA GPU，详细信息可在以下链接找到：aws.amazon.com/nvidia/。

让我们深入了解 GPU 如何帮助进行计算密集型计算的基础。想象一下将一个数字列表添加到另一个相同大小的数字列表中。直观上看，这就像以下图示：

图 2.3 – 添加两个数组

将这些添加到数组中的简单方法是遍历每个数组的所有元素，并将顶部和底部数组中相应的数字相加。这对于小型数组来说可能没问题，但对于数百万个元素的数组呢？要在 GPU 上完成这项工作，我们首先为这两个非常长的数组分配内存，然后使用线程来并行化这些计算。使用单个 GPU 上的单个线程添加这些数组与我们的早期简单方法相同。使用多个线程（例如 256 个）可以通过将部分工作分配给每个线程来帮助并行化此操作。例如，前几个元素（在这种情况下是总大小除以 256）将由第一个线程完成，依此类推。这通过让每个线程专注于较小的工作部分，并并行执行这些分割的加法操作来加快操作速度；请参见以下图中的阴影区域：

图 3.4 – 多个线程处理计算的一部分

今天的 GPU 架构允许更高的并行级别——多个处理线程组成一个块，通常 GPU 中有多个块。每个块可以在 流式多处理器 (SM) 中并发运行，并处理相同的一组计算或内核。直观上看，这就像以下图示：

图 3.5 – GPU 中的多个块

为了让您了解在 AWS 上可以访问的内容，考虑一下 P4d.24xlarge 实例。这个实例有八个 GPU，如下面的图所示，每个 GPU 都是一个包含 108 个 SM 的 NVIDIA A100，每个 SM 能够并行运行 2,048 个线程：

图 3.6 – 单个实例中的多个 GPU

在 AWS 上，P4d 实例可用于部署超级计算机或具有超过 4,000 个 A100 GPU 的 EC2 Ultracluster，以及 Amazon FSx for Lustre 上的可扩展、共享的高吞吐量存储（[aws.amazon.com/fsx/lustre/](https://aws.amazon.com/fsx/lustre/））。应用程序和包开发者使用 NVIDIA CUDA 库构建用于 HPC 和深度学习的海量并行应用程序。例如，PyTorch，一个流行的 ML 库，使用 NVIDIA 的 CUDA GPU 编程库进行大规模模型的训练。另一个例子是 Ansys Fluent，一个流行的 计算流体动力学 (CFD) 模拟软件，它使用 GPU 内核来加速流体流动计算。

在 AWS 上，有几个系列的 GPU 实例：

G 系列实例：AWS 上的 G2、G3、G4 和 G5 类型实例提供经济高效的 GPU 资源访问。这里提到的每种 G 类型实例都配备了不同的 NVIDIA GPU – 例如，最新的 G5 实例配备了 NVIDIA A10G GPU，G5g 实例配备了 NVIDIA T4G GPU，而 G4Dn 则配备了 NVIDIA Tesla GPU。AMD 基础的 GPU 也可用 – 例如，G4ad 实例使用 AMD Radeon Pro V520 GPU。
P 系列实例：这些实例为单实例和分布式应用提供了高性能 GPU。P2 实例提供对 NVIDIA K80 GPU 的访问，P3 实例配备 NVIDIA Tesla V100 GPU，而 P4d 实例则配备 A10 GPU。
VT1 实例：这些实例提供访问 Xilinx Alveo U30 媒体加速卡，主要用于视频转码应用。有关 VT1 实例的更多信息，请参阅此处：aws.amazon.com/ec2/instance-types/vt1/。
AWS Inferentia：这些实例专门设计用于提供经济高效且低延迟的机器学习推理能力，并由 AWS 定制制造。客户可以使用这些 Inf1 实例遵循的典型工作流程是使用 TensorFlow 等机器学习框架在另一个 EC2 实例或 SageMaker 训练实例上训练模型，然后使用 Amazon SageMaker 的编译功能 Neo 将模型编译用于与 Inf1 实例一起使用。您还可以使用 AWS Neuron SDK 对深度学习模型进行性能分析并将其部署到 Inf1 实例。

FPGA 实例

Amazon EC2 F1 实例允许您在云上轻松开发并部署硬件加速应用。示例应用包括（但不限于）大数据分析、基因组学和与模拟相关的应用。开发者可以使用高级 C/C++ 代码来编写他们的应用，将 FPGA 注册为 Amazon FPGA Image（AFI），并将应用部署到 F1 实例。有关 F1 实例的更多信息，请参阅本章末尾参考部分中的链接。

在下一节中，我们将讨论 AWS 上的内存优化计算实例。

内存优化实例

AWS 上的内存优化实例适用于运行需要将极大量数据存储在内存中的应用。典型的此类应用包括内存数据库、高性能计算应用、模拟和 电子设计自动化（EDA）应用。在 AWS 上，有几种类型的内存优化实例：

R5 型实例：R5 型实例系列（如 R5、R5a、R5b 和 R5n 实例类型）是关系数据库（如 MySQL、MongoDB 和 Cassandra）、内存数据库（如 Redis 和 Memcached）以及商业智能应用程序（如 SAP HANA 和 HPC 应用程序）的理想选择。R5 金属实例类型还提供了对基于物理服务器的处理器和内存的直接访问。
R6 型实例：R6 型实例（如 R6g 和 R6gd）基于 ARM 架构的 AWS Gravitron2 处理器，与 R5 实例相比，可以提供更好的价格性能比。应用开发者可以使用这些实例类型开发或支持需要高内存占用脚本的 ARM 架构应用程序。
U 型实例：这些实例是极高性能的内存实例 – 每个实例可以提供从 6 到 24 TB 的内存。它们通常用于运行大型内存应用程序，如数据库和 SAP HANA，并由 Intel Xeon Platinum 8176M 处理器提供动力。
X 型实例：X 型实例（如 X1、X1e 和 X1gd 实例类型）是为云中的大规模内存应用程序设计的。每个 X1 实例由四个 Intel Xeon E8880 处理器提供动力，最高可达 128 个 vCPU，以及最高 1,952 GB 的内存。X1 实例因其提供的内存量与其它实例系列相比具有较低的价格性能比而受到开发者的青睐。X1e 实例提供更高的内存（高达 3,904 GB）并支持生产级 SAP 工作负载。X1 和 X1e 实例类型在使用弹性网络适配器（ENA）时提供高达每秒 25 千兆位的网络带宽。最后，X1gd 和 X2gd 是基于 AWS Graviton2 的 ARM 实例，与基于 x86 的 X1 实例相比，提供更好的价格性能。
Z 型实例：Z1d 实例类型既提供高性能又提供高内存，适用于典型的数据分析、金融服务和 HPC 应用程序。Z1d 实例非常适合需要非常高的单线程性能且对高内存有额外依赖的应用程序。Z1d 实例有七种不同的大小，最高可达 48 个 vCPU 和 384 GB 的 RAM，因此客户可以根据其应用程序选择合适的实例大小。

存储优化实例

存储优化实例非常适合需要频繁、顺序地从本地存储进行读取和写入的应用程序，通过提供非常高的每秒I/O 操作数（IOPS）。在 AWS 上存在几个存储优化实例：

D 型实例：D2、D3 和 D3en 等实例提供高性能本地存储，可用于 MapReduce 风格的操作（使用 Hadoop 或 Spark）、日志处理以及其他大数据工作负载，这些工作负载不需要将所有数据都保留在内存中，但需要非常快速、按需访问这些数据。
H 型实例：H1 实例通常用于 MapReduce 应用、分布式文件存储和其他数据密集型应用。
I 型实例：I 型实例，如 I3 和 I3en，非常适合关系型和非关系型数据库、内存缓存和其他大数据应用。I3 实例是基于 NVMe 固态硬盘（SSD）的实例，可以提供高达 25 GB 的网络带宽和每秒 14 千兆位的专用带宽，用于连接的弹性块存储（EBS）卷。Im4gn 和 Is4gen 类型的实例可用于关系型和非NoSQL数据库、流式应用和分布式文件应用。

亚马逊机器镜像（AMIs）

现在我们已经讨论了您可以在 AWS 上为应用程序选择的不同实例类型，我们可以继续讨论亚马逊机器镜像（AMIs）的主题。AMIs 包含启动实例所需的所有信息。这包括以下内容：

描述要使用的操作系统、架构（32 位或 64 位）、要包含的应用程序以及应用程序服务器，以及启动前要附加的 EBS 快照
在启动时定义要附加到实例上的卷的块设备映射
启动权限，控制哪些 AWS 账户可以使用此 AMIs

您可以创建自己的 AMIs，或者在 AWS 市场上购买、共享或出售您的 AMIs。AWS 维护基于 Amazon Linux 的稳定且安全的 AMIs，这些 AMIs 定期更新和维护，并包括几个 AWS 工具和包。此外，这些 AMIs 免费提供给 AWS 客户。

AWS 上的容器

在上一节中，我们讨论了 AWS 上的 AMIs，可以帮助在多个实例和实例类型之间隔离和复制应用程序。容器可以用来进一步隔离并在实例上启动一个或多个应用程序。最受欢迎的容器类型被称为 Docker。Docker是一个用于开发、运输和运行应用程序的开源平台。Docker 提供了在称为容器的松散隔离环境中打包和运行应用程序的能力。Docker 容器是可运行镜像的定义，这些镜像可以在您的计算机上本地运行，在虚拟机上运行，或在云中运行。只要在主机系统上运行 Docker，Docker 容器就可以在任何主机操作系统上运行，因此它们非常便携。

一个 Docker 容器包含了运行其中定义的应用程序所需的一切——这包括配置信息、目录结构、软件依赖、二进制文件和包。这可能听起来很复杂，但实际上定义一个 Docker 镜像非常简单；这是在 Dockerfile 中完成的，其外观可能类似于以下内容：

FROM python:3.7-alpine
COPY . /app
WORKDIR /app
RUN pip install -r requirements.txt
CMD ["gunicorn", "-w 4", "main:app"]

前面的文件名为 Dockerfile，它定义了运行一个使用流行的 Gunicorn 包的 Python 示例应用程序的 Docker 镜像（请参阅文件中的最后一行）。在我们能够运行应用程序之前，我们告诉 Docker 使用 Python-3.7 基础镜像（FROM python:3.7-alpine），将所有必需的文件从主机系统复制到名为 app 的文件夹中，并安装该应用程序成功运行所需的要求或依赖项（RUN pip install -r requirements.txt）。现在你可以在云上大规模部署之前在本地测试这个应用程序。

在 AWS 上，你可以在你选择的 EC2 实例上运行容器，或利用许多可用的容器服务：

当你需要以服务器级控制运行容器时，你可以直接在 EC2 上运行你定义的镜像。此外，在 EC2 Spot 实例上运行这些容器可以节省高达 90% 的成本，与按需实例相比。有关 Spot 实例的更多信息，请参阅aws.amazon.com/ec2/spot/。
在光谱的另一端，你可以使用像 AWS Fargate 这样的服务来运行容器，而不需要管理服务器。Fargate 去除了维护服务器级软件的所有运营开销，这样你就可以专注于手头的应用程序。使用 Fargate，你只需为所使用的资源付费——例如，如果你创建了一个从 Amazon S3 下载数据文件、处理这些文件并将输出文件写回 S3 的应用程序，并且这个过程需要 30 分钟来完成，你只需为完成任务所使用的时时间和资源（vCPUs）付费。
当你拥有多个复杂、基于容器的应用程序时，管理和编排这些应用程序是一项重要任务。在 AWS 上，可以使用像 Amazon 弹性容器注册库（ECR）、Amazon 弹性容器服务（ECS）和 Amazon 弹性 Kubernetes 服务（EKS）这样的服务来实现容器管理和编排。关于这些服务的详细讨论超出了本书的范围，但如果你感兴趣，可以参考 参考文献 部分中提到的链接以了解更多信息。

AWS 上的无服务器计算

在上一节中，你了解了 AWS Fargate，它允许你基于 Docker 容器运行应用程序和代码，而不需要管理基础设施。这是一个 AWS 上的无服务器服务的例子。AWS 提供的无服务器服务具有以下共同特征：

无需管理基础设施
自动扩展
内置高可用性
按使用付费计费

AWS 上的无服务器计算技术包括 AWS Lambda 和 Fargate。AWS Lambda 是一种无服务器计算服务，允许您运行由超过 200 个服务和 SaaS 应用程序触发的任何代码。代码可以用 Python、Node.js、Go 和 Java 等流行语言编写，或者可以像之前描述的那样打包成 Docker 容器。使用 AWS Lambda，您只需为代码运行的毫秒数付费，超过一百万次免费请求的非常慷慨的免费层。AWS Lambda 支持创建各种应用程序，包括文件处理、流媒体、Web 应用程序、物联网后端应用程序和移动应用后端。

如需了解 AWS 上无服务器计算的更多信息，请参阅参考文献部分包含的链接。

在下一节中，我们将介绍 AWS 上网络的基本概念。

AWS 上的网络

AWS 上的网络是一个庞大的主题，超出了本书的范围。然而，为了方便解释接下来的某些章节和部分，我们将在此尝试提供一个简要概述。首先，AWS 有一个称为区域的概念，这是 AWS 在全球范围内放置数据中心集群的物理区域。每个区域包含多个逻辑上分离的数据中心组，称为可用区。每个可用区都有独立的电源、冷却和物理安全。可用区通过冗余和超低延迟的 AWS 网络连接。在撰写本章时，AWS 有 26 个区域和 84 个可用区。

我们接下来将讨论的基础概念是虚拟私有云（VPC）。VPC 是一个逻辑分区，允许您启动和分组 AWS 资源。在下面的图中，我们可以看到区域包含多个可用区，这些可用区可以跨越多个 VPC：

图 3.7 – 区域、VPC 和可用区之间的关系

子网是与您定义的 VPC 关联的 IP 地址范围。路由表是一组规则，用于确定 VPC 内流量如何流动。在 VPC 中创建的每个子网都会自动与 VPC 的主路由表关联。VPC 端点允许您将一个 VPC 中的资源连接到另一个 VPC 和其他服务。

接下来，我们将讨论无类域间路由（CIDR）块和路由。

CIDR 块和路由

CIDR 是一组标准，用于将 IP 地址分配给设备或设备组。CIDR 块看起来如下所示：

10.0.0.0/16

这定义了起始 IP 和块中的 IP 地址数量。在这里，16 表示有 2^(32-16)或 65,536 个唯一的地址。当您创建 CIDR 块时，必须确保所有 IP 地址都是连续的，块大小是 2 的幂，IP 地址范围从0.0.0.0到256.256.256.256。

例如，CIDR 块 10.117.50.0/22 总共有 2^(32-22)，或 1,024 个地址。现在，如果我们想将这个网络划分为四个具有 256 个地址的网络，我们可以使用以下 CIDR 块：

`10.117.50.0.22`	`10.117.50.0/24`	256 个地址
`10.117.51.0/24`	256 个地址
`10.117.52.0/24`	256 个地址
`10.117.53.0/24`	256 个地址

图 3.8 – 使用 CIDR 块在网络上创建四个分区的示例

很好，现在我们知道了 CIDR 块是如何工作的，让我们将其应用到 VPC 和子网上。

HPC 工作负载的联网

回顾 图 3.8，我们在以下图中对 CIDR 块进行了一些修改，以显示定义 VPC1 内两个子网的 CIDR 块：

图 3.9 – 用于在 VPC1 中定义两个子网的 CIDR 块

如 图 3.9 所示，VPC 1 有一个 CIDR 块 10.0.0.0/16（相当于 65,536 个地址），两个子网（/24）各自分配了 256 个地址。如您已经注意到的，在这个 VPC 中有几个未分配的地址，将来可以用于更多子网。路由决策是通过路由表定义的，如图所示。这里，每个子网都被认为是私有的，因为来自 VPC 内部的流量不能离开 VPC。这也意味着默认情况下，VPC 内部的资源不能访问互联网。允许来自子网内的资源访问互联网的一种方法是通过添加互联网网关。为了仅从私有子网允许出站互联网连接，您可以使用 NAT 网关。这通常是安全敏感型工作负载的要求。这种修改导致我们的网络图发生了以下变化：

图 3.10 – 向子网 1 添加互联网网关

主要路由表与 VPC 中的所有子网相关联，但我们可以为每个子网定义自定义路由表。这定义了子网是私有、公共还是仅 VPN。现在，如果我们需要 子网 2 中的资源仅通过 图 3.11 中的 虚拟专用网关（VGW）访问企业网络中的 VPN 资源，我们可以创建两个路由表并将它们与 子网 1 和 子网 2 关联，如下面的图所示：

图 3.11 – 添加 VGW 以连接到本地资源

可以使用一个名为 VPC 对等连接 的功能来私有地访问 AWS 上另一个 VPC 的资源。使用 VPC 对等连接，您可以在两个 VPC 之间使用私有网络连接来启用它们之间的通信。有关更多信息，您可以访问 docs.aws.amazon.com/vpc/latest/peering/what-is-vpc-peering.html。如图所示，VPC 对等连接允许 VPC 1 和 VPC 2 中的资源相互通信，就像它们在同一个网络中一样：

图 3.12 – 添加 VPC 对等连接和 VPC 端点

VPC 对等连接可以在同一区域的 VPC 内或不同区域的 VPC 内进行。VPC 端点允许 VPC 内部（此处为 VPC 2）的资源私有地访问 AWS 服务。在此，一个 EC2 实例可以对 Amazon S3、Kinesis 或 SageMaker 等服务进行私有 API 调用。这些被称为 接口类型端点。对于 Amazon S3 和 DynamoDB，也提供了网关类型 VPC 端点，您可以使用策略（例如，Amazon S3 的存储桶策略）进一步自定义访问控制。

在本地和云上运行的工作负载的大型企业客户可能有一个类似于 图 3**.13 的设置：

图 3.13 – 企业网络架构示例

每个企业位置都可以通过使用 Direct Connect（一个用于创建与 AWS 的专用网络连接并带有 VPN 备份的服务）连接到 AWS。私有子网可以托管大型、永久性工作负载的单个或集群的 EC2 实例。EC2 实例集群放置在多可用区自动扩展组中，以便工作负载可以从 AZ 故障的不太可能事件中恢复，并保持最小数量的 EC2 实例。

对于短暂的工作负载，可以使用 EKS、Glue 或 SageMaker 等托管服务。在前面的图中，一个私有的 EKS 集群放置在 VPC 2 中。由于默认情况下禁用了互联网访问，所有容器镜像都必须位于 VPC 内或复制到 ECR 存储库中；也就是说，您不能使用 Docker Hub 上的镜像。要发布日志和保存检查点，需要在 VPC 2 中使用 VPC 端点连接到 Amazon S3 和 CloudWatch 服务。数据存储和数据库在此图中未讨论，但在混合架构中是重要的考虑因素。这是因为某些数据不能离开企业网络，但可以在 AWS 上临时匿名化和复制。

通常，这些在 AWS 上的临时数据用于分析目的，然后被删除。最后，混合架构也可能涉及 AWS Outposts，这是一个完全托管的服务，它扩展了 AWS 服务，例如 EC2、ECS、EKS、S3、EMR、关系数据库服务 (RDS) 等等，到本地。

选择适合 HPC 工作负载的计算

现在您已经了解了 AWS 上的计算和网络基础，我们准备探索一些典型的 AWS 计算架构模式。

选择适合 HPC 和 ML 应用程序的计算涉及考虑您正在设计的其余架构，因此涉及 Well-Architected Framework 的所有方面：

运营卓越
安全性
可靠性
性能效率
成本优化

我们在本节末尾将涵盖这些支柱的最佳实践，但首先，我们将从 AWS 计算的最基本模式开始，并在进展过程中增加复杂性。

模式 1 – 独立实例

许多专为模拟、金融服务、CFD 或基因组学构建的高性能计算（HPC）应用程序，只要选择了正确的实例类型，就可以在单个 EC2 实例上运行。我们在 介绍 AWS 计算生态系统 部分讨论了许多这些实例类型选项。如图所示，可以使用 CloudFormation 模板 在 VPC 中启动 EC2 实例，并为用户提供 Secure Shell （SSH）访问权限，以便在此实例上安装和使用软件：

图 3.14 – 在 VPC 内启动 EC2 实例所使用的 CloudFormation 模板

接下来，我们将描述一个使用 AWS ParallelCluster 的模式。

模式 2 – 使用 AWS ParallelCluster

AWS ParallelCluster 可用于为大规模并行处理或 HPC 提供具有头节点和工作节点的集群。一旦启动，ParallelCluster 将类似于本地 HPC 集群，并增加了云中的安全性和可扩展性优势。这些集群可以是永久的，也可以根据需要配置和取消配置。在 AWS 上，用户可以使用 AWS ParallelCluster 命令行界面 （CLI）即时创建 EC2 实例集群。AWS CloudFormation 用于启动基础设施，包括所需的网络、存储和 AMI 配置。当用户（或多个用户）通过作业调度器提交作业时，自动扩展组中将根据需要配置和取消配置更多实例，如图所示：

图 3.15 – 在 AWS 上使用 AWS ParallelCluster 进行分布式工作负载

用户完成使用集群进行 HPC 工作负载后，他们可以使用 CLI 或 CloudFormation API 删除创建的所有资源。作为对以下架构建议的修改，您可以将 头/主 EC2 节点替换为 Amazon SQS 队列，以获得适用于典型 HPC 工作负载的基于队列的架构。

接下来，我们将讨论如何使用 AWS Batch。

模式 3 – 使用 AWS Batch

AWS Batch 可以帮助运行基于未连接输入配置或文件的 HPC 和大数据应用程序，无需管理基础设施。要将作业提交到 AWS 批处理，您需要将应用程序打包为容器，并使用 CLI 或支持的 API 定义和提交作业。使用 AWS Batch，您可以通过使用默认作业配置、内置作业队列以及与 AWS Step Functions 和 Luigi 等工作流服务的集成来快速开始。

如以下截图所示，用户首先定义一个Docker 镜像（类似于我们在容器部分讨论的镜像），然后将其注册到Amazon ECR。然后，用户可以在AWS Batch中创建一个作业定义，并将一个或多个作业提交到作业队列。输入数据可以从Amazon S3中提取，输出数据可以写入 Amazon S3 上的不同位置：

图 3.16 – 使用 AWS Batch 和 AWS EC2 实例进行批量工作负载

接下来，我们将讨论有助于 AWS 混合架构的模式。

模式 4 – 混合架构

已经投资于大型本地集群的客户，同时希望利用按需、高度可扩展和安全的 AWS 环境进行工作，通常会选择混合方法。在这种方法中，组织决定执行以下操作之一：

在 AWS 上运行特定类型的作业，其余的保持在本地
使用 AWS 处理溢出/多余容量
由于安全原因，将本地作为主要数据存储，或者仅在本地放置调度器或作业监控器，所有计算都在 AWS 上完成
在本地运行小型、测试或开发作业，但使用 AWS 上的高性能或高内存实例运行较大的生产作业

可以使用名为 DataSync 的软件代理将本地数据传输到 Amazon S3（有关信息，请参阅docs.aws.amazon.com/datasync/latest/userguide/working-with-agents.html）。在本地使用 Lustre 共享高性能文件系统的集群可以利用 AWS 上的 Amazon FSx for Lustre（更多信息，请参阅aws.amazon.com/fsx/lustre/）。以下图是混合工作负载的参考架构：

图 3.17 – 使用 FSx、S3 和 AWS DataSync 进行混合架构

接下来，我们将讨论基于容器的分布式处理模式

模式 5 – 基于容器的分布式处理

以下图是适合 HPC 和其他相关应用的基于容器的分布式处理工作流的参考架构：

图 3.18 – 基于 EKS 的分布式计算架构

管理员可以使用如 eksctl 或 CloudFormation 这样的命令行工具来配置资源。可以运行一个或多个容器的 Pod 可以在您选择的托管 EC2 节点上运行，或者通过 AWS Fargate 服务运行。EKS 上的 EMR 也可以用来在 EKS 管理的节点上直接运行开源的大数据应用（例如，基于 Spark）。在所有上述情况下，都可以使用 AWS 提供的容器作为基础，或者使用您构建并推送到 ECR 的完全定制的容器。在 EKS Pod 中运行的应用可以访问 Amazon S3、Redshift、DynamoDB 或其他众多服务和应用的数据。要了解更多关于 EKS、Fargate 或 EKS 上的 EMR 的信息，请参阅参考部分提供的链接。

模式 6 – 无服务器架构

下面的图示是一个用于实时、无服务器处理、分析和商业智能的无服务器架构示例：

图 3.19 – 实时、无服务器处理和商业分析架构

首先，Kinesis Data Streams 从一个或多个数据生产者捕获数据。接下来，可以使用Kinesis Data Analytics来构建实时应用，使用 SQL、Java、Python 或 Scala 转换这些传入的数据。数据还可以通过管理的Apache Zeppelin笔记本（zeppelin.apache.org/）进行交互式处理。在这种情况下，正在使用Lambda 函数来持续后处理Kinesis Analytics应用程序的输出，然后将过滤后的结果集放入无服务器、NoSQL 数据库DynamoDB中。

同时，Kinesis Firehose组件被用来将传入的数据保存到 S3，然后由其他几个无服务器组件如AWS Glu和AWS Lambda进行处理，并使用AWS Step Functions进行编排。使用 AWS Glu，您可以运行用熟悉的语言如 SQL 或 Spark 编写的无服务器提取-转换-加载（ETL）应用。然后，您可以将 Glue 转换作业的输出保存到数据存储如 Amazon S3 或 Amazon Redshift。在 Amazon SageMaker 上运行的 ML 应用也可以利用实时流分析输出的数据。

一旦数据被转换，就可以使用 Amazon Athena 进行交互式查询。Amazon Athena 使你能够使用标准 SQL 命令查询存储在 Amazon S3 中的数据。Athena 还直接集成到 Glue 数据目录中，这使得在没有额外负担编写 ETL 作业或脚本以启用此连接的情况下，与这两个服务一起工作变得更加容易。Athena 基于开源库 Presto (prestodb.io/)，可以用于查询各种标准格式，如 CSV、JSON、Parquet 和 Avro。使用 Athena 联邦数据源，你可以使用可视化工具如 Amazon QuickSight 来运行复杂的 SQL 查询。

与使用数据集来可视化输出不同，当配置正确时，QuickSight 可以直接将这些 SQL 查询发送到 Athena。查询的结果可以随后通过多种图表类型直接进行交互式可视化，并组织到仪表板中。然后，这些仪表板可以与业务分析师共享以进行进一步研究。

在本节中，我们介绍了围绕 AWS 计算主题的各种模式。尽管这不是模式的完整列表，但这应该能给你一个基本的概念，了解所使用的组件或服务以及这些组件是如何相互连接以实现不同需求的。接下来，我们将描述一些与 AWS 上 HPC 相关的最佳实践。

HPC 工作负载的最佳实践

AWS 架构良好框架有助于在云上构建安全、经济高效、弹性好和性能高的应用程序和工作负载。它是构建任何应用程序时的首选参考资料。有关 AWS 架构良好框架的详细信息，请参阅 aws.amazon.com/architecture/well-architected/。然而，某些领域和垂直领域的应用程序需要进一步的审查，并且需要以与 AWS 架构良好框架提供的通用指南不同的方式处理详细信息。因此，我们有许多其他称为透镜的文档，提供最佳实践指导；以下列出了一些与我们当前讨论相关的透镜：

数据分析透镜 – 适用于数据分析工作负载的架构良好透镜 (docs.aws.amazon.com/wellarchitected/latest/analytics-lens/analytics-lens.html?did=wp_card&trk=wp_card)
无服务器透镜 – 专注于在 AWS 上构建无服务器应用程序 (docs.aws.amazon.com/wellarchitected/latest/serverless-applications-lens/welcome.html)
ML 视角 – 用于 AWS 上的 ML 工作负载 (docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/welcome.html?did=wp_card&trk=wp_card)
HPC 视角 – 关注 AWS 上的 HPC 工作负载 (docs.aws.amazon.com/wellarchitected/latest/high-performance-computing-lens/welcome.html?did=wp_card&trk=wp_card)

尽管本书的范围不包括概述通用的 AWS Well-Architected 框架的最佳实践，以及这些个别视角，但我们将列出一些与当前主题 HPC 和 ML 相关的重要设计考虑因素：

HPC 和 ML 应用程序都会随着时间的推移而发展。那些提前几年冻结架构的组织往往是对变化持抵制态度的，并且后来会受到更大的成本影响，以适应新的需求。一般来说，避免静态架构是最佳实践，因为原始需求可能会迅速变化。当需要运行更多训练作业或更多 HPC 模拟时，架构必须允许扩展并提高整体性能，但在需求较低时也能回到稳定、低成本的状态。

在 AWS 上，计算集群可以在任何给定时间点进行适当规模调整，使用托管服务可以帮助动态配置资源。例如，Amazon SageMaker 允许用户为训练配置各种实例类型，无需承担维护集群或基础设施的繁重工作。客户只需选择感兴趣的框架，指向 Amazon S3 中的训练数据，并使用 API 启动、监控和停止训练作业。客户只需为使用的部分付费，无需为任何闲置时间付费。

构建旨在鼓励和启用协作的架构，可以显著提高在 AWS 上运行 HPC 和 ML 工作负载的团队的生产力。随着团队变得越来越远程和全球化，有效协作的重要性不容低估。为了提高协作，以下事项很重要：
- 使用实验跟踪工具跟踪实验。
- 启用资源共享，例如配置文件、CloudFormation 模板、管道定义、代码、笔记本和数据。
- 启用自动化，并使用工具进行持续集成、持续交付、持续监控、持续训练和持续改进。
- 确保工作可重复 – 这意味着输入、环境配置和包可以轻松重用，批量处理的输出可以验证。这有助于跟踪变更，进行审计，并保持高标准。
当可能时，使用托管服务提供的临时资源。同样，这适用于 HPC 和 ML。在考虑混合架构或迁移本地工作负载到 AWS 时，不再需要完全在 AWS 上复制工作负载。例如，基于 Spark 的工作负载可以在 AWS Glue 上运行，无需配置整个 EMR 集群。同样，您可以使用 Amazon SageMaker API 运行机器学习训练或推理，而无需处理底层的集群。
在调整资源大小时要考虑性能和成本。对于非时间敏感型的工作负载，在 AWS 上使用 Spot 实例是最简单的成本优化策略。对于高性能计算（HPC）应用，可以在 EC2 Spot 实例上运行工作负载，或者在 EKS 或 Fargate 上使用 Spot 舰队来处理容器化工作负载，这可以比同类型的按需实例提供高达 90%的折扣。

在 SageMaker 上，使用 Spot 实例非常简单——您只需向支持的训练 API 传递一个参数即可。另一方面，对于高性能工作负载，优先考虑按需实例而不是 Spot 实例，以便及时返回和分析模拟或 ML 训练作业的结果。在选择用于您的 HPC 或 ML 工作负载的服务或应用程序时，优先考虑按使用付费的定价模式，而不是许可和前期成本。

考虑整个管道的成本优化和性能。对于 HPC 和 ML 应用，通常是在管道上设计——例如，数据传输、预处理、训练或模拟、后处理和可视化。可能某些步骤需要的计算资源比其他步骤少。此外，提前关于数据格式或位置的决定可能会迫使下游步骤在时间、处理资源或成本方面更加昂贵。
专注于进行小而频繁的更改，构建模块化组件，并以自动化的方式进行测试。减少手动干预的程度，并设计工作负载以便它不需要任何停机时间进行维护，这是一种最佳实践。
对于 HPC 和机器学习（ML），使用提供良好文档和支持的软件包和工具。这个选择需要在前期谨慎做出，因为基于这个选择，可能需要更改几个架构、设计和团队决策。例如，在选择 PyTorch 这样的机器学习框架时，了解支持该框架的 AWS 服务，并雇佣一个熟悉该特定框架的团队以确保成功是非常重要的。

在 HPC 中，选择用于分子动力学模拟的软件将决定可以进行的模拟规模，哪些服务与 AWS 上的包兼容，以及哪些团队成员受过培训并准备好使用 AWS 上设置的此软件套件。

在开始开发多个工作负载或应用程序之前，优先考虑安全并建立安全最佳实践。在 AWS Well-Architected 框架和几个透镜中详细讨论了这些最佳实践领域。在此，我们概述了主要子主题以保持完整性：
- 身份和访问管理（IAM）
- 侦探控制
- 预防性控制
- 基础设施保护
- 数据保护
- 事件响应
预期复杂的架构系统会失败是正常的，但最佳实践是快速响应并从这些故障中恢复。检查点是一个常见的功能，它被构建到 HPC 和 ML 应用程序中。一个常见的想法是将数据或进度（或两者）检查点到远程 S3 位置，以便模拟或训练作业在失败后可以继续。当使用 spot 实例时，检查点变得更加重要。当自行管理基础设施时，您有灵活性将应用程序部署到多个可用区，当极端低延迟要求不需要满足时。托管服务负责维护和更新在这些实例上运行的实例和容器。
确保集群是动态的，可以由多个用户同时使用，并且设计用于处理大量数据。为了成功设计集群，使用云原生技术在一个有意义的用例上测试应用程序和包，而不是玩具问题。有了云，您有能力以低成本启动和关闭临时集群来测试您的用例，同时确保生产规模的工作负载可以平稳且如预期地运行。

在本节中，我们列出了一些适用于 AWS 上 HPC 工作负载的最佳实践。

摘要

在本章中，我们首先描述了 AWS 计算生态系统，包括各种类型的 EC2 实例，以及基于容器的服务（Fargate、ECS 和 EKS），以及无服务器计算选项（AWS Lambda）。然后我们介绍了 AWS 上的网络概念，并通过视觉巡游将其应用于典型工作负载。为了帮助您选择适合 HPC 工作负载的正确计算，我们描述了几个典型模式，包括独立实例、自管理实例、AWS ParallelCluster、AWS Batch、混合架构、基于容器的架构以及完全无服务器的 HPC 架构。最后，我们讨论了各种最佳实践，这些最佳实践可能有助于您正确调整实例和集群的大小，并将 Well-Architected 框架应用于您的负载。

在下一章中，我们将概述可用于 AWS 上 HPC 和 ML 工作负载的各种存储服务。

参考资料

关于本章涵盖主题的更多信息，请导航到以下页面：

第四章：数据存储

云中的数据存储变得非常普遍，不仅用于个人用途，也用于商业、计算和应用目的。在个人方面，云存储由知名公司提供，从免费使用的几千兆字节（GBs）到每月或每年支付太字节（TBs）数据的计划。这些服务与移动设备上的应用程序集成良好，使用户能够存储数千张图片、视频、歌曲和其他类型的文件。

对于需要高性能计算的应用程序，云数据存储发挥着更大的作用。例如，在大型数据集上训练机器学习（ML）模型通常需要算法以分布式方式运行。如果数据存储在云中，那么对于 ML 平台来说，将存储在云中的数据进行分区并使这些单独的分区可用于模型训练作业的分布式组件要容易得多。同样，对于需要大量数据和高吞吐量的其他应用程序，使用云数据存储来避免本地存储的限制要合理得多。此外，云数据存储几乎总是内置冗余，以避免硬件故障、意外删除以及数据丢失。云数据存储服务还提供了多种安全和治理工具和功能。此外，由于规模和基础设施维护由存储服务提供商管理，因此云中数据存储的真正拥有成本显著降低。

AWS 为云数据存储提供了多种选项。在本章中，我们将了解各种 AWS 数据存储服务，以及这些服务的安全性、访问管理和治理方面。此外，我们还将了解分层存储选项以节省云数据存储成本。

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

AWS 数据存储服务
数据安全和治理
分层存储以优化成本
为高性能计算（HPC）工作负载选择正确的存储选项

技术要求

要在本章中与各种 AWS 存储选项一起工作，主要技术要求是拥有 AWS 账户以及使用这些存储服务的适当权限。

AWS 数据存储服务

AWS 提供三种不同类型的数据存储服务：对象、文件和块。根据应用的需求，可以使用这些类型中的一种或多种。在本节中，我们将介绍涵盖这些存储类别的 AWS 服务。各种 AWS 数据存储服务如图4.1所示。

图 4.1 – AWS 数据存储服务

在下一节中，我们将讨论 AWS 提供的各种存储选项。

Amazon Simple Storage Service (S3)

Amazon S3 是最常用的云数据存储服务之一，适用于网络应用和高性能计算用例。它是亚马逊的对象存储服务，提供几乎无限的数据存储。使用 Amazon S3 的一些优点包括非常高的可扩展性、持久性、数据可用性、安全性和性能。Amazon S3 可用于各种云原生应用，从简单的数据存储到非常大的数据湖，再到网站托管和高性能应用，例如训练非常高级和计算密集型的机器学习模型。Amazon S3 提供了几种存储选项，这些选项在数据访问、弹性、归档需求和成本方面有所不同。我们可以选择最适合我们的用例和业务需求的存储类别。当访问模式未知或随时间变化时，还有节省成本的选项（S3 智能分层）。我们将在本章的“分层存储以优化成本”部分详细讨论这些不同的 S3 存储类别。

Amazon S3 的关键功能和特性

在 Amazon S3 中，数据以对象的形式存储在 存储桶 中。对象是一个文件及其描述文件的任何元数据，而存储桶是对象的资源（容器）。接下来将讨论 Amazon S3 的一些关键功能。

数据持久性

Amazon S3 设计用于提供非常高的数据持久性，高达 99.999999999%。这意味着存储在 Amazon S3 中的数据对象丢失的可能性极低（平均预期损失约为 0.000000001% 的对象，或者说每 1000 万个对象中大约有 1 个在 1000 万年中丢失）。对于高性能计算应用，数据持久性至关重要。例如，为了训练机器学习模型，数据科学家需要对同一数据集进行各种实验，以微调模型参数以获得最佳性能。如果用于读取训练和验证数据的存储不适用于这些实验，则训练模型的输出将不会一致，从而导致错误的见解以及不良的推理结果。因此，Amazon S3 被用于许多机器学习和其他数据依赖型高性能计算应用，用于存储大量数据。

对象大小

在 Amazon S3 中，我们可以存储高达 5 TB 大小的对象。这对于需要处理大型文件的应用程序特别有用，例如视频（例如，高清电影或安全录像）、大型日志或其他类似文件。许多高性能计算应用程序，如用于视频分类的机器学习模型训练，需要处理数千个此类大型文件，以生成对未见数据做出良好推断的模型。深度学习模型可以一次（或多次）从 Amazon S3 读取这些大型文件，将它们临时存储在模型训练虚拟机上，计算和优化模型参数，然后继续处理下一个对象（文件）。这样，即使是磁盘空间和内存较小的机器也可以用于在大型数据文件上训练这些计算密集型模型。同样，在模型推理时，如果需要存储数据，可以将其存储在 Amazon S3 中，对象大小可达 5 TB。

存储类别

Amazon S3 有各种存储类别。我们可以在这些类别中的任何一个中存储数据，也可以在类别之间移动数据。选择用于存储数据的正确存储类别取决于我们的数据存储、成本和保留需求。不同的 S3 存储类别如下：

S3 标准版
S3 标准版-不经常访问
S3 单区-不经常访问
S3 智能分层
S3 冰川即时检索
S3 冰川灵活检索
S3 冰川深存档
S3 Outposts

我们将在本章的“分层存储以优化成本”部分了解这些存储类别。

存储管理

Amazon S3 还提供了各种高级存储管理选项，例如数据复制、防止数据意外删除和数据版本控制。Amazon S3 中的数据可以被复制到同一或不同 AWS 区域的目标存储桶中。这样做可以增加冗余，从而提高可靠性和性能，并降低延迟。这对于高性能计算（HPC）应用也非常重要，因为需要访问存储在 Amazon S3 中的数据的实时 HPC 应用将从访问地理位置更近的 AWS 区域的数据中受益。当数据集在多个 AWS 区域之间复制时，性能通常可以加速高达 60%。Amazon S3 还支持数据访问的批量操作，允许通过单个 API 调用执行各种 S3 操作。此外，可以为存储在 Amazon S3 中的对象配置生命周期策略。使用这些策略，S3 对象可以根据访问需求自动移动到不同的存储类别，从而实现成本优化。

存储监控

亚马逊 S3 还具有一些监控功能。例如，可以将标签分配给 S3 存储桶，并使用 AWS 成本分配报告来查看使用这些标签的汇总使用情况和成本。Amazon CloudWatch 还可以用于查看 S3 存储桶的健康状况。此外，还可以使用 AWS CloudTrail 跟踪存储桶和对象级别的活动。图 4**.2展示了各种存储监控工具与 Amazon S3 存储桶协同工作的示例：

图 4.2 – S3 存储监控和管理

前面的图示显示，我们还可以配置亚马逊简单通知服务（SNS）以在发生某些事件的情况下触发 AWS Lambda 执行各种任务，例如新文件上传等。

数据传输

对于建立在大量数据之上并使用 S3 的任何应用程序，数据首先需要传输到 S3。AWS 提供了各种服务，这些服务与 S3 协同工作，以满足不同的数据传输需求，包括混合（本地/云）存储以及在线和离线数据传输。例如，如果我们想将我们的本地存储扩展到云 AWS 存储，我们可以使用AWS 存储网关（图 4**.3）。AWS 存储网关的一些常见用例包括替换磁带库、云存储后端文件共享以及为本地应用程序提供低延迟数据缓存。

图 4.3 – 使用 AWS 存储网关的数据传输示例

对于需要在线数据传输的用例，可以使用 AWS DataSync 高效地将数百 TB 数据传输到 Amazon S3。此外，AWS Transfer Family 也可以用于使用 SFTP、FTPS 和 FTP 将数据传输到 S3。对于离线数据传输用例，AWS Snow Family 提供了一些选项，包括 AWS Snowcone、AWS Snowball 和 AWS Snowmobile。有关 AWS Snow Family 的更多详细信息，请参阅进一步阅读部分。

性能

S3 对于 HPC 应用程序的一个重大优势是它支持并行请求。每个 S3 前缀每秒支持 3500 次添加数据请求和 5500 次检索数据请求。前缀用于在 S3 存储桶中组织数据。这些是对象键名开头的一系列字符。我们可以根据需要并行拥有多个前缀，每个前缀都将支持这种吞吐量。这样，我们可以通过添加前缀来实现应用程序所需的吞吐量。此外，如果客户端和 S3 存储桶之间存在较长的地理距离，我们可以使用 Amazon S3 传输加速来传输数据。Amazon CloudFront 是一个全球分布的边缘位置网络。

使用 S3 传输分配，数据首先传输到 Amazon CloudFront 的边缘位置。从边缘位置，然后使用优化后的高带宽和低延迟网络路径将数据传输到 S3 存储桶。此外，数据还可以在 CloudFront 边缘位置缓存，以优化频繁访问请求的性能。这些与性能相关的功能有助于提高数据访问的吞吐量和降低延迟，特别适合各种高性能计算（HPC）应用。

一致性

向 Amazon S3 的数据存储请求具有强大的读后写一致性。这意味着任何写入（新或覆盖）到 S3 的数据都可以立即访问。

分析

Amazon S3 还具备分析功能，包括 S3 存储透镜和 S3 存储类分析。S3 存储透镜可用于提高存储成本效率，以及提供数据保护的最佳实践。此外，它还可以用于查看对象存储的使用和活动趋势。它可以在组织中的数千个账户中提供单一视图，并在多个级别上生成见解，如账户、存储桶和前缀。使用 S3 存储类，我们可以通过决定何时将数据移动到正确的存储类来优化成本。这些信息可用于配置生命周期策略，以实现 S3 存储桶的数据传输。Amazon S3 库存是另一个 S3 功能，它生成每日或每周报告，包括存储桶名称、键名称、最后修改日期、对象大小、类别、复制、加密状态以及一些额外的属性。

数据安全

Amazon S3 具有各种安全措施和功能。这些功能包括阻止未经授权的用户访问数据、锁定对象以防止删除、修改对象所有权以进行访问控制、身份和访问管理、发现和保护敏感数据、服务器端和客户端加密、检查 AWS 环境，以及使用私有 IP 地址从本地或云连接到 S3。我们将在数据安全与 治理部分详细了解这些数据安全和访问管理功能。

Amazon S3 示例

要能在 S3 存储桶中存储数据，我们首先需要创建该存储桶。一旦存储桶创建成功，我们就可以向其中上传对象。上传对象后，我们可以下载、移动、打开或删除它。为了创建 S3 存储桶，有一些先决条件，如下所述：

注册 AWS 账户
创建一个身份和访问管理（IAM）用户或假定 IAM 角色的联合用户
以 IAM 用户身份登录

如何执行这些先决步骤的详细信息可以在 Amazon S3 的文档网页上找到（参见进一步 阅读部分）。

S3 存储桶创建

我们可以通过登录 AWS 管理控制台并在服务中选择 S3 来创建一个 S3 存储桶。一旦进入 S3 控制台，我们将看到一个类似于 图 4**.4 所示的屏幕。4*:

图 4.4 – Amazon S3 控制台

如 图 4**.4 所示，我们目前在账户中还没有任何 S3 存储桶。要创建一个 S3 存储桶，请执行以下步骤：

点击此页面上显示的 创建存储桶 按钮之一。图 4**.5 显示了 S3 控制台上的 创建存储桶 页面。
接下来，我们需要指定 存储桶名称 和 AWS 区域。请注意，S3 存储桶名称需要是全球唯一的：

图 4.5 – Amazon S3 存储桶创建

我们还可以从我们的现有 S3 存储桶中选择某些存储桶设置。在 S3 创建存储桶 页面上，我们还可以定义存储桶中的对象是否由创建存储桶的账户拥有，因为其他 AWS 账户也可以拥有存储桶中的对象。此外，我们还可以选择是否要阻止对存储桶的所有公共访问（如图 图 4**.6 所示）。在 S3 存储桶创建页面上还有其他我们可以选择的功能，例如版本控制、标签、加密和对象锁定：

图 4.6 – S3 存储桶的公共访问选项

存储桶创建完成后，它将显示在 S3 控制台中，如图 图 4**.7 所示，其中我们创建了一个名为 myhpcbucket 的存储桶。我们可以使用控制台、AWS 命令行界面 （CLI）、AWS SDK 或 Amazon S3 Rest API 向其中添加对象：

图 4.7 – 显示 myhpcbucket 的 Amazon S3 控制台

我们可以点击存储桶名称，查看其中存储的对象以及存储桶属性、权限、指标、管理选项和访问点。

在本节中，我们学习了关于 Amazon S3 存储类、其关键特性和功能，以及如何创建一个 Amazon S3 存储桶。在下一节中，我们将讨论 Amazon Elastic File System，它是 Amazon Elastic Compute Cloud 实例的文件系统。

Amazon Elastic File System (EFS)

亚马逊弹性文件系统（EFS）是一个完全管理的无服务器弹性 NFS 文件系统，专门为 Linux 工作负载设计。它可以自动扩展到 PB 级数据，非常适合与本地资源以及各种 AWS 服务一起使用。亚马逊 EFS 的设计使得数千个亚马逊弹性计算云（EC2）实例可以提供并行共享访问。除了 EC2 之外，EFS 文件系统还可以通过文件系统接口由亚马逊弹性容器服务（ECS）、亚马逊弹性 Kubernetes 服务（EKS）、AWS Fargate和AWS Lambda函数访问。以下是一些常见的 EFS 用例：

高性能计算：由于亚马逊 EFS 是一个共享文件系统，因此非常适合需要跨多个实例分布式工作负载的应用程序。需要高性能计算的应用程序和用例，如图像和视频处理、内容管理以及特征工程、数据处理、模型训练、数值优化、大数据分析等类似的应用程序，可以从亚马逊 EFS 中受益。
容器化应用程序：由于亚马逊 EFS 具有耐久性，这对于这些应用程序来说是非常重要的，因此非常适合容器化应用程序。EFS 与亚马逊基于容器的服务集成，例如亚马逊 ECS、亚马逊 EKS 和 AWS Fargate。
DevOps：由于亚马逊 EFS 具有共享代码的能力，因此可以用于 DevOps。这有助于快速、敏捷、安全地修改代码以及应用错误修复和增强，从而根据客户反馈实现快速周转时间。
数据库备份：亚马逊 EFS 也常被用作数据库备份。这是因为 EFS 具有非常高的耐久性和可靠性，低成本，以及作为符合 POSIX 规范的文件存储系统——所有这些通常都是数据库备份的要求，在数据丢失或紧急情况下，可以从该备份快速恢复主数据库。

在下一节中，我们将讨论亚马逊 EFS 的关键功能。

亚马逊 EFS 的关键功能和特性

在本节中，我们将讨论亚马逊 EFS 的一些关键功能和特性。亚马逊 S3 的一些关键功能也适用于亚马逊 EFS。

耐久性

与亚马逊 S3 一样，亚马逊 EFS 也非常具有高度耐久性和可靠性，提供 99.999999999%的耐久性。EFS 通过在同一个 AWS 区域内的多个可用区（AZs）存储所有内容来实现这一高水平的耐久性和冗余（除非我们为 EFS 存储选择 EFS 单区存储类）。由于数据可以在多个 AZs 中访问，EFS 具有从并发设备故障中快速恢复和修复的能力。

存储类

亚马逊 EFS 还提供了通过存储类进行存储的多种选项。这些存储类如下：

亚马逊 EFS 标准
Amazon EFS 单区
Amazon EFS 标准-不常用访问
Amazon EFS 单区-不常用访问

我们将在分层存储以优化成本部分讨论这些类别。我们可以通过策略轻松地在存储类别之间移动文件以实现成本和性能优化。

性能和吞吐量

Amazon EFS 有两种性能和吞吐量模式。对于性能模式，它有通用型和最大 I/O。通用型模式为随机以及顺序输入输出文件系统操作提供低延迟。另一方面，最大 I/O 模式是为非常高的吞吐量和每秒操作而设计的。因此，它非常适合高性能和高并行化计算应用。

对于吞吐量，EFS 有突发（默认）和配置模式。在突发模式下，吞吐量随着文件系统的大小而扩展，并且可以根据工作负载的性质动态地突发。在配置模式下，吞吐量可以根据应用程序所需的专用吞吐量进行配置。它不依赖于文件系统的大小。

可伸缩性

Amazon EFS 具有高度弹性和可伸缩性。随着数据的增加或减少，其大小会上下增长，并且是为高吞吐量、每秒输入/输出操作（IOPS）和低延迟而设计的，适用于广泛的负载和用例。它还具有为不可预测和波动的负载提供非常高的突发吞吐量的能力，在撰写本文时，支持高达 10 GB/秒和 500,000 IOPS。

AWS 备份

Amazon EFS 与 AWS Backup 一起工作，AWS Backup 是一个完全托管的备份服务。它自动化并使我们能够集中管理 EFS 文件系统，消除了昂贵且繁琐的手动流程。

数据传输

与 Amazon S3 一样，Amazon EFS 也与各种 AWS 数据传输服务一起工作，例如 AWS DataSync 和 AWS Transfer Family，用于在 EFS 中传输数据，用于一次性迁移，以及用于定期同步、复制和数据恢复。

Amazon EFS 示例

我们可以使用 AWS 管理控制台或 AWS CLI 创建 Amazon EFS 文件系统。在本节中，我们将通过 AWS 管理控制台创建 EFS 文件系统的示例：

当我们登录 AWS 管理控制台并浏览到 Amazon EFS 服务时，我们会看到类似于图 4.8的主页面。它还列出了我们在查看的 AWS 区域中创建的所有 EFS 文件系统：

图 4.8 – Amazon EFS 登录页面

要创建 Amazon EFS 文件系统，我们点击创建文件系统按钮。当我们点击此按钮时，我们会看到一个类似于图 4.9的屏幕。在这里，我们可以为我们的文件系统选择任何名称。

图 4.9 – 创建 Amazon EFS 文件系统

对于文件系统，选择一个虚拟私有云（VPC），并选择我们是否希望它在我们的区域的所有可用区（AZ）中跨域，或者只在一个 AZ 中。
我们还可以点击自定义按钮来配置其他选项，例如生命周期管理（图 4.10）、性能模式和吞吐量模式（图 4.11）、加密、标签、网络选项和文件系统策略。

图 4.10 – 选择 Amazon EFS 文件系统的选项

图 4.11 – 选择 Amazon EFS 的附加选项

点击下一步然后创建将创建 Amazon EFS 文件系统。我们创建的 EFS 文件系统如图图 4.12所示。

图 4.12 – 创建的 EFS 文件系统

我们可以点击文件系统来查看其各种属性，以及获取将其挂载到 Linux 实例的命令，如图图 4.13所示。一旦 EFS 文件系统挂载，我们就可以像使用常规文件系统一样使用它。

图 4.13 – EFS 文件系统的挂载选项和命令

让我们在下一节讨论 Amazon 弹性块存储（EBS）及其关键特性和功能。

Amazon EBS

Amazon EBS是一个可扩展、高性能的块存储服务，可以用于创建附加到 EC2 实例的存储卷。这些卷可用于各种目的，例如作为常规块存储卷，在这些卷上创建文件系统，甚至运行数据库。以下是一些 Amazon EBS 的常见用例：

EBS 可用于大数据分析，需要频繁调整集群大小，特别是对于 Hadoop 和 Spark。
可以使用 Amazon EBS 部署多种类型的数据库。一些例子包括 MySQL、Oracle、Microsoft SQL Server、Cassandra 和 MongoDB。
如果我们在 EC2 实例上运行计算作业，并需要附加存储卷来读取数据并写入结果，而无需跨多个实例进行扩展，那么 EBS 是一个很好的选择。

接下来，让我们看看 Amazon EBS 的一些关键特性和功能。

Amazon EBS 的关键特性和功能

在本节中，我们讨论 Amazon EBS 的关键特性和功能，如卷类型、快照、弹性卷、EBS 优化实例和持久性。

卷类型

EBS 卷分为两大类：SSD-backed 存储和HDD-backed 存储。我们在这里讨论这些类别：

SSD-backed storage: 在 SSD-backed 存储中，性能主要取决于 IOPS，最适合事务性工作负载，例如数据库和引导卷。SSD-backed 存储卷主要有两种类型：
- 预配置 IOPS SSD 卷：它们是高吞吐量卷，设计用于提供个位数的毫秒级延迟，并且 99.9% 的时间都能提供预配置的性能。它们特别适合需要非常高的正常运行时间的关键应用程序。
- 通用 SSD 卷：这些存储卷也提供低至个位数的毫秒级延迟，并且 99% 的时间都能提供预配置的性能。它们特别适合事务性工作负载、虚拟桌面、引导卷和类似的应用程序。
HDD 支持的存储：在 HDD 支持的存储中，性能主要取决于 MB/s，最适合吞吐量密集型工作负载，例如 MapReduce 和日志处理。HDD 支持的存储卷主要有两种类型：
- 吞吐量优化 HDD 卷：这些卷以 MB/s 为单位提供性能，最适合 MapReduce、Kafka、日志处理和 ETL 工作负载。
- 冷 HDD 卷：它们是所有 EBS 卷中成本最低的，由硬盘驱动器支持。这些卷最适合不常访问的工作负载，例如冷数据集。

根据使用情况选择适当的 EBS 卷类别选项为用户提供灵活性。

快照

Amazon EBS 具有将卷快照存储到 Amazon S3 的能力。这是通过增量方式完成的，仅添加自上次快照以来已更改的数据块。EBS 快照的数据生命周期可用于安排 EBS 的自动创建和删除。这些快照不仅可用于数据恢复，还可以用于启动新卷、扩展卷大小以及将 EBS 卷在 AWS 区域内的 AZ 之间迁移。

弹性卷

使用 Amazon EBS 弹性卷，我们可以在稍后的时间动态增加卷的容量，也可以更改卷的类型而无需停机。

EBS 优化实例

为了充分利用为 EBS 卷配置的 IOPS 并提供最大性能，一些 EC2 实例可以启动为 EBS 优化实例。这确保了 Amazon EC2 实例和 Amazon EBS 卷之间的专用吞吐量。

耐用性

类似于 Amazon S3 和 Amazon EFS，Amazon EBS 也具有高度耐用性和可靠性。Amazon EBS 中的数据在 AZ 中的多个服务器上进行复制，以提供冗余和恢复功能，以防卷存储中的任何单个组件出现故障。

EBS 卷创建

在创建 EC2 实例时，我们可以向其实例添加额外的 EBS 卷，如图 4.14中所示，在添加存储步骤中。此外，我们还可以在实例启动后从 EC2 管理控制台添加新卷。在 EC2 管理控制台中，我们可以审查我们的现有卷和快照，以及生命周期管理策略。

图 4.14 – 在创建 EC2 实例过程中添加 EBS 卷

图 4**.15 展示了一个示例，其中我们有两个 EBS 卷，以及它们的各种配置参数：

图 4.15 – EC2 管理控制台中的卷页面，显示了创建的两个 EBS 卷

到目前为止，在本章中，我们已经了解了 Amazon S3、Amazon EFS 和 Amazon EBS。在下一节中，我们将讨论 Amazon FSx 文件系统系列。

Amazon FSx

Amazon FSx 是一个功能丰富、可扩展、高性能且成本效益高的文件系统系列。它包括以下常用的四种文件系统：

Amazon FSx for NetApp ONTAP
Amazon FSx for Windows 文件服务器
Amazon FSx for Lustre
Amazon FSx for OpenZFS

一些 FSx 文件系统系列常用的例子包括以下内容：

FSx 可以提供非常低的延迟（亚毫秒级）和数百万 IOPS，并且具有高度的可扩展性，使其非常适合高性能计算应用，如机器学习、数值优化、大数据分析和类似应用
数据可以通过将 FSx 文件系统与本地文件系统匹配，在不破坏或修改现有代码和工作流程的情况下迁移到 FSx。
媒体和娱乐是另一个 FSx 非常常用的例子，因为它是一个高性能的文件系统

Amazon FSx 的关键特性

在本节中，我们将讨论 Amazon FSx 的关键特性，例如管理、持久性和成本。

全托管

Amazon FSx 是全托管的，这使得将基于行业常用文件系统构建的应用程序迁移到 AWS 变得非常容易。由于亚毫秒级的延迟，Linux、Windows 和 macOS 应用程序与 Amazon FSx 配合得非常好，非常适合需要非常低延迟和高性能的工作。

持久性

除了可以选择在 AWS 区域之间复制数据外，Amazon FSx 中的数据在 AZ 之间或内部进行复制。它还与 AWS Backup 集成，用于备份管理和保护。这些特性使 Amazon FSx 成为一个高度可用和持久的文件系统系列。

成本

根据需要，Amazon FSx 的成本和性能可以进行优化。它可以用于小型以及非常计算密集型的工作负载，如机器学习和大数据分析。与 Amazon EBS 一样，它也提供 SSD 和 HDD 存储选项，可以分别配置性能和存储容量。

创建 FSx 文件系统

我们可以通过登录 AWS 管理控制台来创建 FSx 文件系统。在控制台中，按下创建文件系统按钮后，我们可以选择 FSx 文件系统的类型（图 4**.16）。

图 4.16 – FSx 文件系统类型

在选择我们想要创建的类型时，我们还会收到额外的选项提示，其中一些是针对正在创建的特定 FSx 系统的。其中一些选项，如部署和存储类型、网络和安全、以及 Windows 身份验证，在图 4.17至图 4.19中展示了 FSx for Windows 文件服务器的选项。这些选项将根据我们创建的文件系统类型而有所不同。创建文件系统后，我们可以将其挂载到我们的 EC2 实例上。

图 4.17 – 创建 FSx for Windows 文件服务器

图 4.18 – FSx for Windows 文件服务器的网络和安全选项

图 4.19 – FSx for Windows 文件服务器的身份验证和加密选项

这结束了我们对 AWS 提供的各种数据存储选项的讨论。我们了解了 Amazon S3、Amazon EFS、Amazon EBS 以及 Amazon FSx 系列，以及它们的关键功能和特性。在下一节中，我们将学习 AWS 云数据存储的数据安全和治理方面。

数据安全和治理

数据安全和治理是云存储解决方案和应用程序的重要方面，无论是网页、文件存储、机器学习应用还是任何其他利用云数据存储的应用。在数据存储或传输过程中保护数据是绝对重要的。此外，应根据数据访问所需的权限对不同的用户应用访问控制。之前提到的所有 AWS 数据存储服务都有各种安全、保护、访问管理和治理功能。我们将在以下章节中讨论这些功能。

IAM

为了能够访问 AWS 资源，我们需要一个 AWS 账户，并在每次登录时进行身份验证。一旦我们登录到 AWS，我们需要权限来访问 AWS 资源。AWS IAM 用于将权限策略附加到用户、组和角色。这些权限策略管理和控制对 AWS 资源的访问。我们可以指定谁可以访问哪些资源以及他们可以对该资源执行哪些操作（例如，创建 S3 存储桶、添加对象、列出对象、删除对象等）。上一节中描述的所有 AWS 数据存储服务都与 AWS IAM 集成，并且可以使用 IAM 管理和控制对这些服务和相关资源的访问。

数据保护

所有 AWS 数据存储和文件系统服务都具备各种数据保护功能。我们应始终保护 AWS 账户凭证，并使用 AWS IAM 创建个人用户账户，为每个用户提供完成工作职责所需的最小权限访问 AWS 资源。以下是一些有助于 AWS 数据保护的安全建议：使用多因素认证（MFA）、安全套接字层（SSL）、传输层安全性（TLS）、通过AWS CloudTrail进行活动日志记录、AWS 加密解决方案以及用于保护个人和敏感数据的Amazon Macie。

Amazon S3 的各个层级（除 One Zone-IA 外）在 AWS 区域内至少存储三个可用区（AZ）中的所有数据对象。One Zone-IA 存储类通过在同一可用区内的多个设备上存储数据来提供冗余和保护。此外，借助版本控制，可以根据需要保留和恢复数据对象的各个版本。

数据加密

AWS 提供静态数据和传输中的数据加密。传输中的加密可以通过启用 SSL/TLS 来实现。此外，所有跨 AWS 区域流动并通过 AWS 全球网络的数据都会自动加密。在 Amazon S3 中，数据也可以通过客户端加密进行加密。Amazon S3 上的静态数据可以使用服务器端加密或客户端加密进行加密。对于服务器端加密，我们可以使用AWS 密钥管理服务（KMS）或 Amazon S3 管理的加密。对于客户端加密，我们需要负责加密过程，并在加密后上传对象到 S3。我们还可以创建加密的 Amazon EFS 文件系统、Amazon EBS 卷以及 Amazon FSx 文件系统系列。

日志记录和监控

日志记录和监控是任何存储解决方案的两个非常关键组件，因为我们需要跟踪谁在访问数据以及他们如何使用数据。通常，这种日志记录也是为了满足审计要求，并构建用于使用和威胁分析的报告。AWS 数据存储服务提供了多种日志记录和监控工具。可以使用 Amazon CloudWatch 警报来监控指标，触发警报到 Amazon SNS 发送通知。我们还可以使用 Amazon CloudTrail 来查看用户、IAM 角色和 AWS 服务在我们数据存储和文件系统中执行的操作。此外，还有其他日志记录和监控功能，例如 Amazon CloudWatch Logs 用于访问日志文件，以及 Amazon CloudWatch Events 用于捕获状态信息并采取纠正措施。

弹性

AWS 基础设施由 AWS 区域组成，而这些区域又由多个物理上分离的可用区（AZ）组成。这些 AZ 具有高吞吐量和低延迟的连接性。默认情况下，S3、EFS、EBS 和 FSx 资源要么在 AWS 区域内的多个 AZ 之间备份和复制，要么根据用户选择的配置在同一 AZ 内备份和复制。此外，还有一些针对这些数据存储和文件系统的特定弹性功能，例如生命周期配置、版本控制、S3 对象锁定、EBS 快照等。所有这些功能使得存储在 AWS 上的数据具有极高的容错性和抗丢失性。

除了上述 AWS 数据存储服务的安全和治理功能外，还有其他一些选项可供选择，例如 VPC 的配置、网络隔离以及一些额外的选项。结合这些工具和资源，AWS 数据存储服务是可用的最安全的云存储服务之一。

AWS 为 Amazon S3 和 Amazon EFS 提供了使用分层存储的选项。这有助于优化用户的数据存储成本。

分层存储以优化成本

AWS 提供了配置其数据存储服务以使用不同存储类型层级的选项。这根据使用案例的要求，显著有助于优化成本和性能。在本节中，我们将讨论 Amazon S3 和 Amazon EFS 的分层存储选项。

Amazon S3 存储类别

如在 Amazon Simple Storage Service (S3) 部分所述，根据使用案例、访问模式和成本要求，存在各种存储类别。我们可以在对象级别配置 S3 存储类别。以下几节将讨论这些存储类别。

Amazon S3 Standard

Amazon S3 Standard 是一种通用型 S3 对象存储，通常用于频繁访问的数据。它提供高吞吐量和低延迟。S3 Standard 的常见应用包括在线游戏、大数据分析、机器学习模型训练和数据存储、机器学习应用的离线特征存储、内容存储和分发，以及具有动态内容的网站。

Amazon S3 Intelligent-Tiering

Amazon S3 Intelligent-Tiering 是针对未知、不可预测和变化的访问模式的存储类别。S3 Intelligent-Tiering 有三个访问层级：频繁访问、不频繁访问和存档层级。S3 Intelligent-Tiering 监控访问模式，并根据需要将数据移动到适当的层级，以节省成本，同时不影响性能、检索费用或产生运营开销。此外，我们还可以设置 S3 Intelligent-Tiering 将数据移动到 Deep Archive Access 层级，用于很少访问的数据（180 天或更长时间）。这可以进一步节省成本。

Amazon S3 Standard-不频繁访问

Amazon S3 Standard-Infrequent Access适用于数据通常访问频率较低，但可能需要快速访问的场景。它提供每 GB 存储和检索的低价格，但性能和耐用性与 S3 Standard 相同。此层级的常见用例包括备份、灾难恢复的数据存储和长期存储。对于高性能计算应用，如机器学习，此存储层级可以用于存储已经训练过的模型或已执行分析的历史数据，而无需在一段时间内重新训练模型。

Amazon S3 One Zone-Infrequent Access

Amazon S3 One Zone-Infrequent Access与 Amazon S3 Standard-Infrequent Access 非常相似，但数据仅存储在一个可用区（多个设备）中，而不是像其他 S3 存储类别的默认设置那样在同一个 AWS 区域内存储三个可用区。这甚至比 S3 Standard-Infrequent Access 存储类别的成本效益更高，通常用于存储二级备份或易于重新创建的数据，例如不再用于活跃机器学习模型训练的工程特性。

Amazon S3 Glacier

Amazon S3 Glacier存储类别是高度灵活、低成本和高性能的数据归档存储类别。在 Amazon S3 Glacier 中，有三个存储类别。Amazon S3 Glacier Instant Retrieval 通常用于数据访问非常罕见，但需要以毫秒级的延迟进行检索的场景，例如新闻媒体资产和基因组数据。Amazon S3 Flexible Retrieval 适用于需要以无额外成本检索大型数据集的场景，如备份恢复数据，但不需要即时检索。此类用例的常规检索时间通常是几分钟到几小时。Amazon S3 Glacier Deep Archive 适用于需要非常罕见检索的场景，例如保存的数字媒体和合规性归档。它是之前讨论的所有选项中成本最低的存储，典型的检索时间是 12 小时到 2 天。

Outposts 上的 S3

对于本地 AWS Outposts 环境，可以使用Outposts 上的 Amazon S3配置对象存储。它在 AWS Outposts 的多个设备和服务器上可靠且冗余地存储数据，特别适合具有本地数据居住要求的使用场景。

在下一节中，我们将讨论 Amazon EFS 的不同存储类别。

Amazon EFS 存储类别

如本处所述，Amazon EFS 提供了根据数据访问频率不同而选择不同存储类别的选项。

Amazon EFS Standard 和 EFS Standard-Infrequent Access 类别

Amazon EFS 标准和 EFS 标准不频繁访问类别是高度可用、耐用且可扩展的文件系统存储类别。它们都在 AWS 区域内多个地理上分离的 AZ 中进行了复制。EFS 标准适用于需要频繁访问数据的使用场景，而 EFS 标准不频繁访问类别适用于不需要频繁数据访问的使用场景。使用 EFS 标准不频繁访问，我们可以显著降低存储成本。

Amazon EFS 单区与 EFS 单区-不频繁访问类别

Amazon EFS 单区与 EFS 单区-不频繁访问类别在单个可用区（AZ）内跨多台设备存储数据，与 Amazon EFS 标准和 EFS 标准不频繁访问类别相比，分别降低了存储成本。对于频繁访问的文件，建议使用 EFS 单区，而对于不频繁访问的文件，建议使用 EFS 单区-不频繁访问类别。

在 Amazon S3 和 Amazon EFS 有多种选项可用的情况下，正确的做法是首先确定一个使用场景的性能、访问和检索需求，然后选择满足这些要求的同时最小化总成本的存储类别。如果我们选择正确的存储类别，尤其是对于非常大的数据集和使用场景，其中数据随时间显著扩展，可以节省大量成本。

到目前为止，我们已经讨论了各种 AWS 存储选项及其功能以及成本优化选项。在下一节中，我们将了解如何为我们的 HPC 使用场景选择正确的存储选项。

选择适合 HPC 工作负载的正确存储选项

在云数据存储有如此多的选择时，决定为 HPC 工作负载选择哪种存储选项变得具有挑战性。数据存储的选择在很大程度上取决于使用场景以及性能、吞吐量、延迟、扩展、归档和检索需求。

对于需要长期归档对象数据的使用场景，应考虑使用 Amazon S3。此外，由于它可以被其他 AWS 服务访问，Amazon S3 非常适合多种高性能计算（HPC）应用。例如，在 Amazon SageMaker 中，我们可以使用存储在 Amazon S3 中的数据进行特征工程，然后将这些特征导入 SageMaker 离线特征存储库，该存储库同样存储在 Amazon S3 中。Amazon SageMaker 使用 Amazon S3 进行机器学习（ML）模型训练。它从 Amazon S3 读取数据，并使用这些数据进行模型拟合、超参数优化和验证。由此产生的模型工件随后也存储在 Amazon S3 中，可用于实时或批量推理。除了 ML 之外，Amazon S3 也是进行数据分析和存储我们希望运行复杂查询的数据、数据归档和备份的良好存储选择。

Amazon EFS 是用于 Amazon EC2 实例的共享文件系统。数千个 EC2 实例可以共享同一个 EFS 文件系统。这使得它非常适合需要高性能扩展的应用程序。内容管理系统、在各个实例上运行且需要访问文件系统中相同数据的分布式应用程序，以及非常大规模的数据分析是一些 EFS 应该被使用的例子。

Amazon EBS 是为单个 EC2 实例（除 EBS Multi-Attach 外）提供的块存储服务，因此 EBS 的主要用例是我们需要为 EC2 实例提供高性能存储时。对于高性能计算应用，如机器学习和数值优化，我们通常需要访问用于训练和调整算法的数据。数据的大小通常非常大，无法在处理过程中存储在内存中（例如，数千个视频）。在这种情况下，我们可以在运行我们的算法的 EC2 实例上存储数据，这使得在数据文件之间进行交换和读取以执行计算操作变得更快。

当我们在本地运行类似的文件系统，并希望将我们的应用程序迁移到云上，同时在新文件系统上设计新应用程序而不必担心底层基础设施和工具以及流程变化时，应使用 Amazon FSx。

这些是我们在这里讨论的一些例子，说明了高性能计算应用如何从各种 AWS 数据存储选项中受益。在设计架构时，选择正确的存储选项组合以使我们的应用程序提供最佳性能，同时确保我们不产生不必要的成本，这一点非常重要。

摘要

在本章中，我们讨论了在 AWS 上可用的不同数据存储选项，以及它们的主要功能和能力。我们介绍了 Amazon S3——一个高度可扩展且可靠的对象存储服务，Amazon EFS——用于 EC2 实例的共享文件系统，Amazon EBS——用于 EC2 实例的块存储，以及 Amazon FSx 文件系统系列。我们还讨论了这些服务的数据保护和治理能力，以及它们如何与其他数据保护、访问管理、加密、日志记录和监控服务集成。我们还探讨了 Amazon S3 和 Amazon EFS 可用的各种存储层，以及我们如何使用这些层来优化我们用例的成本。最后，我们讨论了在哪些情况下使用哪种数据存储服务来为高性能计算应用提供支持。

现在我们对各种 AWS 数据存储服务有了很好的了解，我们准备进入本书的下一部分，第五章**，数据分析，它从如何使用 AWS 服务进行数据分析开始。

进一步阅读

关于本章所学内容的进一步阅读，请参阅以下文章：

Amazon S3 特性: aws.amazon.com/s3/features/
Amazon 区域和可用性 区域: aws.amazon.com/about-aws/global-infrastructure/regions_az/
AWS Snow 系列: aws.amazon.com/snow/
开始使用 Amazon S3: docs.aws.amazon.com/AmazonS3/latest/userguide/GetStartedWithS3.html
先决条件：设置 Amazon S3: docs.aws.amazon.com/AmazonS3/latest/userguide/setting-up-s3.html
AWS EFS 深入了解：它是做什么的以及何时使用它: www.learnaws.org/2021/01/23/aws-efs-deep-dive/
使用 Amazon EFS 实现高度可用和耐用的数据库备份工作流程: aws.amazon.com/blogs/storage/using-amazon-efs-to-cost-optimize-highly-available-durable-database-backup-workflows/
Amazon EFS 特性: aws.amazon.com/efs/features/
AWS 备份: aws.amazon.com/backup/
Amazon EBS 特性: aws.amazon.com/ebs/features/
Amazon FSx 文档: docs.aws.amazon.com/fsx/index.html
Amazon S3 Glacier 存储类别: aws.amazon.com/s3/storage-classes/glacier/

第二部分：应用建模

第二部分 专注于机器学习的高性能计算（HPC）的应用。它包括从分析大量数据开始，然后涵盖分布式训练和大规模部署模型，包括性能优化和边缘机器学习的手动实现。

本部分包括以下章节：

第五章, 数据分析
第六章, 机器学习模型的分布式训练
第七章, 大规模部署机器学习模型
第八章, 优化和管理边缘部署的机器学习模型
第九章, 实时推理的性能优化
第十章, 数据可视化

第五章：数据分析

任何大规模数据科学程序背后的一个基本原理是这样一个简单的事实：任何机器学习（ML）模型产生的质量仅与其训练数据相当。初学者数据科学家常常犯的错误是认为他们只需要找到适合他们用例的正确 ML 模型，然后简单地训练或拟合数据到模型中。然而，事实并非如此。获得最佳模型需要探索数据，目标是完全理解数据。一旦数据科学家理解了数据以及如何在该数据上训练 ML 模型，数据科学家通常会花费大部分时间进一步清理和修改数据，这通常被称为数据整理，以准备模型训练和构建。

虽然这个数据分析任务在概念上可能看起来很简单，但当我们考虑到我们正在探索的数据的类型（图像、文本、表格等）以及数据的数量/体积时，任务会变得更加复杂。此外，数据的存储位置以及获取数据的权限也可能使数据科学家的工作更加困难。例如，有用的机器学习数据可能存储在数据仓库中，或者位于各种关系型数据库中，通常需要各种工具或程序性 API 调用来挖掘正确的数据。同样，关键信息可能分布在多个文件服务器或云对象存储的各个存储桶中。定位数据并确保正确访问数据的权限可能会进一步延迟数据科学家开始工作。

因此，考虑到这些挑战，在本章中，我们将回顾一些实际的方法来探索、理解和本质上处理不同类型，以及大量数据，以训练机器学习模型。此外，我们还将检查 AWS 提供的一些功能和服务，以使这项任务不那么令人畏惧。

因此，本章将涵盖以下主题：

探索数据分析方法
检查 AWS 服务用于数据分析
分析大量结构化和非结构化数据
在 AWS 上大规模处理数据

技术要求

在开始本章之前，您应该具备以下先决条件：

熟悉 AWS 服务及其基本用法。
一个网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）。
一个 AWS 账户（如果您不熟悉如何开始使用 AWS 账户，您可以访问此链接：aws.amazon.com/getting-started/)。
熟悉 AWS 免费层（免费层允许您根据资源限制免费访问一些 AWS 服务。您可以通过此链接了解这些限制：aws.amazon.com/free/)。
本章的示例 Jupyter 笔记本可以在配套的 GitHub 仓库中找到（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter05)。

探索数据分析方法

如本章开头所强调的，收集和探索这些各种数据来源的任务可能显得有些令人畏惧。因此，你可能此时正在想在哪里以及如何开始数据分析过程？为了回答这个问题，让我们探讨一些我们可以用来分析你的数据并为机器学习任务做准备的方法。

收集数据

开始数据分析任务的第一步之一是将来自各个孤岛的相关数据收集到一个特定的位置。这个单一的位置通常被称为数据湖。一旦相关数据被集中到一个单一的数据湖中，在湖中移动数据进出就变得显著更容易。

例如，让我们暂时想象一下，一个数据科学家被分配了一个构建产品推荐模型的任务。利用数据湖作为中心存储，他们可以查询客户数据库以获取所有客户特定的数据，通常来自关系型数据库或数据仓库，然后结合来自 Web 应用程序事务日志的客户点击流数据，以获取预测产品推荐所需的所有信息的共同来源。此外，通过从产品目录中获取产品特定的图像数据，数据科学家可以进一步探索可能增强或有助于机器学习模型预测潜力的产品图像的各种特征。

因此，一旦收集了完整的数据集并将其存储在共同的仓库或数据存储中，我们就可以继续进行数据分析的下一个步骤，即理解数据结构。

理解数据结构

一旦数据被收集到一个共同的位置，在数据科学家能够完全调查如何使用它来提出机器学习假设之前，我们需要了解数据的结构。由于数据集可能来自多个来源，因此在有效分析之前理解数据的结构是很重要的。

例如，如果我们继续以产品推荐为例，数据科学家可能将与来自关系型数据库或数据仓库的表格数据形式的结构化客户数据一起工作。此外，当从 Web 服务器中提取客户交互数据时，数据科学家可能需要处理时间序列或 JSON 格式数据，通常被称为半结构化数据。最后，当将产品图像纳入其中时，数据科学家将处理图像数据，这是非结构化数据的一个例子。

因此，理解数据的本质或结构决定了如何提取我们需要的临界信息并有效地进行分析。此外，了解我们处理的数据类型也将影响所需的工具类型，例如应用程序编程接口（APIs），甚至理解数据所需的基础设施资源。

注意

我们将在本章的后续部分深入探讨这些工具和基础设施资源。

一旦我们理解了数据结构，我们就可以将这种理解应用到数据分析的另一种技术中，即描述数据本身。

描述数据

一旦我们理解了数据结构，我们就可以描述或总结数据的特征，以进一步探索这些特征如何影响我们的整体假设。这种方法通常被称为将描述性统计应用于数据，其中数据科学家将通过总结数据中每个特征的集体属性来尝试描述和理解数据集中的各种特征，这些属性以中心性、变异性和数据计数的形式表示。

让我们探索这些术语的含义，看看它们如何被用来描述数据。

确定中心趋势

通过使用描述性统计来总结数据的中心趋势，我们实际上是在关注数据集中特定特征的分布中的平均、中间或中心位置。这使数据科学家能够了解数据集中某个特征的正常或平均情况，从而允许他们将这些平均值与其他数据特征或整个数据进行比较。

例如，假设客户 A 每天访问我们的网站 10 次，但只购买了一件商品。通过比较客户 A 的平均访问次数与总客户访问次数，我们可以看到客户 A 的排名情况。如果我们再比较购买的商品数量与总商品数量，我们可以进一步衡量基于客户排名的正常情况。

测量变异

使用描述性统计来衡量数据的变异或数据分布情况在机器学习中非常重要。了解数据的分布将使数据科学家能够很好地了解数据是否成比例。例如，在产品推荐用例中，我们有数据表明购买书籍的客户比购买割草机的客户分布更广。在这种情况下，当模型基于这些数据进行训练时，它将倾向于推荐书籍而不是割草机。

计算数据点

不要与数据集大小混淆，数据集计数指的是数据集中单个数据点的数量或数量。总结数据集中每个特征的数据点数量可以进一步帮助数据科学家验证他们是否为每个特征有足够数量的数据点或观测值。拥有足够数量的数据点将进一步帮助证明整体假设。

此外，通过比较每个特征的个别数据点的数量，数据科学家可以确定是否存在任何缺失数据点。由于大多数机器学习算法处理缺失数据的能力不佳，数据科学家可以在数据分析过程中处理这些缺失值，从而在模型训练过程中避免任何不必要的麻烦。

注意

虽然之前展示的描述性技术可以帮助我们理解数据的特征，但还需要一个名为推断统计的独立统计学分支来衡量和理解特征在整个数据集中如何相互作用。当处理大量数据时，这一点尤为重要，如果没有机制来大规模分析大数据集，就需要应用推断技术。

我们都听说过“一图胜千言”的说法。因此，一旦我们充分理解了数据集的特征，另一个重要的数据分析技术就是可视化这些特征。

数据可视化

虽然总结数据的特征为数据科学家提供了有用的信息，但我们实际上是在分析任务中添加更多数据。绘制或图表化这些附加信息可能会揭示数据的一些特征，这些特征在总结和推断统计中可能会被忽略。

例如，使用可视化来理解数据点的方差和分布，数据科学家可能会使用条形图将各种数据点分组到具有相等范围的桶中，以可视化每个桶中数据点的分布。此外，通过使用箱线图，数据科学家可以可视化是否存在任何影响数据整体分布的异常数据点。

根据数据类型和数据集的结构，可以使用许多不同类型的图表和图形来可视化数据。本章的范围不包括深入探讨每种可用的图表类型及其使用方法。然而，可以说数据可视化是探索性数据分析的一个基本方法，用于验证数据质量并帮助数据科学家更熟悉数据集的结构和特征。

审查数据分析生命周期

尽管有许多其他的数据分析方法，我们只涉及了四种，但我们可以在以下步骤中总结整体数据分析方法：

确定需要从数据中回答的用例和问题，以及机器学习模型需要预测的特征。
收集或挖掘数据到一个公共数据存储库中。
探索并描述数据。
可视化数据。
清洗数据并准备用于模型训练，同时考虑任何缺失的数据。
设计新的特征以增强假设并提高机器学习模型的预测能力。
重复上述步骤以确保数据以及机器学习模型满足业务用例。

现在我们已经回顾了一些重要的数据分析方法和分析生命周期，让我们来回顾一下 AWS 提供的一些能力和服务，特别是用于大规模应用这些技术的情况。

查看用于数据分析的 AWS 服务

AWS 提供了多项服务，旨在帮助数据科学家在规模上分析结构化、半结构化或非结构化数据。所有这些服务的一个共同风格是向用户提供选择的灵活性，以便根据用例匹配每个服务的适当方面。有时，用户可能会对选择哪个服务来满足他们的用例感到困惑。

因此，在本节中，我们将把一些 AWS 能力映射到我们在上一节中回顾的方法。

将数据统一到一个公共存储库中

为了满足在公共存储库中存储来自多个来源的相关全球数据集的需求，AWS 提供了 Amazon 简单存储服务（S3）对象存储服务，允许用户在存储桶中将结构化、半结构化和非结构化数据作为对象存储。

备注

如果你不太熟悉 S3 服务，它的运作方式以及如何使用它，你可以在此处查看 S3 产品页面：aws.amazon.com/s3/。

因此，S3 是创建数据湖的最佳位置，因为它具有无与伦比的安全性、可用性和可伸缩性。顺便提一下，S3 还提供了多种额外的资源，以便将数据引入存储库。

然而，设置和管理数据湖可能既耗时又复杂，根据您的需求，设置可能需要几周时间。通常需要从多个不同的来源加载数据，设置分区，启用加密，并提供可审计的访问。随后，AWS 提供了 AWS Lake Formation（aws.amazon.com/lake-formation）服务，只需几天即可构建安全的数据湖。

创建用于分析的数据结构

如前所述，了解我们数据的基础结构对于提取分析所需的关键信息至关重要。因此，一旦我们的数据存储在 S3 中，我们就可以使用Amazon Athena (aws.amazon.com/athena)通过结构化查询语言（SQL）进行查询，或者使用Amazon EMR (aws.amazon.com/emr/)来分析大规模数据，使用开源工具，如Apache Spark (spark.apache.org/)和PySpark (spark.apache.org/docs/latest/api/python/index.html?highlight=pyspark) Python 接口。让我们通过从 Amazon Athena 的概述开始进一步探索这些分析服务。

检查 Amazon Athena

Athena 使得定义模式变得容易，这是一种数据结构的概念性设计，并使用 SQL 在 S3 中查询结构化或半结构化数据，这使得数据科学家能够轻松地获取分析大型数据集所需的关键信息。

Athena 的一个关键方面是它实际上是无服务器的。这对数据科学家来说非常重要，因为不需要构建和管理基础设施资源。这意味着数据科学家可以立即开始他们的分析任务，而无需依赖平台或基础设施团队来开发和构建分析架构。

然而，执行 SQL 查询的技能可能或可能不在数据科学家的技能范围内，因为大多数从业者更熟悉 Python 数据分析工具，例如pandas (pandas.pydata.org/)。这正是 Spark 和 EMR 发挥作用的地方。让我们回顾一下 Amazon EMR 如何提供帮助。

检查 Amazon EMR

Amazon EMR或弹性 MapReduce本质上是由 AWS 提供的一种托管基础设施，您可以在其上运行 Apache Spark。由于它是一种托管服务，EMR 允许基础设施团队轻松配置、管理和自动扩展大型 Spark 集群，使数据科学家能够使用他们熟悉的工具在数据上运行 PB 级规模的统计分析。

在利用 EMR 和 Spark 进行数据分析时，有两个关键点需要注意。首先，与 Athena 不同，EMR 不是无服务器架构，需要基础设施团队来配置和管理一组 EMR 节点。虽然使用 EMR 时这些任务已经自动化，配置一个集群大约需要 15 到 20 分钟，但事实仍然如此，这些基础设施资源在数据科学家可以利用它们之前需要先进行搭建。

其次，EMR 与 Spark 结合使用弹性分布式数据集（RDDs）(spark.apache.org/docs/3.2.1/rdd-programming-guide.html#resilient-distributed-datasets-rdds)，通过缓解使用 pandas 时通常施加的内存限制，来执行 PB 级数据分析。本质上，这允许数据科学家对整个数据集进行分析任务，而不是提取足够小的样本以适应内存，在所述样本上执行描述性分析任务，然后将分析推断回全局人口。能够在单步中执行对全部数据的分析可以显著减少数据科学家描述和理解数据所需的时间。

在大规模上可视化数据

对于数据科学家来说，处理和分析大规模数据集已经足够复杂，而使用程序化可视化库，如 Matplotlib (matplotlib.org/) 和 Seaborn (https://seaborn.pydata.org/) )，则进一步增加了分析任务的复杂性。

因此，为了帮助数据科学家可视化数据、获得额外的洞察力以及执行描述性和推断性统计，AWS 提供了Amazon QuickSight (aws.amazon.com/quicksight/)服务。QuickSight 允许数据科学家连接到其 S3 上的数据以及其他数据源，以创建交互式图表和图形。

此外，利用 QuickSight 进行数据可视化任务不需要数据科学家依赖他们的基础设施团队来提供资源，因为 QuickSight 也是无服务器的。

选择正确的 AWS 服务

如您所想，AWS 为大规模数据分析提供了许多更多服务和功能，其中 S3、Athena 和 QuickSight 只是专注于数据分析任务的更常见技术中的少数几种。选择正确的功能取决于用例，可能需要集成其他基础设施资源。从这个对这些服务的简要介绍中，我们可以得出的关键结论是，在可能的情况下，数据科学家不应该因为不得不管理数据分析这一复杂任务之外的资源而遭受损失。

因此，从数据科学家或机器学习实践者的角度来看，AWS 提供了一个专门的服务，该服务具有专门针对常见机器学习任务的Amazon SageMaker (aws.amazon.com/sagemaker/)功能。

因此，在下一节中，我们将展示 SageMaker 如何帮助分析大规模数据，以便数据科学家无需亲自管理或依赖基础设施团队来管理资源。

分析大量结构化和非结构化数据

到目前为止，我们已经回顾了一些典型的大规模数据分析方法，并介绍了一些专注于简化用户分析任务的 AWS 服务。在本节中，我们将实际介绍 Amazon SageMaker 作为一项综合服务，它允许新手和经验丰富的 ML 实践者执行这些数据分析任务。

虽然 SageMaker 是 AWS 提供的完全托管的基础设施，包括满足 ML 流程每个步骤的工具和工作流程，但它还提供了一个专门用于 ML 开发的完全集成开发环境（IDE），称为Amazon SageMaker Studio（aws.amazon.com/sagemaker/studio/）。SageMaker Studio 为数据科学家提供开发、管理和查看 ML 生命周期每个部分的能力，包括探索性数据分析。

但是，在我们进行一个实际示例之前，该示例展示了如何使用 Studio 进行大规模数据分析，我们需要配置一个 SageMaker 域。SageMaker Studio 域包括一组授权的数据科学家、预构建的数据科学工具和安全防护栏。在域内，这些用户可以共享访问 AWS 分析服务、ML 实验数据、可视化和 Jupyter 笔记本。

让我们开始吧。

设置 EMR 和 SageMaker Studio

我们将使用一个 AWS CloudFormation（aws.amazon.com/cloudformation/）模板来完成以下任务：

启动 SageMaker Studio 域以及一个 studio-user
创建一个未启用身份验证的标准 EMR 集群，包括所需的其它基础设施，如虚拟私有云（VPC）、子网和其他资源

注意

当您启动此 CloudFormation 模板时，您将产生 EMR 的费用。因此，请确保参考章节末尾的清理部分。

我们在书中使用的 CloudFormation 模板最初取自 aws-ml-blog.s3.amazonaws.com/artifacts/sma-milestone1/template_no_auth.yaml，并已修改以运行书中提供的代码。

要开始启动 CloudFormation 模板，请使用您的 AWS 账户执行以下步骤：

登录您的 AWS 账户并打开 SageMaker 管理控制台（console.aws.amazon.com/sagemaker/home），最好是以管理员用户身份。如果您没有管理员用户访问权限，请确保您有创建 EMR 集群、Amazon SageMaker Studio 和 S3 的权限。您可以参考所需权限（docs.aws.amazon.com/sagemaker/latest/dg/studio-notebooks-emr-required-permissions.html）以获取所需权限的详细信息。
前往 S3 桶，上传 GitHub 仓库中 S3 文件夹的内容。转到 templates 文件夹，点击 template_no_auth.yaml，并复制 对象 URL。
确保您在 S3 桶中 artifacts 文件夹与 templates 文件夹平行。
搜索 CloudFormation 服务并点击它。
一旦进入 CloudFormation 控制台，点击如图 图 5.1* 所示的 创建堆栈 橙色按钮：

图 5.1 – AWS CloudFormation 控制台

在 指定模板 部分，选择 Amazon S3 URL 作为 模板源 并输入 步骤 2 中注明的 Amazon S3 URL，如图 图 5.2* 所示，然后点击 下一步 按钮：

图 5.2 – 创建堆栈

输入您选择的堆栈名称，然后点击 下一步 按钮。
在 配置堆栈选项 页面上，保持默认设置，然后点击页面底部的 下一步 按钮。
在审查页面上，滚动到屏幕底部，点击 我承认 AWS CloudFormation 可能会使用自定义名称创建 IAM 资源 复选框，然后点击 创建堆栈 按钮，如图 图 5.3* 所示：

图 5.3 – 审查堆栈

注意

CloudFormation 模板启动需要 5-10 分钟。

一旦启动，前往 Amazon SageMaker，点击 SageMaker Studio，您将看到为您配置的 SageMaker 域 和 studio-user，如图 图 5.4* 所示：

图 5.4 – SageMaker 域

点击 studio-user 旁边的 启动应用程序 下拉菜单，选择 Studio，如图所示的先前的屏幕截图。之后，您将看到一个全新的 JupyterLab 界面 (jupyterlab.readthedocs.io/en/latest/user/interface.html)。

注意

建议您通过查看 Amazon SageMaker Studio UI 文档 (docs.aws.amazon.com/sagemaker/latest/dg/studio-ui.html) 来熟悉 Studio UI，因为我们将在本章中引用许多 SageMaker 特定的小部件和视图。

为了使使用 Studio UI 运行书中的各种示例更容易，我们将从配套的 GitHub 仓库克隆源代码。在 Studio UI 中，点击左侧侧边栏中的 Git 图标，一旦资源面板打开，点击 克隆仓库 按钮，以启动 克隆仓库 对话框，如图 图 5.5* 所示：

图 5.5 – 克隆仓库

输入配套仓库的 URL (github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS.git) 并点击 CLONE 按钮。
克隆的仓库现在将出现在 Applied-Machine-Learning-and-High-Performance-Computing-on-AWS 文件夹中，以便展开。
然后双击 Chapter05 文件夹以打开它进行浏览。

我们现在可以使用 SageMaker Studio 分析大量结构化数据。然而，在我们开始分析之前，我们需要获取数据。让我们看看如何做到这一点。

分析大量结构化数据

由于本节的目标是提供一个分析大规模结构化数据的动手示例，我们的第一个任务将是合成大量数据。使用 Studio UI，执行以下步骤：

使用左侧的1_data_generator.ipynb文件启动 Jupyter 笔记本。
当出现 设置笔记本环境 对话框时，请确保从图像下拉菜单中选择 数据科学，以及内核选项中的 Python 3。*图 5**.6 展示了对话框的示例：

图 5.6 – 设置笔记本环境

设置好这些选项后，点击选择按钮继续。
接下来，你应该会看到一个 启动笔记本内核… 消息。笔记本内核需要几分钟来加载。
笔记本加载完成后，通过点击内核菜单并选择 重启内核并运行所有单元格… 选项来运行笔记本。

笔记本执行完所有代码单元格后，我们可以深入了解笔记本做了什么，从检查数据集开始。

检查数据集

我们将在本例中使用的数据集是加利福尼亚住房数据集 (www.dcc.fc.up.pt/~ltorgo/Regression/cal_housing.html)。这个数据集是从 1990 年美国人口普查中得出的，每个普查区块组一行。区块组是美国人口普查局发布样本数据的最小地理单位。一个区块组通常有 600 到 3,000 的人口。

数据集被纳入 sklearn Python 库 (scikit-learn.org/stable/index.html)。scikit-learn 库包括一个数据集模块，允许我们从 StatLib 数据集存档（http://lib.stat.cmu.edu/datasets/）下载流行的参考数据集，例如加利福尼亚住房数据集。

数据集引用

Pace, R. Kelley, 和 Ronald Barry，稀疏空间自回归，统计学与概率通讯，33 (1997) 291-297。

一个需要注意的关键点是，这个数据集只有 20,640 个样本，大小约为 400 KB。所以，我相信您会同意这并不完全符合大量结构化数据的定义。因此，我们刚刚执行的笔记本的主要目标是使用这个数据集作为合成大量结构化数据的基础，然后将这个新数据集存储在 S3 上进行分析。

让我们通过代码来查看这是如何完成的。

安装 Python 库

笔记本中的前五个代码单元用于安装和升级必要的 Python 库，以确保我们有 SageMaker SDK、scikit-learn 和合成数据仓库的正确版本。以下代码片段展示了这五个代码单元的合并：

...
import sys
!{sys.executable} -m pip install "sagemaker>=2.51.0"
!{sys.executable} -m pip install --upgrade -q "scikit-learn"
!{sys.executable} -m pip install "sdv"
import sklearn
sklearn.__version__
import sdv
sdv.__version__
...

注意

我们升级和安装 SageMaker 和 scikit-learn 库没有特定的原因，只是为了确保本章示例的一致性。

一旦安装了所需的库，我们就加载它们并配置全局变量。以下代码片段展示了我们如何导入库并配置 SageMaker 默认的 S3 存储桶参数：

...
import os
from sklearn.datasets import fetch_california_housing
import time
import boto3
import numpy as np
import pandas as pd
from sklearn.model_selection import train_test_split
import sagemaker
from sagemaker import get_execution_role
prefix = 'california_housing'
role = get_execution_role()
bucket = sagemaker.Session(boto3.Session()).default_bucket()
...

然而，在我们能够合成更大的数据集并将其上传到 S3 之前，我们需要下载加利福尼亚住房数据集。如您从以下代码片段中可以看到，我们创建了两个本地文件夹data和raw，然后使用sklearn.datasets中的fetch_california_housing()方法下载数据。结果数据变量使我们能够描述数据，以及将数据本身作为二维数据结构df_data捕获：

...
data_dir = os.path.join(os.getcwd(), "data")
os.makedirs(data_dir, exist_ok=True)
raw_dir = os.path.join(os.getcwd(), "data/raw")
os.makedirs(raw_dir, exist_ok=True)
data = fetch_california_housing(data_home=raw_dir, download_if_missing=True, return_X_y=False, as_frame=True)
...
df_data = data.data
...

df_data变量是我们结构化数据的必要表示，列显示数据标签，行显示每个标签的观测或记录。将这种结构想象成类似于电子表格或关系表。

使用df_data变量，我们进一步描述这种结构，并执行本章“探索数据分析方法”部分中描述的一些描述性统计和可视化。例如，以下代码片段展示了如何描述我们正在处理的数据类型。您会记得，理解数据类型对于欣赏数据的整体模式或结构至关重要：

...
df_data.astype({'Population': 'int32'}).dtypes
...

此外，我们可以定义一个名为plot_boxplot()的 Python 函数来可视化df_data变量中包含的数据。您会记得，可视化数据可以提供对数据的进一步了解。例如，您可以从下一个代码片段中看到，我们可以可视化房屋的平均房间数或avgNumrooms的整体分布：

...
import matplotlib.pyplot as plt
def plot_boxplot(data, title):
    plt.figure(figsize =(5, 4))
    plt.boxplot(data)
    plt.title(title)
    plt.show()
...
df_data.drop(df_data[df_data['avgNumRooms'] > 9].index, inplace = True)
df_data.drop(df_data[df_data['avgNumRooms'] <= 1].index, inplace = True)
plot_boxplot(df_data.avgNumRooms, 'rooms')
...

如我们从图 5.7.7 中可以看到，代码生成的箱线图表明加利福尼亚住房数据的平均房间数为5：

图 5.7 – 房间平均数量

此外，你还会注意到在图 5.7中，数据的上限和下限之间有一种某种程度的均匀分布。这表明我们有一个很好的数据分布，对于平均卧室数量来说，因此，我们不需要增强这个数据点。

最后，你可能还记得在计数数据点部分，我们可以通过确定数据中是否存在缺失值来避免模型训练过程中的任何不必要的麻烦。例如，下一个代码片段展示了我们如何查看df_data变量中任何缺失值的总和：

...
df_data.isna().sum()
...

虽然我们只介绍了几种分析方法来展示分析生命周期，但从中可以得出的一个关键结论是，由于数据量足够小，可以放入内存中，因此数据很容易分析。所以，作为数据科学家，我们不需要捕获全球人口的样本来分析数据，然后再将分析结果推断回更大的数据集。让我们看看当我们合成一个更大的数据集时，这个结论是否仍然成立。

合成大量数据

笔记本的最后部分涉及使用合成数据仓库(sdv.dev/SDV/index.html)，或sdv Python 库。这个 Python 库生态系统使用专门关注从结构化表格和时间序列数据集学习以及创建与原始数据集具有相同格式、统计属性和结构的合成数据的 ML 模型。

在我们的示例笔记本中，我们使用一个 TVAE（arxiv.org/abs/1907.00503）模型来生成加利福尼亚住房数据的一个更大版本。例如，以下代码片段展示了我们如何在df_data变量上定义和训练一个 TVAE 模型：

...
from sdv.tabular import TVAE
model = TVAE(rounding=2)
model.fit(df_data)
model_dir = os.path.join(os.getcwd(), "model")
os.makedirs(model_dir, exist_ok=True)
model.save(f'{model_dir}/tvae_model.pkl')
...

一旦我们训练了模型，我们就可以将其加载到synthetic_data变量中，生成一百万个新的观测值或行。以下代码片段展示了这个例子：

...
from sdv.tabular import TVAE
model = TVAE.load(f'{model_dir}/tvae_model.pkl')
synthetic_data = model.sample(1000000)
...

最后，正如所示，我们使用以下代码片段来压缩数据，并利用 SageMaker SDK 的upload_data()方法将数据存储在 S3 中：

...
sess = boto3.Session()
sagemaker_session = sagemaker.Session(boto_session=sess)
synthetic_data.to_parquet('data/raw/data.parquet.gzip', compression='gzip')
rawdata_s3_prefix = "{}/data/raw".format(prefix)
raw_s3 = sagemaker_session.upload_data(path="./data/raw/data.parquet.gzip", key_prefix=rawdata_s3_prefix)
...

在 S3 中存储了 100 万行数据集后，我们终于有一个大量结构化数据的例子。现在我们可以使用这些数据来展示如何使用 Amazon EMR 在结构化数据上大规模利用突出显示的分析方法。

使用 EMR 集群和 SageMaker Studio 分析大规模数据

要开始分析我们刚刚创建的大规模合成数据集，我们可以在 Studio UI 中执行以下步骤：

使用左侧导航面板，双击2_data_exploration_spark.ipynb笔记本以启动它。
正如我们通过前面的示例所看到的，当出现设置笔记本环境对话框时，选择SparkMagic作为图像，并将PySpark作为内核。
一旦笔记本准备就绪，点击内核菜单选项，然后再次选择重启内核并运行所有单元格…选项以执行整个笔记本。

当笔记本正在运行时，我们可以开始审查我们在各个代码单元格中试图完成的事情。正如您从第一个代码单元格中可以看到的，我们连接到在设置 EMR 和 SageMaker 工作室部分配置的 EMR 集群：

%load_ext sagemaker_studio_analytics_extension.magics
%sm_analytics emr connect --cluster-id <EMR Cluster ID> --auth-type None

在下一个代码单元格中，以下代码显示了从 S3 读取合成的数据集。我们在这里创建一个housing_data变量，使用 PySpark 的sqlContext方法从 S3 读取原始数据：

housing_data=sqlContext.read.parquet('s3://<SageMaker Default Bucket>/california_housing/data/raw/data.parquet.gzip')

一旦我们分配了这个变量，我们就可以使用 PySpark 和 EMR 集群在数据的整个总体上执行各种数据分析任务，而无需摄入用于分析的样本数据集。

虽然笔记本提供了针对数据的多种特定分析方法的示例，但我们将重点关注与我们已经在原始加利福尼亚住房数据集上进行的探索相关的少数示例，以说明这些相同的方法如何在大规模上应用。

复习数据结构和计数

正如已经提到的，了解数据的类型、结构和计数是分析的重要部分。为了在整个housing_data上执行此分析，我们可以执行以下代码：

print((housing_data.count(), len(housing_data.columns)))
housing_data.printSchema()

执行此代码会产生以下输出，其中我们可以看到我们有 100 万个观测值，以及每个特征的类型：

(1000000, 9)
Root
|-- medianIncome: double (nullable = true)
|-- medianHousingAge: double (nullable = true)
|-- avgNumRooms: double (nullable = true)
|-- avgNumBedrooms: double (nullable = true)
|-- population: double (nullable = true)
|-- avgHouseholdMembers: double (nullable = true)
|-- latitude: double (nullable = true)
|-- longitude: double (nullable = true)
|-- medianHouseValue: double (nullable = true)

接下来，我们可以确定是否存在任何缺失值以及如何处理它们。

处理缺失值

您会记得，确保没有缺失值是任何数据分析的重要方法。为了暴露任何缺失数据，我们可以运行以下代码来创建每个列或特征中缺失值的计数：

from pyspark.sql.functions import isnan, when, count, col
housing_data.select([count(when(isnan(c), c)).alias(c) for c in housing_data.columns]).show()

如果我们确实发现任何缺失值，我们可以使用多种技术来处理它们。例如，我们可以使用dropna()方法在housing_data变量上删除包含缺失值的行。或者，根据缺失值的数量，我们可以使用插补技术根据特征的均值或中位数推断一个值。

分析数据的中心性和变异性

记住，了解数据的分布情况将给我们一个很好的想法，了解数据是否成比例。这项分析任务还提供了一个想法，即我们数据中是否有异常值扭曲了分布或扩散。之前已经强调，使用条形图和箱线图可视化数据分布可以进一步帮助确定数据的变异性。

为了适应这项任务，以下代码突出显示了一个捕获我们希望分析的特征并绘制其分布作为条形图的示例：

import matplotlib.pyplot as plt
df = housing_data.select('avgNumRooms', 'avgNumBedrooms', 'population').toPandas()
df.hist(figsize=(10, 8), bins=20, edgecolor="black")
plt.subplots_adjust(hspace=0.3, wspace=0.5)
plt.show()
%matplot plt

在对大量数据进行代码执行后，我们可以在 图 5.8 中看到平均房间数量 (avgNumRooms)、平均卧室数量 (avgNumBedrooms) 和区块人口 (population) 特征的结果分布示例：

图 5.8 – 特征分布

如您从 图 5.8 中所见，avgNumBedrooms 和 population 特征都没有围绕均值或平均特征值进行中心化。此外，avgNumBedrooms 特征的分布显著偏向光谱的较低端。这个因素可能表明存在潜在的异常值或过多的数据点集中在 avgNumBedrooms 特征之间：

plot_boxplot(df.avgNumBedrooms, 'Boxplot for Average Number of Bedrooms')
%matplot plt

执行此代码单元格的结果箱线图显示在 图 5.9 中：

图 5.9 – 房间平均数量的箱线图

图 5.9 清楚地显示了导致数据偏斜的多个异常值。因此，我们需要在数据分析和在大型数据集上训练机器学习模型之前解决这些差异。以下代码片段展示了如何从箱线图中查询数据，然后简单地删除它，以创建一个名为 housing_df_with_no_outliers 的变量：

import pyspark.sql.functions as f
columns = ['avgNumRooms', 'avgNumBedrooms', 'population']
housing_df_with_no_outliers = housing_data.where(
    (housing_data.avgNumRooms<= 8) &
    (housing_data.avgNumRooms>=2) &
    (housing_data.avgNumBedrooms<=1.12) &
    (housing_data.population<=1500) &
    (housing_data.population>=250))

一旦我们有了 housing_df_with_no_outliers，我们可以使用以下代码创建 avgNumBedrooms 特征变异性的新箱线图：

df = housing_df_with_no_outliers.select('avgNumRooms', 'avgNumBedrooms', 'population').toPandas()
plot_boxplot(df.avgNumBedrooms, 'Boxplot for Average Number of Bedrooms')
%matplot plt

图 5.10 展示了执行此代码后生成的箱线图示例：

图 5.10 – 房间平均数量的箱线图

从 图 5.10 中，我们可以清楚地看到已经移除了异常值。随后，我们可以在 avgNumRooms 和 population 特征上执行类似的程序。

虽然这些例子只展示了数据分析生命周期中突出的一些重要方法，但从这个练习中我们可以得到的一个重要启示是，由于集成了 SageMaker Studio 和 EMR，我们能够在大规模结构化数据上完成数据分析任务，而无需捕获全球人口的样本，然后再将分析推断回更大的数据集。然而，在分析大规模数据的同时，我们还需要确保任何预处理任务也能在大规模上执行。

接下来，我们将回顾如何使用 SageMaker 自动化这些预处理任务的大规模执行。

大规模预处理数据

SageMaker 服务通过其核心组件之一 preprocess.py 来处理数据转换或预处理任务的重负载和扩展。

以下代码片段展示了如何将删除异常值的代码转换为 Python 脚本：

%%writefile preprocess.py
...
def main():
    parser = argparse.ArgumentParser(description="app inputs and outputs")
    parser.add_argument("--bucket", type=str, help="s3 input bucket")
    parser.add_argument("--s3_input_prefix", type=str, help="s3 input key prefix")
    parser.add_argument("--s3_output_prefix", type=str, help="s3 output key prefix")
    args = parser.parse_args()
    spark = SparkSession.builder.appName("PySparkApp").getOrCreate()
    housing_data=spark.read.parquet(f's3://{args.bucket}/{args.s3_input_prefix}/data.parquet.gzip')
    housing_df_with_no_outliers = housing_data.where((housing_data.avgNumRooms<= 8) &
                   (housing_data.avgNumRooms>=2) &
                   (housing_data.avgNumBedrooms<=1.12) &
                    (housing_data.population<=1500) &
                    (housing_data.population>=250))
    (train_df, validation_df) = housing_df_with_no_outliers.randomSplit([0.8, 0.2])
    train_df.write.parquet("s3://" + os.path.join(args.bucket, args.s3_output_prefix, "train/"))
    validation_df.write.parquet("s3://" + os.path.join(args.bucket, args.s3_output_prefix, "validation/"))
if __name__ == "__main__":
    main()
...

一旦创建了 Python 脚本，我们可以加载适当的 SageMaker SDK 库，并配置输入数据以及转换后的输出数据的 S3 位置，如下所示：

%local
import sagemaker
from time import gmtime, strftime
sagemaker_session = sagemaker.Session()
role = sagemaker.get_execution_role()
bucket = sagemaker_session.default_bucket()
timestamp = strftime("%Y-%m-%d-%H-%M-%S", gmtime())
prefix = "california_housing/data_" + timestamp
s3_input_prefix = "california_housing/data/raw"
s3_output_prefix = prefix + "/data/spark/processed"

最后，我们可以创建 SageMaker PySparkProcessor()类的实例，作为spark_processor变量，如下代码所示：

%local
from sagemaker.spark.processing import PySparkProcessor
spark_processor = PySparkProcessor(
    base_job_name="sm-spark",
    framework_version="2.4",
    role=role,
    instance_count=2,
    instance_type="ml.m5.xlarge",
    max_runtime_in_seconds=1200,
)

定义了spark_processor变量后，我们可以调用run()方法来执行 SageMaker Processing 作业。以下代码演示了如何调用run()方法，并附带preprocess.py脚本以及数据输入和输出位置的arguments：

spark_processor.run(
    submit_app="preprocess.py",
    arguments=[
        "--bucket",
        bucket,
        "--s3_input_prefix",
        s3_input_prefix,
        "--s3_output_prefix",
        s3_output_prefix,
    ],
)

在后台，SageMaker 将创建一个临时的 Spark 集群，并在输入数据上执行preprocess.py脚本。一旦数据转换完成，SageMaker 将把结果数据集存储在 S3 上，然后解散 Spark 集群，同时将执行日志输出重定向回 Jupyter 笔记本。

虽然这种技术使得分析大量结构化数据的复杂任务更容易扩展，但仍然存在如何在非结构化数据上执行类似过程的问题。

让我们回顾一下如何解决这个问题。

分析大量非结构化数据

在本节中，我们将使用从laurencemoroney.com/datasets.html下载的非结构化数据（马和人类图像）进行操作。这个数据集可以用来训练一个二进制图像分类模型，以在图像中区分马和人类。从 SageMaker Studio 启动3_unstructured_data_s3.ipynb笔记本，从图像下拉菜单中选择PyTorch 1.8 Python 3.6 CPU Optimized，以及Python 3作为内核选项。一旦笔记本打开，重启内核并运行如使用 SageMaker Studio 分析大规模数据部分中提到的所有单元格。

笔记本执行完所有代码单元格后，我们可以深入了解笔记本具体做了什么。

如笔记本中所示，我们首先从storage.googleapis.com/laurencemoroney-blog.appspot.com/horse-or-human.zip下载马或人类数据，然后解压文件。

一旦我们有了数据，我们将使用super-image库将图像转换为高分辨率：

我们将首先下载具有scale = 4的预训练模型，这意味着我们打算将图像的分辨率提高四倍，如下代码块所示：

from super_image import EdsrModel, ImageLoader

from PIL import Image

import requests

model = EdsrModel.from_pretrained('eugenesiow/edsr-base', scale=4)

接下来，我们将遍历包含图像的文件夹，使用预训练模型将每个图像转换为高分辨率，并保存，如下面的代码块所示：

import os

from os import listdir

folder_dir = "horse-or-human/"

for folder in os.listdir(folder_dir):

    folder_path = f'{folder_dir}{folder}'

    for image_file in os.listdir(folder_path):

        path = f'{folder_path}/{image_file}'

        image = Image.open(path)

        inputs = ImageLoader.load_image(image)

        preds = model(inputs)

        ImageLoader.save_image(preds, path)

您可以通过检查其中一张图像的文件大小来确认图像已被转换为高分辨率。一旦图像被转换为高分辨率，您可以可选地复制图像以增加文件数量，最后将它们上传到 S3 桶。我们将使用上传到 S3 桶的图像来运行 SageMaker 训练作业。

注意

在本例中，我们将向您展示如何使用 SageMaker 训练功能，通过存储在 S3 桶中的数据运行一个PyTorch训练作业。您也可以选择使用其他框架，例如也由 SageMaker 支持的TensorFlow和MXNet。

为了使用 PyTorch，我们首先导入sagemaker.pytorch模块，使用它我们将定义SageMaker PyTorch Estimator，如下面的代码块所示：

from sagemaker.pytorch import PyTorch
estimator = PyTorch(entry_point='train.py',
                    source_dir='src',
                    role=role,
                    instance_count=1,
                    instance_type='ml.g4dn.8xlarge',
                    framework_version='1.8.0',
                    py_version='py3',
                    sagemaker_session=sagemaker_session,
                    hyperparameters={'epochs':5,
                                     'subset':2100,
                                     'num_workers':4,
                                     'batch_size':500},
                   )

在估计器对象中，如代码片段所示，我们需要提供配置参数。在这种情况下，我们需要定义以下参数：

instance_count: 这是实例数量
instance_type: 这是训练作业将启动的实例类型
framework_version: 这是用于训练的 PyTorch 框架版本
py_version: 这是 Python 版本
source_dir: 这是笔记本中的文件夹路径，其中包含训练脚本
entry_point: 这是 Python 训练脚本的名称
hyperparameters: 这是训练脚本将使用的超参数列表

一旦我们定义了 PyTorch 估计器，我们将定义TrainingInput对象，它将输入数据的 S3 位置、内容类型和输入模式作为参数，如下面的代码所示：

from sagemaker.inputs import TrainingInput
train = TrainingInput(s3_input_data,content_type='image/png',input_mode='File')

input_mode参数可以取以下值；在我们的情况下，我们使用File值：

None: Amazon SageMaker 将使用基础Estimator类中指定的输入模式
File: Amazon SageMaker 将训练数据集从 S3 位置复制到本地目录
Pipe: Amazon SageMaker 通过Unix 命名管道直接从 S3 流数据到容器
FastFile: Amazon SageMaker 在训练开始前按需从 S3 流式传输数据，而不是下载整个数据集

注意

您可以通过此链接查看 PyTorch 估计器的完整参数列表：sagemaker.readthedocs.io/en/stable/frameworks/pytorch/sagemaker.pytorch.html.

一旦我们配置了 PyTorch Estimator和TrainingInput对象，我们现在就可以开始训练作业，如下面的代码所示：

estimator.fit({'train':train})

当我们运行estimator.fit时，它将启动一个ml.g4dn.8xlarge类型的训练实例，安装PyTorch 1.8容器，将训练数据从S3 位置和train.py脚本复制到训练实例的本地目录，并最终运行你在估计器配置中提供的训练脚本。一旦训练作业完成，SageMaker 将自动终止它启动的所有资源，你只需为训练作业运行的时间付费。

在这个例子中，我们使用了一个简单的训练脚本，该脚本涉及使用 PyTorch DataLoader 对象加载数据并遍历图像。在下一节中，我们将看到如何使用 AWS 进行大规模数据处理。

在 AWS 上大规模处理数据

在上一节分析大量非结构化数据中，数据存储在 S3 存储桶中，用于训练。在有些情况下，你需要更快地加载数据进行训练，而不是等待训练作业将数据从 S3 本地复制到训练实例。在这些情况下，你可以将数据存储在文件系统上，例如3_unstructured_data.ipynb笔记本。请参阅笔记本中的使用 EFS 上的数据优化和使用 FSX 上的数据优化部分。

注意

在运行template_filesystems.yaml模板之前，以与我们在设置 EMR 和 SageMaker Studio部分所做的方式类似。

清理

让我们终止在设置 EMR 和 SageMaker Studio部分启动的 EMR 集群，因为它在本书的后续章节中不会被使用。

首先，让我们登录 AWS 控制台并按照这里给出的步骤操作：

在 AWS 控制台中搜索EMR。
你将看到活动的EMR-Cluster-sm-emr集群。选择 EMR 集群名称旁边的复选框，然后点击终止按钮，如图图 5.11*所示：

图 5.11 – EMR 集群列表

在弹出的窗口中点击红色终止按钮，如图图 5.12*所示：

图 5.12 – 终止 EMR 集群

终止 EMR 集群可能需要几分钟，一旦完成，状态将变为已终止。

让我们总结一下本章学到的内容。

摘要

在本章中，我们探讨了各种数据分析方法，回顾了一些 AWS 数据分析服务，并启动了一个 CloudFormation 模板来创建 EMR 集群、SageMaker Studio 域和其他有用的资源。然后我们深入研究了分析结构化和非结构化数据的代码，并提出了一些优化其性能的方法。这将帮助你为训练机器学习模型准备数据。

在下一章中，我们将看到如何以分布式的方式在大量数据上训练大型模型，以加快训练过程。

第六章：分布式训练机器学习模型

当涉及到 机器学习（ML）模型训练时，数据科学家或 ML 实践者的主要目标是根据相关数据训练出最优模型，以解决业务用例。虽然这个目标是首要的，但最佳方案是以尽可能快和有效的方式完成这项任务。那么，我们如何加快模型训练速度呢？ 此外，有时数据或模型可能太大，无法适应单个 GPU 内存。*那么我们如何防止内存不足（OOM）错误呢？

这个问题的最简单答案就是向问题投入更多的计算资源，换句话说，更多的 CPU 和 GPU。这本质上是在使用更大的计算硬件，通常被称为扩展策略。然而，服务器中可以挤入的 CPU 和 GPU 数量是有限的。因此，有时需要扩展策略，即向混合中添加更多服务器，本质上是在多个物理计算资源之间分配工作负载。

尽管如此，将模型训练工作负载分散到更多的 CPU 或 GPU，甚至分散到更多的计算服务器上，肯定会加快整体训练过程。利用扩展、扩展或两种策略的组合也会给模型训练活动的整体编排和配置增加更多的复杂性。因此，本章将帮助您应对这些挑战，通过涵盖以下主题来帮助克服分布式训练过程带来的额外复杂性：

使用 AWS 构建 ML 系统
介绍分布式训练的基本原理
在 AWS 上执行分布式训练工作负载

技术要求

在开始本章之前，您应该具备以下先决条件：

网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）
访问您在 第五章，数据分析 中使用的 AWS 账户
AWS 账户（如果您不熟悉如何开始使用 AWS 账户，您可以访问此链接 aws.amazon.com/getting-started/）
访问我们在 第五章，数据分析 中创建的 SageMaker Studio 开发环境
本章的示例 Jupyter 笔记本提供在配套 GitHub 仓库中 (github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter06))

使用 AWS 构建 ML 系统

在我们探索如何实现一开始就强调的分布式训练策略的基本原理之前，我们首先需要统一认识，了解如何在 AWS 平台上执行 ML 模型训练练习。一旦我们了解了 AWS 如何处理模型训练，我们就可以进一步扩展这个概念来讨论分布式训练的概念。

为了帮助 ML 从业者构建 ML 系统，AWS 提供了 SageMaker (aws.amazon.com/sagemaker/) 服务。虽然 SageMaker 是一个单一的 AWS 服务，但它由多个模块组成，这些模块专门对应于 ML 任务。例如，SageMaker 提供了专门用于处理模型训练任务的重负载和扩展的训练作业组件。ML 从业者可以使用 SageMaker 训练作业来基本提供临时的计算环境或集群来处理模型训练任务。本质上，ML 从业者需要做的只是指定一些配置参数，SageMaker 训练作业就会处理其余的工作。例如，我们需要提供以下四个基本参数：

包含模型训练、测试，以及可选的验证数据的 S3 存储桶的 URL。
执行模型训练任务所需的 ML 计算实例的类型和数量。
存储训练好的模型的 S3 存储桶的位置。
存储模型训练代码的位置，无论是本地还是 S3。

以下代码片段展示了如何将这些四个基本要求正式化成一个 SageMaker 训练作业请求是多么简单：

...
from sagemaker.pytorch import PyTorch
estimator = PyTorch(entry_point='train.py',
                    source_dir='src',
                    role=role,
                    instance_count=1,
                    instance_type='ml.p3.2xlarge',
                    framework_version='1.8.0',
                    py_version='py3',
                    sagemaker_session=sagemaker_session,
                    hyperparameters={'epochs':10,
                                     'batch_size':32,
                                     'lr':3e-5,
                                     'gamma': 0.7},
                   )
...

使用这个代码片段，我们基本上告诉 SageMaker 我们想要使用内置的 PyTorch 估计器，通过声明使用 PyTorch 框架的estimator变量。然后，我们提供必要的要求，例如以下内容：

entry_point：这是训练脚本的存储位置。
instance_count：这是集群中要配置的计算服务器数量。
instance_type：这是集群中所需的计算资源类型。在这个例子中，我们指定了ml.p3.16xlarge实例。

注意

关于 SageMaker PyTorch 估计器的更多信息，以及如何利用 SageMaker SDK 实例化估计器，请参阅 AWS 关于如何在 SageMaker 上使用 PyTorch 的文档（docs.aws.amazon.com/sagemaker/latest/dg/pytorch.html）和 SageMaker SDK 文档（https://sagemaker.readthedocs.io/en/stable/frameworks/pytorch/sagemaker.pytorch.html#pytorch-estimator）。

一旦我们声明了估计器，我们就在 S3 上指定训练和验证数据集的位置，如下代码片段所示：

...
from sagemaker.inputs import TrainingInput
train = TrainingInput(s3_train_data,
                      content_type='image/png',
                      input_mode='File')
val = TrainingInput(s3_val_data,
                    content_type='image/png',
                    input_mode='File')
...

然后，我们调用 PyTorch 估计器的fit()方法，告诉 SageMaker 在数据集上执行训练作业，如下代码片段所示：

...
estimator.fit({'train':train, 'val': val})
...

在幕后，SageMaker 创建了一个短暂的计算集群，在这些资源上执行训练任务，然后生成最终的优化模型，该模型随后存储在 Amazon S3 上。在此任务完成后，SageMaker 将拆除短暂的集群，用户只需为训练时间消耗的资源付费。

注意

关于 SageMaker 训练作业在幕后如何工作的更详细信息，请参阅 AWS 文档（docs.aws.amazon.com/sagemaker/latest/dg/how-it-works-training.html）。

因此，现在我们已经对如何使用 Amazon SageMaker 执行模型训练练习有了基本的了解，那么我们如何改进模型训练时间，并通过利用更多计算资源来加快这个过程呢？

为了回答这个问题，我们可以非常容易地通过 SageMaker 训练作业实现一个扩展策略。我们只需要将estimator变量的instance_type参数从ml.p3.2xlarge更改为ml.p3.16xlarge。通过这样做，我们正在增加或扩展计算资源的大小，从一个具有 8 个 vCPU、61GB RAM 和单个 GPU 的实例扩展到一个具有 64 个 vCPU、488GB RAM 和 8 个 GPU 的实例。

生成的代码现在如下所示：

...
from sagemaker.pytorch import PyTorch
estimator = PyTorch(entry_point='train.py',
                    source_dir='src',
                    role=role,
                    instance_count=1,
                    instance_type='ml.p3.16xlarge',
                    framework_version='1.8.0',
                    py_version='py3',
                    sagemaker_session=sagemaker_session,
                    hyperparameters={'epochs':10,
                                     'batch_size':32,
                                     'lr':3e-5,
                                     'gamma': 0.7},
                   )
...

因此，如您所见，使用 SageMaker 实施扩展策略非常简单。然而，如果我们需要超出加速计算实例的最大容量怎么办？

那么，我们就需要实施一个扩展策略，并将训练过程分散到多个计算节点上。在下一节中，我们将探讨如何使用分布式训练来应用扩展策略于 SageMaker 训练作业。

介绍分布式训练的基本原理

在上一节中，我们强调了如何通过指定大型计算资源或大型实例类型来应用扩展策略于 SageMaker 训练作业。实施训练过程的扩展策略同样简单。例如，我们可以将训练作业的instance_count参数从1增加到2，从而指示 SageMaker 实例化一个由 2 个计算资源组成的短暂集群，而不是 1 个节点。因此，以下代码片段突出了estimator变量配置将如何看起来：

...
from sagemaker.pytorch import PyTorch
estimator = PyTorch(entry_point='train.py',
                    source_dir='src',
                    role=role,
                    instance_count=2,
                    instance_type='ml.p3.2xlarge',
                    framework_version='1.8.0',
                    py_version='py3',
                    sagemaker_session=sagemaker_session,
                    hyperparameters={'epochs':10,
                                     'batch_size':32,
                                     'lr':3e-5,
                                     'gamma': 0.7},
                   )
...

不幸的是，仅仅更改计算实例的数量并不能完全解决问题。正如在本章开头所述，将扩展策略应用于分散 SageMaker 训练作业会增加模型训练活动的整体编排和配置的复杂性。例如，在分配训练活动时，我们还需要考虑以下方面：

如何让各种计算资源访问和共享数据？
计算资源之间是如何相互通信和协调它们的训练任务的？

因此，虽然简单地指定训练作业的计算资源数量将创建一个适当规模的训练集群，但我们还需要通知 SageMaker 我们的模型放置策略。模型放置策略指导 SageMaker 如何将模型分配或分配给集群中每个节点的每个计算资源。反过来，SageMaker 使用放置策略来协调每个节点如何与相关的训练数据互动，以及每个节点如何协调和沟通其模型训练任务的相应部分。

那么我们如何确定 SageMaker 的有效模型放置策略呢？

回答这个问题的最佳方式是了解可用的放置策略，并剖析每种策略是如何工作的。针对不同的训练框架，以及许多开源框架，存在众多特定的放置策略。尽管如此，所有这些不同的机制都可以归纳为两种特定的放置策略类别，即数据并行和模型并行。

让我们先来探讨 SageMaker 的数据并行策略。

检查 SageMaker 分布式数据并行策略

正如其名所示，数据并行策略侧重于模型训练数据的放置。因此，为了全面理解这种放置策略是如何应用于数据的，我们应该首先了解训练活动是如何与训练数据互动以优化机器学习模型的。

当我们训练一个机器学习模型时，我们基本上创建了一个训练循环，该循环将特定的机器学习算法应用于数据。通常情况下，与深度学习算法一样，我们将数据分成更小的记录组或数据批次。这些批次被称为小批量。然后我们将每个小批量通过神经网络层向前传递，然后向后传递以优化或训练模型参数。完成一个小批量后，我们再将相同的程序应用于下一个小批量，依此类推，直到我们处理完所有数据。在整个数据集上完整执行此过程被称为一个epoch。根据算法类型和当然，用例，我们可能需要运行算法多次 epoch 来训练模型。这项任务无疑花费了最多的时间，这也是我们本质上想要改进以减少模型训练所需总时间的任务。

因此，当使用数据并行放置策略时，我们基本上是将训练任务从顺序过程转换为并行过程。我们不再按顺序运行算法通过一个迷你批次，然后是下一个迷你批次，然后是下一个迷你批次，我们现在将每个单独的迷你批次分配给一个单独的计算资源，每个计算资源依次在其单独的迷你批次上运行模型训练过程。因此，当每个计算资源同时运行其自己的迷你批次时，我们实际上是在并行地将纪元分布到多个计算资源中，从而提高了整体模型训练时间。因此，使用数据并行技术确实引入了一个额外的复杂性，即对所有模型加权参数的并行优化。

为了进一步阐述这个问题，我们将使用 图 6**.1 中描述的示例，详细说明模型的单个节点参数：

图 6.1 – 单个节点参数

如您从 图 6**.1 中的示例中可以看到，我们有四个单独的计算资源或节点。使用数据并行放置策略，我们实际上在每个这些节点上放置了一个模型算法的副本，并将迷你批次数据分布到这些资源中。现在，每个节点在其数据单独的迷你批次上计算梯度减少操作，在这种情况下，是模型加权参数的总和，本质上产生了四个独特的梯度计算结果。由于我们的目标不是产生四个独立的优化模型表示，而是一个单一的优化模型，那么我们如何将所有四个节点的结果组合起来呢？

为了解决这个问题，SageMaker 在分布式训练过程中提供了一个额外的优化操作，并使用 AllReduce 算法在集群间共享和通信结果。通过在过程中包含这个额外的步骤，我们可以在 图 6**.2 中看到结果：

图 6.2 – 共享节点参数

从 图 6**.2 中，我们可以看到 AllReduce 步骤从每个节点的梯度减少操作中获取结果，并将结果与每个其他节点共享，确保每个节点对模型的表示包括所有其他节点的优化。因此，这保证了从分布式训练过程中产生一个单一、一致的模式作为最终输出。

注意

虽然 AllReduce 步骤用于分布式深度学习的初始概念最初是在百度研究的一个博客文章中提出的，但原始帖子已经被删除。因此，为了了解更多关于其工作细节的背景信息，你可以查看名为 Horovod 的开源实现（eng.uber.com/horovod/)）。

到目前为止，在本章的这一部分，我们使用广泛的术语计算资源来表示 CPU、GPU 和物理计算实例。然而，在实施一个成功的数据并行放置策略时，完全理解 SageMaker 如何使用这些计算资源来执行分布式训练工作负载是非常重要的。

简而言之，当我们指示 SageMaker 为训练作业实施数据并行放置策略时，我们实际上是在指示 SageMaker 将微型批次分布或分片到所有的计算资源中。SageMaker 反过来将训练数据分片到所有指定的estimator对象中的 GPU 上，以及偶尔的 CPU 上。为了使这个概念更容易理解，图 6.3.3 展示了 SageMaker 处理任务的示例：

图 6.3 – SageMaker 上的数据并行训练任务

如您从图 6.3.3 中所示，当为 SageMaker 的estimator对象调用fit()方法时，指定两个 GPU 实例（每个实例有八个 GPU），SageMaker 在临时集群中的两个实例上创建模型训练例程或训练脚本的副本。相应地，每个训练脚本被进一步复制到每个实例上的每个 GPU 上。一旦每个 GPU 都有一个训练脚本的副本，每个 GPU 随后在其各自分片的训练数据微型批次上执行训练脚本。

GPU 工作进程随后训练模型副本以生成一组最佳参数，然后与其他 GPU 工作进程共享，无论是同一实例内的，还是第二个实例中的其他 GPU，使用fit()操作报告成功。结果是单个优化模型，存储在 S3 上，并且整体模型训练时间减少了 16 倍，这是分配给任务的 GPU 总数。

因此，如您所见，我们通过实施数据并行放置策略有效地减少了整体训练时间。虽然这种策略对于大型训练数据集有效，并且是减少模型训练时间的良好开端，但这种策略在训练大型模型时并不总是有效。

注意

由于模型并行放置策略本质上是在多个节点上分布模型的计算图或模型流水线，这种放置策略通常被称为管道并行策略。

为了解决当我们有数百万甚至数十亿可训练参数的大型 ML 模型时，如何减少整体训练时间的问题，我们可以回顾如何实施模型并行放置策略。

检查 SageMaker 模型数据并行策略

数据并行策略主要被构想为一种减少整体模型训练时间的方法，在引入该策略时，在大数据量上进行训练提出了最大的挑战。然而，随着大规模自然语言处理（NLP）模型，如 OpenAI 的生成预训练转换器（GPT）openai.com/blog/gpt-3-apps/的发明，现在训练具有数十亿参数的大型 ML 模型提出了最大的挑战。基本上，这些模型太大，无法适应 GPU 的板载内存。

现在我们对 SageMaker 如何实现数据并行放置策略有了基本的了解，将其概念转换为模型并行放置策略相对容易。关键区别在于，虽然数据并行策略将大量训练数据分割成更小的数据块，但模型并行放置策略对大型 ML 模型执行类似的技巧，使得这些模型的小部分能够适应 GPU 内存。这也意味着我们不需要通过修剪或压缩模型来降低模型的能力。

图 6**.4突出了当 SageMaker 使用模型并行放置策略执行训练作业时，模型并行执行与数据并行执行是多么相似：

图 6.4 – SageMaker 上的模型并行训练任务

您可以从图 6**.4中看到，当调用 SageMaker estimator对象的fit()方法时，就像图 6**.3中的数据并行示例一样，SageMaker 将模型训练脚本的一个副本分配给两个实例中的每个 GPU。然而，与数据并行放置策略不同，SageMaker 将模型分割成更小的部分，或者模型分区，并将每个模型分区分配给一个 GPU 工作器。

为了协调每个模型分区的训练，SageMaker 实现了一个管道调度器。与 AllReduce 优化算法协调不同 GPU 工作者的参数优化方式相同，管道调度器确保每个批次的数据被输入到模型中，并且每个模型分区的计算被正确协调和调度在所有 GPU 工作者之间。这确保了在正向和反向遍历这些网络分区时，每一层的矩阵计算都符合模型架构的整体结构。例如，调度器会确保在正向遍历中，层二的数学计算在层三之前执行，并且层三的梯度计算在层二之前发生。一旦执行了所有所需的周期，本质上就是通过整个训练数据集的正向和反向遍历模型架构，SageMaker 解散临时集群并将优化后的模型存储在 S3 上。

总结来说，数据并行放置策略最初是为了通过共享数据和并行化跨多个计算资源执行来减少模型的总体训练时间。模型并行放置策略背后的主要动机是解决不适合计算资源内存的大型模型。这引出了一个问题，即是否可以将数据并行和模型并行放置策略结合起来，以分布式方式减少大型模型和大型数据集的总体训练时间。

接下来，让我们回顾这种混合方法。

混合数据并行和模型并行策略的回顾

由于数据并行和模型并行放置策略都是为了解决特定挑战而创建的，因此将两种策略结合成一个统一的混合策略在本质上是不可能的。本质上，两种策略通过数据分片或模型分片来解决它们各自的具体问题。

幸运的是，由于整个训练作业由 SageMaker 协调和管理，现在可以将两种策略结合成一个混合策略成为可能。例如，如果我们回顾图 6.5，我们可以直观地看到 SageMaker 如何使我们能够独立执行实现数据并行和模型并行放置策略的训练作业：

图 6.5 – SageMaker 上的独立数据并行和模型并行策略

图 6**.5 展示了使用相同数量的计算实例，并基本上实现了一个两节点数据并行放置策略，以及一个四路模型并行放置策略。这意味着创建两个训练脚本的副本，并将每个副本分配给两个计算实例中的一个。然后我们使用数据并行放置策略执行分布式训练任务。在训练任务执行的同时，我们使用模型并行放置策略将特定模型架构的副本分配给每个计算实例中的各个 GPU。

因此，尽管每种放置策略在其方法上都是独特的，但通过使用 SageMaker，我们可以获得两种方法的好处，以减少在大数据集和大型机器学习模型上的整体训练时间。在下一节中，我们将回顾如何在 SageMaker 上实际实施每种放置策略的示例，包括这个混合方法的示例。

在 AWS 上执行分布式训练工作负载

现在我们已经介绍了分布式训练的一些基本原理，以及当我们利用 SageMaker 启动分布式训练作业时幕后发生的事情，让我们来探讨如何在 AWS 上执行这样的工作负载。由于我们已经审查了两种放置技术，即数据并行和模型并行，我们将首先回顾如何执行分布式数据并行训练。之后，我们将回顾如何执行分布式模型并行训练，同时包括混合方法和在模型并行示例中包含独立的数据并行放置策略。

注意

在这个例子中，我们利用一个视觉 Transformer（ViT）模型来解决图像分类用例。由于本节的目标是展示如何实际实施数据并行和模型并行放置策略，我们不会深入探讨模型本身的细节，而是将其用于迁移学习的上下文中。要了解更多关于 ViT 模型的信息，请参阅大规模图像识别的 Transformer论文（arxiv.org/pdf/2010.11929.pdf）。

让我们从数据并行工作负载开始。

在 Amazon SageMaker 上执行分布式数据并行训练

使用 SageMaker 通过数据并行放置策略执行分布式训练作业有两个关键要素：

配置后端集群
配置模型训练脚本

在下一节中，我们将首先通过一个示例来讲解如何配置后端暂态 SageMaker 集群。

配置后端集群

要开始设置 SageMaker 集群，我们将利用与第五章，数据分析中介绍的相同的 SageMaker Studio 环境，以及来自配套 GitHub 存储库的示例代码。

注意

如果您尚未配置 SageMaker Studio 环境，请参阅第五章，数据分析中的设置 EMR 和 SageMaker Studio部分。

以下步骤将指导您设置示例：

登录用于第五章，数据分析示例的 AWS 账户，并打开 SageMaker 管理控制台（console.aws.amazon.com/sagemaker/home）。
在 SageMaker 管理控制台打开的情况下，使用左侧导航面板点击SageMaker 域链接。在用户部分，您将看到用户的名称和启动应用下拉框。
点击启动应用下拉菜单并选择Studio选项以启动 Studio IDE。
一旦 Studio 环境打开，双击我们在第五章，数据分析中克隆的Applied-Machine-Learning-and-High-Performance-Computing-on-AWS文件夹。
现在，双击Chapter06文件夹以访问示例 Jupyter 笔记本。
双击1_distributed_data_parallel_training.ipynb文件以启动笔记本。

注意

笔记本将初始化一个ml.m5.xlarge计算实例，配备4 vCPUs和16 GB的 RAM 来运行预配置的PyTorch 1.8内核。此实例类型超过了 AWS 免费层允许的免费资源类型（aws.amazon.com/free），因此将产生 AWS 使用费用。

一旦示例笔记本已启动且内核已启动，点击内核菜单选项，并选择重启内核并运行所有单元格…选项来执行笔记本代码单元格。

当笔记本正在运行时，让我们回顾一下代码，以了解到底发生了什么。在前两个代码单元中，我们下载了训练集和验证集的马或人数据集。这些数据集由 Laurence Moroney 提供（laurencemoroney.com/datasets.html），包含 500 张不同品种的马的渲染图像，以及 527 张人的渲染图像。我们将使用这个数据集来生成更高分辨率的版本，从而创建更大的图像文件大小，以模拟拥有大量训练和验证数据集的情况。因此，通过增加数据的大小，我们实际上创建了一个场景，在这个场景中，在大型图像文件上训练模型将导致图像分类模型的整体训练时间延迟。因此，我们正在设置一个要求利用数据并行放置策略，这将实际上减少训练我们的图像分类模型所需的总时间。

注意

这些数据集受 Creative Commons 2.0 Attribution 2.0 Unported License 许可。

在第三个代码单元中，如以下代码片段所示，我们以编程方式提取下载的train.zip和validation.zip文件，并将它们保存在本地的data文件夹中：

...
import zipfile
with zipfile.ZipFile("train.zip","r") as train_zip_ref:
    train_zip_ref.extractall("data/train")
with zipfile.ZipFile("validation.zip","r") as val_zip_ref:
    val_zip_ref.extractall("data/validation")
...

现在数据已经下载并提取，我们应该在data目录下有两个文件夹，分别命名为train和validation。这两个文件夹都包含马和人的图片。然而，正如之前提到的，这些图片的尺寸相当小。例如，如果我们检查./data/train/horses文件夹中的horse01-0.png文件，你会注意到这个文件的大小仅为 151.7 KB。由于我们只有 500 个这样的小文件代表马，我们需要想出一种方法来使这些文件变大。因此，我们将使用一个名为Enhanced Deep Residual Networks for Single Image Super-Resolution（EDSR）的 ML 模型来提高这些文件的分辨率，从而实际上增加文件的大小，以模拟一个真实世界的使用案例，其中图片大小为 MB，而不是 KB。

注意

虽然本章的范围不包括详细说明 EDSR 模型，我们只是用它来提高图像的分辨率，从而使文件大小变大。你可以通过参考 Hugging Face 的模型存储库了解更多关于预训练模型的信息（huggingface.co/eugenesiow/edsr-base）。

因此，在下一组代码单元中，如以下代码片段所示，我们运行预训练的 EDSR 模型在我们的图像数据集上以提高图像分辨率，并作为副产品增加图像文件大小：

...
from super_image import EdsrModel, ImageLoader
from PIL import Image
import requests
import os
from os import listdir
folder_dir = "data/validation/"
model = EdsrModel.from_pretrained('eugenesiow/edsr-base', scale=4)
for folder in os.listdir(folder_dir):
    folder_path = f'{folder_dir}{folder}'
    for image_file in os.listdir(folder_path):
        path = f'{folder_path}/{image_file}'
        image = Image.open(path)
        inputs = ImageLoader.load_image(image)
        preds = model(inputs)
        ImageLoader.save_image(preds, path)
file_size = os.path.getsize(path)
print("File Size is :", file_size/1000000, "MB")
...

如您从代码单元格的示例输出中看到的那样，我们已将每个图像的文件大小从大约 178 KB 增加到略低于 2 MB。因此，当数据集准备好用于训练时，我们可以将它们上传到 S3，以便临时的 SageMaker 集群可以访问它们。以下代码片段展示了我们如何初始化 SageMaker 对 S3 的权限，并使用 SageMaker Python SDK 的S3Upload类的upload()方法将数据存储在 S3 上：

...
import sagemaker
from sagemaker import get_execution_role
from sagemaker.estimator import Estimator
from sagemaker.s3 import S3Uploader
import boto3
sagemaker_session = sagemaker.Session()
bucket = sagemaker_session.default_bucket()
prefix = 'horse-or-human'
role = get_execution_role()
client = boto3.client('sts')
account = client.get_caller_identity()['Account']
print(f'AWS account:{account}')
session = boto3.session.Session()
region = session.region_name
print(f'AWS region:{region}')
s3_train_data = S3Uploader.upload('data/train',f's3://{bucket}/{prefix}/data/train')
s3_val_data = S3Uploader.upload('data/validation',f's3://{bucket}/{prefix}/data/validation')
print('s3 train data path: ', s3_train_data)
print('s3 validation data path: ', s3_val_data)
...

现在，我们已经准备好定义 SageMaker 估计器。您可能还记得在使用 AWS 构建 ML 系统部分中展示的代码片段，我们只需要定义一个PyTorch估计器并提供基本的配置参数，例如instance_count和instance_type，SageMaker 就会负责剩下的繁重工作来编排训练作业。然而，为了配置数据并行放置策略，我们需要向估计器提供一个额外的配置参数，称为distribution。正如您可以从以下代码片段中看到的那样，我们声明了相同的估计器实例，但现在我们添加了distribution参数来通知 SageMaker 我们希望启用dataparallel放置策略：

...
estimator = PyTorch(entry_point='train.py',
                    source_dir='src',
                    role=role,
                    instance_count=1,
                    instance_type='ml.p3.16xlarge',
                    framework_version='1.8.0',
                    py_version='py3',
                    sagemaker_session=sagemaker_session,
                    hyperparameters={'epochs':10,
                                     'batch_size':32,
                                     'lr':3e-5,
                                     'gamma': 0.7},
                    distribution={"smdistributed": {"dataparallel": {"enabled": True}}},
                    debugger_hook_config=False,
                    metric_definitions=metric_definitions,
                   )
...

现在，我们剩下的工作就是通过调用我们的estimator对象的fit()方法来启动训练作业。以下代码片段展示了如何使用我们已上传到 S3 的训练和验证数据初始化分布式训练作业：

...
from sagemaker.inputs import TrainingInput
train = TrainingInput(s3_train_data,
                      content_type='image/png',
                      input_mode='File')
val = TrainingInput(s3_val_data,
                    content_type='image/png',
                    input_mode='File')
estimator.fit({'train':train, 'val': val})
...

一旦初始化了训练作业，SageMaker 将重定向日志，以便我们可以看到 PyTorch 训练容器内部发生了什么，并且我们可以将日志输出与我们关于分布式数据并行放置策略如何工作的了解相匹配。

注意

如果您收到estimator.fit()方法的错误，您可以遵循如何解决 Amazon SageMaker 中的 ResourceLimitExceeded 错误知识文章中的解决步骤（aws.amazon.com/premiumsupport/knowledge-center/resourcelimitexceeded-sagemaker/)。

您可能还记得在审查 SageMaker 分布式数据并行策略部分中，训练脚本以及模型算法被复制到计算实例中的每个 GPU。由于每个 GPU 本质上都在执行其自己的训练脚本副本以优化其独特的模型参数集，然后通过 AllReduce 与 GPU 工作共享，我们还需要确保训练脚本本身被配置为作为更大分布式训练过程的一部分执行。

基本上，这意味着当我们为 SageMaker 的 estimator 对象指定 distribution 参数时，我们是在指示 SageMaker 为分布式训练作业配置适当的后端资源。但我们也需要配置训练脚本来正确使用这个分布式后端集群。因此，为了扩展训练脚本利用后端集群分布式功能的能力，AWS 为指定的深度学习框架（在本例中为 PyTorch）提供了 smdistributed。

注意

AWS 还为 TensorFlow 2.x 深度学习框架提供了 smdistributed 库。有关如何利用分布式数据并行放置策略为 TensorFlow 训练脚本提供支持的信息，您可以查看 TensorFlow 指南 (sagemaker.readthedocs.io/en/stable/api/training/sdp_versions/latest/smd_data_parallel_tensorflow.html)。

在下一节中，我们将回顾如何使用 smdistributed Python 库配置模型训练脚本。

配置模型训练脚本

将 smdistributed 库集成到 PyTorch 训练脚本中有五个基本具体步骤。要查看这些步骤，我们可以在 Studio IDE 中打开 ./src/train.py 文件，并按以下方式遍历重要的代码：

第一步是导入 PyTorch 框架的 smdistributed 库。正如您可以从以下代码片段中看到的那样，通过导入并初始化这些模块，我们实际上是将 PyTorch 执行并行训练方法的能力封装到数据并行放置策略中：
```
...
```
```
from smdistributed.dataparallel.torch.parallel.distributed import DistributedDataParallel as DDP
```
```
import smdistributed.dataparallel.torch.distributed as dist
```
```
dist.init_process_group()
```
```
...
```
下一步是将数据集成到 PyTorch 的数据加载机制中，以便 PyTorch 可以迭代分配给 GPU 工作者的数据块。在下面的代码片段中，我们将 num_replicas 指定为参与此分布式训练练习的 GPU 工作者数量。我们还通过指定 rank 参数提供了 GPU 工作者的本地排名或其在当前练习中的成员排名：
```
...
```
```
train_sampler = torch.utils.data.distributed.DistributedSampler(
```
```
        train_dataset, num_replicas=world_size, rank=rank
```
```
)
```
```
...
```
从前面的代码片段中，我们使用了 world_size 和 rank 变量。world_size 变量用于表示数据并行任务正在分布的总 GPU 工作者数量。因此，正如您可以从下一个代码片段中看到的那样，为了获取总的 GPU 数量，我们调用 smdistributed.dataparallel.torch.distributed 模块中的 get_world_size() 方法。同样，我们也使用这个库中的 get_rank() 方法来获取当前 GPU 的成员排名：
```
...
```
```
world_size = dist.get_world_size()
```
```
rank = dist.get_rank()
```
```
...
```
最后，我们为 PyTorch 的 DataLoader() 方法配置了小批量大小，声明为 batch_size 变量。这是训练作业的全局批量大小，除以 GPU 工作者的数量，由 步骤 3 中描述的 world_size 变量表示：
```
...
```
```
args.batch_size //= world_size // 8
```
```
args.batch_size = max(args.batch_size, 1)
```
```
...
```

因此，将这些最小代码添加应用到模型训练流程中，我们已经有效地实现了一个数据并行放置策略的示例。接下来，让我们看看如何使用相同的示例，但应用模型并行放置策略。

在 Amazon SageMaker 上执行分布式模型并行训练

由于我们使用与前面示例中相同的图像分类模型来展示模型并行训练的示例，您可以使用相同的步骤打开并执行笔记本。然而，在本例中，我们将打开 2_distributed_model_parallel_training.ipynb 文件并运行所有的代码单元，而不是打开 1_distributed_data_parallel_training.ipynb 文件。

因此，就像数据并行放置策略一样，在 SageMaker 上成功实施模型并行放置策略有两个关键组件，即配置后端集群和配置模型训练脚本。让我们首先探讨需要对 estimator 配置进行的所有更改。

配置后端集群

当审查估计器配置时，请注意提供给 distribution 参数的选项已更改。如您从以下代码片段中看到的，我们现在指定了一个 modelparallel 选项，而不是为 smdistributed 启用 dataparallel 设置：

...
                    distribution={
                        "smdistributed": {"modelparallel": smp_options},
                        "mpi": mpi_options
                    },
...

此外，如以下代码片段所示，我们声明了一个名为 smp_options 的变量，通过该变量我们指定了针对 modelparallel 策略的配置选项字典：

...
smp_options = {
    "enabled":True,
    "parameters": {
        "partitions": 1,
        "placement_strategy": "spread",
        "pipeline": "interleaved",
        "optimize": "speed",
        "ddp": True,
    }
}
mpi_options = {
    "enabled" : True,
    "processes_per_host" : 8,
}
...

如您从前面的代码片段中看到的，其中最重要的配置选项已被突出显示，我们将 placement_strategy 参数设置为 spread。实际上，我们正在配置 SageMaker 在计算实例内的所有 GPU 设备上均匀地分配模型分区。由于我们使用的是单个 ml.p3.16xlarge 实例，该实例具有八个 GPU，而不是多个计算实例，因此我们在实例内部均匀分配模型分区。

此外，我们还将管道调度机制，即 pipeline 参数，设置为 interleaved。此设置通过优先执行反向执行模型提取任务以释放 GPU 内存，从而提高了后端集群的整体性能。

最后，为了启用模型并行以及数据并行放置策略的混合实现，我们将分布式数据并行或 ddp 参数设置为 True。正如我们在标题为“混合数据并行和模型并行策略回顾”的部分中看到的，数据并行和模型并行策略可以同时使用，以进一步减少训练模型所需的总时间。

因此，由于我们在这个例子中同时使用了这两种策略，我们必须也提供一个mpi参数，以指导 SageMaker 每个 GPU 工作器如何与其他 GPU 工作器通信其正在执行的操作。例如，在之前的代码片段中，在启用mpi_options设置后，我们还设置了processes_per_host为8。这个设置实际上配置了临时的 SageMaker 集群架构以匹配图 6**.5，其中我们将单个ml.p3.16xlarge计算实例上的 GPU 工作器设置为使用四路模型并行策略，从而将模型基本分割成四个 GPU 工作器。此外，我们还配置了双向数据并行策略，将训练数据分割成两个数据块，并在数据块上并行执行模型分割。因此，双向乘以四路等于每个主机八个进程。

正如你所见，通过添加这些最小配置更改，可以实现一个支持数据并行和模型并行的 SageMaker 集群。然而，就像之前的例子一样，训练脚本也需要进行一些更改。接下来让我们来回顾这些更改。

配置模型训练脚本

由于实现模型并行放置策略比数据并行策略更为复杂，训练脚本中需要添加一些额外的要求。现在让我们打开./src/train_smp.py文件来回顾最重要的要求。你可能立即会注意到，为了执行 PyTorch 模型的模型并行放置策略，需要 11 个特定的脚本更改：

再次强调，正如你从下面的代码片段中看到的，第一步是从smdistributed库中导入modelparallel模块，并将这些模块初始化为 PyTorch 的包装器：
```
...
```
```
import smdistributed.modelparallel
```
```
import smdistributed.modelparallel.torch as smp
```
```
smp.init()
```
```
...
```
一旦模块初始化完成，我们就扩展使用model变量定义的图像分类模型，并将其包装进DistributedModel()类中，如下面的代码块所示。这表明我们的模型现在正在被分布式处理：
```
...
```
```
model = smp.DistributedModel(model)
```
```
...
```
由于模型现在正在被分布式处理，我们还需要分布式优化器。所以，正如你从下面的代码片段中看到的，我们使用 PyTorch 的Adam()算法实现来优化模型参数，并通过将优化任务包装进DistributedOptimizer()类来跨 GPU 分布式优化任务：
```
...
```
```
optimizer = smp.DistributedOptimizer(
```
```
    optim.Adam(model.parameters(), lr=args.lr))
```
```
...
```

除了分布式处理模型本身以及优化器之外，我们还需要精确定义正向和反向传递通过模型计算图或模型管道的执行方式。相应地，我们通过将正向和反向传递的计算结果包装在step()装饰函数中来扩展模型的计算结果。下面的代码片段显示了扩展train_step()用于正向传递和test_step()用于反向传递的step()装饰器：

...

@smp.step

def train_step(model, data, label):

    output = model(data)

    loss = F.nll_loss(F.log_softmax(output), label,

                      reduction="mean")

    # replace loss.backward() with model.backward in the train_step function.

    model.backward(loss)

    return output, loss

@smp.step

def test_step(model, data, label):

    val_output = model(data)

    val_loss = F.nll_loss(F.log_softmax(val_output),

                          label, reduction="mean")

    return val_loss

...

最后，一旦使用模型并行策略训练了模型，正如您可以从以下代码片段中看到的那样，我们只在集群中排名最高的 GPU 工作节点上保存最终模型：

...

    if smp.rank() == 0:

        model_save = model.module if hasattr(model, "module") else model

        save_model(model_save, args.model_dir)

...

虽然这些只是使用smdistributed.modelprallel模块配置训练脚本时最重要的几个参数，但您可以看到，通过极少的代码，我们可以完全配置我们的训练脚本，以使用自动配置的 SageMaker 临时集群，同时实现数据并行和模型并行放置策略，从而减少使用这种混合实现的整体训练时间。

摘要

在本章中，我们关注了机器学习实践者在训练机器学习模型时可能面临的两个潜在挑战：首先，减少整体模型训练时间，尤其是在有大量训练数据的情况下；其次，当存在具有数百万甚至数十亿可训练参数的大型模型时，减少整体模型训练时间的挑战。

我们回顾了三种可以用来解决这些挑战的具体策略，即数据并行放置策略，它将大量训练数据分布到多个工作资源中，以并行执行模型训练过程。此外，我们还回顾了模型并行放置策略，它将一个非常大的机器学习模型分布到多个 GPU 资源中，以避免试图将这些大型模型压缩到可用的内存资源中。最后，我们还探讨了如何通过混合方法将这两种策略结合起来，以进一步获得两者带来的好处。

此外，我们还回顾了如何使用 Amazon SageMaker 来解决这些挑战，特别是关注 SageMaker 如何处理构建专门配置以处理任何这三种放置策略的分布式训练计算和存储基础设施的重任。SageMaker 不仅提供临时的计算资源，还提供了可以集成到模型训练脚本中的 Python 库，以充分利用集群。

现在我们已经了解了如何使用分布式训练进行机器学习模型训练，在下一章中，我们将回顾如何大规模部署训练好的机器学习模型。

第七章：大规模部署机器学习模型

在前面的章节中，我们学习了如何存储数据、执行数据处理以及为机器学习应用进行模型训练。在训练机器学习模型并使用测试数据集进行验证后，接下来的任务通常是对新数据和未见数据进行推理。对于任何机器学习应用来说，训练好的模型应该能够很好地泛化未见数据，以避免过拟合。此外，对于实时应用，模型应该能够在访问所有相关数据（包括新数据和存储数据）的同时，以最小的延迟执行推理。同时，与模型相关的计算资源应该能够根据推理请求数量进行扩展或缩减，以便在优化成本的同时，不牺牲性能和实时机器学习应用的需求。

对于不需要实时推理的使用案例，训练好的模型应该能够在合理的时间内对包含数千个变量的非常大的数据集进行推理。此外，在几种情况下，我们可能不想费力去管理推理所需的服务器和软件包，而是将精力集中在开发和改进我们的机器学习模型上。

考虑到上述所有因素，AWS 提供了多种选项来部署机器学习模型，以便对新数据和未见数据执行推理。这些选项包括实时推理、批量推理和异步推理。在本章中，我们将讨论使用 Amazon SageMaker 进行机器学习模型的托管部署选项，以及各种功能，如模型的高可用性、自动扩展和蓝/绿部署。

本章将涵盖以下主题：

AWS 上的托管部署
选择正确的部署选项
批量推理
实时推理
异步推理
模型端点的高可用性
蓝绿部署

AWS 上的托管部署

数据科学家和机器学习从业者通常非常专注于开发机器学习模型以解决业务问题。问题表述和开发优雅的解决方案、选择合适的算法以及训练模型以确保其提供可靠和准确的结果是我们希望我们的数据科学家和数据工程师关注的机器学习问题解决周期的主要组成部分。

然而，一旦我们有一个好的模型，我们希望在新的数据上运行实时或批量推理。部署模型并管理它通常是需要专门工程师和计算资源的任务。这是因为，我们首先需要确保我们有所有正确的包和库，以便模型能够正确工作。然后，我们还需要决定模型运行所需的计算资源类型和数量。在实时应用中，我们通常是为了满足峰值性能需求而进行设计，就像为 IT 项目配置服务器一样。

模型部署并运行后，我们还需要确保一切按预期工作。此外，在现实世界场景中，数据科学家通常需要定期手动进行分析，以检测模型或数据漂移。如果在这些漂移中检测到任何一个，数据科学家将再次经历整个探索性分析、特征工程、模型开发、模型训练、超参数优化、模型评估和模型部署的周期。所有这些任务都需要大量的努力和资源，因此，许多组织已经转向使用 机器学习操作（MLOps）工作流程和管理模型部署选项来自动化这些流程，这些选项能够很好地适应不断变化的工作负载。

Amazon SageMaker 提供了多种完全管理的模型部署选项。在本节中，我们将概述这些管理部署选项及其优势，然后在接下来的几节中详细讨论其中的一些部署选项。

Amazon SageMaker 管理模型部署选项

Amazon SageMaker 提供以下管理部署模型选项：

批量转换：SageMaker 批量转换用于对大型数据集进行推理。在这种情况下没有持久端点。此方法通常用于在需要离线对大型数据集进行推理的非实时机器学习用例中执行推理。
实时端点：SageMaker 实时端点用于需要持久机器学习模型端点用例，该端点对少量数据样本进行实时推理。
异步推理：Amazon SageMaker 异步推理部署了一个异步端点，用于对大型负载（高达 1 GB）进行推理，具有长处理时间和低延迟。
无服务器推理：在所有之前的方法中，用户都需要选择用于推理的计算实例类型。Amazon SageMaker 无服务器推理会自动选择服务器类型，并根据端点的负载进行扩展和缩减。这对于具有不可预测流量模式的应用程序通常很有用。

让我们接下来探索可用的计算资源种类。

可用的计算资源种类

为了进行推理，有各种各样的计算实例可供选择。在撰写本文时，大约有 70 多个实例可用于执行机器学习推理。这些实例具有不同的计算能力和内存，可以服务于不同的用例。还有使用图形处理单元（GPUs）进行推理的选项。此外，SageMaker 还支持 Inf1 实例，用于高性能和低成本推理。这些选项使 SageMaker 模型部署和推理非常灵活，适用于各种机器学习用例。

经济高效的模型部署

Amazon SageMaker 有多种优化模型部署成本的选择。有多个模型可以共享一个容器的多模型端点。这有助于降低托管成本，因为端点利用率由于多个模型共享相同的端点而提高。此外，它还允许不同模型之间共享内存资源。SageMaker 还有构建和部署多容器端点的选项。此外，我们可以将扩展策略附加到我们的端点，以便在流量增加时分配更多计算资源，在流量减少时关闭实例以节省成本。

另一种经济高效的模型部署选项是 SageMaker 无服务器推理。无服务器推理利用 AWS Lambda 根据流量增加或减少来扩展和缩减计算资源。它对于流量模式不可预测的场景特别有用。

蓝绿部署

每当我们更新 SageMaker 模型端点时，SageMaker 都会自动使用蓝绿部署。在蓝绿部署中，SageMaker 使用一组新实例来部署更新的端点，然后将流量从旧实例群切换到新实例群。Amazon SageMaker 为蓝绿部署提供以下流量切换策略：

同时流量切换
金丝雀流量切换
线性流量切换

我们将在本章后面更详细地讨论这些流量模式。

推理推荐器

使用 Amazon SageMaker 推理推荐器，我们可以自动获取用于部署我们的模型端点的计算实例类型的推荐。它通过负载测试各种实例并提供测试实例类型的推理成本、吞吐量和延迟来给出实例推荐。这有助于我们决定用于部署模型端点的实例类型。

MLOps 集成

使用 Amazon SageMaker，我们可以轻松构建与持续集成和持续交付（CI/CD）管道集成的机器学习工作流程。这些工作流程可用于自动化整个机器学习生命周期，包括数据标注、数据处理和特征工程、模型训练和注册、后处理、端点部署以及数据漂移和模型漂移监控的模型监控。对于模型部署，这些工作流程可用于自动化批量推理的过程，以及将模型端点从开发环境推送到预生产和生产环境。

模型注册

Amazon SageMaker 提供了使用 SageMaker 模型注册功能注册和编目机器学习模型的能力。使用模型注册，我们可以将训练模型的多个版本包含在模型包组中。这样，每次我们训练和注册模型时，它都会作为新版本添加到模型包组中。此外，使用模型注册，我们还可以将元数据和训练指标关联到机器学习模型，批准或拒绝模型，如果批准，则将模型移至生产环境。模型注册的这些功能有助于构建自动化机器学习工作流程所需的 CI/CD 管道。

弹性推理

对于需要非常高的吞吐量和低延迟的机器学习用例，我们通常最终会使用 GPU 机器，从而显著增加推理的成本。使用 Amazon SageMaker，我们可以将弹性推理添加到我们的端点。弹性推理通过仅附加适量的 GPU 推理加速器到任何 SageMaker 实例类型，为我们端点提供推理加速。这有助于显著降低延迟和提高吞吐量，同时与使用 GPU 实例进行推理相比，成本要低得多。

在边缘设备上部署

许多机器学习用例需要模型在边缘设备上运行，例如移动设备、摄像头和专用设备。这些设备通常具有较低的计算资源、内存和存储。此外，由于设备硬件和操作系统的可变性，部署、管理和监控设备上的机器学习模型是一项困难的任务。使用 Amazon SageMaker Edge Manager，可以在具有不同硬件和软件配置的设备群上部署、监控和管理机器学习模型。SageMaker Edge Manager 使用 SageMaker Neo 编译机器学习模型，并将这些编译后的模型打包以部署到边缘设备。此外，我们还可以收集边缘设备上模型使用的数据样本，并将它们发送到云端进行数据分析，以确定数据和质量问题，如数据漂移和模型漂移。

现在，让我们在下一节中讨论 AWS 上各种模型部署选项。

选择合适的部署选项

如前所述，AWS 提供了多种模型部署和推理选项。有时决定正确的模型部署选项可能会让人困惑和不知所措。选择正确的模型部署选项的决定实际上取决于用例参数和需求。在决定部署选项时，以下是一些重要的考虑因素：

我们是否有需要实时、持久端点以实时和非常快速地按需对新数据进行推理的应用程序？
我们的应用程序是否可以等待一分钟或两分钟，直到计算资源上线后再获取推理结果？
我们是否有不需要近乎实时结果的使用场景？我们能否每天/每周或按需对一批数据进行推理？
我们是否有不可预测且不均匀的流量模式需要推理？我们是否需要根据流量调整计算资源的大小？
我们试图进行推理的数据有多大（数据点/行数）？
我们是否需要一直使用专用资源来执行推理，或者我们可以采用无服务器的方法？
我们能否在一个端点中打包多个模型以节省成本？
我们是否需要一个由多个模型、预处理步骤和后处理步骤组成的推理管道？

在以下小节中，我们将讨论何时选择亚马逊 SageMaker 提供的不同类型的模型部署和推理选项，同时解答之前提到的问题。我们还将提供每个模型部署选项的典型用例示例。

使用批量推理

亚马逊 SageMaker 批量转换用于不需要持久实时端点且可以在大量数据上执行推理的情况。以下示例说明了 SageMaker 批量转换的使用：

预测性维护：在制造工厂中，各种组件的传感器和机器数据可能全天收集。对于此类用例，不需要实时或异步端点。夜间，可以使用机器学习模型预测某个组件是否即将失效，或者机械的一部分是否需要维护。这些模型将在大量数据上运行，并使用 SageMaker 批量转换进行推理。这些模型的结果可以用来制定和执行维护计划。
房价预测：房地产公司在新房价和市场方向预测出台前收集几天（有时是几周）的数据。这些模型不需要实时或异步端点，因为它们只需要在几天或几周后以及在大量的数据上运行。对于此类用例，SageMaker 批量转换是推理的理想选择。SageMaker 批量转换作业可以在机器学习管道中定期运行，处理新数据和历史数据，通过地区预测房价调整和市场方向。这些结果反过来又可以用来确定是否需要重新训练机器学习模型。

我们将在本章后面的部分详细介绍 Amazon SageMaker 中的批量、实时和异步推理选项。

使用实时端点

亚马逊 SageMaker 的实时端点应在需要实时持久化模型端点、随着新数据的到来进行低延迟预测时作为模型部署的选择。实时端点由 Amazon SageMaker 完全管理，并可部署为多模型和多容器端点。以下是一些实时端点的示例用例：

欺诈交易：客户使用信用卡在线购买商品或在实体零售店购买。这种金融交易可以是信用卡的实际持卡人进行的，也可以是盗窃的信用卡进行的。金融机构需要实时决定是否批准这笔交易。在这种情况下，可以将机器学习模型部署为实时端点。该模型可以使用客户的人口统计数据和历史购买记录（来自历史数据表），同时使用一些来自当前交易的数据，例如 IP 地址和网页浏览器参数（如果是在线交易），或实时使用来自摄像头的商店位置和图像以及/或视频（如果是实体交易），以判断交易是否为欺诈。金融机构可以使用这个决定来批准或拒绝交易，或联系客户进行通知、手动验证和批准。
实时情感分析：客户在与客户服务代表进行聊天或电话交谈。机器学习模型实时分析聊天或语音对话的转录文本，以确定客户所表现出的情感。根据情感，如果客户不满意，代表可以提供各种促销活动或升级案件至主管，以防止事情失控。这个机器学习模型应该使用实时端点部署，以便正确确定情感而没有任何延迟或延迟。
质量保证：在制造工厂中，产品正在装配线上组装，需要进行严格的质量控制，以便尽快去除有缺陷的产品。这同样是一个应用，其中来自机器学习模型的实时推理，该模型使用实时图像或视频流将对象分类为有缺陷或正常，将非常有用。

与实时端点类似，我们还有使用异步端点的选项，我们将在下一节中了解。

使用异步推理

Amazon SageMaker 异步推理端点与实时端点非常相似。异步端点可以排队推理请求，并且在需要接近实时延迟的同时处理大量工作负载时是首选的部署选项。以下示例说明了潜在的异步端点用例。

轨道检查：几列火车在其日常路线上运行，并配备了摄像头，这些摄像头可以捕捉轨道和开关的图像和视频以进行缺陷检测。这些火车没有足够的带宽来实时传输这些数据以进行推理。当这些火车停靠在车站时，大量图像和视频可以发送到 SageMaker 异步推理端点进行推理，以确定一切是否正常，或者轨道或开关上是否存在任何缺陷。与异步端点关联的计算实例将在接收到来自任何火车的数据后立即启动，对数据进行推理，然后一旦所有数据都已被处理，就关闭。这将有助于降低与实时端点相比的成本。

批量推理

对于在数据集上执行批量推理，我们可以使用 SageMaker 批量转换。当不需要实时持久部署的机器学习模型时，应使用推理。批量转换在推理数据集很大或我们需要对数据集进行大量预处理时也非常有用。例如，从数据中去除偏差或噪声，将语音数据转换为文本，以及过滤和归一化图像和视频数据。

我们可以将输入数据传递给 SageMaker 批量转换，要么是一个文件，要么是多个文件。对于单个文件中的表格数据，文件中的每一行都被解释为一个数据记录。如果我们选择了多个实例来执行批量转换作业，SageMaker 将将输入文件分发到不同的实例以进行批量转换作业。单个数据文件也可以分成多个小批量，并且可以在不同的实例上并行对这些小批量进行批量转换。图 7.1 展示了 SageMaker 批量转换的简化典型架构示例：

图 7.1 – Amazon SageMaker 批量转换的示例架构

如图中所示，数据是从Amazon S3读取的。使用Amazon SageMaker Processing对数据进行预处理和特征工程，以便将数据转换为机器学习模型期望的正确格式。然后，使用Amazon SageMaker Batch Transform对训练好的机器学习模型进行批量推理。结果随后写回到Amazon S3。批量转换中使用的机器学习模型可以是使用 Amazon SageMaker 训练的，也可以是在 Amazon SageMaker 之外训练的模型。批量转换的两个主要步骤如下：

创建一个转换器对象。
创建一个批量转换作业以进行推理。

这些步骤在以下小节中描述。

创建一个转换器对象

我们首先需要创建Transformer类的对象，以便运行 SageMaker 批量转换作业。在创建Transformer对象时，我们可以指定以下参数：

model_name：这是我们打算用于推理的机器学习模型的名称。这也可以是一个内置的 SageMaker 模型，对于这种模型，我们可以直接使用内置估计器的transformer方法。
instance_count：我们将用于运行批量转换作业的 EC2 实例数量。
instance_type：我们可以使用的 EC2 实例类型。有多种实例可供批量转换作业使用。实例的选择取决于我们用例的计算和内存需求，以及数据类型和大小。

此外，我们还可以指定其他几个参数，例如批量策略和输出路径。完整的参数列表可以在参考文献部分的文档页面上找到。在以下示例中，我们使用了 SageMaker 的内置 XGBoost 容器。对于运行自己的容器/模型或框架（如 PyTorch 和 TensorFlow）的批量转换器，容器镜像可能会有所不同。

图 7.2 – 7.8展示了 SageMaker 的 XGBoost 模型在训练数据上拟合的示例，然后为这个训练模型创建了一个转换器对象。我们指定转换作业应在ml.m4.xlarge类型的一个实例上运行，并期望text/csv数据：

如图 7.2所示，我们可以指定运行示例中代码所需的各个包和 SageMaker 参数。

图 7.2 – 在 SageMaker 中设置包和存储桶，并下载用于模型训练和推理的数据集

如图 7.3所示，我们可以读取数据并对分类变量进行独热编码。

图 7.3 – 对分类变量进行独热编码并显示结果

图 7.4展示了数据被分割成训练、验证和测试分区，这些分区将在模型训练过程中使用。

图 7.4 – 将数据分割成训练、验证和测试集以用于模型训练和测试

如图 7.5所示，我们可以按照机器学习模型（XGBoost）期望的顺序重新排列数据表中的列。此外，我们还可以将训练和验证数据文件上传到 S3 桶中，以便进行模型训练步骤。

图 7.5 – 重新组织数据并将其上传到 S3 桶以进行训练

图 7.6显示我们正在使用 SageMaker 的 XGBoost 容器来训练我们的模型。它还指定了用于训练和验证模型的数据通道。

在 S3 中指定模型训练的容器以及训练和验证数据路径

图 7.6 – 在 S3 中指定模型训练的容器以及训练和验证数据路径

如图 7.7所示，我们需要定义估计器、实例类型和实例数量，并设置 XGBoost 模型所需的各个超参数。我们还将通过调用fit方法启动训练作业。

图 7.7 – 定义 SageMaker 估计器进行训练并设置超参数

接下来，让我们创建一个批量转换作业。

创建用于推理的批量转换作业

在创建 transformer 对象之后，我们需要创建一个批量转换作业。图 7.8展示了使用批量 transformer 对象的transform方法调用启动批量转换作业的示例。在这个转换调用中，我们将指定我们想要在上面进行批量推理的 Amazon S3 中数据的存储位置。此外，我们还将指定数据的内容类型（在这种情况下为text/csv），以及数据文件中记录的分割方式（在这种情况下，每行包含一个记录）。

图 7.8 – 创建 transformer 对象，准备批量推理数据，并启动批量转换作业

图 7.9展示了从 S3 读取结果并然后绘制结果（实际值与预测值）的示例：

图 7.9 – 创建一个辅助函数来读取批处理转换的结果，并绘制结果（实际值与预测值对比）

图 7.10 展示了生成的对比图：

图 7.10 – 实际值与预测环值对比图

本节中讨论的代码和步骤概述了训练机器学习模型的过程，然后使用该模型对数据进行批推理。

优化批处理转换作业

SageMaker 批处理转换还提供了使用一些超参数优化转换作业的选项，如下所述：

max_concurrent_transforms：在任何给定时间可以向每个批处理转换容器发出的最大 HTTP 请求数。为了获得最佳性能，此值应等于我们用于运行批处理转换作业的计算工作线程数。
max_payload：此值指定了发送到批处理转换进行推理的单个 HTTP 请求中有效负载的最大大小（以 MB 为单位）。
strategy：此指定了策略，即我们是否希望在批处理中只有一个记录或多个记录。

SageMaker 批处理转换是一个非常实用的选项，用于对大型数据集进行推理，这些用例不需要实时延迟和高吞吐量。SageMaker 批处理转换可以通过使用 MLOps 工作流程来执行，该工作流程可以在有新数据需要进行推理时触发。然后可以使用批处理转换作业结果生成自动报告。

接下来，我们将学习如何使用 Amazon SageMaker 的实时推理选项部署实时端点以对数据进行预测。

实时推理

如本章前面所述，当我们需要非常低延迟的结果时，就会出现实时推理的需求。一些日常用例是使用机器学习模型进行实时推理的例子，例如人脸检测、欺诈检测、缺陷和异常检测以及实时聊天中的情感分析。在 Amazon SageMaker 中，可以通过将我们的模型部署到 SageMaker 托管服务作为实时端点来执行实时推理。图 7.11 展示了使用实时端点的典型 SageMaker 机器学习工作流程。

图 7.11 – SageMaker 实时端点的示例架构

在此图中，我们首先从 Amazon S3 存储桶中读取我们的数据。使用 Amazon SageMaker Processing 在此数据上执行数据预处理和特征工程。然后，在处理后的数据上训练机器学习模型，接着进行结果评估和后处理（如果有）。之后，该模型被部署为实时端点，以低延迟实时执行新数据的推理。图中还显示了 SageMaker Model Monitor，它连接到端点，以检测发送到端点进行推理的新数据中的数据和概念漂移。SageMaker 还提供了将我们的机器学习模型注册到 SageMaker Model Registry 的选项，用于各种目的，如编目、版本控制和自动化部署。

将机器学习模型托管为实时端点

Amazon SageMaker 为我们提供了多种选项来托管模型或多个模型作为实时端点。我们可以使用 SageMaker Python SDK、AWS SDK for Python（Boto3）、SageMaker 控制台或 AWS 命令行界面（CLI）来托管我们的模型。此外，这些端点还可以托管单个模型、单个端点中的一个容器中的多个模型，以及单个端点中使用不同容器托管的多个模型。此外，单个端点还可以托管包含预处理逻辑的序列推理管道的模型。我们将在以下小节中介绍这些多个选项。

单个模型

如前所述，我们可以使用多种选项托管模型端点。在此，我们将向您展示如何使用 Amazon SageMaker SDK 托管包含单个模型的端点。使用 Amazon SageMaker SDK 创建单个模型端点涉及两个步骤，如下所述：

Model 类用于创建可以部署为 HTTPS 端点的模型对象。我们还可以使用在 SageMaker 中训练的模型。例如，图 图 7**.7 中所示的 XGBoost 模型。
deploy() 方法用于创建 HTTPS 端点。deploy 方法需要实例类型以及部署模型所需的初始实例数量。这如图 图 7**.12 所示：

图 7.12 – 调用我们之前训练的 XGBoost 估计器的部署方法，将我们的模型部署在单个 ml.m4.xlarge 类型的实例上

图 7**.13 展示了一个自定义推理函数，用于序列化测试数据，并将其发送到实时端点进行推理：

图 7.13 – 将数据序列化以发送到实时端点。此外，创建一个辅助函数以使用端点进行推理

图 7**.14 展示了几条记录的推理结果以及我们目标变量——Rings的实际值：

图 7.14 – 显示一些预测结果与实际值（Rings）的比较

只要端点没有被删除，它就会继续产生费用。因此，我们只有在有需要实时推理结果的使用场景时才应使用实时端点。对于可以在批量中进行推理的使用场景，我们应该使用 SageMaker Batch Transform。

多个模型

对于在单个端点中托管多个模型，我们可以使用 SageMaker 多模型端点。这些端点也可以用来托管同一模型的多个变体。多模型端点是节省实时端点推理成本的一种非常经济的方法，因为当我们使用多模型端点时，端点的利用率通常更高。我们可以使用业务逻辑来决定用于推理的模型。

在多模型端点中，模型间的内存资源也是共享的。当我们的模型在大小和延迟上相当时，这非常有用。如果有模型的延迟需求或每秒事务量有显著差异，则建议为这些模型使用单模型端点。我们可以使用 SageMaker 控制台或 AWS SDK for Python（Boto3）创建多模型端点。我们可以遵循与创建单模型端点类似的步骤来创建多模型端点，但有一些不同。Boto3 的步骤如下：

首先，我们需要一个支持多模型端点部署的容器。
然后，我们需要使用 Boto3 SageMaker 客户端创建一个使用此容器的模型。
对于多模型端点，我们还需要创建一个端点配置，指定实例类型和初始计数。
最后，我们需要使用 Boto3 SageMaker 客户端的 create_endpoint() API 调用来创建端点。

在调用多模型端点时，我们还需要传递一个目标模型参数来指定我们想要使用请求中的数据进行推理的模型。

多个容器

我们还可以部署使用不同容器（如不同框架）的模型作为多容器端点。这些容器可以单独运行，也可以作为推理管道按顺序运行。多容器端点也有助于提高端点利用率效率，从而降低与实时端点相关的成本。可以使用 Boto3 创建多容器端点。创建多容器端点的过程与创建多模型和单模型端点非常相似。首先，我们需要创建一个具有多个容器的模型作为参数，然后创建端点配置，最后创建端点。

推理管道

我们也可以将包含两个到五个容器的实时端点作为单个端点后面的推理管道托管。这些容器中的每一个都可以是预训练的 SageMaker 内置算法、我们的自定义算法、预处理代码、预测或后处理代码。推理管道中的所有容器以顺序方式运行。第一个容器处理初始 HTTP 请求。来自第一个容器的响应作为请求发送到第二个容器，依此类推。来自最终容器的响应由 SageMaker 发送到客户端。推理管道可以被视为一个可以托管在单个端点后面或用于运行批量转换作业的单个模型。由于推理管道中的所有容器都在同一个 EC2 实例上运行，因此容器之间的通信延迟非常低。

监控已部署的模型

在将模型部署到生产环境中后，数据科学家和机器学习工程师需要持续检查模型的质量。这是因为随着时间的推移，模型的质量可能会漂移，并可能开始做出错误的预测。这可能是由几个原因造成的，例如数据集中一个或多个变量的分布发生变化，随着时间的推移在数据集中引入偏差，或者某些其他未知的过程或参数发生变化。

传统上，数据科学家通常每隔几周运行一次分析，以检查数据或模型质量是否发生变化，如果有变化，他们需要再次经历特征工程、模型训练和部署的整个过程。使用 SageMaker Model Monitor，这些步骤可以自动化。我们可以设置警报来检测数据质量、模型质量、模型中的偏差漂移和特征分布漂移是否有任何偏移，然后采取纠正措施，例如修复质量问题并重新训练模型。

图 7.15 展示了使用 SageMaker Model Monitor 与端点（实时或异步）的示例：

图 7.15 – 部署端点的 SageMaker Model Monitor 工作流程（实时或异步）

首先，我们需要在我们的端点上启用 Model Monitor，无论是在创建时还是之后。此外，我们还需要运行一个基线处理作业。这个处理作业分析数据并为基线数据（通常是模型训练或验证所用的相同数据集）创建统计和约束。我们还需要在我们的 SageMaker 端点上启用数据捕获，以便能够捕获新的数据以及推理结果。然后，在固定的时间间隔运行另一个处理作业，以创建新的统计和约束，将它们与基线统计和约束进行比较，并在分析指标中存在任何偏移的情况下，使用 Amazon CloudWatch 指标配置警报。

如果任何指标发生违规，将生成警报，并且可以将这些警报发送给数据科学家或机器学习工程师进行进一步分析，并在需要时重新训练模型。或者，我们也可以使用这些警报来触发一个工作流程（MLOps），以重新训练我们的机器学习模型。模型监控器是数据科学家的一个非常有价值的工具。它可以减少在模型部署后随着时间的推移检测数据集和模型偏差和漂移的繁琐手动过程。

异步推理

SageMaker 实时端点适用于具有非常低延迟推理要求（最多 60 秒）的机器学习用例，以及推理数据的大小不是很大（最大 6 MB）。另一方面，批量转换适用于对非常大的数据集进行离线推理。异步推理是 SageMaker 中另一种相对较新的推理选项，可以处理高达 1 GB 的数据，并且处理推理请求可能需要长达 15 分钟。因此，它们适用于没有非常低延迟推理要求的用例。

异步端点与实时端点有多个相似之处。要创建异步端点，就像创建实时端点一样，我们需要执行以下步骤：

创建一个模型。
为异步端点创建端点配置。异步端点有一些额外的参数。
创建异步端点。

与实时端点相比，异步端点也有一些不同之处，如下所述：

与实时端点的一个主要不同之处在于，当没有推理请求时，我们可以将端点实例的规模降至零。这可以减少与端点推理相关的成本。
与实时端点相比的另一个关键区别是，我们不是在推理请求中按顺序传递有效负载，而是将数据上传到 Amazon S3 位置，并将 S3 URI 与请求一起传递。内部，SageMaker 保留这些请求的队列，并按接收顺序处理它们。就像实时端点一样，我们也可以对异步端点进行监控，以检测模型和数据漂移，以及新的偏差。

展示 SageMaker 异步端点的代码在图 7.16中，使用我们在批量转换示例中创建的相同模型。

图 7.16 – 创建异步端点配置，随后创建异步端点

图 7.17显示了在之前章节中用于批量转换和实时端点示例的 Abalone 数据上执行异步推理的样本结果。

图 7.17 – 序列化推理请求并调用异步端点对数据进行推理。

图 7.18 展示了几个数据点的实际和预测结果。

图 7.18 – 使用异步端点显示一些预测结果与实际值（环）的对比

在下一节中，我们将探讨 SageMaker 端点的高可用性和容错能力。

模型端点的高可用性

Amazon SageMaker 提供了已部署端点的容错性和高可用性。在本节中，我们将讨论 AWS 云基础设施和 Amazon SageMaker 的各种功能和选项，我们可以使用这些功能和选项来确保我们的端点是容错的、有弹性的和高度可用的。

在多个实例上部署

SageMaker 给我们提供了在多个实例上部署端点的选项。这可以防止实例故障。如果一个实例宕机，其他实例仍然可以处理推理请求。此外，如果我们的端点部署在多个实例上，并且发生可用区故障或实例故障，SageMaker 会自动尝试将我们的实例分布到不同的可用区，从而提高端点的弹性。将端点部署使用不同可用区的小型实例类型也是一种良好的实践。

端点自动扩展

通常，我们为峰值负载和流量设计我们的在线应用程序。对于基于机器学习的应用程序也是如此，我们需要托管端点以实时或近实时地进行推理。在这种情况下，我们通常使用最大数量的实例来部署模型，以便服务于峰值工作负载和流量。

如果我们不这样做，那么当推理请求多于实例可以处理的总量时，我们的应用程序可能会开始超时。这种方法会导致计算资源的浪费或我们机器学习应用程序服务的中断。

为了避免这种场景，Amazon SageMaker 允许我们使用自动扩展策略来配置我们的端点。使用自动扩展策略，随着流量的增加，我们的端点部署的实例数量也会增加，随着流量的减少而减少。这不仅有助于提高我们的推理端点的高可用性，还有助于显著降低成本。我们可以通过 SageMaker 控制台、AWS CLI 或应用程序自动扩展 API 来为模型启用自动扩展。

为了应用自动扩展，我们需要一个自动扩展策略。自动扩展策略使用 Amazon CloudWatch 指标和由我们指定的目标值来决定何时向上或向下扩展实例。我们还需要定义端点可以部署的最小和最大实例数。自动扩展策略的其他组件包括执行自动扩展所需的权限、服务关联的 IAM 角色以及缩放活动后的冷却期，在开始下一次缩放活动之前等待一段时间。

图 7.19 – 7.22 显示使用 Amazon SageMaker 控制台在异步端点上配置自动扩展：

图 7**.19 显示，最初端点仅部署在单个实例上：

图 7.19 – 端点运行时间设置显示端点正在实例上部署且未使用自动扩展

点击配置自动扩展按钮后，您的屏幕应类似于图 7**.20和图 7**.21中所示。

如图 7**.20所示，我们需要将最小和最大实例数分别更新为2和10。

图 7.20 – 在端点上配置自动扩展以使用 2 – 10 个实例，根据流量（使用 SageMaker 控制台）。

如图 7**.21所示，我们需要更新200的值。

图 7.21 – 设置自动扩展的缩放时间和目标指标阈值以触发自动扩展

一旦达到此目标值并且我们走出冷却期，无论我们是在目标值之上还是之下，SageMaker 都会自动启动新实例或关闭实例。

图 7**.22 显示端点更新后应用我们的自动扩展策略的结果。

图 7.22 – 应用自动扩展策略后运行的端点

应用自动扩展策略后，也可以更新或删除该策略。

无中断的端点修改

我们还可以修改已部署的端点，而不会影响在生产中部署的模型的可用性。除了在上一节中讨论的应用自动扩展策略外，我们还可以更新端点的计算实例配置。我们还可以添加新的模型变体并更改不同模型变体之间的流量模式。所有这些任务都可以在不影响生产中部署的端点的情况下完成。

现在我们已经讨论了如何确保我们的端点具有高可用性，接下来让我们讨论蓝/绿部署。

蓝绿部署

在一个生产环境中，我们的模型正在实时或接近实时地运行以进行推理，当我们需要更新我们的端点时，确保这一过程不会造成任何中断或问题非常重要。Amazon SageMaker 在更新我们的端点时自动使用蓝/绿部署方法。在这种场景下，一个新的集群，称为绿色集群，被配置了我们的更新端点。然后，工作负载从旧的集群（称为蓝色集群）转移到绿色集群。经过一段评估期以确保一切运行正常，没有出现任何问题后，蓝色集群被终止。SageMaker 还提供了以下三种不同的流量转移模式，用于蓝/绿部署，使我们能够对流量转移模式有更多的控制。

同时全部更新

在这种流量转移模式下，所有流量一次性从蓝色集群转移到绿色集群。蓝色（旧）集群在一段时间内（称为烘烤期）保持运行，以确保一切正常，性能和功能符合预期。烘烤期结束后，一次性终止蓝色集群。这种类型的蓝绿部署最小化了整体更新时间，同时也最小化了成本。一次性方法的缺点是，回归性更新会影响所有流量，因为整个流量一次性转移到绿色集群。

金丝雀

在金丝雀蓝/绿部署中，首先将一小部分流量从蓝色集群转移到绿色集群。这部分开始服务部分流量的绿色集群被称为金丝雀，其容量应小于新集群容量的 50%。如果在烘烤期间一切正常，没有触发 CloudWatch 警报，则其余流量也将转移到绿色集群，之后终止蓝色集群。如果在烘烤期间触发任何警报，SageMaker 将所有流量回滚到蓝色集群。

使用金丝雀蓝/绿部署的优势在于，它将回归性更新的影响范围仅限于金丝雀集群，而不是整个集群，这与一次性蓝/绿部署不同。使用金丝雀部署的缺点是，在整个部署期间，蓝色和绿色集群都处于运行状态，从而增加了成本。

线性

在线性蓝/绿部署中，流量以预指定的固定步骤从蓝色舰队转移到绿色舰队。一开始，流量的一部分转移到绿色舰队，同时相同比例的蓝色舰队被停用。如果在烘烤期间没有警报响起，SageMaker 将启动第二部分的转移，依此类推。如果在任何时刻警报响起，SageMaker 将所有流量回滚到蓝色舰队。由于流量是分步骤转移到绿色舰队的，线性蓝/绿部署显著降低了回归更新的风险。线性部署方法的成本与配置用于将流量从蓝色舰队转移到绿色舰队的步骤数量成正比。

如本节所述，SageMaker 具有这些蓝/绿部署方法，以确保我们在更新端点时有安全防护措施。这些蓝/绿部署方法确保我们能够在生产环境中以无干扰或最小干扰的方式更新我们的推理端点。

现在让我们总结一下本章所涵盖的内容。

摘要

在本章中，我们讨论了使用 Amazon SageMaker 时可以使用的各种托管部署方法。我们讨论了不同部署/推理方法对不同用例类型的适用性。我们展示了如何进行批量推理和部署实时和异步端点。我们还讨论了如何配置 SageMaker 以自动扩展和缩减，以及 SageMaker 如何确保在发生故障时，我们的端点被部署到多个可用区。我们还简要介绍了 Amazon SageMaker 提供的各种蓝/绿部署方法，以便在生产环境中更新我们的端点。

在许多实际场景中，我们没有高性能的实例集群可用于实时处理新数据和未见数据。对于此类应用，我们需要使用边缘计算设备。这些设备通常在计算能力、内存、连接性和带宽方面有限制，并且需要模型被优化以便能够在这些边缘设备上使用。

在下一章中，我们将扩展这一讨论，了解如何在边缘设备上使用机器学习模型。

参考文献

您可以参考以下资源获取更多信息：

在单个端点上托管多个模型：docs.aws.amazon.com/sagemaker/latest/dg/multi-model-endpoints.html
Amazon EC2 Inf1 实例：aws.amazon.com/ec2/instance-types/inf1/
使用 SageMaker 批量转换自己的推理代码：docs.aws.amazon.com/sagemaker/latest/dg/your-algorithms-batch-code.html
单个端点后多个不同容器模型：docs.aws.amazon.com/sagemaker/latest/dg/multi-container-endpoints.html
Amazon SageMaker 上的无服务器推理：docs.aws.amazon.com/sagemaker/latest/dg/serverless-endpoints.html
使用 Amazon SageMaker 的蓝绿部署：docs.aws.amazon.com/sagemaker/latest/dg/deployment-guardrails-blue-green.html
金丝雀流量切换：docs.aws.amazon.com/sagemaker/latest/dg/deployment-guardrails-blue-green-canary.html
SageMaker 的 Transformer 类：sagemaker.readthedocs.io/en/stable/api/inference/transformer.html?highlight=transformer
Amazon SageMaker 实时推理：docs.aws.amazon.com/sagemaker/latest/dg/realtime-endpoints-deployment.html
使用 Amazon SageMaker 运行模型的最佳实践：docs.aws.amazon.com/sagemaker/latest/dg/deployment-best-practices.html

第八章：优化和管理适用于边缘部署的机器学习模型

每个机器学习（ML）从业者都知道，机器学习开发生命周期是一个极其迭代的过程，从收集、探索和为我们的算法工程正确的特征，到训练、调整和优化机器学习模型以进行部署。作为机器学习从业者，我们花费高达 80%的时间来获取训练机器学习模型所需的数据，最后 20%的时间实际上是在训练和调整机器学习模型。在过程结束时，我们可能都感到非常欣慰，因为我们终于有一个优化的机器学习模型，我们往往没有足够关注最终模型是如何部署的。因此，重要的是要认识到，训练模型部署的位置和方式对整个机器学习用例有重大影响。例如，假设我们的机器学习用例是针对自动驾驶汽车（AVs），特别是训练来检测其他车辆的计算机视觉（CV）模型。一旦我们的 CV 模型被训练和优化，我们就可以部署它。

但是我们在哪里部署它？是部署在车辆本身上，还是部署在训练 模型 所使用的相同基础设施上？

好吧，如果我们将模型部署到我们用于训练模型的相同基础设施上，我们还需要确保车辆可以连接到这个基础设施。我们还需要确保从车辆到模型的连接足够稳健和高效，以确保模型推理结果及时。如果车辆无法及时检测到迎面而来的车辆，那将是灾难性的。因此，在这种情况下，在车辆本身上执行模型推理可能更好；这样，我们就无需担心车辆和机器学习模型之间的网络连接、弹性、带宽和延迟。本质上，就是在边缘设备上部署和执行机器学习模型推理。

然而，在边缘部署和管理机器学习模型给机器学习开发生命周期带来了额外的复杂性。因此，在本章中，我们将回顾一些这些复杂性，并通过一个实际示例，我们将看到如何确切地优化、管理和部署边缘的机器学习模型。因此，我们将涵盖以下主题：

理解边缘计算
审查最佳边缘部署的关键考虑因素
设计用于最佳边缘部署的架构

技术要求

要完成本章中的动手示例，你应该具备以下先决条件：

网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）
访问你在第五章，数据分析中使用的 AWS 账户
访问我们在第五章，数据分析中创建的 Amazon SageMaker Studio 开发环境
本章的示例代码可在配套的 GitHub 仓库中找到（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter08）

理解边缘计算

要了解我们如何优化、管理和部署边缘的 ML 模型，我们首先需要了解什么是边缘计算。边缘计算是一种模式或架构类型，它将数据存储机制和计算资源更靠近实际的数据源。因此，通过将这些资源靠近数据本身，我们从根本上提高了整体应用程序的响应性，并消除了提供最佳和弹性网络带宽的需求。

因此，如果我们参考本章开头强调的 AV 示例，通过将 CV 模型靠近数据源，即实时的摄像头视频流，我们能够实时检测其他车辆。因此，我们不需要让我们的应用程序连接到托管训练模型的底层基础设施，而是将摄像头视频发送到 ML 模型，检索推理结果，最后，根据结果让应用程序采取一些行动。

现在，使用边缘计算架构，我们可以直接将摄像头视频发送到车辆内部的计算资源上运行的训练好的 CV 模型，并根据实时检索到的推理结果让应用程序采取一些行动。因此，通过使用边缘计算架构，我们减轻了连接到 CV 模型托管基础设施所带来的任何不必要的应用程序延迟。随后，我们允许车辆实时对检测到的其他车辆做出反应。此外，我们消除了对弹性光纤网络连接的依赖。

然而，尽管边缘计算架构提供了改进的应用程序响应时间，但该架构本身也引入了额外的复杂性，尤其是在其设计和实现方面。因此，在下一节中，我们将回顾在最佳部署 ML 模型到边缘时需要考虑的一些关键因素。

检查最佳边缘部署的关键考虑因素

如前两章所述，在设计适用于大规模训练和部署机器学习模型的适当架构时，需要考虑几个关键因素。在这两章中，我们还看到了如何使用 Amazon SageMaker 来实现执行这些任务的有效临时基础设施。因此，在本章的后续部分，我们还将回顾如何使用 SageMaker 在边缘大规模部署机器学习模型。然而，在我们深入使用 SageMaker 进行边缘部署之前，回顾一些影响边缘部署机器学习模型成功的关键因素是很重要的：

效率
性能
可靠性
安全性

虽然并非所有提到的因素都会影响边缘架构的设计，也不一定对机器学习用例至关重要，但至少考虑它们是很重要的。因此，让我们首先考察效率在边缘架构设计中的重要性。

效率

按定义，效率是输出与输入之间的比率或百分比。当机器学习模型在边缘部署时，它使执行更接近应用程序，以及用于生成推理的输入数据。因此，我们可以这样说，将机器学习模型部署到边缘默认使其变得高效。然而，这个假设是基于机器学习模型仅根据输入数据提供推理结果，并且不需要在之前对输入数据进行任何预处理的事实。

例如，如果我们参考 CV 模型示例，如果提供给机器学习模型的图像数据需要预处理，例如，图像需要调整大小，或者图像张量需要归一化，那么这个预处理步骤为机器学习模型引入了更多的工作。因此，这个机器学习模型不如一个仅提供推理结果而不进行任何预处理的模型高效。

因此，在设计边缘部署的架构时，我们需要减少在输入数据上执行的不必要工作，以进一步简化推理结果，从而使推理尽可能高效。

性能

性能的衡量与效率的衡量类似，只不过它不是一个比率，而是一个质量的测量。因此，当衡量部署到边缘的机器学习模型的质量时，我们衡量模型提供推理结果的速度以及推理结果的准确性。因此，就像效率一样，将机器学习模型的推理结果更接近数据源确实可以提高整体性能，但还需要考虑特定于机器学习用例的权衡。

以 CV 用例为例，我们可能需要通过压缩或剪枝模型架构来妥协模型推理结果的质量，使其更小，以便适应有限的内存，并在边缘计算设备的有限处理能力上运行。此外，尽管大多数 CV 算法在训练和推理时都需要 GPU 资源，但我们可能无法为边缘设备提供 GPU 资源。

因此，在设计边缘部署的架构时，我们需要预测边缘可用的计算资源，并探索如何重构训练好的机器学习模型，以确保它能够适应边缘设备，并在最短的时间内提供最佳的推理结果。

可靠性

根据机器学习用例以及模型推理结果的使用方式，可靠性可能不是影响边缘架构设计的决定性因素。例如，如果我们考虑自动驾驶用例，检测附近其他车辆对乘客来说是生死攸关的问题。另一方面，如果不能使用机器学习模型来预测智能恒温器上的未来温度波动，可能只是不便，但并不一定是影响边缘架构设计的决定性因素。

能够检测到部署的机器学习模型失败并发出警报是边缘架构整体可靠性的关键方面。因此，在边缘管理机器学习模型的能力成为边缘架构整体可靠性的关键要素。可能影响架构可靠性和可管理性的其他因素是所使用的通信技术。这些技术可能提供不同级别的可靠性，可能需要多种不同类型。例如，在自动驾驶用例中，车辆可能将蜂窝连接作为主要通信技术，如果这失败了，可以使用卫星链路作为备份。

因此，在设计边缘部署的架构时，可靠性可能不是一个关键因素，但能够管理部署到边缘的模型也是架构整体可扩展性的一个重要因素。

安全性

就像可靠性一样，安全性可能不是影响边缘架构设计的决定性因素，而是更具体地取决于用例本身。例如，可能需要加密存储在边缘架构上的所有数据。至于部署在边缘架构上的机器学习模型，这意味着所有推理数据（包括机器模型请求和响应数据）都必须在边缘架构上加密。此外，架构内部和外部传输的任何数据也必须加密。

重要的是要记住，从安全管理角度来看，存在从集中式信任模型到去中心化信任模型的转变，并且边缘架构中的计算资源受限于大小和性能能力。因此，加密类型的选择有限，因为高级加密需要额外的计算资源。

现在我们已经回顾了一些影响机器学习模型部署最佳边缘架构设计的关键因素，在下一节中，我们将深入探讨如何使用 Amazon SageMaker 以及其他专注于边缘设备管理的 AWS 服务来构建最佳边缘架构。

设计最佳边缘部署的架构

尽管有许多关键因素会影响边缘架构设计，正如前文所述，但还需要一个关键能力来启用这些因素，即构建、部署和管理边缘设备软件的能力。此外，我们还需要管理应用的能力，本质上是指部署到边缘设备上运行的机器学习模型。因此，AWS 通过一个名为AWS IoT Greengrass的专用设备管理服务提供了这两种管理能力，以及内置在 Amazon SageMaker 中的机器学习模型管理能力，称为Amazon SageMaker Edge(aws.amazon.com/greengrass/)和aws.amazon.com/sagemaker/edge)。AWS IoT Greengrass 是 AWS 提供的一项服务，可以在无需固件更新的情况下大规模部署软件到远程设备。图 8.1展示了利用 Greengrass 和 SageMaker 支持边缘部署的架构示例。

Figure 8.1 – 使用 Amazon SageMaker 和 IoT Greengrass 进行边缘部署的架构

如 图 8**.1 所示，典型的架构分为两个独立的架构。一个用于基于云的组件，另一个用于边缘组件。从高层次来看，云环境用于构建、部署和管理部署到边缘的用例应用程序。相应的边缘环境，或在此情况下企业数据中心，是边缘设备所在之处，并依次通过运行支持的 ML 模型来执行 ML 用例。从 ML 用例的角度来看，图 8**.1 还显示了连接到边缘服务器设备的摄像头，允许任何捕获的视频流到 ML 模型，以便模型对视频帧中检测到的对象进行分类。图 8**.1 展示了 CV 用例的简化流程，从在 SageMaker 上训练 ML 模型到使用 Greengrass 部署到边缘服务器，然后管理和监控解决方案。但构建实际解决方案非常复杂。

因此，为了说明这种复杂性，在下一节中，我们将通过分解每个组件来构建此架构，从企业数据中心或边缘架构开始。

构建边缘组件

如前文所述，企业数据中心作为我们的 CV 用例的边缘位置。在这个边缘位置内部，我们有一些摄像头，连接到计算设备或边缘服务器，运行 CV 模型。由于我们没有访问企业数据中心，在本书的背景下，我们将使用 弹性计算云 （EC2）实例来模拟构建边缘环境。

注意

如果您不习惯使用 EC2 实例，您可以通过参考以下文档来熟悉它们：aws.amazon.com/ec2/getting-started/。

以下步骤将演示如何使用 EC2 实例设置边缘服务器，并配置必要的 Greengrass 软件以及所需的安全权限。让我们开始设置适当的 身份和访问管理 （IAM）角色和权限：

登录您的 AWS 账户并打开 IAM 控制台 (console.aws.amazon.com/iam/home)。
一旦打开 IAM 控制台，请使用左侧导航面板并点击角色以打开角色仪表板。然后点击右上角的 创建角色 按钮。
一旦启动 创建角色 向导，请选择 AWS 服务 作为 受信任 实体类型。
对于用例，选择 EC2 并点击 下一步 按钮。
在 添加权限 页面上，点击右上角的 创建策略 按钮以打开创建策略页面。
在 GitHub 上的SageMakerGreenGrassV2MinimalResourcePolicy.json文件（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/blob/main/Chapter08/SageMakerGreenGrassV2MinimalResourcePolicy.json），并确保将策略中的<account_id>标签更新为您的 AWS 账户 ID。
点击下一步：****标签按钮。
点击下一步：****审查按钮。
在SageMakerGreenGrassV2MinimalResourcePolicy上，然后点击创建****策略按钮。
从步骤 5的添加权限页面返回，刷新页面以捕获新创建的 IAM 策略。
在搜索栏中搜索SageMakerGreenGrassV2MinimalResourcePolicy策略，一旦找到，选择策略的复选框以添加权限，然后点击下一步按钮。
在SageMakerGreenGrassV2MinimalResourceRole上，作为角色名称。
再次使用SageMakerGreenGrassV2MinimalResourceRole角色打开角色****摘要页面。
现在，点击添加权限下拉菜单并选择附加****策略选项。
在搜索栏中搜索AmazonSageMakerEdgeDeviceFleetPolicy策略，并点击复选框以选择此策略。
重复步骤 15中显示的过程，但这次选择AmazonSageMakerFullAccess、AWSIoTLogging、AmazonS3FullAccess、AWSIoTRuleActions、AWSIoTThingsRegistration和AmazonSSMManagedInstanceCore策略的复选框。
选择这些策略后，点击附加****策略按钮。
在策略选项中。

在创建策略页面，点击JSON选项卡并添加以下策略声明：

    "Version":"2012-10-17",

    "Statement":[

        "Sid":"GreengrassComponentAccess",

        "Effect":"Allow",

        "Action":[

            "greengrass:CreateComponentVersion",

            "greengrass:DescribeComponent"

],

        "Resource":"*"

点击审查****策略按钮。
将策略命名为GreengrassComponentAccessPolicy，然后点击创建****策略按钮。
在角色摘要页面，点击信任关系选项卡，然后点击编辑信任****策略按钮。

用以下信任策略声明替换现有的策略：

    "Version": "2012-10-17",

    "Statement": [

            "Effect": "Allow",

            "Principal": {

                "Service": "ec2.amazonaws.com"

},

            "Action": "sts:AssumeRole"

},

            "Effect": "Allow",

            "Principal": {

                "Service": "credentials.iot.amazonaws.com"

},

            "Action": "sts:AssumeRole"

},

            "Effect": "Allow",

            "Principal": {

                "Service": "sagemaker.amazonaws.com"

},

            "Action": "sts:AssumeRole"

现在我们已经设置了必要的权限，接下来我们可以按照以下步骤配置边缘服务器，这些步骤展示了如何配置 EC2 实例：

在创建 EC2 实例之前，我们需要配置必要的脚本，以将 EC2 实例定制为边缘服务器。为了提供对 AWS 资源的简单命令行访问，打开AWS CloudShell控制台（console.aws.amazon.com/cloudshell/home）。

一旦浏览器中的 CloudShell 控制台初始化完成，通过运行以下命令克隆配套的 GitHub 仓库：

$ git clone https://github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS src && cd src/Chapter08

接下来，我们创建一个 S3 存储桶，并通过运行以下命令存储 EC2 实例的配置脚本：

$ export AWS_ACCOUNT=$(aws sts get-caller-identity --query "Account" --output text)

$ aws s3 mb s3://ec2-scripts-$AWS_REGION-$AWS_ACCOUNT

$ aws s3 sync scripts s3://ec2-scripts-$AWS_REGION-$AWS_ACCOUNT/scripts

运行以下命令以捕获包含 EC2 配置脚本的 S3 存储桶的名称：
```
$ echo ec2-scripts-$AWS_REGION-$AWS_ACCOUNT
```

注意

请确保记住包含 EC2 实例配置脚本的 S3 存储桶名称，因为它将在后续步骤中使用。

在浏览器标签页中打开 EC2 管理控制台 (console.aws.amazon.com/ec2/v2/home)。
一旦打开 EC2 控制台，点击 启动实例按钮。
在 edge-server 作为此实例的名称。
选择 AMI 为 amzn2-ami-kernel-5.10-hvm-2.0.20220426.0-x86_64-gp2，实例类型为 c5.large。
滚动到 20 GiB 的根卷。
在 高级详情部分的 IAM 实例配置文件下拉框中，选择 SageMakerGreenGrassV2MinimalResourceRole 角色。

在 高级详情部分的 用户数据文本框中，粘贴以下 Bash 代码：

#!/bin/bash

aws s3 cp s3://<REPLACE WITH THE NAME OF YOUR S3 BUCKET>/scripts/ /home/ec2-user --recursive

sleep 30

process_id=$!

wait $process_id

sudo yum update -y

sudo yum install docker -y

sudo yum install python-pip -y

sudo pip3 install boto3

sudo pip3 install requests

cd /home/ec2-user

python3 getResourceTempCredentials.py

sudo service docker start

sudo usermod -a -G docker ec2-user

docker build -t "aws-iot-greensgrass:2.5" ./

chmod +x dockerRun.sh

注意

确保将 S3 存储桶名称替换为步骤 4 输出中的您的 S3 存储桶名称。

点击 启动实例按钮以创建 EC2 实例。
在登录到 EC2 实例之前，请等待 10 分钟，因为用户数据中的 Bash 脚本需要一些时间来安装必要的软件包并构建 AWS IoT Greengrass 软件的 Docker 镜像。

登录到 EC2 实例，并确保您位于 /home/ec2-user 目录。使用 env 文件，并确保 AWS_REGION 变量设置为当前使用的 AWS 区域。例如，以下输出显示了为 us-east-1 区域配置的 env 文件：

GGC_ROOT_PATH=/greengrass/v2

AWS_REGION=us-east-1

PROVISION=true

THING_NAME=mything

THING_GROUP_NAME=mythinggroupname

TES_ROLE_NAME=GreengrassV2TokenExchangeRole

TES_ROLE_ALIAS_NAME=GreengrassCoreTokenExchangeRoleAlias

COMPONENT_DEFAULT_USER=ggc_user:ggc_group

DEPLOY_DEV_TOOLS=true

注意

您还可以自定义 THING_NAME 和 THING_GROUP_NAME 参数。但是，请确保这些变量是小写。

保存并退出 env 文件。
通过执行以下命令运行 Docker 容器：
```
$ ./dockerRun.sh
```

注意

如果需要重新启动 Greengrass V2 Docker 容器，请确保通过运行以下命令获取新的凭据：

$ rm credentials # 删除旧的 credentials 文件

$ sudo python3 getResourceTempCredentials.py # 使用 new credentials 创建凭据文件`

$ ./``dockerRun.sh

打开另一个终端窗口，登录到 EC2 实例，并运行以下命令以验证 Greengrass V2 是否正在运行并检索容器 ID：
```
$ docker ps
```
然后，您可以运行以下命令来访问容器并探索容器内运行的 AWS IoT Greengrass Core 软件：
```
$ docker exec -it container-id /bin/bash
```

注意

当您使用 docker exec 在 Docker 容器内运行命令时，这些命令不会记录在 Docker 日志中。作为最佳实践，我们建议您将命令记录在 Docker 日志中，以便在需要调试任何问题时可以查看 Greengrass Docker 容器的状态。

在不同的终端中运行以下命令。它将您的终端的输入、输出和错误附加到当前运行的容器。这将帮助您从终端查看和控制容器。
```
$ docker attach container-id
```

通过执行这些步骤，我们实际上已经配置了一个 EC2 实例来运行我们的机器学习模型作为边缘服务器。因此，随着我们架构的边缘组件成功构建，我们可以继续构建机器学习模型。

构建机器学习模型

构建机器学习模型涉及训练一个适合我们业务用例的最优机器学习模型。正如我们在前面的章节中看到的，Amazon SageMaker 为我们提供了独特的功能，使我们能够摄取和处理必要的训练数据，以及训练和优化最佳的机器学习模型。此外，我们还看到 SageMaker 允许我们在云中部署和托管这些模型，而且正如我们将要看到的，SageMaker 还允许我们在边缘部署和管理机器学习模型。

以下步骤将指导您如何构建一个适合我们用例的机器学习模型，为边缘环境编译模型，然后将模型部署到边缘，所有这些操作都使用 SageMaker：

在您的 AWS 账户中，打开 Amazon SageMaker 管理控制台 (console.aws.amazon.com/sagemaker/home)。
启动 SageMaker Studio IDE。

注意

关于如何创建和启动 SageMaker Studio IDE 的更多信息，请参阅 第五章 的 设置 EMR 和 SageMaker Studio 部分，数据分析。

一旦 SageMaker Studio IDE 启动，使用 Applied-Machine-Learning-and-High-Performance-Computing-on-AWS 文件夹展开它。
然后，双击 Chapter_8 文件夹以打开它进行浏览。
双击 sagemaker_notebook 文件夹，然后启动 1_compile_resnet_model_egde_manager.ipynb 笔记本。
一旦笔记本启动，使用菜单栏选择 Kernel 菜单，然后选择 Restart Kernel and Run All Cells… 选项。

笔记本运行完毕后，我们的图像分类模型将在边缘服务器上运行，并作为机群的一部分进行管理。尽管如此，让我们通过回顾笔记本中的一些重要代码单元来验证这一点。笔记本的第一部分下载了一个已经优化或预训练的 sagemaker_model：

from sagemaker.pytorch.model import PyTorchModel
from sagemaker.predictor import Predictor
sagemaker_model = PyTorchModel(
    model_data=model_uri,
    predictor_cls=Predictor,
    framework_version=framework_version,
    role=role,
    sagemaker_session=sagemaker_session,
    entry_point="inference.py",
    source_dir="code",
    py_version="py3",
    env={"MMS_DEFAULT_RESPONSE_TIMEOUT": "500"},
)

在定义了模型对象之后，我们使用 SageMaker Neo (docs.aws.amazon.com/sagemaker/latest/dg/neo.html) 编译一个适合边缘设备特定计算架构的模型，在这种情况下，是我们的 X86_64 Linux 边缘服务器：

sagemaker_client = boto3.client("sagemaker", region_name=region)
target_arch = "X86_64"
target_os = 'LINUX'
response = sagemaker_client.create_compilation_job(
    CompilationJobName=compilation_job_name,
    RoleArn=role,
    InputConfig={
        "S3Uri": sagemaker_model.model_data,
        "DataInputConfig": data_shape,
        "Framework": framework,
    },
    OutputConfig={
        "S3OutputLocation": compiled_model_path,
#         "TargetDevice": 'jetson_nano',
        "TargetPlatform": {
            "Arch": target_arch,
            "Os": target_os
        },
    },
    StoppingCondition={"MaxRuntimeInSeconds": 900},
)

注意

请确保注意编译模型的 S3 路径，因为我们将会使用这个路径来部署模型包。

在为边缘服务器编译了模型之后，我们通过将其作为 SageMaker 托管的端点部署来验证模型的功能，然后使用以下代码为测试图像生成一个样本推理：

import numpy as np
import json
with open("horse_cart.jpg", "rb") as f:
    payload = f.read()
    payload = bytearray(payload)
response = runtime.invoke_endpoint(
    EndpointName=ENDPOINT_NAME,
    ContentType='application/octet-stream',
    Body=payload,
    Accept = 'application/json')
result = response['Body'].read()
result = json.loads(result)
print(result)

一旦我们验证了模型能够正确地工作，即能够正确地分类图像，我们就可以按照以下代码片段所示打包模型：

packaging_job_name = compilation_job_name + "-packaging-ggv2"
component_name = "SagemakerEdgeManager" + packaging_job_name
response = sagemaker_client.create_edge_packaging_job(
    RoleArn=role,
    OutputConfig={
        "S3OutputLocation": s3_edge_output_location,
    },
    ModelName=packaged_model_name,
    ModelVersion=model_version,
    EdgePackagingJobName=packaging_job_name,
    CompilationJobName=compilation_job_name,
)

最后，一旦模型打包完成，我们可以使用create_device_fleet()方法创建一个可管理的边缘设备编队来托管新编译的 ML 模型，然后使用register_device()方法初始化我们的 EC2 边缘服务器作为已注册或管理的边缘设备，该设备运行我们的 ML 模型：

s3_device_fleet_output = os.path.join(s3_edge_output_location, 'fleet')
iot_role_arn = f'arn:aws:iam::{account_id}:role/SageMakerGreenGrassV2MinimalResourceRole'
device_fleet_name = "mydevicefleet"
device_name = 'mything'
sagemaker_client.create_device_fleet(
    DeviceFleetName=device_fleet_name,
    RoleArn=iot_role_arn, # IoT Role ARN specified in previous step
    OutputConfig={
        'S3OutputLocation': s3_device_fleet_output
    }
)
sagemaker_client.register_devices(
    DeviceFleetName=device_fleet_name,
    Devices=[
        {
            "DeviceName": device_name,
            "IotThingName": device_name
        }
    ]
)

一旦模型经过训练和编译，并将边缘服务器注册为 SageMaker 管理的边缘设备，我们就可以继续部署模型包到边缘服务器。

部署模型包

要将模型包部署到边缘服务器，我们将将其注册为 Greengrass 组件，然后使用 Greengrass 控制台将组件部署到边缘服务器。以下步骤将指导我们如何完成此操作：

使用网页浏览器打开 AWS IoT 管理控制台（console.aws.amazon.com/iot/home）。
在左侧导航面板的管理部分，展开Greengrass 设备选项，然后点击组件。
点击创建组件按钮。
将com.greengrass.SageMakerEdgeManager.ImageClassification.Model.json文件内容输入到配方框中。

注意

com.greengrass.SageMakerEdgeManager.ImageClassification.Model.json文件可以在配套的 GitHub 仓库中找到（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/blob/main/Chapter08/custom_component_recipes/com.greengrass.SageMakerEdgeManager.ImageClassification.Model.json）。

更新 JSON 文件中Artifacts标签下打包模型的 S3 位置，以匹配编译模型的 S3 路径。

注意

打包模型的 S3 位置是上一节中使用的create_compilation_job()方法的输出。

点击创建组件按钮。
前往您的 S3 存储桶，创建artifacts文件夹，并在其中创建一个名为com.greengrass.SageMakerEdgeManager.ImageClassification的另一个文件夹。您的 S3 路径应如下所示：s3://<bucket_name>/artifacts/com.greengrass.SageMakerEdgeManager.ImageClassification/。
从 GitHub 仓库（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter08）上传image_classification.zip和installer.sh文件到第 7 步中定义的 S3 位置。
更新 JSON 文件中Artifacts标签下image_classification.zip和installer.sh文件的 S3 位置，以匹配第 8 步中定义的 S3 路径。
对于com.greengrass.SageMakerEdgeManager.ImageClassification组件，重复第 3 步和第 4 步。

注意

com.greengrass.SageMakerEdgeManager.ImageClassification.json 文件可以在配套的 GitHub 仓库(github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/blob/main/Chapter08/custom_component_recipes/com.greengrass.SageMakerEdgeManager.ImageClassification.json)中找到。

在注册了 Greengrass 组件后，我们现在可以将它们部署到边缘服务器，并使用我们刚刚创建的组件运行图像分类推理。部署这些组件将下载 SageMaker Neo 编译的预训练 ML 模型，并在边缘服务器上安装 SageMaker Edge Manager 代理。然而，在我们实际部署这些组件之前，我们必须订阅通知主题，以便查看和管理边缘服务器上的任何推理任务。以下步骤将指导我们如何订阅主题：

前往 AWS IoT 控制台(console.aws.amazon.com/iot/)，然后在左侧导航面板的测试选项中点击 MQTT 测试客户端。
在 gg/sageMakerEdgeManager/image-classification。
点击订阅按钮。

由于可以监控和管理运行在边缘服务器上的 ML 模型的任何推理请求，我们可以部署 Greengrass 组件。以下步骤将展示如何进行此操作（这些步骤也在 AWS Greengrass 开发者指南docs.aws.amazon.com/greengrass/v2/developerguide/greengrass-v2-developer-guide.pdf中突出显示）：）

在 AWS IoT Greengrass 控制台(console.aws.amazon.com/greengrass) 导航菜单中，选择部署，然后选择目标设备的部署。
在部署页面，选择修订，然后选择 修订部署。
在 指定目标 页面，点击 下一步。
在 选择组件 页面的 我的组件 选项下，选择 com.greengrass.SageMakerEdgeManager.ImageClassification 和 com.greengrass.SageMakerEdgeManager.ImageClassification.Model 组件。
在 公共组件 下，关闭 仅显示所选组件 切换，然后选择 aws.greengrass.SageMakerEdgeManager 组件。
点击 下一步。
在 配置组件 页面，选择 aws.greengrass.SageMakerEdgeManager 组件，并选择 配置组件。

在 配置更新 下的 要合并的配置 中，输入以下配置：

    "DeviceFleetName": "device-fleet-name",

    "BucketName": "S3-BUCKET"

注意

将 device-fleet-name 和 S3 存储桶名称替换为在笔记本中创建设备编队时创建的相应值。

选择确认，然后选择下一步。
在配置高级设置页面，保持默认配置设置并选择下一步。
在审查页面，选择部署。

部署可能需要几分钟才能完成。组件部署完成后，我们可以在 Greengrass Core 设备的组件日志以及 AWS IoT 控制台的 AWS IoT MQTT 客户端中查看、管理和监控机器学习模型推理结果。要查看 Greengrass Core 设备的组件日志中的推理结果，请登录到边缘服务器 EC2 实例并运行以下命令：

$ sudo tail –f /greengrass/v2/logs/com.greengrass.SageMakerEdgeManager.ImageClassification.log

您应该在日志中看到类似于以下内容的“得分 0.3 或以上的前 5 个预测”：

2022-08-15T03:38:45.437Z [INFO] (Copier) com.greengrass.SageMakerEdgeManager.ImageClassification: stdout. {"timestamp": "2022-08-15 03:38:45.282879+00:00", "inference-type": "image-classification", "inference-description": "Top 5 predictions with score 0.3 or above ", "inference-results": [{"Label": "slot, one-armed bandit", "Score": "83.41295623779297"}, {"Label": "mousetrap", "Score": "75.826416015625"}, {"Label": "comic book", "Score": "73.64051055908203"}, {"Label": "microphone, mike", "Score": "71.14073181152344"}, {"Label": "honeycomb", "Score": "68.3149185180664"}]}. {scriptName=services.com.greengrass.SageMakerEdgeManager.ImageClassification.lifecycle.run.script, serviceName=com.greengrass.SageMakerEdgeManager.ImageClassification, currentState=RUNNING}

或者，您也可以通过点击左侧导航面板上的测试选项中的MQTT 测试客户端在 AWS IoT 控制台上查看结果（console.aws.amazon.com/iot/）。在订阅部分，您将看到预测结果，如下面的截图所示：

图 8.2 – 在 AWS IoT 控制台 MQTT 测试客户端上的推理结果

如果您在 MQTT 客户端看不到推理结果，部署可能已失败或未达到核心设备。这主要可能由两个原因造成：您的核心设备未连接到网络，或者它没有执行组件的正确权限。要排查问题，您可以在核心设备上运行以下命令。此命令将打开 AWS IoT Greengrass Core 软件日志文件，其中包含 Greengrass Core 设备部署服务的日志。

$ sudo tail -f /greengrass/v2/logs/greengrass.log

注意

如需更多信息，请参阅故障排除文档：docs.aws.amazon.com/greengrass/v2/developerguide/ml-troubleshooting.html。

现在 Greengrass 组件已部署到边缘服务器，我们已经成功将我们的机器学习模型部署到边缘。此外，通过利用 AWS IoT Greengrass 和 Amazon SageMaker 的能力，我们不仅使机器学习在边缘设备上高效运行并确保性能，还建立了一种管理和监控环境的机制。正如您在回顾最佳边缘部署的关键考虑因素部分所回忆的那样，这些是构成最佳边缘架构的关键因素。

摘要

在本章中，我们向您介绍了将机器学习模型部署在云之外的概念，主要是边缘架构。为了奠定边缘部署的基础，我们还探讨了边缘架构是什么，以及在设计边缘架构时需要考虑的最重要因素，即效率、性能和可靠性。

考虑到这些因素，我们探讨了如何使用 AWS IoT Greengrass 以及 Amazon SageMaker 服务在云中构建一个最优的机器学习模型包，编译后能够在边缘设备上高效运行，并且以可靠的方式部署到边缘环境中。在这个过程中，我们还强调了管理和监控边缘设备以及部署的机器学习模型对于创建最优边缘架构的重要性。

在下一章中，我们将继续探讨部署的机器学习模型的性能监控和优化。

第九章：实时推理的性能优化

机器学习（ML）和深度学习（DL）模型几乎在所有行业中都得到应用，例如电子商务、制造业、生命科学和金融。因此，为了提高这些模型的表现，已经产生了有意义的创新。自 2018 年引入基于转换器的模型以来，这些模型最初是为自然语言处理（NLP）应用开发的，模型的规模和训练模型所需的数据集规模已经呈指数增长。基于转换器的模型现在也用于预测以及计算机视觉应用，除了 NLP。

让我们回顾一下这些模型规模的增长。语言模型嵌入（ELMo），于 2018 年推出，有9360 万个参数，而生成预训练转换器模型（也称为GPT-3），在 2020 年，有1750 亿个参数。今天，我们有了具有超过1000 亿个参数的深度学习模型，如开关转换器（arxiv.org/pdf/2101.03961.pdf）。然而，用于训练和部署此类模型的硬件创新速度并没有跟上大型模型创新的速度。因此，我们需要复杂的技巧以成本效益和性能的方式训练和部署这些模型。

解决这一问题的方法之一是考虑减少模型的内存占用。此外，许多推理工作负载必须提供灵活性、高可用性以及随着企业服务数百万或数十亿用户的能力，特别是对于实时或近实时用例。我们需要了解用于部署的实例类型以及需要多少实例。我们还应该了解基于哪些关键指标来优化模型。

因此，为了共同解决上述场景，在本章中，我们将深入探讨以下主题：

减少深度学习模型的内存占用
优化模型的关键指标
选择实例类型、负载测试和模型性能调整
观察结果

重要提示

有关训练大型深度学习模型的详细信息，请参阅第六章，机器学习模型的分布式训练，其中我们详细介绍了该主题，并附带了一个示例。

技术要求

在开始本章之前，您应该具备以下先决条件：

一个网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）
访问您在第五章，数据分析中使用的 AWS 账户
访问我们在第五章，数据分析中创建的 SageMaker Studio 开发环境
本章节的示例 Jupyter 笔记本可在配套的 GitHub 仓库中找到 (github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter09)

降低深度学习模型的内存占用

一旦我们训练了模型，我们需要部署模型以获取预测结果，这些结果随后被用来提供业务洞察。有时，我们的模型可能比市场上今天可用的单个 GPU 内存大小还要大。在这种情况下，你有两个选择——要么减小模型的内存占用，要么使用分布式部署技术。因此，在本节中，我们将讨论以下技术来减小模型的内存占用：

剪枝
量化
模型编译

让我们深入探讨这些技术的每一个，从剪枝开始。

剪枝

剪枝是一种消除深度学习模型中权重和参数的技术，这些权重和参数对模型性能的影响很小或没有，但对推理速度和模型大小有显著影响。剪枝方法背后的理念是使模型在内存和功耗上更高效，减少模型的存储需求和延迟。深度学习模型基本上是一个具有许多相互连接的隐藏层的神经网络。随着模型大小的增加，隐藏层的数量、参数以及层之间的权重连接也会增加。因此，剪枝方法倾向于移除未使用的参数和权重连接，而对模型的准确性影响不大，如图 图 9.1* 和 图 9.2* 所示。图 9.1 展示了剪枝前的神经网络：

图 9.1 – 剪枝前的简单神经网络

图 9.2 展示了剪枝后的相同神经网络：

图 9.2 – 剪枝后的简单神经网络

现在我们已经讨论了剪枝，接下来让我们看看量化。

量化

要训练一个神经网络，首先需要将数据通过前向传递传递到网络中，这会计算激活值，然后是反向传递，它使用激活值来计算梯度。激活值和梯度通常存储在浮点 32 中，这需要 4 字节内存。当你有具有数十亿或数万亿参数的模型时，这个数字相当可观。因此，量化是一种通过降低模型中权重、偏置和激活的精度来减小模型大小的技术，例如浮点 16 或 8，甚至到整数 8，这会显著减少内存占用。例如，具有 60 亿个可训练参数的 GPT-J-6B 模型大约需要 23 GB 的内存，如图 图 9.3* 所示。

图 9.3 展示了从 Hugging Face 库加载时的模型参数数量和大小：

图 9.3 – GPT-J-6B 模型的模型大小和参数数量

当使用 16 位浮点精度加载相同模型时，大约需要 11 GB 的内存，这大约是内存减少了一半，并且可以像 图 9.4 中所示的那样适应单个 GPU 的内存进行推理：

图 9.4 – GPT-J-6B 模型在 FP16 精度下的模型大小和参数数量

如 图 9.3 和 图 9.4 所示，量化可以是一种减少模型内存占用大小的有用技术。

现在，让我们看看另一种技术，称为模型编译。

模型编译

在我们进入模型编译之前，让我们首先了解编译。

编译是将人类可读的程序（一组指令）转换为机器可读程序的过程。这一核心思想被用作许多编程语言（如 C、C++ 和 Java）的骨干。这个过程还在程序的运行时环境中引入了效率，例如使其平台无关、减少程序内存大小等。大多数编程语言都自带 编译器，用于将代码编译成机器可读形式，因为编写编译器是一个繁琐的过程，需要深入理解编程语言以及硬件。

在编译机器学习模型时，使用了类似的想法。使用机器学习，编译器将神经网络的核心操作放置在 GPU 上，以最小化开销。这减少了模型占用的内存，提高了性能效率，并使其与硬件无关。这一概念在 图 9.5 中得到展示，其中编译器将使用 PyTorch、TensorFlow、XGBoost 等开发的模型转换为一种语言无关的中间表示，然后将其转换为机器可读的代码：

图 9.5 – 高级模型编译过程

模型编译消除了针对每个平台的特定硬件和软件配置微调模型所需的努力。现在有许多框架可供使用，可以编译您的模型，例如 TVM 和 ONNX，每个都有自己的优缺点。

注意

详细讨论编译器超出了本书的范围。有关 TVM 的详细信息，请参阅此链接：tvm.apache.org/。有关 ONNX 的详细信息，请参阅此链接：onnx.ai/。

让我们讨论 Amazon SageMaker 的一个功能，称为SageMaker Neo，它用于优化适用于多个平台的机器学习模型。Neo 自动优化各种框架（如 Gluon、Keras、PyTorch、TensorFlow 等）编写的模型，以便在不同的平台（如 Linux 和 Windows）以及许多不同的处理器上进行推理。有关 Neo 支持的框架或处理器的完整列表，请参阅此链接：docs.aws.amazon.com/sagemaker/latest/dg/neo-supported-devices-edge.html。

Neo 的工作方式是首先读取模型，将框架特定的操作和函数转换为无框架的中间表示，然后应用一系列优化。接下来，它将为优化操作生成二进制代码，将其写入共享对象库，并将模型定义和参数保存到单独的文件中（docs.aws.amazon.com/sagemaker/latest/dg/neo.html）。

它还为每个目标平台提供了一个运行时，用于加载和执行编译后的模型。此外，它可以将参数优化为浮点 32 (FP32)、量化为整数 8 (INT8)或浮点 16 (FP16)。它可以将模型性能提高高达 25 倍，同时占用比 TensorFlow 或 PyTorch 等深度学习框架少十分之一的内存。为了进一步了解这一点，让我们从一个 PyTorch 的预训练图像分类模型开始，并使用 SageMaker Neo 对其进行优化。

注意

我们在第八章中提到了 SageMaker Neo，优化和管理边缘部署的机器学习模型。在这里，我们将使用相同的示例来详细解释它。完整的代码请参考 GitHub 链接：github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/blob/main/Chapter08/sagemaker_notebook/1_compile_resnet_model_egde_manager.ipynb。

按照以下步骤使用 SageMaker Neo 优化预训练模型：

首先，我们将从 PyTorch 库中下载一个预训练模型，如下面的代码片段所示：

…

from torchvision.models import resnet18, ResNet18_Weights

#initialize the model

weights = ResNet18_Weights.DEFAULT

model = resnet18(weights)

…

接下来，我们需要将模型保存为 SageMaker 所需的model.tar.gz格式，指定输入数据形状，并将模型上传到Amazon S3：

…

torch.save(model.state_dict(),

           './output/resnet18-model.pt')

with tarfile.open("model.tar.gz", "w:gz") as f:

    f.add("model.pth")

input_tensor = torch.zeros([1, 3, 224, 224])

model_uri = sagemaker_session.upload_data(

    path="model.tar.gz", key_prefix=key_prefix)

print("S3 Path for Model: ", model_uri)

…

一旦我们有了 SageMaker 格式的模型，我们将准备模型编译所需的参数。最重要的是，您需要提及target_device参数，因为 SageMaker Neo 将根据它为模型部署的特定硬件编译模型：

…

compilation_job_name = name_from_base("image-classification-neo")

prefix = key_prefix+'/'+compilation_job_name+"/model"

data_shape = '{"input0":[1,3,224,224]}'

target_device = "ml_c5"

framework = "PYTORCH"

framework_version = "1.8"

compiled_model_path = "s3://{}/{}/output".format(bucket, compilation_job_name)

print("S3 path for compiled model: ", compiled_model_path)

…

接下来，我们将声明 SageMaker 提供的PyTorchModel对象，它将包含必要的配置，例如模型的 S3 路径、框架版本、推理脚本、Python 版本等：

…

from sagemaker.pytorch.model import PyTorchModel

from sagemaker.predictor import Predictor

sagemaker_model = PyTorchModel(

    model_data=model_uri,

    predictor_cls=Predictor,

    framework_version=framework_version,

    role=role,

    sagemaker_session=sagemaker_session,

    entry_point="inference.py",

    source_dir="code",

    py_version="py3",

    env={"MMS_DEFAULT_RESPONSE_TIMEOUT": "500"},

…

最后，我们将使用PyTorchModel对象创建编译作业，并将编译好的模型部署到ml.c5.2xlarge实例，因为模型是为ml.c5作为目标设备编译的：

…

sagemaker_client = boto3.client("sagemaker",

    region_name=region)

target_arch = "X86_64"

target_os = 'LINUX'

response = sagemaker_client.create_compilation_job(

    CompilationJobName=compilation_job_name,

    RoleArn=role,

    InputConfig={

        "S3Uri": sagemaker_model.model_data,

        "DataInputConfig": data_shape,

        "Framework": framework,

},

    OutputConfig={

        "S3OutputLocation": compiled_model_path,

        "TargetDevice": 'jetson_nano',

        "TargetPlatform": {

            "Arch": target_arch,

            "Os": target_os

},

},

    StoppingCondition={"MaxRuntimeInSeconds": 900},

print(response)

…

一旦模型完成编译，您就可以部署编译好的模型进行推理。在这种情况下，我们将模型作为端点部署以进行实时推理：
```
…
```
```
predictor = compiled_model.deploy(
```
```
    initial_instance_count=1,
```
```
    instance_type="ml.c5.2xlarge")
```
```
…
```

注意

有关 SageMaker 提供的不同部署选项的更多详细信息，请参阅第七章，大规模部署机器学习模型。

现在，一旦模型部署完成，我们可以像以下代码片段所示那样调用端点进行推理：

…

import numpy as np

import json

with open("horse_cart.jpg", "rb") as f:

    payload = f.read()

    payload = bytearray(payload)

response = runtime.invoke_endpoint(

    EndpointName=ENDPOINT_NAME,

    ContentType='application/octet-stream',

    Body=payload,

    Accept = 'application/json')

result = response['Body'].read()

result = json.loads(result)

print(result)

…

注意

由于我们已经将模型部署为实时端点，您将根据模型部署的实例付费。因此，如果您不使用端点，请确保使用以下代码片段将其删除。

如果您不使用它，请使用以下代码片段删除端点：

…

# delete endpoint after testing the inference

import boto3

# Create a low-level SageMaker service client.

sagemaker_client = boto3.client('sagemaker',

                                region_name=region)

# Delete endpoint

sagemaker_client.delete_endpoint(

    EndpointName=ENDPOINT_NAME)

…

现在我们已经了解了如何使用 SageMaker Neo 优化模型进行推理，让我们谈谈在尝试提高模型延迟时应该考虑的一些关键指标。下一节中介绍的思想适用于深度学习模型，即使您不使用 SageMaker Neo，因为您可能无法使用 Neo 编译所有模型。您可以在以下位置查看 SageMaker Neo 支持的模型和框架：docs.aws.amazon.com/sagemaker/latest/dg/neo-supported-cloud.html。

优化模型的关键指标

当涉及到实时推理时，为了提高性能，优化模型通常包括指标，如延迟、吞吐量和模型大小。为了优化模型大小，通常涉及有一个训练好的模型，检查模型的大小，如果它不适合单个 CPU/GPU 内存，您可以选择在减少深度学习模型内存占用部分讨论的任何技术来准备它以供部署。

对于部署，最佳实践之一是标准化环境。这涉及到使用容器来部署模型，无论您是在自己的服务器上部署还是使用 Amazon SageMaker。该过程在图 9.6中说明。6。

图 9.6 – 作为实时端点部署的模型

总结来说，我们首先将为部署准备模型，选择或创建一个容器以标准化环境，然后部署容器到实例（们）。因此，为了优化模型性能，寻找推理和实例指标都很重要。推理指标包括以下内容：

调用次数：发送到模型端点的请求数量。您可以通过使用Amazon CloudWatch中的总和统计来获取总请求数量，Amazon CloudWatch实时监控您在 AWS 上运行的资源或应用程序，包括 SageMaker（docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/WhatIsCloudWatch.html）。
每实例调用次数：如果您的模型部署在多台机器上，那么了解发送到每个实例上的模型调用次数很重要。
模型延迟：这是模型响应所需的时间间隔。它包括发送请求的本地通信时间、模型在容器中完成推理以及从模型容器获取响应的时间：

模型延迟 = 请求时间 + 模型在容器中完成推理所需的时间 + 从容器获取响应的时间

开销延迟：这是端点收到请求后响应所需的时间减去模型延迟。它可能取决于多个因素，例如请求大小、请求频率、请求的认证/授权以及响应负载大小。
最大调用次数：这是每分钟对端点的最大请求数量。
每小时成本：这表示您端点的每小时预估成本。
每推理成本：这提供了您端点每推理的预估成本。

注意

成本指标以美元为单位提供成本。

除了推理指标外，您还应该根据所选实例类型优化实例指标，例如 GPU 利用率、GPU 内存、CPU 利用率和 CPU 内存。Amazon SageMaker 提供了超过 70 种实例，您可以从中选择来部署您的模型。这引发了一个额外的问题，即如何确定选择哪种实例类型和实例数量来部署模型以实现您的性能要求。让我们在下一节中讨论为您的模型选择最佳实例的方法。

选择实例类型、负载测试和模型性能调整

传统上，根据模型类型（ML 模型或 DL 模型）和模型大小，你可以根据经验猜测来测试模型在几个实例上的性能。这种方法速度快，但可能不是最佳方法。因此，为了优化此过程，你可以使用 Amazon SageMaker 的推理推荐器功能（docs.aws.amazon.com/sagemaker/latest/dg/inference-recommender.html），该功能自动化了 SageMaker ML 实例上的负载测试和模型调整过程。它帮助你以最低的成本，根据你的性能要求，在优化的硬件上部署 ML 模型。

让我们通过使用预训练的图像分类模型来举例说明如何理解推理推荐器的工作原理。以下步骤概述了使用推理推荐器的过程：

确定 ML 模型细节，例如框架和领域。以下是一个代码片段示例：

…

# ML model details

ml_domain = "COMPUTER_VISION"

ml_task = "IMAGE_CLASSIFICATION"

…

取一个预训练模型，将其打包成 SageMaker 理解的压缩 TAR 文件（*.tar.gz）格式，并将模型上传到 Amazon S3。如果你已经在 SageMaker 上训练了模型，那么你可以跳过此步骤：

…

from torchvision.models import resnet18, ResNet18_Weights

#initialize the model

weights = ResNet18_Weights.DEFAULT

model = resnet18(weights)

torch.save(model.state_dict(), './output/resnet18-model.pt')

with tarfile.open("model.tar.gz", "w:gz") as f:

    f.add("model.pth")

input_tensor = torch.zeros([1, 3, 224, 224])

model_uri = sagemaker_session.upload_data(path="model.tar.gz", key_prefix=key_prefix)

print("S3 Path for Model: ", model_uri)

…

选择推理容器，它可以是 AWS 提供的预构建 Docker 容器或你自己的自定义容器。在我们的例子中，我们正在获取 AWS 提供的预构建 PyTorch 容器镜像：

…

instance_type = "ml.c5.xlarge"  # Note: you can use any CPU-based instance type here, this is just to get a CPU tagged image

container_uri = image_uris.retrieve(

    "pytorch",

    region,

    version=framework_version,

    py_version="py3",

    instance_type=instance_type,

    image_scope="inference",

container_uri

…

创建一个样本有效载荷。在我们的例子中，我们有.jpg格式的图像，将它们压缩成 TAR 文件，并上传到 Amazon S3。在这个例子中，我们只使用了四张图像，但建议添加各种样本，以反映你的实际有效载荷：

!wget https://multimedia-commons.s3-us-west-2.amazonaws.com/data/images/139/019/1390196df443f2cf614f2255ae75fcf8.jpg -P /sample-payload

!wget https://multimedia-commons.s3-us-west-2.amazonaws.com/data/images/139/015/1390157d4caaf290962de5c5fb4c42.jpg -P /sample-payload

!wget https://multimedia-commons.s3-us-west-2.amazonaws.com/data/images/139/020/1390207be327f4c4df1259c7266473.jpg  -P /sample-payload

!wget https://multimedia-commons.s3-us-west-2.amazonaws.com/data/images/139/028/139028d865bafa3de66568eeb499f4a6.jpg  -P /sample-payload

按照以下代码片段压缩有效载荷，并将其上传到 S3：

cd ./sample-payload/ && tar czvf ../{payload_archive_name} *

一旦我们有了 TAR 格式的有效载荷，让我们使用以下代码片段将其上传到 Amazon S3：

…
sample_payload_url = sagemaker_session.upload_data(path=payload_archive_name, key_prefix="tf_payload")
…

在模型注册表中注册模型，该注册表用于对生产中的模型进行编目、管理模型版本、关联元数据、管理模型的批准状态、将模型部署到生产环境，以及自动化模型部署过程（docs.aws.amazon.com/sagemaker/latest/dg/model-registry.html）。在模型注册表中注册模型是一个两步过程，如下所示：

创建一个模型包组，它将包含模型的全部版本：

…

model_package_group_input_dict = {

"ModelPackageGroupName": model_package_group_name,

"ModelPackageGroupDescription": model_package_group_description,

create_model_package_group_response = sm_client.create_model_package_group(**model_package_group_input_dict)

…

将模型版本注册到模型包组中。要获取推荐的实例类型，你有两种选择——你既可以指定 Inference Recommender 要使用的实例列表，也可以不提供实例列表，它将根据 ML 领域和 ML 任务选择正确的实例。在我们的例子中，我们将使用用于图像分类算法的常见实例类型列表。这涉及三个步骤。

首先，创建一个输入字典，用于注册模型，如下面的代码片段所示：

…

model_approval_status = "PendingManualApproval"

# provide an input dictionary with configuration for registering the model

model_package_input_dict = {

    "ModelPackageGroupName": model_package_group_name,

    "Domain": ml_domain.upper(),

    "Task": ml_task.upper(),

    "SamplePayloadUrl": sample_payload_url,

    "ModelPackageDescription": model_package_description,

    "ModelApprovalStatus": model_approval_status,

}# optional – provide a list of instances

supported_realtime_inference_types = ["ml.c5.xlarge", "ml.m5.large", "ml.inf1.xlarge"]

...

第二步是创建模型推理规范对象，这将包括提供有关容器、框架、模型输入、内容类型以及训练模型 S3 路径的详细信息：

#create model inference specification object

modelpackage_inference_specification = {

    "InferenceSpecification": {

        "Containers": [

                "Image": container_uri,

                "Framework": "PYTORCH",

                "FrameworkVersion": framework_version,

                "ModelInput": {"DataInputConfig": data_input_configuration},

],

        "SupportedContentTypes": "application/image",

        "SupportedRealtimeInferenceInstanceTypes": supported_realtime_inference_types,  # optional

# Specify the model data

modelpackage_inference_specification["InferenceSpecification"]["Containers"][0]["ModelDataUrl"] = model_url

create_model_package_input_dict.update(modelpackage_inference_specification)

...

最后，在提供推理规范后，我们将创建模型包。一旦模型包创建完成，你就可以获取模型包的 ARN，它也会在 SageMaker Studio UI 的模型注册下可见：
```
create_mode_package_response = sm_client.create_model_package(**model_package_input_dict)
```
```
model_package_arn = create_mode_package_response["ModelPackageArn"]
```
```
…
```

现在，模型已经注册，我们将创建一个推理推荐器作业。有两种选择——你可以创建一个默认作业以获取实例推荐，或者你可以使用一个高级作业，其中你可以提供你的推理要求、调整环境变量并执行更广泛的负载测试。高级作业比默认作业花费更多时间，并且取决于你的流量模式和它将在哪些实例类型上运行负载测试的数量。

在本例中，我们将创建一个默认作业，这将返回一个包括环境变量、成本、吞吐量、模型延迟和最大调用次数的实例类型推荐列表。

以下代码片段展示了如何创建默认作业：

…
response = sagemaker_client.create_inference_recommendations_job(
    JobName=str(default_job),
    JobDescription="",
    JobType="Default",
    RoleArn=role,
    InputConfig={"ModelPackageVersionArn": model_package_arn},
)
print(response)
…

注意

在 GitHub 仓库中提供了创建自定义负载测试的代码：Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/Chapter09/1_inference_recommender_custom_load_test.ipynb。

在下一节中，我们将讨论推理推荐器作业提供的结果。

观察结果

推理推荐器提供的推荐包括实例指标、性能指标和成本指标。

实例指标包括InstanceType、InitialInstanceCount和EnvironmentParameters，这些指标根据作业进行了调整以获得更好的性能。

性能指标包括MaxInvocations和ModelLatency，而成本指标包括CostPerHour和CostPerInference。

这些指标使你能够在成本和性能之间做出明智的权衡。例如，如果你的业务需求是整体价格性能，且注重吞吐量，那么你应该关注CostPerInference。如果你的需求是在延迟和吞吐量之间取得平衡，那么你应该关注ModelLatency和MaxInvocations指标。

你可以通过 API 调用或在 SageMaker Studio UI 中查看推理推荐器作业的结果。

以下代码片段用于观察结果：

…
data = [
    {**x["EndpointConfiguration"], **x["ModelConfiguration"], **x["Metrics"]}
    for x in inference_recommender_job["InferenceRecommendations"]
]
df = pd.DataFrame(data)
…

你可以通过登录 SageMaker Studio，点击橙色三角形图标，并在下拉菜单中选择模型注册来观察 SageMaker Studio UI 中的结果：

图 9.7 – 推理推荐器结果

现在我们已经了解了如何使用 Amazon SageMaker 的推理推荐器功能来获取正确的实例类型和实例数量，让我们在下一节中查看本章涵盖的主题。

摘要

在本章中，我们讨论了各种优化机器学习和深度学习模型以实现实时推理的技术。我们讨论了不同的方法来减少深度学习模型的内存占用，例如剪枝和量化，随后深入探讨了模型编译。然后，我们讨论了可以帮助评估模型性能的关键指标。最后，我们深入探讨了如何使用 SageMaker 推理推荐器的功能来选择合适的实例、运行负载测试以及自动进行模型调优。

在下一章中，我们将讨论在 AWS 上可视化探索大量数据的方法。

第十章：数据可视化

在前几章中，我们讨论了各种 AWS 服务和工具，这些工具可以帮助构建和运行高性能计算应用。我们讨论了存储、计算实例、数据处理、机器学习模型构建和托管，以及这些应用的边缘部署。所有这些应用，尤其是基于机器学习模型的应用，通常都需要某种类型的可视化。这种可视化可能从探索性数据分析到模型评估和比较，再到构建显示各种性能和业务指标的仪表板。

数据可视化对于发现各种业务洞察以及决定采取哪些特征工程步骤来训练提供良好结果的机器学习模型非常重要。AWS 提供了一些托管服务来构建数据可视化以及仪表板。

在本章中，我们将讨论这样一个选项，即 Amazon SageMaker Data Wrangler，它使数据科学、机器学习和分析领域的用户能够在不编写太多代码的情况下构建有洞察力的数据可视化。SageMaker Data Wrangler 提供了几个内置的可视化选项，以及通过几点击和很少的努力添加自定义可视化的能力。这有助于数据科学家进行探索性分析、特征工程和实验过程，这些过程涉及任何数据驱动用例。

此外，我们还将简要介绍 AWS 的图形优化实例的主题，因为这些实例可以与其他高性能计算应用（如游戏流和机器学习）一起用于创建动态实时数据可视化。

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

使用 Amazon SageMaker Data Wrangler 进行数据可视化
Amazon 的图形优化实例

使用 Amazon SageMaker Data Wrangler 进行数据可视化

Amazon SageMaker Data Wrangler是 SageMaker Studio 中的一个工具，它帮助数据科学家和机器学习从业者执行探索性数据分析和特征工程/转换。SageMaker Data Wrangler 是一个低代码/无代码工具，用户可以使用内置的绘图或特征工程能力，或者使用代码来制作自定义图表并执行自定义特征工程。在需要可视化的数据科学项目中，特别是那些需要执行探索性数据分析的大型数据集，SageMaker Data Wrangler 可以帮助通过几点击快速构建图表和可视化。我们可以将数据从各种数据源导入到 Data Wrangler 中，并执行诸如连接和过滤等操作。此外，还可以生成数据洞察和质量报告，以检测数据中是否存在任何异常。

在本节中，我们将通过一个示例来展示如何使用 SageMaker Data Wrangler 构建一个工作流程，以执行数据分析和可视化。

SageMaker Data Wrangler 可视化选项

在 SageMaker Data Wrangler 中，首先，我们需要导入数据，然后构建一个工作流程以执行各种转换和可视化任务。在撰写本文时，数据可以从亚马逊 S3、亚马逊 Athena 和亚马逊 Redshift 导入到 SageMaker Data Wrangler 中。图 10**.1显示了亚马逊 SageMaker Data Wrangler 的导入数据界面。要添加来自亚马逊 Redshift 的数据，我们需要点击右上角的添加数据源按钮：

图 10.1 – SageMaker Data Wrangler 数据导入界面

接下来，我们将展示一个从亚马逊 S3 将数据导入 SageMaker Data Wrangler 的示例，然后说明对此数据的各种可视化选项。我们将使用加州大学欧文分校机器学习仓库中可用的Adult数据集(archive.ics.uci.edu/ml/datasets/Adult)。此数据集将个人分为两类：该人是否每年收入超过 50,000 美元。数据集中有各种数值和分类特征。在导入数据时，我们可以选择是否要加载整个数据集或数据集的样本。图 10**.2显示了 SageMaker Data Wrangler 导入整个Adult数据集后创建的工作流程：

图 10.2 – 导入数据后 SageMaker Data Wrangler 创建的工作流程

通过在右侧的块上按下加号，我们可以将转换和可视化步骤添加到工作流程中，正如我们接下来将要演示的那样。

将可视化添加到 SageMaker Data Wrangler 的数据流中

在导入数据后，我们还可以在 SageMaker Data Wrangler 中查看数据，包括列（变量）类型。图 10**.3显示了 Adult 数据表的视图。此视图可以帮助数据科学家和分析人员快速查看数据并验证它：

图 10.3 – 携带列类型的 Adult 数据表

要在我们的数据集上构建各种可视化，我们必须按下图 10**.2中显示的Transform: adult.csv块上的+号。这显示了 SageMaker Data Wrangler 中可用的各种分析和可视化选项。现在，我们将使用 SageMaker Data Wrangler 在Adult数据集上查看一些可视化示例。

直方图

一个education-num（教育年数）变量。我们还使用income目标变量来着色此分布，以显示收入如何依赖于教育年数：

图 10.4 – 教育年限（education-num）的直方图，按两个类别（<=50k 和>50k）着色

除了颜色，我们还可以使用按收入着色的education-num。这是按sex变量分面，以分别显示男性和女性的分布：

图 10.5 – 教育年限（education-num）的直方图，按两个类别（<=50k 和>50k）着色，并按性别分面

我们可以看到，通过这种方式只需点击几下就能创建多列的直方图，而且无需编写任何代码，这可以非常有助于进行快速探索性分析和在短时间内构建报告。这在多个高性能计算用例中通常是必需的，例如机器学习。

散点图

以age与education-num的关系，按sex分面：

图 10.6 – 成人数据集中年龄与教育年限的散点图，按性别分面

结合直方图，散点图是极其有用的可视化工具，在机器学习的用例中进行探索性数据分析时被广泛使用。

多重共线性

在数据集中，当变量相互关联时，会出现多重共线性。在机器学习用例中，这很重要，因为如果检测到多重共线性，可以降低数据维度。数据维度降低有助于避免维度诅咒，以及提高机器学习模型的性能。此外，它还有助于减少模型训练时间、存储空间、内存需求和推理过程中的数据处理时间，从而降低总成本。在 SageMaker Data Wrangler 中，我们可以使用以下方法来检测变量中的多重共线性：

方差膨胀 因子 (VIF)
主成分 分析 (PCA)
Lasso 特征选择

接下来，我们将使用我们的Adult数据集在 SageMaker Data Wrangler 中展示这些方法的示例。

VIF

VIF 表示一个变量是否与其他变量相关。它是一个正数，值为一表示该变量与数据集中的其他变量不相关。大于一的值表示该变量与数据集中的其他变量相关。值越高，与其他变量的相关性越高。图 10.7显示了Adult数据集中数值变量的 VIF 图：

图 10.7 – 成人数据集中各种数值变量的 VIF

如图中所示，education-num、hours-per-week和age与其他变量高度相关，而capital-gain和capital-loss根据 VIF 分数与其他变量不相关。

PCA

PCA 是机器学习中应用最广泛的特征转换和降维方法之一。它通常不仅用作探索性数据分析工具，还用作监督学习问题中的预处理步骤。PCA 将数据投影到彼此正交的维度上。以这种方式生成的变量按方差（或奇异值）递减的顺序排列。这些方差可以用来确定变量中有多大的多重共线性。图 10.8展示了使用 SageMaker Data Wrangler 对我们的Adult数据集应用 PCA 的结果：

图 10.8 – 使用 SageMaker Data Wrangler 对 Adult 数据集进行 PCA 的结果

从这张图中可以推断出，大多数变量没有多重共线性，而少数变量有。

Lasso 特征选择

在 SageMaker Data Wrangler 中，我们可以使用 lasso 特征选择来找到数据集中对目标变量最有预测性的变量。它使用 L1 正则化方法为每个变量生成系数。系数分数越高，表示该特征对目标变量的预测性越强。就像 VIF 和 PCA 一样，lasso 特征选择在机器学习用例中通常用于降低数据集的维度。图 10.9展示了在 SageMaker Data Wrangler 中对我们的Adult数据集应用 lasso 特征选择的结果：

图 10.9 – 使用 SageMaker Data Wrangler 在 Adult 数据集上的 Lasso 特征选择结果

接下来，我们将讨论如何使用 SageMaker Data Wrangler 的快速模型功能来研究变量重要性。

快速模型

我们可以在 Data Wrangler 中使用快速模型来评估机器学习数据集的变量/特征重要性。快速模型根据监督学习问题类型训练随机森林回归器或随机森林分类器，并使用基尼重要性方法确定特征重要性分数。特征重要性分数介于 0 到 1 之间，特征重要性值越高，表示该特征对数据集的重要性越大。图 10.10展示了使用 SageMaker Data Wrangler 为我们Adult数据集创建的快速模型图：

图 10.10 – 使用 SageMaker Data Wrangler 对 Adult 数据集的快速模型结果

快速模型可以帮助数据科学家快速评估特征的重要性，然后使用这些结果进行降维、模型性能改进或商业洞察。

偏差报告

使用 sex 变量（男性或女性），显示类别不平衡和两个其他指标：

图 10.11 – 使用 SageMaker Data Wrangler 对 Adult 数据集进行的偏差报告

关于这些指标的更多信息，请参阅本章的 进一步阅读 部分。

数据质量及洞察力报告

我们也可以在 SageMaker Data Wrangler 中构建一个数据质量和洞察力报告。此报告显示了诸如表格摘要、重复行、目标变量的分布、异常样本、运行快速模型的结果、混淆矩阵（用于分类问题）、特征摘要以及特征重要性，以及特征详细图。图 10.12 展示了 Adult 数据集的表格摘要：

图 10.12 – 显示 Adult 数据集数据统计的表格摘要

图 10.13 展示了目标变量的直方图，以及 occupation 变量的各种值：

图 10.13 – 目标变量的直方图，以及职业变量的各种值

只需点击几下就能访问这些图表、指标和分布，这在执行探索性数据分析时节省了大量时间和精力。

数据流

随着我们在 SageMaker Data Wrangler 中的数据分析步骤增加，它们会在数据流中显示出来。图 10.14 中所示的数据流可视化是我们在此流程中已执行的一系列转换：

图 10.14 – 显示我们已在我们数据集上执行的一系列步骤的 SageMaker Data Wrangler 流程

我们可以点击单个框来查看工作流程中迄今为止执行的探索性分析步骤和数据转换。例如，点击中心框会显示 图 10.15 中的步骤：

图 10.15 – 在 SageMaker Data Wrangler 中对我们数据集执行的各种探索性数据分析和数据转换步骤

点击 图 10.14 中显示的右侧框，会显示我们的偏差和数据质量报告，如 图 10.16 所示：

图 10.16 – SageMaker Data Wrangler 流中的偏差报告和数据质量及洞察报告步骤

SageMaker Data Wrangler 允许将这些步骤的结果导出到 SageMaker Feature Store 或 Amazon S3。此外，我们还可以将这些步骤作为代码导出到 SageMaker pipelines 或作为 Python 代码。

在本节中，我们讨论了使用 SageMaker Data Wrangler 在 Amazon SageMaker 中的各种可视化选项。Data Wrangler 中内置了多种可视化和分析选项，我们可以在机器学习用例中使用这些选项。在下一节中，我们将讨论亚马逊的图形优化实例选项。

亚马逊的图形优化实例

亚马逊提供了一系列图形优化实例，可用于高性能计算应用，如机器学习用例和需要图形密集型计算工作负载的应用。这些实例配备 NVIDIA GPU 或 AMD GPU，适用于需要高性能计算用例，如游戏流、图形渲染、机器学习等。

亚马逊图形优化实例的益处和关键特性

在本节中，我们将概述亚马逊图形优化实例的一些益处和关键特性：

高性能和低成本：配备良好 GPU 的机器通常购买成本很高，且由于成本高昂，难以扩展。亚马逊提供以低成本获得配备最先进 GPU 的高性能实例的选项。这些实例可用于运行图形密集型应用、构建可视化以及执行机器学习训练和推理。此外，这些实例还提供超过一兆字节的基于 NVMe 的固态存储，以便快速访问本地数据，这在高性能计算用例中通常是必需的。

虽然 AWS 提供了非常广泛的基于 GPU 的实例，可用于不同类型的高性能计算应用，但 P3、P3dn、P4 和 G4dn 实例特别适合在多个节点上执行分布式机器学习模型训练任务。此外，这些实例可以为具有极高吞吐量要求的应用提供高达每秒 400 Gbps 的网络带宽。

全面管理服务：亚马逊的图形优化实例可以作为弹性计算云（EC2）实例进行配置，适用于各种用例，包括机器学习、数值优化、图形渲染、游戏和流媒体。用户可以安装自定义内核和库，并根据需要管理它们。这些实例还支持 TensorFlow、PyTorch 和 MXNet 等常见深度学习框架的亚马逊机器镜像。此外，用户可以在 Amazon SageMaker 中使用这些实例来训练深度学习模型。当在 SageMaker 中用于训练作业时，这些实例由 AWS 全面管理，并且仅在训练作业期间使用，从而显著降低成本。

在下一节中，我们将总结本章所学内容。

摘要

在本章中，我们讨论了如何使用 Amazon SageMaker Data Wrangler 为分析和机器学习用例构建快速可视化。我们展示了 SageMaker Data Wrangler 中可用的各种探索性数据分析、绘图和数据转换选项。快速且轻松地构建这些可视化和偏差及质量报告对于数据科学家和机器学习领域的从业者来说非常重要，因为它有助于显著减少与探索性数据分析相关的成本和努力。此外，我们还讨论了适用于游戏流媒体、渲染和机器学习用例等高性能计算应用的亚马逊图形优化实例。

从下一章开始，我们将讨论高性能计算和应用的机器学习的各种应用，第一个是计算流体动力学。

进一步阅读

要了解更多关于本章讨论的主题，请参阅以下资源：

加州大学欧文分校机器学习仓库的成人数据集：archive.ics.uci.edu/ml/datasets/Adult
Amazon SageMaker Data Wrangler：aws.amazon.com/sagemaker/data-wrangler/
Amazon SageMaker Data Wrangler 文档：docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler.html
Amazon SageMaker Data Wrangler 可视化：docs.aws.amazon.com/sagemaker/latest/dg/data-wrangler-analyses.html
在 SageMaker Data Wrangler 中使用的随机森林回归器：spark.apache.org/docs/latest/ml-classification-regression.html#random-forest-regression
在 SageMaker Data Wrangler 中使用的随机森林分类器：spark.apache.org/docs/latest/ml-classification-regression.html#random-forest-classifier
数据偏差报告：docs.aws.amazon.com/sagemaker/latest/dg/data-bias-reports.html
Amazon EC2 G4 实例：aws.amazon.com/ec2/instance-types/g4/

第三部分：推动各行业创新

AWS 提供高性能存储、计算和网络服务，以服务于覆盖多个垂直领域的典型高性能计算（HPC）应用，包括多物理建模、基因组学、计算机辅助设计和仿真、以及天气建模和预测，以及如机器学习（ML）等应用。在本部分，我们涵盖了四个主要的 HPC 应用，它们如何在 AWS 上设置和解决，并在每个章节结束时介绍如何将 ML 的新兴研究与应用经典方法相结合来解决这些典型的 HPC 问题。

本部分包括以下章节：

第十一章, 计算流体动力学
第十二章, 基因组学
第十三章, 自动驾驶汽车
第十四章, 数值优化

第十一章：计算流体动力学

计算流体动力学（CFD）是一种分析流体（空气、水和其他流体）如何流过或穿过感兴趣物体的技术。CFD 是一个成熟的领域，起源于几十年前，并在与制造、医疗保健、环境以及涉及流体流动、化学反应或热力学反应和模拟的航空航天和汽车工业相关的学术领域中使用。鉴于该领域的进步和悠久的历史，本书的范围超出了讨论该领域许多方面的范围。然而，这些视频链接可能是读者了解 CFD 是什么以及一些 CFD 工具，以及 AWS 上的最佳实践的一个很好的途径：

在本章中，我们将回顾计算流体力学（CFD）领域，并探讨今天如何使用机器学习（ML）与 CFD 结合。此外，我们还将探讨一些您可以在 AWS 上运行 CFD 工具的方法。

本章将涵盖以下主题：

介绍计算流体力学（CFD）
检查在 AWS 上运行 CFD 的最佳实践
讨论如何将 ML 应用于 CFD

技术要求

在开始本章之前，您应具备以下先决条件：

熟悉 AWS 及其基本使用。
网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）。
AWS 账户（如果您不熟悉如何开始使用 AWS 账户，可以访问此链接：aws.amazon.com/getting-started/).
对 CFD 有一定的了解。尽管我们将提供 CFD 的简要概述，但本章最适合那些至少对 CFD 可以解决的典型用例有所了解的读者。

在下一节中，我们将通过一个示例应用问题——设计赛车！来介绍计算流体力学（CFD）。

介绍计算流体力学（CFD）

CFD 是使用数值分析预测流体流动。让我们来分解一下：

预测：与其他物理现象一样，流体流动可以通过数学建模和模拟。对于来自 ML 领域的读者来说，这与 ML 模型的预测不同。在这里，我们通过迭代求解一系列方程来构建物体内部或周围的流动。主要使用 Navier-Stokes 方程。
数值分析：为了实际解决这些方程，已经创建了几个工具——不出所料，这些工具被称为求解器。与任何一组工具一样，这些求解器有商业和开源两种版本。如今，编写任何与实际求解方程相关的代码是不常见的——类似于在开始解决你的机器学习问题之前，你不会编写自己的机器学习框架。这些求解器通过代码实现了数十年来研究过的数值或数学方法，这些方法有助于流体流动的分析。

现在，假设你是即将到来的赛车赛季一支新一级方程式（F1）车队的主教练，负责管理新车的研发设计。这辆车的研发设计必须满足许多新的 F1 规则，这些规则定义了车辆设计可以施加的限制。幸运的是，你有一个庞大的工程团队可以管理新车的研发和制造。最大的车队在制造任何部件之前，仅在概念设计上就花费了数百万美元。车队通常从基准设计开始，并迭代地改进这个设计。这种设计的迭代改进并不仅限于赛车车身的开发；想想你口袋或包里的最新版 iPhone，或者几代商用客机设计看起来相似但实际上却非常不同。你要求工程师使用计算机辅助设计（CAD）工具对现有车辆进行设计修改，经过一个月对潜在设计变更的工作后，他们向你展示了你团队最新车辆的设计（见图 图 11**.1）。这看起来很棒！

图 11.1 – F1 赛车设计

然而，你怎么知道这辆车在赛道上会表现更好呢？你可以跟踪的两个关键指标如下：

阻力：物体在流体流动中产生的阻力。阻力系数是一个无量纲量，用于量化阻力。对于你的 F1 赛车来说，更高的阻力系数更差，因为你的车会移动得更慢，假设其他所有因素保持不变。
下压力：将汽车推到赛道上的空气动力学力；下压力越高，越好，因为它在高速行驶或转弯时提供了更大的抓地力。

图 11**.2 展示了这两个力作用在 F1 赛车上的方向：

图 11.2 – F1 赛车的阻力和下压力方向

现在测量阻力和下压力的一种方法是将整辆车制造出来，在赛道上驾驶并使用力传感器进行测试，然后将结果反馈给团队——但如果您有其他的设计想法呢？或者是对您汽车某个部件的变体？您将需要重新构建这些部件，或者整辆车，然后进行相同的测试，或者在风洞中运行比例模型——这些选项可能非常耗时且成本高昂。这就是数值分析代码，如 CFD 工具变得有用的地方。使用 CFD 工具，您可以模拟汽车上的不同流动条件并计算阻力和下压力。

在 CFD 中，通常会在感兴趣的对象内部创建一个流动域。这可以类似于图 11.3中的外部流动（例如，车辆周围的流动）。另一方面，您可能有内部流动，其中域定义在对象本身内（例如，弯曲管道内的流动）。在图 11.3中，绿色和蓝色表面代表该域中的入口和出口。空气从入口流入，经过并绕过汽车，然后通过出口流出。

图 11.3 – 围绕 F1 赛车的 CFD 域定义

到目前为止，汽车和域是概念性的想法，需要以对象或文件的形式表示，以便 CFD 代码可以读取和使用。用于表示对象的典型文件格式是立体光刻（STL）文件格式。每个对象表示为一组三角形，每个三角形由一组 3D 点表示。在 STL 格式中的同一辆汽车如图 11.4所示——汽车现在是由数万个三角形组成的集合。

图 11.4 – STL 格式的 F1 赛车

我们现在可以使用这个汽车对象并对 CFD 域进行网格化。创建网格或网格化是在 CFD 域中创建网格点的过程，其中要解决与流体流动相关的数值方程。网格化是一个非常重要的过程，因为它可以直接影响结果，有时也可能导致数值模拟发散或无法求解。

注意

网格化技术和所使用的算法的细节超出了本书的范围。每个求解器工具都使用不同的网格化技术，并具有各种配置。团队花费大量时间获得高质量的网格，同时平衡网格的复杂性以确保更快的求解时间。

一旦构建了网格，它可能看起来类似于图 11.5。我们看到网格单元在车身附近有集中。请注意，这是一个网格的切片，实际的网格是一个 3D 体积，其边界在图 11.3中定义。

图 11.5 – 为 F1 赛车案例构建的 CFD 网格

一旦构建了网格，我们就可以使用 CFD 求解器计算围绕这辆 F1 赛车的流动，然后对这些结果进行后处理，以提供关于阻力下压力的预测。图 11**.6和图 11**.7显示了涉及流线（图像中的白色线条表示流体如何围绕车身流动）、速度切片（在感兴趣平面或截面上的速度大小）、车身上的压力（红色区域表示更高的压力）以及原始汽车几何形状的典型后处理图像。

图 11.6 – F1 赛车案例的后处理结果，显示流线和速度切片

图 11**.7展示了汽车表面的压力不同输出可视化，以及透视视图中的流线。

图 11.7 – F1 赛车案例的后处理结果，显示车身上的压力和流线

总结来说，运行 CFD 案例涉及以下步骤：

加载和处理几何形状
网格化 CFD 域
使用求解器在域内求解流动
使用后处理工具可视化结果

在下一节中，我们将讨论根据我们记录的最佳实践，在 AWS 上运行 CFD 分析的一些方法。

检查在 AWS 上运行 CFD 的最佳实践

由于 CFD 计算密集度很高，需要大规模扩展才能适用于依赖分析结果来做出产品设计决策的公司。AWS 允许客户使用多种商业和开源工具，按需以大规模（数千个核心）运行 CFD 模拟，无需任何容量规划或前期资本投资。您可以在以下位置找到有关 AWS 上 CFD 的许多有用链接：aws.amazon.com/hpc/cfd/。

如本章开头所强调的，有几种商业和开源工具可用于解决您的 CFD 问题，这些工具可以在 AWS 上大规模运行。以下是一些这些工具的例子：

西门子 SimCenter STAR-CCM+
Ansys Fluent
OpenFOAM（开源）

在本章中，我们将向您提供如何设置和使用OpenFOAM的示例。对于其他工具，请参阅 AWS 提供的此研讨会：cfd-on-pcluster.workshop.aws/。

注意

注意，AWS Well-Architected 框架定义了在 AWS 上运行任何类型工作负载的最佳实践。它包括以下支柱在 AWS 上设计架构的最佳实践：运营卓越、安全性、可靠性、性能效率、成本优化和可持续性。

如果你不太熟悉“架构良好框架”，你可以在这里详细了解它：docs.aws.amazon.com/wellarchitected/latest/framework/welcome.html/。

我们现在将讨论两种在 AWS 上运行 CFD 仿真模拟的不同方法：使用 ParallelCluster 和使用 CFD Direct。

使用 AWS ParallelCluster

在 AWS 上，这些“架构良好”的最佳实践被封装在一个名为 AWS ParallelCluster 的解决方案中，你可以在你的 AWS 账户中启动它。ParallelCluster 允许你通过简单的命令行界面（CLI）配置和启动整个 HPC 集群。CLI 还允许你以安全的方式动态扩展 CFD（以及其他 HPC）应用所需的资源。流行的调度器，如 AWS Batch 或 Slurm，可以用于在 ParallelCluster 上提交和监控作业。以下是一些安装 ParallelCluster 的步骤（请注意，完整的步骤可以在 ParallelCluster 的官方 AWS 文档页面找到：docs.aws.amazon.com/parallelcluster/latest/ug/install-v3-pip.html）。

步骤 1 – 创建 AWS Cloud9 IDE

这有助于我们访问指定实例类型上的完整 IDE，并使用临时、管理的凭证来启动 ParallelCluster。按照以下说明启动 AWS Cloud9 IDE：docs.aws.amazon.com/cloud9/latest/user-guide/setup-express.html。

一旦你创建了你的 Cloud9 IDE，按照以下说明导航到终端：docs.aws.amazon.com/cloud9/latest/user-guide/tour-ide.html#tour-ide-terminal。

步骤 2 – 安装 ParallelCluster CLI

一旦你进入了终端，请执行以下操作：

使用pip安装ParallelCluster：

...

python3 -m pip install "aws-parallelcluster" --upgrade –-user

...

接下来，确保你已经安装了节点版本管理器（NVM）：

...

curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.38.0/install.sh | bash

chmod ug+x ~/.nvm/nvm.sh

source ~/.nvm/nvm.sh

nvm install --lts

node –version

...

最后，验证ParallelCluster是否已成功安装：

pcluster version

    "version": "3.1.3"

让我们继续到步骤 3。

步骤 3 – 配置你的 ParallelCluster

在你启动 ParallelCluster 之前，你需要使用 configure 命令定义参数：

...
pcluster configure
...

命令行工具将询问你以下问题以创建一个配置（或简称 config）文件：

设置 ParallelCluster 的区域（例如，US-East-1）
EC2 密钥对使用（在此处了解更多关于密钥对的信息：docs.aws.amazon.com/AWSEC2/latest/UserGuide/ec2-key-pairs.html）
操作系统（例如，Amazon Linux 2、CentOS 7 或 Ubuntu）
主节点实例类型（例如，c5n.18xlarge）
是否要自动化 VPC 创建
子网配置（例如，将头节点或主节点放置在公共子网中，其余的计算集群在私有子网或子网中）
额外的共享存储卷（例如，FSx 配置）

这将创建一个可以在 ~/.parallelcluster 中找到并修改的配置文件，在创建集群之前。以下是一个 ParallelCluster 配置文件的示例：

...
Region: us-east-2
Image:
  Os: alinux2
HeadNode:
  InstanceType: c5.4xlarge
  Networking:
    SubnetId: subnet-0e6e79abb7ed2452c
  Ssh:
    KeyName: pcluster
Scheduling:
  Scheduler: slurm
  SlurmQueues:
  - Name: queue1
    ComputeResources:
    - Name: c54xlarge
      InstanceType: c5.4xlarge
      MinCount: 0
      MaxCount: 4
    - Name: m516xlarge
      InstanceType: m5.16xlarge
      MinCount: 0
      MaxCount: 2
    Networking:
      SubnetIds:
      - subnet-09299f6d9ecfb8122
...

深入了解 ParallelCluster 配置文件的复杂性，请参阅以下内容：aws.amazon.com/blogs/hpc/deep-dive-into-the-aws-parallelcluster-3-configuration-file/。

第 4 步 – 启动您的 ParallelCluster

一旦您已验证配置文件，请使用以下命令创建和启动 ParallelCluster：

...
pcluster create-cluster --cluster-name mycluster --cluster-configuration config
{
  "cluster": {
    "clusterName": "mycluster",
    "cloudformationStackStatus": "CREATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:us-east-2:989279443319:stack/mycluster/c6fdb600-d49e-11ec-9c26-069b96033f9a",
    "region": "us-east-2",
    "version": "3.1.3",
    "clusterStatus": "CREATE_IN_PROGRESS"
  }
}...

在这里，我们的集群已被命名为 mycluster。这将基于您之前定义的配置文件启动一个包含所需资源的 CloudFormation 模板。AWS ParallelCluster 使用以下服务：

AWS Batch
AWS CloudFormation
Amazon CloudWatch
Amazon CloudWatch 日志
AWS CodeBuild
Amazon DynamoDB
Amazon 弹性块存储
Amazon 弹性计算云（EC2）
Amazon 弹性容器注册
Amazon 弹性文件系统（EFS）
Amazon FSx for Lustre
AWS 身份和访问管理
AWS Lambda
NICE DCV
Amazon Route 53
Amazon 简单存储服务
Amazon VPC

关于所使用服务的更多详细信息，请参阅本章 参考文献 部分提供的链接。AWS ParallelCluster 的简化架构图显示在 图 11.8 中。更多详细信息可以在以下博客中找到：aws.amazon.com/blogs/compute/running-simcenter-star-ccm-on-aws/。否则，请参阅 ParallelCluster 的文档页面（docs.aws.amazon.com/parallelcluster/latest/ug/what-is-aws-parallelcluster.html）。

图 11.8 – AWS ParallelCluster 架构

启动通常需要大约 10 分钟，可以在控制台以及 AWS 管理控制台上的 CloudFormation 页面上跟踪。在控制台上，以下消息将确认您的启动正在进行：

pcluster list-clusters --query 'clusters[?clusterName==`mycluster`]'
[
  {
    "clusterName": "mycluster",
    "cloudformationStackStatus": "CREATE_IN_PROGRESS",
    "cloudformationStackArn": "arn:aws:cloudformation:us-east-2:<account_number>:stack/mycluster/c6fdb600-d49e-11ec-9c26-069b96033f9a",
    "region": "us-east-2",
    "version": "3.1.3",
    "clusterStatus": "CREATE_IN_PROGRESS"
  }
]

等待状态显示为 "clusterStatus": "CREATE_COMPLETE"

第 5 步 – 在集群上安装 OpenFOAM

要在您的集群上安装 OpenFOAM，请参阅以下内容：

首先，将 Secure Shell（SSH）添加到您新创建的 ParallelCluster 的头节点：

pcluster ssh -n mycluster -i pcluster.pem

The authenticity of host '3.135.195.149 (3.135.195.149)' can't be established.

ECDSA key fingerprint is SHA256:DZPeIcVRpZDg3VMYhA+2zAvEoLnD3gI6mLVkMPkyg90.

ECDSA key fingerprint is MD5:87:16:df:e7:26:f5:a0:da:a8:3a:7c:c4:c8:92:60:34.

Are you sure you want to continue connecting (yes/no)? yes

Warning: Permanently added '3.135.195.149' (ECDSA) to the list of known hosts.

Last login: Sun May 15 22:36:41 2022

__|  __|_  )

       _|  (     /   Amazon Linux 2 AMI

      ___|\___|___|

您现在位于 ParallelCluster 的头节点上。接下来，按照以下步骤下载 OpenFOAM 文件：

...

wget https://sourceforge.net/projects/openfoam/files/v2012/OpenFOAM-v2012.tgz

wget https://sourceforge.net/projects/openfoam/files/v2012/ThirdParty-v2012.tgz

...

接下来，解压缩您刚刚下载的两个文件：

...

tar -xf OpenFOAM-v2012.tgz

tar -xf ThirdParty-v2012.tgz

...

将目录更改到新提取的 OpenFOAM 文件夹，并编译 OpenFOAM：
```
...
```
```
cd OpenFOAM-v2012
```
```
export WM_NCOMPPROCS=36
```
```
./Allwmake
```
```
...
```

要在所有节点上安装 OpenFOAM，你可以使用sbatch命令，并将前面的命令作为名为compile.sh的文件提交：例如，sbatch compile.sh。

安装完成后，你可以运行如步骤 6中所示的示例 CFD 应用程序。

步骤 6 – 运行示例 CFD 应用程序

在这里，我们将使用 ParallelCluster 运行一个示例 CFD 应用程序。首先，我们使用 SSH 访问我们刚刚创建的集群的头节点：

...
pcluster ssh --cluster-name mycluster -i /path/to/keyfile.pem
...

确保你使用与步骤 3中创建的相同的.pem文件！

在这个案例中，我们将运行 OpenFOAM 的一个示例——摩托车上的不可压缩流动。此案例的案例文件可以在以下位置找到：static.us-east-1.prod.workshops.aws/public/a536ee90-eecd-4851-9b43-e7977e3a5929/static/motorBikeDemo.tgz。

与此案例对应的几何体在图 11.9中显示。

图 11.9 – OpenFOAM 中摩托车案例的几何体

仅在头节点上运行案例，你可以运行以下命令：

cp $FOAM_TUTORIALS/resources/geometry/motorBike.obj.gz constant/triSurface/
surfaceFeatureExtract
blockMesh
snappyHexMesh
checkMesh
potentialFoam
simpleFoam

我们将在后面的章节中详细介绍这些命令的功能。现在，我们的目标只是运行示例摩托车案例。

要在所有计算节点上并行运行相同的案例，你可以使用sbatch提交以下 shell 脚本（类似于提交安装 shell 脚本）。我们可以在脚本中定义一些输入参数，然后加载OpenMPI和OpenFOAM：

...
#!/bin/bash
#SBATCH --job-name=foam
#SBATCH --ntasks=108
#SBATCH --output=%x_%j.out
#SBATCH --partition=compute
#SBATCH --constraint=c5.4xlarge
module load openmpi
source OpenFOAM-v2012/etc/bashrc
cp $FOAM_TUTORIALS/resources/geometry/motorBike.obj.gz constant/triSurface/

首先，我们使用blockMesh和snappyHexMesh工具对几何体进行网格划分（参见以下代码）：

surfaceFeatureExtract  > ./log/surfaceFeatureExtract.log 2>&1
blockMesh  > ./log/blockMesh.log 2>&1
decomposePar -decomposeParDict system/decomposeParDict.hierarchical  > ./log/decomposePar.log 2>&1
mpirun -np $SLURM_NTASKS snappyHexMesh -parallel -overwrite -decomposeParDict system/decomposeParDict.hierarchical   > ./log/snappyHexMesh.log 2>&1

然后，我们使用checkMesh检查网格的质量，并对网格进行重新编号并打印出网格的摘要（参见代码）：

mpirun -np $SLURM_NTASKS checkMesh -parallel -allGeometry -constant -allTopology -decomposeParDict system/decomposeParDict.hierarchical > ./log/checkMesh.log 2>&1
mpirun -np $SLURM_NTASKS redistributePar -parallel -overwrite -decomposeParDict system/decomposeParDict.ptscotch > ./log/decomposePar2.log 2>&1
mpirun -np $SLURM_NTASKS renumberMesh -parallel -overwrite -constant -decomposeParDict system/decomposeParDict.ptscotch > ./log/renumberMesh.log 2>&1
mpirun -np $SLURM_NTASKS patchSummary -parallel -decomposeParDict system/decomposeParDict.ptscotch > ./log/patchSummary.log 2>&1
ls -d processor* | xargs -i rm -rf ./{}/0
ls -d processor* | xargs -i cp -r 0.orig ./{}/0

最后，我们通过potentialFoam和simpleFoam二进制文件运行 OpenFOAM，如下所示：

mpirun -np $SLURM_NTASKS potentialFoam -parallel -noFunctionObjects -initialiseUBCs -decomposeParDict system/decomposeParDict.ptscotch > ./log/potentialFoam.log 2>&1s
mpirun -np $SLURM_NTASKS simpleFoam -parallel  -decomposeParDict system/decomposeParDict.ptscotch > ./log/simpleFoam.log 2>&1
...

你可以按照以下 AWS 工作坊中的说明来可视化 CFD 案例的结果：catalog.us-east-1.prod.workshops.aws/workshops/21c996a7-8ec9-42a5-9fd6-00949d151bc2/en-US/openfoam/openfoam-visualization。

接下来，让我们讨论 CFD Direct。

使用 CFD Direct

在上一节中，我们看到了如何使用 ParallelCluster 在 AWS 上运行 CFD 模拟。现在，我们将探讨如何在 AWS Marketplace 上的 CFD Direct 产品中运行 CFD：aws.amazon.com/marketplace/pp/prodview-ojxm4wfrodtj4。CFD Direct 提供了一个基于 Ubuntu 的 Amazon EC2 镜像，其中包含了运行 CFD 所需的典型工具。

执行以下步骤开始操作：

点击上面的链接访问 CFD Direct 的 Marketplace 产品，然后点击继续订阅。
然后，按照提供的说明操作，并点击 继续配置（保留所有选项为默认），然后点击 继续启动。类似于 ParallelCluster，请记住使用正确的 EC2 密钥对，以便您能够 SSH 进入为您启动的实例。

图 11.10 – CFD Direct AWS Marketplace 提供的产品（截至 2022 年 8 月 5 日的截图）

按照说明获取更多关于使用 CFD Direct 的图像的帮助，请参阅cfd.direct/cloud/aws/。

要首次连接到实例，请使用以下说明：cfd.direct/cloud/aws/connect/。

在以下教程中，我们将使用 NICE DCV 客户端作为远程桌面与 EC2 实例进行交互。

安装 NICE DCV 的步骤如下：

首先，SSH 进入您刚刚启动的实例，然后下载并安装服务器。例如，对于 Ubuntu 20.04，请使用以下命令：
```
wget https://d1uj6qtbmh3dt5.cloudfront.net/nice-dcv-ubuntu2004-x86_64.tgz
```

然后，执行以下命令以提取 tar 文件：

tar -xvzf nice-dcv-2022.0-12123-ubuntu2004-x86_64.tgz && cd nice-dcv-2022.0-12123-ubuntu2004-x86_64

通过执行以下命令安装 NICE DCV：

sudo apt install ./nice-dcv-server_2022.0.12123-1_amd64.ubuntu2004.deb

要启动 NICE DCV 服务器，请使用以下命令：
```
sudo systemctl start dcvserver
```
最后，使用以下命令启动会话：
```
dcv create-session cfd
```
找到您启动的 EC2 实例的公网 IP，并使用任何 NICE DCV 客户端连接到该实例（见 图 11**.11）：

图 11.11 – 使用公网 IP 连接到 EC2 实例

接下来，使用 Ubuntu 的用户名和密码（见 图 11**.12）。如果您尚未设置密码，请在 SSH 终端上使用 passwd 命令。

图 11.12 – 输入 Ubuntu 的用户名和密码

如果提示，选择您想要连接的会话。在这里，我们启动了一个名为 cfd 的会话。现在您应该能看到预装了 OpenFOAM 9 的 Ubuntu 桌面。

图 11.13 – 由 CFD Direct 提供的 Ubuntu 桌面

要定位所有要尝试的 OpenFOAM 教程，请使用以下命令：
```
echo $FOAM_TUTORIALS
```
```
/opt/openfoam9/tutorials
```

我们将在以下目录中运行一个基本的翼型教程：

/opt/openfoam9/tutorials/incompressible/simpleFoam/airFoil2D/

目录设置与典型的 OpenFOAM 案例类似，包含以下内容（在 Ubuntu 上使用 tree 命令进行探索）：

/opt/openfoam9/tutorials/incompressible/simpleFoam/airFoil2D/
|-- 0
|   |-- U
|   |-- nuTilda
|   |-- nut
|   `-- p
|-- Allclean
|-- Allrun
|-- constant
|   |-- momentumTransport
|   |-- polyMesh
|   |   |-- boundary
|   |   |-- cells
|   |   |-- faces
|   |   |-- neighbour
|   |   |-- owner
|   |   `-- points
|   `-- transportProperties
`-- system
    |-- controlDict
    |-- fvSchemes
    `-- fvSolution

让我们探索一些这些文件，因为这将帮助您了解任何 OpenFOAM 案例的结构。名为 0 的文件夹代表我们将要解决这些关键量的初始条件（即，时间步长 0）：

速度 (U)
压力 (p)

这些文件看起来是什么样子？让我们看看 U（速度）文件：

FoamFile
{
    format      ascii;
    class       volVectorField;
    object      U;
}
dimensions      [0 1 -1 0 0 0 0];
internalField   uniform (25.75 3.62 0);
boundaryField
{
    inlet
    {
        type            freestreamVelocity;
        freestreamValue $internalField;
    }
    outlet
    {
        type            freestreamVelocity;
        freestreamValue $internalField;
    }
    walls
    {
        type            noSlip;
    }
    frontAndBack
    {
        type            empty;
    }
}

如我们所见，该文件定义了 CFD 域的尺寸、自由流速度，以及入口、出口和壁面边界条件。

Airfoil2D 文件夹还包含一个名为 constant 的文件夹；此文件夹包含我们将要创建的 CFD 网格的特定文件。momentumTransport 文件定义了解决此问题所使用的模型类型：

simulationType RAS;
RAS
{
    model           SpalartAllmaras;
    turbulence      on;
    printCoeffs     on;
}

在这里，我们使用 Reynolds-Averaged Flow （RAF）类型的 SpalartAllmaras 湍流模型。有关更多信息，请访问 www.openfoam.com/documentation/guides/latest/doc/guide-turbulence-ras-spalart-allmaras.html。

polyMesh 文件夹内的 boundary 文件包含了墙壁本身的定义；这是为了让模拟知道表面入口或墙壁代表什么。polyMesh 文件夹中还有其他几个文件，我们将在本节中不进行探讨。

在 System 文件夹内，controlDict 文件定义了为此案例运行的应用程序。OpenFOAM 包含超过 200 个编译应用程序；其中许多是求解器以及代码的前处理和后处理。

最后，我们来到了 OpenFOAM 案例中最重要的一些文件之一：Allrun 可执行文件。Allrun 文件是一个 shell 脚本，按照我们之前定义的顺序运行每个典型 CFD 应用程序的步骤 – 导入几何形状、创建网格、解决 CFD 问题以及后处理结果。

根据您在 ControlDict 文件中定义的输出间隔，将在同一目录中输出几个输出文件夹，对应于模拟中的不同时间戳。CFD 求解器将解决问题，直到收敛或达到最大时间步数。输出文件夹将类似于我们之前创建的 timestep 0 文件夹。为了可视化这些结果，我们使用一个名为 ParaView 的工具：

首先，让我们看看我们创建的网格（见图 11.14）。OpenFOAM 中包含的负责创建此网格的可执行文件是 blockmesh 和 snappyhexmesh。您也可以手动运行这些命令，而不是运行 Allrun 文件。

图 11.14 – OpenFOAM 中 Airfoil 2D 案例的网格

太好了 – 使用 SimpleFoam 可执行文件解决问题后，让我们看一下翼型周围的压力分布（见图 11.15）：

图 11.15 – OpenFOAM 中 Airfoil 2D 案例的压力分布

最后，我们可以使用 ParaView 来可视化速度分布，以及流线（见图 11.16）：

图 11.16 – OpenFOAM 中 Airfoil 2D 案例的速度分布

注意，这些图表是通过使用paraFoam可执行文件初始化ParaView后进行后处理的，它能够自动理解由 OpenFOAM 案例格式化的输出。

现在让我们看看一个稍微复杂一些的案例——汽车周围的流动：

首先，让我们看看车辆的几何形状（图 11.17 和 图 11.18）：

图 11.17 – 车辆几何形状（透视视图）

图 11.18 – 车辆几何形状（侧面视图）

接下来，我们可以使用blockmesh和snappyhexmesh命令来创建围绕汽车的 CFD 网格（参见图 11.19）：

图 11.19 – 为车辆案例创建的网格

然后，我们可以运行Allrun文件来解决问题。最后，我们将可视化输出（图 11.20 和 图 11.21）：

图 11.20 – 为车辆案例创建的流线（黑色）和压力分布（透视视图）

图 11.21 – 为车辆案例创建的流线（黑色）和压力分布（侧面视图）

以下案例所需的文件可以在 GitHub 仓库提供的 ZIP 文件中找到：github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter11/runs。

在下一节中，我们将讨论与使用 CFD 工具的机器学习和深度学习相关的 CFD 领域的某些进展。

讨论如何将机器学习应用于 CFD

CFD（计算流体动力学）作为一个存在了几十年的领域，已经发展成熟，对各个领域的公司非常有用，并且已经通过云服务提供商大规模实施。最近在机器学习（ML）方面的进步已经应用于 CFD，在本节中，我们将为读者提供关于这个领域的文章的指引。

总体来看，我们看到深度学习技术以两种主要方式得到应用：

使用深度学习将输入映射到输出。在本章中，我们探讨了翼型上的流动并可视化了这些结果。如果我们有足够的输入变化并将输出保存为图像，我们可以使用自编码器或生成对抗网络（GANs）来生成这些图像。例如，以下论文使用 GANs 来预测使用稀疏数据的翼型流动：www.sciencedirect.com/science/article/pii/S1000936121000728。正如我们在图 11.22中看到的那样，CFD 和 GAN 预测的流动场在视觉上非常相似：

图 11.22 – 由训练好的 GAN（左）和 CFD（右）生成的压力分布

同样，Autodesk 训练了一个包含 800 多个汽车示例的网络，可以瞬间预测新汽车体的流动和阻力：dl.acm.org/doi/10.1145/3197517.3201325（参见图 11.23）。

图 11.23 – 预测各种汽车形状的流动场和阻力系数

第二种创新的一般类型不仅仅是将输入映射到输出，而是实际上将机器学习技术作为 CFD 求解器本身的一部分。例如，NVIDIA 的 SIMNET(arxiv.org/abs/2012.07938)论文描述了如何使用深度学习来模拟定义流体流动和其他物理现象的实际偏微分方程(PDEs)。参见图 11.24中的示例结果，展示了 SIMNET 对散热片的流动。参数化训练运行比商业和开源求解器更快，对新几何形状的推理是瞬时的。

图 11.24 – OpenFOAM 与 NVIDIA 的 SIMNET 在速度（顶部行）和温度（底部行）比较

让我们总结一下在本章中学到的内容。

摘要

在本章中，我们提供了对 CFD 世界的概述，然后探讨了多种使用 AWS 解决 CFD 问题的方法（使用 ParallelCluster 和 EC2 上的 CFD Direct）。最后，我们讨论了一些将 CFD 领域与 ML 联系起来的最新进展。虽然本书的范围不包括对 CFD 的更多细节，但我们希望读者能受到启发，更深入地探索这里探讨的主题。

在下一章中，我们将专注于使用 HPC 的基因组学应用。具体来说，我们将讨论药物发现，并对蛋白质结构预测问题进行详细的讲解。

参考文献

AWS Batch: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#aws-batch-v3
AWS CloudFormation: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#aws-services-cloudformation-v3
Amazon CloudWatch: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-cloudwatch-v3
Amazon CloudWatch Logs: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-cloudwatch-logs-v3
AWS CodeBuild: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#aws-codebuild-v3
Amazon DynamoDB: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-dynamodb-v3
Amazon Elastic Block Store: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-elastic-block-store-ebs-v3
Amazon Elastic Container Registry: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-elastic-container-registry-ecr-v3
Amazon EFS: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-efs-v3
Amazon FSx for Lustre: docs.aws.amazon.com/parallelcluster/latest/ug/aws-services-v3.html#amazon-fsx-for-lustre-v3

第十二章：基因组学

基因组学是研究生物体基因组或遗传物质的科学。在人类中，遗传物质以脱氧核糖核酸（DNA）的形式储存。这些是构成人类个体的指令，人类基因组中有 99.9%是相同的，只有 0.1%是不同的，这导致了诸如眼色等身体特征的差异。大多数这些变异是无害的，但一些变异可能导致健康问题，例如镰状细胞性贫血。因此，分析此类信息可以用于预测或预防疾病，或提供个性化治疗，也称为精准医疗。DNA 中存在四种化学碱基，即腺嘌呤（A）、胸腺嘧啶（T）、胞嘧啶（C）和鸟嘌呤（G）。它们总是以特定的方式结合；例如，腺嘌呤总是与胸腺嘧啶结合，而胞嘧啶与鸟嘌呤结合。这些化学碱基的组合构成了 DNA 序列。

测序是基因组学的核心。为了理解它的含义，人类基因组计划（www.ncbi.nlm.nih.gov/pmc/articles/PMC6875757/pdf/arhw-19-3-190.pdf）于 1989 年启动，目标是 15 年内测序一个人类基因组。这项工作在 2001 年的 12 年内完成，涉及数千名科学家。随着下一代测序技术的发展，现在可以在大约一天内生成整个人类基因组。单个人类基因组大约有 30 亿个碱基对长；其他生物体，如老鼠或牛，也有类似的大小。

由于生成基因组序列的时间和成本显著降低，这导致了大量数据的生成。因此，为了分析如此大量的数据，我们需要强大的机器和大量的经济高效的存储。好消息是 DNA 测序数据是公开可用的，其中最大的存储库之一是国家生物技术信息中心（NCBI）。我们可以使用统计和机器学习（ML）模型从基因组数据中获得见解，这可能需要大量的计算。这提出了两个主要挑战：需要大数据和大规模的 ML 模型来进行预测，例如预测启动子或预测掩蔽的 DNA 序列。

因此，本章将通过涵盖以下主题来帮助您应对这些挑战：

在 AWS 上管理大型基因组数据
设计基因组学架构
将机器学习应用于基因组学

技术要求

在开始本章之前，您应该具备以下先决条件：

网络浏览器（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器）
访问您在 第五章，数据分析 中使用的 AWS 账户
访问我们在第五章（[B18493_05.xhtml#_idTextAnchor095]）数据分析中创建的 SageMaker Studio 开发环境
本章的示例 Jupyter 笔记本可在配套的 GitHub 仓库中找到（github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter06）

在 AWS 上管理大型基因组数据

除了基因组数据集的大规模之外，管理它所面临的挑战还包括可发现性、可访问性、可用性，以及将其存储在允许可扩展数据处理同时保持关键数据安全的存储系统中。负责和安全地共享基因组与健康数据是加速研究和改善人类健康的关键目标，这是全球基因组与健康联盟（GA4GH）的一个明确目标。这种方法需要两个重要的事情：一是对领域有深入的技术理解，二是访问计算和存储资源。你还可以在AWS 开放数据注册表（registry.opendata.aws/）上找到由 AWS 托管的许多基因组数据集。

在您可以使用云服务对基因组数据集进行任何处理之前，您需要确保它已传输并存储在 AWS 云上。对于存储数据，我们建议使用Amazon Simple Storage Services（Amazon S3），因为下一代测序仪产生的基因组数据以文件形式持久化，许多基因组数据分析工具也以文件作为输入，并将输出写回文件。例如，使用机器学习模型进行数据分析可能涉及以大型 DNA 序列文件作为输入，并将推理或预测结果存储在文件中，对于这种情况，Amazon S3 是一个自然的选择。

您可以通过启用服务器端加密来安全地存储基因组数据，无论是使用Amazon S3 管理的加密密钥（SSE-S3）还是AWS 密钥管理服务（AWS KMS）密钥。此外，Amazon S3 还允许您通过将不常访问的数据存储在Amazon S3 标准-不经常访问（S3 Standard-IA）层或存档到低成本存储选项，例如当数据未使用时存档到Amazon S3 Glacier Deep Archive，来启用数据生命周期，从而显著降低成本。这种模式在第四章（[B18493_04.xhtml#_idTextAnchor074]）数据存储的分层存储以优化成本部分有详细讨论。

对于将基因组数据传输到 Amazon S3，您可以使用在第二章（[B18493_02.xhtml#_idTextAnchor035]）数据管理和传输中讨论的 AWS DataSync 服务。

让我们更详细地看看将机器学习模型应用于基因组数据集的详细架构。

设计基因组学架构

在本节中，我们将描述一个示例参考架构，用于在 AWS 云中以安全和经济的方式传输、存储、处理和获取基因组数据集的见解。图 12.1显示了示例基因组数据处理流程：

图 12.1 – 基因组数据处理流程

图 12.1显示了以下工作流程：

科学家或实验室技术人员将收集样本基因组数据，例如皮肤细胞，在实验室中准备它，然后将其加载到测序仪中。
然后，测序仪将生成一个序列，这可能是短的 DNA 片段。这些通常被称为reads，因为您正在读取 DNA。
DNA 序列存储在本地数据存储系统中。
然后，AWS DataSync 服务将基因组数据安全地传输到云端；有关更多详细信息，请参阅第二章，数据管理 和传输。
然后将原始基因组数据存储在 Amazon S3 上。您可以使用 AWS Analytics 工具进行数据处理。
Amazon Genomics CLI 是一个专为在云中处理 PB 级原始基因组数据而构建的开源工具。有关详细信息，请参阅此链接：aws.amazon.com/genomics-cli/。
可选地，我们建议将处理过的基因组数据存储在Amazon Feature Store上，这是一个用于存储、共享、版本控制和管理的完全托管服务，用于存储、共享、版本控制和管理的机器学习特征，以便在机器学习应用之间重用特征。
您可以使用AWS Lake Formation服务在 Amazon S3 或 Amazon Feature Store 上存储的基因组数据上添加细粒度的访问控制策略，根据您的业务需求。有关 AWS Lake Formation 的详细信息，请参阅此链接：aws.amazon.com/lake-formation。
一旦数据被处理并存储在 Amazon Feature Store 或 Amazon S3 上，您可以使用Amazon SageMaker运行如DNABERT（www.biorxiv.org/content/10.1101/2020.09.17.301879v1）等机器学习模型，以获得更深入的见解或预测掩码 DNA 序列。该机器学习模型可以处理一批基因组数据，进行推理，并将结果存储回 Amazon S3。
此外，您可以将未使用的数据存档到 Amazon S3 Glacier Deep Archive，以在数据存储上实现显著的成本节约。

注意

本章不涉及对 Amazon Genomics CLI、AWS Lake Formation 和 Amazon Feature Store 的详细讨论；然而，我们将在本章的将机器学习应用于基因组部分使用 DNABERT 模型。

让我们学习如何将机器学习模型应用于基因组应用，并使用预训练的机器学习模型预测 DNA 序列中的掩码序列。

将机器学习应用于基因组

在我们深入探讨机器学习模型细节之前，让我们首先了解基因组数据，它以 DNA 的形式存储在每一个生物体中。DNA 中存在四种化学碱基，即ACTCCACAGTACCTCCGAGA。人类基因组的一个完整序列大约有 30 亿个碱基对（bp）长，大约需要 200 GB 的数据存储空间(www.science.org/doi/10.1126/science.abj6987)。

然而，对于分析 DNA 序列，我们不需要完整的基因组序列。通常，我们只分析人类 DNA 的一部分；例如，为了确定毛发生长或皮肤生长，实验室技术人员会取一小部分人类皮肤并准备它通过下一代测序仪，然后读取 DNA 并生成 DNA 序列，这些是 DNA 的短片段。机器学习模型可用于各种任务，例如 DNA 分类、启动子识别、解释人类基因组中的结构变异、精准医疗、癌症研究等等。

在本节中，我们将展示如何使用 Amazon SageMaker 对 DNABERT 模型进行微调，以执行近端启动子识别任务。DNABERT 基于在 DNA 序列上微调的 BERT 模型，如研究论文监督启动子识别：一个基准框架（bmcbioinformatics.biomedcentral.com/track/pdf/10.1186/s12859-022-04647-5.pdf）中概述的。因此，让我们以在 Amazon SageMaker 服务上使用 DNA 序列数据部署预训练的 DNABERT 模型进行启动子识别为例。

Amazon SageMaker 是 AWS 提供的一项完全托管服务，旨在协助机器学习从业者构建、训练和部署机器学习模型。尽管它为机器学习的每个阶段提供了功能和集成开发环境，但其本质上是高度模块化的，这意味着如果您已经有一个训练好的模型，您可以使用 SageMaker 托管 功能来部署模型，以便在您的模型上执行推理/预测。有关 SageMaker 提供的各种部署选项的详细信息，请参阅第七章，大规模部署机器学习模型。

我们将部署由Hugging Face提供的 DNABERT 预训练模型版本，Hugging Face 是一个拥有 65K+预训练 transformer 模型的 AI 社区。Amazon SageMaker 为 Hugging Face 提供了一方深度学习容器，用于训练和推理。这些容器包括 Hugging Face 预训练 transformer 模型、分词器和数据集库。有关所有可用容器的列表，您可以参考此链接：github.com/aws/deep-learning-containers/blob/master/available_images.md。这些容器定期维护和更新，包括安全补丁，并减轻了机器学习实践者的繁重工作。

通过几行配置代码，您可以在 Amazon SageMaker 上部署 Hugging Face 库中的预训练模型，并开始使用您的模型进行预测。Amazon SageMaker 为部署 ML 模型提供了许多功能。例如，在实时推理的情况下，当您选择将模型作为 API 部署时，设置自动扩展策略以根据模型调用的数量调整部署的实例数量。此外，您可以使用 Amazon SageMaker 托管功能进行蓝绿部署、添加安全护栏、自动回滚等操作。有关部署推理模型的详细信息，请参阅此链接：docs.aws.amazon.com/sagemaker/latest/dg/deploy-model.html。现在我们已经了解了使用 Amazon SageMaker 部署模型和 Hugging Face 集成的优势，让我们看看我们如何部署用于促进识别的预训练 DNABERT 模型。

注意

部署模型的完整代码可在 GitHub 上找到：github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/blob/main/Chapter12/dnabert.ipynb。

我们需要遵循三个步骤来部署由 Hugging Face 库在 Amazon SageMaker 上提供的预训练 transformer 模型进行实时推理：

提供模型中心配置，其中我们提供 Hugging Face 模型 ID 和任务——在我们的案例中，是文本分类。
创建一个由 SageMaker API 提供的HuggingFaceModel类，其中我们提供参数，如 transformer 版本、PyTorch 版本、Python 版本、中心配置和角色。
最后，我们使用deploy() API，其中我们提供要部署的实例数量和实例类型。

以下代码片段展示了我们刚刚概述的三个步骤：

…
from sagemaker.huggingface import HuggingFaceModel
import sagemaker
role = sagemaker.get_execution_role()
# Step 1: Hub Model configuration. https://huggingface.co/models
hub = {
     'HF_MODEL_ID':'AidenH20/DNABERT-500down',
     'HF_TASK':'text-classification'
}
# Step 2: create Hugging Face Model Class
huggingface_model = HuggingFaceModel(
     transformers_version='4.17.0',
     pytorch_version='1.10.2',
     py_version='py38',
     env=hub,
     role=role,
)
# Step 3: deploy model to SageMaker Inference
predictor = huggingface_model.deploy(
     initial_instance_count=1, # number of instances
     instance_type='ml.m5.xlarge' # ec2 instance type
)
…

使用此代码片段，我们基本上告诉 SageMaker 部署在'HF_MODEL_ID'中提供的 Hugging Face 模型，用于'HF_TASK'中提到的任务；在我们的案例中，是text classification，因为我们希望通过提供 DNA 序列来对启动子区域进行分类。HuggingFaceModel类定义了模型将要部署的容器。最后，deploy() API 启动由HuggingFaceModel类定义的 Hugging Face 容器，并将存储在 hub 配置中的模型加载到由 ML 实践者提供的初始实例数量和实例类型。

注意

即使模型已部署，也可以更新模型作为 API 部署的实例数量。

模型部署后，您可以使用 SageMaker 提供的predict() API 对模型进行推理或预测，如下面的代码片段所示：

…
dna_sequence = 'CTAATC TAATCT AATCTA ATCTAG TCTAGT CTAGTA TAGTAA AGTAAT GTAATG TAATGC AATGCC ATGCCG TGCCGC GCCGCG CCGCGT CGCGTT GCGTTG CGTTGG GTTGGT TTGGTG TGGTGG GGTGGA GTGGAA TGGAAA GGAAAG GAAAGA AAAGAC AAGACA AGACAT GACATG ACATGA CATGAC ATGACA TGACAT GACATA ACATAC CATACC ATACCT TACCTC ACCTCA CCTCAA CTCAAA TCAAAC CAAACA AAACAG AACAGC ACAGCA CAGCAG AGCAGG GCAGGG CAGGGG AGGGGG GGGGGC GGGGCG GGGCGC GGCGCC GCGCCA CGCCAT GCCATG CCATGC CATGCG ATGCGC TGCGCC GCGCCA CGCCAA GCCAAG CCAAGC CAAGCC AAGCCC AGCCCG GCCCGC CCCGCA CCGCAG CGCAGA GCAGAG CAGAGG AGAGGG GAGGGT AGGGTT GGGTTG GGTTGT GTTGTC TTGTCC TGTCCA GTCCAA TCCAAC CCAACT CAACTC AACTCC ACTCCT CTCCTA TCCTAT CCTATT CTATTC TATTCC ATTCCT'
predictor.predict({
     'inputs': dna_sequence
})
…

输出将是具有最高概率的标签。在我们的案例中，是LABEL_0或LABEL_1，表示 DNA 序列中是否存在启动子区域。

注意

上述代码将模型作为 API 部署在长时间运行的实例上，因此如果您不使用端点，请务必将其删除；否则，您将为此付费。

您还可以通过在左侧导航面板中点击橙色三角形图标（SageMaker 资源）并选择端点，在 SageMaker Studio 上查看端点详情，如图所示：

图 12.2 – 在 SageMaker Studio 上访问端点

这将显示所有 SageMaker 端点（作为 API 部署用于实时推理的模型）。双击端点名称将显示通过调用后台的DescribeEndpoint() API 的详细信息。SageMaker Studio UI 向您展示了大量选项，例如测试推理、数据质量、模型质量、模型可解释性、模型偏差、监控作业历史记录和AWS 设置。这些选项卡上的数据基于您启用的功能；例如，要了解数据和模型质量，您需要启用 SageMaker 的模型监控功能，该功能根据您设置的日程安排监控作为实时端点部署的模型，将其与基线统计数据进行比较，并将报告存储在 S3 中。有关模型监控的详细信息，请参阅此链接：docs.aws.amazon.com/sagemaker/latest/dg/model-monitor.html。

另一方面，AWS 设置选项卡将始终包含模型端点元数据，例如端点名称、类型、状态、创建时间、最后更新时间、Amazon Resource Name（ARN）、端点运行时设置、端点配置设置、生产变体（如果你有同一模型的多个变体）、实例详细信息（类型和实例数量）、模型名称和血统，根据适用情况。图 12.3 展示了一些与端点相关的元数据：

图 12.3 – SageMaker 端点详细信息

此外，如果你想从 SageMaker Studio UI 快速测试你的模型，你可以点击 测试推理，在 JSON 编辑器中提供 JSON 格式的有效载荷（输入请求），如图 图 12.4 所示，并快速查看模型提供的响应：

图 12.4 – 从 SageMaker Studio UI 进行测试推理

现在我们已经了解了如何在亚马逊 SageMaker 上部署和测试 Hugging Face 模型库中的预训练模型，让我们再举一个例子，看看如何微调 Hugging Face 库中的预训练模型，并部署微调后的模型。对于本节，我们将使用一个基于 BERT 的、在蛋白质序列上训练的模型，称为 ProtBERT，该模型发表在以下研究论文中：www.biorxiv.org/content/10.1101/2020.07.12.199554v3。

蛋白质结构、功能和相互作用的研究被称为 蛋白质组学，它借助基因组学研究，因为蛋白质是基因组的功能性产物。蛋白质组学和基因组学都用于预防疾病，并且是药物发现活动的一部分。尽管有很多任务有助于药物发现、蛋白质分类和二级结构识别，但它们发挥着至关重要的作用。在下一节中，我们将了解如何使用亚马逊 SageMaker 的分布式训练功能微调大型蛋白质模型（Hugging Face 库），以预测蛋白质的二级结构。

蛋白质序列的二级结构预测

蛋白质序列由 20 种必需的 氨基酸 组成，每种氨基酸由一个大写字母表示。它们组合形成一个蛋白质序列，你可以用它来进行蛋白质分类或预测蛋白质的二级结构，以及其他任务。蛋白质序列基于约束条件形成特定的 3D 结构，这些约束条件是为了执行特定功能而优化的。你可以将这些约束条件视为自然语言中的语法规则或意义，这使我们能够使用 自然语言处理（NLP）技术来处理蛋白质序列。

在本节中，我们将重点调整prot_t5_xl_uniref50模型，该模型大约有110 亿个参数，您可以使用相同的训练脚本以不同的配置调整较小的prot_bert_bfd模型，该模型大约有4.2 亿个参数，以适应模型的大小。调整prot_t5_xl_uniref50模型的代码在 GitHub 仓库中提供：github.com/PacktPublishing/Applied-Machine-Learning-and-High-Performance-Computing-on-AWS/tree/main/Chapter12。

要使用 Hugging Face 库中的模型创建 SageMaker 训练作业，我们需要一个来自 SageMaker SDK 的 Hugging Face 估计器。估计器类将根据我们提供的配置处理所有训练任务。例如，要使用基本配置训练 Hugging Face 模型，我们需要提供以下参数：

entry_point: 这是我们将指定用于训练模型的训练脚本的位置。
source_dir: 这是训练脚本或其他辅助文件所在文件夹的名称。
instance_type: 这是训练脚本将在云中运行的机器类型。
instance_count: 这是将用于运行训练作业的云中机器的数量。如果计数大于1，则将自动启动一个集群。
transfomer_version, pytorch_version, py_version: 这些参数决定了容器中将存在的 transformers、PyTorch 和 Python 的版本。根据这些参数的值，SageMaker 将获取适当的容器，并将其部署到云中的实例（机器）上。
hyperparameters: 这定义了将传递给训练脚本的命名参数。

以下代码片段将这些参数正式化为 SageMaker 训练作业：

...
huggingface_estimator = HuggingFace(entry_point='train.py',
                           source_dir='./code',
                           instance_type='ml.g5.12xlarge',
                           instance_count=1,
                           role=role,
                           transformers_version='4.12',
                           pytorch_version='1.9',
                           py_version='py38',
                           hyperparameters=hyperparameters)
...

一旦定义了估计器，您就可以提供您数据的 S3 位置（路径）以启动训练作业。SageMaker 为训练作业提供了一些非常有用的环境变量，包括以下内容：

SM_MODEL_DIR: 这提供了训练作业将存储模型工件的位置，一旦作业完成，该文件夹中存储的模型将直接上传到 S3 输出位置。
SM_NUM_GPUS: 这表示主机可用的 GPU 数量。
SM_CHANNEL_XXXX: 这表示指定通道的输入数据路径。例如，在我们的案例中，data将对应于SM_CHANNEL_DATA环境变量，该变量被训练脚本使用，如下面的代码片段所示：
```
…
```
```
# starting the train job with our uploaded datasets as input
```
```
huggingface_estimator.fit({'data': data_input_path})
```
```
…
```

当我们在 Hugging Face 估计器上调用fit()方法时，SageMaker 将首先提供临时的计算环境，并将训练脚本和数据复制到计算环境中。然后它将启动训练，将训练好的模型保存到估计器类中提供的 S3 输出位置，最后，拆除所有资源，这样用户只需为训练任务运行的时间付费。

注意

有关 SageMaker Hugging Face 估计器的更多信息，以及如何利用 SageMaker SDK 实例化估计器，请参阅 AWS 文档(docs.aws.amazon.com/sagemaker/latest/dg/hugging-face.html)和 SageMaker SDK 文档(sagemaker.readthedocs.io/en/stable/frameworks/huggingface/sagemaker.huggingface.html#hugging-face-estimator)。

我们将扩展这个基本配置，使用 SageMaker 的分布式训练功能微调prot_t5_xl_uniref50，该模型具有110 亿参数。

在我们深入代码之前，让我们首先了解一些我们将用于训练模型的概念。由于这是一个大模型，第一步是了解模型的大小，这将帮助我们确定它是否可以适应单块 GPU 内存。SageMaker 模型并行文档(docs.aws.amazon.com/sagemaker/latest/dg/model-parallel-intro.html)提供了估计模型大小的好方法。对于使用自动混合精度（AMP）和16 位浮点数（FP16）大小的Adam 优化器的训练任务，我们可以使用以下分解来计算每参数所需的内存，大约为 20 字节：

一个 FP16 参数 ~ 16 位或 2 字节
一个 FP16 梯度 ~ 16 位或 2 字节
一个基于 Adam 优化器的 FP32 优化器状态 ~ 64 位或 8 字节
一个参数 FP32 副本 ~ 32 位或 4 字节（用于优化器应用（OA）操作）
一个梯度 FP32 副本 ~ 32 位或 4 字节（用于 OA 操作）

因此，我们这个拥有 110 亿参数的模型将需要超过 220 GB 的内存，这比目前单块 GPU 上可用的典型 GPU 内存要大。即使我们能够获得具有超过 220 GB GPU 内存的机器，这也不会具有成本效益，而且我们无法扩展我们的训练任务。在这里需要理解的一个另一个约束是批大小，因为我们至少需要一个数据批次在内存中才能开始训练。使用较小的批大小会降低 GPU 利用率并降低训练效率，因为模型可能无法收敛。

因此，我们必须将我们的模型分割成多个 GPU，为了增加批量大小，我们还需要对数据进行分片。所以，我们将采用一种混合方法，该方法将利用数据并行和模型并行的两种方法。这种方法在第六章《机器学习模型的分布式训练》中已有详细解释。

由于我们的模型大小为 220 GB，我们将在训练作业中使用一种机制，以优化内存以避免内存不足（OOM）错误。为了内存优化，SageMaker 模型并行库提供了两种类型的模型并行性，即流水线并行性和张量并行性，以及内存节省技术，如激活检查点、激活卸载和优化器状态分片。让我们了解每个术语：

如果配置中提供的partitions参数值为2，则模型将在 4 个 GPU 上分成 2 个分区，这意味着它将有 2 个模型副本。由于在这种情况下，GPU 的数量大于分区的数量，我们必须将ddp参数设置为true。否则，训练作业将给出错误。启用ddp的流水线并行性在图 12.5中得到了说明：

图 12.5 – 展示了模型和数据并行的混合方法

张量并行性：这种方法与流水线并行性具有相同的概念，并且更进一步，将我们模型的最大层分割并放置在不同的节点上。这一概念在图 12.6中得到了说明：

图 12.6 – 张量并行性将模型的张量（层）分割到多个 GPU 上

激活检查点：通过清除层的激活并在反向传播期间重新计算，这有助于减少内存使用。对于任何深度学习模型，数据首先在正向传播中通过中间层，这些层计算输出，也称为激活。这些激活需要被存储，因为它们在反向传播期间用于计算梯度。现在，在内存中存储大型模型的激活可以显著增加内存使用，并可能导致瓶颈。为了克服这个问题，激活检查点或梯度检查点技术就派上用场了，它可以清除中间层的激活。

注意

激活检查点会导致额外的计算时间，以减少内存使用。

激活卸载：这使用激活检查点，在模型训练期间仅在 GPU 内存中保留少量激活。在正向传递期间，将检查点激活卸载到 CPU 内存，在特定微批数据的反向传递期间将它们加载回 GPU。
优化器状态分片：这是另一种有用的内存节省技术，它将描述由权重集定义的优化器状态分割到数据并行设备组中。它只能在使用状态优化器的情况下使用，例如 Adam 或 FP16。

注意

由于优化器状态分片将优化器状态分割到数据并行设备组中，它只有在数据并行度大于一的情况下才会变得有用。

在模型并行中理解的一个重要概念是微批，它是数据批次的一个较小子集。在训练过程中，你将一定数量的数据记录正向和反向通过层，称为批次或有时称为小批量。完整遍历你的数据集称为一个 epoch。SageMaker 模型并行将批次分割成更小的子集，这些子集称为微批。然后，这些微批通过管道调度器传递以提高 GPU 利用率。管道调度器在第六章中详细解释，机器学习模型的分布式训练。

因此，现在我们了解了 SageMaker 模型并行库使用的内存节省技术，让我们看看如何在代码中使用它们。以下代码片段以简单的方式将所有内存节省技术组合在一起：

…
# configuration for running training on smdistributed Model Parallel
mpi_options = {
    "enabled": True,
    "processes_per_host": 8,
}
smp_options = {
    "enabled":True,
    "parameters": {
        "microbatches": 1,
        "placement_strategy": "cluster",
        "pipeline": "interleaved",
        "optimize": "memory",
        "partitions": 4,
        "ddp": True,
        # "tensor_parallel_degree": 2,
        "shard_optimizer_state": True,
        "activation_checkpointing": True,
        "activation_strategy": "each",
        "activation_offloading": True,
    }
}
distribution = {
    "smdistributed": {"modelparallel": smp_options},
    "mpi": mpi_options
}
…

所有节省内存的技术都在代码片段中突出显示，你首先必须确保将optimize参数设置为memory。这指示 SageMaker 模型拆分算法优化内存消耗。一旦设置完成，你就可以通过将它们的值设置为true来简单地启用其他内存节省功能。

然后，你将distribution配置提供给HuggingFace估计器类，如下面的代码片段所示：

…
huggingface_estimator = HuggingFace(entry_point='train.py',
                           source_dir='./code',
                           instance_type='ml.g5.48xlarge',
                           instance_count=1,
                           role=role,
                           transformers_version='4.12',
                           pytorch_version='1.9',
                           py_version='py38',
                           distribution= distribution,
                           hyperparameters=hyperparameters)
huggingface_estimator.fit({'data': data_input_path})
…

如你所见，我们还提供了train.py训练脚本作为估计器的entry_point。在第六章中，机器学习模型的分布式训练，我们了解到当我们使用模型并行时，我们必须使用 SageMaker 模型并行结构更新我们的训练脚本。在这个例子中，因为我们使用HuggingFace估计器和Trainer API 进行模型训练，它内置了对 SageMaker 模型并行的支持。因此，我们只需导入 Hugging Face 的Trainer API 并提供与模型训练相关的配置，根据HuggingFace估计器中提供的模型并行配置，它将在模型训练期间调用 SageMaker 模型并行结构。

在我们的train.py脚本中，首先，我们需要导入Trainer模块，如下面的代码片段所示：

…
from transformers.sagemaker import SageMakerTrainingArguments as TrainingArguments
from transformers.sagemaker import SageMakerTrainer as Trainer
…

由于我们正在训练一个基于 T5 的 BERT 模型（prot_t5_xl_uniref50），我们还需要从transformers库中导入T5Tokenizer和T5ForConditionalGeneration模块：

…
from transformers import AutoTokenizer, T5ForConditionalGeneration, AutoModelForTokenClassification, BertTokenizerFast, EvalPrediction, T5Tokenizer
…

下一步是将蛋白质序列转换为 PyTorch DataLoader，并将它们加载进去。在获得DataLoader中的数据后，我们将提供TrainingArguments，如下面的代码片段所示，它将被Trainer API 使用：

…
training_args = TrainingArguments(
    output_dir='./results',         # output directory
    num_train_epochs=2,              # total number of training epochs
    per_device_train_batch_size=1,   # batch size per device during training
    per_device_eval_batch_size=1,   # batch size for evaluation
    warmup_steps=200,                # number of warmup steps for learning rate scheduler
    learning_rate=3e-05,             # learning rate
    weight_decay=0.0,                # strength of weight decay
    logging_dir='./logs',            # directory for storing logs
    logging_steps=200,               # How often to print logs
    do_train=True,                   # Perform training
    do_eval=True,                    # Perform evaluation
    evaluation_strategy="epoch",     # evalute after each epoch
    gradient_accumulation_steps=32,  # total number of steps before back propagation
    fp16=True,                       # Use mixed precision
    fp16_opt_level="02",             # mixed precision mode
    run_name="ProBert-T5-XL",      # experiment name
    seed=3,                         # Seed for experiment reproducibility
    load_best_model_at_end=True,
    metric_for_best_model="eval_accuracy",
    greater_is_better=True,
    save_strategy="epoch",
    max_grad_norm=0,
    dataloader_drop_last=True,
    )
…

如您所见，TrainingArguments包含一系列超参数，例如 epoch 数量、学习率、权重衰减、评估策略等，这些参数将用于模型训练。有关TrainingArguments API 的不同超参数的详细信息，您可以参考此 URL：huggingface.co/docs/transformers/v4.24.0/en/main_classes/trainer#transformers.TrainingArguments。确保在提供TrainingArguments时，dataloader_drop_last的值设置为true。这将确保批大小可以被微批次整除，并将fp16设置为true将使用自动混合精度进行模型训练，这也有助于减少内存占用，因为浮点 16 位需要 2 个字节来存储一个参数。

现在，我们将定义Trainer API，它接受TrainingArguments以及训练和验证数据集作为输入：

…
trainer = Trainer(
    model_init=model_init,                # the instantiated Transformers model to be trained
    args=training_args,                   # training arguments, defined above
    train_dataset=train_dataset,          # training dataset
    eval_dataset=val_dataset,             # evaluation dataset
    compute_metrics = compute_metrics,    # evaluation metrics
    )
…

一旦定义了Trainer API，模型训练将通过train()方法启动，一旦训练完成，我们将使用save_model()方法将训练好的模型保存到指定的模型目录：

…
trainer.train()
trainer.save_model(args.model_dir)
…

save_model() API 接受模型路径作为参数，该路径来自SM_MODEL_DIR SageMaker 容器环境变量，并解析为model_dir变量。然后，存储在此路径中的模型工件将被复制到HuggingFace估计器中指定的 S3 路径，随后所有资源，如训练实例，都将被拆除，这样用户只需为训练作业的持续时间付费。

注意

我们正在训练一个非常大的模型prot_t5_xl_uniref50，在非常大的实例ml.g5.48xlarge上，该实例是一个具有 8 个 GPU 和 768 GB GPU 内存的 NVIDIA A10G 张量核心机器，具有 110 亿个参数。尽管我们使用了模型并行，但模型的训练将需要超过 10 个小时，您将为此承担费用。或者，您可以使用较小的模型，例如prot_bert_bfd，它大约有 4.2 亿个参数，并在蛋白质序列上预训练。由于它是一个相对较小的模型，可以适应单个 GPU 内存，因此您只能使用如第六章**， 机器学习模型的分布式训练 *中描述的 SageMaker 分布式数据并行库。

模型训练完成后，您可以使用 SageMaker 的HuggingFaceModel类来部署模型，如本章“将机器学习应用于基因组学”主部分中所述，或者简单地使用huggingface_estimator.deploy() API，如下面的代码片段所示：

…
predictor = huggingface_estimator.deploy(1,"ml.g4dn.xlarge")
…

模型部署后，您可以使用predictor变量进行预测：

…
predictor.predict(input_sequence)
…

注意

所讨论的部署选项都将模型作为 API 部署到长期运行的实例上进行实时推理。因此，如果您不使用端点，请确保将其删除；否则，您将为此承担费用。

现在我们已经了解了机器学习在基因组学中的应用，接下来让我们回顾一下到目前为止所学的知识。

摘要

在本章中，我们首先了解了基因组学的概念以及如何在 AWS 上存储和管理大量基因组数据。我们还讨论了使用 AWS 服务进行数据传输、存储、分析和将机器学习应用于基因组数据的端到端架构设计。然后，我们关注了如何使用 Amazon SageMaker 和几行代码部署用于基因组学的大规模最先进模型，例如 DNABERT，用于启动子识别任务，以及如何使用代码和 SageMaker Studio UI 测试您的端点。

然后，我们转向了解蛋白质组学，这是研究蛋白质序列、结构和它们的功能的学科。我们通过一个使用具有 110 亿参数的 Hugging Face 预训练模型预测蛋白质二级结构的示例来了解蛋白质组学。由于这是一个内存需求超过 220 GB 的大模型，我们探索了 SageMaker 模型并行库提供的各种内存节省技术，如激活检查点、激活卸载、优化器状态分片和张量并行。然后，我们使用这些技术来训练我们的模型以预测蛋白质结构。我们还了解了 SageMaker 如何与 Hugging Face 集成，并使其能够轻松使用最先进模型，否则在训练过程中需要做大量的繁重工作。

在下一章中，我们将回顾另一个领域，即自动驾驶汽车，并了解 AWS 提供的高性能计算能力如何用于大规模训练和部署机器学习模型。

第十三章：自动驾驶汽车

现在，几乎每家汽车公司都在使用自动驾驶汽车（AV）系统和高级驾驶辅助系统（ADAS）来推进他们汽车中的技术。这包括从定速巡航到多个安全特性，以及你们可能都熟悉的完全自动驾驶。如果您不熟悉这些概念，我们鼓励您参加以下速成课程——试驾一辆具有完全自动驾驶能力的汽车，以欣赏构建这些系统所涉及的技术和复杂性。目前，在 AV 和 ADAS 系统中大量投资的公司需要大量的计算资源来测试、模拟和开发相关技术，然后再将其部署到他们的汽车中。许多公司正在转向云服务，以满足这些大规模应用对按需、弹性计算的需求。前几章已经涵盖了存储、网络和计算，并介绍了机器学习。

在本章中，我们将广泛介绍 AV 系统和 ADAS 是什么，以及 AWS 计算和 ML 服务如何帮助设计 AV/ADAS 架构。具体来说，我们将涵盖以下主题：

介绍 AV 系统
支持 AV 系统的 AWS 服务
设计 AV 系统的架构
机器学习在 AV 系统中的应用

到本章结束时，你将了解以下内容：

AV 系统中的高级技术
可以用于创建和测试与 AV 相关的软件的 AWS 服务
机器学习在 AV 开发中的应用

技术要求

在开始本章之前，你应该具备以下先决条件：

熟悉 AWS 及其基本使用。
一个网络浏览器。（为了获得最佳体验，建议您使用 Chrome 或 Firefox 浏览器。）
一个 AWS 账户。（如果您不熟悉如何开始 AWS 账户，您可以访问此链接：aws.amazon.com/getting-started/。）

介绍 AV 系统

如我们之前提到的，几家汽车公司已经在他们的车辆中实施 ADAS 和 AV 系统。因此，在这个领域正在进行大量的研究和开发，但本节将向你介绍关键术语和概念，以便我们进一步探讨机器学习在这里的涉及情况。

首先，让我们从高层次上讨论 ADAS 和 AV。对于刚开始接触这个领域的人来说，有几个问题线索会导致混淆，如下所示：

AV 系统和 ADAS 是否是同一件事？
ADAS 是否包含在 AV 系统中？
公司通常会先开发 ADAS 系统，然后再开发 AV 系统吗？
AV 系统中是否存在不同的自动化级别？

在我们能够回答这些问题之前，让我们进一步深入探讨。为了自动化驾驶体验的任何一部分，无论是汽车还是集装箱卡车，以下组件的创新变得必要：

驾驶辅助或自动驾驶硬件
驾驶辅助或自动驾驶软件
数据和计算服务

在添加这些技术时，第一步是添加正确的硬件。通常，这包括雷达、激光雷达和摄像头传感器的组合。

无线电探测与测距，或称为雷达，使用无线电波来估计周围物体的距离和速度。雷达根据其范围分为短程、中程和长程。短程雷达用于停车距离辅助和盲点监控等功能。长程雷达用于车道保持、自动制动等。
光探测与测距，或称为激光雷达，与雷达类似，但使用从表面反射的光来确定物体距离。高分辨率激光雷达还可以与深度学习（DL）算法一起使用，以确定物体的形状，正如我们将在本章后面学到的那样。
最后，车辆周围安装了摄像头，用于低级任务，如停车，以及高级任务，如完全自动驾驶（当使用完整的摄像头阵列和正确的深度学习算法时）。特斯拉公司的首席执行官埃隆·马斯克，该公司是一家拥有大量已售出具有自动驾驶功能的汽车的公司，著名地更喜欢特斯拉汽车只设计有摄像头系统——没有雷达或激光雷达——因为他表示，人类只依赖视觉来驾驶。以下图显示了特斯拉较老的系统架构，现在它严重依赖于基于计算机视觉的系统，而不是激光雷达。

图 13.1 – 安装在自动驾驶车辆上的摄像头、雷达和激光雷达传感器。

在典型的汽车底盘上，你可以想象这些传感器被安装的情况，如图 13.1所示。正如我们所见，有几个摄像头、雷达和激光雷达传感器，它们被用来实现车辆的多种自动驾驶级别。那么，这些自动驾驶级别是什么？

除了之前定义的一些硬件（传感器）之外，还需要一个复杂的软件堆栈来构建和维护自动驾驶车辆开发所需的功能。这些功能被汽车工程师协会（SAE）分类，并且被广泛采用。SAE 定义了（2014 年及以后修订）五个级别的自动驾驶（见此处：www.sae.org/blog/sae-j3016-update）：

级别 0：提供警告和有限辅助的功能，例如，自动紧急制动、盲点警告和车道偏离警告。
第一级 – 基本驾驶辅助：驾驶员可以抬起脚离开踏板，但需要保持手在方向盘上以接管，例如车道保持或定速巡航。请注意，定速巡航也可以是自适应的，与前方车辆保持安全距离。
第二级 – 有限自动化：系统控制转向、制动和驾驶，但仅限于有限场景。然而，驾驶员必须随时准备接管，以确保安全。
第三级 – 低级自动化：系统可以在更多情况下导航，例如在高速公路驾驶外，还可以在交通中驾驶。驾驶员仍需要在某些情况下接管驾驶。
第四级 – 高级自动化：系统在所有情况下控制车辆，驾驶员仅在遇到未知情况时很少需要接管。这项技术旨在用于无人出租车和卡车，尽管驾驶员仍然在场，以减少工作量和疲劳。
第五级 – 完全自动化：系统可以处理所有驾驶情况，无需驾驶员在场。

注意

为了澄清本章开头提出的一个问题，ADAS 可能是更大 AV 系统的一部分或独立使用。它们主要关注低级自动化任务和驾驶员辅助，如自适应定速巡航或驾驶员警觉性警告系统。

下图显示了 SAE 对自动化水平的定义：

图 13.2 – 自动化水平 SAE。来源：www.sae.org/blog/sae-j3016-update

在本节中，我们以高级别介绍了 AV 系统相关的基本概念，包括这些系统开发所需的硬件和软件组件。在下一节中，我们将探讨支持 AV 系统开发的 AWS 服务。

支持 AV 系统的 AWS 服务

AV 系统和 ADAS 的开发和测试需要一个具有高度可扩展计算、存储和网络功能的云平台。作为高性能计算应用，这些组件在之前的章节中已有详细阐述。作为回顾，本章仍涉及以下相关主题：

第三章，计算和网络（参见关于架构模式和计算实例的主题）
第四章，数据存储（参见关于 Amazon S3 和 FSx for Lustre 的主题）
第五章，数据分析与预处理（参见关于大规模数据处理的主题）
第六章至第九章（涵盖在云和边缘的分布式训练和部署）

在本节中，我们将突出介绍一些更多服务，包括我们在自动驾驶和 ADAS 开发背景下讨论的服务。一辆单一的自驾驶汽车每天可以生成数 TB 的数据。这些数据被用于以下链接中讨论的自动驾驶开发工作流程（aws.amazon.com/blogs/architecture/field-notes-building-an-autonomous-driving-and-adas-data-lake-on-aws/），并包括以下内容：

数据采集和摄取
数据处理和分析
标记
地图开发
模型和算法开发
模拟
验证和验证
部署和编排

随着数据规模的不断扩展，客户寻求在所有上述活动的中心寻找可扩展的、几乎无限容量的数据存储。例如，Lyft Level 5 管理着来自汽车传感器的PB（PB）存储数据，存储在Amazon S3中。Amazon S3 也是构建自动驾驶领域应用数据湖概念的核心，这将在下一节中讨论。

但客户最初是如何将数据放入 Amazon S3 的 呢？

对于这一点，客户有多种选择。在自动驾驶领域，客户使用Snow系列设备（SnowBall、SnowCone和SnowMobile）将高达 PB 的数据传输到 Amazon S3。拥有本地系统的客户也可以使用Amazon Outposts来临时托管和处理这些数据，并使用与云类似的 API，同时还可以使用Amazon Direct Connect通过专用网络连接安全地将数据传输到 Amazon S3。这里突出的一些用例来自使用 AWS 进行实际自动驾驶开发的公司公开引用（有关更多信息，请参阅参考文献部分）。

客户还可以使用AWS IoT FleetWise，这是一种在撰写本文时仍在预览中的服务，可以轻松地从车辆收集和传输数据到云中，几乎实时。使用 IoT FleetWise，客户首先使用 FleetWise 设计器对车辆传感器进行建模，然后在车辆上运行的兼容边缘设备上安装IoT FleetWise Edge Agent，定义数据模式和条件以收集数据，并将这些数据流式传输到Amazon Timestream或 Amazon S3。

收集的数据可以是原始或处理过的传感器数据、图像、音频、视频、雷达或激光雷达数据。一旦这些数据存储在 Amazon S3 上，就可以在用于下游任务之前进行处理、分析和标记。例如，TuSimple 等几家客户使用 Amazon 弹性计算云（EC2）来完成各种与自动驾驶相关的处理任务。试图优化处理成本并使用如此规模数据的客户广泛使用 EC2 Spot Instances。2020 年，Lyft Level 5 报告称，他们超过 75%的计算车队都在使用 EC2 Spot Instances 以降低运营成本（有关用例的链接，请参阅参考文献部分）。

对于基于图像和视频的预处理工作负载，可以使用几个预训练的机器学习模型，但需要访问基于 GPU 的实例。例如，丰田研究院广泛使用 P3 和 P4 实例来构建高度可扩展和性能优异的云应用。像 Momenta 这样的公司也使用 Amazon EMR 来创建如安全驾驶辅助决策服务之类的分析服务。

对于数据标注（主要是图像、视频和 3D 激光雷达数据），客户使用 AWS 上的Amazon SageMaker Ground Truth，它为这些标注用例提供专门的模板，访问私有、供应商或公共标注工作者池，以及几种辅助标注能力，以加快这些耗时任务并降低成本。

客户还使用管道来编排端到端预处理、训练或后处理工作流程。一个可以帮助创建、管理和大规模运行这些管道的服务是 Amazon Managed Workflows for Apache Airflow或MWAA。MWAA 是 Apache Airflow 的托管编排服务，使得在云中大规模设置和操作端到端数据管道变得非常简单。使用 MWAA 的替代方案包括 AWS 服务，如Step Functions和Amazon SageMaker Pipelines。

模型训练、模拟、模型编译、验证和验证工作流程可以利用Amazon EC2或以下托管服务之一 – Amazon SageMaker、Amazon Elastic Kubernetes Service（EKS）、Amazon Elastic Container Service（ECS）和/或AWS Batch。

在下一节中，我们将讨论 AWS 上自动驾驶开发的一个参考架构，它汇集了许多这些服务。

设计自动驾驶系统架构

在本节中，我们将讨论 AWS 发布的名为自动驾驶数据湖参考架构的参考架构，其链接可在参考文献部分找到。

完整的架构在图 13.3中得到了复制：

图 13.3 – 自动驾驶数据湖参考架构

在本节中，我们将深入探讨该架构的某些部分，以进一步详细讨论。让我们从数据采集开始：

图 13.4展示了汽车可能安装有数据记录器或某些可移除的存储介质，用于存储传感器的数据。可以使用定制硬件或 AWS Outposts 来处理存储在一个或多个行程中的数据。对于接近实时，可以使用AWS IoT core以及Amazon Kinesis Firehose将数据传输到 Amazon S3。客户还可以使用在本章前面提到的 Amazon Direct Connect，以安全快速地将数据传输到 Amazon S3。

图 13.4 – 数据采集 – 步骤 1 和 2

图 13.5 展示了如何使用 Amazon EMR 来过滤传入的原始数据。例如，可以使用自定义 PySpark 代码评估数据质量，并将其丢弃到不同的桶中。

图 13.5 – 初始数据处理 – 步骤 3

图 13.6 展示了 步骤 5 和 步骤 6，其中数据进一步清理和丰富（例如，使用特定位置或天气数据）。鉴于收集到的数据量很大，可以在 Amazon EMR 中使用另一个处理步骤来识别对下游步骤（如机器学习）有趣的场景。

图 13.6 – 数据丰富 – 步骤 5 和 6

图 13.7 展示了如何使用 Amazon MWAA 来编排这些端到端的数据处理工作流程（步骤 4）。在许多中间步骤中生成的数据可以存储在 AWS Glue 数据目录 中，并且这些数据的历史可以存储在 Amazon Neptune 中作为图（步骤 7）。
最后，数据可以预先处理以供 Fargate 任务中的可视化工具使用，AWS AppSync 和 Amazon QuickSight 提供可视化和 KPI 报告功能。

图 13.7 – 工作流程编排、数据目录和可视化工具 – 分别为步骤 4、7 和 10

图 13.8 展示了如何使用 Amazon Fargate 任务从视频中提取图像或图像序列，使用预训练模型或借助 Amazon Rekognition 来模糊和匿名化图像的某些部分（如面部或车牌）。对于自动驾驶系统客户，还可以进行进一步的预标注，其中可以使用开源中可用的预训练模型来识别行人、汽车、卡车、路标等。

这有助于加快标注过程，因为大部分的标注工作只是调整现有的标签，而不是从头创建所有标签（如边界框）。这种高质量的标注数据是创建机器学习驱动的 ADAS 和自动驾驶系统时最重要的步骤，这些系统可能包含多个模型。关于自动驾驶系统中的机器学习的更多细节将在下一节讨论。

图 13.8 – 标注和标注数据上的机器学习 – 步骤 8 和 9

在下一节中，我们将讨论机器学习在自动驾驶系统中的应用和用例。

应用到自动驾驶系统中的机器学习

开发能够安全操作自动驾驶汽车的深度神经网络（DNNs）是一项高度复杂的技术挑战。从业者需要 PB 级的真实世界传感器数据，数百万甚至数百万的虚拟中央处理器（vCPU）小时，以及数千个加速器芯片或图形处理单元（GPU）小时来训练这些 DNNs（也称为模型或算法）。最终目标是确保这些模型可以比人类驾驶员更安全地自主驾驶车辆。

在本节中，我们将讨论在 AWS 上开发与端到端 AV/ADAS 开发工作流程相关的模型所涉及的内容。

模型开发

自动驾驶汽车（AVs）通常通过五个关键过程来运行，每个过程可能涉及机器学习（ML）的不同程度：

定位和地图构建
感知
预测
规划
控制

每个步骤都需要不同的支持数据和基础设施来高效地生成一个或多个功能模型。例如，虽然感知堆栈建立在需要分布式计算基础设施来支持深度学习训练的大型计算机视觉模型之上，但控制步骤消耗了通用 GPU 和针对深度学习优化的、具有大内存的 GPU 卡，在一个在线或离线的强化学习（RL）工作流程中。

在下一节中，我们将探讨基于云的 ML 环境如何利用 AWS 克服一些挑战，以实现自动驾驶汽车（AV）的成功开发。

挑战

在构建基于深度学习（DL）的 AV 模型方面有三个主要挑战：

将 TB 或更多的训练数据输入到运行在大型高性能计算基础设施上的 ML 框架中
弹性扩展计算基础设施，以线性方式扩展到数千个加速器，利用高带宽网络
ML 框架训练的编排

大量的数据也意味着需要大量的资源来进行标注，因此让我们接下来讨论这个挑战。

标注大量数据

车辆传感器和仿真数据包含图像和视频流、来自雷达和激光雷达的点云，以及来自惯性测量传感器、GPS 和车辆控制器区域网络（CAN）总线的时间序列数据。在 8 小时的特定测试驾驶中，AV 可能通过这些传感器收集超过 40 TB 的数据。根据公司规模，测试车队可能从几辆车到近 1000 辆车不等。在这样的规模下，AV 数据湖每年增长 PB 级。总的来说，这些数据按时间索引并存储为用于模型训练的场景或情景。为了构建最终能够驾驶车辆的模型和代理，这些数据需要得到处理和标注。

第一个挑战是在训练过程中尽可能快地将这些标注数据集提供给机器学习（ML）框架，以便它能够处理数据批次。仅在一个特定任务中训练一个模型所需的数据量就可能超过数百 TB，这使得预先获取并将数据加载到内存中变得不可行。机器学习框架和计算硬件加速器的组合决定了从源读取此类数据批次的速度，以适应特定模型任务。

今天，您可以在 Amazon SageMaker Ground Truth 上使用几个内置的标签模板来标注图像、视频和 LiDAR 数据。有关可以使用 AWS 服务预处理和标注高分辨率视频文件的描述，请访问参考文献部分中的链接。特别是对于 LiDAR 用例，您可以使用同时使用多个机载摄像头捕获的 LiDAR 以及图像数据的数据。Amazon SageMaker Ground Truth 可以将包含 3D 点云数据的帧与多达八个摄像头源同步。一旦原始数据清单准备就绪，您就可以使用 SageMaker Ground Truth 进行 3D 目标检测、目标跟踪和 3D 点云的语义分割。与标准的 SageMaker Ground Truth 标注工作一样，您可以使用完全私有的劳动力或受信任的供应商来完成您的标注任务。图 13.9.9 是一个使用 3D 边界框以及三个投影侧视图和对应时间戳的摄像头图像对车辆进行标注的示例：

图 13.9 – Amazon SageMaker Ground Truth 标注作业，用于自动驾驶工作负载的 LiDAR 和摄像头数据

有关使用 Ground Truth 标注 3D 点云数据的更多信息，请参阅参考文献部分中的链接。

使用大量数据进行训练

通常，在自动驾驶车辆（AV）的背景下，深度学习（DL）任务可以与感知（寻找有关环境或障碍物的信息）和定位（以高精度确定你在世界中的位置）相关联。正在开发一些最先进的深度学习模型，用于检测其他车辆、道路、行人、标志和物体，并描述这些二维物体在 3D 世界中的位置。KITTI 基准测试通常用于测试新的算法和针对自动驾驶车辆相关用例的方法，例如语义分割和目标检测。可以在 AWS 开放数据注册表中找到对 KITTI 数据集（以及其他类似的数据集，如奥迪 A2D2 自动驾驶数据集）的访问。

在大型开源数据集上训练大型语义分割和目标检测模型，例如在 Common Objects in Context（COCO）数据集上的 Mask R-CNN，可以在单个多 GPU 实例上实现每秒 60 张图像的吞吐量——大约 35 MB/s。对于更简单的架构，由于训练网络的规模较小，训练吞吐量可以达到每秒数千张图像。这在使用构成更大模型（如 Mask R-CNN）骨干的 ResNet 模型进行图像分类的情况下是正确的。最近，一些模型如 DeepManta 已被用于在车辆姿态估计等其他相关任务上获得高分——这些方法和论文的链接可以在 参考文献 部分找到。

在较低的数据传输速率下，训练作业可以直接从 Amazon S3 获取数据对象。Amazon S3 是 AWS 上自动驾驶汽车开发的基础数据服务，如本博客文章 构建自动驾驶数据湖 中所述（请参阅 参考文献 部分）。

一些数据加载器直接提供对 Amazon S3 的连接，例如 TensorFlow，用于 TFRecord 风格的数据集。然而，这需要优化每个数据文件的大小以及工作进程的数量，以最大化 Amazon S3 的吞吐量，这可能会使数据加载管道复杂且可扩展性降低。当水平扩展数据读取器时，可以直接从 S3 读取以实现数百 GB/s 的总吞吐量，但会在训练过程的 CPU 利用率上做出妥协。本博客 (aws.amazon.com/blogs/machine-learning/optimizing-i-o-for-gpu-performance-tuning-of-deep-learning-training-in-amazon-sagemaker/) 解释了如何优化 I/O 以提高 GPU 性能。Mobileye 在他们的 reinvent 视频中解释了他们在 Amazon SageMaker 上使用 TFRecord 数据集和 Pipe 模式来训练大型 DNN，从而实现了更快的训练和开发时间提高 10 倍，该视频包含在 参考文献 部分。

为了获得更直接的架构，AWS 提供了利用 ML 框架原生支持 POSIX 兼容 文件系统接口的 FSx for Lustre（有关 FSx 和 POSIX 兼容的更多信息，请参阅 参考文献 部分）。FSx for Lustre 是一个高吞吐量、低延迟的分布式文件系统，可以从现有的 S3 数据中配置，使整个数据集作为文件对 DNN 训练工作员可用。这些文件可以使用任何主要的 ML 框架数据读取器进行迭代，例如 PyTorch 数据集或 DataLoader。

FSx for Lustre 可以将其基线聚合带宽扩展到 200 GB/s，用于 1 PB 的训练数据集，每个 TiB 的训练数据有 1.3 GB/s 的突发速度。提供的 FSx for Lustre 部署越大，聚合带宽就越高，从而实现 PB 级网络布线。FSx for Lustre 使用来自自动驾驶数据湖的数据子集进行初始化，并在训练过程中生成和记录模型工件或数据转换时，使用数据存储库任务进行同步。关于 Amazon ML 解决方案实验室如何帮助现代汽车使用 SageMaker 的分布式训练库和 FSx for Lustre，以 10 倍的速度仅用 5 倍的实例数量训练模型的真实世界示例，请参阅参考文献部分的使用案例链接。

需要一个 PB 级数据存储库的需求也来自于需要扩展处理这些数据的计算工作者的数量。以每秒 60 张图片的速度，单个工作者需要超过 6.5 小时才能在COCO数据集的 118,000 张图片上完成训练，考虑到需要十二个 epoch 才能达到合理的准确率。在每次训练迭代中扩展图片数量对于实现合理的训练时间至关重要。考虑到基于深度学习的模型构建的实验性和迭代性，需要多次训练运行才能构建单个模型。大规模训练通常意味着运行训练实验的高成本。Amazon SageMaker 为训练和部署都提供了节省成本的功能。

Lyft Level 5 的 ML 系统负责人 Alex Bain 表示：“通过使用 Amazon SageMaker 分布式训练，我们将模型训练时间从几天缩短到几个小时。通过在 AWS 上运行我们的机器学习工作负载，我们简化了我们的开发周期并降低了成本，最终加速了我们将自动驾驶能力交付给客户的使命。”

想了解更多关于成本节约的使用案例，请访问以下博客文章：aws.amazon.com/blogs/aws/amazon-sagemaker-leads-way-in-machine-learning/。

Amazon SageMaker 提供了连接到存储数据的常见文件系统的连接，例如 Amazon S3、EFS 和 FSx for Lustre。当运行长时间的训练作业时，选择合适的存储服务可以加快整体训练时间。如果训练数据已经在 EFS 中，通常会在 EFS 上继续预处理数据，并通过将 SageMaker 指向 EFS 来训练模型。当数据在 Amazon S3 中时，客户可以选择直接从 S3 使用这些数据，以利用 SageMaker 上的功能，如快速文件模式、管道模式、数据洗牌或通过 S3 键进行分片以进行分布式训练（有关这些模式的更多信息请参阅参考部分）。客户还可以使用 FSx for Lustre，因为它会自动使数据可供 SageMaker 训练实例使用，并避免任何重复的数据复制。当多个 epoch 使用略微不同的数据子集，这些子集适合实例内存，或者在分布式训练的情况下，FSx for Lustre 通过挂载一个数据可供训练代码访问的卷，提供了对数据集的极快和一致访问。

规模化

使用分布式训练策略时，集群内的许多计算节点读取数据批次，对它们进行训练，并在训练过程中同步模型参数。这些集群的计算单位不是单个计算实例，有时称为节点，而是单个 GPU。这是因为深度神经网络（DNNs）需要硬件加速进行训练。因此，分布式发生在多 GPU 计算实例内部和之间。

亚马逊的 EC2 服务提供了云中最广泛的计算平台，拥有 17 种不同的计算实例系列。每个系列都是为了少数几个特定的工作负载而设计的，并包含一定比例的 vCPU、GPU（对于某些实例）、内存、存储和网络。对于完整的端到端 AV 开发，公司主要依赖于 C、M、R、G 和 P 实例系列。

对于机器学习模型的训练，公司利用深度学习亚马逊机器镜像（DLAMI）在P 系列中启动基于 NVIDIA GPU 的 EC2 实例。每个 EC2 P 系列实例代都集成了最新的 NVIDIA 技术，包括 p2 实例（Tesla K80）和 p3 实例（Volta V100），以及最近发布的 p4d（配备 A100 GPU）。

AWS 和 NVIDIA 持续合作，以实现数据并行和模型并行训练的最先进模型训练时间（参见参考文献部分的博客链接）。SageMaker 分布式训练包括用于分布式数据并行和模型并行训练模式的库。这些用于数据和模型并行训练的库扩展了 SageMaker 的训练能力，因此您可以通过对训练脚本进行少量代码更改来训练大规模模型。对于对此主题感兴趣的读者，AWS 深度引擎团队以下视频介绍了 AWS 库，该库对数据和模型并行训练都很有用：youtu.be/nz1EwsS5OiA。

在单个 GPU 级别上，优化内存消耗有助于提高吞吐量。对于可以批处理的数据进行模型训练，这意味着在 GPU 内存耗尽之前，每轮迭代可以处理更多的图像。因此，GPU 内存越高，可实现的训练吞吐量就越大，这有利于使用大内存 GPU 节点。

在多个 GPU 之间，实例内部和实例之间的快速通信使得在训练过程中梯度同步更快。因此，网络是增强每个迭代步骤速度的可扩展性的关键方面。此类基础设施类似于紧密耦合的高性能计算（HPC）基础设施。

AWS 提供支持云上 HPC 和加速计算的 EC2 实例。AWS 已经展示了 Mask R-CNN 等模型的最快训练时间，以及使用 EC2 p3dn.24xlarge 实例的大规模 GPU 实例的近线性可扩展性。该实例具有 8 个 NVIDIA V100 GPU，每个 GPU 有 32 GB 的内存，并且可以利用AWS 弹性网络适配器（EFA）网络接口。EFA 是一个定制的操作系统旁路硬件接口，它增强了实例间通信的性能，每张卡达到 100 千兆比特每秒的带宽，并且与 ML 应用中使用的通信库（如 MPI 和NVIDIA 集体通信库（NCCL））原生集成。

AWS 推出了最新一代（2020 年）的 NVIDIA GPU 硬件通用可用性（GA）与 EC2 p4d 实例。该实例将云中的机器学习训练提升到了新的水平，包括 8 个配备 40 GB 内存的 NVIDIA A100 GPU 以及改进的网络堆栈。p4d 实例不再只有一个网络接口卡，而是拥有 4 个 EFA 卡，总带宽达到每秒 400 Gbps。在实例内部，p4d 系列还通过 NVlink 网格拓扑结构增加了 GPU 到 GPU 的通信带宽，适用于使用 NCCL 的机器学习框架。新的 p4d 实例设计相比p3dn.24xlarge在主干模型上的训练吞吐量提高了高达 3.8 倍，这对于在自动驾驶车辆开发过程中的数据标注阶段使用的计算机视觉任务，如语义分割，至关重要。有关 p4d 设计和基准测试结果的更多信息，请参阅这篇深度分析博客。

在 2020 年 12 月的 AWS re:Invent 大会上，AWS 宣布了计划使 Intel Habana Gaudi 加速器和自建的训练芯片可用，这些芯片将提供比云中任何计算实例更多的万亿次浮点运算（TFLOPS）。2020 年，AWS 与 NVIDIA 合作，将 Mask R-CNN 在云上的训练时间缩短到 PyTorch 上的 6 分钟 45 秒和 TensorFlow 上的 6 分钟 12 秒（见参考文献部分链接）。有关在 Amazon SageMaker 上使用最小代码更改进行数据并行和模型并行训练的更多信息，请参阅参考文献部分链接的 SageMaker 分布式训练文档。

编排

训练自动驾驶深度神经网络（DNN）的最终挑战是在大规模上管理和编排紧密耦合的高性能计算（HPC）基础设施。AWS 提供了一套服务解决方案，您可以利用这些服务构建和管理大规模的自动驾驶 DNN 训练集群，包括 Amazon EKS、Amazon ECS、AWS Batch 和 AWS Parallel Cluster 等工具。这些主题在前面的章节中已经详细讨论过，此处不再重复。

基础设施管理挑战还包括在整个模型开发过程中集成 AV 堆栈的上游和下游任务的能力。例如，感知模型堆栈的验证可能包括在线驾驶模拟。当将模拟环境集成到模型构建部署中时，分布式计算的要求从紧密耦合的高性能计算转变为高度并行化的、尴尬的并行批处理模拟和客户端-服务器架构。有效地集成服务对于将自动驾驶系统开发从研究练习转变为可扩展、生产就绪的管道变得至关重要。

这些选项为您提供了灵活性，可以帮助您以最快的速度和最稳健的基础设施构建一个可扩展且多样化的机器学习平台，供您的数据科学家团队使用。无论您是使用像 Amazon SageMaker 这样的托管机器学习平台，还是在 Kubernetes 上管理自己的平台，针对自动驾驶车辆（AV）的机器学习部署和编排必须具备以下特点：

持续训练和再训练功能
持续部署
持续监控

关于 AWS 上 MLOps 的更多信息，请参阅aws.amazon.com/sagemaker/mlops/。

对于自动驾驶车辆（AV）而言，以下是一个典型的跨越几周的机器学习工作流程示例：

新或更新的数据集。
数据集整理和场景选择。
预标签和数据整理，其中使用预训练模型为人工标注者提供粗略质量标签的数据，以及在某些情况下从图像和视频数据集中隐藏敏感信息。
标签和主动学习（更多信息请参阅aws.amazon.com/sagemaker/data-labeling/)。
为各种任务进行分布式训练（参见第五章，数据分析）。
模型测试：
- 软件在环测试
- 硬件在环测试
- 路上测试
数据集收集，并返回到步骤 1。

关于这些步骤的更多信息，您可能对阅读 AWS 的实际客户 Aurora 如何使用他们的 Aurora Driver 平台实现自动驾驶功能感兴趣，请参阅www.cnet.com/roadshow/news/aurora-drive-aws-autonomous-vehicle-development/和www.youtube.com/watch?v=WAELZY_TJ04。

第六章，机器学习模型的分布式训练，讨论了分布式训练，第八章，优化和管理边缘部署的机器学习模型，讨论了边缘模型部署；这两者都与之前步骤（步骤 5-9）中列出的主题非常相关。在模型测试中，可以使用 AWS 上的工具进行软件在环测试，这将在下一节中通过一个您可以跟随的动手示例进行讨论。

软件在环（SITL）模拟

在本节中，我们将讨论一种针对自动驾驶车辆客户非常有用的特定类型的软件在环（SITL）测试。请注意，这并不是全球自动驾驶车辆客户正在运行的唯一类型的模拟。一些可能涉及感知任务、规划或地图制作任务，以及在进行硬件在环（HITL）或路上测试之前，进行端到端软件任务。

在本节中，我们将介绍如何设置一个高保真驾驶环境模拟，甚至可以在模拟环境中测试一些 AV 的 DL 模型！为此，您必须遵循两个高级步骤：

创建一个包含您的模拟环境的容器。
使用 RoboMaker 运行您的模拟。

设置完成后，您可以交互式地与您的模拟进行工作，将环境作为 RL 循环的一部分使用，甚至为未来的 ML 实验生成合成数据。

在我们介绍步骤之前，这里有一些基础知识：

什么是 AWS RoboMaker？ RoboMaker是一个基于云的模拟服务，您可以在其中运行模拟而无需管理任何基础设施。更多信息可以在aws.amazon.com/robomaker/找到。RoboMaker 为以下要点中讨论的高保真模拟器提供基于 GPU 的计算。
针对 AV 和制造相关的模拟，RoboMaker 允许您使用模拟器，例如 CARLA（我们将在本节中使用），AirSim，Aslan，Summit，DeepDrive 或Ignition，Drake 或 NVIDIA Isaac Sim，甚至您使用高保真渲染引擎（如 Unity 或 Unreal Engine）创建的定制模拟。这些模拟器和工具的链接可以在参考文献部分找到。
CARLA是一个开源项目，常用于 AV 研究中模拟环境中的车辆，并测试 AV 的 DL 或 RL 模型。CARLA 提供了一个 API，允许用户控制模拟的所有方面，如驾驶、环境、交通和行人，并允许用户在车辆上配置传感器，如激光雷达、摄像头和 GPS。

太好了，现在让我们开始运行 CARLA 在 RoboMaker 上的步骤！

第 1 步 - 构建并将 CARLA 容器推送到 Amazon ECR

要构建我们的定制模拟容器，我们需要两个文件：

一个 Dockerfile
一个 shell 脚本，用于构建并将客户的 Docker 容器推送到 ECR（您也可以使用自己的管道来完成此步骤）

在这里，我们将在 SageMaker 笔记本实例上构建容器，但您也可以使用来自本地笔记本电脑或 EC2 实例的相同脚本，前提是您已设置正确的权限。为了演示这一步骤，我们假设您已经熟悉 SageMaker 笔记本。

下面是查看 CARLA Dockerfile 时的样子。writefile命令将以下代码写入一个名为Dockerfile的新文件中：

%%writefile Dockerfile
FROM carlasim/carla:0.9.11
USER root
# see https://github.com/NVIDIA/nvidia-docker/issues/1632
RUN rm /etc/apt/sources.list.d/cuda.list
RUN rm /etc/apt/sources.list.d/nvidia-ml.list
# install dependencies
RUN apt update && \
      apt install -y python3-pip \
      libjpeg-dev \
      libtiff5-dev \
      libomp-dev \
      fontconfig
# fix ALSA errors
RUN echo pcm.!default { type plug slave.pcm "null" } >> /etc/asound.conf
# install NICE DCV (for RoboMaker)
RUN apt update -y && apt upgrade -y && apt install -y wget pgp
RUN wget https://d1uj6qtbmh3dt5.cloudfront.net/NICE-GPG-KEY
RUN gpg --import NICE-GPG-KEY
RUN wget https://d1uj6qtbmh3dt5.cloudfront.net/2021.1/Servers/nice-dcv-2021.1-10598-ubuntu1804-x86_64.tgz
RUN tar -xvzf nice-dcv-2021.1-10598-ubuntu1804-x86_64.tgz
RUN apt update && apt install -y ./nice-dcv-2021.1-10598-ubuntu1804-x86_64/nice-dcv-gl_2021.1.937-1_amd64.ubuntu1804.deb \
                                 ./nice-dcv-2021.1-10598-ubuntu1804-x86_64/nice-dcv-gltest_2021.1.275-1_amd64.ubuntu1804.deb
# install opengl
RUN apt update && apt install -y libglfw3 libglfw3-dev
# install xterm
RUN apt update && apt install -y xterm
# run as user carla
USER carla
# install example dependencies
RUN python3 -m pip install -U pip
RUN cd ~/PythonAPI/examples && python3 -m pip install -r requirements.txt
# set path to carla python API
ENV PYTHONPATH=/home/carla/PythonAPI/carla/dist/carla-0.9.11-py3.7-linux-x86_64.egg
ENTRYPOINT ["/bin/bash", "-c"]

如您所见，我们首先使用 CARLA 基础镜像并安装一些额外的依赖项：

FROM carlasim/carla:0.9.11

第二个必需的文件是一个构建并推送容器的脚本。首先，我们定义脚本的参数（容器名称）和一些输入，例如区域、账户以及要构建的 Docker 容器的全名：

%%sh
# The name of our algorithm
algorithm_name=$1
account=$(aws sts get-caller-identity --query Account --output text)
# Get the region defined in the current configuration (default to us-west-2 if none defined)
region=$(aws configure get region)
fullname="${account}.dkr.ecr.${region}.amazonaws.com/${algorithm_name}:latest"

然后，我们创建仓库并登录：

# If the repository doesn't exist in ECR, create it.
aws ecr describe-repositories --repository-names "${algorithm_name}" > /dev/null 2>&1
if [ $? -ne 0 ]
then
    aws ecr create-repository --repository-name "${algorithm_name}" > /dev/null
fi
# Get the login command from ECR and execute it directly
aws ecr get-login-password --region ${region}|docker login --username AWS --password-stdin ${fullname}

最后，我们将构建并将容器推送到 ECR：

# Build the docker image locally with the image name and then push it to ECR
# with the full name.
docker build  -t ${algorithm_name} .
docker tag ${algorithm_name} ${fullname}
docker push ${fullname}
echo ${fullname}

此 shell 脚本接受您的容器名称作为参数，根据本地的 Dockerfile 构建容器，并将容器推送到 ECR 中的存储库。一旦您在笔记本实例或安装了 Docker 的任何地方有了这两个脚本，您可以运行以下命令：

./build_and_push.sh carlasim

这将输出您刚刚构建的容器的位置，类似于以下内容：

<account_number>.dkr.ecr.<region>.amazonaws.com/carlasim:latest

复制此输出，因为您在步骤 2 – 在 RoboMaker 上配置和运行 CARLA时需要它。

步骤 2 – 在 RoboMaker 上配置和运行 CARLA

要在 RoboMaker 上配置和运行 CARLA 仿真，请按照以下步骤操作：

导航到 AWS 上的AWS RoboMaker控制台 – aws.amazon.com/robomaker/（如果需要，请登录您的 AWS 账户）。
接下来，查找carsimrole：

图 13.10 – 在 AWS RoboMaker 上创建仿真作业

在同一屏幕上，滚动到计算选项，并确保您选择了 CPU 和 GPU，滑块对应于s3://carlasim-bucket/output；确保您浏览到的存储桶是您有权访问的，而不是本例中显示的存储桶：

图 13.11 – 配置仿真作业的计算选项和输出位置

在指定机器人应用页面，为机器人应用选择无（见图图 13.12*）：

图 13.12 – 为机器人应用选择“无”

转到指定仿真应用页面，如图图 13.13*所示：

图 13.13 – 创建新的仿真应用

选择创建新应用，并添加从步骤 1中复制的 ECR 仓库链接。如果您已经有一个仿真应用，您可以从下拉菜单中选择它，如图图 13.14*所示：

图 13.14 – 从下拉菜单中选择配置仿真应用

滚动到仿真应用配置部分，输入以下内容作为您的启动命令，如图图 13.15*所示，并记得勾选运行带有流会话的选项：
```
./CarlaUE4.sh -opengl
```

图 13.15 – 在仿真应用配置部分输入启动命令

在仿真应用工具部分，创建两个终端，选项如图图 13.16*所示：

图 13.16 – 添加两个自定义工具以访问终端

最后，点击下一步进入摘要屏幕，然后点击创建。创建您的模拟环境的过程将需要几分钟。一旦创建完成，您应该会看到您的模拟作业已创建，如图图 13**.17所示：

图 13.17 – 等待创建模拟作业

一旦模拟创建完成，并且状态字段显示为运行中，点击模拟应用程序部分中的连接按钮，如图图 13**.18所示。您还可以访问终端来运行脚本或监控模拟环境。

图 13.18 – 连接到主模拟应用程序或创建的终端

点击PythonAPI文件夹，如图图 13**.19所示。

图 13.19 – 模拟作业内的 CARLA Python 示例

访问入门指南以了解 Python API 以及包含的示例（carla.readthedocs.io/en/0.9.2/getting_started/)。图 13**.20到图 13**.22提供了示例。

图 13.20展示了一个示例应用，您可以在 CARLA 模拟中手动驾驶特斯拉赛博卡车，与其他 264 辆车一起：

图 13.20 – 在 CARLA 模拟中手动驾驶特斯拉赛博卡车

图 13.21展示了一个示例应用，它通过我们创建的一个终端应用程序使用 Python 程序生成交通：

图 13.21 – 使用 Python 代码在 CARLA 模拟世界中生成交通

图 13.22展示了一个模拟应用程序，它模拟了模拟中车辆周围的激光雷达数据：

图 13.22 – 模拟汽车周围的激光雷达数据

作为下一步，阅读如何在教程中了解如何使用 RL 模型来控制您的汽车以用于自动驾驶用例：carla.readthedocs.io/en/latest/tuto_G_rllib_integration/

让我们总结一下本章到目前为止所学到的所有内容。

摘要

在本章中，我们从高层次讨论了 AV 和 ADAS 系统，并提供了在 AWS 上构建这些系统的一些参考架构。我们还讨论了实践者在云中训练与 AV 相关的机器学习模型时面临的三个主要挑战：向运行在大型、高性能计算基础设施上的机器学习框架提供 TB 或更多的训练数据，弹性地线性扩展计算基础设施以利用高带宽网络，以及编排机器学习框架的训练。

最后，我们向您展示了如何利用 AWS 上的工具运行 SITL 模拟来测试您的机器学习模型。

在下一章中，我们将专注于在 AWS 上解决数值优化问题。

参考文献

如需了解本章讨论的主题的更多信息，请访问以下链接：

*AWS 上自动驾驶和 ADAS 开发第一部分：实现 Scale: aws.amazon.com/blogs/industries/autonomous-vehicle-and-adas-development-on-aws-part-1-achieving-scale/
在 AWS 上构建自动驾驶和 ADAS 数据湖: aws.amazon.com/blogs/architecture/field-notes-building-an-autonomous-driving-and-adas-data-lake-on-aws/
在 AWS 上为自动驾驶开发实现硬件在环测试: aws.amazon.com/blogs/architecture/field-notes-implementing-hardware-in-the-loop-for-autonomous-driving-development-on-aws/
*高级驾驶辅助系统（ADAS）: www.gartner.com/en/information-technology/glossary/advanced-driver-assistance-systems-adass
CARLA 文档: carla.readthedocs.io/en/0.9.2/getting_started/
使用 Amazon Web Services 进行高度自动化和自动驾驶车辆开发: pages.awscloud.com/rs/112-TZM-766/images/Autonomous_Vehicle_Development_with_AWS.pdf
AWS IoT FleetWise: aws.amazon.com/iot-fleetwise/
Lyft 使用 Amazon EC2 Spot 实例增加模拟容量，降低成本: aws.amazon.com/solutions/case-studies/Lyft-level-5-spot/
自动驾驶数据湖参考 架构: d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/autonomous-driving-data-lake-ra.pdf?did=wp_card&trk=wp_card
自动化自动驾驶车辆 开发 的数据摄取和标注: aws.amazon.com/blogs/architecture/field-notes-automating-data-ingestion-and-labeling-for-autonomous-vehicle-development/
使用真实标签标注 3D 点 云: docs.aws.amazon.com/sagemaker/latest/dg/sms-point-cloud.html
Mask RCNN 论文: arxiv.org/abs/1703.06870
COCO 数据集: cocodataset.org
KITTI 数据集: registry.opendata.aws/kitti/ 和 www.cvlibs.net/datasets/kitti/
A2D2 数据集: registry.opendata.aws/aev-a2d2/
ResNet: arxiv.org/abs/1512.03385
DeepManta: arxiv.org/abs/1703.07570
在 KITTI 汽车上进行车辆姿态估计 困难: paperswithcode.com/sota/vehicle-pose-estimation-on-kitti-cars-hard.
在 AWS 上构建自动驾驶和 ADAS 数据湖: aws.amazon.com/blogs/architecture/field-notes-building-an-autonomous-driving-and-adas-data-lake-on-aws/
TFRecord 数据集: www.tensorflow.org/api_docs/python/tf/data/TFRecordDataset
为 Amazon S3 设计性能模式: docs.aws.amazon.com/AmazonS3/latest/userguide/optimizing-performance-design-patterns.html
将我们的机器学习迁移到云端激发 创新: www.mobileye.com/blog/moving-our-machine-learning-to-the-cloud-inspired-innovation/
Lustre 用户 指南: docs.aws.amazon.com/fsx/latest/LustreGuide/what-is.html
Pytorch DataLoader: pytorch.org/docs/stable/data.html
将更改导出到数据 仓库：docs.aws.amazon.com/fsx/latest/LustreGuide/export-changed-data-meta-dra.html
现代汽车公司使用 Amazon SageMaker 减少自动驾驶模型训练时间：aws.amazon.com/de/blogs/machine-learning/hyundai-reduces-training-time-for-autonomous-driving-models-using-amazon-sagemaker/
访问训练 数据：docs.aws.amazon.com/sagemaker/latest/dg/model-access-training-data.html
Amazon EC2 P4 实例：aws.amazon.com/ec2/instance-types/p4/
AWS 和 NVIDIA 实现了 Mask R-CNN 和 T5-3B 的最快训练时间：aws.amazon.com/blogs/machine-learning/aws-and-nvidia-achieve-the-fastest-training-times-for-mask-r-cnn-and-t5-3b/
NVLink 和 NVSwitch：www.nvidia.com/en-us/data-center/nvlink/
NVIDIA 集成通信库（NCCL）：developer.nvidia.com/nccl
AWS re:Invent：reinvent.awsevents.com/
Amazon EC2 DL1 实例：aws.amazon.com/ec2/instance-types/habana-gaudi/
分布式训练 库：aws.amazon.com/sagemaker/distributed-training/
CARLA：carla.org/
AirSim：github.com/microsoft/AirSim
阿斯兰项目：github.com/project-aslan/Aslan
SUMMIT 模拟器：github.com/AdaCompNUS/summit
Deepdrive：github.com/deepdrive/deepdrive
Gazebo：gazebosim.org/home
Drake：drake.mit.edu/
NVIDIA Isaac 模拟器：developer.nvidia.com/isaac-sim
Unity：unity.com/
虚幻引擎：www.unrealengine.com/

第十四章：数值优化

在我们的日常生活中，无论是跑腿还是做家务，人的大脑总是在执行某种形式的优化。例如，大脑可能会优化前往单个或多个目的地的路线。它也可以优化我们在杂货店购买物品的成本，或者，例如，按周或按月预算我们的收入和支出。另一个例子是尝试优化睡眠量，以便我们的思维在第二天工作项目时保持清醒。简而言之，我们每天都在优化多个任务和日程，甚至不知道或思考过这一点。同样，自然界也在优化其过程。例如，地球围绕太阳以最佳路径运行，以保持各种引力之间的平衡。

优化在技术产业中也发挥着重要作用。许多大型优化问题由小型和大型企业解决。例如，送快递到我们家的快递员遵循由优化问题确定的路线和时间表，该优化问题在多个约束条件下解决了一个方程（无论是数值还是解析），以得出那个最佳路线。同样，股票交易是另一个例子，其中的行动可以是卖出、持有或购买特定公司的股票，以实现长期或短期收益的最大化。

在本章中，我们将讨论优化的一般概念，同时更多地关注数值优化、其示例、用例，以及其在应用机器学习中的应用。本章将涵盖以下主题：

优化简介
常见的数值优化算法
大规模数值优化问题的示例用例
在 AWS 上使用高性能计算进行数值优化
机器学习和数值优化

优化简介

如本章引言所述，优化是我们日常生活中和各个科学领域解决大量问题的重要工具。优化问题有许多组成部分，我们将在以下小节中讨论。

目标或目标函数

优化的过程始于定义一个目标或目标函数，例如货币收益、路线或路径、时间表、物品等等。选择目标或目标函数在很大程度上取决于问题领域，以及我们试图解决的问题的具体性。除了目标函数外，我们还需要知道我们是最大化还是最小化目标函数。同样，这也取决于具体的问题领域和目标函数。对于一个以成本为目标函数的优化问题，我们的目标很可能是最小化它，而如果我们的目标函数是收入或利润，我们希望最大化它。

对于我们的路由优化示例，一个组织可能专注于解决最大化配送物品数量的问题，而另一个组织可能希望最小化每配送的燃料成本。因此，尽管两个问题的领域相同，但目标不同。很多时候，目标可能相互关联或依赖。例如，在路由优化问题中，配送物品的数量和每配送的燃料成本似乎相互依赖。试图在给定的时间内配送尽可能多的物品也意味着路线需要定义得尽可能短，这意味着车辆将行驶短距离来配送物品，因此每配送的燃料成本将会较低。

变量

任何优化问题的目标函数通常都是几个变量的函数。通过改变这些变量的值，目标函数的值也会改变。例如，对于路由优化问题，一个变量可以是车辆的速度。如果增加车辆速度，车辆完成的配送数量将会增加，从而提高目标函数的值。数值优化问题通过改变这些变量的值来尝试达到优化函数的最优值。从数学上讲，我们可以定义目标函数，它将一组变量 X 映射到实空间：

我们的目标或目的是找到变量 X 的值，以最小化或最大化（取决于问题）我们的目标函数。因此，对于最大化情况，优化问题可以写成如下形式：

对于最小化情况，优化问题可以写成如下形式：

约束

在之前讨论的路由优化问题中，车辆的速度将基于道路允许的最高速度有一个上限。车辆不应超过这个速度限制。这将是对优化目标函数的一个约束。任何优化问题要么有约束（约束优化）要么没有（无约束优化）。通常，大规模数值优化问题有几个约束。在存在约束的情况下，优化问题的目标就变成了在满足所有约束的条件下找到目标函数的最佳值。以下定义了一些示例约束：

线性约束：变量和大于或等于零，并且它们的和小于 100：

非线性约束：变量的平方大于：

现实世界中的大规模数值优化问题通常既有线性约束也有非线性约束。

建模优化问题

在任何优化问题中，最困难且最重要的任务之一是制定或建模问题本身。这个过程包括识别变量、约束条件和目标函数。了解问题域以及对我们试图解决的商业问题的良好理解对于制定良好的优化问题至关重要。一个非常简单的公式不会帮助我们获得好的结果，而一个过于复杂的公式可能会导致我们无法找到解决方案或得到一个不良的解决方案，即使是在现代机器上，也可能需要非常长的时间来数值求解问题。

优化算法

在制定问题之后，下一步是选择一个优化算法，然后使用软件工具在包含我们的变量和约束的数据上运行它。没有一种算法可以解决所有的优化问题。选择正确的算法是在合理的时间内获得良好解决方案的重要因素。同样，也有几个开源和商业工具实现了优化算法。根据我们的预算和可用资源，我们应该选择合适的软件工具来解决优化问题。一旦算法执行完毕并且我们得到了结果，下一步是确保所有约束条件以及最优性条件都得到满足。如果我们得到的不是一个最优解，我们还可以对解进行敏感性分析，以改进它。

局部和全局最优解

我们优化问题试图解决的目标函数通常具有多个最优值。例如，如果我们的优化问题是最小化问题，并且我们的目标函数是凸函数，那么它将只有一个最小值，称为全局最小值，可以使用基于微积分的方法或如梯度下降、爬山法等已知算法找到。

图 14.1 展示了一元凸目标函数的全局最小值的情况，而 图 14.2 展示了两个变量的凸目标函数：

图 14.1 – 一元凸目标函数的全局最小值

图 14.2 – 两个变量的凸目标函数的全局最小值

我们在日常生活中遇到并处理的许多优化问题都具有非凸目标函数。这些目标函数有多个最优值，称为局部最优解。图 14.3 和 图 14.4 展示了具有一个变量的目标函数的示例，这些函数具有多个局部最小值：

图 14.3 – 具有多个局部最小值的目标函数

图 14.4 – 具有多个局部最小值的目标函数

图 14.5 和 图 14.6 展示了具有两个变量的目标函数的示例，这些函数具有多个局部最小值：

图 14.5 – 显示多个局部最小值的非凸目标函数

图 14.6 – 非凸目标函数的另一个示例，显示多个局部最小值

对于具有非凸目标函数的优化问题，找到全局最小值并不容易。无论我们使用哪种算法，我们很可能会得到一个局部最小值作为解。然而，有一些算法通过迭代过程来找到良好的局部最小值。随机重启爬山法和模拟退火法就是这样的算法。这些迭代算法可以在多台机器或处理器上运行——不仅可以在短时间内找到良好的局部最优解，还可以同时搜索目标函数搜索空间中的多个位置。

在下一节中，我们将了解一些常用的数值优化算法。

常见的数值优化算法

几种数值优化算法已实现于开源和商业销售的优化软件工具中。其中许多算法基于启发式搜索，这是一种与经典方法相比快速解决问题的技术。基于启发式的算法试图找到一个近似解，因为精确解非常难以找到。基于启发式方法提供的解被认为足够好以解决问题；然而，这通常不是最佳解。在本节中，我们将简要讨论这些算法中的一些。有关这些算法及其数学公式的详细讨论，您可以参考本章“进一步阅读”部分中引用的文章和文本。

随机重启爬山法

在爬山法中，我们从一点开始，，并在的邻域内搜索。如果在的邻域内任何方向的目标函数值增加，我们就向增加的方向移动。当目标函数的值在任意方向上不再增加时，我们停止。这是相对于我们的起点而言的目标函数的局部最优值。这种方法也称为最速上升爬山法。算法非常简单：

图 14.7显示了爬山到局部最大值的示例：

图 14.7 – 目标函数中爬山到局部最优的示例

对于最小化问题的情况，算法在目标函数中搜索一个山谷（或局部最小值）。请注意，图14.7中找到的最优值是一个局部最优值，它取决于我们从哪里开始搜索。

随机重启爬山法是爬山法的扩展，在该方法中，在找到一个最优值后，算法在变量空间的不同位置重新开始。这通常会导致达到不同的最优值，如图14.8所示：

图 14.8 – 从两个不同的变量值开始随机重启爬山，然后使用爬山法到达附近的最佳值

即使算法在图 14.8中达到了全局最优值，但这并不总是如此。然而，如果我们多次运行随机重启爬山法，最终得到的局部最优值可能会比只尝试爬山一次更好。由于随机重启爬山法每次都从变量随机选择不同的值开始，因此每个迭代可以在不同的处理器和线程上运行，以加快算法的速度。

模拟退火

在随机重启动爬山法中，我们只向一个方向移动——即向局部最大值（或最小值，取决于问题类型）的方向。这意味着算法只利用信息，而不探索其邻近区域之外。由于完全不探索，算法有很大机会陷入局部最优值并停留在那里。在 模拟退火 中，算法也会探索。它并不总是试图改进当前的目标函数值（向局部最优方向移动），但它有时也会向目标函数值变差的方向移动（与局部最优方向相反）。模拟退火算法的描述如下。

对于有限的迭代次数，执行以下操作：

在当前点的邻域中采样新点
使用接受概率函数给出的概率跳转到新点，该函数为，其中 T 是温度参数，它控制我们跳转的频率，而 f 是目标函数的值：

降低温度，

在前面的表达式中，如果新点的目标函数值大于当前值，则我们跳转到新点。如果新点的目标函数值小于当前值，我们以以下概率跳转到新点：

现在，让我们看看温度对模拟退火的影响。

温度 T 的影响

以下是在模拟退火中温度 T 的影响：

如果 T 很大，指数将接近 1，并且我们会以很高的概率跳转，无论新点的目标函数值如何。这非常类似于当时随机游走。
如果 T 很小，指数将非常小，我们很少跳转到新点。这非常类似于当时爬山法。

在算法运行过程中，T 通常会缓慢降低。当 T 很大时，我们在目标函数空间中跳跃得相当频繁，并且有很大机会最终落在全局最优值或目标函数的良好局部最优值附近。当我们把 T 降低到很小的值时，我们可能非常接近全局最优值，因此我们只在其附近寻找。达到某一点，，的概率如下：

在这里，将概率缩放到 0 到 1 之间。从该表达式可以看出，目标函数的值（在全局最大值的情况下）越大，我们最终停留在该点，的概率就越大。对于最小化任务的情况也是一样的。

图 14.9 展示了模拟退火的概念，以及根据新选点是否改进目标函数，移动到新点的概率：

图 14.9 – 在模拟退火过程中，当选择相邻点作为下一个点时移动到新点的概率

接下来让我们讨论禁忌搜索。

禁忌搜索

禁忌搜索是另一种基于启发式的数值优化方法，在概念上与模拟退火相似。就像模拟退火一样，我们允许移动到一个目标函数值变差解。在禁忌搜索中，进行局部搜索时，不允许回到之前访问过的解。维护一个禁忌列表，其中包含在局部搜索期间不允许探索的规则和解决方案，因此这种方法被称为禁忌搜索。

进化方法

进化算法是基于群体的算法，它使用候选解和一些适应度函数，通过变异和重组来进化/改进解。进化方法在数值优化问题中应用相当广泛，通常在几次迭代内就能找到一个好的局部最优解。遗传算法是进化算法中非常知名且广泛使用的一类。遗传算法在数值优化领域以及机器学习领域有多个应用。它们可以使用二进制以及非二进制表示。遗传算法通常使用两个解，并应用交叉算子来这些解以得到更好的解。

在下一节中，我们将讨论大规模数值优化问题的各种应用和用例。

大规模数值优化问题的示例用例

在上一节中，我们讨论了一些常用的数值优化方法。还有一些我们没有涉及，我们建议您查看参考文献部分，以了解关于多种数值优化方法的优秀文本。一些非常常见的大规模优化问题已在垂直领域实现并解决，例如物流、制造、电信、医疗保健和生命科学、金融服务等。在本节中，我们将讨论一些非常常见的实际大规模数值优化用例和应用。我们将讨论以下用例：

确定销售人员从一个城市到下一个城市最佳路线的旅行销售人员问题
技术人员通过车辆旅行并在地理位置执行各种工作的调度优化问题
汇总线优化，以确定在汇总线上制造的最佳类型和数量的零件

我们将首先讨论一个最古老且最常研究的数值优化问题，称为旅行销售人员问题。

旅行销售人员优化问题

旅行销售人员问题是研究最广泛的组合优化问题之一，首次于 1930 年提出。它属于 NP-hard 问题类别；该问题的决策版本属于 NP-complete 问题类别。在旅行销售人员问题中，我们给定一组城市（或位置），从一个城市出发，每个城市恰好访问一次，然后返回起点城市以找到完成此任务的最短路线。例如，如图图 14.10所示，在美国地图上，我们想要从城市 A 出发，经过所有标记的城市，然后沿着最短的可能路线返回城市 A：

图 14.10 – 显示任意城市 A 至 O 的美国地图

尽管这个问题看起来容易解决，但它是一个 NP-hard 问题。旅行销售人员可以采取多种组合来访问每个城市恰好一次，但通常只有一个解决方案能够以最短的可能路线完成这项任务。旅行销售人员问题可以用几种不同的方式来表述。它可以表述为一个无向加权图，其中城市是图的顶点，连接城市的路线是边，并按城市之间的距离进行加权。然后它可以作为一个以给定顶点开始和结束的最小化问题来解决，每个顶点恰好访问一次。

另一种将旅行推销员问题建模的方法是将其作为一个整数线性规划问题。可以使用几种不同的表述，例如米勒-塔克泽林（Miller-Tucker-Zemlin）表述和丹齐格-富尔克森-约翰逊（Dantzig-Fulkerson-Johnson）表述。当城市数量较少且城市间只有少量路径时，可以在很短的时间内找到精确解。然而，随着城市数量和城市间路径数量的增加，在合理的时间内找到精确解几乎变得不可能。在这种情况下，数值方法试图找到问题的近似解或次优解。图 14.11展示了在图 14.10中所示城市之间找到的一条这样的路线。对于这个问题，可能存在可能的最短路线，但图 14.11中显示的路线是相当合理的，并且很可能是最短的可能路线，或者非常接近最短的可能路线：

图 14.11 – 旅行推销员问题的示例，展示了在地图上从 A 标记到 O 标记的城市之间的一条非常好的路线（可能是可能的最短路线）

旅行推销员问题在各个领域都有多个应用，例如规划、物流、制造、DNA 测序等。还有多种开源和商业销售的软件工具可用于解决旅行推销员问题，以及将其扩展到行业中存在的其他类似问题。旅行推销员问题最常见的实际扩展之一是车辆路径问题。在下一节中，我们将讨论车辆路径问题的一个更复杂的扩展，称为工人调度优化问题。

工人调度优化

车辆路径问题旨在为车队找到最优的路线，以便向客户进行配送。这在物流领域是一个非常常见的问题，例如，像美国邮政服务（United States Postal Service，简称USPS）、联合包裹服务公司（United Parcel Service，简称UPS）、联邦快递公司（FedEx Corporation）等组织，每天都需要向不同地理位置的客户配送多个包裹。这个问题可以使用各种商业目标来表述，例如，在最大化分配给司机/车辆的配送数量和最小化总燃料成本的同时，及时地配送包裹。这些组织通常将这个问题表述为一个优化问题，并在每天（有时一天内多次）解决它，以便向客户配送，同时也在一定约束条件下最大化其盈利性。

与旅行者问题类似，寻找车辆路径问题的解决方案也是 NP 难的。然而，几个数值优化软件工具可以在合理的时间内找到一个非常好的局部最优解。此外，使用高性能和分布式计算，软件可以编写为同时在多个处理器和机器上开始寻找各种解决方案，然后汇总并从找到的各种局部最优解中找到最佳的一个。

通常，车辆路径问题也会通过一些修改来扩展，以解决更加复杂的问题。其中一个例子就是技术人员或工人调度优化问题。在工人调度优化问题中，目标是派遣技术人员或工人到客户位置并完成一些需要时间才能完成的任务。这对于像电力、燃气、互联网、电信等服务提供组织来说是一个非常普遍的问题。这些组织根据工作人员的居住地设有几个工人/技术人员中心或车库。每天到达的工作需要根据他们的日程、技能和技能熟练程度分配给这些工人，因为不是所有的工作都是一样的。所有工人在不同类型的工作中都有相同的技能水平。此外，在所有这些工作中，都有一个需要满足客户满意度的固定时间窗口。此外，不同的工作完成所需的时间不同，还需要考虑前往客户位置所需的时间，这可能会因一天中的时间而异。

图 14.12 展示了一个示例，其中有一个位于中心的工人中心，以及一些在给定一天需要由工人/技术人员服务的客户位置：

图 14.12 – 工作人员/技术人员优化问题的示例

我们现在将正式概述这些约束条件，并讨论一些可以用来解决这个问题的目标函数。

工作人员优化问题的可能客观指标

工作人员优化问题可以根据业务需求具有几个目标函数/指标。我们将在下面列出其中的一些：

最小化总燃料成本：使用这个目标函数，目标是找到一个非平凡解，以最小化任何给定一天所有车辆每项工作的总燃料成本。燃料成本将取决于工人和车辆的数量、工作的数量、工作的位置、到达工作的路线、工作的顺序以及工人的日程安排。通常，最小化燃料成本是完成给定一天最大数量工作的间接结果，因为如果算法可以为特定工人打包大量工作，那么该特定车辆的每项工作的燃料成本就会很低，因此所有工人的每项工作的总燃料成本也会很低。
最大化给定一天完成的工作数量：为了最大化利润并保持客户满意，服务组织需要以尽可能少的工作转移到下一天为前提，最大化给定一天完成的工作数量。这也取决于给定一天可用的工人数量、工人技能以及执行工作所采取的路线。
最大化工人效率：这个目标依赖于最大化给定一天完成的工作数量。这个目标函数的目的是最大化每个工人在给定一天完成的工作数量，这也取决于技术人员的日程安排、技能、竞争力水平、起始位置以及技术人员需要行驶的距离。
复合目标函数：在复合目标函数中，目标是显式优化一组目标函数的组合，例如最大化工人效率、最小化距离或燃料成本。有时，复合目标函数中的各个项也可能相互对立。例如，增加一个可能会减少另一个，依此类推。在这种情况下，我们可能需要与复合函数中包含的不同目标函数相关的惩罚项，并优化由此产生的惩罚项组合。

现在，让我们看看一些对于制定工人调度优化问题可能很重要的约束。

工人调度优化问题的重要约束

以下是一些工人调度优化问题的重要约束。虽然约束涵盖了最常见的约束，但根据具体用例，可能会有额外的约束：

工作数量：给定一天给定工人中心的总工作数量很重要，它会影响工人效率数字、行驶距离以及燃料成本。任何给定一天可以实际完成的工作数量也严重依赖于该天的工作数量。
给定一天可用的工人数量：有多少工人在给定的一天内可以执行工作是另一个重要的约束条件，它对工人效率、旅行距离和燃料成本有重大影响。
工人排班：除了可用的工人数量外，每个工人的排班也是另一个重要的约束条件。一些工人可能从早上 8 点开始上班，而另一些则从 10 点开始，依此类推。同样，每个工人每天可能工作的小时数也可能不同。有些人可能工作 8 小时，而其他人可能工作 6 小时。此外，通常，工人也有休息时间，如午餐和其他定期休息。这些休息时间也可能在不同的时间，这进一步增加了与排班相关的约束，使优化问题更加复杂。
工作类型：通常有几种不同的工作类型。例如，对于电信组织，可能会有新的服务安装或旧服务维修工作。此外，几个服务提供组织提供多种产品和服务。例如，电信组织通常提供互联网、有线电视服务和家庭电话服务。这些不同的工作类型为优化问题增加了另一个维度，进一步复杂化了问题。
工人技能和技能相关能力水平：就像之前提到的不同工作类型一样，不同的工人和技术人员也有不同的技能类型以及在该技能领域的专业水平。再次以相同的电信使用案例为例，一些工人可能专注于安装新的服务，而其他人则专注于维修旧服务。此外，一些技术人员可能是互联网服务安装的专家，而其他人则是电话服务安装的专家。这导致不同工人安装相同服务或调试和维修相同问题所需的时间不同。这也为从商业角度制定问题时增加了一个有趣的困境。

企业可能希望在一个给定的一天内完成尽可能多的工作，这通常通过算法适当地匹配工人技能水平与工作来实现。另一方面，如果企业采取这种方法，那么工人可能无法学习新技能或获得与他们在该领域不是专家的服务和问题相关的实践经验。在制定问题的过程中，应该适当地模拟关于技能水平的这个参数，以实现最佳结果。

工作地点：每个工作在地理位置上的位置对于决定优化解决方案分配给每个工人的路线也很重要。
客户时间窗口：服务提供公司还承诺一个特定的时间窗口，在这个时间窗口内，工人应到达客户/工作地点。这些时间窗口也可能根据工作的类型、可用工人的数量以及地理位置而变化。这些时间窗口对最终目标函数值也有显著影响。例如，在某个特定的一天，客户地点可能有一个承诺的时间窗口，时间为早上 8-10 点进行新的服务安装工作。同时，附近可能还有另一个客户有维修请求。现在，尽管这些工作在物理上非常接近，但由于承诺的时间窗口，组织可能需要派遣多个工人来遵守对客户的承诺时间。因此，许多现代化的组织也在将工人调度问题与调度问题联合制定；当有维修或安装请求时，调度员应在与客户承诺时间窗口时考虑到所有这些约束条件。
工作时长：不同的工作完成所需的时间不同。通常，在工人中心的所有工人中，对于特定的工作都有一个平均时间，而且每个工人完成该工作的时间也是个体差异。所有这些也被建模为优化问题中的约束条件，以获得最佳结果。
最大旅行时间和距离：通常，对于工人一天内可能行驶的总距离或时间也有一个最大限制，以及工人可能从车库中心最远能到达的距离。

除了这些约束条件之外，还可能有其他额外的约束条件（例如，天气：雨、雪、风暴等），具体取决于特定组织正在处理的使用案例。正如我们可以想象的那样，所有这些约束条件使得工人调度优化问题非常复杂。通常，对于任何使用这种方法为其工人分配工作的组织，这个问题每天早上都在多个高性能计算机器上以分布式方式解决。例如，对于相同的地理位置，可以使用随机重启方法进行爬山和其他类似算法，每个重启迭代都在不同的处理器和/或机器上执行。有几款开源和商业化的优化软件可以非常高效地在合理的时间内制定和解决此问题。

图 14**.13 展示了三个工人中心，每个中心有三位工人，他们遵循优化的路线前往工作地点并返回工人中心：

图 14.13 – 示例展示了三个工人中心和总共九名工人，其中三名工人从每个工人中心出发，遵循优化的路线到达工作地点

通过使用数值优化算法来解决这个优化问题，服务公司可以提高工人效率，减少燃料成本，并显著提高客户满意度。接下来，我们将讨论另一个数值优化示例，即如何将物品分配到装配线以最大化给定日期的生产物品数量。

装配线优化

在电子制造等制造业中，通常有多个装配线或传送带，各种物品在这些装配线上被组装成最终产品，如台式/笔记本电脑、手机、平板电脑等。在这些装配线上，人工工人正在手动组装物品。不同的装配线可以组装不同的产品，存在一些重叠。此外，组装产品的工人也具有不同的技能和技能水平，就像工人调度优化问题一样。让我们根据业务用例讨论可用于此问题的各种优化指标。

装配线优化的目标指标

以下目标指标是装配线优化问题中常用的一些：

最大化给定日期生产的物品数量：使用此指标，目标是最大化任何给定日期组装的总物品数量。通常，这也取决于订单数量，以及近期内所需物品的预测。
最小化存储中物品的数量：使用此指标，目标是最小化过多制造并存储在存储中用于未来销售的物品数量。此指标还取决于要制造的物品的预测以及存储容量。

除了这些指标外，还可以根据业务用例和目标使用其他指标。此外，就像工人调度优化问题一样，由多个指标组成的客观指标也可以使用。让我们看看此问题的一些约束条件。

装配线优化问题的约束条件

以下约束对于装配线优化问题很重要：

每天需要组装的不同物品数量。此约束取决于销售预测以及预订单数量。
每天可供工作的工人数量，以及每个工人的日程安排。
各个工人的技能，以及每个工人的技能竞争力水平。
组装各种物品所需的技能。
每条传送带组装不同物品的容量。
工厂和/或仓库的存储容量。
在特定时间段内（如一天、一周或一个月）可以存储的最大物品数量（过剩）。

虽然这些是在制定流水线优化问题时考虑的一些常见约束，但根据具体的业务用例以及各种其他条件和要求，还可能有额外的约束。通过将此问题作为优化问题进行制定，然后在每日、每周、每月或每季度的时间表上解决它，制造公司通常可以提高产量、利润和效率，同时减少浪费和过剩物品的数量。

在本节中，我们讨论了在工业界使用的数值优化的一些应用和用例。在下一节中，我们将讨论 AWS 上可用于解决这些数值优化问题的性能计算选项。

在 AWS 上使用高性能计算进行数值优化

如前几节所述，大多数数值优化问题都是 NP 难的，对于找到合理的解决方案来说计算密集型很高。采用这些算法的软件工具必须在非常复杂的多元目标函数上进行大规模搜索，以寻找全局最优解。由于复杂性、维度数量、非凸性和有时存在于这些目标函数中的不连续性，即使在今天的计算资源下，几乎不可能在有限的时间内找到全局最优解。

然而，对于这些问题的大多数，几个商业和开源软件工具可以在合理的时间内找到一个非常好的解决方案（局部最优解）。这些工具可以在 AWS 提供的基础设施和计算资源上运行。让我们讨论一些常见的商业和开源工具，这些工具可以安装在 AWS 的各种资源上，以解决几乎每个行业领域的数值优化问题。

商业优化求解器

以下是一些在 AWS 计算基础设施上使用最流行和最常用的商业求解器：

IBM ILOG CPLEX 优化工作室（通常称为CPLEX）
Gurobi 优化
FICO Xpress 优化
数学规划 语言（AMPL）

开源优化求解器

除了商业销售的优化求解器工具之外，以下开源优化求解器也可以轻松地在 AWS 计算基础设施上运行：

GNU 线性规划 套件（GLPK）
计算基础设施 研究（COIN-OR）
Pyomo
凸包和非线性 估计 （Couenne）
PuLP
Google OR-Tools
SCIP 优化套件

这些商业和开源软件工具可以使用以下章节中概述的各种不同的架构模式在 AWS 基础设施上运行。

AWS 上的数值优化模式

可以采用各种架构模式在 AWS 资源上运行之前提到的优化软件工具。

图 14.14 展示了 AWS 堆栈中可用于帮助解决数值优化问题的各种工具和资源：

图 14.14 – 可用于解决数值优化问题的各种 AWS 资源和工具

让我们讨论一些使用这些 AWS 资源和工具的架构模式，并看看它们如何帮助解决数值优化问题。

EC2 实例

我们可以在 Amazon EC2 实例上安装并运行这些优化工具，以容器的方式运行。优化软件套件以及所有必需的库可以构建成一个容器，然后利用 EC2 实例，这些实例也可以以分布式方式同时运行多个并行搜索（例如，随机重启爬山法）。通过并行运行这些算法的多个迭代，有更好的机会达到全局最优值或非常好的局部最优值。图 14.15 展示了在 EC2 实例上使用容器运行这些优化工具的架构：

图 14.15 – 示例架构，展示数值优化软件在 Amazon EC2 计算实例上的容器中运行

使用无服务器架构

除了使用 EC2 实例外，我们还可以在 AWS 上以无服务器的方式运行优化软件。图 14.16 中展示了使用无服务器架构的一个示例，其中 AWS Lambda 用于在 AWS Fargate 上启动多个优化任务。这些任务可以并行运行，然后汇总以获得优化问题的最佳解决方案。这些任务也可以是尝试解决同一问题的不同优化包和库，最终使用最佳结果。包含约束和变量的数据可以从 Amazon S3 读取，如图 14.16 所示。在此模式中，Amazon CloudWatch 也用于输出必要的步骤和状态消息：

图 14.16 – 使用 AWS Lambda 和 AWS Fargate 运行各种并行优化任务的示例无服务器架构

使用这种方法而不是 EC2 实例的优势在于成本和可扩展性。我们可以启动所需的任何数量的优化任务，而无需担心管理 EC2 实例。此外，由于我们使用的是无服务器架构，我们只需为优化任务运行的时间付费。例如，对于我们的工作者调度优化问题，相关的工作者和作业数据每天早上都会到达 Amazon S3 存储桶。然后，使用 AWS Lambda，可以在 AWS Fargate 上启动各种优化任务，每个特定工作者中心的任务都试图为该中心中的每个工作者找到最佳路线和调度。

使用 Amazon SageMaker 处理

除了使用专用 EC2 实例和无服务器架构外，我们还可以在 Amazon SageMaker 上使用 SageMaker 处理作业进行数值优化。图 14**.17 展示了这种架构模式的示例，其中包含约束和各种变量的数据存储在 Amazon S3 存储桶中。AWS Lambda 和 AWS Step Function 用于启动一个 SageMaker 处理作业，该作业从 S3 存储桶读取数据，并在一个包含所有必需的包和软件的容器中运行优化任务，这些软件是运行优化作业所需的。这个优化作业在一个短暂的 EC2 实例上运行；一旦作业完成，实例就会被释放，不再产生实例费用。结果在经过 AWS Lambda 函数的一些后处理后被写入 S3 和 Amazon DynamoDB。图 14**.17 还显示了其他一些 AWS 资源，例如用于身份验证和缓存的资源，这些资源可能有必要，也可能没有必要，具体取决于特定的用例：

图 14.17 – 使用 Amazon SageMaker 处理运行数值优化的示例

在本节中，我们探讨了使用 AWS 高性能计算资源和工具解决数值优化问题的几种方法。虽然这些是适用于各种用例的架构模式的良好示例，但根据用例和业务需求，这些模式也可以进行修改和扩展。

在下一节中，我们将探讨数值优化对于解决机器学习问题的重要性。

机器学习和数值优化

到目前为止，我们已经从优化问题的角度讨论了数值优化及其用例。虽然数值优化有几个独立的行业用例和应用，但它也非常常见于多种机器学习算法和用例中。无论是监督学习、无监督学习还是强化学习，我们总是在机器学习算法的核心使用迭代过程解决某种形式的优化问题。

在监督学习中，例如，让我们看看线性回归的例子。在线性回归中，我们最小化一个成本函数，这个成本函数通常由实际目标变量的值与通过模型预测的值之间的均方误差组成。

我们的算法通过迭代算法（如梯度下降）找到成本函数的最小值（如果它是均方误差，则具有全局最小值的凸函数；在大多数其他情况下是非凸的，具有局部最小值）。梯度下降查看成本函数的梯度，然后按梯度方向修改线性回归参数。这样，经过一定次数的迭代后，算法就达到了目标函数的全局或局部最小值。

同样，在逻辑回归中，我们使用由对数项组成的目标函数。这个目标函数再次是凸函数，我们再次使用梯度下降来找到目标函数的最小值。因此，我们再次在问题的核心解决一个数值优化问题，其高级目标是构建一个用于分类问题的机器学习模型。

在神经网络中，包括深度神经网络，我们有几个参数需要找到最优值，以便在输出层最小化某些错误。在深度学习领域，我们通常有非常大的机器学习模型，包含数百万甚至数十亿个权重或参数，尤其是在自然语言处理和计算机视觉问题中。神经网络中的每个神经元或单元都有一些激活函数，它是这些参数的函数之一。为了构建一个拟合数据良好并在测试或新数据上做出良好预测的模型，我们需要找到神经网络参数/权重的最优值。这再次是通过使用梯度下降或其他优化算法来解决由大量参数组成的数值优化问题。

与监督学习类似，数值优化也被用于无监督学习问题中。例如，在诸如 K-means 聚类这样的聚类方法中，我们试图最小化簇中心与簇中相关点之间的距离。同样，在期望最大化（一种软聚类方法）中，我们试图最大化每个数据点由高斯分布生成的可能性，而我们正在尝试找到的是这个分布的均值。

在强化学习中，数值优化也经常被使用。例如，在大多数强化学习方法中，算法的目标是通过行动和奖励最大化某种长期奖励，同时重复模拟场景以学习最大化长期奖励的最佳策略。在深度强化学习中，我们使用神经网络权重来近似策略。这些权重再次是通过使用梯度下降等数值优化算法来学习的。简而言之，无论我们试图解决哪种类型的机器学习问题，都与数值优化有着紧密的联系，并且对于这些机器学习问题中的大多数，我们都在解决某种形式的优化问题以获得机器学习问题的答案。

让我们总结一下本章学到的内容。

摘要

在本章中，我们讨论了数值优化及其应用。我们首先讨论了数值优化的概念及其必要成分。接下来，我们讨论了几种常见的数值优化方法。我们还讨论了几种数值优化的大规模应用和案例。这些案例在学术界和工业界都非常知名，并被多个组织在其业务中实施。此外，我们讨论了如何使用 AWS 高性能计算选项和资源来解决数值优化方法，并讨论了几种实现这一目标的架构模式。

最后，我们简要讨论了各种机器学习算法如何在其核心使用数值优化来构建良好的模型。本章涵盖的主题将帮助您理解和制定数值优化用例，了解数值优化对机器学习的重要性，以及高性能计算如何帮助解决数值优化用例。此外，您应该对可用于解决数值优化问题的工具和软件有所了解。

总体而言，在这本书中，我们讨论了高性能计算的基础知识，随后讨论了高性能计算的数据管理、传输、计算、网络和存储方面。我们还讨论了应用建模及其示例，例如数据分析、预处理、可视化、机器学习模型的分布式训练、模型优化及其部署，以及机器学习模型的扩展。此外，我们探讨了高性能计算的多种应用，如计算流体动力学、基因组学、自动驾驶汽车和数值优化。本文档中介绍的材料将向您介绍所有这些概念，并使您能够进一步探索并解决高性能计算和相关领域中的有趣用例。

进一步阅读

要了解更多关于本章所涉及主题的信息，请查看以下资源：

数值优化交互教程: www.benfrederickson.com/numerical-optimization/
El-Ghazali Talbi. 2009. 元启发式：从设计到实现. Wiley 出版。
关于 NP-hard 和完备性的参考文献：
- 旅行商问题: en.wikipedia.org/wiki/Travelling_salesman_problem
- 车辆路径问题: www.sciencedirect.com/topics/economics-econometrics-and-finance/vehicle-routing-problem
- IBM ILOG CPLEX 优化工作室: www.ibm.com/analytics/cplex-optimizer
- Gurobi 优化: www.gurobi.com
- FICO Xpress 优化: www.fico.com/en/products/fico-xpress-optimization
- AMPL: ampl.com/
- GNU 线性规划工具包: www.gnu.org/software/glpk/
- 运筹学计算基础设施: www.coin-or.org/
- Pyomo: www.pyomo.org/
- 非线性估计的凸包和下凸包: github.com/coin-or/Couenne
- PuLP: pypi.org/project/PuLP/
- Google OR-Tools: developers.google.com/optimization
- SCIP 优化套件: www.scipopt.org/

posted @ 2025-09-03 09:53 绝不原创的飞龙阅读(5) 评论(0) 收藏举报

刷新页面返回顶部

龙哥盟

掠夺·扩张·投机·博弈

AWS-应用机器学习与高性能计算-全-

AWS 应用机器学习与高性能计算（全）

前言

本书面向对象

本书涵盖内容

为了充分利用这本书

下载示例代码文件

下载彩色图像

使用的约定

联系我们

分享您的想法

下载此书的免费 PDF 副本

第一部分：介绍高性能计算

第一章：高性能计算（HPC）基础

我们为什么需要高性能计算（HPC）？

本地高性能计算的局限性

创新障碍

效率降低

错过的机会

可扩展性和弹性有限

在云上运行高性能计算（HPC）的好处

推动创新

使分布式团队之间能够安全协作

提高运营效率

优化性能

优化成本

利用 HPC 推动跨行业创新

生命科学和医疗保健

基因组学

成像

计算化学和基于结构的药物设计

自动驾驶汽车

供应链优化

摘要

进一步阅读

第二章：数据管理和传输

数据管理的重要性

将数据迁移到云中的挑战

如何安全地将大量数据传输到云端

AWS 在线数据传输服务

AWS DataSync

用例

AWS DataSync 的工作原理

从本地到 AWS 存储服务的数据传输

AWS 存储资源之间的数据传输

AWS Transfer Family

用例

AWS Transfer Family 的工作原理

Amazon S3 传输加速

Amazon Kinesis

AWS Snowcone

AWS 离线数据传输服务

从 AWS Snow Family 订购设备的流程

摘要

进一步阅读

第三章：计算和网络

介绍 AWS 计算生态系统

通用型实例

计算优化实例

加速计算实例

GPU

FPGA 实例

内存优化实例

存储优化实例

亚马逊机器镜像（AMIs）

AWS 上的容器

AWS 上的无服务器计算

AWS 上的网络

CIDR 块和路由

HPC 工作负载的联网

选择适合 HPC 工作负载的计算

模式 1 – 独立实例

模式 2 – 使用 AWS ParallelCluster

模式 3 – 使用 AWS Batch

模式 4 – 混合架构

模式 5 – 基于容器的分布式处理

模式 6 – 无服务器架构

HPC 工作负载的最佳实践