基于Hadoop的客車超載監(jiān)測系統(tǒng)設計與實現(xiàn)

石明翔 彭建輝 賴力 上官陳媛 郭磊

摘? 要： 為了解決長途客車日益嚴重的超載問題，設計實現(xiàn)了基于Hadoop的客車超載監(jiān)測系統(tǒng)。利用大數(shù)據(jù)處理、圖像識別和人臉檢測等技術對車載人員數(shù)量進行遠程核查，從而避免超載現(xiàn)象的發(fā)生。文章介紹了系統(tǒng)的設計與架構，著重闡述了如何在Hadoop集群下解決“視頻關鍵幀提取”、“Spark Streaming與Opencv結合實現(xiàn)人臉檢測”、“MapFile實現(xiàn)小文件合并”等問題，最后通過實驗對比證明了系統(tǒng)具有良好的效率及可擴展性。

關鍵詞： Hadoop; Spark Streaming; 人臉檢測; 分布式系統(tǒng)

中圖分類號：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 引言

近年來，盡管中國的交通體系結構不斷完善，但人們在中短途出行中主要還是依靠大客車。由于大部分公共大客車是私營運行，有些車主為了自身利益需求，經常超載行駛，這一現(xiàn)象嚴重威脅著乘客的生命安全。針對此問題，以往是交警部門投入大量人力物力在交通干道、樞紐等位置進行設點檢查。但是在利益的驅動下，車輛運營商可能采用各種方式來躲避交警檢查，例如：讓超載乘客提前下車步行通過檢查口，之后再上車等，因此，傳統(tǒng)的檢查方法并不能杜絕超載現(xiàn)象的發(fā)生[1]。

隨著我國信息化建設的不斷深入，一些學者嘗試利用技術手段來解決超載問題，例如，徐斌等人提出在車門處安裝紅外傳感器來統(tǒng)計乘客數(shù)量[2];楊勁松等人開發(fā)了一種客運汽車超載預警裝置，利用車載攝像頭配合圖像識別模塊來檢測超載的發(fā)生[3]。但是這些辦法或需要安裝昂貴易損的紅外熱感設備，或系統(tǒng)服務器為單點架構，無法同時處理多車的海量視頻數(shù)據(jù)。文本嘗試將開源大數(shù)據(jù)技術與客車超載檢測結合起來，利用分布式系統(tǒng)架構Hadoop[4]、分布式實時計算框架Spark Streaming[5]以及視頻關鍵幀提取、人臉檢測等算法，設計實現(xiàn)了基于Hadoop的客車超載監(jiān)測系統(tǒng)，通過對平臺中所有運行客車的海量視頻進行實時檢測和預警超載。

1 系統(tǒng)架構及工作原理

本系統(tǒng)主要依托于Hadoop集群，利用車載攝像頭實時采集車內視頻并利用GPS定位、圖像比對分析、人臉檢測及分布式計算等技術實現(xiàn)對客車是否存在超載現(xiàn)象進行監(jiān)測和分析。

系統(tǒng)主要由車載終端層、應用服務層和數(shù)據(jù)存儲層構成（圖1）。其工作原理：客車行駛過程中，車載終端層的前置攝像頭實時拍攝車內情況，并將視頻通過4G網絡上傳到服務器中的應用服務層，該層的視頻處理模塊通過擴展后的視頻處理庫Ffmepg[6]將視頻文件切割成一幅幅圖片后存入數(shù)據(jù)存儲層，接下來人臉檢測模塊使用分布式計算框架Spark Streaming和開源圖片處理庫OpenCV[7]對存儲層中的圖片進行人臉檢測，如果在客車過道處連續(xù)檢出多張人臉，則可判定該車超載。其工作流程如圖2所示。

2 系統(tǒng)設計與實現(xiàn)

2.1 車載終端層

該層由車載攝像頭和GPS定位模塊組成，攝像頭用于實時采集車輛內部視頻信息，并通過DVR自帶的4G傳輸模塊定時將視頻文件上傳至應用服務層的特定目錄;GPS定位模塊則負責將車輛位置實時發(fā)送至服務器，用于對車輛行駛狀況進行監(jiān)控。

2.2 應用服務層

該層為系統(tǒng)的核心功能層，主要由“車載視頻預處理”、“人臉檢測”、“GPS定位、監(jiān)控”等模塊構成。

2.2.1 車載視頻預處理

