城市级公共安全视频图像智能分析平台系统架构设计实践

郑雪原

（南京擎天科技有限公司 江苏省南京市 211800）

1 城市公共安全

“城市公共安全是指国家各级人民政府为了保护社会公众的生命财产安全，保障城市公共设施的稳定运行，预防和控制各类重大灾害、事故和突发事件的发生，减少社会危害和经济损失，稳定社会和谐发展而提供的一种社会性公共服务”[1][2]。城市公共安全已经成为各级政府部门城市管理、社会治理、治安防控、打击犯罪，建设平安城市的重要关注点。近几年宽带和5G 通信技术大面积普及，城市级视频监控覆盖范围逐渐扩大，海量视频实现了汇聚存储。随着基于深度学习的AI 视频图像处理分析比对技术实用性的提高，在城市公共安全管理中以人像、车辆视频图像为分析目标的应用需求快速增加。为此需要建设一套针对城市级监控视频人像、车辆图像处理、检索比对和算法挖掘的智能分析平台。

2 城市级视频图像智能分析系统的需求

城市级视频图像智能分析系统通过建立统一的平台实时汇聚城市范围内的监控视频数据流，集中存储和管理，提供即时视频、图像查询服务；建立统一的视频、图像计算分析引擎，支持多家视频、图像处理分析厂商的引擎进行算法融合，全面提供人像、车辆等比对、识别、分析的服务能力；根据具体业务需要建立人像、车辆等图像相关业务应用。

通常城市级的视频图像智能分析系统可分为以下几个子系统：

（1）视频图像数据采集系统：通常由视频采集设备、编码器、存储设备、控制器和软件系统组成。目前主流监控视频厂家都会提供比较完善的视频数据采集系统的解决方案。

（2）视频图像数据汇聚存储系统：用于集中接入、管理和存储多个监控点的视频图像数据，根据业务需求和规则进行规范化存储管理。重点是要解决海量视频图像流的并发接入、实时存储和横向扩容问题，确保接入和存储业务的不间断性和可扩展性。

（3）视频处理与图像提取系统：用于处理视频文件，从中提取出完整图像，对图像进行加工，提供达到一定标准要求的高质量图像文件。该系统通常包括：

①视频处理组件：读取视频文件进行加工处理，例如视频剪辑、转码、压缩、降噪、滤镜等。

②图像提取组件：从视频文件中提取单独的完整图像进行处理，例如调整大小、剪切图像、调整颜色、增加滤镜等。

（4）图像比对与预警系统：实时检测和比对图像数据，对异常情况进行预警处理。该系统通常包括：

①图像比对组件：使用各种算法，例如人脸识别、车牌识别、动态目标检测等，比对图像数据，识别出异常情况，例如犯罪行为、交通事故等。

②预警系统组件：根据识别出的异常情况通过短信、邮件、语音等方式发送给相关人员。

（5）图像查询比对与分析计算服务系统：利用图像特征提取和计算服务实现图像查询、比对和分析。主要由三个主要组件构成：

①图像特征提取组件：负责对图像进行特征提取。常见的特征包括颜色、纹理、形状、边缘等。该组件使用各种算法，例如局部二值模式（LBP）、方向梯度直方图（HOG）、卷积神经网络（CNN）等。

②图像查询比对组件：负责对提取出的特征进行比对，返回与之相似的图像。该组件使用各种比对算法，例如余弦相似度、欧氏距离、汉明距离、深度卷积神经网路（DCNN）等。

③图像分析计算服务组件：负责对图像进行分析和计算。例如可以使用深度学习算法进行图像分割、分类、目标检测等任务。该组件使用云计算、分布式计算等计算服务以提高处理效率。

（6）基于视频图像的业务应用系统：依托上述各系统的能力，结合业务应用的需求，解决业务场景中的实际问题。

本文讨论的系统架构不涉及视频数据采集子系统，以解决视频图像数据汇聚存储、处理提取、比对预警、查询分析和业务应用为主要设计目标。

