到目前为止，在本书中，我们已经讨论了如何利用公共云的能力规划、设计和实施数据平台。然而，有许多情况下，单一的公共云是不够的，因为根据数据用例的特性，数据可能在其他位置产生、处理或存储，这可能是在本地、在多个超大规模云提供商处，或者在连接的智能设备（如智能手机或传感器）中。在这些情况下，需要解决一个新的挑战：如何提供对平台的全面视图，以便用户能够有效地混合和连接分布在不同地方的数据？在本章中，您将了解组织在处理这种分布式架构时可以采取的方法、技术和架构模式。

此外，还有其他情况需要在部分连接或断开连接的环境中使数据发挥作用。在本章中，您将学习如何利用一种称为边缘计算的新方法来处理这种情况，该方法可以将存储和计算资源的一部分移到云外，更靠近生成或使用数据的主体。

为什么选择多云？

作为数据领导者，您的组织希望您不断寻找提高业务结果并最小化技术成本的方法。在数据平台方面，您被期望通过采用市场上最佳的解决方案，或至少是最适合业务需求的解决方案，来管理整个数据生命周期。

单一云更简单且成本效益高

将整个软件架构集中在单一云提供商上有很多吸引人的原因：

简单在使用单一云提供商时，由此产生的技术堆栈更简单、更流畅。通常情况下，云内的服务是本地集成的。例如，在Google Cloud上，DWH工具（BigQuery）可以本地读取托管关系数据库（Cloud SQL）中的数据，无需数据移动。在AWS上的Redshift和Aurora之间以及Azure SQL Data Warehouse和Azure SQL Database之间（通过Azure Synapse Link）也有类似的零ETL集成。
学习曲线当您只有一个云时，员工在组织内部移动变得更容易。新员工入职变得更容易，员工使用组织其他部分构建的工具也更容易。
成本使用单一云提供商使从安全性到合同签订等方面都变得更简单。仅IT和法律服务上的成本节约就足以使单一云成为最佳选择。由于云提供商基于使用量提供折扣，通过将所有技术支出集中在一个提供商上，可以获得更大的折扣。

因此，我们建议小型和中型企业选择单一云提供商，并使用该超大规模云上提供的完全托管服务设计其架构。

多云是不可避免的

我们发现许多组织可能希望使用单一云，但最终采用了混合或多云环境。为什么呢？

收购即使您的组织最初使用单一云，您可能收购了一家在另一云上运行其整个技术堆栈的公司。现在，您是一个多云商店。这是最常见的情况，因为重新平台化的成本可能非常高，而且不值得对业务产生拖累。
最佳云在不同超大规模云提供商上可用的能力存在差异。如果您真的喜欢BigQuery、DynamoDB或Azure OpenAI，并认为它们是最优秀的，并且已经根据这些能力设计了应用程序，那么您将希望该应用程序在Google Cloud、AWS或Azure上运行，即使您的其他技术基础设施位于其他地方。最好/最熟悉的工具可用性的差异、只需信用卡即可开始阴影IT项目的能力以及不愿重写已经运作的部分，意味着许多组织逐渐演变成一种事实上的多云系统。
支持客户如果您正在构建在客户环境中运行的软件，您将需要支持所有主要云，因为您将有来自所有三个云的客户。这就是为什么，例如，SAP或Teradata在AWS、Azure和Google Cloud上都可用的原因。

面对这些不可避免的情况，重要的是要认识到没有理由成为障碍。不再需要与单一供应商绑定并围绕单一技术构建整个数据堆栈。云技术比传统的本地技术更加开放，企业现在可以创建依赖于来自多个供应商的多个互连环境的复杂架构，或完全使用开源软件（例如，有些公司正在一个云提供商上实现其主站点，而在另一个上实现灾难恢复站点，以减少对单一超大规模云提供商的依赖风险）。当然，这种自由度的层次会带来不同的成本（在技术和人员方面），并需要额外的治理和管理。但正如您将在后面看到的那样，这种方法由于它可以提供的优势而变得越来越受欢迎。

多云可能是战略性的

与大型企业的IT高管交流时，我们经常听到他们正在进行包括多云战略在内的数字化转型之旅。已经有一些大型组织采用了多云方法的例子：例如，为其iCloud服务利用所有三个主要的公共超大规模云提供商的苹果；或者Twitter，在最近被收购之前，将Google Cloud Platform用于其数据平台，但使用AWS提供其新闻推送；或者汇丰银行，将工作负载分配给Google Cloud和AWS，并将一些传统服务迁移到Azure。

正确使用时，多云使您能够通过在不同环境上部署最佳解决方案来为业务增加价值。实际上，这是一个全新的相互连接的服务生态系统的发展，成为公司所有解决方案的着陆区域。

采用多云环境的主要驱动因素是什么？最相关的是：

