边缘上的智能工作负载-二-

边缘上的智能工作负载（二）

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

译者：飞龙

协议：CC BY-NC-SA 4.0

第六章：第六章：在云上处理和消费数据

边缘计算的价值主张是在数据源附近处理数据，并为不同用例中的不同类型的应用提供智能近实时响应。此外，边缘计算减少了需要传输到云中的数据量，从而节省了网络带宽成本。通常，高性能边缘应用程序需要本地计算、本地存储、网络、数据分析以及机器学习能力，以在低延迟下处理高保真数据。尽管 AWS IoT Greengrass 允许你在设备和网关上运行复杂的边缘应用程序，但与云端的强大计算能力相比，它将受到资源限制。因此，对于不同的用例，利用云计算的规模来满足大量复杂数据处理需求是非常常见的。

在上一章中，你学习了关于边缘数据转换策略的不同设计模式。本章将重点解释如何根据从运行 Greengrass 实例的 HBS 中心收集到的数据速度、数据种类和数据量，在云上构建不同的数据工作流。具体来说，你将学习如何将数据持久化到事务性数据存储中，开发 API 驱动访问，并构建无服务器数据仓库以向最终用户提供数据。因此，本章分为以下主题：

• 为物联网工作负载定义大数据

• 领域驱动设计（DDD）概念简介

• 在云上设计数据流模式

• 记住边缘工作负载的数据流反模式

技术要求

本章的技术要求与第二章**，边缘工作负载基础中概述的要求相同。完整的要求数据见该章节。

为物联网工作负载定义大数据

在大数据中的“大”是相对的，因为随着企业数字化和连接生态系统的转型，数据流入在过去二十年里从太字节增长到艾字节，数据量大幅增加。大数据技术的出现使得人们（如社交媒体）和企业（如数字化转型）能够生成、存储和分析大量数据。为了分析如此大量的数据集，需要复杂的计算基础设施，该基础设施可以根据输入数据量和所需结果弹性扩展。大数据工作负载的这一特性，加上云计算的可用性，使得所有规模的公司都能够民主化地采用大数据技术。即使在边缘计算的演变中，云上的大数据处理在物联网工作负载中也发挥着关键作用，因为当数据靠近并与其他数据系统丰富时，数据更有价值。在本章中，我们将学习大数据生态系统如何允许对从边缘收集的大量原始测量或事件进行高级处理和分析，从而使得不同角色能够消费可操作信息。

物联网与大数据生态系统的集成开辟了一系列分析能力，这允许生成额外的业务洞察。以下是一些例子：

• 描述性分析：这种分析类型帮助用户回答“发生了什么以及为什么？”的问题。例如，传统的查询和报告仪表板。

• 预测分析：这种分析形式帮助用户根据历史事件或检测到的异常情况，预测未来某个事件的概率。例如，在银行交易中早期欺诈检测和不同系统的预防性维护。

• 规范性分析：这种分析帮助用户提供具体的（清晰的）建议。它们解决的是“如果发生 x，我应该做什么？”的问题。例如，选举活动接触目标选民或财富管理中的统计建模以最大化回报。

这些流程的结果使得组织能够对新的信息、新兴趋势或隐藏的数据相关性有更高的可见性，以提高效率或产生新的收入来源。在本章中，你将了解对从边缘收集的数据进行描述性和预测性分析的方法。此外，你还将学习如何实现设计模式，如将流式传输到数据湖或云上的事务性数据存储，以及利用 API 驱动的访问，这些都被认为是边缘的反模式。因此，让我们开始学习与物联网工作负载相关的大数据设计方法。

什么是大数据处理？

大数据处理通常按照三个 V 来分类：数据量（例如，太字节、拍字节或更多），数据种类（即结构化、半结构化或非结构化），以及数据速度（即数据产生或消费的速度）。然而，随着越来越多的组织开始采用大数据技术，V 列表中又增加了以下内容：

• 粘度：这强调数据的易用性；例如，可能存在从边缘收集的噪声数据，这些数据不易解析。

• 易变性：这指的是数据变化的频率以及因此数据的有用性持续时间；例如，捕捉家庭中的特定事件可能比其他所有活动更有用。

• 真实性：这指的是数据的可信度，例如，如果从户外摄像头捕获的图像质量差，那么它们不能被信赖用于识别入侵。

对于边缘计算和物联网（IoT），所有六个 V 都相关。以下图表展示了随着物联网和大数据技术的出现而变得可用的数据范围。这要求你考虑根据各自特征以不同方式组织大规模数据：

图 6.1 – 大数据的发展

因此，你已经学习了关于数据建模概念的内容，在第五章“从边缘摄取和流式传输数据”，这是一种基于数据类型和关系组织数据到有意义结构的标准方式，并从中提取价值。然而，收集数据，将其存储在流或持久层中，并快速处理以采取智能行动只是故事的一方面。下一个挑战是如何在整个生命周期中保持数据的高质量，以确保它能够为下游应用持续产生业务价值，而不是不一致或风险。对于物联网工作负载，这一点至关重要，因为设备或网关位于物理世界，有时具有间歇性的连接性，并可能受到不同形式的干扰。这就是领域驱动设计（DDD）方法可以提供帮助的地方。

什么是领域驱动设计？

为了更好地管理数据质量，我们需要学习如何通过内容如数据域或主题领域来组织数据。其中最常见的方法之一是通过 DDD，这是由埃里克·埃文斯（Eric Evans）在 2003 年提出的。在他的书中，埃里克表示“软件的核心是其解决用户领域相关问题的能力。所有其他功能，尽管它们可能很重要，但都支持这一基本目的”。因此，DDD 是一种围绕业务领域的需求、规则和流程的软件开发方法。

DDD 方法包括两个核心概念：有界上下文和通用语言。让我们更深入地探讨每个概念：

• 有界上下文：有界上下文有助于你定义解决方案的逻辑边界。它们可以根据组织的需要，在应用层或业务层实现。然而，核心概念是一个有界上下文应该拥有自己的应用、数据和流程。这允许相关团队在特定领域内清楚地定义他们拥有的组件。这些边界对于管理数据质量和最小化数据孤岛至关重要，因为随着不同的 V 值增长，它们会在组织内部或外部与不同的消费者一起重新分配。例如，使用连接的 HBS 解决方案，HBS 的内部业务功能及其最终消费者可能需要不同的业务能力。这可以包括以下内容：

  • 内部能力（针对组织实体）：

    • 产品工程：利用不同的服务或功能

    • 车队运营：监控车队健康状况

    • 信息安全：监控遵守不同的监管要求，例如 GDPR

    • 更多如 CRM、ERP 和营销

  • 外部能力（针对最终消费者）：

    • 车队遥测：处理如恒温器或 HVAC 设备从设备中近实时读取的数据流

    • 车队监控：捕获车队健康状况信息或关键事件，例如传感器的故障

    • 车队分析：通过其他元数据丰富遥测数据，以考虑不同环境因素（如时间、位置和海拔）进行分析

  以下图表展示了有界上下文的示例：

图 6.2 – 有界上下文

所有这些不同的业务能力都可以定义为有界上下文。因此，现在我们已经确定了业务能力，我们可以在有界上下文中定义技术要求，以实现所需的企业成果。一般规则是，应用、数据或流程应该是内聚的，不应跨越其他上下文的使用。在本章中，我们将主要关注构建外部能力所需的有界上下文，这些能力是由最终消费者使用不同技术实现的。

注意

然而，在现实世界中，在定义一个有界上下文时，可能需要考虑许多额外的因素，例如组织结构、产品所有权等。我们不会深入探讨这些因素，因为它们与这里讨论的主题无关。

• 通用语言：DDD 的第二个概念是通用语言。每个边界上下文都应该有自己的通用语言。属于同一边界上下文的应用程序都应该遵循相同的语言。如果边界上下文发生变化，通用语言也应该是不同的。这允许一个团队开发和管理工作负载的边界上下文，因此与 DevOps 方法相一致。这种运营模式使得一个熟悉通用语言的单一团队能够更快地拥有和解决不同的应用程序或数据依赖关系。在本章的后面部分，您将发现不同的边界上下文（或工作流程）是如何使用多种不同的语言实现的。

  备注

  DDD 模型没有规定如何在应用程序或数据管理中确定边界上下文。因此，建议您从您的用例开始，逆向确定适当的内聚性。

因此，基于这个基础，让我们定义一些在云上管理数据的设计原则 – 其中一些将在本章的剩余部分使用。

使用 DDD 设计数据工作流程的原则是什么？

我们将概述一系列指导原则（即原则），以了解如何使用领域驱动设计（DDD）设计数据工作负载：

• 原则 1：通过领域管理数据所有权 – 使用领域的优势在于数据的质量以及易用性。最了解数据的团队拥有并管理它。因此，数据所有权是分散的，而不是集中的。

• 原则 2：使用边界上下文定义领域 – 领域实现一个边界上下文，反过来，这个上下文又与一个业务能力相联系。

• 原则 3：将一个边界上下文链接到一个或多个应用程序工作负载 – 一个边界上下文可以包括一个或多个应用程序。如果有多个应用程序，所有这些应用程序都应提供相同业务能力的价值。

• 原则 4：在边界上下文中共享通用语言 – 负责在其边界上下文中分发数据的应用程序使用相同的通用语言，以确保不同的术语和数据语义不会冲突。每个边界上下文与一个概念数据模型有一对一的关系。

• 原则 5：保留原始源数据 – 需要保留摄入的原始数据作为集中解决方案中的真相来源。这通常被称为黄金数据集。这将允许不同的边界上下文在发生故障的情况下重复处理数据。

• 原则 6：将数据与元数据关联 – 随着数据在多样性和数量上的增长，任何数据集都应易于发现和分类。这有助于不同下游应用程序的数据重用，并建立数据血缘。

• 原则 7：使用合适的工具做合适的工作 – 根据数据工作流程，如速度层或批量层，持久性和计算工具将不同。

• 原则 8：分层数据存储 – 根据数据的访问模式选择最佳存储层。通过将数据集分布到不同的存储服务中，你可以构建一个成本优化的存储基础设施。

• 原则 9：保护和管理数据管道 – 实施控制以保护和管理所有静态和传输中的数据。需要一个机制来仅允许授权实体可视化、访问、处理和修改数据资产。这有助于我们保护数据机密性和数据安全。

• 原则 10：设计以规模为基础 – 最后但同样重要的是，云的一切都是关于规模经济。因此，利用托管服务弹性扩展并可靠地处理任何数据量。

在本章的剩余部分，我们将深入探讨这些设计原则（如果不是全部）作为我们深入研究不同的设计模式、数据流和动手实验室。

在云上设计数据模式

当数据通过不同的通道（如通过速度层或批量层）安全地从边缘流向云端时，根据数据速度或数据多样性，将数据存储在不同的临时区域或集中位置是一种常见做法。这些数据源作为单一的真实来源，有助于确保各自边界上下文中数据的品质。因此，在本节中，我们将讨论不同的数据存储选项、数据流模式以及云上的反模式。让我们从数据存储开始。

数据存储

正如我们在前面的章节中学到的，由于边缘解决方案在计算资源方面受到限制，根据用例优化应用程序的数量或本地持久化的数据量是很重要的。另一方面，云没有这种限制，因为它几乎拥有无限的资源，以及不同的计算和存储选项。这使得它非常适合大数据应用根据需求增长和收缩。此外，它还提供了轻松访问全球基础设施的便利，以满足不同下游或终端消费者在更靠近他们的地区所需的数据。最后，当数据与其他数据或元数据相结合时，数据更有价值；因此，在最近几年，如数据湖等模式变得非常流行。那么，什么是数据湖呢？

数据湖是一个集中式、安全且耐用的存储平台，允许您摄取、存储结构化和非结构化数据，并根据需要转换原始数据。您可以将数据湖视为在*第五章**，从边缘摄取和流式传输数据中引入的数据池塘概念的超集。由于物联网设备或网关的存储相对较低，只有与边缘操作高度相关的、具有高度价值的数据才能在数据池塘中本地持久化：

图 6.3 – 数据湖架构

数据湖架构的一些基本特性在此进行解释：

• 存储原始数据，并确保数据在最小或无转换的情况下安全存储的中心存储。这是数据的单一事实来源。计算层、存储层、模式、摄取频率和数据质量的选取由数据生产者决定。Amazon S3 通常被选作中心存储，因为它是一个高度可扩展、高度耐用且成本效益高的服务，允许计算层和存储层的解耦。AWS 在 Amazon S3 内提供不同的分层选项，以及一个称为 Amazon Glacier 的全面归档服务。

• 存储特定领域的数据集市或以列式格式（如 Parquet、ORC 或 Avro）转换的数据的持久层，以通过边界上下文实现隔离、提高性能或降低成本。AWS 提供不同的服务，如 AWS Glue 进行数据转换和数据目录，Amazon Athena 或 Amazon Redshift 进行数据仓库和数据集市，以及 Amazon EMR 或 EMR 上的 Spark 进行大数据处理管理。

• 存储从边缘安全摄取的事务数据的持久层。这一层通常被称为操作数据存储（ODS）。AWS 提供不同的服务，可以根据给定的数据结构和访问模式利用这些服务，例如 Amazon DynamoDB、Amazon RDS 和 Amazon Timestream。

您可能想知道数据湖中的数据是如何提供给数据仓库或 ODS 的。这正是数据集成模式发挥关键作用的地方。

数据集成模式

数据集成与互操作性（DII）通过批量、速度和服务层实现。大数据世界中将这些所有层交织在一起的一种常见方法是提取、转换和加载（ETL）或提取、加载和转换（ELT）。我们已经在第五章，从边缘摄取和流式传输数据中详细解释了这些概念，并讨论了它们如何随着时间的推移演变成不同数据流模式，如事件驱动、批量、lambda 和复杂事件处理。因此，我们在此不再重复这些概念。但在下一节中，我们将解释它们如何与云中的数据工作流相关。

数据流模式

在本章前面，我们讨论了如何使用边界上下文来隔离针对最终消费者的不同外部能力，如车队遥测、车队监控或车队分析。现在，是时候学习如何使用不同的数据流模式来实现这些概念了。

批量（或聚合处理）

让我们考虑一个场景；你发现过去六个月你的电费账单越来越高，你想要比较这段时间内不同设备的利用率。或者，你想要查看更细粒度的信息，比如在过去六个月中洗衣机一天运行了多少次？运行了多长时间？这导致了多少 X 瓦特的消耗？

这就是批量处理发挥作用的地方。在事件驱动架构变得流行之前，它一直是行业的实际标准，并且仍然被广泛用于不同的用例，如订单管理、账单、工资单、财务报表等。在这种处理模式下，大量数据，如数千或数百万条记录（或更多），通常以文件格式（如TXT或CSV）传输，清洗、转换并加载到关系数据库或数据仓库中。之后，数据用于数据核对或分析目的。典型的批量处理环境还包括一个作业调度器，可以根据数据馈送可用性或业务需求触发生成分析工作流。

为了设计车队分析边界上下文，我们设计了以下批量工作流：

图 6.4 – 批量架构

在这个模式中，以下活动正在进行：

• 来自边缘的事件通过流服务（即 Amazon Kinesis）路由到数据湖（即 Amazon S3）。

• Amazon Kinesis 允许在将数据持久化到数据湖之前，使用额外的元数据对数据进行预处理或增强（如果需要）。

• 数据可以通过 ETL 引擎（即 AWS Glue）进行爬取或转换，并可以使用无服务器分析服务（即 Amazon Athena）轻松查询。Amazon Athena 在底层使用 Presto 引擎，并兼容 ANSI SQL。

• 不同的服务，如 Amazon S3 和 Amazon Athena，通过 JDBC 和 ODBC 连接器提供与 Amazon QuickSight 和不同的第三方商业智能（BI）工具的集成。

• Amazon S3 是一个高度可用且耐用的对象存储，它与其他大数据服务集成，例如完全管理的 Hadoop 集群（即 Amazon EMR）或数据仓库（即 Amazon Redshift）。

  有趣的事实

  Amazon EMR 和 Amazon Redshift 通过解耦计算层和存储层来支持大数据处理，这意味着不需要从数据湖将所有数据复制到本地存储。因此，处理变得更加成本效益高，并且从操作上更加优化。

在此边界上下文中使用的通用语言包括以下内容：

• 用于 Amazon Kinesis 流处理的 REST API、Amazon S3 桶上的数据处理和 AWS Glue 上的 ETL 处理

• 在 Amazon Athena 和 Amazon Redshift 上使用 SQL 进行数据分析

• 用于 Amazon EMR 上的数据处理 MapReduce 或 Spark

• 与 Amazon QuickSight 或第三方 BI 工具的 REST API、JDBC 或 ODBC 连接器

批处理非常强大，因为它没有任何窗口限制。在如何关联单个数据点与整个数据集方面有很多灵活性，无论是为了所需的分析结果而以千兆字节或太字节的大小。

事件驱动处理

让我们考虑以下场景：您匆匆忙忙离开了家，在通勤途中收到通知，您忘记关上烹饪炉灶。由于您有一个连接的炉灶，您可以从应用程序中立即远程关闭它，以避免火灾风险。 Bingo！

这看起来很简单，但在本地枢纽（如 HBS 枢纽）需要一定程度的智能，并且需要一系列事件来促进这个工作流程。这些可能包括以下内容：

• 从运动传感器、占用传感器或摄像头检测到家中无人。

• 在一段时间内从炉灶传感器捕获多个测量值。

• 使用边缘的本地过程关联事件，以识别这是一个危害场景。

• 将事件流式传输到消息代理，并将其持久化存储在 ODS 中。

• 触发微服务（s）以通知最终用户此事件。

• 根据用户响应解决问题。

因此，正如您所观察到的，在边缘、云和最终用户之间，在短短几秒钟内发生了很多事情，以帮助减轻风险。这就是为什么在过去十年左右的时间里，事件驱动架构等模式变得非常受欢迎。

在 EDA 之前，轮询和 Webhooks 是用于在不同组件之间通信事件的常见机制。轮询效率低下，因为总是存在从数据源获取新更新并将其与下游服务同步的滞后。Webhooks 并不总是首选，因为它们可能需要自定义授权和身份验证配置。简而言之，这两种方法都需要额外的工作来集成或存在扩展问题。因此，您有事件的概念，它可以被过滤、路由，并以较小的带宽和较低的资源利用率推送到不同的其他服务或系统，因为数据是以小事件或数据集的流的形式传输的。类似于边缘，流式处理允许数据在到达时进行处理，而不会产生任何延迟。

通常，事件驱动架构有两种拓扑，即中介拓扑和代理拓扑。我们在这里进行了解释：

• 中介拓扑：在事件处理中需要一个中央控制器或协调器。这在存在一系列处理事件的步骤时通常很有用。

• 代理拓扑：没有中介，因为事件通过代理广播到不同的后端消费者。

由于它将边缘与云解耦并允许整体解决方案更好地扩展，因此边缘工作负载中非常常见的代理拓扑。因此，对于车队遥测边界上下文，我们设计了一个使用代理拓扑的事件驱动架构，如下所示。

在以下数据流中，从连接的 HBS 中心（即边缘）流出的事件通过 MQTT 路由到物联网网关（即 AWS IoT Core），这允许通过内置的规则引擎（如果需要）过滤数据，并将数据持久化到 ODS（即 Amazon DynamoDB）。Amazon DynamoDB 是一个高性能的非关系型数据库服务，可以根据从数百万边缘设备流出的数据量自动扩展。从上一章，您应该已经熟悉了如何建模数据以及如何优化 NoSQL 数据库以适应时间序列数据。一旦数据在 Amazon DynamoDB 中持久化，就可以使用无服务器函数（即 AWS Lambda）在数据上执行创建、读取、更新和删除（CRUD）操作。最后，数据通过 API 访问层（即 Amazon API 网关）以同步或异步的方式提供。

![图 6.5 – 流式架构]

![图片 B17595_06_05.jpg]

![图 6.5 – 流式架构]

在此边界上下文中使用的通用语言包括以下内容：

• 使用 SQL 访问 DynamoDB 表

• 使用 Python 开发 lambda 函数

• 用于 API 网关和 DynamoDB 访问的 REST API

流处理和事件驱动架构（EDA）对于许多需要近乎实时关注的物联网用例非常强大，例如警报、异常检测等，因为它在数据到达时立即分析数据。然而，每个架构都有权衡，EDA 也不例外。由于流处理的结果可以立即提供，因此对特定数据点的分析不能考虑未来的值。即使是过去的数据，也受到较短的间隔限制，这通常通过不同的窗口机制（如滑动、滚动等）来指定。这正是批量处理发挥关键作用的地方。

复杂事件处理

让我们考虑以下场景，您计划在家减少食物浪费。因此，每次您在杂货店签到时，您都会收到一个通知，列出了冰箱（或食品架）中即将过期的易腐物品，因为这些物品甚至还没有被打开或利用率低，即将到期。

这可能听起来像是一个容易解决的问题，但需要在本地枢纽（例如 HBS 枢纽）有一定的智能处理，以及在云端的复杂事件处理工作流程来促进这一点。它可能包括以下内容：

• 基于位置共享和用户行为，识别用户计划进行购物的事件模式（或特殊事件）。

• 从冰箱或食品架中安装的摄像头传感器检测到一些易腐物品即将到期。或者，使用气味传感器来检测腐烂食品的模式。

• 通过状态机关联所有这些模式（即用户、位置和食品到期日期），并应用业务规则以识别需要关注的物品清单。

• 触发微服务（s）将此信息通知最终用户。

对于餐饮业来说，由于易腐物品的数量和它们运营的规模，这个问题可能会变得更加复杂。在这种情况下，基于当前实践对浪费的近实时可见性可以帮助企业优化其供应链并节省大量成本。因此，正如你可以想象的那样，边缘和物联网与 CEP（复杂事件处理）等大数据处理能力的结合可以帮助解决具有挑战性的用例。

与通过关联事件来识别模式相比，以小块或批量处理到达的事件进行处理和查询相对容易。这就是 CEP 发挥作用的地方。它被认为是流处理的一个子集，重点是通过对多个来源的事件进行关联或通过监听更长时间段的遥测数据来识别特殊（或复杂）事件。实现 CEP 的常见模式之一是通过构建状态机。

在以下流程中，从连接的 HBS 枢纽（即边缘）流出的事件通过 MQTT 路由到物联网网关（即 AWS IoT Core），该网关根据设定的标准过滤复杂事件，并将它们推送到复杂事件处理引擎（即 AWS IoT 事件）内部定义的不同状态机。AWS IoT 事件是一个完全管理的 CEP 服务，允许您监控设备或设备车队以检测故障或操作变化，然后根据定义的事件触发操作：