視頻是一種壓縮數(shù)據(jù)文件，只有先將其轉換為圖片后才能進行人臉檢測。車載視頻預處理模塊在運行時會啟動處理線程，該線程會時刻監(jiān)控存放視頻的目錄是否發(fā)生變化，如果發(fā)現(xiàn)有新視頻上傳，線程會調用視頻處理庫Ffmepg并結合關鍵幀提取算法（具體原理在下段描述）將視頻文件切割成一幅幅圖片，在進行二值化和灰度處理后，以“車牌號+日期+時間”的方式對圖片重命名并上傳到數(shù)據(jù)存儲層中的HDFS中進行保存。

雖然FFmepg庫可以將視頻文件按照時間間隔分割成圖片，但是視頻是一種高度壓縮的數(shù)據(jù)格式，在解壓過程中得到視頻幀的數(shù)據(jù)量將成倍增長，以一個大小約100M每秒24幀的480p視頻為例，解壓完后的圖片總大小約為800M，數(shù)據(jù)量增大8倍。而由于行駛客車的車內場景基本處于靜止狀態(tài)，通過對車內視頻解壓后的圖片進行對比發(fā)現(xiàn)，相鄰圖片之間的差異非常小，幾乎不會影響人臉檢測的結果，因此本文使用直方圖平均法來擴展FFmepg庫，通過計算兩視頻幀圖像之間的距離來完成關鍵幀的提取，從而大大降低圖片數(shù)據(jù)量。算法公式如下：

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

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

式⑵用于計算某一幀經過量化后圖像信號的熵，其中[P（εi）]表示隨機變量[ε]的概率密度函數(shù)。式⑴會在式⑵的基礎上計算兩個不同視頻幀[Im]，[In]之間的距離，并將該值與經驗閾值[η]進行比較：如果距離大于等于[η]，則將[In]作為關鍵幀提取出來;如果距離小于[η]，則丟棄圖片[In]，繼續(xù)抓取下一幀進行計算，直到將視頻中所有的關鍵幀全部提取出來。

通過實驗對比發(fā)現(xiàn)，在相同環(huán)境下經過擴展FFmepg庫提取出的圖片數(shù)量約為未擴展庫提取出圖片數(shù)量的1/8，極大地降低了人臉檢測模塊需要處理的數(shù)據(jù)量。

2.2.2 人臉檢測

人臉檢測模塊是判斷客車是否超載的核心功能，由于長途客車每人一座，若發(fā)生超載，人員會主要集中于過道，因此本模塊對車內圖片的過道處進行人臉檢測，如果在連續(xù)時間段檢測出多張人臉，則可判定該客車疑似超載，并將結果反饋至系統(tǒng)前臺，管理員接到通知后可對該車圖片或視頻進行回溯查看，從而確定客車是否真實超載。

在具體實現(xiàn)時，本文通過調用開源圖片處理庫OpenCV和局部二值直方圖算法（LBPH）完成了對圖片過道區(qū)域的截取及人臉檢測。同時由于業(yè)務場景需要對大量的車內圖片進行實時處理，因此本文選擇分布式實時計算框架Spark Streaming來完成圖片的讀取和OpenCV的調用，相比于另一個分布式計算框架MapReduce[8]，Spark Streaming作為Spark的擴展，支持在內存中對流式數(shù)據(jù)進行迭代計算，其處理磁盤存儲數(shù)據(jù)的速度約是MapReduce的10倍，處理內存存儲數(shù)據(jù)的速度可達MapReduce的百倍。在工作時Spark Streaming會將連續(xù)不斷的數(shù)據(jù)流進行切片后放入多個批處理流程（Batches），再由Spark引擎進行并行處理，最后將計算結果匯總輸出。實現(xiàn)流程如下。

⑴ 通過調用RDD API構建一個用于業(yè)務數(shù)據(jù)處理的有向無環(huán)圖（靜態(tài)DAG模板）。

⑵ 構建一個工作控制器（JobScheduler），將從HDFS中讀取的圖片流切割成數(shù)據(jù)片段（Data Stage）后再按照第1步的DAG模板創(chuàng)建出新的RDD。

⑶ 實現(xiàn)DAG實例以對數(shù)據(jù)片段進行處理。

基于以上原理，本文的人臉檢測功能在實現(xiàn)時構建了“從HDFS讀取圖片”=>“調用Opencv進行人臉檢測”=>“結果反饋”=>“超載預警”的Spark工作流（圖3），在通過實驗對比后發(fā)現(xiàn)系統(tǒng)的運行效率要遠大于基于MapReduce框架構建的程序。

2.2.3 GPS定位、監(jiān)控

該模塊在運行時會啟動車輛監(jiān)控線程，將車載終端層的GPS定位信息與百度地圖開放接口結合起來，對車輛的運行線路、是否超速等信息進行監(jiān)控和預警。