避免被锁定这是组织最担心的问题之一，因为他们不想受制于单一提供商的"暴政"。这不是技术问题（因为无论是云还是多云软件供应商，都无法逃避锁定），而更多是业务战略问题。
退出策略在失败的情况下离开提供商的能力（甚至可能是合同违约）。
利用您的管理层可能希望通过维持两个或更多云提供商来保留与超大规模云提供商的谈判筹码。
商业可能是您的组织使用Microsoft的企业软件，在Amazon上销售，并在Google上进行广告宣传。在一个公共云上留下足迹可能具有更大的商业迫切性。
法规要求也许某个提供商在某些地区或在该地区提供的服务集中没有适当的服务（例如，灾难恢复）。
可持续性公司希望选择最佳的可持续云，因为这对于满足未来环境、社会和企业治理战略的趋势至关重要。
创新采用没有成本、商业方面或功能方面障碍的解决方案。
知识提供一个无障碍的环境，让员工成功，并且人们可以利用他们在职业生涯中已经获得的技能，或者可以获得新的技能。
可移植性超大规模云的专有解决方案在运行位置方面往往受到限制，而在多个云上运行的开源解决方案通常也可以在本地和边缘上使用。

现在，您对为什么应该考虑为您的业务采用多云战略有了更好的理解，让我们看一些您可以使用的架构模式，以使其成为现实。

多云架构模式

多云架构可以使用不同的模式连接数据，使用户能够与进行分析所需的所有解决方案进行交互。在本节中，您将了解在使用这些范例时可能遇到的最常见模式。

一面玻璃

面临的最大挑战之一是开发一种解决方案，使得能够跨越由不同供应商管理的各种位置中的多个数据孤岛进行数据分析。为了实现这一目标，必须利用从根本上具有云不可知性的开放解决方案，并具备与多个和不同的数据源连接的能力，以在需要时混合数据。在这里主要有两种不同的方法可以利用：

基于 BI 工具的方法，如图9-1所示。
基于处理引擎的方法，如图9-2所示。

在第一种方法中，您将任务委托给BI工具（例如Looker或Power BI），以连接多个稀疏的数据源，检索相关信息，远程执行查询，并最终聚合结果。在第二种方法中，您相反地赋予处理引擎（例如PrestoSQL、BigQuery Omni）与不同环境中的各种数据源连接的能力。在这种情况下，可能有两种不同的方法：

利用跨越多个超大规模云提供商的分布式环境（例如BigQuery Omni），为最终用户提供与解决方案交互的一面玻璃。
利用连接器（例如Java数据库连接[JDBC]）查询和混合跨多个系统的数据。

一次编写，到处运行

获得云选择性的常见方法是使用可以在不同超大规模平台上原样运行的软件。有几种可能的方法来实现这种模式：

托管开源软件您可以使用Apache Airflow（一种开源工具）进行工作流编排，但通过使用Amazon Managed Workflows for Apache Airflow（MWAA）、Google Cloud上的Cloud Composer或Azure上的Azure Data Factory来避免管理的开销。这样，开发人员编写的代码在不同云之间是可移植的，但您仍然可以获得托管服务的好处，除了初始设置上的小差异。这种在不同超大规模云上使用不同托管服务的开源的模式在其他情况下也适用，包括Presto、Spark、PyTorch和TensorFlow等。
多云产品 Snowflake、Confluent Kafka和Databricks等工具作为主要超大规模云提供商上的完全托管服务可用。因此，可以将在AWS上运行的Snowflake工作负载（包括Snowflake SQL、Snowpark等）几乎原样运行在Azure或GCP上。请注意，不同超大规模云上的软件版本之间通常存在一些滞后。
多个运行程序 Google Cloud将用于编写Cloud Dataflow管道的软件API开源为Apache Beam。由于Apache Flink和Apache Spark现在为Apache Beam提供了运行时实现，因此您可以在托管Flink服务（例如Amazon Kinesis Data Analytics）上运行几乎没有更改的Apache Beam管道。
OSS抽象层与通过Azure OpenAI或Google Cloud Vertex AI提供的提示API调用LLM不同，您可以选择通过提供一致的接口访问LangChain来访问模型。这允许在不同LLM提供商之间保持软件工作负载的可移植性（尽管您将不得不验证所使用的提示是否可以互换使用）。
IaaS上的OSS 开源软件，如Dask、Modin、RAPIDS等，可以在从超大规模云提供商租用的虚拟机或集群上运行。除非您具有管理IaaS上软件的成本效益的规模，否则请尽量避免这种情况。

从本地扩展到云的突发模式

这是一种旨在支持拥有大型数据湖的组织的模式，他们希望将其影响扩展到云中，但尚未准备好进行完整的迁移。混合工作负载可以帮助解决他们的紧急问题，并作为额外的奖励，它们实际上还可以为未来的迁移铺平道路，显示采用和使用云技术的简便性。