![图 6.6 – CEP 架构

![img/B17595_06_06.jpg]

图 6.6 – CEP 架构

在车队监控的边界上下文中使用的通用语言包括以下内容：

• 复杂事件处理的状态机

• 用于通知或订阅的 REST API 通过Amazon Simple Notification Service（SNS）

CEP 对于许多需要根据来自多个传感器、时间线或其他环境因素的事件进行关注的物联网用例非常有用。

在设计现实生活中的物联网工作负载时，可能需要考虑许多其他设计模式。这些可能是功能性的或非功能性的要求，例如为了合规要求进行数据归档、为了冗余进行数据复制以及为了实现所需的 RTO 或 RPO 进行灾难恢复；然而，这些内容超出了本书的范围，因为这些是通用原则，并不一定与边缘计算或物联网工作负载相关。如果这些主题对您感兴趣，有许多其他书籍或资源可供参考。

云端数据流反模式

使用边缘设备在云端处理数据的反模式可以通过三个定律——物理学定律、经济学定律和土地法——来更好地解释：

• 物理学定律：对于需要低延迟的使用案例，通常将数据处理更靠近事件源是最佳方法，因为我们无法超越光速，因此往返延迟可能无法承受。让我们考虑一个场景，自动驾驶汽车在检测到行人后需要紧急制动；它无法承受从云端返回的往返延迟。这一因素对于物理上偏远的环境也很相关，例如采矿、石油和天然气设施，这些地方网络覆盖差或间歇性。即使在我们这里的使用案例中，如果出现电力或网络故障，中心节点仍然需要足够智能，能够通过分析本地事件来检测入侵。

• 经济学定律：与网络成本相比，过去几十年中计算和存储的成本呈指数级下降，但网络成本在规模上可能仍然过高。尽管数字化转型导致了不同行业数据量的激增，但其中大部分数据质量较低。因此，边缘的数据聚合和过滤将允许您仅将高价值数据发布到云端，从而降低网络带宽成本。

• 土地法：大多数行业需要遵守与数据主权相关的法规或合规要求。因此，在特定设施、地区或国家本地保留数据可能是数据处理的关键因素。即使在我们这里与连接的 HBS 相关的使用案例中，工作负载可能需要符合 GDPR 要求。

AWS 提供不同的边缘服务来支持需要遵守上述法律的使用案例，而不仅限于物联网服务。例如，考虑以下情况：

• 基础设施：AWS Local Zones、AWS Outposts 和 AWS Wavelength

• 网络：Amazon CloudFront 和 POP 位置

• 存储：AWS Storage Gateway

• 坚固且断开连接的边缘设备：AWS Snowball Edge 和 AWS Snowcone

• 机器人技术：AWS Robomaker

• 视频分析：Amazon Kinesis Video Streams

• 机器学习：Amazon Sagemaker Neo、Amazon Sagemaker Edge Manager、Amazon Monitron 和 AWS Panorama

上述服务超出了本书的范围，信息仅提供给你，以便你能够全面了解 AWS 边缘服务的广度和深度。

通过实验室的动手方法

在本节中，你将学习如何利用本章学到的概念在云上设计一个架构。具体来说，你将继续使用在第五章，“从边缘摄取和流式传输数据”中引入的 lambda 架构模式，在云上处理数据：

图 6.7 – 动手架构

在上一章中，你已经完成了步骤 1 和 4。本章将帮助你完成步骤 2、3、5、6 和 7，包括消费遥测数据和构建用于执行 BI 的分析管道：

图 6.8 – 动手实验室组件

在本节动手实践中，你的目标包括以下内容：

1. 查询 ODS。

2. 构建一个 API 接口层以启用数据消费。

3. 在数据湖中为处理遥测数据构建 ETL 层。

4. 通过 BI 工具可视化数据。

构建云资源

本实验建立在你在第五章，“从边缘摄取和流式传输数据”中已部署的云资源之上。因此，请确保你在继续以下步骤之前已经完成了那里的动手实践部分。此外，请继续从chapter 6/cfn文件夹部署 CloudFormation 模板，以创建本实验所需的资源，例如 AWS API 网关、lambda 函数和 AWS Glue 爬虫。

注意

请从第五章，“从边缘摄取和流式传输数据”中已部署的 CloudFormation 堆栈的输出部分检索此 CloudFormation 模板所需的参数（例如 S3 存储桶）。

此外，你还可以从已部署的 CloudFormation 堆栈的资源或输出部分找到本实验所需的具体资源名称（例如 lambda 函数）。将它们复制到本地记事本中是一个好习惯，这样你可以快速参考它们。

一旦 CloudFormation 成功部署，请继续以下步骤。

查询 ODS

导航到 AWS 控制台，并尝试从操作（或事务）数据存储中持久化的数据中生成洞察。正如你在上一章所学，所有近实时处理的数据都持久保存在 DynamoDB 表中（packt_sensordata）：

1. 要查询数据，请导航到DynamoDB 控制台，从左侧面板中选择表，点击表，然后点击查看项目。

2. 在 device_id 分区键中点击 1，然后点击运行。这应该会返回包含所有属性的数据点集。

3. 展开过滤器部分，并添加以下属性的过滤器：

   • 温度。

   • 湿度。

   • 类型 – 数字。

   • 条件 – 大于或等于。

   • 值 – 35。

   • 点击运行。

   在这里，查询接口允许您根据不同的标准快速过滤数据。如果您熟悉 SQL，您还可以尝试 DynamoDB 控制台上的 PartiQL 编辑器。

4. 此外，DynamoDB 允许您扫描整个表或索引，但这通常是一个昂贵的操作，尤其是对于大数据集。要扫描表，请点击扫描标签（位于查询标签旁边），然后点击运行。

为了获得更好的性能和更快的响应时间，我们建议您使用查询而不是扫描。

AWS Lambda

除了在数据上具有交互式查询功能外，您通常还需要为各种其他角色（如消费者、车队运营商等）构建表示层和业务逻辑来访问数据。您可以使用 Lambda 定义业务逻辑层：

1. 导航到 AWS Lambda 控制台。点击左侧面板中的函数，然后选择之前使用 CloudFormation 模板创建的函数。

2. 您还记得我们在第五章，“从边缘摄取和流式传输数据”的数据建模练习中创建了两个方面（getItems 和 putItems）来访问数据吗？以下是在 Lambda 函数中嵌入的逻辑，以实现等效的功能结构。请审查代码以了解 get 和 put 功能是如何工作的：

     try {
       switch (event.routeKey) {
         case "GET /items/{device_id}":
           var nid = String(event.pathParameters.id);
           body = await dynamo
             .query({
               TableName: "<table-name>",
               KeyConditionExpression: "id = :nid",
               ExpressionAttributeValues: {
                 ":nid" : nid
               }
             })
             .promise();
           break;
         case "GET /items":
           body = await dynamo.scan({ TableName: "<table-name>" }).promise();
           break;
         case "PUT /items":
           let requestJSON = JSON.parse(event.body);
           await dynamo
             .put({
               TableName: "<table-name>",
               Item: {
                 device_id: requestJSON.id,
                 temperature: requestJSON.temperature,
                 humidity: requestJSON.humidity,
                 device_name: requestJSON.device_name
               }
             })
             .promise();
           body = `Put item ${requestJSON.id}`;
           break;
         default:
           throw new Error(`Unsupported route: "${event.routeKey}"`);
       }
     } catch (err) {
       statusCode = 400;
       body = err.message;
     } finally {
       body = JSON.stringify(body);
     }
     return {
       statusCode,
       body,
       headers
     };};
   

请注意，在这里，我们使用 Lambda 函数。这是因为无服务器函数已成为处理近实时事件驱动数据的一种常见模式。由于它减轻了您在整个应用程序生命周期中管理或操作任何服务器的需求，您的唯一责任是使用支持的语言编写代码并将其上传到 Lambda 控制台。

有趣的事实

AWS IoT Greengrass 为边缘设备提供 Lambda 运行时环境，以及 Python、Java、Node.js 和 C++ 等多种语言。这意味着您不需要管理两个不同的代码库（例如嵌入式和云）或多个开发团队。这将缩短您的开发时间，从边缘到云实现统一的开发生态，并加速您的上市时间。

Amazon API 网关

现在业务逻辑已经使用 Lambda 函数开发，让我们使用 Amazon API 网关创建 HTTP 接口（即表示层）。这是一个用于创建、管理和大规模部署 API 的托管服务：

1. 导航到使用 CloudFormation 模板创建的 MyPacktAPI。

2. 展开 REST 方法。

3. 您应该观察以下操作：

   /items GET – allows accessing all the items on the DynamoDB table (can be an expensive operation)
   

4. 在开发下拉菜单下继续操作。点击授权并检查相应的操作。在这个实验室中，我们没有附加任何授权者，但在实际工作中推荐使用。API 网关提供了不同形式的授权者，包括内置的 IAM 集成、JSON Web Tokens（JWT）或使用 lambda 函数的自定义逻辑。

5. 接下来，点击/items GET)。在右侧面板中，您将看到相关的 lambda 函数。为了简化，我们在这里对所有操作使用相同的 lambda 函数，但您可以选择其他函数或目标，例如 Amazon SQS、Amazon Kinesis、您 VPC 中的私有资源，或者根据您的实际用例需要，任何其他 HTTP URI。

6. API 网关提供了许多与 CORS、重新导入/导出和节流相关的附加选项，但它们不在本实验室的范围内。相反，我们将专注于执行 HTTP API 并检索传感器数据。

7. 在您的设备终端中点击GET) items：

   a. Query all items from the table 
   curl https://xxxxxxxx.executeapi.<region>.amazonaws.com/items
   

   您应该在终端上看到一个长列表的项目，这些项目是从dynamodb表中检索出来的。

亚马逊 API 网关允许您创建不同类型的 API，之前配置的那个就属于 HTTP API 类别，它允许访问 lambda 函数和其他 HTTP 端点。此外，我们在这里也可以使用 REST API，但选择了 HTTP 选项，因为它使用简单，可以自动部署所需的 API 而无需额外努力，并且可能更经济高效。总之，您现在已经通过查询或 API 接口完成了 ODS 边界上下文的实现。

构建分析工作流

在下一节中，您将在 Amazon S3 上持久化的批量数据上构建一个分析管道（即数据湖）。为此，您可以使用 AWS Glue 爬取数据并生成数据目录。之后，您将使用 Athena 进行交互式查询，并使用 QuickSight 通过图表/仪表板可视化数据。

AWS Glue

AWS Glue 是一项托管服务，提供了许多 ETL 功能，如数据爬虫、数据目录、批量作业、与 CI/CD 管道的集成、Jupyter 笔记本集成等。主要来说，您将在本实验室中使用数据爬虫和目录功能。我们认为这应该足够满足物联网专业人士的需求，因为数据工程师在现实世界中将主要负责这些活动。然而，如果您相信学习并对此好奇，请随意探索其他功能：

1. 导航到AWS Glue控制台，点击左侧面板中的爬虫，并使用 CloudFormation 模板选择之前创建的爬虫。

2. 查看爬虫定义的一些关键属性，如下所示：

   • 状态：爬虫是否已准备好运行？

   • 调度：爬虫的频率设置正确吗？

   • 数据存储：S3。

   • 包含路径：数据集的位置是否正确？这应该指向原始传感器数据存储桶。

   • 配置选项：表定义是否根据上游更改在目录中更新？

3. 此外，Glue 允许您通过其分类器功能处理不同的数据格式。您可以使用内置的分类器处理最常见的数据格式，如 Grok、XML、JSON 和 CSV，如果您有专有格式的数据，还可以指定自定义模式。

4. 在这里，爬虫应该按照通过 CloudFormation 配置的指定计划运行；然而，您也可以通过点击 运行爬虫 来按需运行它。如果您这样做，请等待爬虫完成从 启动 -> 运行 -> 停止 -> 就绪 状态的转换。

5. 现在数据抓取已完成，导航到 *packt* 已创建。如果您已经创建了大量的表，另一个快速选项是使用搜索按钮并筛选 packt_gluedb。

6. 点击表以验证属性，例如数据库、位置、输入/输出格式和表架构。确认架构是否显示了您希望保留的属性。如果不是，您可以点击 编辑 架构并进行必要的更改：

   图 6.9 – Glue 中的表架构

7. 记录数据库和表名，因为您在下一两个部分中需要它们。

在这个实验中，您只使用了一个数据源进行爬取；然而，如果您的用例需要，您可以添加多个数据源。一旦数据目录更新并且数据（或元数据）可用，您可以通过不同的 AWS 服务来消费它们。您可能还需要经常清理、筛选或转换您的数据。然而，这些责任通常不是由物联网从业者执行的，主要是由数据分析师或数据科学家负责。

Amazon Athena

Amazon Athena 作为无服务器数据仓库，您可以在由 Glue 等 ETL 引擎整理的数据上运行分析查询。Athena 使用读取时模式；因此，当您运行查询时，架构会被投影到您的数据上。由于 Athena 允许计算层和存储层的解耦，您可以将不同的数据湖服务（如 S3）连接起来以运行这些查询。Athena 使用 Apache Hive 进行 DDL 操作，如定义表和创建数据库。对于通过查询支持的不同功能，底层使用 Presto。Hive 和 Presto 都是开源 SQL 引擎：

1. 导航到 AWS Athena 控制台，并从左侧面板中选择 数据源。

2. 保持数据源为 packt_gluedb：

   • 这是在上一节中由 Glue 爬虫自动创建的，在扫描存储批处理传感器数据的 S3 目标存储桶之后。

3. 这应该会填充在此数据库下创建的表列表。

4. 点击与*mysensordatabucket*名称相似的表旁边的三个点，选择预览表。这将自动构建并执行 SQL 查询。

这应该会显示只有 10 条记录的数据结果。如果您想查看整个数据集，请从查询末尾删除 10 个参数的限制。如果您熟悉 SQL，请随意调整查询并尝试不同的属性或连接条件。

备注

在这里，您处理了从 HBS 中心设备流出的 JSON 数据。但如果您的组织希望利用更轻量级的数据格式呢？Athena 通过使用序列化-反序列化（SerDe）库原生支持各种数据格式，如CSV、AVRO、Parquet和ORC。即使是复杂的模式也通过正则表达式得到支持。

到目前为止，您已经从数据湖中爬取了数据，创建了表，并成功查询了数据。现在，在最后一步，让我们学习如何构建可以在此数据上启用 BI 的仪表板和图表。

QuickSight

作为物联网从业者，构建业务仪表板可能不是您核心职责的一部分。然而，一些基本知识总是有用的。如果您考虑传统的 BI 解决方案，数据工程师可能需要几周或几个月的时间来构建复杂的交互式即席数据探索和可视化能力。因此，业务用户被限制在预定义的报告和预选查询中。此外，这些传统的 BI 解决方案需要大量的前期投资，并且当数据源规模增长时，其性能不如 Amazon QuickSight。这就是 Amazon QuickSight 发挥作用的地方。它是一个易于使用、高度可扩展且支持业务所需复杂功能的管理服务：

1. 导航到 Amazon QuickSight 控制台并完成如这里所述的一次性设置：

   • 如果您之前没有使用过，请注册标准版。

   • 为实验室购买 SPICE 容量

   • 注意，这有一个 60 天的试用期，所以请确保在研讨会结束后取消订阅，以防止被收费。

   • 点击右上角的登录用户，然后选择管理 QuickSight | 安全与权限 | 添加和删除 | 检查 Amazon Athena | 应用。

   • 点击左上角的 QuickSight 标志以导航到主页。

   • 点击右上角的登录用户，您将观察到您的区域首选项列在您的语言首选项下方。

   • 确认或更新区域，使其与您的作业区域相匹配。

2. 点击新建分析，然后新建数据集，并选择Athena。

3. 将数据源名称输入为packt-data-visualization，保持工作组为其默认设置，然后点击创建数据源。

4. 保持目录为默认，选择数据库，然后选择在AWS Glue部分的步骤 5中创建的表。

5. 点击选择，选择直接查询你的数据，然后再次点击可视化。

6. 现在构建仪表板：

   • 选择 X 轴的日期时间戳（从值下拉菜单中选择分钟）。

   • 选择其他读取值，如device_id、温度和湿度作为 Y 轴（从每个读取的值下拉菜单中选择平均值）。

随意尝试不同的字段或视觉类型来可视化其他智能家居相关的信息。正如你可能观察到的，在创建数据集时，QuickSight 原生支持不同的 AWS 和第三方数据源，如 Salesforce、ServiceNow、Adobe Analytics、Twitter、Jira 等。此外，它允许通过移动应用（如 iOS 和 Android）为商业用户或操作快速推断特定工作负载的数据洞察，同时还集成了机器学习增强。

恭喜！你已经使用不同的 AWS 应用程序和数据服务完成了云上数据处理的整个生命周期。现在，让我们通过摘要和知识检查问题来结束本章。

挑战区域（可选）

在Amazon API 网关部分，你构建了一个接口来检索dynamodb表中的所有项目。然而，如果你需要提取特定设备（如 HVAC）的特定项目（或项目集），这可以比扫描所有数据更节省成本。

GET /items {device_id}. 检查 lambda 函数以更好地理解它如何映射到后端逻辑。

摘要

在本章中，你了解了与物联网工作负载相关的大数据概念。你学习了如何使用 DDD 方法设计数据流，以及与物联网工作负载常见的不同数据存储和数据集成模式。你实现了一个 lambda 架构来处理车队遥测数据和数据分析管道。最后，你通过通过 API 消费数据和通过业务仪表板可视化来验证了工作流程。在下一章中，你将学习如何使用所有这些数据来构建、训练和部署机器学习模型。

知识检查

在继续下一章之前，通过回答这些问题来测试你的知识。答案可以在书的末尾找到：

1. 你能想到至少两个从边缘工作负载的角度来看领域驱动设计的优势吗？

2. 对或错：边界上下文和通用语言是相同的。

3. 你认为要有一个可操作的数据存储或数据湖/数据仓库需要什么？

4. 你能回忆起将流式处理和批量工作流程结合在一起的设计模式名称吗？

5. 你可以采用什么策略来将云上的原始数据转换？

6. 对或错：你不能通过 API 访问 NoSQL 数据存储中的数据。

7. 你会在什么情况下使用中介拓扑而不是代理拓扑来处理事件驱动的工作负载？

8. 你能想到使用无服务器函数处理物联网数据至少一个好处吗？

9. 你可以使用哪些商业智能（BI）服务向最终消费者展示数据？

10. 对或错：JSON 是云上大数据处理最优化数据格式。

11. 你会如何在你的运营数据存储（或数据湖）上构建 API 接口？

参考文献

查看以下资源，以获取本章讨论的概念的更多信息：

• 数据管理 - 知识体系：www.dama.org/cpages/body-of-knowledge

• 埃里克·埃文斯的领域驱动设计：www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software-ebook/dp/B00794TAUG

• 领域语言：www.domainlanguage.com/ddd

• AWS 上的大数据：aws.amazon.com/big-data/use-cases/

• AWS 无服务器数据分析管道：d1.awsstatic.com/whitepapers/aws-serverless-data-analytics-pipeline.pdf

• AWS 上的现代无服务器架构：d1.awsstatic.com/architecture-diagrams/ArchitectureDiagrams/mobile-web-serverless-RA.pdf?did=wp_card&trk=wp_card

• BI 工具：aws.amazon.com/blogs/big-data/tag/bi-tools/

第七章：第七章: 边缘的机器学习工作负载

边缘计算的增长不仅是由计算效率高的硬件设备的进步推动的，也是由十年前仅在云（或本地基础设施）上可用的不同软件技术的出现推动的。例如，想想智能手机、智能手表或个人助理，如亚马逊 Alexa，它们将强大的硬件和软件能力带给消费者。使用面部识别解锁手机或车库门、与 Alexa 使用自然语言进行对话或驾驶自动驾驶汽车已经成为新常态。因此，基于从周围环境持续学习而构建智能的物理-数字系统对于当今世界各种工作负载来说已经成为关键。

重要的是要认识到，大多数顶级科技公司（如苹果、亚马逊、谷歌和Meta，前称Facebook）都使用机器学习（ML）并通过他们的产品使消费者更容易接触到它。这也不是一项新技术，它已经被金融、医疗和工业等领域的行业使用很长时间了。在本章中，我们将关注如何利用机器学习能力为任何物联网（IoT）工作负载提供支持。

我们将继续致力于连接的枢纽解决方案，并学习如何在边缘（即Greengrass设备）上开发机器学习能力。在前几章中，你已经学习了如何在边缘处理不同类型的数据，现在，是时候学习不同的机器学习模型如何对数据进行推理，以在边缘得出智能见解。

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

• 定义适用于物联网工作负载的机器学习

• 在云中设计机器学习工作流程

• 实践机器学习工作流程架构

技术要求

本章的技术要求与在第七章“边缘工作负载基础”中概述的要求相同。详见该章节中的完整要求。

定义适用于物联网工作负载的机器学习

机器学习技术不再是未来的技术——在过去的几十年里，它已经改变了数百万人的生活方式。那么，什么是机器学习？

“机器学习是研究计算机在没有明确编程的情况下学习能力的领域。”

– 亚瑟·塞缪尔，1959 年

让我们看看一些来自消费者和工业领域的真实世界机器学习应用物联网工作负载的例子。

首先，这里有一些来自消费者领域的例子：

• 能够识别你的日常习惯并提供与健身或生产力相关的建议的智能手机或智能手表

• 可以以自然方式与之互动的个人助理（如 Alexa、Google 和 Siri），用于控制灯光和供暖、通风和空调（HVAC）等不同需求

• 可以监控您的周围环境并检测意外行为或威胁的智能摄像头

• 可以通过其视觉属性、车牌或甚至驾驶员的面部识别您的汽车的智能车库

• 能够持续变得更聪明，以识别交通中的驾驶模式、物体和行人的自动驾驶汽车

这里有一些来自工业领域的例子：

• 能够更好地优化总体设备效率（OEE）的智能工厂

• 在不同的工业工厂、仓库或工作场所提高工人的安全和生产力

• 使用计算机视觉（CV）或音频进行实时质量控制（QC）以识别缺陷

• 改善供应链以减少浪费并提高客户体验，例如从 Amazon.com 进行 1 小时或 15 分钟的送货（使用无人机）

为了构建上述能力，客户使用了不同的机器学习框架和算法。为了简洁起见，我们不会涵盖今天存在的每一个机器学习框架。我们认为这是数据科学的一个领域，它不适合物联网实践者的日常职责。但如果你有兴趣深入了解，有许多关于机器学习/人工智能（AI）的书籍。因此，本章的重点将是学习一些关于机器学习系统历史和核心概念的知识，以及将机器学习与物联网和边缘工作负载集成的途径。

机器学习的历史是什么？

现在，作为人类，我们可以通过声音、视觉或触觉与各种机器（从手机到自动驾驶汽车）进行交流。没有机器学习技术的采用，这是不可能的。这只是开始，未来几年机器学习将变得更加易于访问，以不同的方式改变我们的生活。您可以通过这篇由《福布斯》杂志发表的文章快速了解这项令人惊叹的技术的历史：www.forbes.com/sites/bernardmarr/2016/02/19/a-short-history-of-machine-learning-every-manager-should-read/?sh=1ca6cea115e7。

在研究界之外，像 Amazon.com、Google 和其他技术公司也在 20 世纪 90 年代末开始采用机器学习技术。例如，Amazon.com 使用机器学习算法来了解其客户的阅读偏好，并建立了一个模型来通知他们发布的新书，这些新书符合他们的兴趣或类型。Google 将其用于搜索引擎，Microsoft 用于识别电子邮件中的垃圾邮件，等等。从那时起，这项技术已被许多其他行业用于各种用例。

现在我们已经对机器学习的背景有所了解，让我们现在尝试理解机器学习的基础。

机器学习系统有哪些不同类型？

与分布式数据系统类似，其中存在不同类型的技术来处理不同类型的数据，机器学习系统也有不同的种类。如果我们将它们分类到更广泛的类别中，区别可以这样描述：

• 监督式机器学习（SML）—在这种机器学习方法中，模型使用标记的数据集进行训练，并需要人类监督（或教师）。例如，让我们考虑一个场景，我们需要一个连接的枢纽解决方案来识别可能入侵您场所的不同对象，如猫、狗、人类（或季节性鸟类？）。因此，需要由人类（或人类）对图像进行标记，然后在模型准备好（即，模型）预测结果之前，使用分类算法在该数据上对模型进行训练。在下面的屏幕截图中，您可以看到一些对象已经标记，而其余的尚未标记。因此，人类需要做好标记工作，以便模型有效：

图 7.1 – 一个标记的图像分类训练集

训练的长度以及数据量和质量将决定模型的准确性。

• 无监督式机器学习（UML）—在这种机器学习方法中，模型使用未标记的数据集进行训练，并且不需要人类监督（或自我教学）。例如，让我们考虑你场所上的一个新入侵者，如鹿、狼（或老虎？），你希望模型将其检测为异常并通知你。在下面的屏幕截图中，您可以看到没有任何图像被标记，模型需要自己找出异常：

图 7.2 – 一个未标记的图像分类训练集

考虑到训练数据集中没有鹿、狼或老虎的图片，模型需要足够智能，能够使用如随机森林等算法将其识别为异常（或新颖性检测）。

• 半监督式机器学习（SSML）—在这种机器学习方法中，模型使用的是混合了未标记和标记数据的集合（想想按需教学，你需要自己学习大部分内容）。让我们考虑一个场景，你收集了在家举办的派对上的客人照片。不同的客人在不同的照片中出现，其中大多数未标记，这是算法的无监督部分（如聚类）。现在，作为派对的主持人，如果你在数据集中一次性标记了独特的人物，机器学习模型可以立即在其它照片中识别出这些人物，如下面的图所示：

图 7.3 – SSML

这可能非常有用，如果你想要搜索个人或家庭的照片并与他们分享（谁在乎其他家庭的照片呢？）

• 强化学习（RL）—在这种机器学习方法中，模型被训练在环境中做出一系列决策并最大化长期目标。模型通过试错法的迭代过程进行学习。一个物理或虚拟设备等代理使用此模型在给定环境状态下采取行动，达到新的状态。这使得代理有资格获得奖励（正面或负面），代理将继续迭代这个过程，直到它导致最优化长期奖励。代理从初始状态到最终状态的全部生命周期被称为一个剧集。

  例如，使用 RL，你可以训练一个机器人拍摄你家中举办的派对上所有宾客的照片。机器人将保持在特定的轨道上，并从该环境中捕捉图像。如果它保持在轨道上并捕捉到可接受的图像，它将获得正面奖励；如果它偏离轨道或捕捉到扭曲的快照，它将获得负面奖励。随着它继续迭代这个过程，最终它将学会如何最大化其长期目标，即捕捉到辉煌的图像。以下图表反映了这个 RL 过程：

图 7.4 – RL

我们在前面图表中解释了机器学习的一个更广泛的类别；然而，有许多框架和算法超出了本书的范围。因此，在下一节中，我们将重点关注最常见的一些，这些可以应用于物联网和边缘工作负载生成数据。