2.3 數(shù)據(jù)存儲層

由于系統(tǒng)在運行時產生的視頻數(shù)據(jù)量巨大，因此本文選用Hadoop框架下的分布式文件系統(tǒng)HDFS作為數(shù)據(jù)存儲層，該層主要用于存放應用服務層提取出來的視頻關鍵幀，這些視頻圖片的特點是文件?。ㄒ话銌螐堅?M左右）、數(shù)量大，但Hadoop在設計之初是為了處理大文件（幾百M或幾個G）而存在的，在處理大量小文件時反而會出現(xiàn)效率低下的問題，這是由于HDFS采用名稱節(jié)點（NameNode）來存放文件的元數(shù)據(jù)，即系統(tǒng)中所有的文件和文件夾都會占用名稱節(jié)點一定的內存空間，而且元數(shù)據(jù)的大小與文件大小沒有必然聯(lián)系，這就導致HDFS在存放海量小文件時會占用名稱節(jié)點的大量內存空間[9]。再者，在使用Spark Streaming做分布式計算時，由于生成RDD階段的任務處理對象通常是一個數(shù)據(jù)塊，如果系統(tǒng)中含有大量小文件的話，勢必會產生大量的batch任務，也會耗費大量的系統(tǒng)資源。

針對Hadoop并不適合處理海量小文件的特點，本文采用了MapFile技術將多個小文件合并成一個大文件再進行存儲。MapFile是一種帶索引的序列文件（SequenceFile），而SequenceFile又是Hadoop一種自帶的二進制文件格式，它支持以“鍵/值對”的形式在HDFS上存儲數(shù)據(jù)[10]。本文在設計時將各個客車的車牌號作為“鍵”，該車所對應的各張圖片內容作為“值”，通過“鍵/值”合并將同一輛車的所有圖片小文件壓縮合并成一個大文件后再存儲，這樣做不但解決了小文件合并問題，而且合并后的大文件在作為Spark的DStream輸入時，也可以被分割后進行單獨處理，從而提高了HDFS的存儲能力和Spark Streaming的處理效率。

3 性能測試

為了驗證系統(tǒng)在Hadoop集群下的運行效率，本文采用以下實驗環(huán)境：集群共有5個節(jié)點，其中1個Master節(jié)點，4個Slaver節(jié)點，每個節(jié)點的硬件配置為4核CPU、8G內存和512G硬盤。在實驗中，集群分別啟動2節(jié)點，3節(jié)點和4節(jié)點對300G的視頻數(shù)據(jù)進行處理，并將結果與Spark Standalone（單節(jié)點偽分布式）模式下結果進行對比，以驗證系統(tǒng)的加速比，實驗結果如圖4所示。

實驗結果表明，在單節(jié)點偽分布式下系統(tǒng)所用時間為1882.5分鐘，隨著節(jié)點的增加，系統(tǒng)的加速比成線性增長，當節(jié)點達到4個時，系統(tǒng)的速度達到單節(jié)點的六倍。這證明集群的處理效率隨著節(jié)點數(shù)目的增加而增加，系統(tǒng)具有良好的可擴展性。

4 結論

本文依托于Hadoop分布式集群，綜合應用GPS定位、圖像比對分析、人臉檢測和分布式計算框架Spark等技術設計實現(xiàn)了《基于Hadoop的客車超載監(jiān)測系統(tǒng)》，用于對行駛客車上的乘客數(shù)量進行監(jiān)測和分析，以防止超載現(xiàn)象的發(fā)生。在系統(tǒng)實現(xiàn)過程中，本文依據(jù)Hadoop和Spark Streaming的特點重點解決了在分布式環(huán)境下實現(xiàn)“視頻關鍵幀提取”、“人臉檢測”、“HDFS小文件合并”等技術難題，并通過實驗結果的對比分析，證明了系統(tǒng)無論是在運行效率還是可擴展性上都有著良好的表現(xiàn)。

參考文獻（References）：

[1] 馬麗娟.長途客車客流統(tǒng)計系統(tǒng)設計[D].西北工業(yè)大學，2007.

[2] 徐斌，陳曉冰.基于紅外傳感器的城市客車客流統(tǒng)計系統(tǒng)的研制[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中海量小文件存取關鍵技術的設計與實現(xiàn)[D].南京郵電大學，2015.

[10] 蔡睿誠.基于HDFS的小文件處理與相關MapReduce計算模型性能的優(yōu)化與改進[D].吉林大學，2012.