开始采用云方法的最简单方式是突发本地Hadoop工作负载。对于那些在硬件和与Hadoop相关的堆栈上都有重大投资且容量受限的组织来说，突发是一种很好的选择。突发对于那些可以针对上传到blob存储服务（例如AWS S3、Google Cloud Storage、Azure Blob Storage）的数据运行多个作业的情况以及可以增量更新用于处理的数据的情况非常有效。这种解决方案的主要优势之一是相同的Spark或Hive作业可以在本地运行，并且可以在PaaS集群上运行（例如Amazon EMR、Google Cloud Dataproc、Azure HDInsight）。它与那些重视开源解决方案并希望避免供应商锁定的组织相一致。在这里重要的是，将数据导入数据湖的所有上游流程保持不变。所有这些显著降低了重新执行和重新测试现有流程的风险，并缩短了第一次部署的时间。

它实际上是如何工作的呢？这种方法使用Hadoop的分布式复制工具，也称为DistCp，将数据从您的本地HDFS移动到目标云blob存储中。一旦数据传输完成，就会创建一个PaaS集群，并可以在此集群上运行Spark作业。作业完成后，集群被销毁，作业结果被保存，如果您不计划运行其他作业，则blob存储桶也可以被销毁。突发工作负载的编排可以利用诸如Airflow之类的开源解决方案进行，这些解决方案既可以在本地工作也可以在云中工作（例如，通过Google Cloud Composer等以PaaS模式提供的解决方案），如图9-3。

该模式涵盖的其他用例包括：

组织测试版本升级的能力。在云中启动具有特定Spark版本的PaaS集群，并验证作业在本地数据的子集上是否正常运行，通常风险较小，成本较低。
实验和测试新技术（例如，直接在Spark作业中集成第三方服务）。

突发是我们在许多组织中经常看到的一种常见模式；让我们看看如何扩展它。

从本地到云的直通模式

这个模式可以看作是对前一个模式的补充。在前一个场景中，我们展示了如何使用Hadoop本地工具DistCp将本地数据湖的一部分移动到云blob存储桶中。一旦数据到位，组织可以利用其他处理引擎的工具（例如AWS Redshift、Google BigQuery、Azure Synapse），如图9-4所述，来处理数据，除了使用Hadoop本地工具。

通过利用云处理引擎，可以实现多种工作负载：

处理ORC、Parquet或Avro文件，包括利用联邦查询的Hive分区数据。
将本地发起的数据与云中的数据进行连接：一个很好的例子是将组织的本地事务数据与从营销工具（如Adobe或Google Analytics）加载的数据进行连接。
利用人工智能/机器学习工具基于本地数据构建模型。
在本地数据上批量运行预测。

采用这种方法时，需要注意一些关键点：

与完全迁移相比，无需更改任何向本地数据湖提供数据或使用本地数据湖的系统。
可以通过云处理引擎进行数据分析，除了使用Hadoop工具。
一旦数据传输到云存储桶，通过所选的处理引擎访问联邦数据无需额外的延迟或处理。
传输到云桶的相同数据可以由在本地运行的相同Spark作业处理。
集成平台即服务（iPaaS）解决方案，如Informatica、Talend、TIBCO或MuleSoft，可用于简化数据源集成并保持同步。

通过流式数据集成

组织之间存在数据库和应用程序、本地和云之间的障碍。处理过程通常是批处理的，因此不支持业务要求的快速运营决策。服务通常是自管理的、传统的，并且不是为云构建的，运行和维护成本高昂。这导致了昂贵、缓慢和分散的系统架构。

变更流是将数据更改（通常是数据库）实时从源移动到目标的过程。由变更数据捕获（CDC）技术驱动，变更流已经成为关键的数据架构构建块。全球公司要求CDC提供对不同数据源的复制功能，并为实时分析和业务运营提供实时流数据源。

那么什么是CDC呢？CDC是一种数据集成方法，使组织能够使用更少的系统资源更快地集成和分析数据。它是一种仅从数据源中提取最新更改（更新、插入或删除）的方法，通常是通过读取源保留用于自身内部事务完整性的更改日志。CDC是限制将新数据加载到操作性数据存储和数据仓库时对源的影响的一种高效机制，它通过支持数据变更的增量加载或实时流式传输到数据目标，消除了批量加载更新和不便的批处理窗口的需求。CDC可以在许多从数据变更中获取价值的用例中使用；最常见的用例按常见程度排序如下：

分析

通过集成CDC将数据加载到数据仓库，组织可以获得源数据的实时物化视图。组织可以使用这个持续更新的数据构建实时仪表板。这可以用于监控系统并获取有关业务状态的最新见解，如图9-5所述。在考虑数据新鲜度的业务影响和收集处理成本之间始终存在权衡。

数据库复制和同步场景

通过集成CDC将数据加载到SQL数据库，组织可以获得这些数据库中源数据的实时物化视图。组织可以在目标数据库中使用这个持续更新的数据，用于从源到目标的低停机时间数据库迁移，或用于多/混合云配置，其中源和目标位于不同的托管环境中，如图9-6所示。

事件驱动架构