物联网工作负载的机器学习分类法

机器学习在物联网中最常见的三个应用领域是分类、回归和聚类，如下所示：

图 7.5 – 机器学习算法的总结分类法

让我们更详细地讨论前面图表中的命名法，如下所示：

• 分类—分类是一种监督学习技术，你从一组观察到的值开始，并从未知数据中得出一些结论。在现实世界中，分类可以用于图像分类、语音识别、药物分类、情感分析、生物识别识别等。

• 回归—回归是一种监督学习技术，你可以预测一个连续值。预测是通过估计因变量（Y）与一个或多个自变量（X）之间的关系，使用最佳拟合直线来实现的。在现实世界中，回归可以应用于预测明天的温度、能源利用价格、金价等。

• 聚类——聚类是一种 UML 算法，你可以将未标记的数据点分组。这通常用于统计分析。数据集中未标记数据点的分组是通过识别具有共同属性和特征的数据点来实现的。在现实世界中，这个算法可以应用于市场细分、医学成像、异常检测和社会网络分析。

在本章的动手实验室部分，你将学习如何使用分类算法来分类对象（例如汽车和宠物）。

为什么机器学习今天可以在边缘访问？

我们已经在第六章中向您介绍了边缘计算的三个定律：物理定律（对延迟敏感的使用案例）、经济定律（对成本敏感的使用案例）和土地定律（对数据敏感的使用案例）。基于这些定律，我们可以识别当今世界中的各种使用案例，特别是与物联网和边缘相关的情况，在这些情况下，在设备或网关本地处理和生成数据洞察是非常有意义的，而不是持续将其发布到云端。

然而，限制是这些边缘设备或网关上可用的有限资源（例如中央处理器（CPU）、图形处理器（GPU）、内存、网络和能源）。因此，建议利用云的计算能力，使用首选框架（例如MXNET、TensorFlow、PyTorch、Caffe或Gluon）构建和训练机器学习模型，然后将模型部署到边缘进行推理。

例如，如果在一个智能家居中产生了大量由婴儿啼哭、狗吠或周围建筑噪音产生的嘈杂数据，机器学习模型可以将其识别为嘈杂数据，在本地触发任何指定的操作——例如提醒检查婴儿或宠物——但避免将这些数据点发布到云端。这样，大量间歇性数据可以在现场本身被过滤掉，这些数据对长期价值较小。

边缘机器学习是一个不断发展的领域，今天有来自不同供应商的许多新兴框架和硬件产品可供选择，其中一些列在下面的表格中。

这里列出了边缘常见的机器学习框架：

