典型的物联网架构典型的物联网系统架构包括部署在物理空间中并且通常包括一个或多个传感器的设备（或节点）; 在通信协议之间桥接并且位于相对靠近设备的集线器（或网关或边缘）; 存储和处理数据的集中式云环境，以及用户可以与之交互，探索数据和获取通知的前端设备。显然，有些设备直接与云环境通信，设备充当前端设备的场景，但从逻辑上讲，这种架构描述了设置中的常见角色。
机器学习和信号处理算法传感器会生成大量数据。以16Khz采样的高质量麦克风将产生256Kbps，如果以30帧/秒采样，则640x480灰度相机可产生大约100Mbps。要实时计算设备的位置和方向，我们需要每秒对加速度计进行100次采样。
典型的物联网系统可能包括数百甚至数千个设备，每个设备都有多个传感器，因此物联网和大数据是两个经常被一起提及的流行语并不奇怪。
为了从这个庞大的数据流中获得对用户的相关见解，我们通常需要使用机器学习和信号处理算法来处理数据。大多数时候，这些算法需要大量的计算资源，例如CPU，GPU和内存，它们既耗电又昂贵。可以将计算资源放置在系统的每个组件上：设备，集线器和云，然后可以处理通过或存储在那里的数据。因此，系统架构师决定如何在这些组件之间拆分/分配处理，以及如何根据权衡标准优化“成本”功能。
设计注意事项以下是影响有关如何跨设备，边缘和云分布机器学习算法的决策的常见示例。
- 物联网设备电池寿命：源自电池容量，不同功耗模式（活动，待机，关闭）之间的占空比以及传感器，CPU和通信接口的标称功耗。将原始数据发送到云将增加通信接口的功耗，在本地处理数据将增加本地CPU的功耗。
- 物联网设备成本：源自传感器，电池，CPU，通信接口和机械部件的成本。
- 物联网设备尺寸和重量。
- TCO（总拥有成本）：设备成本，云成本，网络成本，托管成本，安装成本，支持成本等。
- 实时需求：某些系统需要实时或近实时响应，并且不能容忍1-2秒延迟，这通常与将数据发送到云并等待响应有关。例如，门铃在两秒钟后无法振铃，这不是我们期望的用户体验。
- 加载通信渠道：实时向云端发送千兆位数据可以阻止所有其他流量，有时甚至是不可能的。
- 对通信链路服务质量的敏感性：算法的某些部分不能容忍通信链路中断。例如，即使没有到互联网的链接，警报系统也必须执行。
- 算法需求：有时算法只需要访问所有传感器的所有原始数据以达到最佳性能。这种情况的一个很好的例子是从多个视点对物体进行3D重建，其中来自多个（有时数百个）相机的实时馈送用于重建3D场景。
- 为多种平台和多种语言开发：数据科学家通常使用Python，R或Matlab开发他们的算法并使用浮点计算。在分发机器学习算法时，很可能每个环境都有不同的操作系统，不同的工具链和不同的软件语言（Python，Scala，Javascript，C，C ++，定点......）。拆分算法并将其从一个环境迁移到另一个环境是一个资源密集型过程，也是一个痛苦的过程，通常会影响算法的性能并引入错误和错误。
- 调试/故障排除需求：机器学习算法永远不会是静态的。数据科学家将不断面临边缘情况和新算法，他们的算法失败或需要改进其性能。为了研究问题并提高准确性，数据科学家需要尽可能多地访问数据，有时甚至需要访问原始数据。如果系统仅在设备级处理原始数据，并且原始数据不易被他们访问，那么他们将不得不做很多猜测来理解实际发生的事情。
- 灵活性，灵活性和扩展性：一旦我们决定了IoT设备的CPU和内存的大小并销售/部署它们，它们就是固定的，无法轻松扩展（我们总是可以替换物联网设备并升级其计算资源，但相关的成本和复杂性是巨大的）。另一方面，云资源以及某种程度上的边缘资源更加灵活。在云环境中，性能和内存可以在几分之一秒内上下缩放，这使数据科学家可以轻松地改进和升级那里的机器学习算法。
- 隐私，道德和安全问题：在某些情况下，传感器可能会收集我们希望限制访问的隐私数据或商业敏感数据。想象一下，基于摄像头的占用传感器放置在会议室中，在会议室中呈现敏感材料。从理论上讲，我们可以将视频源发送到云端并在那里处理数据，但这会使系统面临安全风险并可能引发道德问题。Alexa在本地检测到“Alexa”这个词，并没有将我们所有的对话都发送到云端。只有在检测到单词Alexa时，才会将以下请求流式传输到云端。如果企业需要处理大量敏感数据，那么边缘可能是云和设备之间的中间位置，因为它位于企业内部并且还带来了云的一些好处。
Alexa的例子我们已经提到了为什么亚马逊决定在设备上本地检测“Alexa”这个词而不是云端的原因。例如，他们可以分析设备上的所有语音，或者在云中运行所有语音和NLP处理。决定以这种方式拆分算法还有一些好处：
成本：通过完善和优化设备算法以准确检测一个单词，亚马逊成功地大幅降低了设备成本。另一方面，如果他们决定检测设备本身的所有可能的短语，他们将需要更强大和更昂贵的CPU。
TCO：通过在多个Alexa设备之间共享云计算资源，亚马逊设法降低整个解决方案的TCO。从统计上来说，假设每个设备每天只生成几分钟的录音，一个云NLP处理器可以处理数百个Alexa设备。
性能改进，支持更多技能并避免设备固件升级：每次用户向Alexa发出请求时，亚马逊都会将原始语音数据发送到他们的云（AWS），在那里进行处理，然后将其存储数月，可能是永久性的（I我在这里做一个假设...）。当亚马逊的数据科学家添加更多技能或更新他们的NLP算法时，他们拥有运行新软件对历史数据所需的一切，并自动验证他们没有降低性能（使用某种CI / CD管道）。因此，我们每隔两周就会看到Alexa中集成了新技能，这让他们自己很容易测试和部署软件更新，并设法避免将数百万台设备的远程固件升级复杂化，这并不奇怪。
设计师必须做出的权衡是：
- 实时：我们必须等待1-2秒才能听到回复。
- 对通信中断的敏感性：没有互联网连接，Alexa就没用了。
- 实时（或延迟）很重要
- 系统无法容忍连接问题。
- 数据隐私和安全性是一个问题。
- 由于带宽或功率限制，您希望减少设备与云之间的流量。
- 所有其他情况......
另一个重要且相关的教训是，如果您的物联网设备上有强大的CPU，并不总是意味着您必须使用它。尽管使用它很有吸引力，但远程配置管理和相关功耗的额外开销也会有其代价。
关于如何在整个系统中分发机器学习算法，没有一个公式或启发式方法。我们总是会有相互矛盾的约束，我们需要做出权衡，软件工程很快就会变得容易，相反，它会变得更加困难。
/2 