面向城市级视频数据的分析处理系统，对接入的数据量有一定要求。一般单日处理的视频数据不少于5000路，单日人像车辆车牌数据更新量不少于2000 万，静态人像、车辆和车牌特征库记录数不少于3 亿。

本文讨论的系统需要实现以下功能：

（1）建立人像、车辆和车牌资源库：实时汇聚不同来源的图像数据并进行标准化处理。建立静态库、动态库，以及各类业务主题库。其中静态库是人像、车辆和车牌的基准库，更新频率较低，总量相对固定。一般保存证件照或与证件照接近的标准人像图片、行驶证车辆图片或车牌图片。动态库是从视频流、视频文件中提取的人像、车辆和车牌图片等，以及相关的元数据，如时间、采集位置、人像或车辆特征、车辆号牌等。元数据为结构化数据，动态库中一般需要保存人像、车辆、车辆号牌的特征值（特征向量）等；

（2）针对历史数据和实时数据提供即时查询，实现1:1 和1:N 的比对；

（3）实现针对不同时间、地点的相同人像的归集归档处理；

（4）提供多种比对分析挖掘算法，简单算法支持即时查询，复杂算法支持以任务方式执行并反馈结果。

3 视频图像智能分析系统架构初步设计

为了满足上述功能需求和数据量，本系统的架构设计需要重点考虑以下问题：

（1）实时数据与历史数据的存储和处理分离；

（2）图像文件和元数据的存储分离；

（3）动态数据存在不能一次性汇聚完整、有错漏等情况，需要在一段时间内陆续汇聚补齐。针对这种情况可考虑汇聚补齐时间不超过n日，n 一般可设定为3-5。

初步设计如图1 所示的系统架构：

图1：系统架构图1

（1）实时获取的图像数据被写入Kafka 集群作为缓冲池供后台服务使用[3]。

（2）后台服务通过轮询从Kafka 中读取视频抓拍图片和元数据档案。

（3）后台实时数据接入服务将视频抓拍图片和元数据档案插入或更新入分布式数据库集群（MPPCluster）的热数据存储区。热数据存储区保存n日之内的数据。由于每日获取的实时数据存在错漏的情况，需要在后续的n日内补齐，n日之内这部分数据有较高的更新频率。n 一般不超过5，通常可以取3。

（4）分布式数据库集群中超过n日的数据纳入冷数据区保存，一般不需要更新，主要供查询分析使用。

（5）后台历史数据抽取服务从MPPCluster 中抽取超过n日的冷数据存入ES 集群(Elasticsearch Cluster)。ES 集群为存储的所有数据建立索引，提供快速数据查询服务。新数据存入ES 集群后，索引自动更新，确保每日的数据都有最新的索引可用。

（6）本系统的授权用户访问Web 应用服务提交查询分析命令。

（7）Web 应用服务解析查询分析命令，从MPPCluster 获取n日内的热数据，从ES 集群获取超过n日的冷数据。Web 应用服务对获取的热冷数据进行分析计算后将结果反馈给系统授权用户。

以上架构设计相对比较简单，能够应对基本的业务应用，但在数据量和并发访问量较大的情况下性能和稳定性难以满足要求。在实际应用中存在以下问题：

（1）n日内的热数据保存在MPPCluster 的单张数据表中，当Web 应用服务需要大量查询n日内数据时，由于此单张无分区数据表需要同时应对查询、更新、删除和新数据插入操作，性能受到较大影响。

（2）分析计算都是由Web 应用服务将数据从MPPCluster 和ES 集群中抽取到本机进行计算。由于Web 应用服务器本机的性能（包括算力、内存大小等）的影响，直接导致计算效能低，并发处理能力弱，用户体验差，系统整体性能低。

（3）所有查询分析计算全部由Web 应用服务单机承担，存在单点故障的风险，无法通过横向拓展提高性能和稳定性。

4 视频图像智能分析系统架构设计改进

为了解决该系统在实际使用中出现的问题，针对图1 设计中存在的缺陷和不足，在原系统架构设计基础上进行优化调整，形成图2 所示的新系统架构。