![图 7.6 – 在边缘常见的机器学习框架

图 7.6 – 在边缘常见的机器学习框架

这里列出了在边缘执行机器学习常见的硬件堆栈：

![图 7.7 – 在边缘执行机器学习常见的硬件堆栈

图 7.7 – 在边缘执行机器学习常见的硬件堆栈

您已经在本书的不同实验室中使用了树莓派作为底层硬件。在动手实践机器学习架构部分，您将学习如何在云中训练基于 Apache MXNET 的机器学习模型，并在边缘进行推理部署。有了这个背景，让我们讨论如何开始构建边缘机器学习应用。

在云中设计机器学习工作流程

机器学习是一个端到端（E2E）的迭代过程，由多个阶段组成。正如我们在本书的其余部分解释的不同阶段，我们将与跨行业数据挖掘标准流程（CRISP-DM）联盟提供的一般指南保持一致。CRISP-DM 参考模型于 1996 年底由三位新兴数据挖掘市场的先驱提出，并在多个行业细分市场的组织和供应商的参与下不断演变。以下图表显示了 CRISP-DM 参考模型的不同阶段：

![图 7.8 – CRISP-DM 参考模型阶段（重绘自 www.the-modeling-agency.com/crisp-dm.pd…]

![img/B17595_07_08.jpg]

图 7.8 – CRISP-DM 参考模型阶段（重绘自 www.the-modeling-agency.com/crisp-dm.pd…

此模型仍被视为一个基线，是一个成功进行数据挖掘项目的证明工具，因为其应用是中立的，并且适用于广泛的机器学习管道和工作负载。以先前的参考模型（图 7.5）为基础，机器学习项目的生命周期可以扩展到以下活动：

![图 7.9 – 机器学习项目生命周期]

![img/B17595_07_Table3.jpg]

图 7.9 – 机器学习项目生命周期

上述机器学习活动的流程可以直观地表示如下：

![图 7.10 – 端到端机器学习流程]

![img/B17595_07_10.jpg]

图 7.10 – 端到端机器学习流程

在下一节中，我们将通过使用您连接家居中的图像分类场景来详细阐述这些概念。

业务理解和问题界定

第一个阶段是从用例反向工作，从业务角度理解需求。一旦这一点明确，业务背景就会转化为技术需求（例如对机器学习技术的需求），以实现所需的企业成果。这个概念听起来熟悉吗？如果是的话，恭喜您——您已经能够将第六章中介绍的领域驱动设计（DDD）的概念与这些概念联系起来，在云上处理和消费数据。机器学习能力可以被视为另一个有自己一套通用语言的边界上下文。

但使用机器学习解决问题可能会有所不同，以下是从谷歌研究总监彼得·诺维格（Peter Norvig）那里摘录的关于这一点的精彩引言：

"机器学习改变了你对问题的思考方式。焦点从数学科学转向自然科学，通过进行实验和使用统计学方法，而不是逻辑，来分析其结果。"

一个组织需要清楚地确定他们试图解决的商业问题是否是机器学习问题。如果问题可以使用传统的编程方法解决，那么构建机器学习模型可能就是过度了。例如，如果你计划根据历史数据预测特定季度的未来收入，传统的分析方法可能就足够了。但如果你开始考虑其他变量的预测，如天气、竞争对手的活动、促销、经济状况，这更适合机器学习问题。所以，作为一个经验法则，始终尝试用以下问题开始你的机器学习之旅：

• 我的组织或产品面临什么问题？

  让我们考虑一个场景，你试图解决的问题是保护你的家人、宠物和邻居免受停车空间周围来车的影响。

• 使用机器学习或经典分析方法解决这个问题是否合适？

  在这种情况下，需要一个连接的家庭基站解决方案（HBS）中心来识别车辆接近或离开区域时停车空间中的任何生物。这个问题不能使用经典的分析方法来解决，因为你不会为该区域的每个访客、邻居或送货卡车提供时间表。因此，中心可以使用运动传感器检测车辆（的）移动，从周围环境（使用安装的摄像头）捕获不同的图像，并运行实时推理来检测其周围的任何物体。如果发现物体，它将实时警告司机、孩子或宠物，从而避免事故。

  以前，计算机视觉（CV）模型依赖于原始像素数据作为输入，但由于物体背后的不同背景、光照、相机角度或焦点等几个其他因素，这被发现效率低下。因此，图像分类显然是一个机器学习问题。

• 如果是机器学习问题，我是否有足够数量和质量的数据？

  考虑到这里的对象是通用的——例如人类、猫或汽车——我们可以依赖公共数据集，如Caltech-256。这个数据集包含 256 种不同类型的超过 30,000 张图像。

  这通常是我们遇到的最常见问题：多少数据足够用于训练？ 这真的取决于。

  对于基本的线性模型，您至少需要有几千个数据点，对于神经网络（如前面提到的图像分类）则需要数十万个。更多高质量的数据使模型能够更智能地预测。如果您数据较少或数据质量较差，建议首先考虑专用的 AI 服务非机器学习解决方案。我经常引用，有数据，总是“垃圾输入=垃圾输出”。因此，如果您有可疑的数据质量，对经典分析方法或机器学习过程的价值较小。此外，机器学习过程成本更高，因为您将浪费大量时间和资源，并因训练性能可疑的模型而承担成本。

现在，让我们假设您已经满足了前面的要求，并确定您试图解决的问题确实是一个机器学习问题。在这种情况下，您可以选择以下最佳实践来总结问题框架：

1. 将机器学习问题表述为一系列问题，每个问题都有相应的输入和期望的输出。

2. 为项目定义可衡量的性能指标，例如准确性、预测或延迟。

3. 确立项目的成功定义。

4. 制定数据来源和数据标注的策略。

5. 从简单开始——构建一个易于解释、测试、调试和管理的模型。

数据收集或集成

在这个端到端机器学习流程中，您将确定一个数据集，该数据集将作为输入提供给机器学习管道，并评估收集该数据的方法。在前面的章节中，您已经了解到对于不同的物联网用例，AWS 提供了多种方法来批量或实时地摄取原始数据。在其他现实场景中，如果您在云平台或数据中心中有来自物联网设备和信息技术系统的PB（PB）的历史数据，有多种方法可以将这些数据传输到云中的数据湖，如下所示：

• 通过公共互联网传输

• 通过使用从您的数据中心到 AWS 的专用光纤通道设置在私有网络上传输

• 使用硬件设备如 AWS Snowball、AWS Snowmobile 或 AWS Snowcone 进行迁移，因为它比通过公共互联网传输所需时间更短。

  有趣的事实

  通过雪设备传输数据与您将包裹退回 Amazon.com 的方式非常相似！您会得到带有 E-link 屏幕的硬件，充当退货标签，数据可以加载并运回 AWS 数据中心。如果您有EB（EB）的数据，AWS 甚至可以为您提供一辆用于数据传输的卡车，称为 AWS Snowmobile。请参阅 AWS 文档，如何开始使用 AWS Snow Family (docs.aws.amazon.com/snowball/index.html)，以了解所需的步骤。

再次，考虑开发一个用于识别驶向停车位区域的车辆机器学习模型的场景。在这里，您可以使用来自公共数据仓库（如Caltech）的训练数据集，因为您主要需要用于分类的通用图像，包括孩子、宠物以及移动物体，如汽车和卡车。将有两个数据集在范围内，如下所示：

• 训练数据集—Caltech 的公共数据集，将托管在数据湖上（Amazon Simple Storage Service（Amazon S3））

• 推理数据集—在实时中心生成

以下代码可以启用从公共数据仓库下载两个数据集：

![图 7.11 – 数据理解

图 7.11 – 数据理解

对于一个公共数据集不可用的不同用例，您的组织需要拥有足够数量且质量最优的数据点。

这里提供了该阶段最佳实践的总结：

• 定义您将用作机器学习管道输入的各种数据源

• 确定要用于管道输入的数据形式（即，原始数据与转换数据）

• 使用数据血缘机制确保数据位置和来源被编目，如果需要进一步处理的话

• 使用不同的 AWS 管理服务来收集、存储和处理数据，无需额外繁重的工作

数据准备

数据准备是管道中的关键步骤，因为如果底层数据未经清理、整理和验证，机器学习模型无法表现最佳。在物联网工作负载中，由于边缘设备与人类在物理环境中共存（而不是托管在物理数据中心），产生的噪声数据量可能很大。此外，随着数据集从连接的生态系统持续增长，通过模式比较进行数据验证可以帮助检测新获得的数据集中的数据结构是否发生变化（例如，当某个特征被弃用时）。您还可以检测数据是否开始漂移——也就是说，传入数据的潜在统计信息与用于训练模型的初始数据集不同。漂移可能由于数据的潜在趋势或季节性或其他因素引起。

因此，一般建议从一个小型、统计上有效的样本开始数据准备，可以通过不同的策略（如下所示）迭代改进：

• 检查数据异常

• 检查数据模式的变化

• 检查不同数据集版本的统计数据

• 检查数据完整性，等等

AWS 提供了多种方法来帮助你大规模地准备数据。你已经在第五章，“从边缘摄取和流式传输数据”中玩过AWS Glue。如果你还记得，AWS Glue 允许你管理数据生命周期，例如发现、清理、转换和编目。一旦数据处理完成，数据质量达到所需标准，就可以将其作为机器学习过程的输入。

在本章中，我们向您介绍了一个不同的问题陈述，即处理非结构化数据集（即图像）。考虑到你正在使用一个已经标记的公共数据集，你将只将数据集分成训练集和验证集。数据科学家最常用的方法是将可用数据分成训练集和测试集，这通常是 70-30（%）或 80-20（%）。

以下代码可以启用从公共数据存储库中拆分两个数据集：

![图 7.12 – 数据准备![图 7.12 – 数据准备图 7.12 – 数据准备在现实世界中，你可能没有干净或标记好的数据。因此，你可以利用像Amazon SageMaker Ground Truth这样的服务，它具有自动标记数据（如图像、文本、音频、视频）的内建能力，同时可以轻松访问公共和私人的人类标记者。如果你缺乏内部机器学习技能或者对雇佣数据科学专业人士的成本敏感，这将非常有用。Ground Truth 使用机器学习模型自动标记原始数据，并以极低成本生成高质量的训练数据集。但如果模型无法自信地标记数据，它将把问题转交给人类来解决。数据准备的一个方面是理解你的数据集中的模式。本阶段最佳实践的总结如下：+ 通过发现和转换来分析你的数据。+ 选择合适的工具来完成合适的工作（例如数据标记与调整）。+ 从数据组成中理解模式。# 数据可视化和分析在这个阶段，你可以通过各种分析和可视化工具继续数据探索，以评估数据在分析后的适合度，用于机器学习训练。你可以继续利用像 Amazon Athena、Amazon Quicksight 等在第六章，“在云上处理和消费数据”中介绍的服务。## 特征工程（FE）在这个阶段，作为物联网专业人士，您的责任非常有限。这是数据科学家将确定数据集中可用于训练 ML 模型的独特属性的地方。您可以将行视为观测值，将列视为属性（或属性）。作为数据科学家，您的目标是识别在解决特定业务问题（即特征）中起作用的列。例如，在图像分类中，汽车的颜色或品牌不是确定其为车辆的关键特征。这个过程，即选择和转换变量以确保创建优化的 ML 模型，被称为 FE。因此，FE 的关键目标是整理数据，使其以 ML 算法可以用来提取模式和推断更好结果的形式。让我们按以下方式分解 FE 的不同阶段：+ 特征创建，以识别与特定问题相关的数据集属性，例如图像的像素高度和宽度+ 特征转换，用于数据兼容性或质量转换，例如将输入调整到固定大小或将非数值数据转换为数值数据+ 特征提取，确定一组提供最大价值的特征+ 特征选择，通过观察相关阈值方差来过滤数据集中的冗余特征如果数据集中的特征数量与它可以生成的观测值相比变得非常大，ML 模型可能会遭受称为 过拟合 的问题。另一方面，如果特征数量有限，模型可能会做出很多错误的预测。这个问题被称为 欠拟合。换句话说，模型在测试数据上训练得很好，但无法将泛化应用于新的或未见过的数据集。因此，特征提取可以帮助优化一组特征，这些特征足以生成原始集的全面版本。除了减少过拟合风险外，特征提取还可以通过数据压缩和精度改进来加速训练。不同的特征提取技术包括 主成分分析（PCA）、独立成分分析（ICA）、线性判别分析（LDA）和 典型相关分析（CCA）。AWS 提供了多种方式，以帮助您以迭代的方式在您的数据集上进行大规模的特征工程（FE）。例如，Amazon SageMaker 作为一项托管服务，提供了一个托管 Jupyter 笔记本环境，您可以在其中使用 scikit-learn 库进行 FE。如果您的组织已经投资于 提取、转换、加载（ETL）框架，如 AWS Glue、AWS Glue DataBrew，或托管 Hadoop 框架，如 Amazon Elastic MapReduce（Amazon EMR），数据科学家可以在那里进行 FE 和转换，在利用 SageMaker 训练和部署模型之前。另一个选项是使用Amazon SageMaker Processing。此功能提供了一个完全管理的环境，用于在规模上运行分析作业以及模型评估，同时满足各种安全和合规要求。下面是这个阶段最佳实践的总结：+ 评估数据集中符合特征范式的属性+ 考虑对解决当前问题有用的特征，并删除冗余的特征+ 建立一个迭代机制来探索新的特征或特征组合## 模型训练这一阶段的关键活动包括选择适合您问题的机器学习算法，然后使用前期预处理的数据（即特征）来训练模型。我们已经在“机器学习与物联网工作负载的分类”部分向您介绍了最常用于物联网工作负载的机器学习算法。让我们更深入地探讨这些算法，如下所示：+ 分类——分类可以以两种方式应用；即二分类或多分类。二分类在您有两个组或类别的观察值时很有用，例如狗与猫，或电子邮件是否为垃圾邮件。多分类包括两个以上的组或类别，如一组花朵——玫瑰、百合、兰花或郁金香。不同的分类技术包括决策树、随机森林、逻辑回归和朴素贝叶斯。+ 回归——分类用于预测离散值，而回归用于预测连续变量。回归可以以三种方式应用：最小二乘法、线性或逻辑回归。+ 聚类——K-means是一个非常流行的聚类算法，通常用于将组分配给未标记的数据。此算法速度快且可扩展，因为它使用一种方法通过计算数据点与每个组中心之间的距离来分配每个组。在前面提到的停车位安全场景中，我们正在使用多类分类算法，因为我们期望模型能够对多个类别的对象进行分类，例如人类（特别是儿童）、汽车和动物（如猫、狗和兔子）。AWS 服务如 SageMaker 负责创建和管理训练所需的基础设施的重型工作。您可以选择不同类型的实例，例如启用 CPU 或 GPU 的实例。在下面的示例中，您只需指定实例类型为ml.p2.xlarge，以及其他所需的参数，如volume和instance_count，SageMaker 将完成其余工作，使用估算器接口来实例化和管理基础设施：

图 7.13 – 机器学习训练基础设施

在本章中，您将使用MXNet 框架，但 SageMaker 允许使用大多数其他机器学习框架，如 TensorFlow、PyTorch 和 Gluon 来训练您的模型。

请注意，模型优化是机器学习的一个关键方面，您需要使用不同参数集训练模型，以确定性能最佳的一个。SageMaker 超参数调优作业帮助使用贝叶斯优化或随机搜索技术来优化模型。正如以下示例所示，模型正在使用批大小和形状等超参数进行训练，以解决您的业务问题：

图 7.14 – 机器学习训练参数

为了使组织在机器学习方面的新手更容易且成本效益更高地进行模型训练，SageMaker 支持自动模型调优（通过自动飞行），以自动代表您执行这些操作。您还可以使用自定义机器学习算法作为容器镜像，并使用 SageMaker 进行训练。例如，如果您已经有一个自制的图像分类模型，它不使用任何 SageMaker 支持的机器学习框架，您可以使用您的模型作为容器镜像，并在 SageMaker 中重新训练它，而不需要从头开始。SageMaker 还提供监控和调试功能，允许清晰地查看训练指标。

本阶段最佳实践的总结如下：

• 为您的数据选择合适的算法和训练参数，或者让托管服务为您选择这些参数

• 确保数据集被分割成训练集和测试集

• 应用增量学习以构建最优化模型

• 监控训练指标以确保模型性能不会随时间退化

模型评估和部署

在这个阶段，模型被评估以确定它是否解决了业务问题。如果没有，您可以构建多个具有不同业务规则或方法（例如不同的算法、其他训练参数等）的模型，直到找到满足业务关键绩效指标的最优模型。数据科学家在测试模型（们）针对实际应用时，常常在这个阶段发现其他业务问题的推论。为了评估模型，它可以与历史数据（即离线评估）或实时数据（即在线评估）进行测试。一旦机器学习算法通过评估，下一步就是将模型（们）部署到生产环境中。

物联网/边缘工作负载的场景可能会变得有些棘手，尤其是当你的用例主要涉及在边缘进行离线处理和推理时。在这种情况下，你无法访问云的规模，因此最佳实践通常是进一步优化模型。SageMaker Neo在这种情况下可能很有用，因为它允许你一次训练模型，然后在云中的任何地方或边缘运行。使用这项服务，你可以在大多数常见的框架（如 MXNET、TensorFlow、PyTorch、Keras）中编译模型，并在你选择的平台（如英特尔、NXP、NVIDIA、苹果等硬件）上部署优化版本。以下代码有助于根据不同的参数（如操作系统和架构）优化模型：

![Figure 7.15 – 使用 SageMaker Neo 优化模型

![img/B17595_07_15.jpg]

Figure 7.15 – 使用 SageMaker Neo 优化模型

SageMaker Neo 的工作方式是，其编译器在底层使用 ML 模型来为相应的边缘平台或设备上的模型应用最佳性能。Neo 可以将模型优化到比非优化模型快 25 倍，且精度不受损失，并且所需的内存占用仅为非优化模型的十分之一。但这是如何实现的呢？让我们继续探索，如下所示：

• Neo 具有编译器和运行时组件。

• Neo 编译器有一个应用程序编程接口（API），可以读取使用各种框架开发的模型。一旦读取操作完成，它将框架特定的函数和操作转换为框架无关的中间表示。

• 转换完成后，它开始执行一系列优化。由于这种优化的结果，生成了二进制代码，并将其持久化到共享对象库中，同时模型定义和参数存储在单独的文件中。

• 最后，Neo 运行时 API 可以加载并执行此编译模型，以提供所需性能提升。

如你所想，这种优化对资源受限的边缘设备来说非常强大。以下截图以图解方式表示了如何在生产环境中部署优化模型。在本章的“动手实践 ML 架构”部分，你将学习如何使用 SageMaker Neo 部署训练的模型：

![ Figure 7.16 – 为硬件优化 ML 模型

![img/B17595_07_16.jpg]

Figure 7.16 – 为硬件优化 ML 模型

模型部署后，你需要监控性能指标随时间的变化。这是因为模型在实际数据开始与用于训练模型的数据不同时，其功能可能会变得不那么有效是很常见的。SageMaker 模型监控服务可以帮助检测偏差，并提醒数据科学家或 ML 操作员采取补救措施。

这里是这个阶段最佳实践的总结：

• 评估模型性能是否符合业务目标

• 确定您的模型所需的推理方法（离线与在线）

• 在云上部署模型，使用自动扩展选项，或在边缘使用针对特定硬件的优化

• 监控生产中的模型性能，以识别漂移并执行修复

机器学习设计原则

现在你已经了解了机器学习工作流程中的常见活动，让我们总结前述章节中解释的步骤设计原则，如下：

• 从用例逆向工作，以确定是否需要机器学习或可以使用经典分析方法解决的问题。

• 收集足够数量和高质量的数据，以构建准确的机器学习模型。

• 进行性能分析以了解数据关系和组成。记住：垃圾输入=垃圾输出，因此数据准备在机器学习过程中至关重要。

• 以一小组特征（即属性）开始，解决特定的业务问题，并通过实验进行演变。

• 考虑使用不同的数据集进行训练、评估和推理。

• 评估模型的准确性，并继续迭代，直到它对业务问题最优化。

• 确定模型是否需要在实时（在线）或历史（离线）数据上进行推理。

• 在云上或边缘托管模型的多个变体，并针对实际数据确定最优化的一种。

• 持续监控已部署模型的指标，以进行准确性、修复和改进。

• 利用托管服务来减轻管理底层基础设施的繁重工作。

• 尽可能自动化管道的不同活动，如数据准备、模型训练、评估、托管、监控和警报。

物联网工作负载的机器学习反模式

与任何其他分布式解决方案类似，基于机器学习的物联网工作负载也有反模式。以下是一些例子：

• 不要把所有的鸡蛋放在一个篮子里——端到端机器学习过程包括许多活动，因此需要以下不同角色：

  • 数据工程师——用于数据准备、设计 ETL（或 ELT）流程

  • 数据科学家——用于构建、训练和优化模型

  • 开发运维（DevOps 或 MLOps）工程师——用于构建具有操作和监控机制的可扩展和可重复的机器学习基础设施

  • 物联网工程师——用于构建从物联网网关到不同后端服务的云到边缘部署管道

  总结来说，期望单一资源在规模上执行所有这些活动将导致项目失败。

• 不要假设需求；保持一致——有大量工具可用于分析和机器学习目的，每个工具都有其优缺点。例如，考虑以下：

  • R 和 Python 都是开发机器学习系统的流行编程语言。一般来说，业务分析师或统计学家会倾向于使用 R 或其他商业解决方案（如 MATLAB），而数据科学家会选择 Python。

  • 同样，数据科学家可能有自己的首选机器学习框架，例如 TensorFlow 而不是 PyTorch。选择不同的语言或框架会产生下游影响——例如，边缘硬件可能需要支持用于推理机器学习模型的相应版本或库。

  因此，对于所有参与机器学习活动的不同角色来说，保持对业务和技术要求的统一至关重要。

• 规划技术债务—由于机器学习系统依赖于通常由于噪声而不太可靠的物联网来源的数据，因此它们容易积累技术债务。这也可能由于对其他上游数据不一致的依赖而发生。例如，考虑以下情况：

  • 如果任何特征（或几个特征）的组成发生实质性变化，它将导致模型在现实世界中的行为不同。这个问题也被称为训练-服务偏差，即你在训练和服务管道中处理数据的方式存在差异。

  • 机器学习工作负载与传统 IT 系统不同的原因是，只有通过在单元测试中使用小样本的真实数据，才能确定其行为。

因此，监控模型的准确性、根据收集到的数据知识迭代优化并重新部署是关键。

实践机器学习架构

在本节中，你将在一个连接的 HBS 节点上部署一个解决方案，这将要求你在云端构建和训练机器学习模型，然后将它们部署到边缘进行推理。以下截图显示了实验室的架构，其中突出显示了你需要完成的步骤（1-5）：

图 7.17 – 实践机器学习架构

你的目标包括以下内容，这些内容在先前的架构中以不同的步骤突出显示：

• 使用 Amazon SageMaker 构建机器学习工作流程

• 使用 AWS IoT Greengrass 将机器学习模型从云端部署到边缘

• 在边缘执行机器学习推理并可视化结果

以下表格显示了你在实验室中将要使用的组件列表：

图 7.18 – 实践实验室组件

构建机器学习工作流程

在本节中，你将使用 Amazon SageMaker Studio 构建、训练和测试机器学习模型。

注意

使用 Amazon SageMaker 训练模型将产生额外的成本。如果你想要节省这部分成本，请使用 GitHub 上为你平台提供的已训练机器学习模型，并跳到下一节，即从云端部署模型到边缘。

Amazon Sagemaker Studio 是一个基于 Web 的集成开发环境（IDE），它为数据科学家（或 ML 工程师）提供了一个一站式商店，用于所有 ML 相关事务。为了训练模型，你将使用 Caltech 提供的公共数据集，该数据集包含 256 个物体类别中超过 30,000 张图片。让我们开始。按照以下步骤操作：

1. 请导航到Amazon SageMaker控制台，并从左侧面板选择SageMaker Domain Studio。如果你第一次与工作室交互，你将需要完成一次性的设置。请选择快速设置，点击提交，选择默认 VPC 及其子网（s），然后点击保存并继续。

2. 设置工作室需要几分钟时间。请等待状态显示为Ready，然后点击启动应用 -> 工作室。

3. 这应该会为你打开 SageMaker Studio（也称为 Jupyter 控制台）。如果你是 Jupyter 的新手，可以将它视为类似于 Eclipse、Visual Studio 等用于开发分布式应用的 IDE。

4. 请使用左上角的上传文件按钮，从chapter7/notebook文件夹上传Image-Classification*.ipynb和synset.txt文件。

5. 双击打开 Jupyter 笔记本，并选择 Python 运行时和内核，如下面的截图所示：![图 7.19 – Jupyter 笔记本内核

   图 7.19 – Jupyter 笔记本内核

6. 选择内核是一个关键步骤，因为它为你提供了训练 ML 模型所需的适当运行时。更新内核（右上角）以选择用于训练 ML 模型的 GPU 运行时。由于你将处理图像，因此 GPU 运行时更合适。选择内核后，Jupyter 笔记本将具有以下内核和配置：![图 7.20 – 选择内核

   图 7.20 – 选择内核

7. 现在，请慢慢浏览代码。请确保阅读代码前的文本，以便更好地理解每个这些块的功能。

8. 点击与代码块相邻的*)。星号表示代码仍在运行。请在继续之前等待它消失：![图 7.21 – 运行步骤

   图 7.21 – 运行步骤

9. 如果你完成所有步骤直到最后，你将能够完成以下步骤：

   1. 下载训练数据集

   2. 准备和预处理数据

   3. 将数据集拆分为训练样本和测试样本

   4. 使用适当的框架和参数训练模型

   5. 优化边缘硬件上的模型

   6. 在 Amazon S3 存储库上托管模型工件

   模型训练可能需要 10 分钟才能完成。训练完成后，你将拥有一个使用 MXNet 框架训练的 ML 模型，该模型能够对 256 个不同的物体进行分类。

10. 请导航到 S3 存储桶（sagemaker-<region>-<accountid>/ic-fulltraining/）。复制 S3 的DLR-resnet50-*-cpu-ImageClassification.zip文件，因为您将在下一节中使用它。

现在模型已经在云端训练，您将使用 Greengrass 将其部署到边缘进行近实时推理。

从云端到边缘部署模型

作为物联网从业者，将模型从云端部署到边缘是您将主要参与的步骤。这是过渡点，ML 或数据科学团队提供了一个需要推送到边缘设备集群的模型。虽然在现实世界中可以使用**持续集成/持续部署（CI/CD）**管道自动化这些步骤，但您将手动进行以详细了解该过程。

与您在前面章节中创建的用于在边缘部署不同过程（如发布者、订阅者、聚合器）的组件类似，部署 ML 资源需要相同的方法。我们将创建一个包含在上一节中训练的 ML 模型的组件。我们将继续使用 AWS 控制台以保持一致性。

注意

Greengrass 提供了一个示例图像分类模型组件，您在第四章，“将云扩展到边缘”中已经尝试过。在这里，您正在学习如何使用您自定义的资源修改现有的模型组件。在现实世界中，您甚至可能需要从头开始创建一个新的模型组件，您可以遵循类似的过程。

让我们开始。按照以下步骤进行：

1. 请导航到chapter7/recipe文件夹。现在，让我们更新食谱以指向训练好的模型。请将 URI（带有箭头标记）替换为在构建 ML 工作流部分的步骤 10中复制的 S3 URI，如图中所示。如果您跳过了前面的部分并使用了 GitHub 上的训练模型，请手动将模型上传到您选择的 S3 存储桶，并相应地更新食谱中的 S3 URI：

   图 7.22 – 配置食谱

2. 点击创建组件以完成模型资源的创建。此模型应出现在组件页面上的我的组件标签页中。

3. 现在，您需要创建一个推理组件。这是触发边缘上的模型并发布结果到云的资源。

   注意

   Greengrass 提供了一个示例图像分类推理组件，aws.greengrass.DLRImageClassification，您已经在第四章，“将云扩展到边缘”中尝试过。在这里，您正在学习如何使用相同的推理组件与您的自定义机器学习模型一起工作。在现实世界中，您可能需要创建一个新的推理组件，从头开始，并使用修改后的清单文件，就像您刚才对模型所做的那样。

4. 在 variant.DLR.ImageClassification.ModelStore：通过 SageMaker 训练的机器学习模型。您可以从 aws.greengrass.DLRImageClassification 中选择此选项：机器学习模型的推理脚本。您可以从 variant.DLR 中选择此选项：机器学习推理所需的运行时。您可以从 公共组件 选项卡中选择此选项。

5. 在 选择组件 页面上，确保选择了以下屏幕截图所示的组件，然后点击 下一步：![图 7.23 – Greengrass 组件依赖关系

   图 7.23 – Greengrass 组件依赖关系

6. 在 aws.greengrass.DLRImageClassification 组件上。这将启用 配置组件 选项；点击它。

7. 使用以下配置更新 合并配置 部分（右侧面板）并点击 确认：

   {
     "InferenceInterval": "5"
   }
   

8. 在以下屏幕中保持所有其他选项为默认设置，并选择 部署。

现在，让我们继续下一节。

在边缘执行机器学习推理并验证结果

因此，到目前为止，模型已在 Greengrass 上构建、训练和部署。要推理的图像存储在以下目录中：

图 7.24 – Greengrass 中心上的图像目录

与猫图像类似，您还可以部署其他图像（如狗、人类等），并配置推理组件对它们进行推理。

让我们可视化从边缘发布到云端的推理结果。这些结果对于评估模型是否在预期的准确率水平上运行至关重要。我们将按以下步骤进行：

1. 首先，让我们检查组件状态是否显示为正在运行，并检查 Greengrass 日志以验证没有异常。我们将需要以下代码来完成此操作：

   sudo /greengrass/v2/bin/greengrass-cli component list
   sudo tail -100f /greengrass/v2/logs/greengrass.log
   sudo tail -100f aws.greengrass.DLRImageClassification.log
   

2. 如果没有错误，请导航到 AWS IoT 控制台，选择 测试，然后选择 MQTT 测试客户端。

3. 在 ml/dlr/image-classification 下。点击 订阅 查看结果，结果应该看起来像这样：

![图 7.25 – 机器学习推理结果

图 7.25 – 机器学习推理结果

如果您遇到困难或需要帮助，请参阅 GitHub 中的 故障排除 部分。

恭喜您完成本章的动手实践部分！现在，您的连接 HBS 中心 已配备机器学习能力，可以在在线和离线条件下运行，并能在您的停车位区域内对人类、宠物和车辆进行分类。

挑战区域（可选）

您能想出如何对发布到 AWS IoT Core 的推理结果采取行动吗？这将有助于自动通过通知/警报触发公告，以警告在停车位区域内散步的孩子们/宠物。

提示：您需要在 IoT 规则引擎中定义路由逻辑，以便通过通知服务推送结果。

现在你已经学会了如何在边缘为物联网工作负载构建机器学习能力，这不是很神奇吗？现在是时候好好休息一下了！让我们通过快速总结和一系列问题来结束这一章。

摘要

在本章中，你了解了与物联网工作负载相关的机器学习概念。你学习了如何设计机器学习管道，以及针对物联网工作负载优化模型。你实现了边缘到云的架构，以对非结构化数据（图像）进行推理。最后，你通过可视化边缘的推理结果来验证工作流程，以获得更多见解。

在下一章中，你将学习如何实施 DevOps 和 MLOps 实践，以实现大规模部署的物联网边缘工作负载的运营效率。

知识检查

在进入下一章之前，通过回答以下问题来测试你的知识。答案可以在书的末尾找到：

1. 判断对错：存在两种类型的机器学习算法：监督学习和无监督学习。

2. 你能回忆起四种机器学习系统的类型及其重要性吗？

3. 判断对错：K-means 是一种分类算法。

4. 你能将机器学习项目生命周期的三个阶段按正确顺序排列吗？

5. 你能想到至少两种用于训练机器学习模型的常用框架吗？

6. 用于将训练好的模型从云端部署到边缘的 AWS 服务是什么？

7. 判断对错：AWS IoT Greengrass 只支持用于图像分类问题的自定义组件。

8. 你能告诉我关于机器学习与物联网工作负载的一个反模式吗？

参考文献

查看以下资源，以获取本章讨论的概念的更多信息：

• CRISP: www.datascience-pm.com/crisp-dm-2/

• 机器学习简史：www.forbes.com/sites/bernardmarr/2016/02/19/a-short-history-of-machine-learning-every-manager-should-read/?sh=1ca6cea115e7

• AWS 上的机器学习：aws.amazon.com/machine-learning/

• 机器学习与 AWS 物联网服务：aws.amazon.com/blogs/iot/category/artificial-intelligence/sagemaker/

• 使用 AWS IoT Greengrass 版本 2 与 Amazon SageMaker Neo 和 NVIDIA DeepStream 应用程序：aws.amazon.com/blogs/iot/using-aws-iot-greengrass-version-2-with-amazon-sagemaker-neo-and-nvidia-deepstream-applications/

• 机器学习架构框架：docs.aws.amazon.com/wellarchitected/latest/machine-learning-lens/machine-learning-lens.html

• 通过机器学习大学（MLU）学习 AWS：aws.amazon.com/machine-learning/mlu/

第三部分：扩大规模

在本节中，你将学习如何大规模地配置物联网车队，并使用 DevOps 实践通过不同的良好架构实践来构建敏捷且操作高效的物联网工作负载。

本节包括以下章节：

• 第八章*，边缘的 DevOps 和 MLOps*

• 第九章*，大规模车队管理*

第八章：第八章：边缘的 DevOps 和 MLOps

21 世纪的连接设备激增改变了我们的生活方式。很难回忆起没有智能手机、智能手表、个人数字助理（如亚马逊 Alexa）、联网汽车、智能恒温器或其他设备的便利日子。

这种采用趋势不会很快放缓，因为行业预测，在未来几年内，全球将有超过 250 亿个物联网设备。随着连接技术的普及，新的常态是设备始终处于开启状态。换句话说，设备应该始终工作。不仅如此，我们还期望这些设备在其生命周期内持续变得更智能，并通过新功能、增强或错误修复保持安全。但如何可靠且大规模地实现这一点呢？亚马逊首席技术官和副总裁 Werner Vogels 经常说，“一切都会时常出问题。”保持任何技术解决方案始终运行是一个挑战。

在物联网领域，由于边缘设备部署在多样的操作条件下，易受环境干扰，并且具有多层连接性、通信和延迟，这些挑战变得更加严重和复杂。因此，构建边缘到云的连续机制，以收集已部署的边缘设备队伍的反馈并迅速采取行动，至关重要。这正是 DevOps 在物联网中发挥作用的地方。DevOps是开发和运营的缩写。它促进了一种敏捷的方法，从云到边缘执行持续集成和持续部署（CI/CD）。

在本章中，我们将重点关注如何利用 DevOps 能力来处理物联网工作负载。我们还将扩展我们的讨论范围至边缘的MLOps，这意味着为机器学习（ML）工作负载实施敏捷实践。在您构建 ML 管道时，您已经在上一章中学习了这些概念的一些内容。本章的重点将是高效地部署和运行这些模型。

您已经熟悉在边缘开发本地流程或以解耦方式从云中部署组件。在本章中，我们将解释如何使用 DevOps 原则将这些部分拼接在一起，这将有助于自动化一队边缘设备的开发、集成和部署工作流程。这将使您能够高效地运营边缘的智能分布式架构（即 Greengrass 启用的设备），并帮助您的组织更快地将不同产品和服务推向市场。

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

• 定义物联网工作负载的 DevOps

• 在边缘执行 MLOps

• 在边缘部署容器的实践操作

• 检查您的知识

技术要求

• 本章的技术要求与在第二章中概述的要求相同，即边缘工作负载基础。完整的详细要求请参阅该章节。

现在，让我们深入本章内容。

定义针对物联网工作负载的 DevOps

DevOps 改变了当今世界公司开展业务的方式。例如，亚马逊、Netflix、谷歌和 Facebook 每周进行数百次或更多部署，以推送不同的功能、增强或错误修复。对于最终用户来说，这些部署通常是透明的，因为他们不会因为这些持续的部署而经历任何停机时间。

DevOps 是一种方法，它通过缩短开发周期和增加发布频率，使开发者和运维人员更接近，从而在更短的时间内实现可量化的技术和商业效益。一个常见的误解是，DevOps 只是一套用于更快构建和交付软件的新技术。DevOps 还代表了一种文化转变，旨在促进不同团队之间的所有权、协作和凝聚力，以促进组织内的创新。DevOps 已被各种规模的组织和企业采用，以针对分布式工作负载更快地提供创新、增强和运营效率。以下图表显示了软件交付的良性循环：

图 8.1 – 软件交付的良性循环

为了简洁起见，我们在此不会深入探讨 DevOps 或敏捷实践的概念。相反，我们将专注于介绍围绕 DevOps 的高级概念，并讨论其对物联网工作负载的相关性。

DevOps 基础

DevOps 将不同的工具和最佳实践结合在一起，如下所示：

• 共享代码库：在代码开发领域，使用版本控制系统是前提和最佳实践。部署包中所需的所有工件都需要存储在这里。例如，包括Bitbucket、Gitlab和AWS CodeCommit。

• 持续集成（CI）：在这一步中，开发者会定期在代码库中提交代码更改。每次提交都会触发一个自动构建过程，该过程执行代码扫描、代码审查、编译和自动单元测试。这允许开发者快速识别和修复错误，使他们能够遵守最佳实践并更快地交付功能。此过程的结果包括符合组织强制执行的实践的构建工件（如二进制文件或可执行程序）。工具链的例子包括Jenkins、Bamboo、GitLab CI和AWS CodePipeline。对于物联网工作负载，可以使用类似的工具链。

• 持续交付（CD）：这一步在 CI 的先前步骤上进行了扩展，将所有编译的二进制文件部署到预发布或测试环境。一旦部署，与集成、功能或非功能性要求相关的自动化测试作为工作流程的一部分执行。测试工具链的例子包括JMeter、Selenium、Jenkins和Cucumber。这允许开发者彻底测试更改，并在整体应用程序的上下文中预先发现问题。最后一步是将验证过的代码工件部署到生产环境（无论是否有手动批准）。

• 持续监控（CM）：DevOps 的核心目标是消除开发和运维团队之间的隔阂。因此，如果您希望有一个持续的反馈循环来观察、警报和缓解与基础设施或托管应用程序相关的问题，CM 是一个关键步骤，如下面的图所示：

图 8.2 – DevOps 生命周期

常见的监控工具链包括Amazon CloudWatch、Amazon X-Ray、Splunk和New Relic。

• 基础设施即代码（IaC）：遵循 CI/CD 的软件开发实践以加快代码的发布是一个很好的第一步，但这还不够。团队可以使用敏捷流程开发和测试他们的代码，但最终交付到生产环境仍然遵循瀑布方法。这通常是由于缺乏对动态配置或扩展基础设施的控制。传统上，组织将会有系统管理员手动配置所需的基础设施资源，这可能需要几天、几周或几个月。这就是 IaC 发挥作用的地方，因为它允许您使用代码（或 API）以自动化的方式配置和管理基础设施、配置和策略，而不需要任何可能存在错误或耗时的手动干预。常见的工具链包括Amazon CloudFormation、HashiCorp Terraform和Ansible。

现在我们已经涵盖了 DevOps 的基础知识，让我们了解其与物联网和边缘的相关性。

DevOps 对物联网和边缘的相关性

从简单的射频识别系统到今天的微控制器和微处理器的边缘计算演变，为需要在边缘构建分布式架构的行业细分市场打开了不同的用例。例如，连接的 HBS 中心具有以下多样化的功能：

• 后端传感器/执行器的网关

• 本地组件的运行时间

• 连接到云的接口

• 消息代理

• 数据流处理器

• 机器学习推理引擎

• 容器编排器

边缘的工作量很大！因此，传统的开发和交付嵌入式软件的方式已经不再可持续。那么，让我们讨论物联网设备生命周期中的核心活动，如图表所示，以了解 DevOps 的相关性：

图 8.3 – DevOps 在物联网工作负载中的相关性

DevOps 的关键组件，如 CI/CD/CM，对于物联网工作负载同样相关。这组活动通常被称为 EdgeOps，正如我们之前观察到的，它们在边缘和云之间应用方式不同。例如，由于我们需要在部署在世界的相同硬件上测试设备软件，因此边缘的 CI 是不同的。然而，由于边缘部署相关的成本和风险较高，降低边缘设备更新的频率是常见的。组织通常拥有不同的硬件集，用于原型设计和生产运行时。

DevOps 在物联网工作负载中的挑战

现在你已经了解了如何将 DevOps 阶段映射到不同的物联网活动，让我们更深入地探讨一下。以下图表展示了设备生命周期中通常涉及的工作流程，从其创建到退役：

图 8.4 – 物联网的 DevOps 工作流程

在这里，你可以看到物联网工作负载与其他云托管工作负载之间的关键差异。让我们看看。

制造过程涉及：

分布式工作负载，如 Web 应用程序、数据库和 API，使用云平台提供的底层基础设施。软件开发者可以使用 IaC 实践，并将它们与其他 CI/CD 机制集成，以提供自动所需的云资源来托管他们的工作负载。对于边缘工作负载，产品超越了任何数据中心边界。虽然在测试或原型阶段可以在云平台提供的虚拟基础设施上运行边缘应用程序，但实际产品始终托管在硬件上（例如，本书项目中的 Raspberry Pi）。在供应链中，始终依赖于合同制造商（或其他供应商）根据编程设备固件所需的规格进行硬件制造。尽管可以使用 DevOps 实践在云上开发固件，但固件映像的烧录仅在制造时间进行。这阻碍了在传统 DevOps 工作流程中常见的端到端自动化，其中基础设施（如 AWS EC2 实例）可以轻松镜像并可用于应用程序部署。以下图表展示了设备制造和分发的典型生命周期：

图 8.5 – 物联网设备制造过程

确保硬件安全至关重要：

开放网络应用安全项目（OWASP）列出的边缘工作负载的一些关键漏洞如下：

• 弱、可猜测或硬编码的密码

• 缺乏物理加固

• 不安全的数据传输和存储

• 不安全默认设置

• 不安全生态系统接口

尽管分布式工作负载可能面临相似的挑战，但使用云原生控制措施来缓解这些挑战，使得它们比物联网工作负载更容易自动化。以 AWS 为例，AWS 基础设施内部的所有通信（例如跨数据中心）默认都是加密传输的，无需采取任何行动。静态数据可以通过一键选项（或自动化）使用 AWS 提供的密钥管理基础设施进行加密（或客户可以自行提供）。每个服务（或托管工作负载）都需要通过云原生身份与访问管理服务启用访问控制以进行身份验证和授权，这些也可以通过 IaC 实施自动化。每个服务（或托管工作负载）都可以利用云原生监控服务（如Amazon CloudTrail或Amazon CloudWatch）提供的可观察性和可追溯性。

相反，对于边缘工作负载，所有上述要求都必须在制造、组装和注册设备时得到满足，从而给供应链带来更大的压力，手动执行这些操作，而不是一键或自动化工作流程。例如，作为最佳实践，边缘设备应使用 X.509 证书等凭证通过 TLS1.2 与云进行相互认证，而不是使用用户名和密码或对称凭证。此外，凭证应通过正确的权限集（通过策略）实现最小权限访问，这有助于确保设备正在实施所需的访问控制以保护设备身份，并且传输中的数据得到完全加密。此外，边缘上的设备凭证（如 X.509 证书）必须位于安全元素或可信平台模块（TPM）内部，以降低未经授权访问和身份泄露的风险。此外，还需要安全的机制来分离设备上的文件系统，并使用不同的加密工具（如dm-crypt、GPG和Bitlocker）加密静态数据。不同边缘组件的可观察性和可追溯性实现留给各自的拥有者。

缺乏边缘标准化的框架：

边缘组件不再局限于路由器、交换机、微型服务器或工作站。相反，行业正在以不同的方式向边缘构建分布式架构，如下所示：

• 雾计算，它允许我们使用异构节点的分布式计算基础设施将更多智能转移到边缘

• 移动/多接入计算（MEC），通过整合下一代无线电频谱（如 5G）来使边缘可能的新一代工作负载成为可能

• 数据中心即盒子，通过云集成在边缘实现资源密集型计算能力

下面的图示显示了包含分布式架构中常见各种技术能力的边缘到云工作流程：

图 8.6 – 边缘到云架构

边缘架构的标准仍在不断发展。考虑到存在不同的连接接口、通信协议和拓扑结构，解决不同用例的方式也各不相同。例如，连接接口可能包括不同的短距离（如BLE、Wi-Fi和Ethernet）或长距离无线网络（如蜂窝、NB-IoT和LoRa）。所使用的连接接口需要在硬件设计阶段确定，并作为一个一次性过程实现。通信协议可能包括 TCP（面向连接，如MQTT和HTTPS）或 UDP（无连接，如CoAP）。回想一下我们在第二章“边缘工作负载的基础”中回顾的开放系统互联（OSI）模型的层级，通信接口的选择可以灵活，只要底层第 4 层协议在硬件上得到支持。例如，如果硬件支持 UDP，可以通过配置更改激活它，并根据需要安装额外的第 7 层软件（如 COAP 客户端）。因此，这一步可以通过云到边缘的 DevOps 工作流程（即 OTA 更新）来完成。将更多智能带到边缘需要处理在低功耗计算基础设施上运行分布式拓扑结构所带来的挑战。因此，有必要定义标准和设计原则，以设计、部署和运营边缘优化的软件工作负载（如代理、微服务、容器、缓存和轻量级数据库）。

希望这能帮助你从 DevOps 的角度理解边缘工作负载的独特挑战。在下一节中，你将了解 AWS IoT Greengrass 如何帮助你构建和运营边缘的分布式工作负载。

理解边缘的 DevOps 工具链

在前面的章节中，你学习了如何在边缘本地开发和部署原生进程、数据流和机器学习模型，然后使用Greengrass 的内置 OTA 机制进行大规模部署。在这里，我们将解释相反的方法；即在云中使用 DevOps 实践构建分布式应用程序，并将它们部署到边缘。以下图表显示了使用OTA更新机制持续构建、测试、集成和部署工作负载的方法：

图 8.7 – 边缘应用的 CI/CD 视图

在 AWS IoT Greengrass 上构建边缘分布式架构的两种最常见方式是通过使用 AWS Lambda 服务或 Docker 容器。

AWS IoT Greengrass 上的 AWS Lambda

我要明确指出，为了避免任何混淆，第五章中引入的 Lambda 设计概念，从边缘摄取和流式传输数据，是一种用于在边缘操作流式和批处理工作流程的架构模式。AWS Lambda则相反，是一种无服务器计算服务，提供执行任何类型应用程序的运行时，无需管理。它允许开发者专注于业务逻辑，用不同的编程语言（如C、C++、Java、Node.js和Go）编写代码，并将其作为 ZIP 文件上传。服务从那里开始配置底层基础设施的资源，并根据传入的请求或事件进行扩展。

AWS Lambda 在设计基于事件的架构以进行实时处理、批处理和 API 驱动的工作负载时，一直是一种流行的计算选择。因此，AWS 决定通过Amazon IoT Greengrass扩展 Lambda 运行时对边缘处理的支持。

那么，你在想 AWS Lambda 在边缘实施的价值是什么吗？

你并不孤单！考虑到在边缘进行自动硬件配置不是一种选择，正如本章前面所解释的，这里的价值在于从云到边缘的互操作性、一致性和连续性。对于物联网工作负载来说，云（分布式栈）和边缘（嵌入式栈）有不同的代码库是很常见的，这导致了代码集成、测试和部署方面的额外复杂性。这导致了额外的运营开销和市场延迟时间。

AWS Lambda 旨在弥合这一差距，以便云和嵌入式开发者可以使用类似的技术栈进行软件开发，并拥有互操作性解决方案。因此，使用通用工具链从云到边缘构建 DevOps 管道变得可行。

AWS IoT Greengrass 上 AWS Lambda 的优势

在边缘运行 Lambda 函数有几个好处，如下所述：

• 部署在边缘设备本地的 Lambda 函数可以连接到不同的物理接口，如 CANBus、Modbus 或以太网，以访问硬件上的不同串行端口或 GPIO，类似于嵌入式应用程序。

• Lambda 函数可以在 AWS IoT Greengrass 和云资源之间充当不同边缘组件（如流管理器）之间的粘合剂。

• AWS IoT Greengrass 通过使用别名或特定版本为边缘提供 Lambda 函数，使部署不同版本的 Lambda 函数变得更加容易。这有助于持续交付，并在蓝/绿部署等场景中很有用。

• 细粒度访问控制，包括为不同的本地资源（如磁盘卷、串行端口或 GPIO）指定配置（以 root 运行）或权限（读取/写入），可以用于管理 Lambda 函数。

• Lambda 函数可以在容器化和非容器化模式下运行。非容器化模式移除了抽象层，允许 Lambda 作为常规进程在操作系统上运行。这对于对延迟敏感的应用程序（如机器学习推理）很有用。

• 最后，AWS IoT Greengrass 允许你管理边缘上 Lambda 函数可以使用的硬件资源（RAM）。

以下图表展示了已部署在边缘的 AWS Lambda 函数如何与物理层（如文件系统）或抽象层（如 AWS IoT Greengrass 上的流管理器）的不同组件进行交互：

![Figure 8.8 – Lambda interactions on the edge]

![img/B17595_08_08.jpg]

图 8.8 – Lambda 在边缘的交互

在这里，你可以看到 Lambda 提供了一些独特的价值主张，这些价值主张你需要通过本地进程自行构建。

Lambda 在边缘的挑战

如你现在所理解的，每个解决方案或架构都有其权衡之处。AWS Lambda 也不例外，可能面临以下挑战：

• 与本地进程相比，Lambda 函数可能更占用资源。这是因为它们需要额外的库。

• Lambda 函数仅适用于 AWS。因此，如果你正在寻找一个云无关的边缘解决方案（以减轻供应商锁定问题），你可能需要坚持使用本地进程或 Docker 容器。尽管 Greengrass v2 作为边缘软件是开源的，但 AWS Lambda 函数不是。

现在，让我们了解边缘的容器。

边缘容器

容器是一个软件单元，它将应用程序运行所需的所有代码及其依赖项打包在一起，以便在不同的计算环境中可靠地运行。本质上，容器为其托管应用程序提供了一个抽象层，从底层的 OS（例如 Ubuntu、Linux 或 Windows）或 架构（例如 x86 或 ARM）中分离出来。此外，由于容器轻量级，单个服务器或虚拟机可以运行多个容器。例如，您可以使用各自的容器镜像在同一服务器（或 VM）上运行一个 3 层架构（Web、应用和数据库）。最流行的两个开源容器管理框架是 Docker 和 Kubernetes。

在本节中，我们将主要讨论 Docker，因为它是 AWS IoT Greengrass 在编写时唯一原生支持的选项。与 Lambda 类似，Docker 支持一系列编程语言和工具链，以便开发者以敏捷的方式开发、操作和部署他们的应用程序。以下图示展示了基于 Docker 的工作负载在 AWS IoT Greengrass 上的参考架构：

图 8.9 – Docker 抽象层

那么，为什么在边缘使用 Lambda 运行容器呢？

容器可以带来 Lambda 所有的好处（以及更多），同时具有异构性（不同的平台）、开源和针对边缘资源进行了更好的优化。容器还有一个更广泛的开发者社区。由于容器具有编排和抽象层，它不依赖于其他运行时，如 AWS IoT Greengrass。因此，如果您的组织决定迁移到另一个边缘解决方案，容器比 Lambda 函数更易于移植。

AWS IoT Greengrass 上 Docker 容器的优势

使用 Greengrass 在边缘运行容器有以下优势：

• 开发者可以继续使用他们现有的 CI/CD 管道，并将工件（即 Docker 镜像）存储在不同的代码仓库中，例如 Amazon Elastic Container Registry （ECR），公共 Docker Hub，公共 Docker Trusted Registry 或 S3 桶。

• Greengrass 简化了向边缘部署的过程，唯一的依赖是拥有 aws.greengrass.DockerApplicationManager，它使 Greengrass 能够管理凭证并从支持的仓库下载镜像。

• Greengrass 为 Docker 工具提供了第一级支持，例如 docker-compose、docker run 和 docker load，所有这些都可以作为组件配方文件中的依赖项包含，也可以单独用于测试或监控目的。

• 最后，Greengrass 还支持基于 Docker 的应用程序和其他组件之间的进程间通信。

以下图示展示了如何使用 CI/CD 方法开发容器化应用程序，并在运行 AWS IoT Greengrass 的同时部署到边缘：

图 8.10 – Docker 工作负载的 CI/CD 方法

接下来，让我们了解边缘 Docker 的挑战。

边缘 Docker 的挑战

在边缘运行容器有一些权衡需要考虑，如下所示：

• 在边缘大规模管理容器会带来更多的运营开销，因为它可能会变得复杂。因此，它需要仔细的设计、规划和监控。

• 当您使用私有和公共 Docker 镜像构建复杂的边缘应用程序时，您也在增加攻击面。因此，始终遵守各种运营和安全最佳实践至关重要。

• 除了 AWS IoT Greengrass 特定的更新外，您还需要为 Docker 特定的实用程序制定补丁和维护程序，这反过来又增加了运营开销和网络费用。

• 对于对延迟敏感的使用案例，可能不适合使用容器增加抽象层。例如，在 GPU 上执行时间敏感的机器学习推理，如通过计算机视觉检测家庭入侵，可能作为容器上的原生进程运行得更好。

在本章的实验室部分，您将通过使用 AWS IoT Greengrass 将基于 Docker 的应用程序部署到边缘来亲自动手。

Greengrass 部署的附加工具集

与其他 AWS 服务类似，AWS IoT Greengrass 也支持与各种 IaC 解决方案集成，例如CloudFormation、CDK和Terraform。所有这些工具都可以帮助您创建基于云的资源，并集成到不同的 CI/CD 管道中，以支持云到边缘的部署。

现在您已经熟悉了 DevOps 工具链的益处和权衡，让我们学习它是如何扩展到机器学习的。

边缘 MLOps

机器学习运营（MLOps）旨在将敏捷方法集成到运行机器学习工作负载的端到端流程中。MLOps 将数据科学、数据工程和 DevOps 的最佳实践结合在一起，以简化模型设计、开发和交付，贯穿机器学习开发生命周期（MLDLC）。

根据 MLOps特别兴趣小组（SIG）的定义，MLOps 被定义为“将 DevOps 方法扩展到包括机器学习和数据科学资产作为 DevOps 生态系统中的一等公民。”MLOps 在过去几年中从机器学习从业者那里获得了快速发展，并且是一种语言、框架、平台和基础设施无关的实践。

以下图表显示了 MLDLC 的良性循环：

图 8.11 – MLOps 工作流程

上一张图显示了操作是 ML 工作流程的基本模块。我们在第七章，边缘的机器学习工作负载中介绍了一些 ML 设计和开发的概念，因此在本节中，我们将主要关注操作层。

MLOps 有以下几个好处：

• 高效性：数据、ML 工程师和数据科学家可以使用自助环境，通过精选数据集和集成 ML 工具更快地迭代。

• 可重复性：类似于 DevOps，将自动化引入 ML 开发生命周期的各个方面（即 MLDC）可以减少人为错误并提高效率。MLOps 有助于确保可重复的过程，以帮助版本控制、构建、训练、部署和操作 ML 模型。

• 可靠性：将 CI/CD 实践纳入 MLDC 增加了部署的质量和一致性。

• 可审计性：启用所有输入和输出的版本控制功能，从源数据到训练好的模型，允许对 ML 工作负载进行端到端的可追溯性和可观察性。

• 治理：实施治理实践以强制执行政策有助于防止模型偏差并跟踪数据血缘和模型质量随时间的变化。

现在，您已经了解了 MLOps 是什么，您是否好奇它如何与物联网和边缘计算相关？让我们来看看。

MLOps 在物联网和边缘计算中的相关性

作为物联网/边缘领域的专家，您将不会拥有 MLOps 流程。相反，您需要确保边缘（在硬件和软件层）满足依赖关系，以便 ML 工程师能够履行其设置和维护此工作流程的职责。因此，不要对这一章节的简短感到惊讶，因为我们的目标只是向您介绍基本概念和今天在 AWS 上为此主题领域提供的关联服务。我们希望让您快速入门，以便您能够与组织中的 ML 实践者进行更好的对话。

因此，有了这个背景，让我们考虑这样一个场景：连接的 HBS 中心传感器正在报告来自不同客户安装的各种异常。这导致了多次技术员呼叫，从而影响了客户体验和底线。因此，您的首席技术官决定使用 ML 模型构建一个预测性维护解决方案，通过远程操作快速识别和修复故障。这些模型应能够动态地识别数据漂移并收集有关报告异常的附加信息。因此，这里 ML 实践者的目标是构建一个 MLOps 工作流程，以便模型可以频繁且自动地在收集到的数据上训练，然后部署到连接的 HBS 中心。

此外，监控部署在边缘的机器学习模型的表现对于理解其效率至关重要；例如，查看产生了多少假阳性。类似于 DevOps 工作流程，机器学习工作流程包括不同的组件，如版本控制的源代码管理、用于 CI/CD 的训练管道、用于模型验证的测试、用于部署的打包以及用于评估效率的监控。如果这个项目成功，它将帮助公司向边缘添加更多机器学习智能，并预测性地减轻问题以改善客户体验并降低成本。以下参考架构展示了一个我们可以用于在 AWS IoT Greengrass v2 上实现机器学习模型预测性维护的工作流程：

![图 8.12 – HBS 传感器的预测性维护

图 8.12 – HBS 传感器的预测性维护

如果我们要实现前面的架构，我们必须尝试预见一些常见的挑战。

边缘的 MLOps 挑战

很常见，边缘和机器学习从业者关于 MLOps 最常问的问题如下：

• 我该如何大规模准备和部署机器学习模型到边缘设备？

• 一旦模型在边缘部署，我该如何确保模型（作为知识产权）的安全？

• 我该如何监控边缘运行的机器学习模型，并在需要时重新训练它们？

• 我该如何消除安装资源密集型运行时（如 TensorFlow 和 PyTorch）的需求？

• 我该如何使用标准接口将一个或多个模型与我的边缘应用程序接口？

• 我该如何自动化所有这些任务，以便有一个可重复、高效的机制？

这不是一个详尽的列表，因为它随着机器学习在边缘的采用而不断扩展。对一些问题的答案是一个组织内部文化和技术转变的混合。让我们看看一些例子：

• 沟通是关键：为了使 MLOps 产生预期的结果，跨不同利益相关者的沟通和协作是关键。考虑到机器学习项目涉及与算法和数学模型相关的技术不同维度，机器学习从业者通常说的技术语言与传统的 IT（或物联网）人员不同。

  因此，成为一个机器学习组织需要时间、培训和跨不同团队的合作练习，以产生有成效的结果。

• 解耦和重新耦合：机器学习模型的生命周期通常独立于其他分布式系统。这种解耦使得机器学习从业者可以专注于构建他们的应用程序，而不会被其他事情分散注意力。

  同时，尽管如此，机器学习工作流程有一定的依赖性，例如对大数据工作流程或推理所需的应用的依赖。这意味着 MLOps 是传统 CI/CD 工作流程和另一个工作流程引擎的组合。如果没有健壮的管道和所需的工具集，这往往变得很棘手。

• 部署可能很棘手：根据 Algorithmia 的报告，《2020 年企业机器学习现状》，"弥合机器学习模型构建与实际部署之间的差距是一项具有挑战性的任务"。在笔记本电脑或云环境中在 Jupyter 笔记本上构建 ML 模型与将该模型部署到生成价值的生产系统之间存在根本性的区别。

  在物联网中，这个问题充当了乘数效应，因为部署 ML 模型之前，需要考虑针对不同硬件和运行时的各种优化策略。例如，在第七章，“边缘机器学习工作负载”，你学习了如何使用Amazon SageMaker Neo优化 ML 模型，以便在您的环境中高效运行。

• 环境很重要：ML 模型可能需要在离线条件下运行，因此更容易受到不断变化的环境中的数据漂移的影响。例如，想象一下由于自然灾害导致你的家庭停电或断水的情况。因此，你的设备，如 HVAC 或水泵，会以异常的方式运行，导致本地部署的模型数据漂移。因此，你的本地部署的 ML 模型需要足够智能，能够处理意外场景中的不同误报。

在本节中，我们探讨了边缘的 MLOps 挑战。在下一节中，我们将了解边缘的 MLOps 工具链。

理解边缘的 MLOps 工具链

在第七章，“边缘机器学习工作负载”中，你学习了如何使用 Amazon SageMaker 开发 ML 模型，通过 SageMaker Neo 进行优化，并使用 AWS IoT Greengrass v2 在边缘部署它们。在本章中，我想向你介绍 SageMaker 家族中的另一个服务，称为Edge Manager，它可以帮助解决一些先前的 MLOps 挑战，并提供以下即插即用的功能：

• 能够从云端到边缘设备自动化构建-训练-部署工作流程，并跟踪每个模型的整个生命周期。

• 自动优化 ML 模型，以便在由 CPU、GPU 和嵌入式 ML 加速器供电的广泛边缘设备上部署。

• 支持从不同的框架（如DarkNet、Keras、MXNet、PyTorch、TensorFlow、TensorFlow-Lite、ONNX和XGBoost）进行模型编译。

• 支持多模态托管 ML 模型，以及简单的 API 接口，以执行常见的查询，例如在设备上加载、卸载和运行模型推理。

• 支持开源远程过程调用协议（使用gRPC），允许您通过常用编程语言的 API（如Android Java、C#/.NET、Go、Java、Python和C）与现有的边缘应用程序集成。

• 提供仪表板以监控整个车队中不同设备上运行的模型性能。因此，在前面解释的具有连接 HBS 中心的场景中，如果发现与模型漂移、模型质量或预测相关的问题，这些问题可以快速在仪表板中可视化或通过配置的警报报告。

如您所见，Edge Manager 带来了强大的功能，可以开箱即用地管理 MLOps 所需的功能，并带来了与不同 AWS 服务（如 AWS IoT Greengrass）的本地集成。以下是与本书前面介绍的其他服务（如 SageMaker 和 S3）集成的 Edge Manager 的参考架构：

图 8.13 – 边缘管理器参考架构

注意

MLOps 仍在不断发展，如果没有 ML 实践者的参与，实施起来可能会很复杂。如果您想了解更多关于这个主题的信息，请参阅已经出版的其他关于这个主题的书籍。

现在你已经学习了 DevOps 和 MLOps 的基础知识，让我们动手实践，以便我们可以应用一些这些实践，并以敏捷的方式操作边缘工作负载。

实战 DevOps 架构

在本节中，你将学习如何将已经使用云中的 CI/CD 最佳实践开发的多个 Docker 应用程序部署到边缘。这些容器镜像可在名为 Docker Hub 的 Docker 仓库 中找到。以下图表显示了本实战练习的架构，其中你将完成 步骤 1 和 步骤 2 以将 HBS 中心与现有的 CI/CD 管道（由你的 DevOps 组织管理）集成，配置 Docker 容器，然后部署和验证它们，以便它们可以在边缘运行：

图 8.14 – 实战 DevOps 架构

以下是你将在本练习中使用的服务：

图 8.15 – 本练习的服务

本实战部分的你的目标是以下内容：

• 从 Docker Hub 将容器镜像部署到 AWS IoT Greengrass。

• 确认容器正在运行。

让我们开始吧。

从云部署容器到边缘

在本节中，你将学习如何将预构建的容器从云部署到边缘：

1. 导航到您的设备终端并确认 Docker 已安装：

   docker-compose are not installed, please refer to the documentation from Docker for your respective platform to complete this before proceeding.
   

2. 现在，让我们回顾一下 docker-compose 文件。如果您之前没有使用过 docker-compose，请注意，这是一个用于定义和运行多容器应用的实用工具。此工具需要一个名为 docker-compose.yaml 的文件，该文件列出了要安装的应用程序服务的配置细节及其依赖项。

3. 请查阅本章artifacts文件夹中的docker-compose.yaml文件。它包括来自 Docker Hub 的三个容器镜像，分别对应于 Web、应用程序和数据库层：

   services:
     web:
   image: "nginx:latest"
     app:
       image: "hello-world:latest"
     db:
     image: "redis:latest"
   

4. 导航到以下工作目录以审查 Greengrass 配方文件：

   cd ~/hubsub/recipes
   nano com.hbs.hub.Container-1.0.0.yaml
   

5. 注意，这里依赖于 Greengrass 管理的 Docker 应用程序管理器组件。这个组件有助于从相应的仓库检索容器镜像，并执行与安装和管理边缘上容器生命周期相关的 Docker 命令：

   ---
   RecipeFormatVersion: '2020-01-25'
   ComponentName: com.hbs.hub.Container
   ComponentVersion: '1.0.0'
   ComponentDescription: 'A component that uses Docker Compose to run images from Docker Hub.'
   ComponentPublisher: Amazon
   ComponentDependencies:
     aws.greengrass.DockerApplicationManager:
       VersionRequirement: ~2.0.0
   Manifests:
     - Platform:
         os: all
       Lifecycle:
         Startup: 
           RequiresPrivilege: true
           Script: |
             cd {artifacts:path}
             docker-compose up -d
         Shutdown:
           RequiresPrivilege: true
           Script: |
             cd {artifacts:path}
             docker-compose down
   

6. 现在我们有了更新的docker-compose文件和 Greengrass 组件配方，让我们创建一个本地部署：

   sudo /greengrass/v2/bin/greengrass-cli deployment create
   --recipeDir ~/hbshub/recipes --artifactDir
   ~/hbshub/artifacts --merge "com.hbs.hub.Container=1.0.0"
   

7. 使用以下命令验证组件是否已成功部署（并且正在运行）：

   sudo /greengrass/v2/bin/greengrass-cli component list
   

8. 要测试哪些容器目前正在运行，请运行以下命令：

   docker container ls
   

   你应该看到以下输出：

![图 8.16 – 运行中的容器进程

图 8.16 – 运行中的容器进程

在我们这里的例子中，这个应用（hello-world）是一个一次性进程，所以它已经完成了。但剩下的两个容器仍在运行。如果你想检查到目前为止已经运行的所有容器进程，请使用以下命令：

docker ps -a

你应该看到以下输出：

![图 8.17 – 所有容器进程

图 8.17 – 所有容器进程

恭喜你——你现在已经在边缘从 Docker 仓库（Docker Hub）成功部署了多个容器。在现实世界中，如果你想在一个 HBS 中心运行本地 Web 应用程序，这种模式可能很有用。

挑战区域（可选）

你能想出如何从 Amazon ECR 或 Amazon S3 部署 Docker 镜像吗？虽然 Docker Hub 对于存储公共容器镜像很有用，但企业通常会使用私有仓库来存储他们自家的应用程序。

提示：你需要对docker-compose进行更改，使用适当的 URI 来指定容器镜像，并为 Greengrass 角色提供所需的权限。

通过这样，你已经学会了如何从异构源部署任意数量的容器到边缘（只要硬件资源允许），以在边缘开发一个多方面的架构。让我们通过一个快速总结和一些知识检查问题来结束这一章。

摘要

在本章中，你了解了 DevOps 和 MLOps 的概念，这些概念对于在边缘提高物联网和机器学习工作负载的操作效率和敏捷性是必需的。你还学习了如何从云部署容器化应用程序到边缘。这一功能使你能够在 Greengrass 启用的 HBS 中心构建一个智能、分布式和异构的架构。有了这个基础，你的组织可以继续用不同类型的工作负载进行创新，并在产品的整个生命周期中向最终消费者提供功能和功能。在下一章中，你将了解随着你的客户群从数千台设备增长到全球数百万台设备时，扩展物联网操作的最佳实践。具体来说，你将了解 AWS IoT Greengrass 支持的围绕车队配置和车队管理的不同技术。

知识检查

在进入下一章之前，通过回答以下问题来测试你的知识。答案可以在书的末尾找到：

1. 你将实施什么策略来加快开发物联网工作负载的敏捷性？

2. 对或错：DevOps 是一套工具，有助于开发者和运维更快地协作。

3. 你能回忆起实施 DevOps 与物联网工作负载至少两个挑战吗？

4. 设计从云到边缘的 DevOps 工作流程时，你应该考虑哪些服务？

5. 对或错：在边缘运行原生容器和 AWS Lambda 函数都提供了类似的好处。

6. 你能想到使用 MLOps 与物联网工作负载至少三个好处吗？

7. MLOps 工作流程的不同阶段是什么？

8. 对或错：边缘的 MLOps 工具链仅限于几个框架和编程语言。

9. AWS 为在边缘执行 MLOps 提供了哪些服务？

参考文献

有关本章涵盖的主题的更多信息，请参阅以下资源：

• DevOps 和 AWS：aws.amazon.com/devops/

• 使用 AWS CloudFormation 的基础设施即代码：aws.amazon.com/cloudformation/

• 在 AWS 使用 Edge Manager 开发物联网-MLOps 工作流程：docs.aws.amazon.com/sagemaker/latest/dg/edge-greengrass.html

• 带有质量保证的 CRISP-ML 方法论：arxiv.org/pdf/2003.05155.pdf

• 机器学习操作：ml-ops.org/

• Docker 概述：docs.docker.com/get-started/overview/

• 在 AWS IoT Greengrass 上运行 Docker 化应用程序的不同方式：docs.aws.amazon.com/greengrass/v2/developerguide/run-docker-container.html

• 特殊兴趣小组：github.com/cdfoundation/sig-mlops

第九章：第九章：大规模车队管理

物联网（IoT）始于 1999 年，在宝洁公司，凯文·阿什顿提出了将射频识别（RFID）天线集成到口红货架上的想法，以便分支经理更好地跟踪化妆品库存以进行补充。从那时起，这项技术以某种形式被广泛应用于所有行业领域，并在当今世界变得无处不在。

在已知物理边界内管理一组 RFID 标签、传感器和执行器是一项相对简单的工作。然而，在全球范围内管理数百万（或数十亿或数万亿）这些设备在其整个生命周期内则不是。尤其是当这些设备分布在不同的地点，具有各种形式的连接和接口时。

因此，在本章中，您将了解远程上线、维护和诊断设备车队的最佳实践。此外，您将通过构建操作枢纽来获得实际经验，以评估连接车队的健康状况并采取必要的行动。

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

• 全球上线设备车队

• 大规模管理您的车队

• 建立操作枢纽的动手练习

• 检查你的知识

技术要求

本章的技术要求与第二章“边缘工作负载基础”中概述的要求相同。请参阅该章节中的完整要求。

全球上线设备车队

我们已经在第八章，“边缘的 DevOps 和 MLOps”中向您介绍了物联网制造供应链中涉及的不同活动。上线指的是制造、组装并将设备注册到注册机构的过程。在本节中，我们将深入了解以下在上线工作流程中发挥作用的活动：

![Figure 9.1 – 设备上线活动

![img/Table_09_01.jpg]

Figure 9.1 – 设备上线活动

到目前为止，在这本书中，您一直在使用树莓派（或虚拟环境）进行动手练习。这是开发和原型设计中的常见做法。然而，随着您的项目向更高环境（如 QA 或生产）发展，建议您考虑工业级硬件，并且能够在各种条件下运行。因此，图 9.1中提到的所有上述活动都需要在您的设备（即连接的 HBS 枢纽）可以通过您的分销渠道在不同的零售店（并且像热蛋糕一样畅销！）提供之前完成。

在本章的剩余部分，我们假设你的公司已经定义了与首选供应商的供应链，并且设备制造工作流程已经运行，以便组装设备。当你的客户打开这些设备（充满兴奋！）并启动设置过程时，设备需要在本地（边缘）启动并成功注册到AWS IoT服务，以实现完全运行。

因此，你可能正在想，为了使设备注册成功，需要提前执行哪些必要步骤？下面就是。

注册证书颁发机构

存在着不同类型的加密凭证，例如用户 ID、密码、销售令牌（如JWT和OAuth）以及对称或非对称密钥，这些密钥可以被物联网设备使用。我们建议使用非对称密钥，因为在撰写本文时，这些被认为是行业中最安全的做法。在所有之前的动手实践中，你利用了由 AWS IoT证书颁发机构（CA）生成的非对称 X.509密钥和证书，这些证书嵌入在运行 Greengrass 的连接 HBS 网关中。CA 是一个受信任的实体，它颁发加密凭证，如数字密钥和证书。这些凭证在云上注册并嵌入到设备中，以启用传输层安全或基于 TLS 的相互认证。具体来说，与相互 TLS 认证工作流程相关联的数字资源有四个，如下所示：

• X.509 证书：这是一个需要在设备和云中都存在的证书，在相互 TLS 握手过程中被展示。

• 私钥和公钥：使用如Rivest-Shamir-Adleman（RSA）或椭圆曲线加密（ECC）算法生成的非对称密钥对。作为最佳实践，私钥仅保留在设备上，并且应该得到保护，以避免身份泄露。

• 签名 CA：这是一个由受信任的 CA（如 AWS 和 Verisign）签发的根或中间证书。设备在注册过程中需要发送这个签发 CA 以及客户端证书。如果签名 CA 不可用，也可以发送 TLS 相互认证中的服务器名称指示（SNI）部分来验证信任。

• 服务器证书：这是一个由设备使用的证书，用于在 TLS 握手期间通过展示的证书链验证，它不是在与冒充服务器通信。

下面的图示显示了工作流程以及这些数字资源在设备和云中的位置：

![图 9.2 – 物联网工作流程中的加密凭证

图 9.2 – 物联网工作流程中的加密凭证

因此，在设计过程中尽早决定 CA 至关重要。这样，它就可以颁发设备所需的上述数字资源，以便与后端权威机构进行注册并完全运行。CA 可以以以下三种不同的方式与 AWS IoT Core 一起使用，如下表所示，并列出其优缺点：

图 9.3 – 选择 CA

一旦完成 CA 设置，下一步就是根据场景选择设备供应方法。让我们在下一节中更详细地了解这一点。

决定供应方法

在物联网世界的许多情况下，术语“供应”和“注册”被交替使用，但我们认为它们之间存在明显的区别。对我们来说，设备供应是两种活动的结合——设备注册和设备激活。“设备注册”是指设备使用其初始加密凭证对注册机构（如 AWS IoT 身份服务）进行成功认证，报告独特的属性，如型号和序列号，并在设备注册表中关联为唯一的身份。此外，该机构可以返回一组新的凭证，设备可以用这些凭证替换之前的凭证。在此之后，权限提升器可以提高关联主体（如 X.509 证书）的权限，以便设备能够被激活并完全运行。

在这些供应步骤中存在不同的方法，这些方法通常源于组织希望在制造供应链中拥有的控制水平或便利性。通常，这种选择是由多个因素决定的，例如内部技能、成本、安全性、上市时间或对产品知识产权的敏感性。您在第二章“边缘工作负载基础”中学习了通过 IoT 设备测试器实现自动供应的方法，这种方法在原型设计和实验目的上非常普遍。

在本节中，我们将讨论两种可扩展到从一台设备到数百万台设备（或更多）的生产级供应方法，这些方法通过以下场景反向工作。

场景 1 – 批量供应具有独特固件映像的 HBS 集线器

在此场景中，您可以使用包含独特加密凭证的独特固件映像，在您的供应链中批量供应 HBS 集线器群。

1. 作为 HBS 集线器的设备制造商，首先，您将使用支持的 API 将您选择的 CA 与 AWS IoT Core 关联起来。这个 CA 将管理信任链，并为整个设备群创建和验证加密凭证（如证书或证书签名请求）。

2. 然后，您将创建一个配置模板，本质上是一个配置文件，它包含了 AWS IoT 身份服务创建事物（或虚拟表示）的指令，用于 HBS 中心设备群的批量部署。这个模板将包括不同的输入参数，如 ThingName、SerialNumber 和 证书签名请求（CSRs），这将导致创建物联网资源，如虚拟事物、设备元数据、证书和政策。您可以参考官方 AWS 上的物联网 博客上显示的模板，标题为 使用 AWS IoT 设备管理服务轻松部署设备群 (aws.amazon.com/blogs/iot/deploy-fleets-easily-with-aws-iot-device-management-services/)。该模板可在 创建配置模板 部分找到。

3. 下一步是生成加密凭据，如私钥和 CSR，通过首选的工具链（如 OpenSSL）。在此之后，创建一个包含设备列表和加密凭据的输入文件，这些文件将被输入到配置模板中。这个输入文件在最简单的形式下可能看起来像这样：

   {"ThingName": "hbshub-one", "SerialNumber": "0001", "CSR": "*** CSR FILE CONTENT ***"}
   {"ThingName": "hbshub-two", "SerialNumber": "0002", "CSR": "*** CSR FILE CONTENT ***"}
   {"ThingName": "hbshub-three", "SerialNumber": "0003", "CSR": "*** CSR FILE CONTENT ***"}
   

4. 现在，是时候调用 API 来创建所有这些虚拟设备（即事物），在云端的物联网设备注册表中批量创建，以及相应的由 CA 签署的加密凭据（如证书或 CSR）。一旦这一步完成，就需要创建一个令牌交换角色，并将这些事物与 Greengrass 特定的结构相关联，例如 Greengrass 核心组件、事物组以及安装过程中所需的配置文件（config.yaml）。

5. 在此之后，您将注入之前步骤中生成的凭据，包括来自 步骤 3 的私钥和来自 步骤 4 的已签名证书，到您的固件中。这个更新的固件通常被称为金盘镜像，然后与您的组装团队（无论是内部团队还是合同制造商）共享。组装团队将把这个镜像闪存到制造工作流程中的设备部分：

图 9.4 – 嵌入凭据的大规模配置

这种方法对于运行 RTOS 的微控制器来说相当常见，因为这些硬件（目前）不支持增量更新。然而，对于连接的 HBS 中心，将固件镜像与加密凭据解耦在操作上更为灵活和高效。

这就是第二个选项的用武之地。在这里，你仍然会像上一步一样从你的证书机构生成事物和唯一的凭证，但你不会将其注入到固件中。相反，你将开发一个智能固件，它可以接受通过不同接口（如 安全壳 (SSH), 网络文件系统 (NFS), 或 串行连接)提供的凭证。作为最佳实践，通常还会将凭证存储在单独的芯片中，如安全元素或 可信平台模块 (TPM)。此外，固件可以使用公钥加密标准接口（如 PKCS#11）实时检索固件或其他本地应用程序所需的密钥和证书。在撰写本书时，Greengrass v2 正在等待对 TPM 的支持，尽管它曾是 Greengrass v1 的支持功能：

图 9.5 – 使用注入接口进行批量配置

让我们看看如何进行第二个选项：

1. 一旦设备组装完成，包含必要的配置和凭证的金色镜像，产品将通过不同的分销渠道到达客户手中。当客户打开设备并首次唤醒时，引导过程开始。

2. 引导过程将实例化各种本地进程（或 守护进程），即固件指令。其中之一包括与 AWS IoT Identity 服务进行注册，设备将连接到云端点并交换 TLS 互信中嵌入的凭证部分。考虑到事物、证书和政策已经作为组装的先决条件创建，如果互信成功，设备将完全运行。

场景 2 – 具有共享声明的 HBS 中心在需要时进行配置

让我们考虑以下场景；你的设备在制造时可能没有接受唯一凭证的能力。或者，对于你的组织来说，在供应链中的每个 HBS 中心中嵌入唯一凭证的操作成本过高。这就是另一种模式出现的地方，被称为按声明的批量配置，其中，作为设备制造商，你可以在你的设备系列中嵌入一个非唯一的共享凭证（称为声明）。然而，我们建议你不要为整个设备系列共享相同的声明，而只共享其中的一部分，以减少任何安全问题的爆炸半径。请看以下步骤：

1. 作为第一步，合同制造商在设备上加载固件以及舰队配置插件和共享证书（即声明），而不进行任何定制。声明方法通过模板方法来配置所需的云资源，这种方法与之前的场景类似。您可以参考 AWS 文档中提供的示例模板，称为为 Greengrass 核心设备设置 AWS IoT 舰队配置（docs.aws.amazon.com/greengrass/v2/developerguide/fleet-provisioning-setup.html#create-provisioning-template）。主要区别在于，所有这些资源都是即时配置的，每个设备都从当前位置启动引导过程，而不是在制造设施中批量映像。

2. 此方法还支持预配置钩子功能，其中可以调用 lambda 函数来验证不同的参数或执行预配置逻辑。例如，它可以像覆盖参数一样简单，也可以更复杂，例如检查声明证书是否在撤销列表中：

   def pre_provisioning_hook(event, context):
       return {
           'allowProvisioning': True,
           'parameterOverrides': {
               'DeviceLocation': 'NewYork'
           }
           }
   

   在这里，当网关首次唤醒并连接到 AWS IoT 时，声明证书被交换为永久性 X.509 证书，这些证书由 CA（AWS 或 BYO）签名。这就是舰队配置插件发挥作用的地方，因为它允许设备发布和订阅所需的MQ 遥测传输（mqtt）主题，接受唯一的凭据，并持久化存储在安全类型中：

   ![图 9.6 – 使用共享声明的舰队配置

   图 9.6 – 使用共享声明的舰队配置

3. 在此之后，设备还必须断开与之前通过共享声明启动的会话，并使用唯一的凭据重新连接。

   警告

   如果共享声明没有通过供应链得到保护，声明方法配置的舰队配置会带来安全风险。

一旦设备已经配置，下一步就是组织它们，以简化其整个生命周期的管理。Greengrass 核心设备可以被组织成事物组，这是在 AWS IoT 生态系统中组织设备群的结构。事物组可以是静态的或动态的。正如其名称所暗示的，静态组允许根据非变化的属性组织设备，例如产品类型、制造商、序列号、生产日期等。

此外，静态组允许构建具有父设备和子设备的设备层次结构，这些设备可以跨越多达七层。例如，查询属于公司 XYZ 的序列号范围内的洗衣机传感器的组，可以用来识别因生产缺陷需要召回的设备。

相比之下，动态组是通过索引信息创建的，例如连接状态、注册元数据或设备阴影。因此，动态组的成员总是变化的。这就是为什么动态组不与任何设备层次结构相关联的原因；例如，查询在某个时间点连接且固件版本为 v1 的 HBS 设备组。这个结果可以让车队运营商向相应的所有者推送固件更新通知。

使用物组的优势之一是能够在设备组级别分配车队权限（即策略），然后这些策略会级联到该层次结构中的所有设备。这简化了在每个设备级别管理策略的负担。同时，尽管如此，仍然可以拥有针对特定设备的策略，AWS IoT 身份服务将在身份验证和授权工作流程中自动评估组与设备级别之间允许的最小权限访问级别。

现在您已经很好地了解了如何使用不同的方法配置和组织 HBS 集线器。接下来，让我们讨论一旦推出如何管理车队。

在规模上管理您的设备车队

虽然监控少量设备可能更容易，但管理规模化的设备车队可能会变成一个运营噩梦。为什么？好吧，这是因为物联网设备（如 HBS 集线器）不仅部署在受控的区域内（如数据中心）。正如您现在应该已经了解到的，这些设备可以部署在任何地方，例如家庭、办公室、商业地点，这些地方可能具有不同的电力消耗、网络连接和安全状态。例如，可能会有设备离线运行，无法通过公共或私人网络访问，因为该场所的 Wi-Fi 连接间歇性不可用。因此，作为一名物联网专业人士，您必须考虑各种场景，并提前规划如何规模化地管理您的车队。

在连接的 HBS 集线器背景下，设备管理可以帮助您实现以下目标：

• 从现实世界中捕获可操作的信息。

• 通过早期捕获异常来提高解决方案的效率。

• 通过预测性或预防性维护来优化成本。

• 防止知识产权被盗或未经授权的访问。

• 建立一个持续的反馈循环来提高客户体验。

• 通过更多数据洞察来生成额外的收入来源。

因此，如您所了解的，开发和推出物联网解决方案只是开始。为了实现之前提到的业务成果，有必要治理整个解决方案的生命周期。因此，设备管理也可以被视为以下活动的更大范畴：

• 配置

• 组织

• 监控

• 维护

• 诊断

下图显示了物联网设备管理的工作流程：

![图 9.7 – 物联网设备管理流程

图 9.7 – 物联网设备管理流程

各种状态下的组件数量，例如以下内容：

监控

可以配置组件以指定不同的发布间隔（以秒为单位），因此指标可以带批处理或不带批处理发布。例如，对于 lambda，默认的批处理窗口是 10 秒，最大等待时间可能是 900 秒。

• （$local/greengrass/telemetry），您可以在核心设备上本地处理这些数据，即使与云端的连接是间歇性的。

• 可选地，该组件可以配置为将遥测数据发布到云端的mqtt主题。

• 任何自定义组件，如部署在核心设备上的 lambda 函数或容器，都可以将自定义指标发布到本地主题（cloudwatch/metric/put）。

• 如果遥测数据在本地发布，则没有费用，但将其推送到云端时则需收费。

• 遥测代理会原生前缀发布以下指标：

  • 此代理收集遥测数据，并通过Amazon EventBridge（一个无服务器事件总线服务）以尽力而为的方式将其发布到云端。

  • 一旦 Greengrass 核心设备启动并运行，数据就会开始流动。默认情况下，遥测代理每小时汇总遥测数据，每 24 小时将其发布到云端。

  • 由于消息发布到 AWS IoT Core 的保留主题，因此没有数据传输费用。

  • 系统内存和 CPU 利用率

  • 文件描述符的总数，其中每个描述符代表一个打开的文件

  • 遥测代理是您可以用来收集本地遥测数据的另一个选项，默认情况下对所有 Greengrass 核心设备启用：

    • 监控 Greengrass 启用的 HBS 中心节点及其相关设备对于实现可靠、高可用和性能良好的物联网工作负载至关重要。您应该有一种机制来收集边缘解决方案的监控数据，以便在发生故障时进行调试。Greengrass 支持收集系统健康遥测和自定义指标，这些是用于监控 Greengrass 核心设备上不同组件和应用程序关键操作性能的诊断数据点。以下是可以收集这些数据的不同方式列表：

    • 运行、停止和完成

    • 错误的、损坏的和无状态的

  在后续的动手操作部分，您将收集这些指标并在云上进行处理。

  • CloudWatch 指标是 Greengrass 组件，允许您将自定义指标发布到 Amazon CloudWatch：

  • 我们已经在上一节中讨论了与 Greengrass 相关的第一个三个主题。因此，我们将继续关注剩余的活动。

  • 这是一个几乎实时发布到本地主题的系统遥测数据连续流。默认配置是每 60 秒。

  • 因此，如果您考虑需要从与中心关联的传感器和执行器收集指标的场景，而不仅仅是从网关收集，则自定义应用程序可以检索这些数据点并将它们本地发布或发布到云端点以进行监控目的。* 日志管理器是 Greengrass 组件，可以部署到您的 Greengrass 核心设备以收集日志，并可选项地将其上传到 Amazon CloudWatch Logs：

  • 尽管指标可以帮助反映设备的状态，但日志对于排除异常或故障至关重要。

  • 对于日志的实时可观察性，Greengrass 提供了各种日志文件。其中一些您可能已经使用过，如下所示：

    • Greengrass.log：这是用于查看关于核心和组件部署的实时信息的日志文件。例如，使用 HBS 中心，此日志文件可以报告核心软件的错误、异常和故障，您（或客户）可以分析这些故障或故障以确定停机时间或故障。

    • Component.log：这是用于查看核心设备上运行的组件实时信息的日志文件（s）。

    • Main.log：这是处理组件生命周期信息的日志文件。

  • 日志管理器组件可以以不同的频率上传日志。日志管理器的默认配置是每 5 分钟上传一次新日志到 AWS CloudWatch。此外，还可以配置更低的上传间隔以实现更频繁的上传。日志格式也可以在文本格式和 JSON 格式之间进行配置。

  • 日志管理器还支持每小时或当文件大小限制超过时进行文件轮换。日志文件的默认大小限制为 1 MB，磁盘大小为 10 MB，并且可以完全配置。为了优化日志大小，使用不同环境的不同详细程度（如开发、测试和生产）也是一个最佳实践：

    • 例如，您可以选择 DEBUG 级别的日志来帮助在非生产环境中进行故障排除，或选择 ERROR 级别的日志以减少生产环境中设备生成的日志数量。此选择也有助于优化成本。

当您从 HBS 中心收集所有这些数据点（指标和日志）并将它们发布到云端时，下一步是允许不同的角色，如车队运营商（或其他下游业务）消费这些信息。这可以通过 CloudWatch 实现，它原生提供与日志洞察、生成仪表板、设置警报等相关的能力。如果您的组织已经标准化了监控解决方案（如Splunk、Sumologic、Datadog或其他），CloudWatch 也支持该集成。

最后，在控制平面中，Greengrass 与 AWS CloudTrail 集成，记录与服务 API、IAM 用户和角色相关的访问事件。这些访问日志可用于确定有关 Greengrass 访问的更多详细信息，例如请求的 IP 地址、请求者是谁以及何时发起的请求，这些信息对于各种安全和运营需求可能很有用。

维护

之前解释过的服务，例如 Amazon CloudWatch（或第三方解决方案），可能足够强大，可以生成监控物联网工作负载健康状况所需的各类洞察。然而，物联网管理员或车队运营商的另一个常见需求是拥有一个单视图，使他们能够从设备车队中消费一套全面的信息，以便快速排查操作事件。

例如，考虑一个场景，客户抱怨他们的 HBS 调制解调器出现故障。作为车队运营商，您可以从仪表板观察到大量的连接丢失和高资源利用率。因此，您查阅日志（在设备或云中），并确定这是一个由于特定组件（如 聚合器）导致的内存泄漏问题。根据您的操作剧本，您需要确定这是否是一个孤立的问题，或者车队中的更多设备是否表现出类似的行为。因此，您需要一个界面来搜索、识别和可视化跨车队的指标，例如设备状态、设备连接、电池水平，或者根据用户位置进行过滤的集合。这就需要一款车队管理解决方案，如 AWS Fleet Hub，它允许通过无代码方法创建一个完全管理的网络应用程序，以满足各种角色的需求。在我们的场景中，这个网络应用程序可以帮助运营商几乎实时地查看、查询和交互连接的 HBS 调制解调器车队，并进一步排查问题。除了监控之外，运营商还可以响应警报，并通过单一界面触发远程操作 空中（OTA）来修复部署的设备。AWS Fleet Hub 应用程序还支持以下功能：

• 集成现有的身份和访问管理系统，如 Active Directory 和 LDAP，允许基于角色的访问到不同的角色，例如车队运营商、车队经理、设备制造商、第三方以及以某种方式与 HBS 调制解调器交互的 IT 运营商。此外，这还允许这些用户使用 单点登录（SSO）并从任何桌面、平板电脑或智能手机上的浏览器访问车队中心。

• 聚合来自其他服务（如 AWS IoT Fleet Indexing、Amazon CloudWatch 或Amazon Simple Notification Service（SNS））的数据。IoT Fleet Indexing 服务有助于索引、搜索、查询和聚合来自设备注册、设备阴影和设备连接事件的 数据。此外，还可以创建自定义字段。CloudWatch 指标可以与这些可搜索字段结合使用来创建警报。最后，当警报阈值被突破时，Amazon SNS 可以通知不同的角色。

总结来说，Fleet Hub 提供的这些功能可以让一个组织更快地响应不同的运营事件，从而提高客户体验。

诊断

在前面的场景中，你学习了如何通过单视图来实时了解运营事件。然而，如果通过 Fleet Hub 的远程操作不足以修复已识别的问题，如何进一步诊断问题呢？例如，操作员可能已触发远程操作来重新启动聚合组件或 HBS 中心本身，但这并没有解决最终消费者的问题。因此，作为下一步，操作员需要直接访问中心或相关传感器以进行进一步的故障排除。传统上，在这种情况下，公司会安排与技术人员预约，这意味着额外的成本和客户的等待时间。这就是 AWS IoT Secure Tunneling 这样的远程诊断功能派上用场的地方。这是一个 AWS 托管服务，允许车队操作员通过安全隧道获得额外的权限（如 SSH 或 RDP 访问）到目标设备。

Greengrass 的加密隧道组件使得操作员工作站与 Greengrass 启用的设备（如 HBS 中心）之间即使在其后有受限防火墙的情况下也能进行安全的双向通信。这是通过远程操作在底下的安全隧道中导航实现的。此外，设备还将继续使用在遥测中使用的相同的加密凭证（即X509 证书）。客户端（即车队操作员）的唯一其他依赖是需要在笔记本电脑或网络浏览器上安装代理软件。这是因为代理软件通过在会话启动时允许与隧道服务交换临时凭证（即访问令牌）来实现魔法。以下图表显示了安全隧道的工作流程：

图 9.8 – 诊断的加密隧道工作流程

对于我们的场景，源指的是车队操作员的工作站，目标指的是连接的 HBS 中心，而安全隧道服务由 AWS 管理。

现在您已经很好地理解了如何更好地监控、维护和诊断边缘设备，让我们在本章的最后部分亲自动手。

熟练掌握车队中心架构

在本节中，您将学习如何使用核发射器和遥测代理从边缘设备捕获各种指标和日志，并通过 Amazon CloudWatch 和 AWS IoT 车队中心进行可视化。以下是在实验室中您将完成的不同服务和步骤的架构：

![图 9.9 – 实践操作中心]

![img/Figure_09_09.jpg]

图 9.9 – 实践操作中心

以下表格列出了您将在本练习中使用的服务：

![图 9.10 – 本练习范围内的服务]

![img/Table_09_10.jpg]

图 9.10 – 本练习范围内的服务

在本实践部分，您的目标是以下步骤，如前所述的架构所示：

1. 使用 AWS IoT 车队中心构建操作仪表板。

2. 部署一个核发射器组件并通过遥测从边缘收集指标。

3. 部署一个日志管理组件并将日志流式传输到 Cloudwatch。

4. 在物联网车队中心（IoT Fleet Hub）和 CloudWatch 上可视化结果。

让我们更详细地查看前面的步骤。

构建云资源

在本节中，您将学习如何设置一个车队中心应用程序，该应用程序可以用于监控连接的 HBS 中心的数据指标。执行以下步骤：

1. 导航到AWS IoT 核心控制台并选择车队中心。选择入门并点击创建应用程序。

2. 这将提示您使用 AWS SSO 设置单点登录。如果您以前没有使用过这项服务，请创建一个带有必要信息的用户。您将通过电子邮件收到邀请，您需要接受邀请并按照说明设置密码。点击下一步。

3. 现在您需要配置与 AWS IoT 数据的索引。如前所述，车队中心通过聚合来自不同来源的信息，为您提供单一视角视图。这就是您设置所有这些集成的地方。

4. 在车队索引部分点击管理索引。这将打开 AWS IoT 设置页面。再次点击管理索引并启用所有可用选项，例如设备索引和设备组索引。如有需要，您还可以创建自定义搜索字段。点击更新。

5. 返回车队中心设置屏幕，设置现在应该处于活动状态。点击下一步。

6. 创建一个应用程序角色和一个您选择的名称的应用程序。点击查看策略权限以了解提供给应用程序的访问权限。您应该注意到，您正在为车队中心提供访问权限以集成所有这些资源，如前所述。点击创建应用程序。

7. 在 Fleet Hub 的 应用 选项卡上，当应用 URL 显示为活动状态时，点击一次。对于首次访问，这将提示您添加一个 SSO 用户。点击该选项并添加您之前创建的用户。点击 添加选定的用户。

8. 完成后，再次点击应用 URL，进入网页仪表板，并使用您在 步骤 2 中配置的凭据登录。点击应用程序图标，它应该为您打开仪表板。

恭喜！您已经设置好了 Fleet Hub 仪表板！

注意

虽然我们只为这个实验创建了一个用户，但您可以将 AWS SSO 集成到您组织的身份管理系统，如 Active Directory。这将允许基于角色的访问仪表板，针对不同的角色。理想情况下，此配置将属于身份工程师的职责范围，而不是物联网专业人士的职责。

接下来，让我们设置从 HBS 中心到云端的遥测数据摄取的路由规则：

1. 导航到 Amazon EventBridge 控制台 (go.aws/3xcB2T7)，并点击 创建规则。

2. 为规则选择一个名称和描述。

3. 在 AWS。

4. 服务名称：Greengrass。

5. 事件类型：Greengrass Telemetry Data。

6. 保持 选择事件总线 部分为默认设置。

7. 在 /aws/events/ <替换为您的选择名称>

8. 保持其他所有设置为默认，并点击 创建。

干得好！EventBridge 已经准备好摄取遥测数据并将其发布到 CloudWatch 组。

我们将在实验结束时再次访问这些仪表板，以可视化从中心收集的数据。现在，让我们转换方向，配置和部署 Greengrass 上的边缘连接器。

从云端部署组件到边缘

在本节中，您将学习如何将 Nucleus Emitter 和 Log Manager 代理部署到 Greengrass 启用的 HBS 中心，以将健康遥测数据发布到云端。执行以下步骤：

1. 请导航到 Amazon Greengrass 控制台，选择 aws.greengrass.telemetry.NucleusEmitter 和 aws.greengrass.LogManager 组件。您可以随意点击 查看配方 来审查此组件的配置。

2. 保持所有之前组件以及前两个组件选中状态，点击 下一步。在接下来的屏幕中，保持其他选项为默认设置，并选择 部署。

可视化结果

现在，您已经设置了车队中心并在边缘部署了代理，您可以使用以下步骤可视化遥测数据：

1. 导航到 AWS IoT Core 控制台，点击 Fleet Hub，并选择在实验室中创建的应用程序。

2. 在设备列表部分，点击 Greengrass 启用 HBS 网关设备。你将能够查看设备的状态以及各种其他属性，如字段属性、设备影子文件（即配置的设备状态）、设备所属的组以及部署的历史（即作业）。

3. 返回主页。你可以随意使用屏幕顶部的搜索和筛选选项来细化结果。通常，这在你有大量网关和关联设备时很有用。你还可以切换到摘要部分，以可视化按类型、事物组以及断开连接的原因的总设备数量。

4. 点击创建警报。这将帮助你设置以下违规的通知：

   1. 选择一个字段：断开连接原因。

   2. 选择一个聚合类型：计数。

   3. 选择周期设置为5 分钟，然后点击下一步。

   4. 选择指标设置为大于/等于 1，然后点击下一步。

   5. 假设你只有一个设备网关，如果你有更多，你可以增加计数。

   6. 配置通知和警报详情，然后点击下一步和提交。

   因此，作为一支船队运营商，你现在可以可视化你的设备船队的健康状况，同时对于阈值违规发出警报。

5. 导航到AWS CloudWatch控制台，点击日志然后选择日志组。

6. 搜索并点击**/aws/events/<将此替换为你选择的名称>日志组**，并可视化日志流。

7. 可能需要一些时间来填充，但日志流应该会显示从 Greengrass 网关设备收集的遥测数据。

8. 随意使用日志洞察，它允许你通过查询界面分析日志。

到目前为止，你已经学会了如何使用 AWS 原生解决方案操作 Greengrass 启用设备船队。这些模式也适用于非 Greengrass 设备，例如，利用其他设备 SDK（如AWS IoT Device SDK或FreeRTOS）的设备。

挑战区

我将给你一个快速挑战，让你确定如何从 AWS IoT Fleet Hub 触发 OTA 作业到特定的 HBS 网关设备。这在需要推送更新，如操作事件期间所需的配置文件时很有用。祝你好运！

让我们通过一个简要的总结和一些知识检查问题来结束这一章。

摘要

在本章中，你被介绍了设计模式和设备集群的上线、管理和维护的最佳实践。这些实践可以帮助你在不同的地理位置部署和操作数百万（或更多）的连接设备。此外，你还学习了如何远程诊断边缘设备以解决常见问题或安全地隧道以进行高级故障排除。在此之后，你实施了一个边缘到云架构，利用各种 AWS 构建的组件和服务。这使得你可以从 HBS 节点收集健康遥测数据，设备管理员可以通过仪表板可视化这些数据，通过警报进行通知，或根据需要采取行动。

在下一章和最后一章中，我们将总结你在整本书中学到的所有关键教训（以及更多），这样你就可以为现实世界构建良好的解决方案了。

知识检查

在进入下一章之前，通过回答以下问题来测试你的知识。答案可以在书的末尾找到：

1. 对或错：设备注册和设备激活是相同的。

2. 有哪些不同的方式可以利用 AWS IoT Greengrass 中的证书颁发机构（CA）？

3. 是否有实时配置设备的选择？如果有，那是什么？

4. 对或错：指标和日志是监控 IoT 工作负载所需的所有数据点。

5. 你认为拥有一个单视图来查看整个设备集群有什么好处？

6. 如果需要，不派遣技术人员的情况下，远程故障排除设备的缓解策略是什么？（提示：考虑隧道。）

7. AWS IoT Greengrass 提供哪些组件来收集系统健康遥测数据？

8. 对或错：在边缘设备上聚合指标是不可能的。它只能在云中完成。

参考资料列表

查看以下资源以获取本章讨论的概念的更多信息：

• 关于在 AWS IoT 核心中使用 X.509 证书进行设备制造和配置的论文：d1.awsstatic.com/whitepapers/device-manufacturing-provisioning.pdf

• 在何时使用 AWS IoT 设备管理：aws.amazon.com/iot-device-management/

• AWS IoT Greengrass 集群管理功能发布：aws.amazon.com/about-aws/whats-new/2021/08/aws-iot-greengrass-v-2-4/

• AWS IoT 设备管理的设备中心：docs.aws.amazon.com/iot/latest/fleethubuserguide/what-is-aws-iot-monitor.html

• AWS IoT 事物组：docs.aws.amazon.com/iot/latest/developerguide/thing-groups.html

第四部分：整合一切

本节将通过审查一个解决方案为何架构良好（安全性、可靠性、运营卓越、成本优化和性能）以及如何使用从本书中学到的知识来交付下一个成果的指导，来结束实际项目。它将指导你下一步应该做什么。

本节包含以下章节：

• 第十章*，使用 AWS Well-Architected 框架审查解决方案*

第十章：第十章：使用 AWS Well-Architected Framework 审查解决方案

您现在拥有了创建边缘机器学习（ML）解决方案所需的技能。本章既是本书所学关键课程的总结，也是通过回顾提供的解决方案来证明它们是最佳实践的依据。通过回顾解决方案，我们可以看到 Home Base Solutions 原型中心设计如何保持稳定，以及进一步改进的机会在哪里。您将了解如何使用AWS Well-Architected Framework对解决方案进行深入分析，这是一个为审查复杂解决方案而创建的机制。最后，我们将为您提供作为边缘智能工作负载交付实践者的旅程中建议的下一步行动。

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

• 总结关键课程

• 描述 AWS Well-Architected Framework

• 审查解决方案

• 深入了解 AWS 服务

总结关键课程

在本节中，我们将对本书中的关键课程进行分组和总结，作为快速参考，以确保不会错过最重要的课程。这些分组基于从第一章到第九章的材料，有一个大致的时间顺序，但某些课程可能出现在它们在本书中出现的顺序之外的组中。

定义边缘机器学习解决方案

以下关键课程捕捉了边缘机器学习解决方案的定义、价值主张和形态：

• 边缘机器学习解决方案的定义：将智能工作负载带到边缘意味着应用已融入网络物理解决方案的机器学习技术，这些解决方案可以交互模拟和数字空间。边缘机器学习解决方案使用具有足够计算能力来运行机器学习工作负载的设备，可以直接与物理组件（如传感器和执行器）接口，或者通过本地网络或串行协议间接与终端设备接口。

• 边缘机器学习的关键益处：将智能工作负载带到边缘的四个关键益处是减少对测量事件的反应延迟、通过减少对远程网络实体（如服务器）的运行时依赖来提高解决方案的可用性、通过减少在广域网中传输的数据量来降低运营成本，以及通过仅在边缘处理受保护数据来符合数据治理政策。

• 边缘机器学习解决方案的工具：在边缘运行智能工作负载所需的三个工具是用于编排您的边缘软件的运行时、机器学习库和机器学习模型，以及在整个边缘和远程服务之间双向交换数据的机制。

• 解耦、隔离的服务：使用面向服务的架构的原则来设计您的边缘机器学习解决方案，以提供由隔离服务组成的整体，这些服务使用解耦机制进行交互。具有单一目的设计的代码更容易编写、测试、重用和维护。从传感器获取测量值的代码不需要知道如何直接调用机器学习推理服务。推理服务也不需要知道如何直接将结果发送到连接的执行器。要达到的隔离和关注点分离的程度是一个范围，也是架构师需要考虑权衡的问题。

• 不要重新设计已解决的问题：使用经过验证、值得信赖的技术来解决边缘机器学习解决方案解决的业务问题中不是核心的实现细节。例如，除非没有其他协议或数据存储层能满足您的业务需求，否则不要创建新的消息协议或数据存储层。

• 常见的边缘拓扑：在构建边缘解决方案中常见的四种拓扑是 星型、总线型、树型 和 混合型。星型拓扑描述了叶设备如何与一个通常运行任何机器学习工作负载的枢纽或网关设备交互。总线型拓扑描述了隔离服务如何使用解耦机制相互交互。树型拓扑描述了如何从中心服务管理边缘解决方案的舰队。混合型拓扑描述了任何与云服务交互的宏观级别架构的一般形状。

使用 IoT Greengrass

以下关键经验总结了对 AWS IoT Greengrass 的定义以及使用它来提供边缘机器学习解决方案的最佳实践：

• 什么是 Greengrass？ AWS IoT Greengrass 是一个运行时编排工具，旨在通过解决物联网和机器学习解决方案中常见的许多实现细节，将智能工作负载交付到边缘，使架构师能够快速交付业务目标。Greengrass 通过允许开发者定义独立运行并可选择通过解耦机制（如进程间通信通道、流、文件或消息队列）与更广泛解决方案交互的组件，支持面向服务的架构。Greengrass 与 AWS 服务原生交互，以提供架构师通常需要解决的常见功能，例如部署软件、获取资源以及将数据传输到云。

• 使用组件构建：Greengrass 将功能单元定义为 组件，这些组件是打包静态资源（如工件、配置、依赖项和运行时行为）的配方。开发者可以将任何类型的代码作为组件运行，无论是 shell 脚本、解释型代码、编译后的二进制文件、AWS Lambda 函数，还是像 Docker 这样的容器。

• 将组件部署到边缘：在开发周期中，可以使用测试设备上的 Greengrass CLI 本地部署组件。对于生产使用，组件在 AWS IoT Greengrass 服务中注册，并作为向一个或多个分组设备推出的部分远程部署。部署定义了一组组件，包括组件的版本，并在部署时可选地应用任何配置。一个设备可以属于多个组，并将聚合它所属的所有组的当前部署。

• 边缘和云之间的安全模型：Greengrass 设备与 AWS 服务之间的安全模型使用非对称加密、角色和策略的组合。Greengrass 使用与 AWS IoT Core 注册的私钥和证书向 AWS IoT 服务进行身份验证。此证书附加到一个 IoT 策略，该策略授予连接和交换消息等权限。设备可以从 AWS IoT Core 凭证提供者服务请求临时 AWS 凭证以使用其他 AWS 服务进行身份验证。这是通过指定一个附加了策略的 AWS 身份和访问管理 角色来实现的，该策略授予其他 AWS 服务权限。在将另一个 AWS 服务交互添加到你的 Greengrass 解决方案之前，你需要附加一个新策略或更新附加策略，以包括该 API 的适当权限。

• 使用托管组件加速构建：当适用时，使用 AWS 托管组件来解决需求。这些组件解决常见需求，例如与 AWS 服务交互、部署本地 MQTT 代理以连接到本地设备、在边缘和云之间同步设备状态以及运行机器学习工作负载。

模型数据和机器学习工作负载

以下关键课程总结了在将问题分解为模型数据和你在边缘机器学习解决方案中使用的机器学习工作负载时应该考虑的技术和模式：

• 结构化数据类型：在边缘获取的数据可以分为三种类型：结构化（一个定义良好的模式）、半结构化（一个在使用的键方面有一些差异的模式）和非结构化数据（一个具有高方差或没有模式的模式）。所有三种类型的数据都可以由机器学习工作负载进行评估，但每种的训练方法和算法可能不同。

• 分析数据以选择实现选择：使用数据建模技术将高级问题从概念模型分解为逻辑模型，再到物理模型，以在为收集、存储和访问数据选择技术时提供实施决策的信息。分析你数据的大小、形状、速度和一致性要求，以在为选择数据存储技术时提供实施决策的信息。

• 常见的数据流模式：在边缘机器学习架构中可以使用的常见数据流模式包括提取、转换、加载（ETL）、事件驱动（流式处理）、微批处理和Lambda 架构（并行热/冷路径）。避免边缘架构的反模式，如复杂事件检测、批处理、数据复制和数据归档。这些模式最好在拓扑层的各个层级中实现，例如数据中心或云服务。

• 领域驱动设计：考虑领域驱动设计的 10 个原则，以最佳方式组织您的数据：通过领域管理数据所有权，使用边界上下文定义领域，将边界上下文与应用工作负载链接，在边界上下文中共享通用语言，保留原始来源数据，将数据与元数据关联，为不同的任务使用合适的工具，分层存储数据，确保并管理数据管道，以及为可扩展性设计。

• 边缘工作负载的三大定律：在必须遵守三大定律时，将数据工作负载保持在边缘（而不是云中）。物理定律意味着边缘和云之间的延迟有限，有时您的工作负载需求无法容忍这种延迟。经济定律意味着将所有数据移动到云中可能成本过高。法律定律意味着存在数据治理和合规要求，需要某些数据保持在边缘。

• 机器学习训练算法的类型：机器学习模型可以使用三种模式之一进行训练：监督学习（训练数据由人类标记），无监督学习（训练数据未标记；机器自行发现模式或结论），或半监督学习（标记数据和未标记数据的混合）。训练一个模型来模仿人类专家的工作，例如在图像中分类对象，通常意味着使用监督或半监督模式。训练一个模型来发现数据之间的关系通常意味着使用无监督模式。

• 迭代数据到模型的生命周期：使用跨行业标准数据挖掘流程（CRISP-DM）迭代您的机器学习工作负载，从理解您的数据到为训练做准备，到评估模型性能，然后部署模型到边缘。

• 适当地使用机器学习：并非所有问题都可以或应该用机器学习来解决。小数据集或信噪比较低的数据往往无法训练出有用的模型。简单的需求（例如需要一次性的预测）可以用传统的数据分析、查询和回归技术来解决。

• 云在训练模型中的价值：使用云的规模来高效地训练模型并在足够大的数据集上进行训练。一旦您的模型在评估阶段表现良好，请使用模型优化来压缩模型，使其在运行您的边缘 ML 解决方案的目标硬件平台上具有高效率和小的占用空间。继续在设备上测试和评估压缩模型的性能，并在任何重新训练事件之后。

• 机器学习需要一个团队：单个技术资源可以推动所有必要的按钮来收集数据、训练模型并将其部署到边缘，但训练一个有效模型的过程是多方面的。训练有效模型并将其部署到边缘需要来自多个领域的专家才能达到成功的成果。一个人无法完成所有事情是可以接受的。

操作生产解决方案

以下关键课程总结了您解决方案生产版本中的重要区别以及如何大规模操作解决方案：

• DevOps 是文化的：开发者操作（DevOps）不仅仅是关于新技术和工具。它代表了组织在促进团队所有权、协作和凝聚力方面的文化转变，以促进创新。DevOps 范式为边缘 ML 解决方案的软件交付生命周期带来了好处，除了传统的软件开发之外。

• 使用托管组件进行监控：使用 AWS 提供的组件将日志和指标存储在您的Amazon CloudWatch账户中。这将帮助您的团队通过日志远程诊断问题，并通过指标上的警报监控不健康的设备，从而操作设备车队。

• IaC 对边缘也很有价值：尽可能将您的解决方案存储和部署为基础设施即代码（IaC）资源。这使得维护解决方案的定义并可靠地在部署之间重现结果变得更加容易。

• 您的设备生命周期始于制造：为设备提供身份并定义其配置过程会影响您的设备供应链。在您的办公桌上配置测试设备很容易。为生产车队创建配置管道则更具挑战性。尽早与您的供应链供应商、原始设备制造商（OEM）和原始设备制造商（ODM）沟通需求。

• 在虚拟化环境中发布代码：您的软件组件可以定义为脚本、源代码、二进制文件以及介于两者之间的任何内容。尽可能在 Docker 和 AWS Lambda 等虚拟化环境中发布您的代码，以在边缘的运行时操作中提供更多可预测性。

• MLOps 是循环的：与用于解决数据科学问题的 CRISP-DM 模型类似，构建和运营 ML 模型的模式是循环的。将 MLOps 部署到边缘的模型可能会更加具有挑战性，因为设备通常是远程的、离线的或暴露在不可预测的元素中。尽早将 MLOps 设计到您的产品生命周期中，以养成良好的习惯。稍后添加它会更困难。

• 部署可能很昂贵：如 AWS IoT Greengrass 等服务使部署软件到边缘变得容易，但必须考虑数据传输的成本。许多边缘解决方案位于昂贵的网络连接的末端，您无法负担得起反复增量推送模型或修复损坏的部署。设置您的 DevOps 和 MLOps 管道，以便在它们推向生产编队之前，您对部署有最高的信心。

• 扩展配置过程：证书颁发机构（CAs）允许您使用独特的证书定义您的设备身份。使用您自己的 CA、来自受信任供应商的 CA 或 AWS 提供的 CA 来扩展您的设备编队的身份。使用如即时（JIT）配置等自动化配置策略，在设备首次连接到您的服务时将设备上线。

• 操作员也需要扩展：扩展的生产设备编队可能意味着管理数千到数百万台设备。使用工具简化操作这么多实体的方式，关注异常和高严重性问题。这意味着您需要一个能够捕获和索引此类运营数据的解决方案。您还需要一个解决方案，使其能够轻松深入单个设备或一次性对大量受影响的设备应用修复。

在下一节中，您将了解 AWS 为在平台上构建解决方案时评估设计权衡提供的框架。

描述 AWS 好架构框架

2015 年，AWS推出了一项框架，指导开发者在 AWS 上构建时做出良好的设计决策。AWS 好架构框架将定义、部署和运营 AWS 云上工作负载的最佳实践编码化。它作为一个最佳实践白皮书和基于网络的工具存在，将解决方案评估作为一个考虑事项清单和建议缓解策略的清单。这种专业知识旨在服务于 AWS 客户，但以一种对评估任何类型的数字工作负载都普遍有用的格式提供。我们将使用这个框架来回顾性地审查这本书的 Home Base Solutions 设备监控产品的解决方案。

好架构框架将最佳实践组织成五个支柱。支柱是框架的一部分，它汇集了设计原则和指导性问题，以共同目标为基础进行解决。五个支柱如下：

• 运营卓越

• 安全性

• 可靠性

• 性能效率

• 成本优化

您可能会认出这些柱子是我们用来定义边缘机器学习解决方案价值主张的关键好处，在第一章，数据驱动边缘机器学习简介中提到！每个柱子都包含一个叙述和一组评估和考虑的问题。对于架构师没有明确回答或现有缓解策略的问题，用于定义解决方案当前架构的完善程度和需要达到的地方之间的差距。例如，如果审查帮助我们确定我们的架构中存在一个单点故障，那么我们会决定在我们解决方案中接受该风险的可行性，或者是否使用故障转移机制进行重构。

重要的是要理解，当您回答框架的问题以审查您的解决方案时，没有客观上是正确或错误的答案。您解决方案的整体状态不是完成审查的可量化结果。您用于回答单个问题的过程可能会确定重要的重构或突出原始设计中的差距。您的团队完成定义决定您的答案必须多么完整或彻底，以及有多少问题得到解决，即您的团队对已进行的尽职调查感到满意。懒惰或肤浅的审查可能不会导致任何有意义的改变。随着解决方案的重要性增加，审查的严谨程度可能成比例或甚至非线性地增加。

在您应用框架的过程中，您可能会发现按柱子逐个移动、连续回答每个问题，或者创建一个所有柱子的优先问题子集作为横截面是有价值的。还建议在设计和实施解决方案的步骤之间审查框架，这是更常见的方法。这有助于架构师在投入时间和资源构建解决方案之前防止失败并提高安全性。对于这本书，我们选择将审查留到结尾，以便快速进入实践项目，认识到我们在一个安全、原型环境中进行实践。

AWS 架构良好框架还包括被称为透镜的扩展。透镜是一系列与特定领域或解决方案类型相关的额外最佳实践，例如 SaaS 应用或物联网解决方案。这些透镜帮助架构师在其领域内批判性地分析其解决方案，尽管其中的指导并不广泛适用于所有类型的解决方案，如框架的主体。在本章中，我们的审查将结合框架主体和物联网透镜之间的问题。这两个资源的链接都包含在本章的参考文献部分。在下一节中，我们将使用 AWS 架构良好框架提出的问题子集来审查我们的解决方案。

审查解决方案

在我们进行解决方案审查之前，让我们重申问题，回顾目标解决方案，并反思在这本书中构建的内容。这将帮助我们刷新我们的记忆，并使用 Well-Architected 框架来具体化解决方案审查。

反思解决方案

在我们的虚构叙述中，我们作为 Home Base Solutions 的物联网架构师，负责设计一款新的家用电器监控产品。该产品结合了一个连接消费者家庭网络并与配对的监控套件交互的枢纽设备。这些套件附着在消费者的大型家用电器上，如锅炉或洗衣机，并将遥测数据发送到枢纽设备。枢纽设备处理遥测数据，将其流式传输到云端以训练机器学习模型，并使用新的遥测数据和部署的模型在本地执行推理工作负载。以下图表显示了这些实体在消费者家庭中的相互关系：

图 10.1 – 检查 HBS 智能中心产品设计

我们的目标解决方案是在树莓派上原型化枢纽设备以收集遥测数据并运行机器学习工作负载，同时使用SenseHAT扩展模块收集传感器数据并将信号结果以视觉方式显示到 LED 矩阵。我们使用AWS IoT Greengrass将运行时环境部署到枢纽设备，以便作为组件安装和运行我们的代码。这些组件封装了我们的业务逻辑，用于收集传感器遥测数据，通过边缘和云路由数据，从云中获取资源，并运行我们的机器学习推理工作负载。

我们使用Amazon SageMaker在云中训练一个新的机器学习模型，该模型使用由枢纽设备获取并作为训练数据流式传输到云端的传感器遥测数据。该机器学习模型被部署到边缘，以智能地评估我们监控的设备健康状况，并在检测到任何异常行为时向消费者发出信号。最后，我们计划如何将我们的解决方案扩展到一组枢纽设备、它们的监控套件和机器学习模型，以及如何在生产环境中运营这个车队。以下图表回顾了我们的解决方案架构：

图 10.2 – 第一章*“数据驱动边缘机器学习简介”*中的原始解决方案架构图

在简要回顾我们的业务目标和解决方案架构以设定背景后，让我们应用 AWS Well-Architected 框架来分析我们的解决方案。

应用框架

我们将用于架构良好审查的格式是先从框架中提出一个问题，然后以 HBS 物联网架构师的身份回答。提醒一下，框架中的亮点是从基础材料和物联网透镜中选出的，以推动本章有趣的案例分析。框架中还有更多最佳实践需要考虑。

注意

以下部分从 AWS 架构良好框架和物联网透镜扩展中提取问题。例如，标记为OPS 4的问题表示它们来自架构良好框架。标记为IOTOPS 4的问题表示它来自物联网透镜扩展。这种区别对本章不相关，但它确定了问题是从哪个原始材料中复制的。

运营卓越

运营卓越支柱强化了对我们如何操作实时解决方案的思考。它将其指导分为四个子领域：组织、准备、运营和演进。这个支柱强调了组织工作文化的重要性，以及预测失败不可避免性的机制、减少人为错误的影响和从错误中学习的重要性。现在，让我们回顾这个支柱的一些问题以及我们可能会从架构师那里看到的样本回答。

OPS 4、OPS 8 和 OPS 9 – 你如何设计你的工作负载，以便你可以理解其状态？你如何理解工作负载的健康状况？你如何理解运营的健康状况？

我们将总结对这三个相关问题的回答，这些问题来自运营卓越支柱。在这个背景下，工作负载意味着与满足我们的业务目标相关的一切，例如通知客户他们的设备故障。这与运营不同，运营指的是与技术实施相关的一切，例如我们用来通知团队工作负载影响的部署机制或工具。

我们已经设计了工作负载的每个级别，以便报告某种健康状态。我们的工作负载可以在三个级别上进行定义，每个级别都有报告其状态的机制，以便我们可以自动化监控和警报。这三个级别是设备编队、运行在网关设备上的组件以及训练机器学习模型的云管道。在编队级别，网关设备通过 AWS IoT Greengrass 和 Amazon CloudWatch 等服务报告其部署的健康状况和与云的连接状态。我们可以使用 AWS IoT 设备管理 等服务来监控不健康状态的设备，并对它们采取行动。运行在设备上的组件由 IoT Greengrass 核心软件进行监控，每个组件的日志可以发送到云中进行自动化分析。机器学习训练管道报告训练准确性的指标，以便我们可以衡量满足业务目标的整体状态。

我们将在关键故障（如设备部署失败和监控套件与网关设备断开连接）上实施阈值警报。这使我们能够在故障影响我们的客户或客户需要采取行动以恢复本地操作之前，主动减轻故障。

OPS 5 和 OPS 6 – 如何减少缺陷、简化修复并提高生产流程的流畅度？如何减轻部署风险？

为了减少缺陷和减轻部署风险，我们必须在我们的测试和部署流程中包含运行我们解决方案的每个目标硬件配置的物理副本。这些设备将是首先通过 Greengrass 接收新部署的，通过在 AWS IoT Core 中将它们指定为单独的组来实现。我们可以配置我们的 CI/CD 流水线为该组创建新的部署，并在这些部署报告为成功之前，将部署推进到第一波生产设备。

无论如何，Greengrass 都会为我们提供一些即插即用的修复价值，因为默认情况下，它将回滚失败的部署到之前的状态。这有助于最小化生产设备的停机时间，并立即向我们的团队发出部署出现问题的信号。如果其中一部分设备在部署活动中失败，Greengrass 还可以停止部署分组设备。

IOTOPS 3 – 你是如何确保新配置的设备具备所需的操作先决条件的？

在我们使用 Greengrass 的解决方案中，我们了解运行 Greengrass 软件的文档化最低要求。我们使用了 IoT 设备测试器 软件来验证我们的目标硬件平台符合 Greengrass 的要求，并且可以连接到 AWS 服务。我们应该使用 IoT 设备测试器软件来验证我们想要用作 HBS 网关设备的任何未来硬件平台。

我们还应该计算所有组件消耗的必要额外资源。例如，如果我们知道所有总静态资源将在磁盘上消耗 1 GB，我们知道我们需要至少这么多，再加上存储日志、临时资源等的空间。一旦我们计算了解决方案的最小需求，我们就可以向 IoT 设备测试器添加一个自定义测试，以验证每个新的硬件目标是否准备好运行我们的解决方案。

安全

安全支柱强化了对如何维护或提高工作负载安全态势的思考，例如保护对数据和系统的访问。它将最佳实践组织成以下子领域：身份和访问管理、检测、基础设施保护、数据保护和事件响应。该支柱明确强调了定义工作负载中的资源和参与者、它们之间的边界和访问模式，以及强制执行这些边界的机制。

SEC 2 和 SEC 3 – 你如何管理人和机器的身份？你如何管理人和机器的权限？

人的身份和权限由 AWS 身份访问管理（IAM）管理。我们的客户将使用来自 OAuth 提供者（如 Google 或 Facebook）的联合身份登录到他们的管理应用，或者直接使用Amazon Cognito创建新的用户名。我们将使用策略将 Cognito 身份与其拥有的设备和交互的设备绑定。

设备的身份和权限由 AWS IAM 和 AWS IoT Core 的组合管理。设备到云的身份使用与 AWS IoT Core 注册的 X.509 私钥和证书来建立 MQTT 连接。这可以用来交换证书以获取临时的 AWS 凭证。这些临时 AWS 凭证与一个附加了策略的 IAM 角色绑定，以确定凭证可以与各种 AWS 服务做什么。通过在每个设备上使用唯一的私钥，恶意行为者无法伪造设备身份。

IOTSEC 10 – 你如何对传输中和静止状态下的数据进行分类、管理和保护？

在边缘，我们可以将数据分类为运行时数据，这些数据来自传感器或用于实现业务成果，或者操作数据，这些数据来自软件和系统日志。在我们的当前设计中，我们在管理或保护方面对运行时数据和操作数据没有进行任何不同的处理。在这里，我们有更好的机会保护任何潜在的客户隐私数据，例如来自连接摄像头的视频流。

在边缘，Greengrass 解决方案组件之间的任何传输中的数据都没有加密。我们使用 Greengrass 组件的权限模型和进程间通信（IPC）来保护通过 IPC 发布的数据的访问权限。使用 MQTT 在叶子设备和 Greengrass 设备之间传输的数据在网络中使用私钥和证书以及相互 TLS 进行加密。

在边缘，静态数据没有加密，而是依赖于 Unix 文件系统的权限来保护对数据的访问。我们必须确保我们使用适当的用户和组配置来保护静态数据的访问。在这里，我们有建立验证机制的机会，以在创建或修改新的系统用户或组时提醒我们。为了每次进行安全威胁分析，我们必须向解决方案中添加一个新的组件，以检查它是否为数据访问提供了适当的安全措施。

从边缘到云，我们应该使用相互 TLS 来加密传输中的 MQTT 流量，并使用 Amazon Signature Version 4 来加密与 AWS API 交换的任何其他流量，使用临时凭据。存储在 AWS 服务中的静态数据使用每个服务的加密策略。例如，存储在 Amazon Simple Storage Service (S3)中的数据可以使用 AWS 管理的加密密钥进行服务器端加密。

IOTSEC 11 – 你如何准备应对影响单个设备或设备群的突发事件？

我们的运营团队在设备群的运行健康指标上设置了警报。例如，如果一个设备部署失败，运营团队将收到警报的通知。如果一组设备部署失败，我们将立即呼叫我们的运营团队进行分类处理。

我们将为我们的运营团队编写一系列针对预期故障事件的运行手册，以便作为第一响应。第一步将是定义在感到对第一波生产设备满意之前所需的运行手册的最小集合。

IOTSEC 8 – 你是如何规划你的物联网设备的安全生命周期的？

我们将与我们的ODM合作，从零部件的供应链开始，通过组装和交付到我们的仓库，以包括在零售包装中，来记录安全生命周期。对我们来说，重要的是像中央处理器、易失性和非易失性内存以及存放私钥的可信平台模块（TPM）这样的部件在组装到我们的产品之前是真实的，并且没有被篡改。

我们设备中由 ODM 提供的所有 TPM 都将与我们在 AWS IoT Core 中注册的 CA 相关联。我们将在云中预先配置每个设备，以便设备可以简单地使用其受保护的凭据进行连接，而不需要任何即时注册过程。

如果我们识别出任何设备存在身份受损的情况，我们将评估证书轮换活动是否是足够的缓解措施。如果不是，我们将撤销其在 AWS IoT Core 中的证书，以防止其进一步交换数据，并主动联系客户开始交换流程。

可靠性

可靠性支柱强调工作负载应继续按照其设计的方式运行，并在预期的时间运行。它将最佳实践组织到以下子领域：基础、工作负载架构、变更管理和故障管理。该支柱强调诸如故障转移和恢复机制等概念，以应对故障，测试恢复场景，并在稳态操作期间以及部署变更后监控可用性。

REL 3 – 你如何设计你的工作负载服务架构？

我们使用面向服务的架构设计了我们的工作负载服务架构，并实现了隔离、解耦服务的原则。我们使用这种架构来简化设计、编写、测试和发布代码，以及最小化孤立服务出现故障对解决方案的影响。我们使用核心 Greengrass 软件及其组件定义的机制来规范化这种架构设计。

REL 8 – 你如何实施变更？

对于我们的边缘解决方案，我们通过 Greengrass 部署使用版本化组件来逐步更新设备上运行的软件。我们在测试设备上部署更改之前，会将这些更改部署到生产设备上。在设备上失败的部署将自动回滚。如果整个机队的 10%部署失败，则将整个部署回滚到该机队。

对于我们的云解决方案，我们使用 CloudFormation 模板和堆栈来配置云资源并对其进行更改。我们不通过 IaC 机制编写的生产基础设施进行任何更改。这些更改在部署之前必须由团队中的同事进行审查。我们可以使用 CloudWatch 度量指标和日志来监控我们配置的资源，以检测任何不健康的状态，并在运营影响的情况下回滚 CloudFormation 更改。

IOTREL 3 – 在与云通信时，你如何处理设备可靠性？

我们设计的边缘机器学习解决方案旨在独立于云运行。在网络不稳定期间，某些功能会受到 影响，例如将失败事件发布到云中，以便向客户的移动应用推送通知。预定发送到云的事件、遥测数据和日志将在本地缓冲，并在网络不稳定问题解决后最终到达云中。已发布到云但未收到确认的数据将重试，例如，使用 MQTT 服务质量设置为至少一次的服务级别。

当云尝试与设备通信时，例如当新的部署准备就绪等待获取时，我们使用持久化服务，如 Greengrass，这些服务会跟踪离线且尚未完成待定部署活动的设备。

REL 11 和 IOTREL 6 – 你如何设计你的工作负载以承受组件故障？你如何验证你物理资产的不同硬件故障模式？

（在这种情况下，“组件故障”并不特指 Greengrass 组件。）在这里，我们使用面向服务的架构来承受组件故障，以便我们的任何自定义服务都应该能够在不使整个解决方案崩溃的情况下失败。例如，如果读取温度传感器的组件失败，中心设备边缘解决方案仍然可以运行，尽管在检测设备异常时的准确性会降低。

Greengrass 提供的一些组件，如果失败，可能会影响我们解决方案的多个结果，例如 IPC 消息总线。如果这些组件失败，我们的自定义组件将无法发布新消息，接收组件将停止接收新消息以进行处理。我们应该更新发布消息的自定义组件代码，以便在 IPC 不可用的情况下能够缓冲消息，我们还应研究 Greengrass 的行为及其在提供的功能（如 IPC）受到影响时的自我恢复能力。

如果我们的任何网络物理硬件接口失败，例如传感器不再能够被读取，我们就不会再看到通过 IPC 发布的值，并在使用传感器的相应软件组件中收到错误消息。我们可能能够通过上传的日志远程对这些事件进行分类。如果我们的计算、内存、磁盘或网络硬件组件失败，整个解决方案可能会被禁用，需要本地分类或通过我们的客户支持计划更换设备。

性能效率

性能效率支柱强调我们在消耗的资源与可用预算之间取得平衡，并且随着技术的发展，我们继续寻求效率提升。它将最佳实践组织到以下子领域：选择、审查、监控和权衡。此支柱强调将复杂任务委托给已解决的问题，规划数据在正确的时间出现在正确的位置，并减少你的团队必须管理的基础设施数量。

PERF 2 – 你如何选择你的计算解决方案？

关于我们机器学习模型训练的需求，我们最初将在 AWS 上根据默认设置选择计算实例，并通过试错法评估是否还有更经济的实例配置可供我们在训练生命周期中使用。由于机器学习是我们消费者产品的差异化优势，我们希望在客户设备上通过适当的服务级别协议（SLA），例如在积累足够训练数据以生成准确模型后的一个工作日内，启用机器学习模型。随着我们生产规模的扩大，我们可能会发现批量处理训练作业以最大化利用已分配的计算实例是有价值的。

关于我们边缘的目标设备硬件，我们将测量原型设备（如树莓派）上我们的完整生产工作负载的性能，并根据计算设备的整体利用率迭代到生产硬件配置文件。我们希望在总利用率中留出一些缓冲空间，以防将来作为未来升级部署新工作负载。

PERF 6 - 你如何演进你的工作负载以利用新版本？

我们将监控 AWS 的新版本，以寻找引入新的管理 Greengrass 组件的机会，这些组件可以为我们边缘工作负载处理更多的无差别重负载。我们还将监控 Amazon SageMaker 和Amazon Elastic Cloud Compute产品组合的新版本，以寻找优化我们的机器学习训练管道的机会。

PERF 7 - 你如何监控你的资源以确保它们的表现？

我们将使用管理组件来启用AWS IoT Device Defender从每个设备收集系统级指标，例如计算、内存和磁盘利用率。我们将监控异常和阈值违规，并对任何检测到的影响采取行动。

IOTPERF 10 - 设备到你的物联网应用的数据传输频率是多少？

对于高优先级的业务成果和操作警报，例如通知他人检测到的异常或传感器值下降，数据将从设备传输到云，一旦此类数据可用。对于其他类别的数据，例如将组件日志或传感器遥测数据用于新的机器学习训练作业，数据可以每天批量传输。

成本优化

成本优化支柱强调了如何以最低成本运营满足业务需求解决方案的方法。它将最佳实践组织到以下子领域：财务管理、使用意识、经济高效的资源、管理供需以及随时间优化。该支柱强调衡量云支出的整体效率，衡量投资回报以确定下一步优化的优先级，并寻求可以降低成本而不影响要求的实施细节。

成本 3 - 你如何监控使用情况和成本？

我们将结合使用 Amazon CloudWatch 来监控指标和日志，以及 AWS 计费控制台来监控消耗的 AWS 服务的使用情况和成本。预计最大的成本来源将是我们的机器学习训练工作负载所需的云计算实例。我们将监控与每个设备相关的成本，以识别异常情况，即单个设备在云成本上的消耗超过了整个机队的平均值。

IOTCOST 1 和 IOTCOST 3 – 您如何选择从您的物联网平台向其他服务提供批量、丰富和聚合数据的方法？您如何优化设备与您的物联网平台之间的有效载荷大小？

为了从我们的设备监控套件中捕获传感器遥测数据，我们将批量处理遥测数据，以便每天传输到云端，这些数据将直接发送到 AmazonS3。这将大大降低传输成本，与传感器组件发布每个有效载荷时的传输成本相比。我们没有计划进一步优化任何在 Greengrass 设备和云端之间交换的操作消息的有效载荷大小，因为我们预计这些消息不会构成显著的费用。

这就结束了我们对 AWS 优秀架构审查的示例回答。您是否对任何回答有异议或希望进行修改？审查过程是一个指南，并不是为了包含正确或错误的答案。定义答案的完整性以及是否因审查而产生行动项目取决于您和您的协作团队。团队无法回答或无法详细回答的问题是深入了解您的架构和提前预见问题的良好机会。在下一节中，我们将提供一些关于 AWS 功能的最终覆盖，这些功能可能对您有用，但未包含在本书的范围之内。

深入了解 AWS 服务

本书以一个虚构的叙事作为特定用例，有选择性地突出 AWS 可用的功能，这些功能可用于将智能工作负载交付到边缘。您可以使用 AWS IoT Greengrass、AWS IoT 套件中的其他服务、ML 服务套件以及 AWS 的其他部分实现更多功能，这些功能超出了我们在这本书中能够涵盖的范围。

在本节中，我们将指出一些可能对您作为该领域架构师感兴趣的功能和服务，同时提供一些关于如何扩展您迄今为止构建的解决方案以进一步提高您专业性的想法。

AWS IoT Greengrass

在解决方案中使用的 Greengrass 功能代表了 Greengrass 解决方案可以提供的灵活性的一个子集。你学习了如何使用组件进行构建，将软件部署到边缘，获取机器学习资源，并利用内置功能在整个边缘和云中路由消息。我们在中心设备原型中使用的组件主要下载 Python 代码并启动与 IPC 消息总线交互的长生命期应用程序。组件可以被设计为每次部署、每次设备启动或按计划运行一次性的程序。它们可以被设计为运行作为其他组件软件依赖项的服务，或者等待其他组件图中的依赖项成功运行后再启动。

您的组件可以通过订阅有关部署事件的通知来与部署生命周期交互。例如，您的软件可以请求延迟，直到达到一个安全里程碑（例如清空队列或将内存中的记录写入磁盘），或者向 Greengrass 核心发出信号，表明它现在已准备好更新。

组件可以向其他组件发出信号，指示它们应该暂停或恢复其功能。例如，如果一个负责有限资源（如磁盘空间或内存）的组件识别到高利用率事件，它可以请求消耗这些资源的组件暂停，直到利用率回到期望的范围。

组件可以通过请求当前配置状态、订阅进一步的更改或为组件的配置设置新值来相互交互配置。回到之前的例子，如果一个资源看门狗组件不想完全暂停消耗组件，它可以指定消耗组件的新配置值，以便更频繁地写入样本值或进入低功耗状态。

所提到的三个功能都使用 Greengrass IPC 实现，并且是您组件和治理组件生命周期的 Greengrass 核心之间的本地消息传递的简单应用。这些功能在您的解决方案设计中有很多实用价值，并且展示了您如何在 IPC 之上构建组件交互的系统。

在您继续作为边缘机器学习解决方案架构师之旅的过程中，以下是一些您应该了解的 Greengrass 的更多功能。有关 Greengrass 功能的文档可以在网上找到：docs.aws.amazon.com/greengrass：

• 核配置：当在您的设备上安装 Greengrass 核心软件（或稍后通过更新配置的部署）时，您有几种选项可以探索以优化消耗的资源、网络配置以及设备如何与云服务交互。所有这些都有智能默认设置以帮助您开始，但您的生产实现可能需要根据您精心设计的审查结果对这些设置进行细化！

• 在 Docker 容器中运行 Greengrass：在这本书的解决方案中，我们将 Greengrass 作为在 Raspberry Pi 上运行的服务安装。Greengrass 也可以安装在运行在其自己的 Docker 容器中的设备上。您可能会发现这对于使用 IaC 简化跨设备的自定义安装很有价值。这也可以用来将您的整个 Greengrass 解决方案作为一个隔离的服务作为更大解决方案架构的一部分来部署到设备上。

• 将 Docker 容器作为组件运行：如果您将 Docker 容器作为新组件包装，则无需修改即可将其导入边缘 ML 解决方案。Greengrass 提供了一个管理组件，用于与设备上运行的 Docker Engine 交互。它可以从 Docker Hub 和 Amazon Elastic Container Registry 下载镜像。这可以加快您在现有工作负载中采用 Greengrass 的步伐，其中您的业务逻辑已经在 Docker 容器中定义。

现在，让我们回顾 AWS IoT 服务套件中的更多功能，这些功能可以为您的下一个项目提供动力。

AWS IoT 服务

AWS IoT 服务套件涵盖了设备连接和控制、大规模管理车队、检测和缓解安全漏洞、执行复杂事件检测、分析工业物联网操作等多种用例。Greengrass 是设计边缘解决方案的模型实现，它基于现有的 AWS IoT 服务，并以强大的方式与它们原生集成。在设计您的下一个边缘 ML 解决方案时，这里有一些 AWS IoT 套件中的更多功能可以查看。这些功能的文档可以在docs.aws.amazon.com/iot找到：

• 安全隧道：在第四章“将云扩展到边缘”中，您已将系统和组件日志上传到 Amazon CloudWatch 以远程诊断您的设备。如果您需要比日志捕获的信息更多，或者需要在设备上运行命令但不想只为该命令编写组件，会发生什么？使用安全隧道，您可以指示您的设备建立到操作员的 SSH 隧道，从而消除对设备入站网络连接的需求。Greengrass 有一个管理组件可以在您的设备上启用此功能。

• 舰队索引：当使用 AWS IoT Core 的影子服务同步您的 Greengrass 设备、连接到中心节点的叶设备以及您的组件的状态时，您可以使用 AWS IoT 设备管理的舰队索引服务对所有的影子进行索引，以便进行查询和动态组。舰队索引使您能够轻松搜索解决方案中基于影子的实体进行分析和操作。例如，您可以创建一个报告电池电量低于 20%的设备的动态组，并通知您的远程技术人员优先更换这些设备的电池。

• 设备卫士：AWS IoT 设备卫士是一项自动化检测和缓解安全漏洞的服务，可以使用机器学习构建您车队正常行为的配置文件。该服务可以向您的安全团队报告以异常方式运行的设备，例如网络流量激增或断开连接事件，这可能代表恶意行为者干扰您的设备。

现在，让我们回顾 AWS 机器学习套件中的更多服务，这些服务可以为您的工作负载添加更多智能。

机器学习服务

AWS 的机器学习服务涵盖了从帮助开发者训练和部署模型到解决特定用例的高级人工智能服务。虽然以下服务目前仅在 AWS 云中运行，但它们可以帮助增强您与远程服务协同工作的 AI 边缘解决方案：

• Amazon Lex 和 Polly：您可以使用为 Amazon 的 Alexa 语音助手提供动力的相同技术将语音界面构建到您的解决方案中。Lex 是一项用于从语音和文本输入构建交互式体验的服务。Polly 是一项将文本转换为语音的服务。您可以使用两者来处理来自您的设备的音频请求，并返回逼真的合成响应。

• Amazon Rekognition：您可以使用来自云端的更深入见解来增强边缘的智能工作负载。例如，您的边缘机器学习工作负载可能使用更简单的运动或对象检测模型来捕获重要事件作为视频剪辑，然后将这些剪辑仅发送到云端，由 Rekognition 等服务进行更深入的分析。这种升级模式可以帮助您减少边缘所需的资源，并降低仅在云中运行机器学习工作负载的成本。

接下来，我们将提供一些想法，关于您可以采取的下一步行动来扩展本书的解决方案。

提高熟练度的想法

在您的中心设备运行本地机器学习工作负载的解决方案中，您已经练习了使用所有必要的工具将智能工作负载部署到边缘。您可能已经有了将本书中学到的知识应用于实际项目并巩固所学内容的计划。如果您正在寻找下一步行动的灵感，我们已整理了一些想法，以扩展您已经构建的内容，从而进一步提高您对本书主题的熟练度：

• 添加新的网络物理接口：Raspberry Pi 的 GPIO 接口、USB 端口和音频输出插孔为扩展网关设备的网络物理接口提供了广泛的设计空间。你可以添加一个新的传感器，编写一个用于读取其值的自定义组件，将值流式传输到云端，并训练你的机器学习模型以检测该数据流中的异常。你可以插入一个扬声器并生成针对我们在第四章中部署的对象检测模型的音频警报。你可以更进一步，从 Amazon Polly 合成自定义语音音频，并通过扬声器播放！

• 构建设备监控套件的原型：在这本书中，我们使用 SenseHAT 的板载传感器来获取测量值，作为设备监控套件的近似。使用两个设备，你可以将一个设备配置为网关设备，另一个配置为监控套件，通过 MQTT 将套件连接到网关，如第四章中所示，将云扩展到边缘。从网关设备中移除发出传感器读数的组件，并编写一个新的组件，该组件订阅 MQTT 主题，并将监控套件的新消息转发到相同的 IPC 主题，如第三章中定义的，构建边缘。你的监控套件设备不需要部署 Greengrass；它可以运行类似于我们在第四章中看到的，将云扩展到边缘的应用程序，用于通过 AWS IoT 设备 SDK 连接到 Greengrass MQTT 代理。

• 执行自己的 AWS 架构审查：本章中我们提供的示例审查突出了向架构师提出的一些问题，并保持答案在较高层次的分析。作为下一步，你可以完成剩余的审查，使用本章未包含的问题，并利用这个机会记录你对相同问题的答案，也许是为了你的工作负载。

你是否有其他项目扩展的建议，或者想要展示你构建的内容？请随时通过在本书的 GitHub 仓库中打开拉取请求或问题与我们的读者和架构师社区互动！

摘要

这就是我们为您准备的所有内容！我们，作为作者，相信这些是您可以使用的最佳技术、实践和工具，以继续您作为边缘机器学习解决方案架构师的旅程。虽然一些工具是特定于 AWS 的，但其他所有内容通常都应能帮助您构建这类解决方案。使用 AWS IoT Greengrass 构建的系统可以轻松地包括与您的网络服务或微软、谷歌等云服务提供商的服务进行通信的组件。本书的指导原则是优先教授您如何构建以及如何思考构建边缘机器学习解决方案，而不是使用特定的工具。

在您迈出下一步时，无论是扩展本书的原型中心设备、启动一个新的解决方案还是现代化现有的解决方案，我们希望您能从反思您学到的经验教训和批判性地思考有助于您实现目标的权衡中找到价值。我们欢迎您通过本书 GitHub 存储库中包含的沟通方式对我们本书的内容和技术示例提供反馈。我们致力于持续提供优秀的示例和教程，认识到在信息技术领域，工具会进化，依赖关系会更新，代码会出错。

我们衷心感谢您决定抽出宝贵的时间来探索使用我们书籍带来的智能工作负载到边缘的世界。我们祝愿您在未来的努力中一切顺利！

参考文献

以下资源提供了关于本章讨论的概念的更多信息：

• 基础设施即代码白皮书：d1.awsstatic.com/whitepapers/DevOps/infrastructure-as-code.pdf

• AWS 架构中心（物联网）：aws.amazon.com/architecture/iot/

• AWS IoT Greengrass 文档：docs.aws.amazon.com/greengrass

• AWS 优秀架构主页：aws.amazon.com/architecture/well-architected/

• AWS 人工智能服务：aws.amazon.com/machine-learning/ai-services/

• 物联网图集：iotatlas.net