基于现代微服务的架构依赖于从组织各部门不断更新的数据的中心数据集，以实现事件驱动。通过持续写入目的地，比如云blob存储，组织可以构建基于从这些目的地消费事件数据的事件驱动架构，如图9-7所述。

既然您对允许构建多云数据能力的可能模式有了更好的了解，让我们看看如何采用一种整体的多云策略。

采用多云战略

采用多云范式是战略的一部分，随后应将其转化为IT架构。

框架

为了将多云战略转化为多云IT架构，企业架构师利用一些常见的框架，如TOGAF（The Open Group Architecture Framework），来识别业务需求，定义支持流程所需的数据，以及定义应用程序如何处理这些数据（Architecture Development Model [ADM]过程），如图9-8所示。一旦完成，就可以确定为整合架构提供愿景的技术需求，而多云范式在这里为组织提供了高度的灵活性和自由度。

拥有广泛的服务选择无疑是一种机会，但重要的是要谨慎管理，以避免失去关注。识别能够根据您的战略和组织规则（特别是在合规性方面）帮助实现业务目标的服务至关重要。这在今天尤为重要，因为组织越来越多地（重新）内部化IT功能，以拥有和控制其软件和解决方案。

以金融服务行业为例。我们可以看到大量的投资用于将传统环境（主要基于主机解决方案）转变为现代环境，特别是在数据方面。实时分析支持着欺诈检测系统，先进的机器学习算法使得客户了解流程得以实现，反洗钱则需要处理海量数据的能力。如果仅依赖于单一提供商，获得这样一个特定解决方案/工作负载可能会很困难；因此，组织正在考虑采用多云方法，以获取最适合满足其需求的解决方案。

时间尺度

确定采用多云的时间尺度至关重要。具体来说：一些组织可能永远不会完全迁移到公共云，可能是因为它们属于金融或医疗行业，需要遵守关于数据存储方式的严格行业法规。对于它们而言，"数据驻留"非常重要。一些企业可能希望保护其遗留的本地工作负载，如SAP、Oracle或Informatica，但同时也希望利用公共云创新，比如完全托管的数据仓库。而其他大型企业则致力于用多年的时间进行与原生公共云的现代化，他们将不得不多年来采用多云架构作为最终状态。最后，有些组织可能还没有准备好迁移，但由于临时大批处理作业的挑战而难以满足业务SLA：他们希望利用公共云的可扩展容量，避免扩展本地基础设施的成本。

考虑到前述概念，您如何最终获得多云架构？让我们深入了解一下。

定义目标多云架构

您可以采用与之前处理单一（公共或私有）云提供商时相同的方法，但需要（1）针对每个涉及的供应商重复该方法，（2）在整体目标架构的上下文中执行。以下步骤将帮助您定义和采用目标云架构：

定义战略。在采用多云策略之前，您需要清楚了解您的目标。这些目标可能与业务、战略或技术相关。一旦了解了您的目标，您需要确定推动您采用多云策略的驱动因素。这些驱动因素可能是成本、功能缺失、开放性或法规合规性。例如，如果您采用多云策略是为了利用，您可能希望将最容易迁移的工作负载（例如Hadoop或Kafka）放在辅助云上。一旦明确了您的目标和驱动因素，您就可以继续进行多云之旅的下一步。
组建团队。总体而言，谈论云时所需的技能可能会非常庞大。身份、安全、网络、编码等只是云工程师应该能够掌握的一些主题。当涉及到多云架构时，这套技能因为即使从高层次上来看这些主题是可以互换的，但仍然需要深入和具体的知识，相关于工程师需要操作的平台。通常情况下，您通常需要建立一个云卓越中心，如"第1步：战略和规划"中所述，以便所有所需的技能都聚集在"一个帽子"下，成为整个项目的参考。
评估。为了确定候选目标解决方案，有必要更好地了解当前的操作情况。这一部分非常关键，因为它可以完全改变后续步骤的方法。您是要执行搬迁和迁移以保持组织现有解决方案，还是最好采用基于重新平台化/重新开发的方法，以从云提供商中获得最大的好处？通常，在这一步中有一些工具可以简化发现，并收集可以用于定义迁移计划的多个数据片段。向完全无服务器架构过渡并使用云原生工具通常是最佳解决方案，但在您手头资源短缺的情况下，这可能在短期内是不可行的。
设计架构。一旦业务目标明确，您有足够的知识将所有事务变为现实，就开始将要求转化为技术架构。定义组件如何相互通信，它们如何交换信息，以及它们如何共同执行定义的任务。架构师的目标是确定最佳解决方案，为最终用户提供更大的灵活性，确保最高级别的安全性和性能，同时注意整体成本。
准备迁移计划。一旦您收集到关于何处开始和何处想要前进的所有信息，您必须确定如何到达那里的方式：方式、时间表、所需的工作量和里程碑。了解不同活动/环境之间的关系以及可能的依赖关系，如果有的话，也很重要。
构建着陆区。一切都从着陆区的定义开始（正如您在第4章中所读到的那样），那里是工作负载将被部署的基础环境：身份和访问管理、网络连接、安全性、监控和成本管理只是需要在这个阶段考虑的一些元素。这个阶段对于准备接收根据前一步中定义的模型传输数据的目标环境至关重要。
迁移和转换。基于前面步骤中定义的所有内容，现在是时候将解决方案迁移到新的架构中了。在这个最后一步中，我们将应用新服务，或者完全重建应用程序，利用本地服务。