图2：系统架构图2

（1）与原系统架构相同，实时获取的图像数据被写入Kafka 集群作为缓冲池供后台服务使用。

（2）后台服务仍然通过轮询的方式从Kafka 中读取视频抓拍图片和元数据档案。

（3）后台实时数据插入服务仍然将n日内的数据写入MPPCluster 的热数据存储区。建立单表保存n日内的数据，该表按图像抓拍时间创建数据分区，并以图像数据ID 建立Hash 索引，保证数据均匀分布在多个节点。数据更新时利用索引进行定位和更新，在一定程度上提升了更新性能。对n日内数据的查询性能和并发性也有一定的保障。

（4）n日内的数据通过后台历史数据抽取服务定时全量同步到ES 集群，保证ES 集群总是有全量数据可使用。

（5）后台历史数据抽取服务将MPPCluster 中超过n日的数据抽取并存储到ES 集群，与定时同步到ES 集群的n日内数据合并成全量数据集。ES 集群建立并维护更新全量数据索引。

（6）本系统的授权用户访问Web 应用服务提交查询分析请求。Web 应用服务提交查询分析请求给服务管理器。根据性能压力的要求可以部署多台服务管理器。服务管理器的任务分配策略可以采用均匀分配；也可以采用按任务类型分配，根据查询分析请求的类型不同分发给不同服务管理器完成。

（7）服务管理器根据分配策略不同进行调度，将任务发送到大数据计算分析集群(Spark/Hive Cluster)。

（8）大数据计算分析集群根据需要从ES 集群中抽取数据到Hive 集群(HiveCluster)中进行分析计算，计算结果写入Hbase 集群(Hbase Cluster)。

（9）服务管理器直接从Hbase 集群中获取分析计算的结果返回给Web 应用服务，反馈给授权用户。

此架构中分布式数据库集群中超过n日的数据抽取到ES 集群后，分布式数据库集群中的数据可以通过删除分区的方式直接删除，大大减少了频繁插入、删除操作，避免数据索引的碎片化。ES 集群中的数据可以分成n日内和n日前两类。n日内的数据通过定时同步方式从分布式数据库同步到ES 集群。同步时间避开业务高峰时段，可选择凌晨用户使用系统负载较小的时段。n日前的数据通过创建临时表和直接修改表名的方式完成加载，保证对数据不需要进行实质性的修改和插入，不影响对数据的读操作，对于读写性能都有一定的保障。在新的架构中引入了大数据计算分析平台，使用Spark/Hive 实现根据业务和负载需要进行横向拓展，确保算力与数据和业务需求的匹配。服务管理器采用主从热备或多机并行的方式，通过策略控制计算任务分配，有效避免原架构中Web 应用服务单机承担计算任务的单点故障风险。后续可以通过扩展服务管理器能力方式实现为外部系统提供服务。

5 结论

上述架构在某市级视频图像智能分析系统中得到实践应用，满足全市每日近5000 路视频，2000 万人像数据的存储、查询和分析计算，ES 集群存储数据量不少于30 亿并持续增加。用户在新架构上获得较好的使用体验，实时查询分析结果响应时间不超过3 秒，大型分析计算任务也能在较短时间内完成。

某市级视频图像智能分析系统投入使用后获得了较好的使用效果，但也存在一些可以改进优化的方面：

（1）查询分析需要从ES 集群抽取数据到大数据计算分析集群。此操作消耗资源较多，耗时较长，导致一定的系统性能下降。可以考虑增加内存计算引擎，常用小批量数据直接从ES 集群加载到内存中计算，提升针对常用小批量数据的计算性能。

（2）目前服务管理器的调度算法比较简单，后续可在任务动态分配，负载均衡，故障迁移等方面优化。

（3）目前针对写入Kafka 集群的实时数据的处理比较简单，后续可考虑增加实时数据的计算引擎，如采用Flink 流处理框架提升实时数据的计算处理能力[4]，以实现实时预警等功能。