基于Hadoop的客车超载监测系统设计与实现

石明翔 彭建辉 赖力 上官陈媛 郭磊

摘  要： 为了解决长途客车日益严重的超载问题，设计实现了基于Hadoop的客车超载监测系统。利用大数据处理、图像识别和人脸检测等技术对车载人员数量进行远程核查，从而避免超载现象的发生。文章介绍了系统的设计与架构，着重阐述了如何在Hadoop集群下解决“视频关键帧提取”、“Spark Streaming与Opencv结合实现人脸检测”、“MapFile实现小文件合并”等问题，最后通过实验对比证明了系统具有良好的效率及可扩展性。

关键词： Hadoop; Spark Streaming; 人脸检测; 分布式系统

中图分类号：TP391          文献标识码：A     文章编号：1006-8228（2020）02-50-04

Design and realization of intelligent passenger bus overload monitoring

system using Hadoop

Shi Mingxiang， Peng Jianhui， Lai Li， Shangguan Chenyuan， Guo Lei

（Beijing City University， Beijing 100075， China）

Abstract： An intelligent public-transport people flow monitoring system using Hadoop is designed and realized so that the increasingly serious bus overloading problem during holidays and festivals can be resolved. The system can make intelligent identification and remote inspection of persons loaded in an inter-city bus so that overloading can be prevented. In this paper， the system design and architecture are introduced， the ways of video key frame extraction， face detection combining Spark Streaming with OpenCV， and small file merger with MapFile， etc. were resolved under Hadoop environments are expounded. And through experimental comparison， the system is proved to have a good efficiency and expandability.

Key words： Hadoop; Spark Streaming; face detection; distributed system

0 引言

近年来，尽管中国的交通体系结构不断完善，但人们在中短途出行中主要还是依靠大客车。由于大部分公共大客车是私营运行，有些车主为了自身利益需求，经常超载行驶，这一现象严重威胁着乘客的生命安全。针对此问题，以往是交警部门投入大量人力物力在交通干道、枢纽等位置进行设点检查。但是在利益的驱动下，车辆运营商可能采用各种方式来躲避交警检查，例如：让超载乘客提前下车步行通过检查口，之后再上车等，因此，传统的检查方法并不能杜绝超载现象的发生[1]。

随着我国信息化建设的不断深入，一些学者尝试利用技术手段来解决超载问题，例如，徐斌等人提出在车门处安装红外传感器来统计乘客数量[2];杨劲松等人开发了一种客运汽车超载预警装置，利用车载摄像头配合图像识别模块来检测超载的发生[3]。但是这些办法或需要安装昂贵易损的红外热感设备，或系统服务器为单点架构，无法同时处理多车的海量视频数据。文本尝试将开源大数据技术与客车超载检测结合起来，利用分布式系统架构Hadoop[4]、分布式实时计算框架Spark Streaming[5]以及视频关键帧提取、人脸检测等算法，设计实现了基于Hadoop的客车超载监测系统，通过对平台中所有运行客车的海量视频进行实时检测和预警超载。

1 系统架构及工作原理

本系统主要依托于Hadoop集群，利用车载摄像头实时采集车内视频并利用GPS定位、图像比对分析、人脸检测及分布式计算等技术实现对客车是否存在超载现象进行监测和分析。

系统主要由车载终端层、应用服务层和数据存储层构成（图1）。其工作原理：客车行驶过程中，车载终端层的前置摄像头实时拍摄车内情况，并将视频通过4G网络上传到服务器中的应用服务层，该层的视频处理模块通过扩展后的视频处理库Ffmepg[6]将视频文件切割成一幅幅图片后存入数据存储层，接下来人脸检测模块使用分布式计算框架Spark Streaming和开源图片处理库OpenCV[7]对存储层中的图片进行人脸检测，如果在客车过道处连续检出多张人脸，则可判定该车超载。其工作流程如图2所示。

2 系统设计与实现

2.1 车载终端层

该层由车载摄像头和GPS定位模块组成，摄像头用于实时采集车辆内部视频信息，并通过DVR自带的4G传输模块定时将视频文件上传至应用服务层的特定目录;GPS定位模塊则负责将车辆位置实时发送至服务器，用于对车辆行驶状况进行监控。