既然您对如何处理多云架构有了更好的了解，让我们深入了解另一个混合范例：边缘计算。

为什么要采用边缘计算？

边缘计算简而言之是一种架构模式，促使数据处理在数据产生的地方进行，即使它位于架构的边缘。

边缘计算是云计算范式的补充。尽管云计算使组织能够以集中的方式访问可无限扩展的计算和存储资源，边缘计算旨在解决不同的挑战。边缘计算帮助组织处理需要在原地处理数据（或延迟非常低）或在断开网络连接的情况下需要运行活动的工作负载。云计算更倾向于将业务带到全球范围，而边缘计算更专注于将功能带到决策点附近（例如，工厂、销售点等）。

带宽、延迟和断断续续的连接

来自工厂部署的机器的数据已经使制造公司能够分析其仪器的使用方式，并预测维护需求，限制潜在的损坏。电信公司已能够更好地了解其网络的拥塞情况并采取适当措施来缓解可能的问题。

问题在于你不能在云中进行这样的分析。为什么呢？

想象一下你是一家制造公司的首席信息官。首席执行官要求你找到一种方法，以加快目前通过手动进行的生产总装线上产品质量检查的速度。你的团队已经开发了一种基于机器学习的图像识别解决方案，通过比较总装线上的物品与完美产品，快速识别缺陷。你决定进行概念验证以展示解决方案的强大之处------它以自动方式识别98%的缺陷，现在你准备投入生产。你该如何做呢？最好的方式是如何进行？概念验证过程非常简单：

收集代表完美物品的图片。
收集代表有损坏/缺陷物品的图片。
为每张图片分配一个特定的标签（良好物品，有缺陷物品）。
开发和训练一个图像识别模型，以识别两组对象。
部署模型并通过API提供。
针对每个总装线上的物品执行以下步骤： a. 使用摄像机拍摄物品的照片。 b. 将照片作为API调用所需的输入有效负载上传到云环境。 c. 根据模型输出决定是否继续（物品良好）或停止流程（有缺陷物品）。

这种方法适用于测试目的，但有一些缺点使其难以在生产场景中部署：

带宽：系统需要拍摄高分辨率的照片才能发挥效果；需要上传到云的每张照片都是相当大的。考虑到每天需要检查每个总装线上的每个物品的数量，需要传输的数据量非常大，需要大量的带宽。
延迟：为了使其快速并可扩展，您需要在拍摄照片后的几毫秒内获得结果（物品良好与有缺陷物品）。即使使用高速连接，要使其足够快以跟上总装线也是困难的。
脱机：工厂通常位于偏远地方，很难保持稳定的网络连接。因此，即使脱机，这些解决方案也至关重要。

所有这些缺点都与单一故障点相关：与云环境的连接需求。但如果您能够使更多的智能接近物理设备/传感器并赋予它们在不可察觉的延迟或甚至脱机的情况下运行和智能决策的能力，会怎么样呢？边缘计算的目标正是实现这一点：将存储和计算资源的一部分从云中带到生成/使用数据的主体附近。

用例

有几种情况下，集中式云环境无法工作，边缘部署可能会有益。这不是详尽无遗的清单，但应该给您提供可能性的想法：

自动光学检查：利用基于深度学习模型的图像分析来识别与期望状态不符的某些内容，例如在总装线上验证项目质量的自动检查或加速车辆组件检查的解决方案，以发现其磨损程度。
提高安全性：利用摄像机和其他传感器监视特定位置（如工厂、工作场所或危险场所）的人员安全的用例。这可能包括使用热感摄像机在危险地方或接近危险机器的地方识别人员，或使用传感器检查某人是否摔倒并需要帮助。
农业：使用传感器监视植物的健康、生长和吸收的营养水平。实时分析收集的数据，以验证是否缺失或超量。
医疗保健：分析实时患者数据以提取更多见解，例如磁共振图像、超声图像、葡萄糖监测仪、健康工具和其他传感器。
内容交付网络（CDN）：为了改善浏览体验，通过互联网提供其数据的内容提供商（例如音乐、视频流、网页等）通常在边缘缓存信息，以减少检索时的延迟。实时算法可以极大提高缓存选择的效果。
沉浸式互动：实时、迅速的反馈对于改善VR头戴设备（例如增强现实、游戏等）提供的沉浸体验至关重要。
智能城市：旨在使城市更智能化并避免能源和资源浪费的应用，例如通过监控和控制单个灯具或一组灯具的传感器来实现的自动照明系统。
交通管理系统：利用摄像机和传感器，可以实时调整交通信号，或管理交通车道的开启和关闭，以避免拥堵。当自动驾驶汽车变得更加普遍时，这一案例的重要性将更加突出。

