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

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

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

译者：飞龙

协议：CC BY-NC-SA 4.0

前言

物联网（IoT）已经改变了企业思考世界和与世界互动的方式。传感器可以测量高容量工业制造操作的绩效或偏远岛屿的日常环境健康。物联网使得能够在各种精度水平上研究世界，并在任何地方实现数据驱动决策。机器学习（ML）和弹性云计算加速了我们理解和分析物联网产生的海量数据的能力。通过边缘计算，数据分析和机器学习模型可以在数据生成的地方本地处理信息。

本书将教会你如何结合边缘计算和机器学习技术，以实现下一代网络物理结果。你将从发现如何使用来自亚马逊网络服务的软件，如 AWS IoT Greengrass，在边缘设备上创建软件应用程序开始。随着你的进步，你将学习如何从边缘到云处理和流式传输物联网数据，并使用亚马逊 SageMaker 对其进行训练。本书还展示了如何优化这些模型，并在边缘运行以实现最佳性能、成本节约和数据合规性。

在本书结束时，你将能够确定自己的物联网工作负载，将机器学习的力量带到边缘，并在生产环境中运行这些工作负载。

本书面向对象

本书面向负责将分析和机器学习支持的软件解决方案交付到边缘的物联网架构师和软件工程师。希望学习和构建物联网解决方案的亚马逊网络服务用户会发现本书很有用。要充分利用本书，需要具备在 Linux 上运行 Python 软件的中级经验。

本书涵盖内容

第一章，《利用机器学习的数据驱动边缘简介》，介绍了边缘的概念以及机器学习在边缘运行时的独特价值。它提供了消费者和工业环境中用例的高级概述。它为将指导本书动手活动的虚构场景设定了背景。

第二章，《边缘工作负载基础》，概述了设计边缘解决方案的关键考虑因素，并介绍了 AWS IoT Greengrass 的使用。

第三章，《构建边缘》，深入探讨了通过更高级的 AWS IoT Greengrass 使用来构建边缘解决方案的下一级细节，用于编写业务逻辑的软件组件。

第四章, 将云扩展到边缘，介绍了如何使用原生云连接构建边缘解决方案，并通过互联网将软件部署到远程设备。它还介绍了 AWS 提供的软件组件，用于抽象化边缘功能的一般需求。

第五章, 从边缘摄取和流式传输数据，介绍了如何对物联网工作负载进行数据建模以及为什么这很重要。它还介绍了在边缘收集、摄取和处理数据流的多种架构模式和反模式。

第六章, 在云上处理和消费数据，解释了物联网与大数据技术的集成如何使云上实现高容量复杂数据处理。它还深入探讨了如何将数据处理设计模式从边缘扩展到云，以解锁高级用例。

第七章, 边缘的机器学习工作负载，介绍了在物联网工作负载背景下机器学习的概念。它还深入探讨了机器学习工作流程的不同阶段，以及适用的设计模式和反模式。

第八章, 边缘的 DevOps 和 MLOps，解释了如何利用 DevOps 和 MLOps 的概念来支持物联网工作负载，以实现从云到边缘的敏捷开发实践。

第九章, 大规模车队管理，介绍了使用云原生物联网工具链进行车队管理的概念。它还深入探讨了在现实世界中大规模接入物联网设备的不同场景和机制。

第十章, 使用 AWS Well-Architected Framework 审查解决方案，通过 AWS 多角度审查框架的关键教训和步骤总结，结束本书。它还针对从本书中学到的经验，为物联网架构师提供下一步行动的建议。

为了充分利用这本书

您需要一个运行 Windows、macOS 或 Linux 的个人电脑。这台电脑在终端中使用 AWS 命令行界面，通过网页浏览器使用 AWS 管理控制台。第二个基于 Linux 的系统充当边缘设备，并托管运行 AWS IoT Greengrass 的边缘解决方案。这个第二个系统可以是本地或远程的虚拟机，或者是一个实际的设备，如 Raspberry Pi。为了获得真实的物联网体验，我们建议使用带有 SenseHAT 扩展板的 Raspberry Pi 3B（或更高版本）来完成本书的动手实践部分。如果您没有硬件设备，可以使用 Ubuntu Linux 虚拟机。最终，您可以在有或没有第二个设备的情况下完成所有动手步骤。

使用 AWS 提供的云服务确实会产生一些费用。您需要访问 AWS 账户或自己创建一个。完成所有动手实践部分可能会产生高达 25 美元（USD）的账单。您可以选择跳过机器学习训练步骤以降低费用至 5 美元以下。

在本书编写时，AWS IoT Greengrass v2 不支持 Windows 安装。与边缘解决方案相关的动手实践部分仅适用于 Linux，不适用于 Windows。

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

下载示例代码文件

您可以从 GitHub 下载本书的示例代码文件，网址为 github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge。如果代码有更新，它将在 GitHub 仓库中更新。

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

下载彩色图片

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

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

使用的约定

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

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

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

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

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

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

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

$ git clone PacktPublishing/Intelligent-Workloads-at-the-Edge-

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

小贴士或重要注意事项

看起来像这样。

联系我们

读者反馈始终受到欢迎。

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

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

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

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

分享您的想法

一旦您阅读了《边缘智能工作负载》，我们很乐意听到您的想法！请点击此处直接进入此书的亚马逊评论页面并分享您的反馈。

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

第一部分：简介和先决条件

本节将向您介绍常见的边缘概念、角色、挑战以及用于实现边缘成果的工具。本节还将向您介绍您将在动手实践章节中构建的项目。

本节包含以下章节：

• 第一章**，机器学习驱动的边缘介绍

第一章：第一章：机器学习驱动的边缘数据驱动介绍

本书的目的在于分享针对在边缘（计算拓扑中与模拟接口数字和相反方向最近的空间）运行的解决方案的端到端（E2E）开发的规范性模式。具体来说，本书专注于那些机器学习（ML）技术带来最大价值的边缘用例，并教你如何使用亚马逊网络服务（AWS）提供的现代工具开发这些解决方案。

在本章中，你将了解实现网络物理结果的基础、挑战、角色和工具，这些工具是交付这些结果所共有的。本章简要介绍了智能家居和工业物联网（IoT）环境，并设定了贯穿本书的实践项目的场景。它将描述机器学习如何改变我们加速决策的能力，使其超越云。你将了解你将使用 AWS 服务（如AWS IoT Greengrass和Amazon SageMaker）构建的端到端项目的范围。你还将了解在进入第一手实践章节第二章，“边缘工作负载基础”之前需要满足哪些技术要求。

本章将涵盖以下主题：

• 活在边缘

• 将机器学习带到边缘

• 完成工作的工具

• 智能家居和工业物联网的需求

• 设定场景：现代智能家居解决方案

• 实践前的必备条件

活在边缘

边缘是计算拓扑中与模拟接口数字和相反方向最近的空间。第一代计算系统的边缘，例如 1945 年的电子数值积分器和计算机（ENIAC）通用计算机，仅仅是用来输入指令和接收打印输出的接口。除非直接站在它们面前，否则无法访问这些接口。随着 20 世纪 70 年代远程访问大型机计算的出现，计算的边缘进一步扩展到桌面上的公共终端，并通过同轴电缆连接到大型机。用户可以从实验室或工作站方便地访问本地大型机的公共资源，利用文字处理器或电子表格等高级功能完成工作。

人类使用边缘进行计算的发展随着计算能力的增加和尺寸、成本的降低而继续。我们每天使用的设备，如个人电脑和智能手机，为我们提供了无数的结果。一些结果完全在边缘（设备上）提供，但许多工作只有在连接到互联网时才能完成，并消耗远程服务。人类边缘工作负载通常是多样化的、多用途的，并处理各种动态性。我们不可能列出我们可以用智能手机及其网络浏览器做的一切！这些边缘的例子都有一个共同点，即人类既是计算任务的操作者也是接收者。然而，边缘不仅仅是人类和硅之间的接口。

边缘的另一个重要历史趋势是自主功能。我们设计计算机器来感知和行动，然后将它们部署在可能完全没有人类交互的环境中。自主边缘的例子包括在制造业装配中使用的机器人、卫星和气象站。这些边缘工作负载与人类驱动的负载不同，它们往往高度专业化、单用途，并且处理很少的动态性。它们执行一组特定的功能，持续执行这些功能，直到过时。以下图表提供了一个关于人类驱动界面和边缘自主机器随时间推移的简单历史：

![图 1.1 – 从 1950 年到 2020 年边缘网络物理接口的时间线]

![图片 B17595_01_001.jpg]

![图 1.1 – 从 1950 年到 2020 年边缘网络物理接口的时间线]

在今天无线通信、微控制器和微处理器、电气效率和耐用性的技术进步中，边缘可以无处不在。你们中的一些人可能正在海拔 10 km 的电子阅读器上阅读这本书，这是一种边缘设备，以 900 kph 的速度巡航。旅行者 1 号航天器是最远的边缘解决方案，在撰写本文时，距离地球 152 AU 仍在继续运行！这里的趋势是，随着时间的推移，通往边缘以及边缘本身的能力范围将继续增长，这条路径的长度（以及路径上的点数！）以及这些能力可以部署的偏远程度也将增加。以下图表说明了实体、计算能力和能力在计算拓扑结构中的扩展规模：

![图 1.2 – 从云到传感器的计算规模示意图]

![图片 B17595_01_002.jpg]

图 1.2 – 从云到传感器的计算规模示意图

我们的世界充满了传感器和执行器；随着时间的推移，越来越多的这些设备正在加入物联网。传感器是任何从我们的模拟世界获取测量值并将其转换为数字数据的组件。执行器是任何接受一些数字命令并将一些力量或变化应用于模拟世界的组件。有如此多的信息需要收集、推理和采取行动。以下原因使得开发边缘解决方案成为一个令人兴奋的前沿领域：

• 在我们今天的世界中，有大量的可能性和问题需要解决。我们需要更多的创新和解决方案来解决全球问题，例如联合国（UN）定义的 17 个可持续发展目标。

• 开发边缘解决方案的成本因素在下降，这降低了实验的门槛。

• 将解决方案开发置于任何有学习愿望的人可触及之处的工具正在成熟并变得更容易使用。

本书将教你如何使用现代边缘到云技术来开发边缘解决方案的软件，包括如何编写与物理传感器和执行器交互的软件，如何与其他本地设备和云交换数据，以及如何在边缘从先进的机器学习技术中获得价值。比“如何”更重要的是“为什么”——换句话说：我们为什么以这种方式构建解决方案？本书还将解释构建良好架构的解决方案的架构模式和技巧，这些解决方案将超越特定技术和工具的时代。

实施细节，如编程语言和框架，随着流行度、必要性和技术突破而出现和消失。我们构建什么以及我们为什么以特定方式构建它们的模式经得起时间的考验，并将为你的许多未来项目提供服务。例如，1995 年设计模式：可重用面向对象软件元素由Gamma、Helm、Johnson和Vlissides所著，尽管作者当时使用的工具已经发展，但至今仍在引导软件开发者。我们，作为作者，不能将自己与这些伟大的思想家或他们的优秀书籍相提并论，但我们将其作为我们如何撰写本书的一个例子。

边缘解决方案的常见概念

为了本书的目的，我们将扩展边缘的定义，将其定义为任何在云、数据中心和互联网骨干之外运行的物理-数字解决方案的组件。边缘解决方案的例子包括控制家庭中智能灯泡的无线电开关、在采矿地点记录拖拉机拖车的工作周期和发动机遥测数据的传感器、为地铁通勤者提供通道的旋转门、在大西洋中漂流的气象浮标、使用新增强现实（AR）游戏中的摄像头的智能手机，当然还有旅行者 1 号。在数据中心运行以保持服务器冷却的环境控制系统仍然是边缘解决方案；我们的定义旨在突出那些远离全球计算拓扑重力的组件。以下图表显示了在此计算拓扑中，距离数据中心重力更远的地方发生的计算示例：