2.2 应用服务层

该层为系统的核心功能层，主要由“车载视频预处理”、“人脸检测”、“GPS定位、监控”等模块构成。

2.2.1 车载视频预处理

视频是一种压缩数据文件，只有先将其转换为图片后才能进行人脸检测。车载视频预处理模块在运行时会启动处理线程，该线程会时刻监控存放视频的目录是否发生变化，如果发现有新视频上传，线程会调用视频处理库Ffmepg并结合关键帧提取算法（具体原理在下段描述）将视频文件切割成一幅幅图片，在进行二值化和灰度处理后，以“车牌号+日期+时间”的方式对图片重命名并上传到数据存储层中的HDFS中进行保存。

虽然FFmepg库可以将视频文件按照时间间隔分割成图片，但是视频是一种高度压缩的数据格式，在解压过程中得到视频帧的数据量将成倍增长，以一个大小约100M每秒24帧的480p视频为例，解压完后的图片总大小约为800M，数据量增大8倍。而由于行驶客车的车内场景基本处于静止状态，通过对车内视频解压后的图片进行对比发现，相邻图片之间的差异非常小，几乎不会影响人脸检测的结果，因此本文使用直方图平均法来扩展FFmepg库，通过计算两视频帧图像之间的距离来完成关键帧的提取，从而大大降低图片数据量。算法公式如下：

[d（Im，In）=i=1j（Hm（ε）-Hn（ε））2Hn（ε）]      ⑴

[H（ε）=-i=0j-1p（εi）logp（εi）]         ⑵

式⑵用于计算某一帧经过量化后图像信号的熵，其中[P（εi）]表示随机变量[ε]的概率密度函数。式⑴会在式⑵的基础上计算两个不同视频帧[Im]，[In]之间的距离，并将该值与经验阈值[η]进行比较：如果距离大于等于[η]，则将[In]作为关键帧提取出来;如果距离小于[η]，则丢弃图片[In]，继续抓取下一帧进行计算，直到将视频中所有的关键帧全部提取出来。

通过实验对比发现，在相同环境下经过扩展FFmepg库提取出的图片数量约为未扩展库提取出图片数量的1/8，极大地降低了人脸检测模块需要处理的数据量。

2.2.2 人脸检测

人脸检测模块是判断客车是否超载的核心功能，由于长途客车每人一座，若发生超载，人员会主要集中于过道，因此本模块对车内图片的过道处进行人脸检测，如果在连续时间段检测出多张人脸，则可判定该客车疑似超载，并将结果反馈至系统前台，管理员接到通知后可对该车图片或视频进行回溯查看，从而确定客车是否真实超载。

在具体实现时，本文通过调用开源图片处理库OpenCV和局部二值直方图算法（LBPH）完成了对图片过道区域的截取及人脸检测。同时由于业务场景需要对大量的车内图片进行实时处理，因此本文选择分布式实时计算框架Spark Streaming来完成图片的读取和OpenCV的调用，相比于另一个分布式计算框架MapReduce[8]，Spark Streaming作为Spark的扩展，支持在内存中对流式数据进行迭代计算，其处理磁盘存储数据的速度约是MapReduce的10倍，处理内存存储数据的速度可达MapReduce的百倍。在工作时Spark Streaming会将连续不断的数据流进行切片后放入多个批处理流程（Batches），再由Spark引擎进行并行处理，最后将计算结果汇总输出。实现流程如下。

⑴ 通过调用RDD API构建一个用于业务数据处理的有向无环图（静态DAG模板）。

⑵ 构建一个工作控制器（JobScheduler），将从HDFS中读取的图片流切割成数据片段（Data Stage）后再按照第1步的DAG模板创建出新的RDD。

⑶ 实现DAG实例以对数据片段进行处理。

基于以上原理，本文的人脸检测功能在实现时构建了“从HDFS读取图片”=>“调用Opencv进行人脸检测”=>“结果反馈”=>“超载预警”的Spark工作流（图3），在通过实验对比后发现系统的运行效率要远大于基于MapReduce框架构建的程序。

2.2.3 GPS定位、监控

该模块在运行时会启动车辆监控线程，将车载终端层的GPS定位信息与百度地图开放接口结合起来，对车辆的运行线路、是否超速等信息进行监控和预警。