现在您对可能采用该模式的用例有了了解，让我们现在关注您可能获得的好处。

好处

边缘计算的作用是扩展集中式基础设施，并将更多计算能力带到架构边界附近。这使连接（或断开连接）的设备能够执行需要极低延迟和本地计算能力的任务（例如，机器学习推断）。这种模式解决了一些基础设施挑战，如带宽限制和网络拥塞。其他好处包括以下几点：

可靠性 大多数物联网（IoT）架构包含在不完全连接的环境中的元素，例如您的办公室或家庭。有一些相当常见的情况，实际上是无法在规定的低延迟的情况下保持与世界的持续可靠连接。想象一下农村工业站点，电信公司没有投资于高速有线连接，或者位于海中的风力涡轮机，利用老式的连接方式（2G/3G），或者自动驾驶汽车需要微秒级的延迟来做出决策（如果您的汽车必须刹车以避免事故，您不希望等待来自云的响应）。所有这些用例为了有效运作，需要能够在本地存储和处理数据的设备，并能够处理暂时的连接中断而不对其功能产生影响。

法律/合规性 在某些行业（例如金融服务和保险）中，某些国家有关存储、处理和暴露数据的规定非常严格（想想GDPR法规）。在本地转换和使用数据，并可能将修改后的数据发送回云端（例如，去标识化、加密等），将增加组织采用现代架构并仍保持合规性的能力。

安全性 数据外泄、分布式拒绝服务（DDoS）攻击防范和数据保护是边缘计算可以显著降低风险的一些场景，因为设备可以完全脱机工作，甚至可以被强制通过强化的网关与外部世界连接，该网关可以实施额外的数据保护层，如临时加密。

现在让我们将注意力转向处理边缘计算范式时可能面临的挑战。

挑战

除了这种新范式可能为组织带来的好处之外，还存在一些您可能需要解决的缺点，例如：

计算和存储能力的限制 部署在边缘的设备通常配备执行定义良好的操作的有限硬件（例如，收集温度数据的传感器等）。因此，这些设备往往是超专业化的，不适合于通用性任务。即使设备能够执行一些通用任务，比如在本地运行ML模型，安装的设备版本可能没有必要的功能。

设备管理/远程控制 正如我们之前所概述的，由于连接性或严格的访问政策，云与这些设备之间的连接可能会很棘手。您可能需要物理访问每个设备以检查状态，并最终应用可能需要的更新/补丁。如果某些位置条件恶劣或设备部署在难以访问的位置，则这可能不是一项简单的任务。

备份和恢复 由于这些设备大多数时间都处于脱机状态，您可能需要实施额外的本地物理基础设施（例如，智能网关加上网络区域存储）来进行备份和恢复，这将提高总体成本。

如果这些挑战中的任何一个适用于您的用例，您将需要评估它们是否构成阻碍，或者是否存在有效的解决方案来缓解这些问题。

边缘计算架构模式

与云计算一样，在定义边缘计算架构时，有一个清晰的策略是很重要的：可能存在所有设备由中央进行管理的情况（可能是由云应用程序管理），而也可能存在节点完全断开连接或只与本地网络部分连接的情况（以相互通信或与本地网关通信）。

总体而言，有两种类型的边缘计算架构：一种是设备智能的情况，另一种是在边缘添加了智能网关的情况。无论是智能设备还是智能网关，ML激活的工作原理都类似。让我们看看这两种模式。

智能设备

智能设备是实施边缘计算架构的一种直截了当（尽管昂贵）的方式。在我们的示例场景中，用于生产必须经过质量检查的物品的机器将都需要具有执行能够识别图片中缺陷的ML算法的硬件。进行逻辑处理的设备可以简单地称为"节点"，它们的硬件根据它们需要解决的用例而变化很大：它们可以配备通用CPU或专用硬件来执行特定任务。

具有可以直接执行复杂逻辑的非平凡硬件的智能设备（例如，Raspberry Pi、Coral传感器等），如图9-9所示，提供了很高的灵活性，但需要大量的管理工作（例如，软件更新、安全补丁等）和更高的硬件成本。

智能网关

通过有线或无线连接到智能网关的"哑"设备/传感器，智能网关可以代表它们执行逻辑，如图9-10所示，是处理同一位置（例如，工厂内）大量传感器的首选方法，因为它可以减少管理工作（一个智能设备而不是n个）及相关成本。然而，这引入了架构中的一些安全挑战，因为它可能成为单点故障（SPOF）。

ML激活

我们之前讨论过一个PoC场景，其中机器与云环境完全连接，不断地发送和接收数据，以决定如何处理流水线上的物品（接受或拒绝）。您已经看到，要使这种架构能够在生产环境中部署，唯一的方法就是扩展它，使设备能够在边缘直接执行该逻辑。