![图 1.3 – 不同距离的边缘示例

![img/B17595_01_003.jpg]

图 1.3 – 不同距离的边缘示例

物理-数字解决方案是指将硬件和软件结合在一起，以实现数字世界与模拟世界的互操作。如果模拟世界是我们可以测量现实并对其施加变化的属性集合，那么数字世界就是我们关于现实的捕获信息，我们可以存储、传输和对其推理。物理-数字解决方案可以是自包含的或闭环的，例如工业制造车间中的可编程逻辑控制器（PLC）或家庭中的数字恒温器。它可能自主执行某些任务，或者在本地行为者（如人或开关）的指导下执行。

因此，边缘解决方案是物理-数字解决方案的特定扩展，它意味着在某个时间点与其他实体进行通信或信息交换。它也可以在本地行为者或远程行为者（如网络服务器）的指导下自主运行。传感器为了满足需要提供数据的个人或作为输入驱动 PLC 或服务器上运行的代码来做出决策，从而提供自主功能。对寒冷的反应的模拟、人类故事是“我感觉冷，所以我将点燃火来取暖”，而数字故事可能看起来像以下在本地控制器上运行的伪代码来切换暖气：

if( io.read_value(THERMOMETER_PIN) < LOWER_HEAT_THRESHOLD ) {
     io.write_value(FURNACE_PIN, HIGH);
}

我们将进一步定义边缘解决方案，使其具备一定的计算能力，例如微控制器或微处理器来执行指令。这些解决方案至少包含一个传感器或执行器，用于与物理世界进行接口。边缘解决方案将在某个时间点与网络或物理世界中的另一个实体进行交互，例如人或其他机器。

根据这个定义，你现在最近的是什么边缘解决方案？

传感器、执行器和计算能力是边缘解决方案的最基本构建块。我们感兴趣开发的解决方案具有更多的复杂性。作为物联网架构师，你的责任是确保边缘解决方案安全、可靠、性能良好且成本效益高。良好架构的高标准意味着你需要精通网络、密码学、电气工程和操作系统等基础知识。今天的实际生产边缘解决方案集成了处理实时信号、通过多种传输媒体在系统之间通信、编写具有冗余故障恢复的固件更新以及自我诊断设备健康等功能。

所有这些都可能让人感到不知所措，而现实是，为边缘构建解决方案既复杂又繁琐。在实践中，我们使用专门定制的工具和耐用的模式，将投入的努力集中在创新和解决问题上，而不是从头开始和重新发明轮子。本书的目标是从功能性结果开始，逐步构建到端到端解决方案的全景图。沿途的学习将帮助你在构建下一个解决方案的旅程中受益。虽然本书没有涵盖该领域的每个主题，但我们将会抓住每一个机会，突出更多的教育资源，帮助你超越所涵盖的焦点领域。这就是边缘解决方案构建的全部内容！接下来，让我们回顾一下机器学习是如何融入其中的。

将机器学习带到边缘

机器学习是一项令人难以置信的技术，正在解决当今的问题。训练计算机处理大量信息的能力，用于分类新的输入和预测结果，与人类大脑所能完成的能力相媲美，在某些应用中甚至超过了人类大脑。因此，机器学习定义了开发人工智能（AI）的机制。

云端提供的强大计算能力显著缩短了训练机器学习模型所需的时间。数据科学家和数据工程师可以在数小时内而不是数天内训练生产模型。机器学习算法的进步使得模型本身变得更加便携，这意味着可以在计算和内存配置较小的计算机上运行模型。交付便携式机器学习模型的影响不容小觑。

在边缘运行机器学习模型有助于我们作为架构师提供最佳的边缘解决方案设计原则。通过在边缘托管一个便携式模型，与整个解决方案的邻近性带来了以下四个关键优势，具体如下：

• 第一，这意味着解决方案可以通过不等待远程服务器的往返延迟来最大化对依赖于机器学习推理结果的能力的响应速度。对即将发生故障的引擎发出的无数信号的延迟可以缩短到 10 毫秒（ms）而不是 100 毫秒。这种延迟程度可能决定了安全运行和灾难性故障之间的区别。

• 第二，这意味着解决方案的功能不会因网络拥塞而中断，并且可以在边缘解决方案与公共互联网断开连接的状态下运行。这为机器学习解决方案独立于云服务运行开辟了可能性。无论连接是否可用，都可以检测并预防即将发生的引擎故障。

• 第三，每次我们都可以使用机器学习模型在本地处理数据，并减少最终需要存储在云中的数据量，这样我们也能在传输过程中获得成本节约的好处。想象一下昂贵的卫星互联网服务提供商合同；在这种传输介质中，物联网架构师只想传输绝对必要的、以降低成本的数据。

• 第四，本地数据处理的好处还包括它使得必须符合法规、数据必须存储在本国或关注隐私问题（如医疗数据）的应用场景成为可能。用于挽救生命的医院设备可能需要尽可能多的智能监控，但运行时数据可能法律上不允许离开现场。

下图展示了这四个关键优势：

![图 1.4 – 边缘机器学习的四个关键优势

图 1.4 – 边缘机器学习的四个关键优势

想象一个可以携带机器学习模型的水下无人机，该模型可以对视频流中的图像进行分类。无人机可以在没有任何网络连接的情况下操作并对其图像进行推理，并且可以丢弃任何没有价值的图像。例如，如果无人机的任务是只带回独角鲸的图像，那么无人机不需要大量的存储空间来保存每个视频片段以供后续分析。无人机可以使用机器学习来分类独角鲸的图像，并且只保留那些回家的图像。随着存储成本的持续下降，但在宝贵的物料清单和空间考虑因素中，如这种边缘解决方案，携带一个可携带的机器学习模型最终可能导致显著的成本节约。

下图说明了这个概念：

![图 1.5 – 潜水无人机概念示意图，处理照片并仅存储那些本地机器学习模型识别出主体为独角鲸的照片

图 1.5 – 潜水无人机概念示意图，处理照片并仅存储那些本地机器学习模型识别出主体为独角鲸的照片

本书将教授您从边缘解决方案常见的机器数据类型中训练机器学习模型的基础知识，以及如何将这些模型部署到边缘以利用结合机器学习能力和在边缘运行的价值主张。我们还将教授您在边缘操作机器学习模型，这意味着分析模型性能，以及如何设置基础设施以部署在云中重新训练的模型更新。

本书课程范围之外是对推动机器学习和人工智能领域的机器学习驱动的数据科学的全面深入研究。您不需要在该领域具有专业知识就能理解机器学习驱动的边缘解决方案的模式。了解如何使用软件中的输入/输出（I/O）缓冲区读取和写入数据就足以使用本书中使用的机器学习工具。

接下来，让我们回顾一下我们需要构建和使用的具体工具。

完成任务的工具

本书专注于 AWS 提供的工具，以在边缘提供基于机器学习的解决方案。AWS 以 2015 年推出的 AWS IoT Core 服务为起点，建立了一套物联网服务，以帮助开发者构建受益于云能力的网络物理解决方案。这些服务范围从边缘软件，如微控制器的 FreeRTOS 实时操作系统，到使用物联网核心和物联网设备管理的设备编队指挥与控制（C2），以及通过物联网 SiteWise 和物联网事件等服务从数据中提取可操作见解的分析能力。物联网服务与亚马逊的机器学习服务套件很好地相互作用，使开发者能够使用亚马逊 SageMaker 等服务摄取大量数据，用于训练机器学习模型。AWS 还使将训练好的模型作为端点托管起来以对实时数据进行推理或将这些模型部署到边缘进行本地推理变得容易。

您需要三种软件工具来创建和操作在边缘的有目的、智能的工作负载。接下来，我们将通过其一般能力和我们使用的具体工具（由 AWS 提供，用于构建本书中的项目）来定义每种工具。任何信息技术（IT）都总是有更多的复杂性，但就我们的目的而言，这些是本书将重点关注的三种主要工具类型，以便将智能带到边缘。

边缘运行时

第一款工具是一个用于编排您边缘软件的运行时。运行时会执行您的代码，并处理来自和您的代码之间的本地事件。理想情况下，这个运行时是自我修复的，这意味着如果任何服务失败，它应该通过故障转移或重启服务来自动恢复。这些本地事件可以是触发某些代码运行的硬件中断，定时事件从模拟传感器读取输入，或将数字命令转换为改变连接的执行器（如开关）的状态。

本书的主角是 AWS 服务IoT Greengrass。这是我们将会用到的第一种工具：边缘软件的运行时。IoT Greengrass 定义了一个打包的运行时，用于编排边缘软件解决方案，以及一个网络服务，用于管理运行在网关等设备上的边缘部署的集群。在 2020 年，AWS 发布了 IoT Greengrass 的新版本，即版本 2，它将边缘软件包重新架构为一个 Apache 2.0 许可证下的开源 Java 项目。在这个版本中，开发者获得了一个新的软件开发模型，用于编写和部署链接组件，使他们能够专注于构建业务应用程序，而不是担心复杂边缘到云解决方案的基础设施。我们将在下一章深入探讨 IoT Greengrass 的更多细节，并开始使用它构建我们的第一个应用程序。

以下图表说明了物联网 Greengrass 在边缘和云中发挥的作用：

![图 1.6 – 物联网 Greengrass 在边缘和云中发挥作用的示意图]

![img/B17595_01_006.jpg]

图 1.6 – 物联网 Greengrass 在边缘和云中发挥作用的示意图

ML

第二款工具是一个机器学习库和模型。库规定了如何读取和消费模型，以及本地代码如何调用模型，也称为进行推理。模型是训练作业的输出，它将智能打包到一个更简单的框架中，用于将新的输入转换为推理。我们需要一个工具从一组称为训练集的数据中训练一个新的模型。然后，该训练模型将被打包并部署到我们的边缘运行时工具。边缘解决方案将需要相应的库和代码，这些代码知道如何处理新数据以对模型进行操作，从而得出推理。

我们第二种工具，即机器学习库和模型，由亚马逊 SageMaker 提供。SageMaker 是亚马逊为机器学习开发者提供的服务套件。包括用于准备数据以用于训练的服务、使用内置或自定义算法构建模型、调整模型以及将模型作为应用程序编程接口（API）端点管理或部署到任何需要运行的地方的服务。您甚至可以在没有任何先前经验的情况下训练一个模型，SageMaker 将分析您的数据集，选择一个算法，构建一组调整后的模型，并告诉您哪个模型最适合您的数据。

对于某些人工智能用例，例如预测数值序列和将人类手写文本解释为文本，亚马逊提供专门构建的服务，这些服务已经解决了训练机器学习模型的繁重工作。请注意，数据科学的教授超出了本书的范围。我们将使用在物联网解决方案中常见的流行机器学习框架和算法来交付结果。当我们使用框架和算法时，我们将提供理由，以便让您了解我们选择它们的过程。我们将在第四章“将云扩展到边缘”中介绍将机器学习资源部署到边缘的概念，并在第七章“边缘的机器学习工作负载”和第九章“大规模车队管理”中深入了解机器学习工作负载。

与边缘通信

第三种工具是与边缘解决方案通信的方法论。这包括将软件和更新部署到边缘硬件以及交换双向数据的机制。由于本书涵盖的边缘解决方案是与云交互的，因此需要一种在边缘和云之间传输数据和命令的方法。这可以是任何数量的开放系统互联（OSI）模型第 7 层协议，在物联网中的常见例子包括超文本传输协议（HTTP）、消息队列遥测传输（MQTT）和约束应用协议（CoAP）。

AWS 物联网服务套件满足这些需求，并在边缘运行的物联网 Greengrass 解决方案与我们将要在 Amazon SageMaker 中使用的机器学习能力之间充当桥梁。物联网核心是一项提供可扩展设备网关和消息代理的服务，适用于 HTTP 和 MQTT 协议。它将处理云连接、身份验证和授权，以及边缘和云之间消息的路由。"物联网设备管理"是一项用于大规模操作设备群的服务。它将帮助我们定义将运行相同软件解决方案的逻辑设备分组，并部署更新到我们的设备群。本书的大部分章节都将依赖于这些工具，并且重点关注在第八章，边缘的 DevOps 和 MLOps，以及第九章，大规模设备管理中的设备群管理规模。

在考虑这些工具的基础上，我们将接下来探讨那些具有机器学习能力的边缘到云解决方案需求最大的市场、人物角色和用例。

智能家居和工业物联网的需求

市场趋势和分析指出，物联网行业，尤其是工业物联网领域，将迎来快速增长。2020 年Mordor Intelligence报告《智能家居市场 – 增长、趋势、COVID-19 影响及预测（2021-2026）》预测智能家居市场将从 2020 年的 790 亿美元（USD）增长到 2026 年的 3130 亿美元。同样，2019 年Grand View Research报告《工业物联网市场规模、份额及趋势分析报告 – 按组件（解决方案、服务、平台）按最终用途（制造、物流与运输）按地区及细分预测，2019-2025》预测工业物联网市场将从 2018 年的 2140 亿美元增长到 2025 年的 9490 亿美元。在这两项研究中，估计的复合年增长率（CAGR）约为 25-30%。这意味着新产品、解决方案和服务在商业和最终消费者中取得成功的机会很大。

您可以在此处看到智能家居和工业物联网的市场预测图：

![图 1.7 – 智能家居和工业物联网的市场预测]

图 1.7 – 智能家居和工业物联网的市场预测

需要牢记的是，预测只是预测而已。只有当发明家和问题解决者，例如您和我，感到兴奋并创造出东西时，那些预测才会成为现实！理解智能家居和工业物联网解决方案未来的关键在于它们如何受到完整边缘到云模式的价值主张和本地机器学习推理的影响。我们可以反思将机器学习带到边缘的关键好处，看看这些市场的解决方案如何为创新做好准备。

智能家居应用案例

在智能家居解决方案中，功能标准是围绕环境监测（温度/电力消耗/发光），自动化状态变化（早上打开并在晚上关闭），以及引入以前不可能的便利性（在你回家的路上打开空调）。

使用该产品的首要人物是居住在部署解决方案的住宅中的最终消费者。次要人物是业主的客人、宠物、公用事业和家庭安全服务提供商。在产品设计层面，主要利益相关者是物联网架构师、安全工程师、设备制造商和数据科学家。智能家居产品在利用云中托管的人工智能和机器学习的力量时，已经探索并取得了关键的成功。

将机器学习能力部署到边缘，以下三种方式可以造福智能家居用例：

• 语音辅助界面：智能语音助手，如亚马逊的 Alexa，依赖于云来执行语音到文本的流程，以便处理命令并生成音频响应。在边缘运行语音识别模型可以帮助在网络不可用的情况下为消费者保留一些常用命令。为识别说话者并将其纳入响应中训练模型，可以增加个性化因素，并使这些语音助手感觉更加可信。

• 家庭安全：传统上，识别安全漏洞依赖于二进制传感器，如被动红外传感器用于检测运动或磁接近以检测门窗是否打开。这种简单的机制可能导致误报和未检测到的真实安全事件。智能安全的下一级别将需要复杂的事件检测，该检测分析来自训练模型的多元输入和置信度分数。本地模型可以自动评估消费者是否在家或外出，解决方案可以使用这一点来校准对事件的敏感性并升级事件通知。视频摄像头流是高数据率用例的典型例子，通过本地处理确定哪些片段上传到云端进行存储和进一步处理，这可以显著降低使用成本。

• 可持续性和便利性：简单的恒温器只能识别温度阈值被突破时的情况，并通过启动锅炉或空调系统来做出反应。传统的智能家居自动化通过读取天气预报、建立家中人员出勤的时间表，并遵守经济运行规则来改进这一点。机器学习可以通过分析更广泛的各种输入，通过推荐引擎确定如何最可持续地实现个人舒适目标，从而更进一步。例如，一个机器学习模型可能会识别并告诉我们，对于你特定的住宅，在晚上最可持续的降温方式是分 5 分钟连续运行 2 小时空调，而不是一次性运行 30 分钟。

工业用例

在制造、电力和公用事业以及供应链物流等工业领域，创新的共同点是创造有利可图的新的商业模式和降低现有商业模式的成本。为了通过 IT 世界进行创新，可以通过更好地理解客户需求和业务产生的运营数据来测试新的假设，从而实现这些目标。这种理解来自于使用更多已经收集到的现有数据，以及获取新的数据流，以解决导致有价值的新机会的假设。

根据 2015 年麦肯锡全球研究院的报告《释放物联网的潜力》，只有 1%的企业物联网传感器收集的数据被检查。使用数据的挑战在于使其对能够从中获得价值的人和系统可访问。当数据在边缘被摄取但存储在无法承担将其运送到云端进行分析的本地孤岛中时，数据几乎没有价值。这就是今天边缘解决方案可以通过本地计算和机器学习将数据转化为可操作见解的地方。

这里是工业物联网设置中边缘机器学习的三个用例：

• 预测性维护：工业企业在昂贵机械上进行投资和部署以执行工作。这种机械，如金属板材冲压机、计算机数控（CNC）路由器或挖掘机，在需要进行维护操作或更糟糕的是在工作时发生故障之前，只能以最佳状态运行有限的周期数。在保持机械处于最佳状态的同时，最大限度地减少停机时间和不必要的维护费用，是工业物联网和边缘解决方案的主要用例。通过在边缘训练模型并部署它们进行预测性维护检测，不仅可以帮助企业避免昂贵的停机事件，而且通过确保在没有高速或持续网络访问的远程环境中平稳运行，利用了本地机器学习的优势。

• 安全和安保：员工的身体安全和安保应该是任何企业的首要关注点。安全第一，这是当然的。机器学习驱动的边缘解决方案通过如计算机视觉（CV）模型等应用提高了工作场所的安全标准，这些模型可以检测到员工在没有必要的安全设备（如安全帽或安全背心）的情况下即将进入危险环境。类似解决方案也可以用来检测未经授权的人员进入（或试图进入）受限区域。当涉及到人类安全时，延迟和可用性至关重要，因此在边缘运行一个完全功能的解决方案意味着将机器学习能力与之一起带来。

• 质量保证：当人工操作员在生产线检查组件或成品时，他们会根据训练过的参考（每一批饼干都应该像这块饼干一样好吃）、与规格（厚度、光泽、铝箔强度）的比较，或人类感知（这两块木头是否有合理的相似木纹可以一起使用？）来了解哪些质量方面需要检查。机器学习创新了制造商如何捕捉人类质量检查员的直觉，以增加其操作规模和精度。通过在制造环境中部署如摄像头和计算机视觉模型等传感器，每次都可以对每个组件或最终产品（而不是任意样本）进行具有统计一致性的评估。这也为质量保证（QA）团队带来了好处，因为它将重点从检查重复性高且依赖于快速主观分析的任务转移到检查解决方案性能上。换句话说，我宁愿检查来自机器学习解决方案的 10,000 个通过检查的样本，而不是检查这 10,000 个样本中的每一个。在边缘运行这样的解决方案可以实现减少发送到云的整体数据量和最小化解决方案产生结果延迟的关键好处。

这些智能家居和工业领域的用例突出了使用机器学习驱动的边缘解决方案所能获得的益处。如果更多开发者将创新的新边缘解决方案付诸实践，那么对物联网市场增长的预测更有可能成为现实！让我们回顾一下智能家居解决方案（以及为某位潜在的建造者提供的免费产品想法），这将推动本书中的实践材料。

设置场景：现代智能家居解决方案

您将在本书的章节中构建的解决方案是一个模拟现代智能家居解决方案网关设备的解决方案。这意味着我们将使用智能家居中心的环境来收集传感器数据，分析并处理这些数据，并根据检测到的事件、日程安排和用户命令控制本地设备。我们选择智能家居环境作为本书解决方案的基础，因为它易于理解，我们预计许多读者都阅读过或亲自与智能家居控制器互动过。这使得我们能够将智能家居环境作为隐喻，快速通过实践章节，并进入精彩内容。如果您在本书中学习到的技能的目标扩展到其他领域，如工业物联网，请不要担心；本书中使用的科技和模式适用于智能家居环境之外。

现在，在我们深入探讨推动我们新智能家居产品的场景时，是时候戴上您的想象力帽子了！想象一下，您是 Home Base Solutions 的员工，这是一家专注于将新的智能家居设备推向市场的公司。Home Base Solutions 为首次使用智能家居产品的客户或寻求通过更换较旧的智能家居系统获得更好服务的经验丰富的客户提供最佳功能。

在下一个假日季节，Home Base Solutions 希望发布一款新的智能家居中心，为顾客提供他们之前未曾见过的产品：一款包含用于监控现有大型家电（如炉子或洗碗机）的传感器的产品，并使用机器学习（ML）向业主推荐何时需要维护。当机器学习模型检测到附加的设备监控套件数据中的异常时，会提供维护建议。即使公共互联网连接中断或拥堵，此功能也必须继续工作，因此机器学习组件不能仅在一个云服务器上运行。

您可以在此处看到 Home Base Solutions 设备监控套件的插图：

![Figure 1.8 – Whiteboard sketch of the Home Base Solutions appliance monitoring kit]

![img/B17595_01_008.jpg]

图 1.8 – Home Base Solutions 设备监控套件的白板草图

您在公司中的角色是物联网架构师，这意味着您负责设计描述端到端（E2E）、边缘到云的数据采集、摄取、存储、分析和洞察的软件解决方案。设计如何实现公司愿景，在中心产品中本地集成机器学习技术，以便没有对任何远程服务的持续运行硬依赖，这取决于您。

作为架构师，这也意味着你需要负责选择工具并设计如何操作这些设备的生产车队，以便客户服务和车队运营团队能够大规模管理客户设备。你不需要成为机器学习（ML）的主题专家（SME），这将是你的团队数据科学家介入的地方，但你应该设计一个与向机器学习训练作业提供数据以及运行在中心设备上的构建模型兼容的架构。

在研究了几周可用的软件技术、工具、解决方案供应商和云服务供应商之后，你决定尝试使用以下架构并通过 AWS 进行测试：

图 1.9 – 器件监控套件解决方案架构图

这有点复杂，对吧？如果这一切现在还让你感到困惑，请不要担心。我们将用本书的其余章节深入探讨这些工具，从入门级别介绍它们，介绍在生产中使用的模式，以及如何将它们结合起来以产生结果。每一章将专注于一个组件或子部分，随着时间的推移，我们将朝着这个整体概念努力。以下是对各个组件及其关系的分解：

1. 由智能家居中心设备控制的传感器和执行器，例如灯光及其开关或调光器。这些将通过 Raspberry Pi Sense HAT、与 Raspberry Pi 兼容的自己的硬件模块或通过软件组件进行模拟。

2. Home Base Solutions创新家用电器监控套件。这些套件的数据流将在本书中作为软件组件实现。

3. 在智能家居中心设备上运行的流缓冲区，用于处理家用电器的运行时数据。

4. 存储在中心设备上的机器学习模型（每个家用电器一个），用于调用从家用电器监控套件流出的传入遥测数据。

5. 所有这些都是在运行在Home Base Solutions中心设备及其由 IoT Greengrass Core 软件部署和运行的组件的边缘软件解决方案中实现的。

6. 在物联网 Greengrass 边缘解决方案内部运行的组件通过 MQTT 消息和 AWS IoT Core 服务与 AWS 云交换消息。

7. AWS IoT Core 的规则引擎使云解决方案的云侧能够执行提取-转换-加载（ETL）操作和消息转发。

8. 家用电器监控数据存储在 Amazon 简单存储服务（S3）。

9. Amazon SageMaker 使用家用电器监控数据作为训练和重新训练机器学习模型的输入。

10. 物联网 Greengrass 的云服务，利用物联网设备管理（IoT Device Management）的本地功能，如组和作业，将代码和资源部署到智能家居中心设备车队。

11. 训练好的机器学习模型作为资源部署回边缘进行本地推理。

12. 一种本地反馈机制，例如发光二极管（LED）或扬声器，向客户发出信号，表明已检测到异常，并建议进行维护活动。

13. 一种网络反馈机制，例如向移动应用程序推送通知，向客户发出维护活动的信号，并提供有关异常事件的更多上下文信息。

14. 客户支持和车队运营团队使用一系列工具，如车队中心、设备守护者和云监控，来监控客户设备的健康状况。

到本书结束时，您将构建整个解决方案，并拥有将类似解决方案应用于您自己的业务需求所需的技能。架构的模式和整体形状保持一致。具体设备、网络和结果实现的细节则因项目而异。

实践前的准备

为了跟随本书的实践部分，您需要访问两台计算机系统。

注意

在撰写本文时，AWS IoT Greengrass v2 不支持 Windows 安装。与边缘解决方案相关的实践部分是针对 Linux 的，不支持在 Windows 上运行。

系统 1：边缘设备

第一个系统将是您的边缘设备，也称为网关，因为它将作为一个或多个设备和解决方案的云组件的代理。在物联网 Greengrass 术语中，这被称为Greengrass 核心。此系统必须运行 Linux 操作系统的计算机，或 Linux 系统的虚拟机（VM）。AWS IoT Greengrass 版本 2（v2）的运行时软件在撰写本文时依赖于 Linux。本书的建议是使用运行最新版本 Raspberry Pi OS 的树莓派（硬件版本 3B 或更高）。合适的替代方案包括 Linux 笔记本电脑/台式机、运行 Linux 镜像的虚拟化产品，如 VirtualBox，或云托管的 Linux 实例，如 Amazon 弹性计算云（EC2）、Azure 虚拟机或 DigitalOcean 滴答。

我们首选树莓派，因为它提供了与物理传感器和执行器交互的最简单方式。毕竟，我们正在构建一个物联网项目！因此，我们将为使用虚拟环境来完成实践部分的读者提供代码示例，以模拟传感器和执行器的功能。用于覆盖传感器和执行器用例的推荐扩展套件是树莓派传感器 HAT。市面上有许多与树莓派兼容的扩展板和模块套件。本书中的用例可以根据需要完成或修改，以适应您所拥有的设备，尽管我们不会涵盖软件示例之外的替代方案。

您可以在此处看到带有 Sense HAT 扩展板的树莓派 3B 的视觉表示：

图 1.10 – 配有 Sense HAT 扩展板的 Raspberry Pi 3B

为了降低解决方案的物料清单（BOM）成本，我们将边缘通信的边界设置在网关设备本身。这意味着在本书的解决方案中，没有设备通过无线方式与网关通信，尽管在智能家居产品的实际应用中可能会使用某种无线通信方式。

如果你正在使用本节中概述的推荐组件，你将能够访问一系列传感器、按钮和反馈机制，这些机制模拟了智能家居网关设备与家中安装的连接设备之间的互操作性。从这个意义上说，设备之间的通信和智能家居中心之间的通信成为与这里展示的软件设计模式正交的实现细节。

系统 2：指挥与控制（C2）

第二个系统将是你的 C2 环境。这个系统可以是基于 Windows、Mac 或 Unix 的操作系统，你将在这个系统上安装和使用 AWS 命令行界面（AWS CLI）来配置、更新和管理你的边缘解决方案。IoT Greengrass 支持本地开发周期，因此我们将直接使用边缘设备（或通过第二个系统的 Secure Shell（SSH））开始，然后在后面的章节中专门使用 C2 系统进行远程操作。

这里是一个简单的需求列表：

• 一个 AWS 账户

• AWS 账户中具有管理员权限的用户

• 第一个系统（边缘设备）：

  • 基于 Linux 的操作系统，如 Raspberry Pi OS 或 Ubuntu 18.x

    • 推荐：Raspberry Pi（硬件版本 3B 或更高）

    • 必须是 Armv7l、Armv8 (AArch64) 或 x86_64 架构

  • 1 80、443 和 8883

  • 通过包管理器安装和升级软件包的 sudo 访问权限

  • （可选）Raspberry Pi Sense HAT 或等效的传感器和执行器扩展模块

• 第二个系统（C2 系统）：

  • 基于 Windows、Mac 或 Unix 的操作系统

  • 键盘和显示器

  • 已安装 Python 3.7+

  • 已安装 AWS CLI v2.2+

  • 可以在 TCP 端口 80 和 443 上访问公共互联网的网络连接

    注意

    如果你为这个项目创建新的 AWS 账户，你还需要一张信用卡来完成注册过程。如果你的公司的 AWS 管理员提供了新的开发者账户或沙盒账户，建议使用新的开发者账户或沙盒账户。不建议在生产服务运行的任何账户中尝试新的项目。

所有这些都可以说是：如果你有一台笔记本电脑和一块 Raspberry Pi，你很可能已经准备好继续了！如果你只有一台笔记本电脑，你仍然可以通过本地 VM 完成所有动手练习，而无需额外费用。

注意

Python 和 AWS CLI 的安装说明因操作系统而异。本书不涵盖这些工具的设置。有关安装和配置信息，请参阅www.python.org和aws.amazon.com/cli/。

摘要

你现在应该已经有一个关于计算拓扑边缘和边缘解决方案组件（如传感器、执行器和计算能力）的工作定义。你应该能够识别机器学习技术对于在边缘运行的智能家居和工业用例的价值主张。我们创建了一家虚构公司，规划了一个新产品发布，并在本书的其余部分描述了您将交付的整体解决方案架构。

在下一章中，你将通过学习如何使用 AWS IoT Greengrass 在你的边缘设备上编排代码来迈出开发边缘解决方案的第一步。如果你的两个动手实践系统的先决条件已经准备好，并且你的 AWS 账户已经设置好，那么你就准备好了！

知识检查

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

1. 网络物理解决方案和边缘解决方案之间的区别是什么？

2. 在它被发明的时候，汽车是一个自给自足的机械实体，不是一个网络物理解决方案或边缘解决方案。在汽车发展的某个阶段，它开始符合网络物理解决方案的定义，然后又符合边缘解决方案的定义。今天我们可以找到哪些符合我们边缘解决方案定义的汽车特征？

3. 电话一直是网络物理解决方案吗？为什么是或不是？

4. 边缘解决方案的常见组件有哪些？

5. 在边缘交付智能工作负载时，需要哪三种主要工具？

6. 使用在边缘运行的机器学习模型，可以实现边缘到云工作负载的四个关键好处是什么？

7. 任何智能家居解决方案的核心人物是谁？

8. 你能否为智能家居垂直领域再找到一个与机器学习边缘解决方案的另一个关键好处相关联的使用案例？

9. 任何工业解决方案的核心人物是谁？

10. 你能否为任何工业垂直领域再找到一个与机器学习边缘解决方案的另一个关键好处相关联的使用案例？

11. 机器学习边缘解决方案的物联网架构师通常是否负责部署的模型的性能准确性（例如，预测的置信度分数）？为什么是或不是？

参考文献

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

• Erich Gamma，Richard Helm，Ralph Johnson，和John Vlissides。1995 年。设计模式：可重用面向对象软件元素。Addison-Wesley Longman Publishing Co., Inc.，USA：

• 智能家居市场 – 增长、趋势、COVID-19 影响和预测（2021-2026）：

  www.mordorintelligence.com/industry-reports/global-smart-homes-market-industry

• 《工业物联网市场规模、份额和趋势分析报告，按组件（解决方案、服务、平台），按最终用途（制造、物流和运输），按地区，以及预测，2019-2025：

  www.grandviewresearch.com/industry-analysis/industrial-internet-of-things-iiot-market

• 释放物联网的潜力：

  www.mckinsey.com/business-functions/mckinsey-digital/our-insights/the-internet-of-things-the-value-of-digitizing-the-physical-world

• *《17 项目目标》，联合国网站：

  sdgs.un.org/goals

第二部分：构建模块

本节将亲自动手使用 AWS 技术，如 IoT Greengrass 和 Amazon SageMaker，以创建一个在本地设备数据流上提供机器学习模型力量的解决方案。

本节包括以下章节：

• 第二章**，边缘工作负载的基础

• 第三章**，构建边缘

• 第四章**，将云扩展到边缘

• 第五章**，从边缘摄取和流式传输数据

• 第六章**，在云上处理和消费数据

• 第七章**，边缘的机器学习工作负载

第二章：第二章：边缘工作负载的基础

本章将探讨关于边缘工作负载的更深入细节以及您的第一次动手实践。您将了解 AWS IoT Greengrass 如何满足设计和交付现代边缘机器学习解决方案的需求。您将学习如何通过部署一个检查设备兼容性要求的工具来准备您的边缘设备与 AWS 协同工作。此外，您还将学习如何安装 IoT Greengrass 核心软件并部署您的第一个 IoT Greengrass 核心设备。您将了解组件的结构，检查 IoT Greengrass 中的软件的基本单元，并编写您的第一个边缘工作负载组件。

到本章结束时，您应该开始熟悉 IoT Greengrass 及其本地开发生命周期的基础知识。

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

• 边缘机器学习解决方案的解剖结构

• IoT Greengrass 大获全胜

• 检查与 IoT 设备测试器的兼容性

• 安装 IoT Greengrass

• 您的第一个边缘组件

技术要求

本章的技术要求与第一章“使用机器学习的数据驱动边缘简介”中描述的手动先决条件部分相同。请参阅该章节中提到的完整要求。提醒一下，您将需要以下内容：

• 基于 Linux 的系统用于部署 IoT Greengrass 软件。建议使用 Raspberry Pi 3B 或更高版本。安装说明与其他基于 Linux 的系统类似。当其他系统（如 Raspberry Pi）的手动步骤不同时，请参考以下 GitHub 仓库以获取进一步指导。

• 安装和使用 AWS 命令行界面（CLI）的系统，以便访问 AWS 管理控制台网站（通常是您的 PC/笔记本电脑）。

您可以从 GitHub 仓库的chapter2文件夹中访问本章的技术资源，网址为github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge/tree/main/chapter2。

边缘机器学习解决方案的解剖结构

上一章介绍了边缘解决方案的概念以及定义具有机器学习应用的边缘解决方案的三个关键工具。本章提供了关于边缘解决方案各层的更多细节。本节中讨论的三个层如下：

• 业务逻辑层包括决定解决方案行为的定制代码。

• 物理接口层通过传感器和执行器将您的解决方案连接到模拟世界。

• 网络接口层将您的解决方案连接到更广泛网络中的其他数字实体。

了解这些层对于重要，因为它们将告知您作为物联网架构师在设计边缘机器学习解决方案时如何进行权衡。首先，我们将从定义业务逻辑层开始。

为业务逻辑设计代码

业务逻辑层是您的边缘解决方案所有代码的存放地。这些代码可以有多种形式，例如预编译的二进制文件（如 C 程序）、shell 脚本、由运行时评估的代码（如 Java 或 Python 程序）和机器学习模型。此外，代码可以以几种不同的方式组织，例如将所有内容打包到一个单体应用程序中、将代码拆分为服务或库，或将代码捆绑到容器中运行。所有这些选项都对架构和发送边缘机器学习解决方案有影响，例如安全性、成本、一致性、生产力和耐用性。业务逻辑层交付代码的一些挑战如下：

• 编写和测试将在您的边缘硬件平台上运行的代码。例如，编写将在硬件平台的新版本推出时工作的代码，您将希望最小化维护满足所有硬件平台需求的代码分支数量。

• 设计一个包含许多功能的强大边缘解决方案。例如，将功能捆绑在一起以处理新的传感器数据、分析数据和与不与常见依赖项或本地资源冲突的 Web 服务进行通信。

• 与一个团队一起编写代码，该团队正在共同开发一个边缘解决方案。例如，一个由许多贡献者组成的单体应用程序可能需要每个作者完全了解解决方案才能进行增量更改。

为了解决编写业务层逻辑的挑战，将代码发送到边缘的最佳实践是在实际可行的情况下使用独立服务。

独立服务

在您的Home Base Solutions hub 设备（我们从第一章，《利用机器学习的数据驱动边缘介绍》）中，代码将以独立服务的形式部署和运行。在这个背景下，一个服务是一个包含业务逻辑的自包含单元，它可以被另一个实体调用以执行任务，或者自行执行任务。隔离意味着服务将捆绑其操作所需的代码、资源和依赖项。例如，您将在第七章，《边缘机器学习工作负载》中创建的服务将运行代码以从数据源或图像集合中读取，定期使用捆绑的机器学习模型进行推理，然后将任何推理结果发布到本地流或云端。选择这种独立服务模式有两个原因：

• 第一个原因是服务导向架构使架构师能够设计相互解耦的能力。解耦意味着我们使用数据结构，如缓冲区、队列和流，在服务之间添加一层抽象，减少依赖性，使服务能够独立运行。

  您可以在不触及其他正在运行的服务的情况下部署单个服务的更新，因此可以降低对它们的影响风险。解耦的服务导向架构是设计良好架构的云解决方案的最佳实践，同时也非常适合边缘机器学习解决方案，在这些解决方案中，多个服务同时运行，并强调对可靠性的需求。例如，一个与传感器接口的服务将新的测量值写入数据结构，仅此而已；它只有一个任务，不需要了解数据是如何被后续功能消费的。

• 第二个原因是代码隔离使开发者能够专注于代码的功能，而不是代码的去向或依赖项在目标位置的管理方式。通过使用隔离原则将运行时依赖项和资源与代码捆绑在一起，我们获得了更强的确定性，即代码将在部署的任何地方都能确定性地工作。开发者可以释放出用于依赖项管理的努力，并且更有信心代码将在边缘平台上以相同的方式工作，这可能与他们的开发环境不同。这并不是说边缘解决方案的开发者不需要测试他们的代码对物理接口（如传感器和执行器）的行为。然而，这意味着开发团队能够交付自包含的服务，这些服务可以独立工作，而不管在聚合的边缘解决方案中部署的其他服务如何。

  隔离的例子包括Python虚拟环境，它明确指定了 Python 运行时版本和包，以及Docker Engine，它使用容器来打包依赖项、资源和在主机上实现进程隔离。以下图表展示了使用隔离服务实现的关注点分离：

![图 2.1 – 使用解耦、隔离服务的边缘解决方案

图 2.1 – 使用解耦、隔离服务的边缘解决方案

同时，隔离和服务模式为边缘机器学习解决方案提供了引人注目的好处。当然，开发中的每一个决策都伴随着权衡。如果作为单一代码单体部署，解决方案会更简单，并且更快地推出最小可行产品。我们选择更复杂的架构，因为这会导致更好的弹性和随时间扩展的解决方案。我们依靠强大的模式和良好的工具来平衡这种复杂性。

物联网 Greengrass 是按照这种模式设计的。在本章及整本书中，你将学习如何使用这种模式与物联网 Greengrass 结合，开发结构良好的边缘机器学习解决方案。

物理接口

网络物理解决方案是通过使用物理接口与模拟世界进行交互来定义的。这些接口分为两类：用于从模拟世界获取测量的传感器和用于对它施加变化的执行器。一些机器两者都做，例如冰箱可以感知内部温度并激活其压缩机循环制冷剂。在这些情况下，传感和执行器的聚合是逻辑的，这意味着传感器和执行器之间存在关系，但在功能上是独立的，并且通过开关、电路或微控制器等机制进行协调。

执行模拟到数字转换的传感器通过采样电信号中的电压并将其转换为数字值。这些数字值通过代码解释以推导出数据，如温度、光和压力。执行器将数字信号转换为模拟动作，通常通过操纵通往开关或电路的电压来实现。深入探讨物理接口的电气工程超出了本书的范围。请参阅 参考文献 部分以获取关于该主题深入研究的建议。以下图表展示了一个简单的模拟示例，包括冰箱以及恒温器（传感器）、开关（控制器）和压缩机（执行器）之间的关系：

图 2.2 – 带有传感器和执行器的模拟控制器

理解由网络物理解决方案提供的输入和输出模式以及与通过边缘机器学习解决方案提供的更高层次结果之间的关系是很重要的。在本书中交付的项目中，你将获得实际应用这些模式的经验。Home Base Solutions 中心设备的一些服务将作为物理层的接口，提供来自传感器的新的测量值，并将命令转换为改变本地设备状态的命令。如果你正在使用物理边缘设备，例如 Raspberry Pi，你将获得一些使用代码与该设备的物理接口交互的经验。

网络接口

在介绍我们的边缘解决方案结构时，需要引入的第三层是网络接口。我们定义的物理-网络解决方案与边缘解决方案之间的区别在于，边缘解决方案在某个时刻将通过网络与另一个实体进行交互。例如，我们为 Home Base Solutions 设计的新设备监控套件使用监控套件与中心设备之间的无线通信。为了将监控器的传感器信号从模拟转换为数字，这两个设备之间没有物理连接。

同样，中心设备也会与云服务交换消息，以存储用于训练机器学习模型的数据、向设备部署新资源以及向客户通知已识别的事件。以下图示说明了消息流以及传感器、执行器、中心设备（网关）和云服务之间的关系：

![图 2.3 – 一个边缘设备与本地传感器、执行器和云交换消息

![img/B17595_02_003.jpg]

图 2.3 – 一个边缘设备与本地传感器、执行器和云交换消息

在物联网解决方案中，无线通信很常见，并且特定的实现可以在广泛的距离范围内实现连接。每个规范和实现都会在范围、数据传输速率、硬件成本和能耗之间做出权衡。短距离无线电规范，如Zigbee（IEEE 802.15.4）、蓝牙（IEEE 802.15.1）和WiFi（IEEE 802.11），适用于连接个人和局域网内的设备。长距离无线电规范，如传统的蜂窝网络（例如，GSM、CDMA和LTE）以及低功耗广域网络（LPWANs）如LoRaWAN和NB-IoT，为部署（无论是静态还是漫游）在特定校园、城市或地区的设备提供了连接选项。

有线通信仍然用于连接边缘设备，如电视、游戏机和 PC，通过以太网连接到家庭网络解决方案，如交换机和路由器。由于家庭网络路由器上以太网端口的数量有限（通常只有 1-8 个端口），设备放置的限制以及在家中的布线负担，有线连接在智能家居产品中不太常见。

例如，家庭基站解决方案的设备监控套件可能会使用 Zigbee 或等效实现，以及电池来平衡能量消耗与预期的数据速率。如果套件需要从附近的插座获取电源，Wi-Fi 就成为一个更可行的选择；然而，它将限制整体产品的实用性，因为要监控的设备类型放置位置并不总是有额外的插座。此外，直接使用以太网将套件连接到集线器也没有意义，因为客户可能不会觉得家里到处都是额外的电线很吸引人。与套件通信的集线器设备可以使用以太网或 Wi-Fi 连接到客户的本地网络，从而访问公共互联网。

现在你已经更好地理解了边缘解决方案的三个层次，让我们来评估选定的边缘运行时解决方案以及它是如何实现每一层的。

物联网 Greengrass 大获全胜

在一本关于使用物联网 Greengrass 提供边缘机器学习解决方案的书中，最重要的一个问题是要回答为什么是物联网 Greengrass？在评估边缘机器学习解决方案的独特挑战和实现它们所需的关键工具时，你希望选择尽可能解决你问题的工具，同时在提高生产效率方面不给你带来麻烦。物联网 Greengrass 是一个专门构建的工具，其价值主张将物联网和机器学习解决方案置于前沿。

物联网 Greengrass 在解决常见需求的无差别的繁重工作问题时具有指导性，但在实现你的业务逻辑时则不具有指导性。这意味着开箱即用的体验提供了许多快速迭代的能力，同时不会阻碍你如何使用它们来实现最终目标。以下是一些物联网 Greengrass 提供的能力列表：

• 边缘安全：物联网 Greengrass 以 root 权限安装，并使用操作系统用户权限来保护在边缘部署的代码和资源，防止篡改。

• 云安全：物联网 Greengrass 使用与公共密钥基础设施互操作的传输层安全（TLS）来在边缘和云之间交换消息。在部署期间使用 HTTPS 和 AWS 签名版本 4 来验证请求者的身份并保护传输中的数据。

• 运行时编排：开发者可以按自己的喜好设计应用程序（使用单体、服务或容器），并轻松地将它们部署到边缘。物联网 Greengrass 提供了智能集成组件生命周期事件的钩子，或者开发者可以忽略它们，只需一个命令就可以引导应用程序。可以添加或更新单个组件，而不会中断其他正在运行的服务。依赖关系树允许开发者将库的安装和配置活动抽象出来，从而与代码工件解耦。

• 日志和监控：默认情况下，IoT Greengrass 为每个组件创建日志，并允许开发者指定哪些日志文件应同步到云端以供操作使用。此外，云服务会自动跟踪设备健康状况，使团队成员更容易识别和响应不健康的设备。

• 扩展车队规模：向单个设备部署更新与向设备车队部署更新并没有太大区别。定义组、将类似设备分类在一起，然后使用托管部署服务向设备组推送更新很容易。

• 原生集成：AWS 为部署到 IoT Greengrass 解决方案提供了许多组件，这些组件增强了基线功能，并可用于与其他 AWS 服务集成。一个流管理组件使您能够在边缘定义、写入和消费流。一个 Docker 应用程序管理器允许您从公共存储库或Amazon Elastic Container Registry中的私有存储库下载 Docker 镜像。预训练和优化的 ML 模型可用于对象检测和图像分类等任务，这些任务由Deep Learning Runtime和TensorFlow Lite提供支持。

在扮演作为构建解决方案的 Home Base 解决方案架构师的角色时，您可能会建议工程团队投入时间和资源来构建所有这些功能，并测试其是否已准备好投入生产。然而，IoT Greengrass 基线服务和可选附加组件已准备好加速开发周期，并由 AWS 审核通过，其中安全性是首要任务。

IoT Greengrass 并不会为您做所有事情。实际上，IoT Greengrass 的全新安装不会做任何事情，只是等待进一步的指令，即部署。把它想象成一张空白画布、颜料和画笔。它提供了您开始所需的一切，但您必须开发它所运行的解决方案。让我们回顾 IoT Greengrass 的运营模式，包括边缘和云端的运营模式。

检查 IoT Greengrass 架构

IoT Greengrass 既是运行在 AWS 上的托管服务，也是边缘运行时工具。托管服务是您定义设备的地方，包括单个设备和分组。当您想要将新的部署推送到边缘时，实际上是在托管服务中调用一个 API，然后该 API 负责与边缘运行时通信，以协调该部署的交付。以下是一个序列图，展示了您作为开发者配置组件并请求运行 IoT Greengrass 核心软件的设备接收并运行该组件的过程：

![图 2.4 – 通过 IoT Greengrass 推送部署

图 2.4 – 通过 IoT Greengrass 推送部署

组件是部署到运行 IoT Greengrass 的设备上的功能的基本单元。组件由一个名为配方的清单文件定义，它告诉 IoT Greengrass 该组件的名称、版本、依赖项和指令。除此之外，组件还可以定义零个或多个在部署期间获取的工件。这些工件可以是二进制文件、源代码、编译代码、存档、图像或数据文件；实际上，任何存储在磁盘上的文件或资源。组件配方可以定义对其他组件的依赖关系，这些依赖关系将通过 IoT Greengrass 软件通过图来解析。

在部署活动期间，在该部署中添加或更新一个或多个组件。组件的工件从云中下载到本地设备；然后，通过评估生命周期指令来启动组件。生命周期指令可能是启动期间发生的事情；它可能是要运行的主要命令，例如启动 Java 应用程序或组件运行结束后要做的事情。组件可能会无限期地保持运行状态，或者执行任务后退出。以下图表提供了一个组件图的示例：

![Figure 2.5 – 组件的生命周期和依赖关系的示例图]

![img/B17595_02_005.jpg]

Figure 2.5 – 组件的生命周期和依赖关系的示例图

这是我们准备开始将边缘设备准备好运行带有 IoT Greengrass 的解决方案之前需要涵盖的所有内容！

在以下章节中，您将验证您的边缘设备是否已准备好运行 IoT Greengrass 软件，安装软件，然后编写您的第一个组件。此外，您将通过即将到来的动手活动更深入地了解组件和部署。

检查与 IoT 设备测试器的兼容性

IoT 设备测试器（IDT）是 AWS 提供的一个软件客户端，用于评估设备在 AWS IoT 解决方案中的使用准备情况。它通过运行一系列资格测试来帮助开发者验证目标系统是否已准备好运行 IoT Greengrass 核心软件。此外，它还运行一系列测试来证明边缘能力已经存在，例如建立与 AWS 的 MQTT 连接或在本地运行机器学习模型。IDT 适用于您正在本地测试的一个设备，或者可以扩展以运行针对任何数量的设备组的定制测试套件，只要它们可以通过网络访问。

在您作为 Home Base Solutions 的物联网架构师的角色下，您应使用 IDT 来证明您的目标边缘设备平台（在这种情况下，平台指的是硬件和软件）能够运行所选的运行时编排工具，即物联网 Greengrass。使用工具来证明兼容性的这种模式是手动评估目标平台和/或假设满足列出的某些要求组合的最佳实践。例如，一个潜在的设备平台可能会宣传其硬件要求和操作系统符合您的需求，但它可能缺少一个在开发生命周期后期才显现的关键库依赖项。最好尽早证明您需要的所有东西都已存在并得到考虑。

注意

IDT 不仅能够使硬件具备运行物联网 Greengrass 核心软件的资格。该工具还可以使运行 FreeRTOS 的硬件具备资格，以验证设备能够与 AWS IoT Core 进行互操作。开发者可以编写自己的自定义测试，并将它们捆绑成套件，以纳入您的软件开发生命周期（SDLC）。

以下步骤将帮助您准备您的 Raspberry Pi 设备作为边缘系统（即，在我们虚构项目中的 Home Base Solutions 中心设备）使用，并在最终运行 IDT 软件之前配置您的 AWS 账户。如果您的设备已经配置了 AWS 账户并准备使用，您可以选择跳过启动 Raspberry Pi和配置 AWS 账户和权限部分。如果您正在使用不同的平台作为边缘设备，您只需确保您可以通过 SSH 从您的指挥控制设备访问设备，并且有一个具有 root 权限的系统用户。

启动 Raspberry Pi

以下步骤是在带有 Raspberry Pi OS 2021 年 5 月版干净安装的 Raspberry Pi 3B 上运行的。请参阅www.raspberrypi.org/software/以获取Raspberry Pi Imager工具。使用您的指挥控制系统运行映像工具，用 Raspberry Pi OS 的新映像闪存 Micro SD 卡。对于本书的项目，我们建议您使用一张空白磁盘，以避免任何预存软件和配置更改的意外后果。以下是 Raspberry Pi Imager 工具和要选择的映像的截图：

图 2.6 – Raspberry Pi Imager 工具和要选择的映像

以下是在使用 Imager 工具对 Micro SD 卡进行闪存操作后需要执行的步骤列表：

1. 将 Micro SD 卡插入 Raspberry Pi。

2. 通过插入电源插头启动 Raspberry Pi。

3. 完成首次启动向导。更新默认密码，设置您的区域首选项，并连接到 Wi-Fi（如果您使用的是以太网，则此步骤为可选）。

4. 打开终端应用程序并运行 sudo apt-get update 和 sudo apt-get upgrade。

5. 重新启动 Pi。

6. 打开终端应用程序并运行 hostname 命令。复制该值并做好笔记；例如，在您的命令和控制系统的便签文件中写下它。在 Raspberry Pi 设备上，默认值为 raspberrypi。

7. 打开 Raspberry Pi 预设应用程序并启用 SSH 接口。IDT 访问设备时必须启用此接口。打开 预设，选择 Raspberry Pi 配置，选择 接口，并启用 SSH。

在这个里程碑时刻，您的 Raspberry Pi 设备已配置为加入与您的命令和控制系统相同的本地网络，并且可以通过远程 shell 会话访问。如果您使用不同的设备或虚拟机作为动手实践的边缘设备，您应该能够通过 SSH 访问该设备。一个检查此操作是否正常工作的好方法是尝试使用终端应用程序（或 ssh pi@raspberrypi）从您的命令和控制系统连接到您的边缘设备（如果您的主机名与 步骤 6 中的不同，请替换 raspberrypi）。接下来，您将配置您的 AWS 账户，以便在边缘设备上运行 IDT。

配置 AWS 账户和权限

在您的命令和控制系统上完成本节中的所有步骤。对于尚未拥有 AWS 账户的读者（如果您已经有账户访问权限，请跳到 步骤 5），请执行以下操作：

1. 创建您的 AWS 账户。在您的网络浏览器中导航到 portal.aws.amazon.com/billing/signup 并完成提示。您需要一个电子邮件地址、电话号码和信用卡。

2. 使用 root 登录 AWS 管理控制台，并导航到 身份与访问管理（IAM）服务。您可以在 console.aws.amazon.com/iam/ 找到它。

3. 使用 IAM 服务控制台设置您的管理组和用户账户。最佳实践是为自己创建一个新用户，而不是继续使用 root 用户登录。您将使用这个新用户通过 AWS 管理控制台或 AWS CLI 完成任何后续的 AWS 步骤：

   1. 创建一个名为 AdministratorAccess 的新用户（使用过滤器字段并输入它会更方便）。此策略由 AWS 管理，以授予用户管理员级别的权限。最佳实践是将权限与组相关联，然后将用户分配到组中以继承权限。这使得审计权限和理解用户从命名良好的组中拥有的访问权限变得更容易。

4. 从 AWS 管理控制台中注销。

   注意

   到目前为止，您应该可以访问一个具有管理员用户的 AWS 账户。完成以下步骤以设置 AWS CLI（如果您已经使用管理员用户配置了 AWS CLI，请跳到 步骤 7）。

5. 安装 AWS CLI。特定平台的说明可以在 aws.amazon.com/cli/ 找到。在这本书中，AWS CLI 步骤将使用 AWS CLI v2。

6. 安装完成后，配置 AWS CLI 并使用您为 aws configure 下载的凭据。

7. 当提示输入 json、yaml、text、table 时。作者的偏好是 json，并将反映在书中出现的任何 AWS CLI 输出示例中。

接下来，您将使用您的 Admin 用户创建一些更多资源，为以下部分使用 IDT 和安装 IoT Greengrass 核心软件做准备。这些是权限资源，类似于您的 Admin 用户，将被 IDT 和 IoT Greengrass 软件用于代表您与 AWS 交互。

• 使用 步骤 3A 中的自定义登录链接登录 AWS 管理控制台。使用 CSV 文件中提供的 Admin 用户名和密码。* 返回 IAM 服务控制台，可以在 console.aws.amazon.com/iam/ 找到。* 创建一个名为 idtgg 的新用户（简称 IDT 和 Greengrass）并选择 程序访问 类型。此用户不需要密码即可访问管理控制台。跳过权限和标签部分。确保您还下载了包含此用户凭据的 CSV 文件。* 创建一个名为 idt-gg-permissions 的新策略。第一步是定义策略的权限。选择 chapter2/policies/idtgg-policy.json。跳过标签部分。在审查部分，输入 idt-gg-permissions 的名称，输入 IoT 设备测试器和 IoT Greengrass 权限 的描述，并选择 创建策略。* 创建一个名为 idt-gg-permissions 策略的新用户组，并选择 idtgg 用户。选择 创建组。您现在已设置了一个新的组，附加了权限，并分配了作为 IDT 客户端和 IoT Greengrass 配置工具的身份验证和授权的程序访问用户。* 在您的终端或 PowerShell 应用程序中，为此新用户配置一个新的 AWS CLI 配置文件：

  1. 运行 aws configure --profile idtgg。

  2. 当提示输入访问密钥和秘密密钥时，请使用在 步骤 9 中下载的凭据 CSV 文件中的新值。

  3. 当提示默认区域时，请使用本书的默认值 us-west-2 或您在本书中所有项目中使用的 AWS 区域。

这就完成了配置您的 AWS 账户、权限和 CLI 的所有准备工作。下一个里程碑是安装 IDT 客户端并准备测试 Home Base Solutions 原型中心设备。

配置 IDT

您将从您的命令和控制系统中运行 IDT 软件，IDT 将通过 SSH 远程访问边缘设备系统以运行测试。

注意

以下步骤反映了编写时的 IDT 配置和使用情况。如果您遇到困难，可能是因为最新版本与编写时我们使用的版本不同。您可以通过 AWS 文档中的 IDT 获取有关安装、配置和使用的最新指南。请参阅docs.aws.amazon.com/greengrass/v2/developerguide/device-tester-for-greengrass-ug.html。

按照以下步骤使用 IDT 验证边缘设备系统是否已准备好运行物联网 Greengrass。以下所有步骤均使用 macOS 上的物联网 Greengrass 核心软件 v2.4.0 和 IDT v4.2.0 以及测试套件 GGV2Q_2.0.1 完成。对于 Windows、Linux 或更晚的 AWS 软件版本，请根据需要更改命令和目录：

1. 在您的命令和控制系统中，打开网页浏览器并导航到docs.aws.amazon.com/greengrass/v2/developerguide/dev-test-versions.html。

2. 在 Windows 的C:\projects\idt下或 macOS 和 Linux 的~/projects/idt下：![图 2.7 – 下载 IDT 的 AWS 文档网站；确切文本和版本可能不同

   ![img/B17595_02_007.jpg]

   图 2.7 – 下载 IDT 的 AWS 文档网站；确切文本和版本可能不同

3. 在目录中解压存档内容。在文件资源管理器中，双击存档以提取它们。如果使用终端，请使用类似unzip devicetester_greengrass_v2_4.0.2_testsuite_1.1.0_mac.zip的命令。这是 macOS 上的目录外观：![图 2.8 – macOS Finder 显示解压 IDT 存档后的目录内容

   ![img/B17595_02_008.jpg]

   图 2.8 – macOS Finder 显示解压 IDT 存档后的目录内容

4. 在您的浏览器中打开一个新标签页，并将以下链接粘贴以提示下载最新的物联网 Greengrass 核心软件：d2s8p88vqu9w66.cloudfront.net/releases/greengrass-2.4.0.zip（如果此链接无效，您可以在docs.aws.amazon.com/greengrass/v2/developerguide/quick-installation.html#download-greengrass-core-v2找到最新指南）。

5. 将下载的文件重命名为aws.greengrass.nucleus.zip，并将其移动到 IDT 目录，例如~/projects/idt/devicetester_greengrass_v2_mac/products/aws.greengrass.nucleus.zip：![图 2.9 – IDT 将使用的物联网 Greengrass 软件

   ![img/B17595_02_009.jpg]

   图 2.9 – IDT 将使用的物联网 Greengrass 软件

6. 打开一个文本文件，例如~/projects/idt/devicetester_greengrass_v2_mac/configs/config.json，并更新以下值：

   1. （可选）如果您不是使用书籍默认的us-west-2，请更新awsRegion。

   2. 要使用您之前配置的 idtgg 配置文件，按照以下方式设置 auth 的值：

    "auth": {
      "method": "file",
      "credentials": {
        "profile": "idtgg"
      }
    }
   

7. 打开一个文本文件，例如 ~/projects/idt/devicetester_greengrass_v2_mac/configs/device.json，并更新以下值：

   1. "id": "pool1"。

   2. "sku": "hbshub"（hbshub 代表 Home Base Solutions hub）。

   3. 在 "features" 下方，对于名为 "arch" 的名称-值对，设置 "value": "armv7l"（这是针对树莓派设备的；或者，您也可以选择适合您设备的适当架构）。

   4. 在 "features" 下方，对于 "ml"、"docker" 和 "streamManagement" 等剩余的名称-值对，设置 "value": "no"。目前，我们将禁用这些测试，因为我们没有立即使用测试功能的计划。如果您想评估设备的兼容性，请随意启用它们，尽管在全新镜像的树莓派上测试可能会失败。

   5. 在 "devices" 下方，设置 "id": "raspberrypi"（或您喜欢的任何设备 ID）。

   6. 在 "connectivity" 下方，将 "ip" 的值设置为您的边缘设备的 IP 地址（对于树莓派用户，该值是 Booting the Raspberry Pi 部分的 步骤 6 的输出）。

   7. 在 "auth" 下方，设置 "method": "password"。

   8. 在 "credentials" 下方，将 "user" 的值设置为用于 SSH 到边缘设备的用户名（通常，对于树莓派用户，这将是指 "pi"）。

   9. 在 "credentials" 下方，将 "password" 的值设置为用于 SSH 到边缘设备的密码。

   10. 在 "credentials" 下方，删除 "privKeyPath" 的行。

   11. 保存此文件的更改。您可以在本书的 GitHub 仓库中查看此文件的示例版本，位于 chapter2/policies/idt-device-sample.json。

8. 打开一个文本文件，例如 ~/projects/idt/devicetester_greengrass_v2_mac/configs/userdata.json，并更新以下值。请确保指定绝对路径而不是相对路径：

   1. "TempResourcesDirOnDevice": "/tmp/idt"。

   2. "InstallationDirRootOnDevice": "/greengrass"。

   3. "GreengrassNucleusZip": "Users/ryan/projects/idt/devicetester_greengrass_v2_mac/products/aws.greengrass.nucleus.zip"（根据本节 步骤 5 中您存储 aws.greengrass.nucleus.zip 文件的位置进行更新）。

   4. 保存此文件的更改。您可以在本书的 GitHub 仓库中查看此文件的示例版本，位于 chapter2/policies/idt-userdata-sample.json。

9. 打开一个应用程序，例如 macOS/Linux 上的 Terminal 或 Windows 上的 PowerShell。

10. 将您当前的工作目录更改为 IDT 启动器所在的位置：

    1. 在 macOS 上 ~/projects/idt/devicetester_greengrass_v2_mac/bin

    2. 在 Linux 上 ~/projects/idt/devicetester_greengrass_v2_linux/bin

    3. 在 Windows 上 C:\projects\idt\devicetester_greengrass_v2_win\bin

11. 运行命令以启动 IDT：

    1. 在 macOS 上执行 ./devicetester_mac_x86-64 run-suite --userdata userdata.json

    2. 在 Linux 上 ./devicetester_linux_x86-64 run-suite --userdata userdata.json

    3. 在 Windows 上 devicetester_win_x86-64.exe run-suite --userdata userdata.json

    运行 IDT 将启动一个本地应用程序，通过 SSH 连接到您的边缘设备并完成一系列测试。它将在遇到第一个失败的测试案例时停止，或者一直运行直到所有测试案例都通过。如果您正在按照前面的步骤运行 IDT 针对新的 Raspberry Pi 安装，您应该观察到以下类似的输出：

    ========== Test Summary ==========
    Execution Time:   3s
    Tests Completed:   2
    Tests Passed:     1
    Tests Failed:     1
    Tests Skipped:     0
    ----------------------------------
    Test Groups:
        pretestvalidation:     PASSED
        coredependencies:     FAILED
    ----------------------------------
    Failed Tests:
    Group Name: coredependencies
            Test Name: javaversion
                Reason: Encountered error while fetching java version on the device: Failed to run Java version command with error: Command '{java -version 2>&1 map[] 30s}' exited with code 127\. Error output: .
    

    故意省略了在 Raspberry Pi 上安装 Java 的步骤，以演示 IDT 如何识别缺失的依赖项；对于这种欺骗表示歉意！如果您运行了 IDT 测试套件并且通过了所有测试案例，那么您已经提前完成了计划，可以跳转到安装 IoT Greengrass部分。

12. 为了修复这个缺失的依赖项，请返回您的 Raspberry Pi 界面并打开终端应用程序。

13. 使用sudo apt-get install default-jdk在 Pi 上安装 Java。

14. 返回您的命令和控制系统，并再次运行 IDT（重复步骤 11中的命令）。

您的测试套件现在应该通过 Java 要求测试。如果您遇到其他失败，您将需要使用idt/devicetester_greengrass_v2_mac/results文件夹中的测试报告和日志来分类和修复它们。一些常见的错误包括缺少 AWS 凭证、权限不足的 AWS 凭证以及指向userdata.json中定义的资源的不正确路径。一个完全通过的测试案例集看起来像这样：

========== Test Summary ==========
Execution Time:   22m59s
Tests Completed:   7
Tests Passed:     7
Tests Failed:     0
Tests Skipped:     0
----------------------------------
Test Groups:
    pretestvalidation:   PASSED
    coredependencies:   PASSED
    version:       PASSED
    component:       PASSED
    lambdadeployment:   PASSED
    mqtt:         PASSED
----------------------------------

这就完成了使用 IDT 分析并协助准备设备使用 IoT Greengrass 的入门介绍。在这里，最佳实践是使用软件测试，不仅是为了您自己的代码，还要评估边缘设备本身是否准备好与您的解决方案一起工作。依靠像 IDT 这样的工具，这些工具承担着证明设备准备好使用的繁重工作，并为每种新注册的设备或主要解决方案版本发布进行验证。您应该能够为您的下一个项目配置 IDT，并使新的设备或设备组能够运行 IoT Greengrass。在下一节中，您将学习如何在您的设备上安装 IoT Greengrass，以便配置您的第一个边缘组件。

安装 IoT Greengrass

现在您已经使用 IDT 验证了您的边缘设备与 IoT Greengrass 兼容，本章的下一个里程碑是安装 IoT Greengrass。

从您的边缘设备（即原型 Home Base Solutions 中心），打开终端应用程序，或者使用您的命令和控制设备通过 SSH 远程访问它：

1. 切换到您的用户主目录：cd ~/。

2. 下载 IoT Greengrass 核心软件：curl -s d2s8p88vqu9w66.cloudfront.net/releases/greengrass-nucleus-latest.zip > greengrass-nucleus-latest.zip。

3. 解压存档：unzip greengrass-nucleus-latest.zip -d greengrass && rm greengrass-nucleus-latest.zip。

4. 您的边缘设备需要 AWS 凭证以便代表您配置云资源。您可以使用在上一节配置 AWS 账户和权限中为idtgg用户创建的相同凭证：

   1. export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE

   2. export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

5. 使用以下命令安装物联网 Greengrass 核心软件。如果您使用的是除us-west-2以外的 AWS 区域，请更新--aws-region参数的值。您可以从chapter2/commands/provision-greengrass.sh复制并粘贴此命令：

   sudo -E java -Droot="/greengrass/v2" -Dlog.store=FILE \
     -jar ./greengrass/lib/Greengrass.jar \
     --aws-region us-west-2 \
     --thing-name hbshub001 \
     --thing-group-name hbshubprototypes \
     --tes-role-name GreengrassV2TokenExchangeRole \
     --tes-role-alias-name GreengrassCoreTokenExchangeRoleAlias \
     --component-default-user ggc_user:ggc_group \
     --provision true \
     --setup-system-service true \
     --deploy-dev-tools true
   

6. 就这样！此配置命令的最后几行输出应该看起来像这样：

   Created device configuration
   Successfully configured Nucleus with provisioned resource details!
   Creating a deployment for Greengrass first party components to the thing group
   Configured Nucleus to deploy aws.greengrass.Cli component
   Successfully set up Nucleus as a system service
   

在与 IDT 套件验证兼容性后，物联网 Greengrass 核心软件的安装和初始资源的配置过程会更加顺畅。现在您的边缘设备已经安装了第一个基本工具：运行时编排器。让我们回顾一下在此配置步骤中在边缘和 AWS 上创建的资源。

查看到目前为止已创建的内容

在您的边缘设备上，物联网 Greengrass 软件安装在了/greengrass/v2文件路径下。在该目录中，生成了用于连接 AWS 的公钥和私钥对、服务日志、用于存储食谱和工件本地包的本地存储库，以及用于推送到此设备的过去和现在部署的目录。您可以自由探索/greengrass/v2目录以熟悉设备上存储的内容；尽管如此，您需要使用sudo提升权限才能浏览所有内容。

安装添加了第一个aws.greengrass.Nucleus。核组件是物联网 Greengrass 的基础；它是唯一必需的组件，它促进了所有其他组件的关键功能，如部署、编排和生命周期管理。没有核组件，就没有物联网 Greengrass。

此外，安装还创建了第一个--deploy-dev-tools true参数。该部署安装了一个名为aws.greengrass.Cli的组件。第二个组件包括一个名为greengrass-cli的脚本，用于本地开发任务，例如审查部署、组件和日志。它还可以用于创建新组件和部署。记住，使用物联网 Greengrass，您可以在设备本地工作，或者通过 AWS 将其远程部署到设备。远程部署在第四章中介绍，将云扩展到边缘。

在 AWS 中，创建了一些不同的资源。首先，从物联网 Greengrass 配置参数--thing-name中创建了一个新的hbshub001。同样，从--thing-group-name配置参数中创建了一个新的hbshubprototypes。事物组包含零个或多个事物和事物组。物联网 Greengrass 的设计使用事物组来识别应该运行相同部署的边缘设备集合。例如，如果您配置了另一个中心原型设备，您会将其添加到同一个hbshubprototypes事物组中，这样新的原型部署就会传播到您的所有原型设备上。

此外，您的hbshub001事物附加了一个名为/greengrass/v2的目录实体，并用于建立与 AWS 的相互认证连接。证书是 AWS 在设备使用其私钥（证书附加到hbshub001事物记录）连接时识别设备的方式，并且知道如何查找设备的权限。这些权限定义在另一个称为物联网策略的资源中。

物联网策略类似于 AWS IAM 策略，因为它定义了当参与者与 AWS 交互时允许执行的操作的明确权限。在物联网策略的情况下，参与者是设备，权限包括打开连接、发布和接收消息以及访问部署中定义的静态资源。设备通过其证书获得权限，这意味着事物附加到证书，而证书附加到一个或多个策略。以下是这些基本资源在边缘和云中如何相互关联的草图：

![Figure 2.10 – Illustrating the relationships between the IoT Core thing registry and edge resources]

![img/B17595_02_010.jpg]

图 2.10 – 展示物联网核心事物注册表与边缘资源之间的关系

在物联网 Greengrass 的云服务中，为您的设备及其首次部署定义了一些额外的资源。物联网 Greengrass 核心 是一个设备（也称为事物）的映射，包括在设备上运行的组件和部署，以及设备所属的相关事物组。此外，核心还存储元数据，例如安装的物联网 Greengrass 核心软件的版本和最后一次已知健康检查的状态。以下是包含物联网 Greengrass 资源的关联关系图的另一种视图：

![Figure 2.11 – Illustrating the relationships between IoT Core, IoT Greengrass, and the edge device]

![img/B17595_02_011.jpg]

图 2.11 – 展示物联网核心、物联网 Greengrass 和边缘设备之间的关系

现在您已经安装了物联网 Greengrass，并对配置过程中创建的资源有了了解，让我们回顾一下组件部署后的样子，以便您实施Hello, world组件。

创建您的第一个边缘组件

任何开发者教育的最基本里程碑是Hello, world示例。对于您首次部署到 IoT Greengrass 的边缘组件，您将创建一个简单的Hello, world应用程序，以加强组件定义、依赖图以及如何创建新部署的概念。

检查现有组件

在开始编写新组件之前，花点时间熟悉已经通过 IoT Greengrass CLI 部署的现有组件。此 CLI 是在安装过程中通过--deploy-dev-tools true参数安装的。此工具旨在帮助您进行本地开发循环；然而，作为最佳实践，它不会在生产解决方案中安装。它安装在/greengrass/v2/bin/greengrass-cli。以下步骤演示了如何使用此工具：

1. 尝试调用help命令。在您的边缘设备的终端应用程序中运行/greengrass/v2/bin/greengrass-cli help。

2. 您应该查看help命令的输出，包括对component、deployment和logs命令的引用。尝试在component命令上调用help命令：/greengrass/v2/bin/greengrass-cli help component。

3. 您应该查看有关如何使用component命令的说明。接下来，尝试调用component list命令以显示所有本地安装的组件，/greengrass/v2/bin/greengrass-cli component list：

   java.lang.RuntimeException: Unable to create ipc client and Please run CLI as authorized user or group. This is an example of IoT Greengrass security principles at work. By default, the IoT Greengrass software is installed as the root system user. Only the root user, or a system user added to /etc/sudoers, can interact with the IoT Greengrass core software, even through the IoT Greengrass CLI. Components are run as the default system user identified in the configuration (please refer to the --component-default-user argument in the installation command), or each component can define an override system user to run as. Run the command again using sudo (*superuser do*):
   

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

   RUNNING, indicating the component's life cycle is either on or available. That makes sense because the CLI should always be available to us while the component is being deployed. Components that run once, perform a task, and close would show a state of FINISHED after they have completed their life cycle tasks.That's just the component's status, so next, let's take a look at the component's recipe and artifacts. As defined earlier, a component is made up of two resources: a recipe file and a set of artifacts. So what does the recipe file for the CLI component look like? You can find this in the `/greengrass/v2/packages/recipes` directory.
   

5. 您不需要运行以下A和B命令。它们被包含在这里是为了向您展示如何稍后找到文件内容：

   1. 要找到配方文件，请使用sudo ls /greengrass/v2/packages/recipes/。

   2. 要检查文件，请使用sudo less /greengrass/v2/recipes/rQVjcR-rX_XGFHg0WYKAnptIez3HKwtctL_2BKKZegM@2.4.0.recipe.yaml（请注意，您的文件名将不同）：

   Selection of recipe.yaml for aws.greengrass.C--
   RecipeFormatVersion: "2020-01-25"
   ComponentName: "aws.greengrass.Cli"
   ComponentVersion: "2.4.0"
   ComponentType: "aws.greengrass.plugin"
   ComponentDescription: "The Greengrass CLI component provides a local command-line interface that you can use on Greengrass core devices to develop and debug components locally. The Greengrass CLI lets you create local deployments and restart components on the Greengrass core device, for example."
   ComponentPublisher: "AWS"
   ComponentDependencies:
     aws.greengrass.Nucleus:
       VersionRequirement: ">=2.4.0 <2.5.0"
       DependencyType: "SOFT"
   Manifests:
   - Platform:
       os: "linux"
     Lifecycle: {}
     Artifacts:
     - Uri: "greengrass:UbhqXXSJj65QLVH5UqL6nBRterSKIhQu5FKeVAStZGc=/aws.greengrass.cli.client.zip"
       Digest: "uziZS73Z6dKgQgB0tna9WCJ1KhtyhsAb/DSv2Eaev8I="
       Algorithm: "SHA-256"
       Unarchive: "ZIP"
       Permission:
         Read: "ALL"
         Execute: "ALL"
     - Uri: "greengrass:2U_cb2X7-GFaXPMsXRutuT_zB6CdImClH0DSNVvzy1Y=/aws.greengrass.Cli.jar"
       Digest: "UpynbTgG+wYShtkcAr3X+l8/9QerGwaMw5U4IiicrMc="
       Algorithm: "SHA-256"
       Unarchive: "NONE"
       Permission:
         Read: "OWNER"
         Execute: "NONE"
   Lifecycle: {}
   

在此文件中，有一些重要的观察结果需要审查：

• 组件名称使用与namespacing Java 包类似的反向域名方案。本书项目中的自定义组件将以com.hbs.hub开头，表示为 Home Base Solutions hub 产品编写的组件。

• 此组件与特定版本的 IoT Greengrass 核心绑定，这就是为什么版本是 2.4.0。您的组件可以在此处指定任何版本，最佳实践是遵循语义版本规范。

• ComponentType属性仅由 AWS 插件（如此 CLI）使用。您的自定义组件将不会定义此属性。

• 此组件仅与特定版本的核心一起工作，因此它定义了对aws.greengrass.nucleus组件的软依赖。您的自定义组件默认情况下不需要指定核心依赖。这是您将定义对其他组件的依赖的地方，例如，确保在加载具有 Python 应用程序的组件之前已安装 Python3 的组件。

• 这个组件在全局级别或针对清单的linux平台版本没有定义特定的生命周期活动。

• 定义的艺术品是为特定的物联网 Greengrass 服务文件。你可以在/greengrass/v2/packages/artifacts目录中查看这些文件。当从云中部署时，你的工件 URI 将使用s3://path/to/my/file模式。在本地开发期间，你的清单不需要定义工件，因为它们预期已经存在于磁盘上。

• 注意两个工件上的权限。ZIP 文件可以被任何系统用户读取。相比之下，JAR 文件只能被OWNER读取，在这个场景中，意味着在安装时定义的默认系统用户，例如，ggc_user用户。

通过对组件结构的审查，现在是时候编写自己的组件了，包括工件和配方。

编写你的第一个组件

如前所述，我们希望创建的第一个组件是一个简单的Hello, world应用程序。在这个组件中，你将创建一个 shell 脚本，使用echo命令打印Hello, world。这个 shell 脚本是你的组件的工件。此外，你将编写一个配方文件，告诉物联网 Greengrass 如何将这个 shell 脚本用作组件。最后，你将使用本地物联网 Greengrass CLI 部署这个组件并检查它是否工作。

本地组件开发使用本地磁盘上可用的工件和配方文件，因此你需要为你的工作文件创建一些文件夹。在/greengrass/v2中没有专门用于存储工作文件的文件夹。因此，你需要创建一个简单的文件夹树并将组件文件放在那里：

1. 从你的边缘设备的终端应用程序中，切换到你的用户主目录：cd ~/。

2. 创建一个新的文件夹来存放你的本地组件资源：mkdir -p hbshub/{artifacts,recipes}。

3. 接下来，为一个新的工件创建路径并在其文件夹中添加一个 shell 脚本。让我们选择组件名为com.hbs.hub.HelloWorld，并从 1.0.0 版本开始。切换到工件文件夹：cd hbshub/artifacts。

4. 为你的组件工件创建一个新的目录：mkdir -p com.hbs.hub.HelloWorld/1.0.0。

5. 为 shell 脚本创建一个新文件：touch com.hbs.hub.HelloWorld/1.0.0/hello.sh。

6. 给这个文件设置写权限：chmod +x com.hbs.hub.HelloWorld/1.0.0/hello.sh。

7. 在编辑器中打开文件：nano com.hbs.hub.HelloWorld/1.0.0/hello.sh。

8. 在这个编辑器内部，添加以下内容（这些内容也可以在这个章节的 GitHub 仓库中找到）：

   #!/bin/bash
   if [ -z $1 ]; then
           target="world"
   else
           target=$1
   fi
   echo "Hello, $target"
   

9. 测试你的脚本是否带参数或不带参数。如果没有提供参数替换world，脚本将打印Hello, world：

   1. ./com.hbs.hub.HelloWorld/1.0.0/hello.sh

   2. ./com.hbs.hub.HelloWorld/1.0.0/hello.sh friend

10. 这就是你的组件工件所需的所有内容。接下来，你将学习如何利用从菜谱文件内部传递参数的优势。切换到菜谱目录：cd ~/hbshub/recipes。

11. 打开编辑器创建菜谱文件：nano com.hbs.hub.HelloWorld-1.0.0.json。

12. 将以下内容添加到文件中。你也可以从本书的 GitHub 仓库复制此文件：

    {
      "RecipeFormatVersion": "2020-01-25",
      "ComponentName": "com.hbs.hub.HelloWorld",
      "ComponentVersion": "1.0.0",
      "ComponentDescription": "My first AWS IoT Greengrass component.",
      "ComponentPublisher": "Home Base Solutions",
      "ComponentConfiguration": {
        "DefaultConfiguration": {
          "Message": "world!"
        }
      },
      "Manifests": [
        {
          "Platform": {
            "os": "linux"
          },
          "Lifecycle": {
            "Run": ". {artifacts:path}/hello.sh '{configuration:/Message}'"
          }
        }
      ]
    }
    

    这个菜谱很简单：它定义了一个生命周期步骤来运行我们位于已部署工件路径中的hello.sh脚本。尚未介绍的一个新功能是组件配置。ComponentConfiguration对象允许开发者定义任意键值对，这些键值对可以在整个菜谱文件中引用。在这种情况下，我们定义一个默认值作为脚本的参数传递。在部署组件时，这个值可以被覆盖，以自定义每个边缘设备如何使用已部署的组件。

    那么，在你编写了菜谱并提供了工件之后，如何测试一个组件呢？下一步是创建一个新的部署，告诉本地 IoT Greengrass 环境加载你的新组件并开始评估其生命周期事件。这正是 IoT Greengrass CLI 可以提供帮助的地方。

13. 使用以下命令创建一个包含你的新组件的新部署：

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

14. 你应该会看到一个类似以下内容的响应：

    Local deployment submitted! Deployment Id: b0152914-869c-4fec-b24a-37baf50f3f69
    

15. 你可以使用以下命令验证组件是否已成功部署（并且已经完成运行）：sudo /greengrass/v2/bin/greengrass-cli component list：

    Components currently running in Greengrass:
    Component Name: com.hbs.hub.HelloWorld
        Version: 1.0.0
        State: FINISHED
        Configuration: {"Message":"world!"}
    

16. 你可以在组件的日志文件中查看此组件的输出：sudo less /greengrass/v2/logs/com.hbs.hub.HelloWorld.log（记住，/greengrass/v2 目录属于 root 用户，因此必须使用sudo来访问日志文件）：

    2021-05-26T22:22:02.325Z [INFO] (pool-2-thread-32) com.hbs.hub.HelloWorld: shell-runner-start. {scriptName=services.com.hbs.hub.HelloWorld.lifecycle.Run, serviceName=com.hbs.hub.HelloWorld, currentState=STARTING, command=["/greengrass/v2/packages/artifacts/com.hbs.hub.HelloWorld/1.0.0/hello.sh 'world..."]}
    2021-05-26T22:22:02.357Z [INFO] (Copier) com.hbs.hub.HelloWorld: stdout. Hello, world!. {scriptName=services.com.hbs.hub.HelloWorld.lifecycle.Run, serviceName=com.hbs.hub.HelloWorld, currentState=RUNNING}
    2021-05-26T22:22:02.365Z [INFO] (Copier) com.hbs.hub.HelloWorld: Run script exited. {exitCode=0, serviceName=com.hbs.hub.HelloWorld, currentState=RUNNING}
    

恭喜！你已经使用 IoT Greengrass 将你的第一个组件部署到了 Home Base Solutions 原型中心。在日志输出中，你可以观察到两个值得注意的观察结果。首先，你可以在向 IoT Greengrass 报告成功退出代码之前，查看组件生命周期状态从STARTING到RUNNING的时序。组件在那个点结束，所以我们不会在日志中看到一个显示它移动到FINISHED状态的条目，尽管这在greengrass.log文件中是可见的。

其次，你可以查看写入STDOUT的消息，其中包含感叹号（world!）。这意味着脚本收到了你的组件默认配置，而不是回退到hello.sh中内置的默认配置（world）。你还可以在菜谱文件中使用部署命令中包含的自定义值来覆盖默认配置值world!。你将在第四章“扩展云到边缘”中学习如何使用该技术配置车队。

摘要

在本章中，你学习了我们将在这本书中使用的特定工具的基础知识，该工具满足任何边缘机器学习解决方案的关键需求之一，即运行时编排器。IoT Greengrass 提供了开箱即用的功能，使开发者能够专注于他们的业务解决方案，而不是构建一个灵活、健壮的边缘运行时和部署机制的工作。你学习了在 IoT Greengrass 中，软件的基本单元是组件，它由一个配方和一组工件组成，组件通过部署进入解决方案。你学习了如何使用 IDT 验证设备是否准备好与 IoT Greengrass 一起工作，如何安装 IoT Greengrass，开发你的第一个组件，并在本地环境中运行它。

在下一章中，我们将通过探索它如何启用网关功能、边缘常用的协议、安全最佳实践以及构建用于在网络物理解决方案中感知和执行的新组件，来更深入地了解 IoT Greengrass 的工作原理。

知识检查

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

1. 以下哪一个是边缘机器学习解决方案中组织代码的最佳实践？是单体应用还是隔离服务？

2. 在你的边缘架构中将服务解耦有什么好处？

3. 将你的代码和依赖项从其他服务中隔离有什么好处？

4. 在选择物联网解决方案中的有线和无线网络实现时，需要考虑哪一种权衡？

5. 一个同时使用传感器和执行器的智能家居设备的例子是什么？

6. 定义物联网 Greengrass 组件的资源有两种类型是什么？

7. 对或错：组件必须在它的配方中定义至少一个工件。

8. 为什么默认情况下，只有 root 系统用户可以与物联网 Greengrass 目录中的文件交互是一个好的设计原则？

9. 对或错：组件可以部署到 IoT Greengrass 设备，无论是本地还是远程。

10. 你能想到三种不同的方法来更新你的Hello, world组件的行为，使其打印Hello, Home Base Solutions customer!吗？

参考文献

请参考以下资源，以获取本章讨论的概念的更多信息：

• semver.org上的语义版本规范。

• 《面向服务的架构：服务和微服务分析与设计》由 Erl Thomas 著，Pearson，2016 年。

• 《模拟与数字电路基础》由 Anant Agarwal、Jeffrey H. Lang 和 Morgan Kaufmann 著，2005 年。

第三章：第三章：构建边缘

在本章中，你将了解边缘解决方案的概念，例如网关，以及如何使用AWS IoT Greengrass作为强大的边缘设备与物理接口和叶子设备进行交互。本章的目标是开始使用 IoT Greengrass 编写和部署软件组件，以建立熟练度。这部分内容是本书许多动手实践项目的基础，也是理解我们如何构建边缘解决方案的关键。

我们将向您介绍 IoT Greengrass 开箱即支持的多种协议，并讨论构建边缘解决方案时常用的协议。此外，我们将回顾几个安全最佳实践，以便您学习如何保护您的边缘工作负载免受威胁和漏洞的侵害。本章以一个动手活动结束，该活动将连接您的第一个两个设备功能作为组件，无论您使用的是实际硬件还是一对模拟器。

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

• 探索边缘拓扑

• 审查常见标准和协议

• 边缘安全

• 连接第一个设备 – 在边缘感知

• 连接第二个设备 – 在边缘执行操作

技术要求

要完成本章的动手练习，您需要完成第二章中边缘工作负载基础的步骤，以确保您的边缘设备已设置好运行 IoT Greengrass Core 软件，并安装了greengrass-cli组件。

如果您还没有这样做，为了方便使用，您可能需要从书的 GitHub 仓库中克隆本章的资源。在连接第一个设备 – 在边缘感知部分中包含了一个步骤，允许您在github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge/tree/main/chapter3克隆仓库。如果您想提前浏览资源，现在就可以执行此步骤：

git clone https://github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge-

作为提醒，本书的动手步骤是以树莓派和Sense HAT扩展板为背景编写的。对于那些使用其他基于 Linux 的系统作为边缘设备的您，GitHub 仓库中包含了替代技术资源，并提供了如何替换它们的指导。

探索边缘拓扑

针对边缘构建的解决方案形态各异，大小不一。解决方案中包含的不同设备数量从一到多个不等。网络布局、计算资源和预算允许将驱动您的架构和实施决策。在一个边缘机器学习（ML）解决方案中，我们应该考虑运行 ML 模型的需求。ML 模型在为特定设备实例定制构建时工作得更准确，而不是一个模型支持同一设备的多个物理实例。这意味着随着边缘 ML 工作负载支持的设备数量增加，边缘所需的 ML 模型和计算资源数量也将增加。在架构边缘 ML 解决方案时，需要考虑四种拓扑结构：星型、总线型、树型和混合型。以下是每种拓扑结构的描述：

• 星型拓扑：家庭基站解决方案（HBS）中心设备和应用监控套件代表了边缘 ML 解决方案中的一种常见模式，称为星型拓扑。应用监控套件是单一用途的设备，它们将遥测数据报告回中心设备。这为套件的成本优化创造了几个优势，因为它们不需要捆绑所有必要的硬件来独立直接与云解决方案通信。它们也不需要任何计算能力或本地存储来运行它们自己的 ML 模型。星型拓扑中的中心设备在某种程度上充当服务器，因为它可以与套件交换数据，并代表它们执行更重的计算和存储任务。例如，叶设备或软件组件直接向其他实体发送消息，并将它们路由到正确的目的地。以下图表显示了在星型拓扑中运行的 HBS 产品设计示例：

![图 3.1 – 带有中心设备和设备的星型拓扑示例

图 3.1 – 带有中心设备和设备的星型拓扑示例

• 总线拓扑：在总线模式中，拓扑中的所有节点都连接到一条单独的共享线，这意味着一个实体发布的消息可以被共享总线的所有实体接收。总线模式源于计算机网络的历史，当时设备被用来物理地接入网络线路，每个设备都扩展了总线。虽然现在我们通常不将这种模式视为物理布线，但在边缘机器学习解决方案中，总线模式有一个逻辑应用。在一个解耦的解决方案中，例如我们正在构建的解决方案，一个实体，如软件组件或叶设备，可以通过使用主题地址发布消息，而无需指向任何其他特定实体。主题地址并不严格标识其他实体；其他实体需要订阅这样的主题地址，以便获取消息的副本。这样，中心设备在技术上是一个星形拓扑的中心；然而，实际上连接的实体之间相互交互的方式更像是总线。以下图示说明了总线概念，在一个平行宇宙中，HBS 通过设备监控套件、运行机器学习推理的本地服务器和连接到中心的总线灯来提供工业设备的监控：

![图 3.2 – 逻辑总线拓扑的示例

![img/Figure_03_02.jpg]

图 3.2 – 逻辑总线拓扑的示例

• 树形拓扑：虽然对于任何边缘机器学习解决方案来说，在功能上独立运行是一种好的做法，但我们不能忽视将我们的解决方案与更广泛的网络和云服务桥接的好处。在树形拓扑中，我们的中心设备只是树形图中节点的一个层次，其中集中式服务与我们的枢纽群进行通信。然后，每个枢纽负责特定数量的运行在本地星形模式下的叶设备和组件。在规模上管理我们的 HBS 产品需要我们考虑整个枢纽群。以下图示显示了云服务协调我们的枢纽群、HBS 枢纽设备群以及每个枢纽支持的本地设备监控套件之间的关系：

![图 3.3 – 管理连接的枢纽群的总线拓扑示例

图 3.3 – 管理连接的枢纽群的总线拓扑示例

• 混合拓扑：如果我们的产品设计或中心设备预算不允许在边缘运行机器学习工作负载，而只是代表套件处理云连接，这将需要混合拓扑。在混合拓扑中，中心设备可能仅集中足够的资源以建立云连接，并在套件和云服务之间来回路由消息。在这里，混合定义了在云中运行进一步计算工作负载（如我们的机器学习推理）的额外拓扑复杂性。在这种情况下，基于云的机器学习工作负载对传入的遥测数据进行推理时，需要将一些设备消息子集传输到云。某些场景可能会选择减少中心设备的物料清单，以换取基于云的机器学习解决方案。当流量量处于较低端或当机器学习工作负载数量超过在单个网关设备上合理运行的数量时，这是有意义的。以下图显示了我们的虚构产品设计作为混合拓扑的修改示例：

图 3.4 – 带有远程计算和存储资源的混合拓扑示例

在研究网络拓扑时，有两个额外的模式是常见的，即网状和环形拓扑：

• 在网状拓扑中，节点可以与其他节点形成一对一或多对一的关系，并通过该连接网络交换信息以到达信息的目的地：

图 3.5 – 网状拓扑，其中网关 2 上的传感器穿越网状结构以到达网关 5 的执行器

• 在环形拓扑中，节点最多有两个相邻连接，并通过环形交换信息，直到达到目的地：

图 3.6 – 环形拓扑，其中从网关 2 读取的传感器数据通过相邻网关传输，以到达网关 3 的执行器

这些模式强调了去中心化，其中节点直接相互连接。虽然这些模式在物联网解决方案的更广泛范围内有其时间和地点，但在边缘机器学习解决方案中它们很少使用，在这些解决方案中，网关或中心设备以及云服务通常是最佳实践或直接要求。

当决定解决方案架构的特定拓扑时，首先考虑边缘的所有设备是否被同等加权，或者它们是否会与一个中心节点，如网关进行通信。针对边缘机器学习解决方案的消费产品设计倾向于在单独考虑边缘时采用星形模式。一个好的边缘解决方案应该能够在任何外部链接到更大的树形或混合拓扑被切断的情况下，仍然以星形模式运行。我们使用星形模式来实现 HBS 产品，因为中心设备将运行我们所需的任何和所有机器学习运行时工作负载。

物联网 Greengrass 被设计为作为星形实现的中心，并连接到 AWS 云的更大树形或混合拓扑。解决方案架构师可以选择运行物联网 Greengrass 的网关设备执行多少或多少计算工作。在下一节中，我们将回顾在边缘和边缘与云之间交换消息所使用的协议。

检查常见标准和协议

协议定义了与边缘解决方案交换消息的规范。这意味着消息的格式，它在线上的序列化方式，以及解决方案中两个参与者之间通信的网络协议。标准和协议帮助我们按照最佳实践进行架构，并在选择实现时进行快速决策。在深入研究边缘解决方案中使用的常见协议之前，首先，让我们回顾在信息技术和运营技术中使用的两个架构标准，以了解物联网 Greengrass 如何融入这些标准。使用这些标准作为基线将有助于设定协议使用的上下文以及消息如何在边缘解决方案中穿越这些模型。

OSI 模型中的物联网 Greengrass

开放系统互联（OSI）模型定义了一个由七个网络通信层组成的堆栈，描述了每个层之间设备交换信息的目的和使用的媒体。在堆栈的顶部是第七层，即应用层，在这里定义了高级 API 和传输协议。在底部是第一层，即物理层，在这里使用电和无线电信号通过物理媒体传输数字位。以下是一个 OSI 模型的图示，展示了物联网 Greengrass 如何与各个层相匹配：

![图 3.7 – 带有物联网 Greengrass 层交互覆盖的 OSI 模型

![img/Figure_03_07.jpg]

图 3.7 – 带有物联网 Greengrass 层交互覆盖的 OSI 模型

在这里，你可以观察到我们的运行时编排器，物联网 Greengrass，从第四层运行到第七层。在物联网 Greengrass Core 软件中使用了高级应用程序和传输协议，用于通过 HTTPS 和 MQTT 等协议与应用程序消息与 AWS 云和本地设备进行交换。此外，核心软件中捆绑的库负责 TCP/IP 堆栈中的传输层通信，但随后将 OSI 模型中的进一步传输转交给主机操作系统。

注意，虽然物联网 Greengrass Core 软件从第四层运行到第七层，但部署到你的边缘解决方案的软件组件可能达到第一层。例如，任何物理连接到物联网 Greengrass 设备的传感器或执行器都可以通过在组件中运行的代码访问，通常使用低级库 API。

ANSI/ISA-95 中的物联网 Greengrass

美国国家标准协会/国际自动化协会标准 95（ANSI/ISA-95）定义了企业控制系统之间接口关联的过程。此标准用于企业及工业解决方案架构中。它描述了另一个分层体系；这一层是系统控制的层级，并建议在此层级上做出决策的时间尺度。以下图表展示了物联网 Greengrass 和边缘机器学习解决方案如何融入整体图景：

图 3.8 – 在 ISA-95 模型上叠加物联网 Greengrass 层交互

在这里，你可以观察到物联网 Greengrass 主要适用于第三层，即控制系统的监控与监督层，以促进设备遥测数据的向上聚合、向下分发命令，并在监督职能中处理一些决策。物联网 Greengrass 适用于任何类型的边缘解决方案，无论是消费级产品还是促进工业机械的运行。虽然我们的 HBS 产品示例不是一个工业用例，但同样的模式适用，即我们的中心设备作为传感器监控设备的网关。

现在你已经了解了物联网 Greengrass 如何融入这些层级，我们可以回顾一下在相关层级中使用的常见协议。

应用层协议

应用层通信的例子包括从 API 请求数据、发布传感器遥测数据或向设备发送命令。这类数据与解决方案本身以及服务于解决方案结果的业务逻辑相关。例如，OSI 模型的其他层，如传输层或网络层，在部署的传感器报告环境温度为 22°C 时不会做出决策。只有你的解决方案运行的应用程序可以使用这些数据，并通过与应用层交互发送或接收这些数据。

在边缘和云之间进行通信时，最流行的应用层协议是用于请求-响应交互的HTTPS。IoT Greengrass 使用 HTTPS 与 AWS 云服务进行交互，用于获取元数据和下载组件资源，例如组件配方和代码以及训练好的机器学习模型等资源。此外，运行在边缘的自定义组件可能也会使用 HTTPS 与其他 AWS 服务、本地系统和其他远程服务器的 API 进行交互。

为了在边缘和云之间以及边缘解决方案内部交换消息，通常使用双向消息协议（也称为发布-订阅或pubsub），如 MQTT 或 AMQP。这些协议的优点如下：

• 它们使用有状态的连接来最小化握手连接的频率。

• 流量可以双向流动，无需任一端负责启动新的交换。

• 它们为每条消息提供最小的开销，这使得它们非常适合受限设备。

• 边缘的客户端可以发起这些连接，从而消除了网络防火墙规则需要允许入站连接的需求。

IoT Greengrass 使用 MQTT 协议以客户端-代理模型打开与 AWS IoT Core 服务的连接，以便将本地设备上传的消息传递到云中，从云中接收命令并将它们传递给本地设备，并在断开连接一段时间后同步状态。此外，IoT Greengrass 还可以作为通过 MQTT 连接到它的其他本地设备的代理。以下是一个 IoT Greengrass 设备（如 HBS 网关设备）作为客户端和代理的示意图：

![图 3.9 – HBS 网关同时作为 AWS IoT 的客户端和本地设备的服务器

![img/Figure_03_09.jpg]

图 3.9 – HBS 网关同时作为 AWS IoT 的客户端和本地设备的服务器

接下来是消息格式协议，它描述了数据在通过应用层协议发送时的结构化方式。

消息格式协议

如果一个消息协议，例如 MQTT，规定了如何建立连接以及如何交换消息，那么一个消息格式协议就规定了交换消息的形状和内容。你可以将电话作为类比。电话听筒代表了语音在两个方向上的发送方式，但参与者两端所说的语言必须被理解，这样说话才有意义！在这个类比中，MQTT 代表了电话本身（抽象掉了公共电话交换网络），而消息格式协议就是两端人们所说的语言。

对于任何两个相互交换数据的参与者，这些数据要么以二进制形式传输，要么会经过序列化和反序列化的过程。在边缘解决方案中常用的常见消息格式协议包括JavaScript 对象表示法（JSON）、Google 协议缓冲区（protobuf）和二进制 JSON（BSON）。这些格式使得设备、边缘组件和云解决方案之间的互操作性变得更容易。在包含多种编程语言的架构中，这一点尤为重要。消息格式是一种抽象手段，对于构建解决方案至关重要。通过使用可序列化的消息格式协议，以下图显示了用 Python 编写的组件如何与用 Java 编写的组件交换消息：

![图 3.10 – 使用 Greengrass 组件进行序列化和反序列化的示例

图 3.10 – 使用 Greengrass 组件进行序列化和反序列化的示例

你可以将所有消息都发送为二进制数据，但每个接收者都会产生额外的开销，需要确定如何处理这些数据或实施严格的发送约定。例如，一个只发送摄氏度数值测量的传感器设备可以直接发送二进制数据。如果该系统永远不会改变，添加注释和序列化的价值有限。接收端可以硬编码来了解如何处理它，从而节省元数据、结构和带宽的开销。这对于刚性、静态系统以及传输成本必须是最优化的优先级的情况是有效的。

不规则数据，如图像、视频和音频，通常以二进制有效载荷的形式发送，但会附带一个头部来指示数据的类型。在一个 HTTP 请求中，Content-Type头部将包括一个值，如text/HTML或 MIME 类型如video/MP4。这个头部告诉接收者如何处理该消息的二进制有效载荷。

物联网 Greengrass 为组件提供的进程间通信（IPC）功能，以支持它们之间消息的交换，支持 JSON 消息格式以及原始二进制格式。在本章中，你将构建两个组件，它们使用 IPC 将 JSON 消息从一个组件传递到另一个组件。

注意

由于物联网 Greengrass 没有规定与边缘设备和系统交互的任何特定协议，你可以轻松实现包含与任何设备或任何协议交互的库的组件。

关于协议的关键要点是，我们可以使用与良好架构模式相同的或类似的通用协议。它们经过实战检验，文档齐全，易于实现，并防止我们陷入实现细节的循环中，我们的时间本可以更好地用于交付成果。在下一节中，我们将从高层次概述边缘机器学习解决方案的安全威胁以及缓解这些威胁的最佳实践和工具。

边缘安全

随着物联网安全成为热门话题并频繁成为头条新闻，你的边缘机器学习解决方案中的安全性必须是你的首要任务。HBS 的领导层永远不会希望看到他们的公司或产品名称因黑客攻击设备的故事而出现在新闻中。最终，安全性是关于与你的客户建立和维护信任。你可以使用如 STRIDE 这样的威胁建模练习来分析你的边缘系统中原子操作者，如端设备、网关和软件组件，以推理最坏情况场景和防止这些场景的最小可行缓解措施。在本节中，我们将介绍常见的安全威胁以及缓解它们的最佳实践。

端设备到网关

让我们从我们的边缘机器学习解决方案的终端部分开始，包括监控套件本身及其与中心设备的连接。这个部分的极端情况是，一个不健康的设备被错误地报告为健康。如果客户安装了产品，但它未能完成其宣传的功能，这将失去所有客户对产品的信任。为了缓解这种情况，监控套件的传感器读数必须是真实的。这意味着我们必须防止中心设备从欺骗套件接收虚假测量值。

在这里，最佳实践是使用只有套件和中心设备才能理解的某种形式的秘密材料。秘密可以是对称加密模型中的预共享密钥，也可以是非对称加密模型中的公钥和私钥对。如果套件可以使用秘密对发送到中心设备的测量结果进行签名，那么只有中心设备可以读取它们，并且它会理解这些结果只能来自与之配对的设备。同样，监控套件只会对消息采取行动，例如请求更新固件，如果这些消息是由它识别的配对中心设备签名的秘密。

为我们监控套件和中心设备之间的配对过程设计一个安全的设计模式，是将手动步骤任务分配给客户，例如按下物理按钮。这与称为Wi-Fi 保护设置（WPS）的 Wi-Fi 配对方法类似。如果客户必须手动启动配对过程，这意味着攻击者更难与套件或中心设备建立通信。如果攻击者能够物理访问客户的场所并使用自己的设备进行配对，这将是一个更大的安全漏洞，会损害我们未来的产品。

物联网 Greengrass 提供了一个名为秘密管理器的组件来帮助处理这种情况。秘密管理器组件可以通过 AWS Secrets Manager 服务从云中安全地检索秘密材料。您可以将工作流程构建到您的边缘解决方案中，例如监控套件的配对过程，以在您的设备之间建立可加密验证的关系。

网关设备

以下风险和缓解措施列表专注于运行物联网 Greengrass Core 软件的网关设备：

• 安全连接到云端：那么，您如何确保核心设备与云服务（如 AWS IoT Core）之间的连接是安全的呢？在这里，最坏的情况是交换的消息已被访问、篡改或发送到伪造的端点。最佳实践，也是物联网 Greengrass 内置的做法，是使用公钥基础设施（PKI）和相互验证。PKI 通过生成私钥和公钥证书来实现非对称加密。接收者使用公钥证书来验证发送者的消息是真实的。在相互验证模型中，连接的两端都使用这种结构在握手过程中证明对方的真实性。包含可信平台模块（TPM）的设备，其中包含安全存储的私钥，可以在不暴露私钥的情况下为 PKI 生成证书。

• 入站网络连接：网络上的任何设备都可能容易受到接收传入连接请求的影响。最坏的情况是，攻击者获得对系统的远程访问权限，并开始探测系统或执行代码。建立连接的最佳实践是拒绝入站发起的连接，并依赖出站、客户端发起的连接。

• 启动篡改：那么，如果设备在制造和客户收到它之间被物理修改，会发生什么情况呢？恶意代码可能会被加载到设备上，在客户收到设备并加入网络时执行。为了防止对设备的任何篡改，请使用 TPM（可信平台模块）设计您的硬件平台（或构建在现有平台之上，这些平台使用 TPM），TPM 可以用来验证加密磁盘在启动序列之间没有被修改。

边缘组件

接下来，我们将继续讨论在物联网 Greengrass Core 设备上运行的边缘解决方案组件：

• 磁盘上的组件完整性：那么，如果攻击者在组件部署到核心设备之后能够访问组件工件，会发生什么情况呢？最坏的情况是，有价值的知识产权被窃取或修改以改变组件行为。在物联网 Greengrass 中，所有组件资源，如工件和食谱，都存储在磁盘上作为 root。组件用于文件 I/O 的工作目录属于物联网 Greengrass 配置中的默认组件系统用户或部署期间指定的覆盖用户。最佳实践是限制除了解决方案组件所需之外的其他系统用户对 root 和组件系统用户访问的保护。如果需要在设备上使用额外的系统用户，他们不应属于与您的组件用户相同的组，也不应有权限提升到 root 配置的权限。

• RequiresPrivilege标志然后对核心设备拥有完全访问权限。物联网 Greengrass 通过在您上传和注册组件时计算摘要（即，用于断言有效载荷真实性的数学求和）来防止这种攻击。核心设备将验证摘要与组件工件进行比较，如果工件被篡改，则失败。

• 模型中毒：那么，如果一个攻击者破坏了基于模型的决策过程，会发生什么？例如，一个使用本地机器学习模型来检测异常存在活动的摄像头输入，每周会使用新数据重新训练。如果攻击者理解了重新训练的循环，他们可以通过在一段时间内用有意的训练数据中毒来改变异常阈值以获得优势。为了减轻模型中毒，使用人工审核验证来批准用于训练的新标记数据。人工审核验证意味着你有一个机制让你的专家审查异常结果、标记结果或结果子集，作为模型质量保证。此外，你可以使用静态批准的训练数据集来测试后续模型的原始成功基准。

• *通配符，或敏感主题，用于明确批准。

因此，本节介绍了一些高风险安全威胁和 IoT Greengrass 提供的内置缓解措施，以及你可以实施的一些最佳实践。边缘安全既复杂又复杂。你可以使用威胁建模来识别最坏的情况，并实施最佳实践来缓解这些威胁。在下一节中，你将继续作为 HBS 物联网架构师的角色，通过使用提供简单传感器到执行器流的组件来连接两个设备。

连接你的第一个设备——边缘感知

在本节中，你将部署一个新的组件，该组件提供了你的边缘解决方案的第一个感知能力。在我们的 HBS 设备监控套件和中心设备的情况下，这个第一个组件将代表设备监控套件的传感器。传感器将测量到的温度和湿度报告给中心设备，该设备连接了一个供暖、通风和空调（HVAC）设备。传感器数据将通过 IoT Greengrass 的 IPC 功能写入本地主题。稍后的章节将部署另一个组件，该组件将消费这些传感器数据。

如果你使用 Raspberry Pi 和 Sense HAT 作为你的边缘设备，温度和湿度测量将从 Sense HAT 板获取。对于任何其他项目配置，你将使用软件数据生产者组件来模拟新数据的测量。两个路径的组件定义都可在 GitHub 仓库的chapter3文件夹中找到。

组件的两个版本都为 Python 3 运行时编写，并使用 Python 虚拟环境定义，以隔离依赖项。你将使用greengrass-cli部署其中一个，以创建一个新的本地部署，该部署与组件合并。本章涵盖了有关如何安装从 Sense HAT 读取和写入的组件的步骤。数据生产者和消费者组件的任何程序差异都在 GitHub 仓库的README.md文件中进行了说明。

安装传感器组件

安装此组件就像安装第二章中的com.hbs.hub.HelloWorld组件一样，边缘工作负载基础。你将使用 IoT Greengrass CLI 通过deployment命令合并一个预定义的组件：

1. 在你的中心设备（树莓派）上，克隆包含书籍配套资源的 Git 仓库：

   cd ~/ && git clone https://github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge-.git
   

2. 切换到克隆的chapter3文件夹：

   cd Intelligent-Workloads-at-the-Edge-/chapter3
   

3. 创建一个部署，包括com.hbs.hub.ReadSenseHAT组件（或在除树莓派以外的硬件上工作，请使用com.hbs.hub.ReadSenseHATSimulated）：

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

4. 你可以在日志文件中监控部署的进度：

   sudo tail -f /greengrass/v2/logs/greengrass.log
   

5. 当部署的日志停止更新时，你可以验证该组件是否已成功安装：

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

6. 你应该会看到com.hbs.hub.ReadSenseHAT。

现在组件已经安装，让我们来审查这个组件。

审查传感器组件

让我们回顾一些来自这个传感器组件的有趣部分，以便你更好地了解这个组件中正在发生的事情。在本节中，我们将回顾一些亮点，从配方文件开始。

IPC 权限

在com.hbs.hub.ReadSenseHAT-1.0.0.json部分，我们使用配置中的新概念accessControl。此配置定义了组件允许使用的 IoT Greengrass 功能。在这种情况下，配方定义了一个使用 IPC 并将消息发布到任何本地主题的权限。操作是aws.greengrass#PublishToTopic，资源是*通配符，意味着组件被允许发布到任何主题。在稍后的部分，你将观察到这里定义的不同权限，用于订阅 IPC 并接收此组件发布的消息。以下是显示accessControl配置的配方文件的相关部分：

com.hbs.hub.ReadSenseHAT-1.0.0.json

  "ComponentConfiguration": {
    "DefaultConfiguration": {
      "accessControl": {
        "aws.greengrass.ipc.pubsub": {
          "com.hbs.hub.ReadSenseHAT:pubsub:1": {
            "policyDescription": "Allows publish operations on local IPC",
            "operations": [
              "aws.greengrass#PublishToTopic"
            ],
            "resources": [
              "*"
            ]
          }
        }
      }
    }
  },

在前面的 JSON 片段中，你可以看到此组件的默认配置包括accessControl键。accessControl的第一个子键用于描述我们设置的哪个系统权限。在这个场景中，权限是针对aws.greengrass.ipc.pubsub系统的。下一个子键是一个唯一的策略 ID，必须在所有组件中都是唯一的。最佳实践是使用组件名称，系统名称或缩写，以及一个计数器的格式，所有这些通过冒号字符连接。操作列表仅包括一个发布消息的权限，但它也可以包括订阅的操作。最后，资源列表表示允许执行先前操作的确切主题列表。在这个场景中，我们使用*通配符以简化；然而，为了观察最小权限原则，更好的做法是穷尽性地列出主题。

多个生命周期步骤

在简单的"Hello, world"组件中，只有一个生命周期步骤在运行时调用 shell 脚本。在这个组件中，你可以看到我们正在使用两个不同的生命周期步骤：安装和运行。每个生命周期步骤在物联网 Greengrass 组件生命周期中的不同事件进行处理：

• Bootstrap步骤在组件首次部署或组件新版本部署时评估。当你想要 Greengrass 或设备重启时，应该在 Bootstrap 生命周期中包含说明。这个组件不需要任何重启，所以我们将其排除在配方之外。

• Install步骤将在组件每次启动时运行，例如，在设备重启和 Greengrass 重启组件之后。在这里，你应该包括在主组件代码开始之前安装或配置依赖项的说明。

• Bootstrap和Install脚本已成功完成。使用Run步骤运行应用程序或一次性活动。

• 另一种生命周期步骤是配方中的Run或Startup，但不一定是两者都使用。

  注意

  物联网 Greengrass Core 软件支持多个生命周期事件，以便灵活使用组件配方模型和组件依赖图。这些生命周期事件的完整定义可以在章节末尾的参考文献部分找到。Run、Install和Startup生命周期事件在组件配方中最常用。

让我们更详细地看看这个配方的生命周期步骤：

com.hbs.hub.ReadSenseHAT-1.0.0.json

"Lifecycle": {
        "Install": {
          "RequiresPrivilege": true,
          "Script": "usermod -a -G i2c,input ggc_user && apt update && apt upgrade -y && apt install python3 libatlas-base-dev -y && python3 -m venv env && env/bin/python -m pip install -r {artifacts:path}/requirements.txt"
        },
        "Run": {
          "Script": "env/bin/python {artifacts:path}/read_senseHAT.py"
        }
      }

在这个配方中，我们使用Install步骤来执行需要提升权限的系统级更改，例如确保 Python 已安装。Install步骤使用pip安装由我们的组件工件中requirements.txt文件定义的任何 Python 库。最后，Run步骤调用 Python 来启动我们的程序。

虚拟环境

在这个 Python 组件中，我们使用 Python 3 的一个特性，即虚拟环境。虚拟环境允许你指定在解释代码时使用的 Python 运行时的显式版本。我们使用它来本地安装任何依赖库，这样依赖项和运行时就不会与系统级 Python 冲突。这强化了将隔离应用于我们的组件的最佳实践。相对调用env/bin/python告诉脚本使用虚拟环境的 Python 版本，而不是系统级别的/usr/bin/python。

此组件使用requirements.txt文件来存储有关使用的 Python 包及其版本的信息。要求文件作为组件的工件存储，与 Python 代码文件一起。由于它是一个工件，所以pip命令必须使用由物联网 Greengrass 提供的{artifacts:path}变量来在磁盘上定位此文件。

我们可以通过以下两种方式之一为我们的组件实现更好的隔离：

• 系统级 Python 运行时管理：我们可以采用更具体的方法将 Python 运行时加载到设备上，并引用该组件所需的版本。使用在引导脚本中安装的系统级 Python 3 运行时有风险，因为另一个组件可能会稍后安装不同的 Python 3 运行时。最佳实践是使用更多组件作为依赖项来安装我们组件所需的每个特定运行时。这样，一个如本组件这样的组件可以依赖于安装 Python 3.7 的组件，另一个组件可以依赖于安装 Python 3.9 的组件，而不会相互冲突。

• 容器化：容器是一种技术，用于强制执行比 Python 虚拟环境更严格的进程和依赖项隔离。我们可以在包含 Python 运行时、系统包和 Python 库的 Docker 容器中构建和部署我们的传感器组件，并在调用 Python 代码之前在容器环境中执行任何额外的自定义步骤。这将实现最佳级别的隔离；然而，这也增加了开发和复杂性的成本，并且需要更多的总磁盘空间来达到这种隔离级别。对于生产环境，作为物联网架构师，您需要负责权衡为了额外的开销，需要多少隔离是合理的。

由于这个 HBS 项目是一个原型，并且我们使用的是预装了 Python 3 的 Raspberry Pi 设备，因此只需确保已安装 Python 3 就在可接受的风险范围内。对于每个组件使用容器进行综合隔离的方法可能适用，但在这一原型阶段，使用 Python 虚拟环境这种更轻量级的方法就足够了。

Unix 设备的权限

读取 Sense HAT 设备数据的代码使用 Sense HAT Python 库从 Unix 内核暴露为设备接口的设备文件中读取值。这些设备文件，如/dev/i2c-1和/dev/input/event2，仅限于i2c和input等系统用户组。root 用户可以访问这些设备，以及 Raspberry Pi 和默认的pi用户。我们的默认组件用户ggc_user不在这组中；因此，以ggc_user身份运行的代码将无法访问这些设备接口的值。有三种方法可以解决这个问题，如下列所示：

• 首先，您可以使用系统命令，如usermod -a -G i2c,input ggc_user，将ggc_user添加到i2c和input组中。

• 其次，您可以在组件配方中的Run脚本中将RequiresPrivilege标志设置为true。

• 第三，你可以通过添加--runWith COMPONENT:posixUser=USERNAME标志来覆盖组件在部署时应该运行的系统用户。（这可以通过在生产组件的部署组件中进行配置更改来实现，这部分内容在第四章，将云扩展到边缘中有所介绍。）

最佳实践是更新ggc_user组件用户所在的组。这减少了我们在 IoT Greengrass 组件中使用特权访问的频率，并通过将需求捆绑在我们的配方文件中来维护我们的隔离原则。以pi用户运行组件并不坏；然而，作为一个开发者，你不应该假设这个用户会在每个设备上存在并且拥有必要的权限，仅仅因为他们是操作系统的默认设置。为了方便，这里有一个设置ggc_user用户权限的生命周期步骤片段：

com.hbs.hub.ReadSenseHAT-1.0.0.json

"Lifecycle": {
  "Install": {
    "RequiresPrivilege": true,
    "Script": "usermod -a -G i2c,input ggc_user && apt update && apt upgrade -y && apt install python3 libatlas-base-dev -y && python3 -m venv env && env/bin/python -m pip install -r {artifacts:path}/requirements.txt"
  },

这涵盖了在组件配方文件中使用的有趣的新功能。接下来，让我们深入探讨代码中的重要部分。

记录日志

监控组件的一个重要部分是记录重要事件。这些行设置了一个日志记录器对象，你可以在整个 Python 代码中使用它。这应该是每个应用程序的标准做法：

read_senseHAT.py

logger = logging.getLogger()
handler = logging.StreamHandler(sys.stdout)
logger.setLevel(logging.INFO)
logger.addHandler(handler)

当为 IoT Greengrass 构建 Python 应用程序时，你可以复制这些行到引导日志中。请注意，你的日志记录器将捕获INFO级别或更高优先级的日志。除非你将级别设置为logging.DEBUG，否则调试日志将不会被捕获。你可能根据你在开发生命周期中的位置设置不同的日志级别，例如在测试阶段使用DEBUG，在生产阶段使用INFO。你可以通过组件级别的配置设置日志级别，并在特定部署中覆盖它。

从 Sense HAT 读取

在build_message函数内部有一些简单的代码用于初始化 Sense HAT 接口并读取其温度和湿度传感器的值。这些值代表我们 HBS 设备监控套件测量的值，该套件连接到一个虚构的 HVAC 设备：

Read_senseHAT.py

sense = SenseHat()
message = {}
message['timestamp'] = float("%.4f" % (time.time()))
message['device_id'] = 'hvac'
message['temperature'] = sense.get_temperature()
message['humidity'] = sense.get_humidity()

这段代码构建了一个新的对象，称为message，并将子属性设置为从 Sense HAT 库获取的值。代码还设置了一个简单的设备 ID 字符串，并生成了当前的时间戳。

发布消息

接下来，我们将介绍publish_message函数内部的关键代码行：

read_senseHAT.py

publish_message = PublishMessage()
publish_message.json_message = JsonMessage()
publish_message.json_message.message = message
request = PublishToTopicRequest()
request.topic = topic
request.publish_message = publish_message
operation = ipc_client.new_publish_to_topic()
operation.activate(request)
future = operation.get_response()
try:
    future.result(TIMEOUT)
    logger.info('published message, payload is: %s', request.publish_message)
except Exception as e:
    logger.error('failed message publish: ', e)

这些代码行准备消息和将要通过 IPC 服务作为新的发布操作与 IoT Greengrass 的 IPC 服务通信的请求。这段代码在需要将消息发布到在 HBS 中心设备上运行的其它组件的任何后续组件中看起来都很熟悉。

现在我们已经浏览了传感器应用程序的源代码，让我们检查日志文件中你正在测量的值。

测试传感器组件

要检查从传感器采集的值，您可以跟踪此组件的日志文件。如果您正在使用ReadSenseHATSimulated组件，请确保检查那个日志文件。

跟踪日志文件：

sudo tail -f /greengrass/v2/logs/com.hbs.hub.ReadSenseHAT.log
2021-06-29T01:03:07.746Z [INFO] (Copier) com.hbs.hub.ReadSenseHAT: stdout. published message, payload is: PublishMessage(json_message=JsonMessage(message={'timestamp': 1624928587.6789, 'device_id': 'hvac', 'temperature': 44.34784698486328, 'humidity': 22.96312713623047})). {scriptName=services.com.hbs.hub.ReadSenseHAT.lifecycle.Run.Script, serviceName=com.hbs.hub.ReadSenseHAT, currentState=RUNNING}

您应该会在日志文件中观察到带有温度和湿度测量的新条目。这些值正在被记录，并且通过 IPC 发布给任何正在监听它们的其他组件。您目前还没有其他组件在监听 IPC，所以现在是继续到第二个组件的绝佳时机。

连接第二个设备 – 在边缘执行

之前部署的组件充当传感器，从虚构的设备监控套件读取值，并通过 IoT Greengrass IPC 在本地主题上发布这些值。下一步是创建一个执行器组件，该组件将对这些发布的测量值做出响应并采取行动。您的执行器组件将通过 IPC 订阅相同的本地主题，并将传感器读数渲染到 Sense HAT 板上的 LED 矩阵。对于不使用带有 Sense HAT 模块的 Raspberry Pi 的项目，模拟执行器组件将把测量值写入文件作为概念验证。

安装组件

与之前的安装类似，您将创建一个部署，该部署将与新组件合并。请参考前面的步骤以获取源文件的位置和部署完成的验证步骤。对于不使用带有 Sense HAT 模块的 Raspberry Pi 的项目，您将部署com.hbs.hub.SimulatedActuator组件。

创建一个部署以包含com.hbs.hub.WriteSenseHAT组件：

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

一旦部署，您应该开始在 LED 矩阵上看到以t: 40.15 h:23.79格式的消息出现。这些是您的传感器组件报告的温度和湿度值。以下照片显示了 LED 矩阵滚动显示输出消息的快照：

图 3.11 – Sense HAT 滚动显示报告的传感器值的照片

如果在任何时候您厌倦了在设备上看到滚动消息，您可以通过以下方式简单地使用新的部署移除com.hbs.hub.WriteSenseHAT组件：

sudo /greengrass/v2/bin/greengrass-cli deployment create --remove com.hbs.hub.WriteSenseHAT 

继续阅读以了解此组件的结构。

检查执行器组件

让我们回顾一下此组件与传感器组件之间有趣的不同之处。

配方文件差异

从配方文件开始，有一个关键的不同之处需要注意。以下是我们将要审查的配方文件片段：

com.hbs.hub.WriteSenseHAT-1.0.0.json

"accessControl": {
        "aws.greengrass.ipc.pubsub": {
          "com.hbs.hub.WriteSenseHAT:pubsub:1": {
            "policyDescription": "Allows subscribe operations on local IPC",
            "operations": [
              "aws.greengrass#SubscribeToTopic"
            ],
            "resources": [
              "*"
            ]
          }
        }
      }

在 com.hbs.hub.WriteSenseHAT 的配方中，accessControl 权限指定了不同的操作，aws.greengrass#SubscribeToTopic。这与我们在传感器组件中定义的相反（aws.greengrass#PublishToTopic）。此权限允许组件在 IPC 上设置主题订阅并接收由其他 IPC 客户端（如传感器组件）发布的消息。以下图表显示了发布传感器和订阅执行器之间 IPC 权限的对比：

![图 3.12 – 传感器和执行器的 IPC 权限

图 3.12 – 传感器和执行器的 IPC 权限

此外，资源列表使用 * 通配符来表示组件可以订阅任何本地主题。遵循生产解决方案的最小权限原则，此资源列表将指定组件允许发布或订阅的显式主题列表。由于这个中心设备是原型，通配符方法是可以接受的。每个读取和写入组件都接受参数来覆盖用于你自己的实验的本地主题（请查看 main() 函数以了解更多信息）。由于任何主题都可以作为覆盖传递，这是使用通配符资源与组件权限的另一个原因。回想一下，这对于开发和测试是可以的，但对于生产组件的最佳实践将是详尽地指定允许发布和订阅的主题。

菜单文件剩余部分基本上是相同的，只是在组件名称和 Run 脚本中调用的 Python 文件名称上有所不同。此外，请注意，我们向 ggc_user 添加了一个新用户组；video 组允许访问 LED 矩阵。接下来，让我们回顾一下该组件 Python 文件中有趣的新代码行。

在 IPC 上接收消息

在 scrolling_measurements.py 中编写的业务逻辑是接收通过 IPC 的消息并将消息写入 LED 矩阵。以下是一些重要部分，你需要熟悉：

scrolling_measurements.py

class StreamHandler(client.SubscribeToTopicStreamHandler):
    def __init__(self):
        super().__init__()
    def on_stream_event(self, event: SubscriptionResponseMessage) -> None:
        try:
            message = event.json_message.message
            logger.info('message received! %s', message)
            scroll_message('t: ' + str("%.2f" % message['temperature']))
            scroll_message('h: ' + str("%.2f" % message['humidity']))
        except:
            traceback.print_exc()

在这个选择中，你可以观察到定义了一个新的本地类，称为 StreamHandler。StreamHandler 类负责实现以下 IPC 客户端订阅方法的行为：

• on_stream_event 是定义当新消息到达时应该做什么的处理程序。

• on_stream_error 是定义当订阅遇到错误时应该做什么的处理程序。

• on_stream_close 是定义在订阅关闭时如何清理任何资源的处理程序。

由于传感器组件正在以 JSON 格式发布消息，你可以看到使用event.json_message.message很容易获取该有效载荷的值。在此之后，on_stream_event处理程序检索temperature和humidity键的值，并将一个字符串发送到scroll_message函数。以下是该函数的代码：

scrolling_measurements.py

def scroll_message(message):
    sense = SenseHat()
    sense.show_message(message)

就这些！你可以看到使用 Sense HAT 库是多么容易。该库提供了将 LED 矩阵操纵成滚动文本墙的逻辑。如果滚动文本消息过于具体，库中还有其他函数，可以提供对 LED 矩阵的更精细控制。你可能想要渲染一种纯色、一个简单的位图或创建一个动画。

注意

在这对组件中，通过 IPC 传输的消息使用 JSON 规范。这对于可以使用 JSON 库的设备软件来说是一个干净的默认设置，因为它减少了我们在有线传输中序列化和反序列化消息时需要编写的代码。此外，使用 JSON 有效载荷将减少与通过 AWS IoT Core 服务交换消息的组件的代码。此服务也默认使用 JSON 有效载荷。然而，IoT Greengrass 的 IPC 功能和 AWS IoT Core 服务都支持发送带有二进制有效载荷的消息。

在 HBS 中心设备及其设备监控套件的情况下，Raspberry Pi 及其 Sense HAT 板在代表我们原型模型中的两种设备时都承担双重任务。要求客户审查连接到任一设备的屏幕上的滚动文本是不切实际的。实际上，解决方案只会通知客户有重要事件发生，而不会在每次进行测量时发出信号。然而，这种传感器和执行器通过 IPC 主题和消息的解耦接口进行通信的模式，展示了我们将在这本书中构建的其余边缘解决方案中使用的核心概念。

摘要

在本章中，你学习了在构建边缘机器学习解决方案中常见的拓扑结构以及它们如何与影响架构决策的约束和要求相关联。你了解了在边缘和云之间交换消息时使用的常见协议，以及为什么今天使用这些协议。你学习了如何评估边缘机器学习解决方案的安全风险以及减轻这些风险的最佳实践。此外，你交付了第一个多组件边缘解决方案，该解决方案使用解耦接口将传感器读数映射到执行器。

现在你已经了解了为边缘构建的基础知识，下一章将介绍如何使用云服务和远程部署工具为边缘构建和部署。此外，你将使用预编译的模型部署你的第一个机器学习组件。

知识检查

在继续下一章之前，通过回答这些问题来测试你的知识。

答案可以在本书末尾找到：

1. 在边缘解决方案中常见的三种网络拓扑是什么？HBS 集线器设备和设备监控套件实现了哪一种？

2. 对错判断：物联网 Greengrass 在 OSI 模型中的物理层（即第 1 层）运行。

3. 使用发布/订阅模型交换消息的好处是什么？

4. 对错判断：物联网 Greengrass 可以同时作为消息客户端和消息代理。

5. 消息如{"temperature": 70}是结构化数据还是非结构化数据的例子？它是可序列化的吗？

6. 从相机捕获的图像数据是结构化数据还是非结构化数据的例子？它是可序列化的吗？

7. 如果你的家庭网络路由器被攻击者入侵但仍然正常处理流量，你认为最坏的情况会是什么？

8. 验证两个网络设备之间真实性的缓解策略是什么？

9. 为什么在网关设备上通过权限提升保护 root 访问很重要？

10. 将每个边缘组件包裹在容器中是否有任何缺点？

11. 物联网 Greengrass 提供了哪些功能以允许组件交换消息？

12. 有什么方法可以使你在本章中部署的传感器和执行器解决方案更加安全？（提示：查看配方文件！）

13. 如果你需要一个第三方组件来在发送消息到执行器之前解释传感器结果，你将如何重新设计传感器和执行器解决方案？

参考文献

请参考以下资源以获取本章讨论的概念的更多信息：

• STRIDE 威胁模型：docs.microsoft.com/en-us/previous-versions/commerce-server/ee823878(v=cs.20)?redirectedfrom=MSDN

• OSI 模型：en.wikipedia.org/wiki/OSI_model

• ISA95，企业控制系统集成：www.isa.org/standards-and-publications/isa-standards/isa-standards-committees/isa95

• PEP 405 -- Python 虚拟环境：www.python.org/dev/peps/pep-0405/

• 开放容器倡议：opencontainers.org/

• Docker：www.docker.com/

• AWS IoT Greengrass 组件配方参考：docs.aws.amazon.com/greengrass/v2/developerguide/component-recipe-reference.html

第四章：第四章：将云扩展到边缘

在本章之前的材料中，所有开发步骤都是在您的设备上本地执行的。本地开发对于学习工具和快速原型设计很有用，但并不代表您通常如何操作生产设备。在本章中，您将把您的中心设备视为实际部署在现场，并学习如何使用云作为部署引擎远程与之交互。

而不是在设备上编写组件，您将学习如何使用Amazon Web Services (AWS) IoT Greengrass同步云资源，如代码、文件和机器学习（ML）模型，到边缘，并通过部署更新设备。您在本章中学习的工具、模式和技能对于您将云扩展到边缘并练习如何管理边缘 ML 解决方案的目标至关重要。您将连接一个新的客户端设备到您的中心设备，并学习如何建立与云解决方案的连接。最后，您将部署您的第一个真正的 ML 模型到边缘。到本章结束时，您将熟悉将组件和资源推送到边缘设备，就像您为生产车队所做的那样。

在本章中，我们将介绍以下主要主题：

• 远程创建和部署

• 将日志存储在云端

• 在边缘和云之间同步状态

• 部署您的第一个机器学习模型

技术要求

要完成本章的动手实践步骤，您应该拥有一个符合“动手实践先决条件”部分中定义的硬件和软件要求的中心设备第一章**，即《使用机器学习的数据驱动边缘简介》，该设备应加载AWS IoT Greengrass核心软件，如第二章**中定义的步骤所示，《边缘工作负载基础》。您还需要访问您的指挥与控制（C2）系统，通常是带有网络浏览器的 PC 或笔记本电脑，以及访问 AWS 管理控制台。

本章步骤中提供的资源可在 GitHub 仓库的chapter4文件夹中找到，网址为github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge/tree/main/chapter4。

远程创建和部署

到目前为止，您一直通过网关设备直接在 IoT Greengrass 解决方案上使用 IoT Greengrass 命令行界面（CLI）进行交互。从现在开始，您将学习如何通过使用 AWS 云从您的 C2 系统（笔记本电脑或工作站）与 IoT Greengrass 设备交互。CLI 和本地开发周期非常适合学习 IoT Greengrass 的基础知识以及组件开发的快速迭代。对于生产解决方案的最佳实践是不将 Greengrass CLI 组件部署到您的设备上并在本地安装新组件，因此接下来您将学习如何打包您的组件，将它们存储在 AWS 中，并完成对网关设备的远程部署。

从云中加载资源

组件可以包括由配方文件定义的任意数量的工件，并且这些工件必须存储在 Greengrass 设备可以访问的地方。工件可以是任何类型的静态资源：如图像或文本这样的二进制数据，Python 源代码或编译的Java ARchive文件（JARs），容器化代码如 Docker 容器，以及组件工作所需的任何其他副本，这里的重点在于静态和副本。工件是设备使用的资源，是其他部署该组件的每个设备都使用的副本。它们也不打算在部署后在设备上更改。

组件使用的另一种资源是动态资源。动态资源作为针对设备特定的配置或运行时消耗的内容被加载。动态资源可能是短暂的，因为它们只存在于设备在线或组件运行期间。动态资源的例子包括在代码中引用的秘密，如应用程序编程接口（API）密钥，基于设备的标识符（ID）或其他元数据的设置行为，以及任何叶设备（那些在解决方案终端点的设备，如Home Base Solutions（HBS）设备监控套件）与 Greengrass 设备（如 HBS 网关设备）之间的通信通道，软件组件，以及云。

在本章的第一个动手操作部分，您将熟悉配方如何定义静态资源作为工件，并使用自定义组件执行您的第一次远程部署。本章的后续部分将介绍动态资源的实现。

打包您的组件以进行远程部署

在 IoT Greengrass 上本地部署和远程部署之间的主要区别在于组件资源来自哪里。在您的本地开发生命周期中，您是在中心设备本身上编写文件，并指向包含配方和工件文件的文件夹。对于远程部署，您必须使用 Amazon Simple Storage Service (Amazon S3) 将您的文件存储在 AWS 云中，并更新您的配方以指向 S3 对象位置。在接下来的步骤中，您将更新 IoT Greengrass 设备的权限模型，以便能够从 S3 读取对象，使用 AWS CLI 将组件打包到 S3，并创建一个新的远程部署到您的中心设备。

更新 IoT Greengrass 权限

在您在中心设备上初始设置 IoT Greengrass 时，在 AWS 身份和访问管理 (AWS IAM) 服务中创建了一个新角色，IoT Greengrass 核心服务使用该角色来获取与任何 AWS 服务交互的授权。在 AWS 中，AWS IAM 服务是定义所有用户、组、策略和角色的地方，这些用户、组、策略和角色授予了对您账户中资源和服务 API 的访问权限。

我们在 AWS 中定义的一个 idtgg 用户，用于最初配置您的中心设备。一个 策略 记录了我们附加到身份的允许和拒绝权限集合。一个 角色 是权限的界面，授权用户可以假定以获得那些指定的权限。用户可以通过三种方式获得授权的权限。策略可以直接附加到用户或从他们所属的组继承。策略还可以附加到用户假定的用于临时会话的角色，让用户在遵循 最小权限原则 (POLP) 的前提下执行特定的基于会话的任务。通过使用角色，我们可以定义用户为完成特定任务而可以获得的抽象权限集合，以遵循限制权限范围的最佳实践。以下是一个用户（一种安全主体类型）、角色、策略以及用户通过假定角色所获得的权限之间关系的简单说明：

图 4.1 – IAM 用户从角色获取临时权限和凭证

对于用户、策略和角色的现实世界类比是，当您的朋友不在家时暂时把他们的家门钥匙给您，以便您可以为他们的植物浇水或喂他们的猫。您可以将角色视为“可以进入我家的人”，而家门钥匙是授予他们家访问权限的策略。通过把钥匙托付给您，您的朋友在您作为用户的情况下授予了一个临时的角色进入他们的家。当您的任务完成并且您的朋友回家后，您归还钥匙，从而结束在该角色下的会话。在数字世界中，您作为用户有自己的钥匙（例如公共证书），用于识别您。角色及其策略授予您的钥匙临时访问资源的权限，而不是给您唯一的钥匙！

IoT Greengrass 的安装过程创建了一个名为GreengrassV2TokenExchangeRole的新角色，并附加了一个名为GreengrassV2TokenExchangeRoleAccess的策略，该策略授予访问与 AWS IoT Core 服务交互的 API 以及将日志写入 Amazon CloudWatch 的权限。默认情况下，并且作为最佳安全实践，此策略不包括对存储在 S3 中的对象的访问权限。作为解决方案开发者，您需要描述您的设备应该能够访问哪些 S3 对象，并将该配置作为新策略添加到角色中。

注意

在本章的剩余部分，包含 AWS CLI 命令和简单的文件系统管理命令（如创建新目录或文件）的步骤将以 Unix 格式编写，适用于 macOS 和 Linux 系统。如果您在使用 AWS CLI 时遇到 Windows 特有的差异，例如将本地文件作为输入引用，请参阅docs.aws.amazon.com/cli/latest/userguide/的 AWS CLI 文档。

在接下来的步骤中，您将使用 AWS CLI 在 S3 中创建一个新的存储桶，一个授予对该 S3 存储桶中对象读取权限的新策略，然后将该新策略附加到 IoT Greengrass 设备使用的角色。按照以下步骤操作：

1. 从您的 C2 系统中，打开终端（或在 Windows 上运行cmd.exe/PowerShell）。

2. 使用 AWS CLI 通过运行以下命令打印出您的 12 位账户 ID：aws sts get-caller-identity --query 'Account'（输出应如下所示：012345678912）。

3. 在您的账户中创建一个新的 S3 存储桶。S3 存储桶名称在 AWS 中共享一个全局命名空间。命名存储桶的一个好习惯是包含您的 AWS 账户 ID 作为唯一的字符串。如果存储桶名称已被占用，您可以在名称中添加唯一的文本（例如您的首字母缩写）直到找到一个未被占用的名称。使用上一步骤中的账户 ID 并替换 12 位账户 ID 占位符。如果您不是使用默认的us-west-2，请确保更新区域。输出应如下所示：aws s3 mb s3://012345678912-hbs-components --region us-west-2。

4. 从现在开始，我们将把这个存储桶名称称为 REPLACEME_HBS_COMPONENTS_BUCKET。当你在文件中看到带有 REPLACEME_HBS_COMPONENTS_BUCKET 占位符的命令或文本时，你需要将其替换为你自己的存储桶名称，例如：012345678912-hbs-components。

5. 接下来，您将创建一个本地文件来存储授予您新存储桶中对象读取访问权限的新策略的内容。您可以在本书的 GitHub 仓库中找到此文件的模板，位于 chapter4/greengrass_read_s3.json 路径，并更新 REPLACEME_HBS_COMPONENTS_BUCKET 占位符。如果您自己创建文件，请将其命名为 greengrass_read_s3.json 并添加以下内容（记得替换占位符！）:

   {
     "Version": "2012-10-17",
     "Statement": [
       {
         "Effect": "Allow",
         "Action": [
           "s3:GetObject"
         ],
         "Resource": "arn:aws:s3:::REPLACEME_HBS_COMPONENTS_BUCKET/*"
       }
     ]
   }
   

6. 使用此文档作为其来源在 IAM 中创建一个新的策略：aws iam create-policy --policy-name GreengrassV2ReadComponentArtifacts --policy-document file://greengrass_read_s3.json。

7. 将策略添加到 IoT Greengrass 使用的 IAM 角色中。将 --policy-arn 参数的值替换为上一个命令输出的 arn 值，如下所示：aws iam attach-role-policy --role-name GreengrassV2TokenExchangeRole --policy-arn arn:aws:iam::012345678912:policy/GreengrassV2ReadComponentArtifacts。

现在，您的 IoT Greengrass 设备，例如 HBS 网关设备，可以读取存储在您的 S3 存储桶中的组件文件。让我们再了解一下网关设备和 AWS 资源之间安全模型的一个要素。

之前，我们描述了 AWS IAM 中用户、角色和策略之间的关系。您的设备在 AWS IAM 中没有作为用户的任何身份，那么它们是如何假定角色的呢？答案是 AWS IoT Core 中的一个功能，称为 凭证提供者服务。您的设备在 AWS IoT Core 中使用 X.509 私钥和公钥证书配置了身份。凭证提供者服务是连接设备展示其已注册的公钥证书以换取具有通过 IAM 角色授予的权限的临时 AWS 凭证的机制。

这里是一个序列图，展示了您的 HBS 网关设备获取权限并最终在 S3 中读取对象的路径：

![图 4.2 – 获取临时凭证的序列图

![img/B17595_04_02.jpg]

图 4.2 – 获取临时凭证的序列图

随着您的边缘解决方案添加与更多 AWS 服务交互的功能，您必须使用您刚刚完成的过程为这些服务添加权限。对于与 AWS 交互的自定义组件也是如此，因为所有组件都通过设备的配置 IAM 角色获取权限。随着您账户中不同边缘解决方案数量的增加，最佳实践是为每组不同的设备创建不同的 IAM 角色。例如，每个 HBS 枢纽将具有相同的解决方案，可以共享一个定义访问 AWS 权限的公共角色。对于 HBS 的下一个使用物联网 Greengrass 的项目，最好的做法是为该项目的设备创建一个新的角色，而不是向同一个 IAM 角色添加更多权限。

注意

AWS IoT 为您的设备定义的角色数量有一个区域配额。截至本文撰写时，配额为 100。这意味着您不想为每个 Greengrass 设备创建一个独特的角色，因为随着您扩展规模，您将很快达到最大配额。在 AWS 上的生产解决方案中，一个最佳实践是每个生产解决方案使用一个 AWS 账户，例如维护 HBS 的枢纽设备舰队。不同的产品线可以部署在单独的 AWS 账户中，从而增加可使用的角色总数。

在添加了新权限后，您可以继续到下一节，在那里您将打包一个新的组件并在物联网 Greengrass 的云服务中注册它。

在物联网 Greengrass 中注册组件

为了将组件远程部署到您的中心设备，您必须首先在物联网 Greengrass 的云服务中注册该组件。您将提供一个配方文件作为 API 的输入，就像您在使用设备上的本地物联网 Greengrass CLI 时做的那样。配方文件将定义组件使用的所有工件的位置。这些工件必须上传到 S3 存储桶，例如在上一步骤中创建的那个。当物联网 Greengrass 处理您的配方文件时，它将在您的账户中注册一个新的组件，然后可以在未来的任何设备部署中引用它。

注册组件的第一步是将您的工件文件添加到 S3 存储桶。只有在这种情况下，您才能知道这些文件在 S3 中的地址，以便能够更新可以引用它们的配方。在本节中，您将上传一个 ZIP 存档作为工件，然后在配方文件中替换工件路径，然后使用 AWS 软件开发工具包（SDK）在您的账户中注册组件，如下所示：

1. 从书籍的 GitHub 仓库中，通过运行以下命令切换到第四章：cd chapter4。

2. 使用 AWS SDK 通过运行以下命令上传工件文件：aws s3 cp artifacts/com.hbs.hub.HelloWithConfig/1.0.0/archive.zip s3://REPLACEME_HBS_COMPONENTS_BUCKET/artifacts/com.hbs.hub.HelloWithConfig/1.0.0/archive.zip。

3. 编辑recipes/com.hbs.hub.HelloWithConfig-1.0.0.json文件，并将统一资源标识符（URI）键的值替换为您在 S3 上的工件路径（上一步中的最后一个参数）。填写完毕后，它应该看起来像这样：

   "Artifacts": [
     {
       "URI": "s3://012345678912-hbs-components/artifacts/com.hbs.hub.HelloWithConfig/1.0.0/archive.zip",
       "Unarchive": "ZIP",
   

4. 现在您的工件已存放在 S3 上，配方文件也已更新，您可以使用 AWS SDK 将新组件注册到 IoT Greengrass 的云服务中。响应中将是aws greengrassv2 create-component-version --inline-recipe fileb://recipes/com.hbs.hub.HelloWithConfig-1.0.0.json。

5. 前面的命令会返回一个状态，例如componentState=REQUESTED，表示 IoT Greengrass 正在采取措施注册您的新组件。要检查组件注册的状态，请运行以下命令（将--arn参数替换为上一步输出的值）：aws greengrassv2 describe-component --arn arn:aws:greengrass:us-west-2:012345678912:components:com.hbs.hub.HelloWithConfig:versions:1.0.0。

当组件在服务中注册后，您将看到此命令的响应，其中componentState值现在显示为DEPLOYABLE。这意味着组件现在已准备好包含在新部署到设备中。在继续部署之前，让我们看一下 IoT Greengrass 现在存储的配方文件，可以使用以下命令查看（将--arn参数替换为上一步中您的组件的 ARN）：aws greengrassv2 get-component --arn arn:aws:greengrass:us-west-2: 012345678912:components:com.hbs.hub.HelloWithConfig:versions:1.0.0 --query "recipe" --output text | base64 --decode。您可能会注意到配方文件看起来并不完全像您发送给 IoT Greengrass 的那个。以下是现在的Artifacts对象看起来像这样：

"Artifacts":[{"Uri":"s3://012345678912-hbs-components/artifacts/com.hbs.hub.HelloWithConfig/1.0.0/archive.zip","Digest":"wvcSArajPd+Ug3xCdt0P1J74/I7QA2UbuRJeF5ZJ7ks=","Algorithm":"SHA-256","Unarchive":"ZIP","Permission":{"Read":"OWNER","Execute":"OWNER"}}]

这里新增的是Digest和Algorithm键。这是 IoT Greengrass 的安全特性。当您的配方被注册为服务中的组件时，IoT Greengrass 会计算配方中引用的每个工件文件的SHA-256哈希值。其目的是确保任何 IoT Greengrass 设备最终下载的工件在使用前未被修改。这也意味着您在注册组件后不能更改存储在 S3 上的工件文件。要更新任何工件，您需要注册组件的新版本并部署新组件版本。

与之前章节中本地开发的组件相比，这个组件还有两个差异：使用解压缩路径和工件权限。以下是此配方文件中关键差异的快照：

"Lifecycle": {
  "Run": "cd {artifacts:decompressedPath}/archive && ./hello.sh"
},
"Artifacts": 
  {
    "URI": "s3://REPLACEME_HBS_COMPONENTS_BUCKET/artifacts/com.hbs.hub.HelloWithConfig/1.0.0/archive.zip",
    "Unarchive": "ZIP",
    "Permission": {
      "Execute": "OWNER"

在Lifecycle对象中，你可以看到运行脚本，它引用了artifacts:decompressedPath变量。这个变量指向 Greengrass 自动解压缩你的归档工件所在的目录。文件被解压缩到与归档相同的子目录中——在这个例子中，是archive/。我们知道我们的hello.sh脚本将引用同一归档中的相邻config.txt文件。我们必须告诉运行脚本更改目录到解压缩路径，然后运行脚本，以便在正确的目录上下文中找到config.txt文件。

对于你的工件，最佳实践是从由 IoT Greengrass 下载或解包的artifacts目录中消费它们，并使用组件的工作目录，在配方中作为work:path提供，用于你的组件将要写入数据的文件。work目录是任何生命周期脚本的默认上下文，这就是为什么我们在运行脚本工件之前包括一个更改目录命令。

另一个新加入的是Permission对象，我们可以看到我们正在将Execute属性设置为OWNER值。默认情况下，解包的工件和文件对组件的所有者（如默认的ggc_user）具有Read文件系统权限。这意味着我们的archive.zip文件中的脚本文件在没有更改文件权限的情况下是不可执行的。对于任何工件使用Permission对象，我们可以将Read和Execute文件系统权限设置为NONE、OWNER或ALL（所有系统用户）。这也与为什么工件是写保护的有关。工件旨在作为只读资源被组件或不应更改而不修改组件定义的可执行文件使用。

在下一节中，你将部署你新注册的组件到你的设备上。

远程部署组件

现在你的组件现在可在 IoT Greengrass 服务中使用，是时候从你的 C2 系统使用 AWS CLI 开始远程部署到你的 HBS 网关设备了。这种从远程系统使用 IoT Greengrass 云服务进行的部署是你将更新部署到设备的标准方式。这不一定总是从你的开发笔记本电脑上的手动步骤，但我们将更详细地介绍生产管道的更多细节，见[第八章，边缘的 DevOps 和 MLOps。

在本地开发周期中，你部署组件的唯一设备是本地设备。通过物联网 Greengrass 的云服务进行部署是您指定多个目标设备的方式。这类部署是您扩大管理任何规模机群的能力，这些机群都应该运行相同组件的方法。部署还将指定部署和成功标准，例如通知设备的速率、它们报告成功部署所需的时间、等待组件发出准备更新信号的时长，以及部署失败时应该采取的措施。

在以下步骤中，您将编写一个文件，告知物联网 Greengrass 有关您的部署细节，启动部署，然后验证部署的成功：

1. 在初始物联网 Greengrass 核心软件安装中，您需要将hbshubprototypes设备组 ARN 作为参数。以下命令将获取您将在下一步中使用的设备组 ARN：aws iot describe-thing-group --thing-group-name hbshubprototypes --query "thingGroupArn"。

2. 编辑 GitHub 仓库中的chapter4/deployment-hellowithconfig.json文件，并将targetArn的值替换为上一步输出的设备组 ARN。编辑文件后，它应该看起来像这样：

   {
     "targetArn": "arn:aws:iot:us-west-2:012345678912:thinggroup/hbshubprototypes",
     "components": {
       "aws.greengrass.Cli": {
         "componentVersion": "2.4.0"
       },
       "com.hbs.hub.HelloWithConfig": {
         "componentVersion": "1.0.0"
       }
     }
   }
   

3. 使用以下部署配置启动对新包含中心设备的组的新部署：aws greengrassv2 create-deployment --cli-input-json file://deployment-hellowithconfig.json。

4. 之前的命令启动了部署过程。要检查特定设备（如您的hbshub001设备）的部署状态，可以使用以下命令：aws greengrassv2 list-effective-deployments --core-device-thing-name hbshub001。

5. 为了验证您的设备上组件是否按预期运行，您可以登录或使用sudo less /greengrass/v2/logs/com.hbs.hub.HelloWithConfig.log如下：

   2021-07-27T20:19:07.652Z [INFO] (pool-2-thread-91) com.hbs.hub.HelloWithConfig: shell-runner-start. {scriptName=services.com.hbs.hub.HelloWithConfig.lifecycle.Run, serviceName=com.hbs.hub.HelloWithConfig, currentState=STARTING, command=["./hello.sh"]}
   2021-07-27T20:19:07.685Z [INFO] (Copier) com.hbs.hub.HelloWithConfig: stdout. Hello from Zimbabwe!. {scriptName=services.com.hbs.hub.HelloWithConfig.lifecycle.Run, serviceName=com.hbs.hub.HelloWithConfig, currentState=RUNNING}
   2021-07-27T20:19:07.699Z [INFO] (Copier) com.hbs.hub.HelloWithConfig: Run script exited. {exitCode=0, serviceName=com.hbs.hub.HelloWithConfig, currentState=RUNNING}
   

到目前为止，您已经使用物联网 Greengrass 完成了对您的中心设备的第一次远程部署！整个过程与本地开发并没有太大的不同。我们需要将我们的工件上传到云服务，如 S3，更新配方文件以指向这些新的工件位置，并在将其包含在部署中之前注册组件。部署本身还有一些更多选项，用于指定目标设备、扩展到机群的行为，以及成功或失败的标准和行为。

每个事物组与一个部署有一个 1:1 的映射，该部署代表了该组中每个设备应使用的最新配置。当你想要向一组设备部署更改时，你将创建部署的修订版而不是启动全新的部署。修订版仍然需要一个类似于本节中使用的部署配置，并期望对所有组件和配置的明确定义，这意味着它不是对最后已知部署的修正。

你可以在多个事物组中包含一个设备，其中每个事物组定义了一个独特的配置和组件的部署。例如，你可以定义一个监控组件的事物组，这些组件将应用于所有 HBS 设备，并与指定基于设备类型的企业逻辑组件的事物组配对，例如我们的智能家居中心。属于多个事物组的设备将接收到每个组的部署通知，并将从所有组中合并组件图。以下是如何使用事物组有效地管理跨设备群组部署的组件以构建聚合解决方案的说明：

![图 4.3 – 在组部署中聚合组件的示例]

![图片 B17595_04_03.jpg]

图 4.3 – 在组部署中聚合组件的示例

如前所述，你的部署配置可以指定是否允许组件有一个选项来表示它们已准备好重启或更新。以这种方式让组件与部署行为交互的价值是防止组件突然终止导致数据丢失或业务流程中断。组件必须包含使用 IoT Greengrass SubscribeToComponentUpdates函数的使用。

组件可以通过使用DeferComponentUpdate命令通过 IPC 发布消息来响应组件更新事件并请求延迟。对于组件使用SubscribeToValidateConfigurationUpdates和相应的SendConfigurationValidityReport功能来验证配置更改请求也有类似的操作。你可以从本章末尾的参考部分了解更多关于这些功能的信息。

随着你第一次远程部署完成，并对 IoT Greengrass 的部署服务有了更好的理解，让我们通过启用将本地日志发布到云中来简化远程故障排除你的中心设备和其组件。

在云中存储日志

边缘解决方案从云中加载资源以进行引导、配置以及通常使本地解决方案为运行时做好准备。设备和解决方案的健康状况也应报告给云，以协助生产操作。默认情况下，您的 HBS 中心设备会与云 IoT Greengrass 服务进行交互，以报告连接状态和最近部署的结果。要获取来自边缘解决方案的更多遥测数据，例如日志和指标，您需要部署额外的组件。在本节中，您将部署一个管理组件，该组件将组件日志发送到 Amazon CloudWatch，这是一个用于存储和查询日志的服务。

将我们中心设备的日志存储在云中是一种最佳实践，并使我们能够单独对设备进行分类，而无需与设备建立实时连接或亲自在设备前。毕竟，这些设备可能位于相当偏远的地方，如阿拉斯加苔原，或者只在预定时间上线，例如 第一章 中提到的 利用机器学习的数据驱动边缘介绍 的海豚研究潜水器。

将日志存储在云中的另一个好处是，您可以在设备群中运行查询，以发现有关群集性能的见解。例如，在 24 小时期间对每个设备日志行数的简单计数可能会发现 健谈 设备的异常，其中存在异常数量的活动，这可能意味着设备正在处理异常数量的数据或资源争用。以下是我们群集中日志活动的直方图可能会表明您的运营团队需要分类的问题：

![图 4.4 – 基于日志活动的样本直方图，显示设备异常]

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/intl-wkld-eg/img/B17595_04_04.jpg)

图 4.4 – 基于日志活动的样本直方图，显示设备异常

由于在边缘解决方案中存储日志是一个常见的用例，并且在更广泛的云应用开发范围内也是如此，因此 IoT Greengrass 提供了一个管理组件，以便轻松摄取您的组件日志。这个名为 aws.greengrass.LogManager 的管理组件由 AWS 编写和维护。管理组件预计将满足物联网架构师的常见需求，但被视为可选功能，您需要在部署时引入。

注意

在撰写本文时，aws.greengrass.LogManager 管理组件的最新版本是 2.2.0。您可能需要根据您开始本书时安装的 IoT Greengrass 核心软件的最新版本来更新版本。对于 第二章 中 边缘工作负载基础 的步骤，使用了 IoT Greengrass 核心软件版本 2.4.0，它与 LogManager 2.2.0 兼容。您可以在本章末尾的 参考文献 部分的 AWS 提供的组件 文档链接中查看最新的依赖信息。

在以下步骤中，您将修改 hbshubprototypes 组的部署，以包括 aws.greengrass.LogManager 管理组件。LogManager 组件的配置将指定上传日志文件的目标组件。然后，您将使用 AWS CLI 运行一个简单的查询以验证日志文件是否正在存储。按照以下步骤操作：

1. 编辑 chapter4/deployment-logmanager.json 文件，将占位符替换为您的账户 ID。此部署添加了 LogManager 组件。请记住，由于在部署列表中没有指定其他组件（例如在前面部分添加的 com.hbs.hub.HelloWithConfig），它们将从设备中删除。我们将为此部署删除 HelloWithConfig，以便在将其添加回时查看日志文件的运行时输出。您需要做的只是更新 targetArn 属性以替换账户 ID 占位符并保存文件。

2. 创建一个新的部署修订版，并传入此新的部署配置文件，如下所示：aws greengrassv2 create-deployment --cli-input-json file://deployment-logmanager.json。

3. 编辑 chapter4/deployment-logmanager.json 文件，再次添加 HelloWithConfig 组件。我们这样做是为了重新部署组件，以便将运行时输出写入日志，然后将其上传到云端。将以下加粗的行添加到 components 对象中并保存文件：

   {
     "targetArn": "arn:aws:iot:us-west-2:0123456789012:thinggroup/hbshubprototypes",
     "components": {
       "aws.greengrass.Cli": {
         "componentVersion": "2.4.0"
       },
       "com.hbs.hub.HelloWithConfig": {
         "componentVersion": "1.0.0"
       },
       "aws.greengrass.LogManager": {
   

4. 使用之前的相同命令创建一个新的部署修订版，如下所示：aws greengrassv2 create-deployment --cli-input-json file://deployment-logmanager.json。

5. 此部署完成后，您将在 5 分钟内开始在 CloudWatch 日志中看到日志，因为 LogManager 的配置指定了 periodicUploadIntervalSec 参数为 300 秒。

6. 使用以下命令检查带有前缀 /aws/greengrass/ 的新日志组的状态：aws logs describe-log-groups --log-group-name-prefix "/aws/greengrass/"。

7. 当您看到如下响应时，您就知道日志正在写入 CloudWatch：

   {
       "logGroups": [
           {
               "logGroupName": "/aws/greengrass/UserComponent/us-west-2/com.hbs.hub.HelloWithConfig",
               "creationTime": 1627593843664,
               "metricFilterCount": 0,
               "arn": "arn:aws:logs:us-west-2:012345678912:log-group:/aws/greengrass/UserComponent/us-west-2/com.hbs.hub.HelloWithConfig:*",
               "storedBytes": 2219
           }
       ]
   }
   

8. 您可以查询日志组以查看存储此组件日志的设备，如下所示：aws logs describe-log-streams --log-group-name /aws/greengrass/UserComponent/us-west-2/com.hbs.hub.HelloWithConfig。

9. 如以下代码片段所示，响应将显示以 /DATE/thing/THING_NAME 格式命名的日志流：

   {
     "logStreams": [
       {
         "logStreamName": "/2021/07/29/thing/hbshub001",
   

10. 将日志组名称插入到 filter-log-events 命令中，以查看 HelloWithConfig 组件的日志输出，如下所示：aws logs filter-log-events --log-group-name /aws/greengrass/UserComponent/us-west-2/com.hbs.hub.HelloWithConfig --filter-pattern stdout。

    输出如下：

    {
        "events": [
            {
                "logStreamName": "/2021/07/29/thing/hbshub001",
                "timestamp": 1627579655321,
                "message": "2021-07-29T17:27:35.321Z [INFO] (Copier) com.hbs.hub.HelloWithConfig: stdout. Hello from Zimbabwe!. {scriptName=services.com.hbs.hub.HelloWithConfig.lifecycle.Run, serviceName=com.hbs.hub.HelloWithConfig, currentState=RUNNING}",
                "ingestionTime": 1627593843867,
                "eventId": "362…"
    }
        ]
    }
    

您可以从这一系列说明中了解如何包含LogManager组件，该组件会自动将您的组件日志文件发送到云端，以及如何使用 Amazon CloudWatch Logs 服务查询日志。IoT Greengrass 通过查询日志组或通过查询代表单个设备组件的日志流，使得跨设备群组轻松地对单个组件的日志文件进行分类。为了获得更强大的日志分析工具，您可以探索 Amazon CloudWatch Logs Insights，用于对日志组进行聚合查询，或者将日志流式传输到索引查询工具，如Amazon Elasticsearch。

合并组件配置

现在是介绍如何在部署时合并组件配置的好时机，您可以在部署中使用logmanager.json看到我们正在这样做。如果您还记得在第二章“编写您的第一个组件”部分中的早期配方创建，即“边缘工作负载基础”，配方可以定义一个ComponentConfiguration对象，该对象指定了组件在运行时将使用的默认设置。我们使用它来定义一个默认的World!文本，并将其传递给HelloWorld组件。这种组件配置也可以在部署到一台或多台设备时定义，以覆盖这些默认设置。当设置不同设备组的配置时，这很有用，例如，告诉所有我们的原型设备使用详尽的调试级别日志记录，而我们的生产设备使用警告级别日志记录以节省成本。以下是该实践效果的说明图：

图 4.5 – 覆盖设备群的配置

部署可以使用两个属性中的任何一个来定义组件配置，即reset和merge。reset属性告诉组件将配置恢复到给定配置键的默认值。merge属性告诉组件为给定的配置键应用新的配置，而不影响其他配置键的现有值。在同一个配置键上同时使用reset和merge属性将始终首先重置值，然后合并新值。这可以用于恢复默认值的树，然后合并树中单个节点的更新。

如果您检查deployment-logmanager.json文件，您可以看到我们正在使用的部署时配置合并，以告诉LogManager组件要做什么。以下是merge对象的格式化版本：

{
  "logsUploaderConfiguration": {
    "systemLogsConfiguration": {
      "uploadToCloudWatch": "true",
      "minimumLogLevel": "INFO",
      "diskSpaceLimit": "10",
      "diskSpaceLimitUnit": "MB",
      "deleteLogFileAfterCloudUpload": "false"
    },
    "componentLogsConfigurationMap": {
      "com.hbs.hub.HelloWithConfig": {
        "minimumLogLevel": "INFO",
        "diskSpaceLimit": "10",
        "diskSpaceLimitUnit": "KB",
        "deleteLogFileAfterCloudUpload": "false"
      }
    }
  },
  "periodicUploadIntervalSec": "300"
}

在部署中没有设置任何合并配置的情况下，这里使用的版本 2.2.0 的LogManager组件实际上并不做任何事情。您必须在部署时提供一些配置，才能将任何日志发送到云端。

在前面的示例中，有一个logsUploaderConfiguration配置键，它有两个子节点和一个间隔属性。systemLogsConfiguration节点指示LogManager组件将系统日志（如greengrass.log）上传到 Amazon CloudWatch IoT Greengrass。componentLogsConfigurationMap节点告诉LogManager组件如何选择性地上传其他组件的日志。您可以看到，我们正在定义一个com.hbs.hub.HelloWithConfig组件以包含到云中发送日志。您将为每个组件添加一个对象到这个列表中，以明确捕获日志。这里概述了两个最佳实践：

• 以编程方式生成您的部署配置，并根据该部署中包含的其他组件构建LogManager配置。在构建过程中检查您的部署中包含的组件的脚本可以在将其传递给CreateDeployment API 之前更新LogManager的componentLogsConfigurationMap节点。

• 创建一个事物组，例如CommonMonitoringTools，将所有您的 Greengrass 设备放入其中，并在systemLogsConfiguration节点中设置一个组级部署配置以捕获系统日志。您的所有设备随后将包含此组件和配置，从而实现默认行为以上传系统日志。然后，代表您的应用程序组件的单独事物组部署将合并componentLogsConfigurationMap节点的LogManager配置，以指定该应用程序组件的日志。这是因为来自两个不同事物组的两个部署可以在单个设备上堆叠，从而有效地合并单个组件的配置。图 4.3和图 4.5共同说明了这一概念。

最后关于配置管理的注意事项是解决前面格式化后的deployment-logmanager.json之间的差异。在撰写本文时，IoT Greengrass 部署 API 仅接受配置作为字符串对象，因此配置必须定义为 JSON，然后作为单个字符串发送到部署 API。当手动编写部署文件时，这会更不方便，但在以编程方式构建部署时，这是一个简单的附加步骤。在这种情况下，可以使用YAML Ain't Markup Language（YAML）格式而不是 JSON 来定义您的部署文件，因为 YAML 规范具有构建多行输入的语法支持。

现在，您已经有一个功能齐全、可管理的组件，可以将中枢的日志文件存储在云中，以便远程诊断您的边缘解决方案。您知道如何通过合并新的配置更改到配置中，向LogManager组件添加更多组件。通过这个过程，您了解了 IoT Greengrass 的组件配置系统，这将帮助您在创建新组件和构建由多个组件协同工作的部署时提供服务。在下一节中，您将学习如何使连接到您的中枢的叶设备交换消息并与云同步状态。

在边缘和云之间同步状态

如果 HBS 中枢设备被制成实际产品，它将通过网络协议与本地设备连接，并代理遥测数据和命令与云服务交互。在前一章中，我们使用运行在中枢设备上的组件来与树莓派 Sense HAT上的本地硬件接口进行交互。

当中枢设备通过串行接口与硬件通信时，这很有意义，但当通过网络通信时，那些设备监控套件实际上并不是在枢纽设备上运行的软件组件，它们使用Greengrass IPC接口交换消息。相反，它们可能使用网络协议，如消息队列遥测传输（MQTT），通过 Wi-Fi 或蓝牙与枢纽设备交换消息。

在本节中，您将部署新的管理组件，通过 MQTT 连接到叶设备，并将叶设备的遥测状态同步到云。

设备阴影简介

通过同步状态，我们指的是保持两个系统与最新值保持一致的结果。当与边缘和云一起工作时，我们必须承认并处理这样一个现实：边缘解决方案可能目前尚未连接到云服务。我们的叶设备和中枢设备可能正在使用尚未报告给云的已获取遥测数据。一旦中枢设备恢复与云的连接，就必须有一种机制来协调边缘和云的当前状态。

例如，如果我们的中枢设备因网络中断而与云断开连接，叶设备将获取新的遥测数据，并且来自云服务的新的远程命令可能已在客户的移动应用程序中排队。当连接恢复时，需要更新设备状态，以便一切都能同步。为此，AWS IoT Core 提供了一种名为设备阴影的服务，该服务作为设备和云之间的同步机制。IoT Greengrass 通过一个管理组件在边缘提供这种设备阴影服务。

设备影子是一个 JSON 文档，它总结了报告数据的当前状态和期望状态。通常这意味着设备负责更新报告的数据，而系统中的其他参与者则使用期望状态来指导设备。假设我们的中心设备应该将来自某个设备监控套件的最新温度测量值通知云。再假设客户的移动应用程序可以发送一个命令来重启监控套件，作为故障排除的一种形式。以下图表说明了这些消息如何在设备影子中存储，并在从网络中断事件恢复后进行协调：

![图 4.6 – 网络中断后同步的影子消息流

![img/B17595_04_06.jpg]

图 4.6 – 网络中断后同步的影子消息流

设备影子对于我们的边缘机器学习工作负载也非常有用，因为运行推理任务的组件可以订阅影子服务报告的变化，或者甚至注册自己的影子，以便与云和其他在 Greengrass 设备上运行的组件交换状态和命令。

在第三章的“连接您的第一个设备：边缘感知”和“连接您的第二个设备：边缘执行”部分中，您在“构建边缘”部分实现了 IPC，以便组件能够实时交换信息。影子可以通过定义同步状态文档来提升您的边缘解决方案，这些文档也可以通过 IPC 进行通信，甚至与云同步。这为一些有趣的使用案例打开了大门，进一步让您作为架构师专注于解决业务问题，而无需同时设计数据交换机制。以下是一些边缘组件运行的机器学习工作负载如何从使用影子中受益的例子：

• 报告和缓存应用程序状态：您的机器学习推理组件可以在每次使用机器学习模型处理新数据时创建一个本地影子，以存储最新的推理结果。如果模型被训练来报告在新的数据中检测到异常时，本地影子可以存储最新的异常分数和置信度评级。这样，设备上的其他组件可以订阅影子中的变化，并根据机器学习组件的输出改变其行为。这看起来可能类似于通过 IPC 发布更新，但这里的关键区别是，组件可以从影子中获取值，无论它们是否与机器学习组件上次发布异常分数时同时运行。从这个意义上说，影子被用作缓存机制，帮助我们解耦我们的边缘解决方案。

• 向组件发送命令：即使组件当前未运行，也可以使用阴影来指示组件的新命令或期望的行为。例如，如果组件在命令本应发送给它的时间崩溃或处于某种其他恢复状态，将此命令放入阴影中可以确保它在组件下次进入运行状态时被传递。结合将阴影同步到云 AWS IoT Core 服务，这使其他应用程序和设备能够以弹性方式与边缘的组件交互。

现在我们已经介绍了与阴影的状态同步，让我们继续进行将此功能部署到您的解决方案中的实际步骤。

部署状态同步组件的步骤

IoT Greengrass 提供了一些分离的托管组件的功能，用于连接叶设备、存储阴影和将消息同步到云。这些组件分别是aws.greengrass.clientdevices.mqtt.Moquette）、aws.greengrass.ShadowManager）和aws.greengrass.clientdevices.mqtt.Bridge）。

以下图示说明了此解决方案的架构以及这些组件如何协同工作以实现设备的状态同步：

图 4.7 – 使用托管组件的消息流示例

通过遵循本节的下一步，您将创建一个新的部署，使所有这三个托管组件能够在您的 C2 系统上启动一个新的独立应用程序，该应用程序通过 MQTT 连接到您的网关设备，并观察使用这些功能在边缘和云之间如何同步状态。按照以下步骤进行：

1. 在 AWS IAM 中更新您的 Greengrass 角色，以允许使用 AWS IoT Core 的设备阴影 API。这些步骤是针对 AWS IAM 的，代表了一种常见的流程，用于准备您的 Greengrass 设备使用新 API。然后，执行以下操作：

   1. 从chapter4目录中，创建一个新的 IAM 策略，如下所示：aws iam create-policy --policy-name greengrass-use-shadows --policy-document file://greengrass_use_shadows.json --description "允许 Greengrass 核心与 AWS IoT Core 设备阴影交互"。

   2. 从create-policy命令的响应中复制策略 ARN，并在下一个attach-role-policy命令中使用它。它看起来像这样，但用您的账户号替换：arn:aws:iam::01234567890:policy/Greengrass-use-shadows。

   3. 将新策略附加到您的 Greengrass IAM 角色，将上一个步骤中的policy-arn参数替换为您自己的，如下所示：aws iam attach-role-policy --role-name GreengrassV2TokenExchangeRole --policy-arn arn:aws:iam::01234567890:policy/Greengrass-use-shadows。

2. 编辑deployment-syncstate.json文件以更新您的账户 ID 的targetArn属性。保存文件。

3. 使用deployment-syncstate.json文件创建一个新的部署。在继续下一步之前，请确认部署已完成且成功。您可以使用list-effective-deployments AWS CLI 命令验证或检查在 AWS IoT Greengrass 管理控制台中的状态，该控制台位于console.aws.amazon.com/iot。

4. 启动本地设备客户端以通过 MQTT 连接到您的网关设备。从 GitHub 仓库的chapter4/apps目录中，运行以下命令：./client.sh。

apps/client.sh脚本使用您的 AWS 凭据在 AWS IoT Core 中注册一个新设备，下载生成的x.509私钥和证书，并将设备添加到 Greengrass 核心关联设备列表中。然后，它安装 AWS IoT Device SDK for Python 并启动一个 Python 应用程序，该应用程序在本地网络上发现您的网关设备并与之连接，以通过 MQTT 交换消息。运行此应用程序的目的是演示 Greengrass 如何支持本地设备的消息交换。

注意

如果您的 C2 笔记本电脑与您的网关设备不在同一网络中，您可以在您的网关设备上运行客户端应用程序。但是，您需要更新在网关设备上配置的idtgg AWS 用户的权限，因为它还没有必要的权限。返回 AWS 管理控制台中的 IAM，找到名为Provision-IDT-Greengrass的用户组，通过附加策略添加新的权限，并选择名为AWSIoTFullAccess的策略。然后，您可以使用那里现有的凭据在您的网关设备上运行client.sh应用程序，这些凭据可以在第二章的边缘工作负载基础中找到。

client.sh应用程序将在一个专门用于设备影子通信的主题上发布新消息。主题地址是$aws/things/localdevice/shadow/update。客户端报告一个随机生成的温度值，就像它是本地网络上的另一个传感器一样。您可以使用 AWS IoT Core 管理控制台在console.aws.amazon.com/iot验证这些消息是否已上传到云端。导航到$aws/things/localdevice/shadow/update/accepted主题以查看发布的结果。以下是一个示例：

![图 4.8 – AWS IoT Core 控制台接受的影子更新的截图

![图 4.8 – AWS IoT Core 控制台接受的影子更新的截图

图 4.8 – AWS IoT Core 控制台接受的影子更新的截图

您也可以通过这个测试客户端与本地设备应用程序进行交互。您可以向本地设备发送一个新的期望状态，并且它将合并命令到下一个报告消息中。使用 MQTT 测试客户端在$aws/things/localdevice/shadow/update主题上发布一条消息，内容如下：{"state":{"desired":{"valve":"open"}}}。您应该在您的订阅和在client.sh应用程序的标准输出中看到，现在报告状态中的阀门是打开的，而不是期望状态。这意味着本地设备通过 Greengrass 接收到了命令，处理了该命令，并相应地更新了其报告状态。

您可以通过在 MQTT 测试客户端中发布更多消息到期望状态来继续实验。实际设备会对期望状态做出一些响应，但此应用程序只是将命令从期望状态复制到报告状态，以模拟处理事件。

为了演示 MQTT 桥接管理组件的功能，client.py应用程序也在dt/localdevice/heartbeat地址的另一个主题上发布心跳消息。这样做的原因是，当使用影子主题时，影子管理器组件实际上为我们处理了所有状态同步。对于任何其他主题和数据发布，例如这个心跳行为，我们必须使用 MQTT 桥接组件将消息从边缘传输到云（或反之亦然）。使用 MQTT 测试客户端订阅dt/localdevice/heartbeat以查看这些消息在云中到达。

尝试一些有趣的事情，比如暂时将您的中心设备离线，并重复之前的步骤，但将阀门期望状态设置为关闭。这将演示当 Greengrass 设备下次上线时，影子服务消息是如何缓冲以供发送的。在您的中心设备上，断开网络连接（无论是通过拔掉以太网电缆还是禁用 Wi-Fi）。您应该不会在 MQTT 测试客户端的影子或心跳主题上看到任何消息到达。在 MQTT 测试客户端中发布一条新消息，例如{"state":{"desired":{"valve":"open"}}}，然后恢复网络连接。您将看到，一旦中心设备重新建立连接，本地设备将接收到新的命令，以及心跳消息的恢复。

扩展管理组件

部署的示例使用 AWS 管理的组件，通过 MQTT 代理为本地设备建立连接，在边缘和云之间发送和接收消息，并与设备的影子服务同步状态。您可以通过合并进一步的配置更新来为您的用例配置这些组件。让我们检查此部署中使用的配置，然后回顾一些更多选项和最佳实践。

注意

对于本节中审查的任何配置 JSON，本书使用的是一种美观打印格式，这与您在实际上部署的文件中看到的格式不匹配，其中 JSON 根据 API 要求进行了字符串化和转义。这是为了在书籍格式中方便和易于阅读而进行的。

阴影管理器

在deployment-syncstate.json文件的aws.greengrass.ShadowManager组件配置中，我们必须明确指定哪些设备阴影将在边缘和云之间保持同步。我们使用的配置定义了名为localdevice的设备阴影，该设备阴影与apps/client.sh应用程序的客户端 ID 相匹配。以下是实现该配置的配置示例：

{
  "synchronize":{
    "shadowDocuments":[
      {
        "thingName":"localdevice",
        "classic":true,
        "namedShadows":[]
    ]
  }
}

经典阴影是 AWS IoT Core 中任何设备的根级阴影。命名阴影是属于设备的子项，一个设备可以有任意数量的附加子阴影来帮助关注点分离（SoC）。在这种情况下，仅使用经典阴影就足够了。

对于您希望 Greengrass 解决方案保持同步的每个设备，您需要配置来指定该设备在shadowDocuments列表中，其中thingName是您用于通过 MQTT（AWS IoT Core 根据物联网的命名约定定义了许多资源和服务 API，将设备表示为事物）连接的设备名称。

您的 Greengrass 核心设备本身是在 AWS IoT Core 中注册的事物，可以使用经典和命名阴影。这些阴影可以用来表示中心设备本身的状态，或者用于中心设备上的组件与某些期望的命令进行协调；例如，将期望状态发送到中心设备的阴影以进入低带宽状态可能会被设备上运行的任何组件捕获并相应地执行。为您的 Greengrass 核心设备启用阴影同步需要在shadowDocuments属性之外进行单独的配置。以下是一个示例：

{
  "synchronize":{
    "coreThing":{
      "classic":true,
      "namedShadows":[
        "CoreBandwidthSettings",
        "CorePowerConsumptionSettings"
      ]
    },
    "shadowDocuments":[ ... ]
}

本节涵盖了您需要了解的 AWS IoT Core 中阴影的相关知识以及如何配置阴影管理器组件。接下来，让我们回顾 MQTT 桥接组件。

MQTT 桥接

aws.greengrass.clientdevices.mqtt.Bridge组件负责在 Greengrass 支持的三个消息通道之间中继消息。这三种消息通道如下所示：

• 组件用于消息的本地 IPC 主题

• Moquette MQTT 代理组件启用的本地 MQTT 主题

• 使用 AWS IoT Core 的云 MQTT 主题

配置 MQTT 桥接功能使您能够创建消息流，从一个通道的主题跨越边界到另一个通道的主题——例如，将发布在dt/device1/sensors IPC 主题上的消息复制到dt/sensors/all AWS IoT Core 主题，以便进行云摄入。

与影子管理组件类似，必须在组件的配置中显式定义源和目标主题的每个映射。为了使来自client.sh应用程序的心跳消息到达云端，我们在 MQTT 网桥中使用了以下配置：

{
  "mqttTopicMapping": {
    "ForwardHeartbeatToCloud": {
      "topic": "dt/localdevice/heartbeat",
      "source": "LocalMqtt",
      "target": "IotCore"
    }
}

而不是为每个使用心跳模式的设备创建一个映射，你可以使用 MQTT 通配符并将主题更新为dt/+/heartbeat。最佳实践是为每个预期的设备显式定义一个映射，除非你有设备可能在多个网关设备之间迁移且无法具体预测哪些设备可能会发布的情况，否则应避免使用通配符。通配符非常适合简化手动输入的配置和可读性，但会引入不可预见行为的风险。通配符也不支持用于 IPC 的Pubsub类型主题。

这里是另一个使用 MQTT 网桥允许从其他 AWS IoT Core 设备或应用程序直接向运行在 Greengrass 核心上的组件发送命令的示例。这个示例的目的是展示我们如何更新所有基于机器学习的组件的设置，以调整推理活动中模型的使用率。订阅了 IPC 主题的组件可以接收更新，而无需进行完整的 Greengrass 部署：

{
  "mqttTopicMapping": {
    "RemoteUpdateMLComponents": {
      "topic": "cmd/ml-components/inferenceRate",
      "source": "IotCore",
      "target": "Pubsub"
    }
}

你现在已经完成了部署用于在边缘和云端之间来回移动消息的管理组件。这个功能为本地设备通过中心设备相互通信、组件与云服务交互以及任何其他本地设备、组件和云之间交换消息的组合创建了一条路径。你还学习了 AWS IoT Core 和设备影子服务如何同步基于底层消息系统的本地设备和组件的状态。这些工具使你能够在不编写任何代码或管理消息需求的基础设施的情况下，根据任何类型的消息要求构建边缘机器学习解决方案。

在下一节中，你将使用预构建的模型、推理代码和用于对推理结果采取行动的自定义组件的组合来部署你的第一个机器学习模型。

部署你的第一个机器学习模型

现在你已经熟悉了远程部署和从云端加载资源，是时候将你的第一个基于机器学习的功能部署到边缘了！毕竟，一个使用机器学习模型的组件就像我们部署的其他组件一样。它是由托管在云端的依赖项、运行时代码和静态资源组合而成的。

审查机器学习用例

在这种情况下，依赖项是用于 OpenCV（一个用于计算机视觉（CV）用例的开源库）和 深度学习运行时（DLR）的包和库，运行时代码是使用 DLR 的预配置推理代码样本，静态资源是预配置的图像分类模型存储和一些示例图像。本例中部署的组件全部由 AWS 提供和管理。

您将部署的解决方案模拟了我们 HBS 设备中心的使用案例，该中心作为我们客户家庭安全故事的一部分执行简单的图像分类。

假设一个附加设备，HBS 客户可以为其中心购买的是一款安全摄像头，当有人接近前门时，它会通知客户。摄像头设备会定时拍照或与运动传感器配对，并将该图像作为文件存储在中心设备上。然后，中心设备使用本地机器学习模型对该图像进行推理，以识别是否检测到任何人。如果是这样，可以在中心设备上播放音频通知或将文本通知发送给客户。以下是解决方案及其各部分的示意图：

图 4.9 – 通过摄像头识别的受识别主题的音频通知示例架构

今天，这种安全功能在市场上有很多产品。然而，尚未普及的是在边缘执行机器学习推理。这提供了一个关键的区别机会，因为通过节省图像传输到云端的带宽和节省在云端运行机器学习推理的计算成本，总拥有成本（TCO）会降低。即使客户的互联网服务中断，安全解决方案也能保持运行，并且不依赖于云服务的可用性。处理和通知延迟也有实际的好处，以及一个吸引客户的隐私故事，因为任何图像数据都保留在本地。

本用例演示了我们已在 第一章 中介绍的数据驱动边缘机器学习的四个关键优势：延迟、可用性、成本和治理。

部署机器学习工作负载的步骤

本节所需采取的步骤相当简单，多亏了 AWS 提供的托管组件。需要从 AWS 目录部署三个组件，以及一个额外的自定义组件来处理推理结果。由于目标原型硬件 Raspberry Pi 和 Sense HAT 不包括任何摄像头接口，我们将依赖托管组件中提供的示例图像来模拟传感器。一个自定义组件作为我们的执行器，它将在发光二极管（LED）上显示推理结果。

注意

如果您不使用目标 Raspberry Pi 和 Sense HAT 硬件，您必须修改步骤以使用 com.hbs.hub.ScrollMessageSimulated 组件。或者，您可以使用 AWS IoT Core 管理控制台（在第 5 步 中介绍）查看推理结果，任何连接到 AWS IoT Core 的其他 MQTT 客户端（订阅在第 5 步 中标记的主题），或查看推理组件日志（在设备本地或将这些日志添加到 LogManager 配置中）。

以下步骤将机器学习解决方案部署到中心设备：

1. 将 Raspberry Pi 更新为安装 OpenCV 依赖项。我们在这里通过手动安装依赖项来简化步骤，而不是增加示例的复杂性（更多内容将在步骤之后介绍）。其他目标平台可能只需要安装 glibc，而托管组件将根据需要安装依赖项。打开到您的 Pi 的 ssh 连接或直接在设备上打开终端程序。运行以下命令：sudo apt-get install libopenjp2-7 libilmbase23 libopenexr-dev libavcodec-dev libavformat-dev libswscale-dev libv4l-dev libgtk-3-0 libwebp-dev。

2. 在您的 AWS 账户中从书籍仓库的源创建一个新的自定义组件，用于 com.hbs.hub.ScrollMessage 组件。这些步骤与 在 IoT Greengrass 中注册组件 部分的 1-4 步骤 相同。将此组件的 archive.zip 文件上传到 S3，编辑配方文件以指向 S3 中的工件，然后注册新的自定义组件。

3. 编辑 deployment-ml.json 文件以更新 targetArn 属性，如过去章节中所述。保存文件。

4. 使用 deployment-ml.json 文件创建一个新的部署，如下所示：aws greengrassv2 create-deployment --cli-input-json file://deployment-ml.json。

5. 当部署完成时（在 Pi 上安装捆绑的 DLR 依赖项可能需要几个小时），您应该开始在您的 Sense HAT LED 矩阵上看到新的推理结果。对于不使用带有 Sense HAT 的 Raspberry Pi 的读者，您可以使用 AWS IoT Core 管理控制台查看结果。登录到 console.aws.amazon.com/iot，导航到 ml/dlr/image-classification 机器学习推理主题。

如果您使用 AWS IoT Core 控制台或 MQTT 客户端检查推理结果，它们应该看起来像这样：

![图 4.10 – AWS IoT Core 中推理结果的截图

图 4.10 – AWS IoT Core 中推理结果的截图

您现在已将第一个机器学习工作负载部署到边缘！此工作负载将以 10 秒的间隔持续运行，并将处理在中心设备上找到的文件 /greengrass/v2/packages/artifacts-unarchived/component-name/image_classification/sample_images/cat.jpeg。有几种方法可以扩展此示例以供您自己的测试和使用案例，例如以下方法：

• 使用aws.greengrass.DLRImageClassification组件指定处理图像的来源位置——例如，您可以使用ImageDirectory参数指定一个新目录，并使用ImageName参数指定一个文件名。然后，您可以创建一个包含您自己的图像作为工件的自定义组件，并在此路径下通过该文件名旋转它们，以查看分类引擎识别的内容。

• 使用aws.greengrass.DLRImageClassification组件指定一个摄像头作为要分类的图像的源。对于在 Raspberry Pi 设备上进行原型设计，您可以连接一个通用串行总线（USB）摄像头或Raspberry Pi Camera Module v2。有关如何设置组件以使用摄像头的更多详细信息，请参阅本章末尾的参考部分。

• 对特定分类结果类型的事件进行升级：当前工作负载报告了指定主题上的所有推理结果。您可以修改订阅这些结果的定制组件，并且仅在推理结果中检测到人类时更新执行器。或者，您可以在另一个预留用于警报的主题上发布消息，并配置 AWS IoT Core 和Amazon Simple Notification Service（Amazon SNS）在检测到人类时向您发送警报。对于这些事件，您可能还希望将检测到的图像存储起来以供将来参考。

• 部署对象检测工作负载：本示例演示了将源图像中的主要对象进行分类的使用场景。另一种使用场景是列出源图像中检测到的所有对象。AWS 还提供了用于对象检测工作负载以及运行在 DLR 或 TensorFlow 框架上的 CV 用例的托管组件。

• 通知新图像可用：托管组件设计了一个间隔模式来处理源图像与 ML 模型的匹配。您可以设计一个变体，订阅本地 IPC 主题，并等待另一个组件的通知，表明需要进行推理，并可以在消息中指定文件路径。

如在 Raspberry Pi 上安装依赖步骤中所述，这些步骤采取了一种捷径，并不反映我们解决方案设计的最佳实践。与其手动在设备上安装依赖项，不如使用 IoT Greengrass 来安装那些缺失的依赖项。本节本可以向您介绍如何分叉 AWS 托管组件，以便在安装生命周期步骤中添加更多依赖项，但考虑到本练习的目的，认为这不是一个有价值的偏离。

此外，aws.greengrass.DLRImageClassification托管组件的默认行为是将推理结果发布到 AWS IoT Core 上的云主题，而不是 IPC 上的本地主题。对于将所有活动报告到云的工作负载，这是期望的行为。然而，鉴于本书中概述的最佳实践，在本地执行数据分析并解耦我们的组件，我们更倾向于在本地 IPC 主题上发布，并让另一个组件决定哪些消息需要升级到云。

这不能通过简单地更新组件的 2.1.3 版本中定义的配置来实现。再次强调，为了本练习的目的，将组件分叉以替换云发布为本地发布并不被认为是有价值的，因此云发布行为保持不变。

随着您的第一个基于机器学习的作业部署完成，您现在已经了解了机器学习组件是如何作为依赖项、代码和静态资源的组合部署到边缘的。

在本节中，您部署了三个组件作为解耦的依赖项、运行时和模型集，再加上一个作用于您机器学习模型推理结果的定制组件。综合来看，您已经拥有了扩展这些组件以提供您自己的图像分类和目标检测工作负载的所有基础知识。接下来，让我们总结一下本章您所学到的一切。

摘要

本章向您介绍了将组件远程部署到 Greengrass 设备的关键差异，如何使用 AWS 提供的托管组件加速您的解决方案开发，以及如何在原型中心设备上部署您的第一个机器学习作业。到目前为止，您已经拥有了开始编写自己的组件和设计边缘解决方案所需的所有基础知识。您甚至可以扩展托管机器学习组件，以开始一些基本的计算机视觉项目。如果您今天在业务中使用的是作为容器化代码训练的机器学习模型和推理代码，您现在就可以开始将它们作为定制组件部署到边缘。

在下一章（第五章**Chapter 5），从边缘摄取和流式传输数据，您将了解数据如何在边缘的规范性结构、模型和转换中移动。在边缘正确处理数据对于增加边缘机器学习解决方案的效率、弹性和安全性至关重要。

知识检查

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

1. 有哪些例子可以区分边缘组件的静态资源和动态资源？

2. 您的组件工件存储在哪里，以便它们可以被您的配方文件引用？

3. 您能否修改已包含在已注册的定制组件中的云存储工件？

4. 为什么您不能写入通过部署加载到边缘设备的工件文件？

5. 对或错：边缘设备可以属于云 AWS IoT Core 服务中的多个事物组，并且每个事物组可以有一个与之关联的激活 Greengrass 部署。

6. 你能想到一个用例，其中一个边缘设备可以接收来自多个事物组的部署吗？

7. 对或错：单个部署可以重置组件的配置并应用新配置的合并。

8. 以下哪个管理组件负责部署本地 MQTT 代理并连接叶设备？

   MQTT 代理桥接/Moquette/设备影子

9. 以下哪个管理组件负责在边缘和云之间同步状态？

   MQTT 代理桥接/Moquette/设备影子

10. 以下哪个管理组件负责在 MQTT、IPC 和云等通信渠道之间中继消息？

    MQTT 代理桥接/Moquette/设备影子

11. 你如何设计从本地 IoT 传感器到运行机器学习推理的应用程序的数据流，并通过连接的扬声器播放警报声音？考虑不同的通信渠道和我们的最佳实践——解耦服务。试着在纸上勾勒出来，就像你正在向同事提出设计方案一样。

参考文献

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

• 使用 TensorFlow Lite 在相机图像上执行样本图像分类推理：docs.aws.amazon.com/greengrass/v2/developerguide/ml-tutorial-image-classification-camera.html

• AWS 提供的组件：docs.aws.amazon.com/greengrass/v2/developerguide/public-components.html

• OpenCV 网站：opencv.org/

• AWS IoT 设备影子服务：docs.aws.amazon.com/iot/latest/developerguide/iot-device-shadows.html

• DLR：机器学习模型的紧凑型运行时：neo-ai-dlr.readthedocs.io

• TensorFlow 网站：www.tensorflow.org/

第五章：第五章：从边缘摄取和流式传输数据

边缘计算可以减少传输到云（或本地数据中心）的数据量，从而节省网络带宽成本。通常，高性能的边缘应用程序需要本地计算、存储、网络、数据分析以及机器学习能力，以在低延迟下处理高保真数据。AWS 将基础设施扩展到边缘，超出区域和可用区，以满足您的工作负载需求。正如您在前几章中学到的，AWS IoT Greengrass允许您在设备和网关上运行复杂的边缘应用程序。

在本章中，您将了解适用于边缘工作负载的不同数据设计和转换策略。我们将解释您如何根据数据速度（如热、温和冷）、数据多样性（如结构化和非结构化）以及数据量（如高频或低频）在边缘通过不同的工作流程摄取来自不同传感器的数据。之后，您将学习从边缘将原始和转换后的数据流式传输到不同云服务的方法。到本章结束时，您应该熟悉使用 AWS IoT Greengrass 进行数据处理。

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

• 定义物联网工作负载的数据模型

• 为边缘设计数据模式

• 了解 Stream Manager

• 在边缘构建您的第一个数据编排工作流程

• 从边缘流式传输到云上的数据湖

技术要求

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

您可以在此处找到 GitHub 代码仓库：github.com/PacktPublishing/Intelligent-Workloads-at-the-Edge/tree/main/chapter5

定义物联网工作负载的数据模型

根据 IDC 的预测，到 2025 年，全球数据总量将从 2018 年的 33 泽字节（ZB）增长到 175 ZB。此外，IDC 估计到 2025 年将有 416 亿个连接的物联网设备或事物，产生 79.4 ZB 的数据（www.datanami.com/2018/11/27/global-datasphere-to-hit-175-zettabytes-by-2025-idc-says/）。此外，许多其他来源重申，数据和信息是货币、生命线，甚至是信息行业中的新石油。

因此，数据驱动型经济将长期存在，物联网（IoT）将作为推动者，从大量设备（或端点）如传感器和执行器中获取数据，并生成汇总见解以实现业务成果。因此，作为一名物联网从业者，你应该熟悉数据建模的基本概念以及它是如何实现边缘数据管理的。

所有行业，如工业、商业、消费、交通、能源、医疗保健等，都在探索新的用例以提高其收入或利润，并为顾客创新。物联网设备，如消费者家庭中的连接中心、道路上的智能停车计费器或连接汽车，将与客户共存，即使在没有互联网连接的情况下也能运行。

这是从过去为企业工作的集中式解决方案到的一种范式转变。例如，一位银行员工可能将他们的工作负载托管在数据中心，但现在他们可以在其分支机构实时监控客户活动（如可疑行为、人流量或 ATM 中的现金可用性），以更好地服务客户。因此，需要一种新的策略来处理本地生成数据，并能够从边缘处理和流式传输数据到云端。

在本章中，我们将重新思考和评估不同大数据架构在物联网和边缘计算环境下的适用性。我们将考虑的三个领域是数据管理、数据架构模式和反模式。

什么是数据管理？

根据数据管理协会（DAMA）的数据管理知识体系（DMBOK2），数据管理是制定、执行和监督计划、政策、项目和做法，以在整个生命周期中交付、控制、保护和增强数据和信息资产的价值（更多信息，请参阅DAMA-DMBOK2）。

DAMA 详细介绍了数据管理框架，如下所示：

![图 5.1 – 数据管理生命周期]

![图片 B17595_05_001.jpg]

![图 5.1 – 数据管理生命周期]

在这里，我们认识到一个机会，即通过边缘计算的相关概念来增强 DAMA 框架。因此，在本节中，我们将更深入地探讨与数据建模、数据架构和数据集成与互操作性（DII）相关的原则，我们认为这些原则与边缘计算和物联网相关。

在我们讨论如何建模数据之前，让我们先定义物联网环境下的数据。物联网数据来自不同的传感器、执行器和网关。因此，它们可以以不同的形式出现，如下所示：

• 结构化数据：这指的是一种可预测的数据形式；例如，包括设备元数据和设备关系。

• 半结构化数据：这是一种具有一定程度变异性和随机性的数据形式；例如，包括传感器和执行器馈送。

• 非结构化数据：这是一种具有更高程度变异性和随机性的数据形式；例如，包括原始图像、音频或视频。

现在，让我们讨论如何使用数据建模技术来治理、组织和存储不同形式的数据。

什么是数据建模？

数据建模是软件工程中的一种常见实践，其中定义并分析数据需求，以支持组织范围内不同信息系统中的业务流程。存在三种不同类型的数据模型：

• 概念数据模型

• 逻辑数据模型

• 物理数据模型

在以下图中，展示了不同建模方法之间的关系：

图 5.2 – 数据建模方法

有趣的事实

在第二次世界大战期间，德国军队使用恩尼格玛机作为所有安全无线通信的主要通信方式。大约 80 年前，当艾伦·图灵破解了每条消息末尾放置的文本时，他破解了恩尼格玛密码。这有助于解读德国军队的关键秘密信息，并帮助结束世界大战。此外，这种机制导致了通过定义一种解码数据的语言来解锁洞察力的时代，这后来被正式化为数据建模。

对于数据库而言，最常见的数据建模技术是实体-关系（ER）模型。在软件工程中，ER 模型是一种常见的以图形方式表示不同实体（如人、物体、地点、事件等）之间关系的方法，以便更好地组织信息，推动组织的业务流程。换句话说，ER 模型是一种抽象的数据模型，它定义了所需信息的结构，可以独立于任何特定的数据库技术。在本节中，我们将使用 ER 模型方法解释不同的数据模型。首先，让我们借助用例图来定义客户与其关联的连接 HBS 中心设备的关联关系：

图 5.3 – 用例图

现在，让我们通过一系列概念性、逻辑性和物理模型来构建 ER 图：

1. 概念数据模型定义了实体及其关系。这是数据建模练习的第一步，由数据架构师等角色使用，从业务利益相关者那里收集初始需求集。例如，传感器、设备和客户是关系中的三个实体，如下所示图所示：![图 5.4 – 概念数据模型

   ![img/B17595_05_004.jpg]

   图 5.4 – 概念数据模型

2. 然后将概念模型转换为逻辑数据模型。在数据建模的这个步骤中，使用概念模型作为基础定义了数据结构以及附加属性。

   例如，你可以定义关系中的不同实体的属性，如传感器类型或设备标识符（通常是一个序列号或 MAC 地址），如下所示。此外，还可能有不同形式的关系，如下所示：

   • 关联是设备和传感器之间的关系。

   • 所有权是客户和设备之间的关系。

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

   ![图 5.5 – 逻辑数据模型

   ![img/B17595_05_005.jpg]

   图 5.5 – 逻辑数据模型

3. 数据建模的最后一步是从定义的逻辑模型构建一个物理数据模型。物理模型通常是数据模型的技术或产品特定实现。例如，你为实体的不同属性定义数据类型，如数字或字符串，这些将在特定供应商的数据库解决方案上部署：

![图 5.6 – 物理数据模型

![img/B17595_05_006.jpg]

图 5.6 – 物理数据模型

企业已经使用 ER 建模几十年来自行设计和治理复杂分布式数据解决方案。所有前面的步骤都可以可视化为以下工作流程，这并不局限于任何特定的技术、产品、领域或操作环境（如数据中心、云或边缘）：

![图 5.7 – 数据建模流程

![img/B17595_05_007.jpg]

图 5.7 – 数据建模流程

现在你已经了解了数据建模的基础，在下一节中，让我们看看如何为物联网工作负载实现这一点。

你如何设计物联网的数据模型？

现在，让我们看看如何将前面提到的数据建模概念应用到物联网工作负载中常见的结构化、非结构化和半结构化数据的例子。通常，当我们提到结构化数据的数据建模时，首先想到的是关系数据库（RDBMS）。然而，对于大多数物联网工作负载，结构化数据通常包括设备与其他实体之间的层次关系。这最好用图或有序键值数据库来展示。同样，对于半结构化数据，在物联网工作负载中，它通常被表示为键值、时间序列或文档存储。

在本节中，我们将向您展示使用 NoSQL 数据解决方案的数据建模技术，以继续为 HBS 构建更多功能。建模 RDBMS 超出了本书的范围。然而，如果您对此感兴趣，互联网上有大量可供参考的材料。

NoSQL 数据库旨在为开发者提供从较长的数据库模式设计周期中解脱出来的自由。然而，认为 NoSQL 数据库缺乏任何数据模型是错误的。设计 NoSQL 解决方案与 RDBMS 设计截然不同。对于 RDBMS，开发者通常创建一个遵循规范化指南的数据模型，而不关注访问模式。数据模型可以在出现新的业务需求时进行修改，从而导致漫长的发布周期。收集的数据以不同的表格形式组织，包括行、列和参照完整性。相比之下，对于 NoSQL 解决方案设计，开发者必须知道需要回答的问题才能开始设计模型。从用例反向理解业务查询是至关重要的。因此，在通过关系型或 NoSQL 数据库进行数据建模时，要记住的一般规则如下：

• 关系型建模主要关注数据的结构。设计原则是我能得到什么答案？

• NoSQL 建模主要关注特定于应用程序的访问模式。设计原则是我要问什么问题？

  有趣的事实

  NoSQL 的常见缩写翻译为不仅 SQL。这突出了 NoSQL 不仅支持 NoSQL，还可以处理关系型、半结构化和非结构化数据。例如，亚马逊、Facebook、Twitter、LinkedIn 和谷歌等组织都设计了不同的 NoSQL 技术。

在我向您展示一些数据建模的例子之前，让我们了解我们的应用程序（即 HBS 中心）的访问模式的五个基本属性，这些属性需要考虑以便提出相关的问题：

• 数据类型：范围内的数据类型是什么？例如，数据是否与遥测、命令控制或关键事件相关？让我们快速回顾一下这些数据类型的用法：

  a) 遥测：这是由传感器/执行器（如温度或湿度读数）发出的持续数据流，可以在边缘进行聚合或直接发布到云中进行进一步处理。

  b) 命令与控制：这些是可执行的消息，例如开关灯，可以在两个设备之间或终端用户与设备之间发生。

  c) 事件：这些是比常规遥测数据更复杂的场景的数据模式，例如家庭中的网络中断或建筑中的火灾警报。

• 数据大小：范围内的数据量是多少？是否需要本地（在边缘）存储和检索数据，或者数据需要传输到不同的数据持久化层（如云上的数据湖）？

• 数据形状：从不同的边缘设备（如文本、二进制大对象和图像）生成数据的格式是什么？请注意，图像和视频等不同数据形式可能具有不同的计算需求（例如 GPU）。

• 数据速度：基于所需延迟，数据处理查询的速度是多少？你有没有热、温或冷的数据路径？

• 数据一致性：这些数据中有多少需要强一致性而不是最终一致性？

回答前面的问题将帮助您确定解决方案是否应该基于以下之一：

• BASE 方法：基本可用性、软状态、最终一致性，这是 NoSQL 数据库的典型特征

• ACID 方法：原子性、一致性、隔离性和持久性，这是关系数据库的典型特征

我们将在下一节更详细地讨论这些概念。

在物联网工作负载中选择 ACID 或 BASE

以下表格列出了两种方法之间的一些关键区别。这应该能够帮助你从用例反向做出明智的决定：

图 5.8 – ACID 与 BASE 总结

有趣的事实

ACID 和 BASE 代表了 pH 谱的相对面。吉姆·格雷在 1970 年提出了这个想法，并在 1981 年 6 月发表了一篇名为《事务概念：优点与局限》的论文。

到目前为止，你已经理解了数据建模和设计方法的基本原理。你一定很好奇如何将这些概念与你之前章节中开发的连接型 HBS 产品联系起来。让我们看看如何将理论与实践相结合。

你还记得数据建模的第一个阶段吗？

Bingo！概念上是这样的。

连接型 HBS 中心的概念建模

以下图是一个假设的概念模型，描述了 HBS 中心：

图 5.9 – 连接型 HBS 的概念数据模型

在前面的图中，你可以观察到不同的设备，如灯光、HVAC 和洗衣机，是如何安装在一所房子的不同房间里的。现在概念模型已经建立，让我们看看逻辑视图。

连接型 HBS 中心的逻辑建模

为了构建逻辑模型，我们需要问自己最终消费者可能会问的问题类型，例如以下问题：

• 显示设备的状态（例如，洗涤是否完成？）。

• 打开或关闭设备（例如，关闭灯光）。

• 显示设备的读取（例如，现在的温度是多少？）。

• 进行新的读取（例如，冰箱消耗了多少能量？）。

• 显示设备（或设备）在一段时间内的聚合连接状态。

为了回答这些问题，让我们确定我们的最终应用程序的访问模式：

图 5.10 – 连接型 HBS 的逻辑数据模型

现在我们已经捕捉到了数据建模需求的总览，您可以看到解决方案需要以高频率摄取结构化和半结构化格式的数据。此外，它不需要强一致性。因此，使用利用 BASE 方法的 NoSQL 解决方案来设计数据层是有意义的。

连接的 HBS 中心物理建模

作为最后一步，我们需要根据收集到的需求定义物理数据模型。为此，我们将定义一个主键和一个二级键。如果您不知道所有属性，您不需要定义所有属性，这是 NoSQL 解决方案的一个关键优势。

定义主键

如其名所示，这是表中的一个必需属性，通常被称为分区键。在一个表中，没有两个主键应该有相同的值。还有一个复合键的概念。它由两个属性组成，一个分区键和一个排序键。

在我们的场景中，我们将创建一个具有复合键（如图所示）的Sensor表。主键是一个设备标识符，排序键是一个时间戳，它使我们能够查询时间范围内的数据：

![图 5.11 – 传感器表中的复合键

图 5.11 – 传感器表中的复合键

定义二级索引

一个二级索引允许我们使用不同的键查询表中的数据，除了对主键或复合键的查询。这为您的应用程序在查询不同用例的数据时提供了更多的灵活性。使用二级索引进行查询与直接从表中查询非常相似。

因此，对于二级索引，如以下图表所示，我们选择了主键作为传感器标识符（sensor_id）以及时间戳作为排序键：

![图 5.12 – 传感器表中的二级索引

图 5.12 – 传感器表中的二级索引

定义额外的属性

NoSQL 解决方案的关键优势是没有强制性的模式。因此，可以在数据到来时动态创建其他属性。话虽如此，如果开发人员已经知道一些属性，则没有限制将它们包含在数据模型中：

![图 5.13 – 传感器表中的其他属性

图 5.13 – 传感器表中的其他属性

现在数据层已经存在，让我们创建访问这些数据的接口。

定义接口

现在我们将为传感器表创建两个不同的方面。方面是一个虚拟结构，它使您能够以不同的视图查看存储在表中的数据。方面可以映射到功能结构，如方法或 API，以执行对表的各种创建、读取、更新、删除（CRUD）操作：

• putItems：此维度允许写入操作，并在有效载荷中至少需要复合键。

• getItems：此维度允许查询具有所有或选择性属性的项的读取操作。

以下截图展示了getItems维度的定义：

![图 5.14 – getItems维度的定义

图 5.14 – getItems维度的定义

因此，现在你已经创建了数据模型及其接口。这使你能够理解开发边缘应用所需的数据特性。

在边缘设计数据模式

当数据从边缘的不同传感器/执行器通过不同的协议或通道安全地流向网关或云端时，它需要被安全存储、处理和编目以供进一步消费。因此，任何物联网数据架构都需要考虑数据模型（如前所述）、数据存储、数据流模式以及反模式，这些内容将在本节中介绍。让我们从数据存储开始。

数据存储

云端的大数据解决方案旨在可靠地存储千兆字节、太字节或艾字节的数据，并能够跨全球多个地理位置进行扩展，以提供高可用性和冗余，以满足企业满足其恢复时间目标（RTO）和恢复点目标（RPO）。然而，边缘解决方案，如我们自己的连接 HBS 中心解决方案，在计算、存储和网络方面资源有限。因此，我们需要设计边缘解决方案以适应不同的时效性、低延迟用例，并将重负载交给云端。数据湖是云端的知名模式，它允许集中存储到达的数据，而无需首先对数据进行结构化。之后，可以对数据进行不同类型的分析、机器学习和可视化，以帮助消费者实现更好的业务成果。那么，边缘的数据湖是什么？

让我们介绍一种新的模式，称为数据池塘，用于在边缘生成并临时持久化的数据权威来源（即，金数据源）。以下列出了数据池塘的一些特性：

• 数据池塘能够快速并以灵活的方式摄取和消费数据。数据生产者只需要知道将数据推送到哪里，即本地存储、本地流或云端。存储层、模式、摄取频率和数据质量的选择留给数据生产者。

• 数据池塘应该与低成本存储一起工作。通常，物联网设备存储空间较小；因此，只有与边缘操作高度相关的数据才能在本地持久化。其余数据被推送到云端进行进一步处理或丢弃（如果数据噪声大）。

• 数据池塘支持读取时模式。数据池塘中可以有多个流支持多个模式。

• 数据池塘应支持静态和加密中的数据保护机制。实现基于角色的访问控制，允许审计数据从边缘流向云的数据轨迹也是有用的。

下图显示了如何将来自不同传感器/执行器的数据持久化并安全地在数据池塘中管理：

图 5.15 – 边缘数据池塘架构

在前面的数据流中涉及的实体包括以下内容：

• 数据生产者：这些是生成数据的实体。这些包括物理实体（如传感器、执行器或相关设备）或逻辑实体（如应用程序），并配置为在数据池塘中存储数据或将数据发布到云中。

• 数据池塘团队：通常，数据操作团队定义数据池塘（或湖泊）的数据访问机制，而开发团队支持数据管理。

• 数据消费者：边缘和云应用程序使用授权机制从数据池塘（或湖泊）检索数据，以进一步迭代数据并满足业务需求。

下面的截图显示了数据池塘的组织实体：

图 5.16 – 数据池塘的组织实体

现在你已经了解了数据如何在数据池塘中存储，并由不同的实体进行管理或治理。接下来，让我们讨论不同类型的数据以及它们如何被集成。

数据集成概念

DII 通过不同的层发生，如下所示：

• 批量：此层聚合数据生产者生成的数据。目标是通过对多个来源或维度的数据进行整合来提高数据洞察的准确性。

• 速度：此层传输数据生产者生成数据。目标是允许以可接受的准确度进行近乎实时的数据分析。

• 服务：此层合并批量层和速度层的数据，以便下游消费者或商业用户能够获得全面和增量洞察业务。

下图是 DII 的说明图：

图 5.17 -- 数据集成与互操作性（DII）

如您所见，数据流中存在多个层次，通常在大数据世界中使用提取、转换和加载（ETL）方法或提取、加载和转换（ELT）方法来实现。ETL 方法包括从不同来源提取数据、实施数据质量和一致性标准、转换（或聚合）数据以符合标准格式，以及将数据加载（或交付）到下游应用。

ELT 过程是 ETL 的一种变体，具有类似的步骤。不同之处在于，提取的数据在转换之前加载。这在边缘工作负载中也很常见，因为本地网关可能没有足够的资源在本地进行转换；因此，它在进一步处理之前发布数据。

但这些数据集成模式如何在边缘使用呢？让我们接下来探索这个问题。

数据流模式

边缘的 ETL 流程将包括以下三个不同的步骤：

1. 从传感器/执行器等设备中提取数据

2. 数据转换以清理、过滤或重新结构化数据，以便进一步消费

3. 将数据加载到持久层，如数据池、数据湖或数据仓库以发布数据

对于 ELT 流程，步骤2和3将以相反的顺序进行。

智能家居的 ETL 场景

例如，在智能家居场景中，通常从不同的传感器/执行器中提取数据，然后进行数据转换，这可能包括格式更改、结构更改、语义转换或去重。此外，数据转换允许您过滤掉家庭中的任何噪声数据（想想哭闹的婴儿或嘈杂的宠物），从而减少将所有比特和字节发布到云中的网络费用。基于入侵警报或补充打印机墨盒等用例，数据转换可以批量或实时进行，通过在准备移动到加载步骤之前在临时区域物理存储结果或虚拟存储传输数据到内存中。

这些核心模式（ETL 或 ELT）随着时间的推移而演变，形成了不同的数据流架构，例如事件驱动、批量、lambda 和复杂事件处理（CEP）。我们将在下一节中解释每个模式。

事件驱动（或流式）

边缘应用在事件发生时，在一天中生成和处理数据通常以较小的数据集进行，这是非常常见的。近实时数据处理具有较低的延迟，可以是同步的也可以是异步的。

在异步数据流中，设备（如传感器）在继续处理之前不会等待接收系统确认更新。例如，在智能家居中，一个运动/占用传感器可以根据检测到的事件触发入侵通知，但继续监控而无需等待确认。

相比之下，在实时同步数据流中，源和目标之间不允许存在任何时间延迟或其他差异。例如，在一个智能家居中，如果发生火灾警报，它应该以确定性的方式通知紧急服务。

使用 AWS Greengrass，您可以设计同步和异步的数据通信。除此之外，在我们构建边缘的多面架构时，在边缘构建多进程或多线程的多语言解决方案以支持不同的低延迟用例是很常见的：

![图 5.18 – 边缘事件驱动架构

图 5.18 – 边缘事件驱动架构

微批处理（或聚合处理）

大多数企业执行频繁的批处理，以便为最终用户提供业务洞察。在这种模式下，数据移动将代表在特定时间点的全部数据集，例如在一段时间结束时（如一天、一周或一个月）连接家庭的能源计量读数，或者自上次发送以来值已更改的数据，例如 hvac 读数或触发的火灾警报。通常，批处理系统被设计为随着数据的增长而按比例扩展和增长。然而，由于缺乏动力，这在边缘是不可行的，如前所述。

因此，对于物联网用例，利用微批处理更为常见。在这里，数据是本地存储的，并且以更高的频率进行处理，例如每几秒、几分钟、几小时或几天（跨越几周或几个月）。这允许数据消费者从本地数据源以降低延迟和成本的方式收集见解，即使在断开互联网连接的情况下也是如此。AWS Greengrass 的 Stream Manager 功能允许您在边缘执行聚合处理。Stream Manager 带来了关于如何在边缘处理数据的增强功能，例如为多个通道定义带宽和数据优先级、超时行为以及直接导出到不同的 AWS 服务，如 Amazon S3、AWS IoT Analytics、AWS IoT SiteWise 和 Amazon Kinesis 数据流：

![图 5.19 – 边缘微批处理架构

图 5.19 – 边缘微批处理架构

Lambda 架构

Lambda 架构是一种结合了微批处理和流（近实时）数据处理的方法。它使综合数据可用于下游消费。例如，一个制冷单元、加湿器或制造厂上的任何关键设备都可以在它变得无法运行之前进行监控和修复。因此，对于连接的 HBS 网关解决方案，微批处理将允许您检测长期趋势或故障模式。这种能力反过来可以帮助您的车队运营商为最终消费者推荐预防性或预测性维护。这种工作流程通常被称为数据流分析流程的温暖或冷路径。

另一方面，流处理将允许车队操作员通过遥测数据获得近乎实时的洞察。这将使消费者能够在检测到任何盗窃时采取关键任务行动，例如锁定整个房屋并呼叫紧急服务。这也被称为 lambda 架构中的热点路径：

![图 5.20 – 边缘的 lambda 架构]

![img/B17595_05_020.jpg]

图 5.20 – 边缘的 lambda 架构

有趣的事实

Lambda 架构与 AWS Lambda 服务无关。这个术语是由 Nathan Marz 提出的，他在 BackType 和 Twitter 等公司从事大数据相关技术工作。这是一个用于描述可扩展和容错的数据处理的设计模式。

边缘的数据流反模式

到目前为止，我们已经了解了边缘上常见的数据处理模式。让我们也讨论一些反模式。

复杂事件处理（CEP）

事件是从摄入的数据中识别复杂情况的数据模式，例如家庭中的网络中断或建筑中的火灾警报。从几个传感器或设备中检测事件可能更容易；然而，要从不同的来源获得对复杂事件的可见性，并能够捕获状态或触发条件逻辑以快速识别和解决问题，则需要特殊处理。

正是 CEP 模式发挥作用的地方。CEP 可能资源密集，需要扩展到所有大小的数据并成比例增长。因此，它仍然不是边缘上非常常见的模式。在云上，如 AWS IoT 事件或 AWS EventBridge 之类的托管服务可以使您更容易地对来自您的物联网设备生成数据进行 CEP。

批处理

传统上，在批处理中，数据以聚合的形式作为块或文件移动，要么是来自消费者的临时请求，要么是自动的定期计划。数据将是从某个时间点的一个完整集合（称为快照）或一个变化集合（增量）。批处理需要不断扩展底层基础设施以促进数据增长和处理需求。因此，这是一个更适合大数据或云上数据仓库解决方案的模式。话虽如此，对于边缘用例，你仍然可以利用前面解释过的微批处理模式来聚合在资源受限环境中可行的大量数据。

复制

在云上，维护不同位置的重复数据集副本是一种常见做法，以提高业务连续性、改善最终用户体验或增强数据弹性。然而，在边缘的背景下，数据复制可能很昂贵，因为你可能需要冗余部署。例如，使用连接的 HBS 中心解决方案，如果网关需要支持用于复制的冗余存储，这将增加硬件的物料清单（BOM）成本，你可能会在市场上失去竞争优势。

归档

不常使用或未积极使用的数据可以迁移到对组织更具成本效益的替代数据存储解决方案。类似于复制，对于在边缘本地存档数据，需要额外部署硬件资源。这增加了设备的 物料清单 （BOM） 成本，并导致额外的运营开销。因此，通常将数据湖中的转换数据存档到云上的成本效益存储服务，如 Amazon Glacier。此后，这些数据可用于本地操作、数据恢复或合规性需求。

通过实验室进行实践方法

在本节中，您将学习如何使用不同的 AWS 服务在边缘构建 lambda 架构。以下图表显示了 lambda 架构：

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/intl-wkld-eg/img/B17595_05_021.jpg)

图 5.21 – 实验室架构

上述工作流程使用以下服务。在本章中，您将完成 步骤 1–6 （如图 5.21 所示）。这包括设计并部署边缘组件、本地处理和转换数据，以及将数据推送到不同的云服务：

\

](https://github.com/OpenDocCN/freelearn-ml-zh/raw/master/docs/intl-wkld-eg/img/B17595_05_022.jpg)

图 5.22 – 实践实验室组件

在本实践部分，您的目标将包括以下内容：

1. 构建云资源（即 Amazon Kinesis 数据流、Amazon S3 存储桶和 DynamoDB 表）。

2. 在 Raspberry Pi 上本地构建和部署边缘组件（即工件和配方）。

3. 验证数据是否从边缘流式传输到云（AWS IoT Core）。

构建云资源

从 chapter5/cfn 文件夹部署 CloudFormation 模板以创建云资源，例如 Amazon S3 存储桶、Kinesis 数据流和 DynamoDB 表。在后续部分需要时，您需要从已部署堆栈的 资源 部分替换这些相应的名称。

构建边缘组件

现在，让我们跳转到我们的设备来构建和部署所需的边缘组件：

1. 从 Raspberry Pi 设备的终端导航到以下工作目录：

   cd hbshub/artifacts
   

2. 使用您选择的编辑器（如 nano、vi 或 emac）打开 Python 脚本：

   DummySensor class that will be referenced by the Publisher component in the next step:
   
   

   def read_value(self):

   message = {}

   device_list = ['hvac', 'refrigerator', 'washingmachine']

   device_name = random.choice(device_list)

   if device_name == 'hvac' :

   message['device_id'] = "1"

   message['timestamp'] = float("%.4f" % (time()))

   message['device_name'] = device_name

   message['temperature'] = round(random.uniform(10.0, 99.0), 2)

   message['humidity'] = round(random.uniform(10.0, 99.0), 2)

   elif device_name == 'washingmachine' :

   message['device_id'] = "2"

   message['timestamp'] = float("%.4f" % (time()))

   message['device_name'] = device_name

   message['duty_cycles'] = round(random.uniform(10.0, 99.0), 2)

   else :

   message['device_id'] = "3"

   message['timestamp'] = float("%.4f" % (time()))

   message['device_name'] = device_name

   message['vibration'] = round(random.uniform(100.0, 999.0), 2)

   return message

3. 现在，打开以下publisher脚本并导航到代码：

   hbs/localtopic topic every 10 seconds over ipc: 
   
   

   TIMEOUT = 10

   ipc_client = awsiot.greengrasscoreipc.connect()

   sensor = DummySensor()

   while True:

   message = sensor.read_value()

   message_json = json.dumps(message).encode('utf-8')

   request = PublishToTopicRequest()

   request.topic = args.pub_topic

   publish_message = PublishMessage()

   publish_message.json_message = JsonMessage()

   publish_message.json_message.message = message

   request.publish_message = publish_message

   operation = ipc_client.new_publish_to_topic()

   operation.activate(request)

   future = operation.get_response()

   future.result(TIMEOUT)

   print("publish")

   time.sleep(5)

4. 现在您已经审查了代码，请检查以下配方文件以审查Publisher组件所需的访问控制和依赖项：

   cd ~/hbshub/recipes
   nano com.hbs.hub.Publisher-1.0.0.yaml
   

5. 现在我们有了组件和配方，让我们创建一个本地部署：

   sudo /greengrass/v2/bin/greengrass-cli deployment create   --recipeDir ~/hbshub/recipes --artifactDir ~/hbshub/artifacts --merge "com.hbs.hub.Publisher=1.0.0"
   Local deployment submitted! Deployment Id: xxxxxxxxxxxxxx
   

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

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

   以下输出：

   Components currently running in Greengrass:
   Component Name: com.hbs.hub.Publisher
       Version: 1.0.0
       State: RUNNING
   

7. 现在Publisher组件已经启动并运行，让我们也审查Subscriber组件中的代码：

   Subscriber component subscribes to the hbs/localtopic topic over the ipc protocol and gets triggered by the published events from the publisher:
   
   

   def setup_subscription():

   request = SubscribeToTopicRequest()

   request.topic = args.sub_topic

   handler = StreamHandler()

   operation = ipc_client.new_subscribe_to_topic(handler)

   future = operation.activate(request)

   future.result(TIMEOUT)

   return operation

   
   Then, the subscriber pushes the messages over `mqtt` to the `hbs/cloudtopic` cloud topic on AWS IoT Core:
   
   

   def send_cloud(message_json):

   message_json_string = json.dumps(message_json)

   request = PublishToIoTCoreRequest()

   request.topic_name = args.pub_topic

   request.qos = QOS.AT_LEAST_ONCE

   request.payload = bytes(message_json_string,"utf-8")

   publish_message = PublishMessage()

   publish_message.json_message = JsonMessage()

   publish_message.json_message.message = bytes(message_json_string, "utf-8")

   request.publish_message = publish_message

   operation = ipc_client.new_publish_to_iot_core()

   operation.activate(request)

   logger.debug(message_json)

8. 现在您已经审查了代码，让我们检查以下配方文件以审查Subscriber组件所需的访问控制和依赖项：

   cd ~/hbshub/recipes
   nano com.hbs.hub.Subscriber-1.0.0.yaml
   

9. 现在我们有了组件和配方，让我们创建一个本地部署：

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

   以下输出：

   Local deployment submitted! Deployment Id: xxxxxxxxxxxxxx
   

10. 使用以下命令验证组件是否已成功部署（并正在运行）。现在您应该看到Publisher和Subscriber组件在本地运行：

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

    以下输出：

    Components currently running in Greengrass:
    Component Name: com.hbs.hub.Publisher
        Version: 1.0.0
        State: RUNNING
    Component Name: com.hbs.hub.Subscriber
        Version: 1.0.0
        State: RUNNING
    

11. 如您所观察到的，在先前的代码中，Subscriber组件不仅会订阅树莓派上的本地mqtt主题，它还会开始向 AWS IoT Core（在云中）发布数据。让我们从 AWS IoT 控制台中验证这一点：

    请导航到hbs/cloudtopic。 | 点击订阅。

    提示

    如果您已更改配方文件中的默认主题名称，请在订阅时使用该名称；否则，您将看不到传入的消息。

12. 现在你已经从边缘到云中有了近乎实时的数据流动，让我们通过集成 Stream Manager 来处理微批处理流程。此组件将订阅hbslocal/topic主题（与订阅者相同）。然而，它将使用 Stream Manager 功能将数据附加到本地数据流，而不是将其发布到云中。Stream Manager 是你在边缘构建 lambda 架构的关键功能。我们将把代码分解成不同的片段，以便你更好地理解这些概念。因此，让我们导航到工作目录：

    nano com.hbs.hub.Aggregator/1.0.0/hbs_aggregator.py
    

13. 首先，我们创建一个具有所需属性（如流名称、数据大小、存活时间、持久性、数据刷新、数据保留策略等）的本地流。流中的数据可以保留在本地以供进一步处理，或者可以使用导出定义参数将其导出到云中。在我们的案例中，我们将数据导出到 Kinesis，但你也可以使用类似的方法将数据导出到其他支持的服务，如 S3、IoT Analytics 等：

     iotclient.create_message_stream(
         MessageStreamDefinition(
           name=stream_name,  
           max_size=268435456,  
           stream_segment_size=16777216,  
           time_to_live_millis=None,
         strategy_on_full=StrategyOnFull.OverwriteOldestData,  
           persistence=Persistence.File,  
           flush_on_write=False,  
           export_definition=ExportDefinition(
                kinesis=
                  KinesisConfig(
                      identifier="KinesisExport",
                      kinesis_stream_name=kinesis_stream,
                      batch_size=1,
                      batch_interval_millis=60000,
                      priority=1
    

14. 现在流已定义，数据将通过append_message api附加：

    sequence_number = client.append_message(stream_name=stream_name, data= event.json_message.message)
    

    事实核查

    Stream Manager 允许你在边缘部署 lambda 架构，而无需部署和管理单独的轻量级数据库或流解决方案。因此，你可以减少此解决方案的操作开销或 BOM 成本。除此之外，作为数据湖的 Stream Manager，你可以使用无模式的动态方法在边缘持久化数据（记得 BASE 吗？）。最后，你可以使用 Stream Manager 与云数据服务（如 IoT Analytics、S3 和 Kinesis）之间的原生集成将数据发布到云中，而无需编写任何额外的代码。Stream Manager 对于具有较大有效负载的用例（如 blob、图像或视频，可以轻松通过 HTTPS 传输）也非常有益。

15. 现在你已经审查了代码，让我们为 Stream Manager 组件添加更新 Kinesis 流的必要权限：

    请导航到AWS IoT 控制台。 | 选择安全（在左侧面板上）。 | 选择角色别名并选择适当的选项。 | 点击编辑 IAM 角色。 | 附加策略。 | 选择Amazon Kinesis Full Access。 | 附加策略。

    请注意，不建议在生产工作负载中使用此类通用策略。这里使用它是为了帮助读者熟悉测试环境中的操作。

16. 在部署此组件之前，让我们快速检查配方文件：

    Configuration section in this recipe file, as it requires the Kinesis stream name to be updated. This can be retrieved from the resources section of the deployed CloudFormation stack. Also, note the dependencies on the Stream Manager component and the reference to sdk, which is required by the component at runtime: 
    
    

    组件配置：

    默认配置：

    子主题: "hbs/localtopic"

    kinesis_stream: "<用 cfn 替换的 kinesis 流>"

    访问控制：

    aws.greengrass.ipc.pubsub：

    com.hbs.hub.Aggregator:pubsub:1:

    策略描述: "允许访问订阅主题"

    操作：

    • aws.greengrass#SubscribeToTopic

    • aws.greengrass#PublishToTopic

    资源：

    • "*"

    组件依赖：

    aws.greengrass.StreamManager：

    版本要求："².0.0"

    清单：

    • 平台：

    os: all

    生命周期：

    安装：

    pip3 install awsiotsdk numpy -t .

    运行：|

    export PYTHONPATH=$PYTHONPATH:{artifacts:path}/stream_manager

    PYTHONPATH=$PWD python3 -u {artifacts:path}/hbs_aggregator.py --sub-topic="{configuration:/sub_topic}" --kinesis-stream="{configuration:/kinesis_stream}"

17. 接下来，在我们已经审查了工件和配方之后，让我们创建一个本地部署：

    sudo /greengrass/v2/bin/greengrass-cli deployment create   --recipeDir ~/hbshub/recipes --artifactDir ~/hbshub/artifacts --merge "com.hbs.hub.Aggregator=1.0.0"
    Local deployment submitted! Deployment Id: xxxxxxxxxxxxxx
    

18. 使用以下命令验证组件是否已成功部署（并且正在运行）。您应该观察到以下所有组件在本地运行：

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

    输出如下：

    Components currently running in Greengrass:
    Component Name: com.hbs.hub.Publisher
        Version: 1.0.0
        State: RUNNING
    Component Name: com.hbs.hub.Subscriber
        Version: 1.0.0
        State: RUNNING
    Component Name: com.hbs.hub.Aggregator
        Version: 1.0.0
        State: RUNNING
    

19. Aggregator组件将直接从本地流将数据发布到云上的 Kinesis 流。让我们导航到 AWS S3 控制台，检查传入的消息是否出现：

    前往Amazon Kinesis 控制台。| 选择Data Streams。| 选择流。| 前往监控选项卡。| 检查传入数据或获取记录等指标。

如果您在图表上看到一些数据点，这意味着数据已成功到达云。

注意

您始终可以在之前部署的 CloudFormation 堆栈的资源或输出部分中找到此实验所需的具体资源名称（例如前面的 Kinesis 流）。

验证从边缘到云的数据流

在本节中，您将执行一些最终验证，以确保从边缘组件流出的交易性和批量数据成功持久化在数据湖中：

1. 在上一节的*第 19 步中，您已经通过指标验证了 Kinesis 流正在接收数据。现在，让我们了解数据是如何从流层持久化到数据湖的：

   前往Amazon Kinesis 控制台。| 选择Delivery Streams。| 选择相应的交付流。| 点击配置选项卡。| 滚动到目标设置。| 点击 Amazon S3 目标下的 S3 存储桶。

   点击存储桶，深入到存储批量数据的子存储桶中，这些数据以压缩格式存储以帮助优化存储成本。

2. 作为最后一步，导航到Tables。然后，选择此实验的表。点击查看项目。

   您能看到时间序列数据吗？干得好。

   注意

   如果您无法完成前面的任何步骤，请参阅 GitHub 仓库中的故障排除部分或创建一个问题以获取更多说明。

恭喜！您已经走得很远了，学习如何使用不同的 AWS 边缘和云服务构建从边缘到云的 lambda 架构。现在，在我们结束这一章之前，让我们总结一些额外的主题。

参考附加主题

除了我们迄今为止所阅读的内容之外，还有一些我想提到的主题。无论何时您有时间，请查看它们，因为它们确实有很多好处，并且可以在网上找到。

时间序列数据库

在本章中，我们学习了如何利用 NoSQL（键值）数据存储，例如 Amazon DynamoDB，来持久化时间序列数据。另一种常见的持久化物联网数据的方式是使用时间序列数据库（TSDB），例如Amazon Timestream或Apache Cassandra。正如你所知，时间序列数据由来自不同来源（如传感器和执行器）的测量或事件组成，这些数据按时间索引。因此，建模时间序列数据库的基本原理与之前解释的 NoSQL 数据解决方案非常相似。所以，剩下显然的问题就是你如何选择 NoSQL 和 TSDB？看看以下考虑因素：

• 考虑数据汇总和数据精度要求：

  例如，让我看看月度或年度的能源利用率。这需要遍历一系列按时间范围索引的数据点，以计算过去 12 周内同一时期能源百分比的增加，按周汇总。这种查询可能会在分布式键值存储中变得昂贵。

• 考虑在一段时间后清除数据：

  例如，消费者真的关心从每小时到每月的整体能源利用率的精确指标吗？可能不是。因此，更有效的方法是存储短期内的精确数据，然后存储汇总和降采样数据以识别长期趋势。这种功能可以通过一些 NoSQL 数据库部分实现（例如 DynamoDB 项目过期功能）。然而，TSDB 更适合，因为它们还可以通过不同的方式提供降采样和汇总功能，例如使用物化视图。

非结构化数据

你可能好奇，本章的大部分讨论都与结构化和半结构化数据相关。我们根本未触及非结构化数据（如图像、音频和视频）。你说得对。考虑到物联网是物理世界和虚拟世界之间的桥梁，将会有大量非结构化数据需要处理，以用于不同的分析和机器学习用例。

例如，考虑一个场景，你客户家中安装的安全摄像头通过运动传感器检测到任何入侵或意外移动，并开始流式传输周围环境的视频。该视频流将通过你的智能中心或移动设备进行消费。因此，在这种情况下，安全摄像头正在流式传输未结构化的视频数据，作为一个可以存储（如果用户允许）在中心或云对象存储上的 P2P 流。在[第七章“边缘机器学习工作负载”中，你将学习从边缘摄取、存储和推断未结构化数据的技术。然而，我们不会深入探讨未结构化数据的建模技术，因为这主要属于数据科学，并且与物联网实践者的日常生活不太相关。

摘要

在本章中，你了解了与物联网边缘工作负载常见的数据建模技术、数据存储和数据集成模式。你学习了如何在 Greengrass 上构建、测试和部署边缘组件。此外，你实现了一个 lambda 架构来收集、处理和从边缘的不同来源流式传输数据。最后，你通过可视化物联网核心上的传入数据来验证了工作流程。

在下一章中，你将学习如何将所有这些数据在云上提供服务，以生成不同终端用户的有价值见解。

知识检查

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

1. 正误判断：数据建模仅适用于关系型数据库。

2. 执行数据建模练习的好处是什么？

3. ETL 架构对于边缘计算有什么相关性？（提示：考虑 lambda。）

4. 正误判断：Lambda 架构与 AWS Lambda 服务相同。

5. 你能想到至少一个在边缘进行数据处理的好处吗？

6. Greengrass 的哪个组件是必需的，以便设备能够正常运行？

7. 正误判断：管理实时处理的流仅适用于云。

8. 你可以实施什么策略来在边缘本地持久化数据，以延长其存储时间？

参考文献

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

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

• 亚马逊的 Dynamo：www.allthingsdistributed.com/2007/10/amazons_dynamo.html

• DynamoDB 的 NoSQL 设计：docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-general-nosql-design.html

• Lambda 架构：lambda-architecture.net/

• 在 AWS IoT Greengrass Core 上管理数据流: docs.aws.amazon.com/greengrass/v2/developerguide/manage-data-streams.html

• AWS 上的数据湖: aws.amazon.com/solutions/implementations/data-lake-solution/

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

边缘计算的价值主张是在数据源附近处理数据，并为不同用例中的不同类型的应用提供智能近实时响应。此外，边缘计算减少了需要传输到云中的数据量，从而节省了网络带宽成本。通常，高性能边缘应用程序需要本地计算、本地存储、网络、数据分析以及机器学习能力，以在低延迟下处理高保真数据。尽管 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 参考模型阶段（重绘自 https://www.the-modeling-agency.com/crisp-dm.pdf）]

![img/B17595_07_08.jpg]

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

此模型仍被视为一个基线，是一个成功进行数据挖掘项目的证明工具，因为其应用是中立的，并且适用于广泛的机器学习管道和工作负载。以先前的参考模型（图 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

附录 1 – 答案关键

本附录提供了本书各章节末尾问题集的答案关键。有些问题是开放式的，即它们没有明确的正确或错误答案。对于这些问题，我们提供了样本回答供您评估。

第一章

1. 任何模拟世界与数字世界之间的互操作都是物理-网络解决方案。边缘解决方案可能包括物理-网络接口，并且与网络拓扑中心最远的其他实体进行互操作。

2. 现在作为边缘解决方案的汽车内置无线通信，用于与远程服务交换消息，以记录运行时操作和接收软件更新。例如，特斯拉公司电动汽车从第一天起就被设计成智能边缘解决方案，除了机械车辆之外。

3. 不，电话最初是一种机械装置。尽管它将模拟音频转换为电脉冲，但这些数据最初并没有用计算机进行处理。我们第一章**，《机器学习驱动的数据驱动边缘简介》*中对物理-网络状态的定义是硬件和软件结合以产生结果。

4. 边缘解决方案至少包含一个传感器或执行器，用于与模拟世界交互，一定量的计算能力用于处理数据或指令，并在某一时刻与至少一种其他实体进行交互。

5. 在边缘交付智能工作负载所需的三个主要工具是用于编排边缘软件的运行时、机器学习模型和库，以及与其他实体通信的方法。

6. 在边缘运行机器学习模型的关键好处包括：处理数据时延迟降低、通过本地自主性提高可用性、减少传输到远程服务的成本节省，以及更多符合数据治理要求的支持。

7. 智能家居解决方案的主要角色是最终消费者（房主、居民或解决方案能力的受益者）。

8. 机器学习驱动的边缘解决方案在家中的另一个潜在用例是辅助生活。需要额外生命体征监测的人可以从本地机器学习的低延迟和数据治理中受益。

9. 工业解决方案的主要角色是工业设备的操作员和维护人员。

10. 工业解决方案的另一个用例是优化设备使用，以最大限度地减少磨损或最大化设备输出。工业设备通常需要自主运行，这意味着边缘机器学习解决方案可以在需要做出决策时独立于任何可能不可用的远程服务运行。

11. 不，通常物联网架构师负责协调机器学习模型在边缘的部署和运行，但不负责它们的整体准确性。物联网架构师与数据科学家和产品所有者合作，以帮助协调整体解决方案的有效性，这与其成功训练和测试的机器学习模型的成功密切相关。

第二章

1. 在边缘机器学习解决方案中，使用独立服务是组织代码的最佳实践。根据项目需求，单体应用有时可能是正确的选择。

2. 在边缘架构中解耦服务的优点是限制这些服务的行为范围。一个简单的单一用途服务更容易编写、维护和重用。

3. 将你的代码和依赖项与其他服务隔离的好处是确保你不会在服务之间有任何依赖冲突。

4. 评估有线和无线网络时，一个关键的权衡点是功耗。无线通信需要更多的能量来传输和接收消息。如果整体解决方案是无线的话，这通常意味着依赖于本地电池电源供电。

5. 同时使用传感器和执行器的智能家居设备是电动车库门。这些设备使用断路传感器来检测当电机执行器关闭门时，门路径上是否有任何物体。

6. 定义物联网 Greengrass 组件的资源有两种：配方和工件。

7. 错误 – 组件不需要工件。组件的所有逻辑都可以包含在配方生命周期脚本中。

8. 物联网 Greengrass 默认使用根系统用户来存储和执行组件，这样其他系统用户就不能与你的组件文件交互。这有助于确保你的代码在设备上运行时未被篡改。

9. 正确 – 组件可以本地部署到物联网 Greengrass 设备，也可以通过远程部署。在项目的原型阶段，本地部署更为常见。

10. 这里介绍三种不同的方法来更新Hello, world组件：启动一个新的部署并合并新的组件配置，覆盖消息键，更新配方中的默认配置并重新部署，以及更新脚本工件以使用新的字符串并重新部署。

第三章

1. 边缘解决方案中常见的三种网络拓扑是星型、总线型和树型。混合拓扑在图中的局部区域混合使用这些拓扑。

2. 错误 – 物联网 Greengrass 不在 OSI 模型的第 1 层运行，尽管一些自定义组件可能与之交互。

3. 使用发布/订阅模型交换消息的好处是解耦了解决方案中其他设备或组件的跨感知，将交互性从特定设备寻址方案转移到主题地址。

4. 是的——物联网 Greengrass 可以同时作为消息客户端（到云）和消息代理（到本地设备和组件）。

5. {"temperature": 70} 消息是结构化数据的例子，并且是可序列化的。

6. 来自摄像头的图像数据是未结构化数据的例子。它不可序列化，将以二进制数据的形式传输。

7. 网络路由器被入侵的最坏情况是中间人攻击，你的个人数据可能被窃取或篡改。因为流量看起来像正常处理一样，这可能意味着攻击未被检测到。

8. 验证两个网络设备之间真实性的缓解策略是公钥基础设施。

9. 在网关设备上保护 root 访问权限很重要，这样受保护的资源和代码就不会被篡改。

10. 在边缘解决方案的每个组件中使用容器的一个缺点是整体磁盘和内存空间增加。在每种情况下使用容器可能不符合你的设备要求。

11. 物联网 Greengrass 提供了一个内置服务，称为进程间通信（IPC），以允许组件交换消息。

12. 使传感器和执行器解决方案更安全的一种方法是将允许的 IPC 主题限制为仅用于解决方案的特定主题，而不是使用通配符。

13. 为了重新设计这个解决方案，添加一个将解释传感器结果的三组件，这个新组件将订阅传感器的发布主题，并将命令发布到新的主题。执行器组件随后需要更新以订阅这个新主题。

第四章

1. 静态资源是指在多个设备部署中不发生变化，并且在部署后也不发生变化的数据。例如，代码工件是静态资源，部署后不应更改，也不应在单个部署中按设备更改。动态资源在部署、安装或运行时获取，并且每次获取或本地更改后可能都不同。例如，智能家居设备的客户特定配置是动态资源，它将被获取并因设备而异。

2. 物联网 Greengrass 组件工件存储在Amazon Simple Storage Service（Amazon S3）中，以便在配方文件中进行参考。

3. 在组件中注册后，您不能修改存储在云中的工件。这将破坏计算摘要并标记给物联网 Greengrass，表明工件不安全使用。

4. 部署后不能覆盖工件文件，因为这些被认为是静态资源。预期这些工件保持不变，因为新的部署将替换任何更改。工件部署应该是幂等的。

5. 正确 – 设备可以属于多个物组，每个物组可以定义一个活动部署。

6. 一个设备用于接收来自多个物组的部署的用例是将通用组件应用于所有设备（例如日志记录或健康分析）以及特定组件应用于设备子集。

7. 正确 – 单个组件可以同时重置配置和合并新配置。

8. Moquette 组件部署一个本地 MQTT 代理以连接叶设备。

9. 设备阴影组件同步边缘和云之间的状态。

10. MQTT 桥组件在通信通道之间中继消息，例如 MQTT、IPC 和云。

11. 物联网传感器向 MQTT 主题发布消息。MQTT 桥将其中继到 IPC 主题。机器学习推理组件订阅 IPC 主题并分析数据以确定警告状态。机器学习推理组件将新的警告消息发布到 IPC 主题。一个可以访问设备音频输出通道的组件订阅警告消息并根据接收到的警告播放声音。

第五章

1. 错误 – 数据建模适用于所有类型的数据库。

2. 执行数据建模练习的好处是选择合适的存储解决方案，如数据库和模式。

3. ETL 架构对于边缘解决方案的相关性在于我们可以根据数据速度（Lambda 架构）定义多个数据处理路径。例如，一个边缘解决方案可以检查单个传感器测量值以检测警告峰值，同时将大量测量值转发到云以进行更便宜的存储。

4. 错误 – Lambda 架构是一个与亚马逊网络服务提供的同名服务不同的模式。

5. 在边缘进行数据处理的一个好处是在接近源头的嘈杂模拟数据上进行数据清洗和过滤步骤，在云上传输和存储数据之前，因为数据可能根本不会被使用。

6. Greengrass 运行所需的最小组件是核心。

7. 错误 – 管理实时处理的流适用于边缘和云。

8. 为了在边缘持久化数据更长时间，配置一个具有最便宜存储类型的数据池解决方案，例如本地磁盘。

第六章

1. 领域驱动设计对于边缘工作负载的两个好处如下：

   • 在多层系统中数据移动时保持高质量数据的高标准

   • 通过使交付解决方案的团队更容易理解和熟练掌握他们正在工作的上下文来最小化开发者的开销。

2. 错误 – 有界上下文和通用语言是领域驱动设计中不同的概念。

3. 与数据湖或数据仓库相比，拥有操作数据存储的好处是可以在操作数据存储中索引和查询特定事件和交易。如果所有交易数据都作为原始输入存储在数据湖中，则必须有一些额外的层来将此输入映射到它所代表的事件。

4. Lambda 设计模式将流式处理和批量工作流程结合在一起。

5. 数据湖策略可以用于在云中转换原始数据。

6. 错误 – 管理服务封装的 NoSQL 数据库提供读取和写入数据的 API。

7. 中介拓扑用于那些由中央协调器指导的一系列步骤的场景。代理拓扑用于数据生产者和消费者可以更自由地交换数据和响应事件的场景。

8. 使用无服务器函数处理物联网数据的一个好处是，只有在有物联网数据要处理时才会消耗计算资源。另一个好处是，根据物联网数据的激增规模来扩展计算资源。

9. 可以使用 商业智能（BI）工具，如 Amazon QuickSight、Microsoft Power BI 和 Tableau，将数据提供给最终消费者。

10. 错误 – JSON 不是大数据处理中最优化的数据格式。更好的例子是 Apache ORC 和 Parquet。

11. 在操作数据存储之上的 API 接口可能是一个无服务器的 HTTP API，它接受日期范围、设备 ID 和传感器的参数，然后对数据存储执行优化的查询以返回结果。

第七章

1. 错误 – 机器学习系统类型不止两种。

2. 四种机器学习系统是监督学习、无监督学习、半监督学习和强化学习。它们的效用取决于我们对输入数据的了解程度，以及我们是否在为特定结果进行训练或试图查看算法在噪声中可以发现什么。

3. 错误 – K-means 是一种聚类算法。

4. 机器学习项目生命周期的三个阶段是数据收集、数据准备和建模。

5. 两个用于训练机器学习模型的框架是 TensorFlow 和 MXNet。

6. AWS IoT Greengrass 是将训练好的模型从云端部署到边缘的工具。

7. 错误 – Greengrass 提供了准备好的图像分类管理组件。

8. 机器学习和物联网工作负载的一个反模式是设定一个期望，即一个人拥有数据准备、机器学习训练和将解决方案部署到边缘的专长。

第八章

1. 使用 DevOps 方法论来开发更具敏捷性的物联网工作负载是一种策略。

2. 错误 – DevOps 是一种方法论，首先设计新的工具来支持更快、更高品质的软件交付的好处。

3. 物联网工作负载中 DevOps 的两个挑战如下：

   • 边缘设备位于偏远地区，通常在我们的直接控制之外。

   • 我们不能像在云中的虚拟机上那样，丢弃因不良变更而损坏的边缘环境并重新开始。

4. AWS IoT Greengrass、CloudFormation 和 Terraform 等工具用于在边缘和云之间设计 DevOps 工作流程。

5. 正确 – 在边缘容器和 AWS Lambda 函数中运行代码提供了类似的好处（尽管每个都有独特的独特好处）。

6. 使用 MLOps 与 IoT 工作负载相结合的三个好处是生产力（加快训练和部署的迭代）、可靠性（使用 CI/CD 实践提高部署质量）和可审计性（实现输入和输出的端到端可见性）。

7. MLOps 工作流程的不同阶段是设计、模型开发和运营。

8. 正确 – MLOps 和相关工具链的生态系统较新，不如 DevOps 生态系统成熟。

9. AWS 提供了 SageMaker Edge Manager 服务，用于在边缘执行 MLOps。

第九章

1. 错误 – 设备注册是分配身份的过程，而设备激活是指它首次上线时。

2. 可以使用证书颁发机构与 Greengrass 一起为设备群配置证书。我可以使用自己的证书颁发机构，使用 AWS 的，或者使用第三方供应商的。

3. 设备可以通过实时过程进行配置，例如设备群配置和 AWS IoT Core 的即时配置。

4. 错误 – 除了指标和日志之外，还有进一步的监控技术，例如心跳监控。

5. 使用仪表板查看整个设备群的好处是能够在一个地方识别异常并对其采取行动，从而加快识别和解决问题的速度。

6. 针对远程故障排除的缓解策略是设置反向隧道会话，以便操作员可以在不牺牲防止入站连接安全性的情况下通过网络与设备交互。

7. AWS IoT Greengrass 提供了管理组件，如 LogManager、CloudWatch 和核心遥测发射器。

8. 错误 – 指标聚合可以在边缘设备上执行。不需要在云中完成。