2.3 数据存储层

由于系统在运行时产生的视频数据量巨大，因此本文选用Hadoop框架下的分布式文件系统HDFS作为数据存储层，该层主要用于存放应用服务层提取出来的视频关键帧，这些视频图片的特点是文件小（一般单张在5M左右）、数量大，但Hadoop在设计之初是为了处理大文件（几百M或几个G）而存在的，在处理大量小文件时反而会出现效率低下的问题，这是由于HDFS采用名称节点（NameNode）来存放文件的元数据，即系统中所有的文件和文件夹都会占用名称节点一定的内存空间，而且元数据的大小与文件大小没有必然联系，这就导致HDFS在存放海量小文件时会占用名称节点的大量内存空间[9]。再者，在使用Spark Streaming做分布式计算时，由于生成RDD阶段的任务处理对象通常是一个数据块，如果系统中含有大量小文件的话，势必会产生大量的batch任务，也会耗费大量的系统资源。

针对Hadoop并不适合处理海量小文件的特点，本文采用了MapFile技术将多个小文件合并成一个大文件再进行存储。MapFile是一种带索引的序列文件（SequenceFile），而SequenceFile又是Hadoop一种自带的二进制文件格式，它支持以“键/值对”的形式在HDFS上存储数据[10]。本文在设计时将各个客车的车牌号作为“键”，该车所对应的各张图片内容作为“值”，通过“键/值”合并将同一辆车的所有图片小文件压缩合并成一个大文件后再存储，这样做不但解决了小文件合并问题，而且合并后的大文件在作为Spark的DStream输入时，也可以被分割后进行单独處理，从而提高了HDFS的存储能力和Spark Streaming的处理效率。

3 性能测试

为了验证系统在Hadoop集群下的运行效率，本文采用以下实验环境：集群共有5个节点，其中1个Master节点，4个Slaver节点，每个节点的硬件配置为4核CPU、8G内存和512G硬盘。在实验中，集群分别启动2节点，3节点和4节点对300G的视频数据进行处理，并将结果与Spark Standalone（单节点伪分布式）模式下结果进行对比，以验证系统的加速比，实验结果如图4所示。

实验结果表明，在单节点伪分布式下系统所用时间为1882.5分钟，随着节点的增加，系统的加速比成线性增长，当节点达到4个时，系统的速度达到单节点的六倍。这证明集群的处理效率随着节点数目的增加而增加，系统具有良好的可扩展性。

4 结论

本文依托于Hadoop分布式集群，综合应用GPS定位、图像比对分析、人脸检测和分布式计算框架Spark等技术设计实现了《基于Hadoop的客车超载监测系统》，用于对行驶客车上的乘客数量进行监测和分析，以防止超载现象的发生。在系统实现过程中，本文依据Hadoop和Spark Streaming的特点重点解决了在分布式环境下实现“视频关键帧提取”、“人脸检测”、“HDFS小文件合并”等技术难题，并通过实验结果的对比分析，证明了系统无论是在运行效率还是可扩展性上都有着良好的表现。

参考文献（References）：

[1] 马丽娟.长途客车客流统计系统设计[D].西北工业大学，2007.

[2] 徐斌，陈晓冰.基于红外传感器的城市客车客流统计系统的研制[J].客车技术与研究，2010.

[3] 杨劲松，陈晓旺，汪亮.一种客运汽车超载预警装置[P].中国，CN202294307U，2012-07-4.

[4] The Hadoop DistributedFile System[EB/OL].http：//hadoop.apache.org/core/docs.

[5] Spark Streaming[EB/OL].http：//spark.apache.org/docs.

[6] FFmpeg[EB/OL]. https： //ffmpeg. org/.

[7] OpenCV. Open Source Computer Vision Library [EB/OL]. http： //opencv. org/.

[8] Apache Hadoop MapReduce[EB/OL].http：//hadoop.apache.org/docs/mapred_tutorial.html.

[9] 贾玉辰.Hadoop中海量小文件存取关键技术的设计与实现[D].南京邮电大学，2015.

[10] 蔡睿诚.基于HDFS的小文件处理与相关MapReduce计算模型性能的优化與改进[D].吉林大学，2012.