在边缘执行的设备代码可能因情况而异，但可以概括为一个ML模型，该模型通过处理一些输入（在这种情况下是图片）来获取所需的输出（我们示例中物品的最终决定）。在前面的章节中，当讨论现代数据云架构时，您已经了解到云的主要优势之一是其能够大规模收集和处理数据，使开发人员能够轻松实现最先进的ML算法。

让我们看看开发ML算法的过程的不同步骤（如图9-11所示），为此，让我们利用先前的示例：

数据收集一切都始于将用作流程输入的数据。在我们的场景中，我们需要开发一个能够从图片中识别物品的信息和特征的模型，因此重要的是能够访问大量正常物品和有缺陷物品的图片。（请注意，您可以创建尽您所愿的状态，但为简单起见，我们将仅考虑两个状态：正常物品和有通用缺陷的物品。）
数据分析需要对在先前步骤收集的数据进行精炼（例如，清理、转换、丰富）以供利用。在这个具体的示例中，我们需要验证所有拍摄的照片的质量（例如，焦点、对齐、噪声等），然后，对于每个图像，我们需要应用一个标签，指示图片中报告了什么，以生成两个分离的集合：正常物品和有缺陷的物品。
ML模型开发、训练和测试是时候开发算法了；有许多工具和技术可供使用（例如，scikit-learn、TensorFlow、PyTorch），甚至还有使生活更轻松的自动化解决方案（例如，在特征工程、模型选择和参数调整方面提供支持）。在我们的示例中，我们可以使用迁移学习技术来开发一个深度学习模型来识别图像。
ML模型部署该模型已准备好用于预测。它可以作为云中的API服务部署，也可以直接部署在边缘节点上。
反馈数据收集为了提高模型的质量，可以收集来自边缘的数据，然后重新开始整个过程，进行交互式过程，旨在使预测变得更好。在我们的案例中，边缘节点将通过批处理过程发送回（例如，分析过的图像以及预测结果）。

很明显，这些ML建模步骤对边缘架构提出了一定的要求：

数据收集需要具备存储收集的图像的能力，以便在足够长的时间内可以交换磁盘并将数据上传到云端，同时可以将磁盘移到具有更好连接性的位置。
数据分析可以在云中进行。
ML模型开发也可以在云中进行。然而，测试需要在云上模拟边缘环境的能力。
部署要求在开发ML模型时牢记边缘硬件的特征。将ML模型部署到边缘可能需要升级硬件组件，包括ML推理芯片，如Google Coral Edge TPU或NVIDIA Jetson Nano。
反馈数据收集需要实施一个应用程序来跟踪人工操作员覆盖ML算法建议的决策的情况。

现在您对边缘计算范式的理论有了更多了解，让我们看看如何采用它。

采用边缘计算

让我们看看采用这种范例可能如何为一个模范组织提供更大的可见性和更高的效率。

最初的背景

MagiCan是一家（虚构的）专门生产用于为全球最具标志性品牌提供服务的饮料罐的制造公司。该公司在世界各地拥有多个生产厂，每个工厂都有多台机器全天候工作。该公司的战略一直是在城市外地区建厂，而在一些地方，本地电信公司为该公司提供了基于老式无线技术（例如3G载波）的互联网连接。

该公司的核心价值之一是"高质量产品是必须的，不惜一切代价"，并且该组织一直投入大量资金以确保端到端生产周期的质量（例如，维护机械和对生产物品进行质量检查）。

MagiCan发现存在一些问题需要解决：多个站点的机器故障引起了生产的多次暂停，生产物品存在缺陷导致罚款，并且难以获得对其生产厂状态的一致性视图。因此，董事会决定启动一个新项目，以改善其收集和处理工厂数据的方式，以解决所有这些问题。

项目

该组织已经在多个工作负载（例如DWH、网站、SAP等）中利用云计算解决方案，并决定扩展其当前的体系结构，投资于直接连接到其机械设备的设备：目标不仅是直接从工厂收集数据以实时查看机器的工作方式，还允许用户对一些参数/组件（例如执行器、装配线等）进行操作，以修复问题、纠正不准确之处并改善生产过程的整体质量。

该组织在IoT项目专业化的第三方合作伙伴的帮助下，定义了一个三步旅程：

通过开发所需的体系结构来改善整体系统的可观察性，以从工厂收集数据并构建近实时监控系统。
开发用于调整执行器运行的自动化。
通过开发预测模型来优化机械设备的维护。

让我们深入探讨这三个步骤的旅程。

改善整体系统的可观察性

考虑到MagiCan在全球各地有几个位置分布，并且其中大多数位置与云世界没有可靠的连接，无法基于流式处理模式开发实时体系结构。该公司决定将问题分为两个不同的部分：

本地体系结构（在工厂级别），在该级别，所有机器都实时连接，所有信息立即被中央但本地应用程序可见。
利用云系统的集中体系结构，从工厂收集的信息每天多次以批处理模式收集。

