边缘分析

边缘分析的定义很简单：它是在数据生成的物联网 (IoT) 设备上，直接进行数据收集、分析，并实时生成可操作的洞察。有人可能会认为这就是边缘计算；实际上，边缘分析更进一步，它在采取快速行动之前捕获更多数据并进行复杂分析。边缘计算类似于软件编程中的 if/then 结构；而边缘分析则采用 what if 的方法。

人工智能 (AI) 纯粹主义者会说，边缘分析涉及预测（推理），即应用经过训练的神经网络模型的知识，并利用这些知识来推断结果。

事实上，数据生成的速度已经超过了网络的容量。因此，我们必须智能地决定哪些数据需要分析，哪些数据需要发送到云端存储，以及最重要的，数据应该在哪里进行分析。虽然对这些问题最简单的回答是“视情况而定”，但在业务和技术层面都有相应的原因和建议。

决定答案的两个因素是：实时分析数据的重要性以及是否需要对这些数据进行额外分析。然后，还有存储空间需求（或不需要存储），以满足业务和司法管辖区的合规要求。

有人说，云环境并不适合实时分析。因此，将所有数据发送到云并不是解决办法，因为存储在云中的大部分数据从未被分析过。它最终会进入某个数据库或位桶中，然后就一直留在那里。

以远程摄像头拍摄视频为例，下表列出了边缘分析与服务器端分析的一些优缺点：

情境感知是指对环境要素和事件在时间或空间上的感知、对其意义的理解，以及对其未来状态的预测。这个定义来源于维基百科，其三个层次如下图所示。由于时间是情境感知中最重要的因素，因此可以认为时间也是分析的驱动力，尤其是边缘分析的驱动力

图 1：情境意识的三个级别。

边缘事件意味着需要实时分析摄像头所看到的内容或传感器所感知的数据，以便能够快速做出决策并采取即时行动。当两辆车处于碰撞轨道上时，没有时间将信息发送到云端或通知他人；可以预见保持当前路径的后果，并通过立即采取措施避免碰撞。当智能摄像头在汽车制造厂观察喷漆机器人时，如果发现车身部件上涂料的量不正确，就必须采取纠正措施。所有这些都只有在预先构建的模型部署在这些设备或系统上时才可能实现。

那么对于新的或此前未预见的情况呢？在施工区域，摄像头可以被训练用来检测未佩戴安全帽的人，并发出警报或通知现场主管。入口传感器可以检测人员是否佩戴工作证或携带武器等。在自然灾害（如疫情）期间，我们希望这些设备能够检测与健康相关的物品，如口罩、手套等。

现有模型必须得到增强，或者需要部署新的机器学习 (ML) 模型，以便这些边缘设备能够检测和分析此类情况并采取必要的行动。所采取的行动是可编程的，并取决于具体情况。可以触发警报、通知相关人员，或者禁止人员进入。这就是边缘分析的强大之处。

在设备达到某个阈值时发出警报相当简单，但真正的价值在于对多个数据变量进行实时可视化分析，并在数据流中找到预测意义。这可以帮助企业识别潜在的异常值或问题，以便深入调查并执行进一步分析。

边缘分析并不总是可视的，还有许多其他数据生成方面，例如冲击和振动分析、噪声检测、温度传感、压力表、流量计以及音频和音调分析。汽车的防撞系统是通过传感器而不是摄像头来实现的。虽然边缘分析应用程序需要在内存、处理能力或通信能力受限的边缘设备上运行，但这些设备会连接到边缘服务器/网关，而容器化应用程序会在该服务器上运行。

使用不同的协议将数据从设备传输到服务器或网关（通常称为第一英里）。以下是一些常见协议，但并不全面：

• HTTP/HTTPS：超文本传输协议/安全协议是无状态通信协议，是互联网的基础。
• MQTT：消息队列遥测传输，是一种轻量级发布/订阅机器对机器消息传递连接协议。
• RTSP：实时流协议，是用于视频传输的状态协议。
• HTTP 上的流：众多基于 HTTP 的自适应协议之一。
• WebRTC：标准、协议以及 JavaScript 和 HTML5 API 的组合，支持实时通信。
• Zigbee：一种无线技术，采用基于数据包的无线电协议，旨在用于工业环境中的低成本、电池供电的设备。

软件堆栈会因特定行业的用例而异，但总的来说，边缘分析的拓扑通常涉及产品组合。在远端边缘，会有视觉、听觉或感觉设备，其中一些能够运行容器化的推理模型。它们会将数据发送到推理服务器，该服务器可能运行 IBM Visual Insights 和 IBM Edge Application Manager。非可视化数据将使用 IBM Event Streams 或 Apache Kafka，被发送到事件主干网。而 IBM Watson 这样的软件产品可以训练/重新训练模型，再加上 IBM Cloud Pak for Data and AI 这样的中间件，则可在下一层聚合、清理和分析数据。

请记住上面所示的态势感知图；从感知到行动，边缘分析必须实时运行。该架构图展示了各个组件的运行情况，并以毫秒为单位显示了不同层之间的延迟时间：

图 2：边缘分析组件架构。

事实证明，人类的感知和认知反应非常敏捷，在认知层面上，我们的操作通常在毫秒级（有时甚至微秒级）。因此，机器和设备的响应与决策必须接近这一速度，而不能通过将数据发送到云端而花费 100 或 500 毫秒。

边缘分析的一个关键要求是通过降低响应延迟来改善计算体验。另一个重要方面是可扩展性。不断增加的传感器和网络设备数量将产生越来越多的数据。这会增加对中央数据分析资源的压力。边缘分析通过将处理和分析能力下沉到数据实际生成的位置，使组织能够横向扩展其处理和分析能力。

最后，边缘分析并不是对中央数据分析的替代方案。两者可以互相补充，共同提供数据洞察。前面我们提到过，在某些场景下，边缘分析是首选；而在另一些场景下，由于需要详细分析并可接受一定延迟，中央数据建模和分析则是更好的选择。边缘分析的主要目标是尽可能提供实时（或接近实时）的业务洞察。

IBM Cloud 架构中心提供了许多混合和多云参考架构，包括边缘计算参考架构。您还可以查看新发布的与边缘相关的汽车参考架构。

请务必查看本系列博客文章中有关边缘计算的所有文章和其他资源：

• 第 1 部分：“边缘架构”
• 第 2 部分：“边缘 DevOps
• 第 3 部分：“边缘 5G”
• 第 4 部分：“边缘的簇”
• 第 5 部分：“边缘自动化”
• 第 6 部分：“边缘网络切片”
• 第 7 部分：“边缘数据”
• 第 8 部分：“边缘架构决策”
• 第 9 部分：“边缘 GitOps”
• 第 10 部分：“边缘存储服务”
• 第 11 部分：“边缘云服务”
• 第 12 部分：“边缘数据主权”
• 第 13 部分：“边缘互联产品”
• 第 14 部分：“边缘基础模型”
• IBM Garage
• IBM Edge Application Manager
• Red Hat PoV
• 边缘计算和边缘分析
• Endsley, Micah; Jones, Debra (2016-04-19). Designing for Situation Awareness (Second ed.). CRC Press. p. 13. ISBN 978-1-4200-6358-5.
• 2020 年边缘分析：智能 IoT 应用程序指南
• 边缘分析 — 什么、为什么、何时、谁、哪里、如何？

感谢 David Booz 对文章的审查，以及 Andy Gibbs 为框图架构图提供的灵感。