论文分享–Networked Cameras Are the New Big Data Clusters
-
ABSTRACT
深度学习复杂性和处于计算边缘的摄像头的日益增加已大幅提高了边缘数据分析的资源需求。相比传统互联网Web的应用程序，类似（计算、存储和网络）这类的资源需求并不选育数百万用户，而是数十亿美元为单位的传感器的连续活动。在此背景下，本文将摄像机抽象为一个集群试图解决这类的视频分析的挑战。我们设想了一种分析堆栈，它可以处理大规模网络摄像机的计算资源，从而实现高效的边缘视频分析。
-INTRODUCTION
目前智能摄像头大规模部署的增加了对于视频分析的边缘计算的可能性。但是也必须解决一个问题：在一个大型摄像头集合中怎样有效利用相机的“资源”处理大规模视频分析任务？
当前系统的缺陷
当处理多个摄像机流时，当前系统单独分析（并优化）每个视频流，仅适用源摄像机的本地资源（仅用于溢出的云/边缘服务器）。因此，随着更多的相机和更多的应用程序，资源需求呈比例地增长。
本文认为，将一组摄像机作为一个抽象的整体，类似于计算集群。本文设想将一组网络摄像机转换成一个摄像机集群，一个带有分析堆栈的计算集群，以提供有效的资源共享、统一的资源访问和一个统一的抽象，以在多个摄像机上执行分析应用。摄像机集群的抽象在性能和可编程性两个方面都带来了原则和好处。
性能益处
相机集群抽象是大型相机网络中充分利用不断增长的相机资源的一种系统方法。它为优化打开了新的思路。例如，由于不同的相机工作肥仔是异构的，相机集群可以将一个相机的工作负载分散到其他相机，以便更多的应用程序可以使用多个相机上的计算资源运行。此外，由于应用程序经常使用模型级联，因此并不需要为每一帧调用所有模型。因此，一个摄像机集群可以将DNN模型装载在特定的摄像机上，并将数据路由到这些位置，而不是笨拙的装载/卸载DNN模型。
可编程性益处
近年来，出现了低级加速器，高级视频分析管道和应用程序两种创新，每种都适合不同的用例。这些趋势是站不住脚的。今天，应用程序是直接在运行与单个设备（摄像机/服务器）上的低级库基础上编译的，因此跨应用程序采用有用的计算将设计大量的重复性工作。相比之下，通过一个通用的编程抽象，相机集群可以通过运行应用程序和系统级优化简化应用程序开发。相关研究
最近工作已经证明了相机集群的前景，例如附近范围下的相机信息共享和合并查询。但是都集中在单个相机或边缘云的层次上，而不是针对于一组网络相机。
与本文工作最接近的是femto cloud，它分享了将链接到无线接入点的边缘设备（如智能手机）组织成集群的高级思想。特别是，他通过最大限度地利用设备资源，在边缘设备上运行一般的云作业。然而，它关注的是需要预先分配资源的作业，而视频分析的工作负载可能是高度动态和内容相关的。更重要的是，视频分析有独特的机会，例如，视频可以重新调整规模，以平衡资源需求的准确性。本文的目标是召集人员来解决为设摄像机集群开发分析堆栈的挑战。我们首先提出了“摄像机集群”抽象，并讨论了构建摄像机集群分析堆栈的主要挑战。我们相信，在摄像机集群上的工作不仅与当前的视频分析及其问题相关，而且会对未来的边缘计算软件堆栈产生重大应用。如果成功的话，这样一个通用的系统将处境一个丰富的视频分析应用生态系统。
1.相机集群的实例
视频分析应用程序通常运行在一段或一组视频流中，大多程序依赖于云服务器执行复杂的视频分析。
但是当前趋势是视频分析应用程序需要利用不断增加的摄像机资源，从许多摄像机中提取实时信息。举个例子，跨摄像头身份识别跟踪搜索在视频源中查询身份，然后跟踪他们在一个较大的区域内遂时间在摄像头之间移动。这些应用在队规模部署时会产生实际影响。例如，大城市中安装了成千上网的交通摄像头来检测汽车、骑自行车的人和行人之间的杰出，这有助于先发制人地部署安全措施。
相机集群抽象的益处：- 在整个相机网络中实现不同应用程序之间的资源共享
- 灵活的数据访问视频流和中间数据
- 针对异构应用程序的优化调度
- 一个通用的编程接口，用于日益多样化的视频分析pipeline
1.3 什么是相机集群
- 直播视频不是文件。处理方式和类型不同
- 直播视频分析不是流处理
- 视觉推理不是大数据任务
- 相机集群不是边缘/云异构
- 相机集群的益处
- 节省计算资源
- 通道合并
例如，分析相同视频源的两个应用程序只需要执行一次视频解码操作或一次视觉特征提取。此外，通过缓存连续的实时查询结果(例如，拥塞监控)，可以使历史视频查询(例如，查找上周的峰值流量小时)变得非常高效。 - 模型位置
不同的应用程序有时使用相同的公共可用的视觉模型集，表明除了数据之外，还可以共享执行相同任务的应用程序间的模型。例如，预期繁琐地加载/卸载DNN模型，不如将模型放在特定的摄像机上，并将数据路由到这些位置。- 首先，加载模型比推理模型更慢
- 其次，许多视频分析管道是级联的，所以不是所有的模型都需要为每个帧调用
- 最后，相同的预加载DNN可以批量处理多个摄像机的帧，进一步节省计算成本。
- 通道合并
- 资源池
- 负载平衡
- 运行更复杂的模型
通过将相机上不断增长的资源集中在一起，集群可以运行更加复杂、精确的模型。一个可能的实现是将视频流拆分为帧组，并通过多个摄像机并行处理它们。
- 改善分析质量
- 通过相机分享信息
例如,找到最好的模型分析相机,你可以看看相机B也有类似的视频特征(例如,相似的对象类分布相机角度,或照明条件),如果我们知道哪些模型是准确的,这种模式可能产生高精度的 - 在线模型更新
当测试视频流与训练数据相似是，视觉模型更准确。因此，一些查询管道通过传输学习用本地捕获的图像更新视觉模型。现在可以通过云资源来更新模型，但这会带来额外通信造成延迟。一个有前途的替代方案是利用所有的相机资源来更新模型，而不是求助于云。
- 通过相机分享信息
- 隐藏底层复杂结构，简化开发
理想情况下，应用程序开发人员需要一个公共接口来访问视频流和计算/网络资源，而不必担心资源争用、带宽共享和容错等问题。不幸的是，今天的许多应用程序都是独立和整体地构建的，没有这样的公共接口，导致在不同的应用程序中应用有用的技术时出现大量的约束和重复。
3.相机集群架构
3.1 资源共享 - 问题1，摄像机集群可以由多个应用程序共享，应用程序可以服务于多用户。这些应用程序在时间尺度、精度要求核资源需求方面可能有所不同。
- 问题2，有更多的视频分析用户。例如，例如，十字路口的交通摄像头可能有三种用途:监控交通堵塞，发现违反交通信号灯的情况，以及识别特定的车辆
如今，应用程序是独立构建的，用户直接配置分析应该在何处运行，并可能无限期地保留资源。在应用程序之间共享资源的惟一选择是在单个摄像机或服务器级别。此方法对于实现3中所述的性能好处是低效的。相比之下，一个更有效的相机集群资源共享机制应该解决__四个挑战__- 异构调度
更好的调度算法应该探索不同应用程序之间的资源/精度权衡之间的内在异构性。这在边/云服务器上节省了大量资源，但是如何在连接松散且具有异构资源的大型分布式摄像机集群上实现类似的节省仍然不清楚。 - 共享网络资源
摄像头之间的网络连接可能是相机集群的一个限制因素，当我们在摄像头之间传输数据时，摄像头之间的网络负载也可能是动态的。因此，我们需要减少通信量。网络资源还必须在应用程序之间正确地共享。当前的解决方案是不够的，因为他们假设网络只被一个视频流使用。 - 工作负载波动
视频分析的资源需求可能非常不稳定。例如，一些视频分析管道仅对少数发生敏感事件的帧调用昂贵的模型。这造成了难以预测的资源需求的突然激增。而云调度算法依赖于具有确定性资源需求的任务。 - 虚拟化
我们需要将正在分析的摄像机源于分析发生的地方解耦。容器是实现这一目标的一种很有前途的方案。
3.2 数据访问和共享
- 异构调度
- 视频数据
API应该支持流视频（实时视频）和历史视频（存档视频），同时还需要保存影响视频分析的相关属性（视频色彩空间、帧率、量化参数等）。不幸的是，今天通过直接指定视频源访问视频以满足这些目标的接口是低效的。此外，相机集群的网络运营商如今经常将存档数据存储在云中，这迫使用户重写程序，以便在实时视频分析和历史视频分析之间切换。 - 中间数据
对于不同的应用程序共享它们的中间数据，数据访问API不仅应该表示原始视频流，还应该表示生成数据的视觉模型。
假设一个应用程序想要统计街道上公交车的数量，而另一个应用程序想要监视街上公交车的速度。当然，它们可以共享检测到的示例，但是这种分享是透明的，我们必须确保示例是由相同的检测模型发现的。一种选择是让存储系统记住如何重新计算每个中间数据。这与MapReduce系统知道如何在map任务丢失输出是重新运行该任务非常相似。 - 模型参考
实现模型局部性（将一个DNN模型加载到GPU内存并将数据路由到它），必须允许不同的应用程序访问相同的视觉模型和例程。一个方法是为每个模型创建一个独特的指纹，这样一个预加载的模型可以在另一个模型提供相同的ID下被其重用。然而， 这以为这任何违纪的变化都可能导致不同的指纹，可能太过严格，因为即使在相同的数据集上训练相同的DNN架构也可能产生略微不同的模型。另一种方法是在API中注入与视觉相关的语义。
3.3 编程框架和接口
来源：CSDN
作者：qq_26088325
链接：https://blog.csdn.net/qq_26088325/article/details/104530591