目标是开发一种标准方法，以监控每个工厂的机器，并在工厂离线时仍使数据可用。中央云智能脑必须收集来自不同工厂的所有数据，然后使数据科学家能够研究这些数据，以便他们可以提取更多见解并利用云的强大功能，如图 9-12所示。

在每个工厂中，部署了带有传感器的设备，用于收集来自不同执行器的数据（例如速度、旋转、温度等）。这些设备与能够实时收集所有数据并通过自定义开发的可视化工具提供给用户的智能网关进行本地连接，该工具为用户提供了对工厂状态的一种连续快照。每隔x分钟，数据会被压缩并发送到云进行进一步分析，然后与来自其他工厂的数据一起进行汇总。如果网络存在问题，则批处理将被排队并在下一批次中发送数据。

发展自动化

一旦来自所有工厂的数据在云中可用，就是时候开始玩耍了！可用的信息量使团队能够对以下几个方面获得可见性，例如：

工人如何与机械设备进行交互
执行器配置与罐头缺陷之间的相关性
由于机械问题导致的平均闲置时间
在使用特定原材料时的理想机器配置考虑到设备和云之间通过智能网关的连接是双向的，可以发送反馈并使机器接收更新的信息以调整它们的操作方式。公司开发了一个近实时的过程，用于处理来自工厂的所有数据，了解与理想目标操作模式的差异，并发送更新的配置以立即调整执行器的行为。通过这个在中心管理的过程，可以根据机器所处的当前场景提供基于定制配置的能力。

优化维护

最后一步是解决一个相当难以处理的问题：机器的维护。在能够全面了解机器运行状况之前，维护是以两种不同的方式进行的：

计划维护通过定期干预
- 根据机器型号、历史记录以及其运行方式，按照明确定义的日历安排，定期检查机器。
非计划维护通过临时干预
- 由于某些事件（如部件损坏或由操作员错误引起的故障），故意检查机器。

考虑到维护操作可能会使机器暂停数小时甚至数天，有必要尽量减少非计划停机时间。利用来自工厂的数据（分析是在最初投入使用后的几个月后进行的，因为需要足够的历史数据量），开发了一个预测ML模型算法来计算机器故障的概率：当百分比超过一定阈值时，会向工厂经理发送警报，后者必须决定如何处理（即安排非计划维护操作或等待下一次计划维护）。

最终结果和下一步骤

整个端到端项目耗时超过一年，但最重要部分（即在各工厂实现统一视图的开发）的第一个版本相对较快（不到六个月）就完成了。借助这种分布式架构，公司能够提高在工厂和公司层面的可观察性，利用了一个共同的、标准化的、统一的过程。同时，它能够提高整个生产链的效率。MagiCan现在正在专注于一个全新的项目，旨在降低质检成本，尽可能自动化整个流程。与本节开头介绍的类似，该组织希望扩展已经建立的架构，实施一个在生产线上直接识别缺陷的流程：为实现这一目标，它将利用新的摄像设备，这些设备具有基于机器学习模型处理图像的能力。其目标是将当前执行质检的大部分人员重新分配到其他活动中。

总结

本章向您提供了处理混合和多云架构的高层次理解，当单一云提供商无法满足所有业务分析需求时。它向您介绍了在处理这种架构时需要考虑的各种因素，以及一些常见的实施模式。最后，它向您介绍了边缘计算以及如何使用它。主要要点如下：

在单一云提供商上 consol，是非常有吸引力的，因为它简化了整体架构，易于学习/采用，以及总体成本较低。
中小型企业应选择单一云提供商，并使用该超大规模提供商提供的全托管服务设计其架构。
由于收购或希望使用在其中一个云上可用的服务，多云架构可能变得不可避免。
当组织担心锁定、需要实施退出策略、有一些严格的监管要求，或想要提高工作负载的可移植性、创新、知识和可持续性时，必须考虑多云战略。
采用多云战略是一个需要明确定义所需战略并扩展团队技能的过程。
在处理多云架构时，有各种各样的架构模式可供利用，如开发单一玻璃窗口、在本地工作负载上爆炸Hadoop、使用Hadoop直通以在云中进行数据处理，以及使用变更流进行数据集成。
边缘计算是一种旨在将存储和计算资源的一部分从云中带到生成/使用数据的主体附近的范例。
带宽限制、网络拥塞、可靠性、法律合规性和安全性仅仅是边缘计算范例可以带来的一些好处。
边缘计算的主要挑战包括计算和存储能力的限制、管理/远程控制以及备份和还原。
利用边缘计算范例的主要用例包括自动光学检测、改进的安全性、农业、医疗保健、CDN、沉浸式交互、智能城市和交通管理系统。
在选择边缘架构时，智能设备比使用智能网关更简单但更昂贵。无论哪种情况，ML 激活都涉及添加诸如设备存储和 ML 推断芯片等功能。
在下一章中，您将了解在人工智能和机器学习中对架构和框架做出的高层次决策。

《Architecting Data and Machine Learning Platforms》第九章：通过混合和边缘扩展数据平台