王 法，譚郁松，伍復(fù)慧，張京京

(國(guó)防科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)學(xué)院，湖南 長(zhǎng)沙 410073)

基于云存儲(chǔ)視頻處理框架的研究與實(shí)現(xiàn)

王 法，譚郁松，伍復(fù)慧，張京京

(國(guó)防科學(xué)技術(shù)大學(xué) 計(jì)算機(jī)學(xué)院，湖南 長(zhǎng)沙 410073)

隨著智慧城市的快速發(fā)展，視頻技術(shù)作為基礎(chǔ)數(shù)據(jù)采集手段已經(jīng)被廣泛使用。這會(huì)引發(fā)一個(gè)問(wèn)題：短時(shí)間內(nèi)生成的海量視頻數(shù)據(jù)無(wú)法快速處理，從而嚴(yán)重影響數(shù)據(jù)時(shí)效性價(jià)值的問(wèn)題愈來(lái)愈嚴(yán)重。文中提出一套基于HBase的分布式處理框架。該框架首先支持多客戶端同時(shí)上傳的視頻，然后提取其中出現(xiàn)的人臉，最終建立一個(gè)可以保存在內(nèi)存中的索引表進(jìn)行查詢加速。通過(guò)處理客戶端上傳的含有待查人臉的圖像，該框架可以快速定位人臉在上傳的視頻中出現(xiàn)的位置。針對(duì)上述需要實(shí)現(xiàn)的功能，文中詳細(xì)描述了實(shí)現(xiàn)該框架各部分中最重要的表的具體設(shè)計(jì)細(xì)節(jié)與設(shè)計(jì)目的，同時(shí)簡(jiǎn)述了人臉查詢的具體流程，并從整個(gè)集群的角度優(yōu)化集群的具體方法。最終通過(guò)在百萬(wàn)人臉中查詢特定的一張來(lái)揭示集群性能。實(shí)驗(yàn)結(jié)果顯示，該框架有較好的性能并完全能滿足真實(shí)需求。

HBase；Coprocessor；視頻檢索；云存儲(chǔ)

0 引 言

智慧城市就是運(yùn)用信息和通信技術(shù)手段感測(cè)、分析、整合城市運(yùn)行核心系統(tǒng)的各項(xiàng)關(guān)鍵信息，借助新一代的物聯(lián)網(wǎng)、云計(jì)算、決策分析優(yōu)化等信息技術(shù)，通過(guò)感知化、物聯(lián)化、智能化的方式，將城市中的物理基礎(chǔ)設(shè)施、信息基礎(chǔ)設(shè)施、社會(huì)基礎(chǔ)設(shè)施和商業(yè)基礎(chǔ)設(shè)施連接起來(lái)，成為新一代的智慧化基礎(chǔ)設(shè)施，使城市中各領(lǐng)域、各子系統(tǒng)之間的關(guān)系顯現(xiàn)出來(lái)，使之成為可以指揮決策、實(shí)時(shí)反應(yīng)、協(xié)調(diào)運(yùn)作的“系統(tǒng)之系統(tǒng)”[1]。智慧城市意味著在城市不同部門和系統(tǒng)之間實(shí)現(xiàn)信息共享和協(xié)同作業(yè)，更合理地利用資源、做出最好的城市發(fā)展和管理決策、及時(shí)預(yù)測(cè)和應(yīng)對(duì)突發(fā)事件和災(zāi)害[2]。智慧城市的實(shí)現(xiàn)過(guò)程中，視頻技術(shù)是其基本感知手段，但隨著智慧城市的發(fā)展，一個(gè)嚴(yán)重問(wèn)題會(huì)慢慢凸顯出來(lái)。以天津市為例，單一個(gè)8 Mb/s的高清攝像頭，每小時(shí)能產(chǎn)生3.6 GB的數(shù)據(jù)，“十二五”末天津市將安裝60萬(wàn)個(gè)攝像頭，即每小時(shí)天津市產(chǎn)生的視頻數(shù)據(jù)量就達(dá)到2.05 PB。如此海量的視頻數(shù)據(jù)如何在一個(gè)可以接受的時(shí)間段內(nèi)進(jìn)行處理并存儲(chǔ)，是建設(shè)智慧城市過(guò)程中必須解決的問(wèn)題。

1 海量視頻數(shù)據(jù)的存儲(chǔ)與處理的相關(guān)研究

海量數(shù)據(jù)存儲(chǔ)的思路有兩種：一是HDFS。由于Hadoop的廣泛應(yīng)用，處理海量數(shù)據(jù)很容易聯(lián)想到用Hadoop,但是由于Hadoop內(nèi)置的數(shù)據(jù)類型有限，視頻作為典型的非結(jié)構(gòu)化數(shù)據(jù)不能直接利用MapReduce框架進(jìn)行處理，解決方法為擴(kuò)展HDFS原生的接口、類來(lái)支持直接對(duì)視頻、圖像進(jìn)行處理。二是通過(guò)HDFS+非結(jié)構(gòu)化數(shù)據(jù)庫(kù)。非結(jié)構(gòu)化數(shù)據(jù)庫(kù)可以直接支持視頻、圖像的存取，例如：HBase，MongoDB(MongoDB是介于關(guān)系型數(shù)據(jù)庫(kù)和非關(guān)系型數(shù)據(jù)庫(kù)之間的，最像關(guān)系型數(shù)據(jù)庫(kù)，支持的查詢語(yǔ)言多)。具體的存儲(chǔ)方案有：邦諾公司的監(jiān)控專用存儲(chǔ)SMI-NVR系統(tǒng)，提供2～8 Gbps的傳輸帶寬和單模塊高達(dá)48 TB的存儲(chǔ)空間，最大容量可以達(dá)到64 EB；天地偉業(yè)公司的最大一款網(wǎng)絡(luò)存儲(chǔ)產(chǎn)品——IPSAN網(wǎng)絡(luò)存儲(chǔ)系統(tǒng)-V2.0，最大支持96塊硬盤，單塊硬盤容量支持4 T；SDFS(Sky Distributed File System)通過(guò)分布式集群架構(gòu)將網(wǎng)絡(luò)中普通PC、通用服務(wù)器及各種存儲(chǔ)設(shè)備集合起來(lái)協(xié)同工作，并通過(guò)專用數(shù)據(jù)接口，向用戶提供海量數(shù)據(jù)存儲(chǔ)、管理和訪問(wèn)服務(wù)。部署方式上支持全網(wǎng)分散部署，或在數(shù)據(jù)中心集中部署。

在視頻的處理領(lǐng)域，傳統(tǒng)的海量視頻處理方案有：

(1)視頻濃縮摘要。它將生成一個(gè)簡(jiǎn)短的視頻，其中包含了原視頻中所有重要的目標(biāo)活動(dòng)和快照。這一技術(shù)主要通過(guò)對(duì)目標(biāo)前景與背景的分割、視頻目標(biāo)活動(dòng)重排序來(lái)摘要和檢索。即截取視頻中有目標(biāo)運(yùn)動(dòng)的部分進(jìn)行分析，可使數(shù)據(jù)量縮小一半左右，但是對(duì)于海量視頻沒(méi)有本質(zhì)的改變[3]。

(2)基于智能分析算法進(jìn)行檢索。目前，業(yè)界推出的智能產(chǎn)品已經(jīng)有周界防范、車牌識(shí)別、人臉識(shí)別等較成熟的產(chǎn)品。在這些產(chǎn)品中，觸發(fā)周界防范規(guī)則的物體，被識(shí)別的車牌和人臉，都可作為視頻檢索的輸入檢索條件[4]。一幀圖像算法執(zhí)行時(shí)間在10 ms左右，監(jiān)控視頻的幀率為24～25 幀/s,每幀的播放時(shí)間為40 ms左右，即檢索速度提升了4倍，一個(gè)24小時(shí)的視頻經(jīng)過(guò)濃縮，智能分析算法之后可縮短為3個(gè)小時(shí)左右。

(3)基于視頻數(shù)據(jù)的元數(shù)據(jù)的檢索。對(duì)經(jīng)過(guò)智能算法分析生成的元數(shù)據(jù)進(jìn)行檢索，24小時(shí)的視頻檢索時(shí)間可以控制在10秒量級(jí)，但對(duì)于60萬(wàn)個(gè)攝像頭1個(gè)小時(shí)生成的視頻來(lái)說(shuō)，查詢其中特定的信息就需要接近70個(gè)小時(shí)，還不計(jì)算海量數(shù)據(jù)傳輸對(duì)性能的影響。

所以傳統(tǒng)的視頻處理手段已經(jīng)不能滿足日益增長(zhǎng)的性能需求。針對(duì)此問(wèn)題，文中提出一種基于云存儲(chǔ)的視頻處理框架。該框架所有的部件都是開(kāi)源軟件，實(shí)現(xiàn)了從視頻中抽取人臉，快速查詢某一圖片中人臉在視頻中出現(xiàn)位置的功能。

2 基于云存儲(chǔ)視頻處理框架

HBase是基于Bigtable:A Distributed Storage System for Structured Data[5]的開(kāi)源實(shí)現(xiàn)，建立在HDFS上，具有高可靠性、高性能、列存儲(chǔ)、可伸縮、實(shí)時(shí)讀寫的數(shù)據(jù)庫(kù)系統(tǒng)[6]。HBase目標(biāo)主要依靠橫向擴(kuò)展，通過(guò)不斷增加廉價(jià)的商用服務(wù)器，來(lái)增加計(jì)算和存儲(chǔ)能力[7]。HBase中表的邏輯結(jié)構(gòu)如圖1所示。

圖1 HBase表的邏輯結(jié)構(gòu)

圖中：Key1，Key2表示行健(Rowkey)；T1，T2，T3表示時(shí)間戳(TimeStamp)；Column1,Column2，Column3表示列(Column)；ColumnFamily1,ColumnFamily2表示列簇(ColumnFamily)。

其中，行健、列簇都是不可重復(fù)的,而不同的列簇可以有相同的列，如圖中ColumnFamily1:Column1,ColumnFamily2：Column1。而要確定一個(gè)單元格的位置，就要通過(guò)來(lái)確定。

HBase主體包括兩部分：一是HMaster，主要負(fù)責(zé)一系列的系統(tǒng)級(jí)的操作。例如，管理用戶對(duì)表的增刪改查，管理HRegionServer的負(fù)載均衡，調(diào)整Region分布；RegionSplit后，負(fù)責(zé)新Region的分布；在HRegionServer停機(jī)后，負(fù)責(zé)失效HRegionServer上Region的遷移。二是HRegionServer，負(fù)責(zé)響應(yīng)用戶的I/O請(qǐng)求，即數(shù)據(jù)的入庫(kù)，查詢都是通過(guò)RegionServer來(lái)處理的[8]。

目前隨著云計(jì)算的快速發(fā)展，海量數(shù)據(jù)的處理都可以通過(guò)云計(jì)算來(lái)完成，而HBase自身支持的Coprocessor[9]分布式計(jì)算框架，可以和HBase共享緩存，不需要單獨(dú)的內(nèi)存數(shù)據(jù)庫(kù)，同時(shí)可以加載到HBase的任意位置，即可以對(duì)HBase中所有操作執(zhí)行前后加載自定義功能。對(duì)文中框架來(lái)說(shuō)，即可以在入庫(kù)的同時(shí)分布式地完成數(shù)據(jù)的處理[10]。

對(duì)于視頻的處理，采用OpenCV(OpensourceComputerVisionlibrary)開(kāi)源計(jì)算機(jī)視覺(jué)庫(kù)來(lái)進(jìn)行。OpenCV對(duì)于商業(yè)應(yīng)用和非商業(yè)應(yīng)用都是免費(fèi)的，有C++，C，Python，Java版本的接口同時(shí)支持Windows，Linux，IOS，Android等平臺(tái)[11]。

綜上所述，文中框架所用的軟件有HBase+HDFS+Zookeeper(HBase集群需要),分布式計(jì)算使用Coprocessor計(jì)算框架，視頻處理采用OpenCV庫(kù)。

系統(tǒng)框架圖如圖2所示。

圖2 系統(tǒng)框架圖

圖2中，客戶端通過(guò)網(wǎng)絡(luò)訪問(wèn)Zookeeper集群，獲取HBase中各個(gè)節(jié)點(diǎn)的位置[12]。面臨海量數(shù)據(jù)時(shí)一個(gè)重要的問(wèn)題就是，怎么能盡可能均勻地把數(shù)據(jù)分發(fā)到集群中的各個(gè)節(jié)點(diǎn)。若都集中在一個(gè)或幾個(gè)節(jié)點(diǎn)，容易引起系統(tǒng)性能降低，甚至宕機(jī)等問(wèn)題[13]。同時(shí)若所有數(shù)據(jù)都存儲(chǔ)在磁盤中查詢的時(shí)候會(huì)影響性能，傳統(tǒng)解決思路就是把表放到內(nèi)存中，但是海量數(shù)據(jù)即使經(jīng)過(guò)提取也不可能放到內(nèi)存中。下面的實(shí)現(xiàn)中會(huì)解決這些問(wèn)題。

3 基于云存儲(chǔ)視頻處理框架的實(shí)現(xiàn)

3.1 表的設(shè)計(jì)

文中框架的分布式計(jì)算是部分通過(guò)掛載在各個(gè)表上的Coprocessor實(shí)現(xiàn)的，用到的表有3個(gè)，分別為：Data，F(xiàn)aces，KeyPoint。其具體設(shè)計(jì)如下：

1)Data、Faces表中行健和列簇設(shè)計(jì)是相同的。不同的是，Data表并不存儲(chǔ)任何數(shù)據(jù)，而是作為原始數(shù)據(jù)接收節(jié)點(diǎn)進(jìn)行第一次分布式計(jì)算，即檢測(cè)從客戶端上傳的每一幀圖像中的人臉，而Faces表在保存所有檢測(cè)到的人臉的同時(shí)進(jìn)行關(guān)鍵點(diǎn)檢測(cè)，并且兩個(gè)表支持的數(shù)據(jù)版本數(shù)不一致。所有表的設(shè)計(jì)都遵循一個(gè)原則：盡量保持行健、列簇最小化[14]。兩個(gè)表的結(jié)構(gòu)為：

(1)行健(Rowkey)：形式表示為A+B。其中，A表示一個(gè)7位16進(jìn)制數(shù)，B表示文件名，例如：ef00201+file1.avi。其中七位數(shù)為這一幀圖片在視頻中的位置，表示成16進(jìn)制逆序形式。取七位數(shù)是由于目前的視頻大都是每秒24～25幀，即使是7*24小時(shí)不停地錄制成一個(gè)文件，最后一幀轉(zhuǎn)換成16進(jìn)制，也可以表示為8000019。所以為了保持行健盡可能短，只取7位數(shù)。逆序是為預(yù)防HBase中的HotSpotting問(wèn)題(即當(dāng)大量的客戶端訪問(wèn)流量集中在集群中的一個(gè)或幾個(gè)節(jié)點(diǎn)時(shí)，這個(gè)流量可能是由大量的讀、寫或者其他操作造成的，這樣超過(guò)單一節(jié)點(diǎn)反應(yīng)能力的流量會(huì)導(dǎo)致性能下降甚至RegionServer宕機(jī))。而在HBase的設(shè)計(jì)中，每一個(gè)要存入HBase的數(shù)據(jù)，都是通過(guò)Rowkey來(lái)定位Region，而HBase中Rowkey是嚴(yán)格按字典序排列的。例如01，02,03,3個(gè)Rowkey都是以0開(kāi)頭的，所以它們都會(huì)定位到同一個(gè)或幾個(gè)Region中。所以若不做預(yù)防，大量具有相同行健首字節(jié)的寫入請(qǐng)求會(huì)導(dǎo)致RegionServer宕機(jī)，而把幀數(shù)變成16進(jìn)制逆序就可以把寫入請(qǐng)求平均分配到以0-f開(kāi)頭的16個(gè)或者16的倍數(shù)個(gè)Region中，而幀位置+文件名，就可以唯一定位一幀圖像了。這樣保持了行健的唯一性，生產(chǎn)環(huán)境中可以再加入客戶端ip，端口，來(lái)防止Rowkey重名。

(2)列簇(ColumnFamily)：列簇名定為T(Time的首字母)，表示的是這一幀圖像在視頻中的時(shí)間，單位為ms，列名以字節(jié)形式保存。此設(shè)計(jì)有2個(gè)優(yōu)點(diǎn)：一是人性化。這樣查找到的結(jié)果顯示的格式就是類似：file:file1.avi，time：01h:01m:30.23s，而不會(huì)是file：file1.avi，locate：5600幀；二是在保持需求的情況下，列盡可能得小。

(3)版本數(shù)：Data表本身不會(huì)存儲(chǔ)數(shù)據(jù)，所以版本數(shù)設(shè)置為1。而Faces表中存儲(chǔ)的數(shù)據(jù)是一幀圖像中提取出來(lái)的人臉，由于在一幀圖像中可能找到多于一張人臉，所以Faces表中的版本數(shù)設(shè)定為256個(gè),即文中框架假設(shè)一幀圖片中定位出的人臉最多有256個(gè)，這是2位16進(jìn)制數(shù)可以表示的最大數(shù)量。而在實(shí)際測(cè)試中，一幀圖像中所能提取的人臉數(shù)量一般只有個(gè)位數(shù)個(gè)。

2)KeyPoint表中存儲(chǔ)的是每一張?zhí)崛〕鰜?lái)的人臉的關(guān)鍵點(diǎn)序列，其設(shè)計(jì)為：

(1)行健(Rowkey)：形式表示為A+B。其中，A表示一個(gè)2位16進(jìn)制隨機(jī)數(shù)(與Faces表的版本數(shù)對(duì)應(yīng))，B表示本張人臉?biāo)鶎?duì)應(yīng)的圖片在視頻中的位置，即存儲(chǔ)在Faces表中對(duì)應(yīng)數(shù)據(jù)的行健。例如：ef+ef00201+file1.avi，A對(duì)應(yīng)ef，B對(duì)應(yīng)ef00201+file1.avi。由于每行數(shù)據(jù)的入庫(kù)操作都是在不同的RegionServer上提交的，所以很難構(gòu)造一個(gè)可以全局比對(duì)的唯一行健，而且進(jìn)行比對(duì)還要花費(fèi)額外的網(wǎng)絡(luò)開(kāi)銷。針對(duì)此問(wèn)題，行健的設(shè)計(jì)：B為Faces表中的行健，所以單就B來(lái)說(shuō)是唯一的，不唯一的情況是一幀圖片中提取的人臉不唯一，所以只要在B之前加一個(gè)2位16進(jìn)制隨機(jī)數(shù)，且保證同一幀圖片中提取出來(lái)的多個(gè)人臉?biāo)〉玫碾S機(jī)數(shù)不重復(fù)，就可以保證行健的唯一性。取隨機(jī)數(shù)同樣是為了預(yù)防HotSpotting問(wèn)題，如果都是從1開(kāi)始增加，則所有的寫入數(shù)據(jù)還是會(huì)定位到一個(gè)或幾個(gè)Region上。

(2)列簇(ColumnFamily)：列簇名為F(From的首字母)，存儲(chǔ)的是本行數(shù)據(jù)來(lái)自視頻中的哪一幀圖像的行健。這樣只要查詢到本條記錄之后，就可以直接以行健來(lái)查詢Faces表。

(3)版本數(shù)：由于KeyPoint表中的每一行數(shù)據(jù)表示的是每一張人臉提取出來(lái)的關(guān)鍵點(diǎn)序列，所以版本數(shù)設(shè)置為1即可。

3.2 數(shù)據(jù)的查詢

數(shù)據(jù)一遍查詢的過(guò)程如圖3所示。

圖3 查詢的過(guò)程

查詢的過(guò)程如下：

(1)輸入要檢測(cè)的圖片。直接把圖片放到程序中設(shè)置的文件夾中即可。

(2)判斷給定的圖片中是否有人臉，若有則跳轉(zhuǎn)到第3步，若沒(méi)有則跳轉(zhuǎn)到第6步。執(zhí)行和加載在Data表上的Coprocessor同樣的功能，直接把檢測(cè)結(jié)果放到一個(gè)List中。若List為空，則表示圖片中沒(méi)有檢測(cè)到人臉，執(zhí)行第6步；若List不為空，則對(duì)提取出來(lái)的結(jié)果進(jìn)行第3步。

(3)計(jì)算每張?zhí)崛〕龅娜四樀年P(guān)鍵點(diǎn)序列。為L(zhǎng)ist中每一張?zhí)崛〕鰜?lái)的人臉計(jì)算關(guān)鍵點(diǎn)，經(jīng)過(guò)與加載在Faces表中的Coprocessor同樣過(guò)程的關(guān)鍵點(diǎn)序列提取轉(zhuǎn)化，生成用于查詢的字節(jié)數(shù)組。進(jìn)行第4步。

(4)構(gòu)造ValueFilter過(guò)濾器，在KeyPoint表中查詢，若有則跳轉(zhuǎn)到第5步，若沒(méi)有則跳轉(zhuǎn)到第6步。構(gòu)造用于KeyPoint表中查詢的ValueFilter中比較運(yùn)算符設(shè)置為EQUAL，比較器使用原生的BinaryPrefixComparator，此比較器從左向右比較當(dāng)前值與閾值，這樣在匹配過(guò)程中只要有一位不匹配就放棄，提高了查詢速度。若匹配結(jié)果為空，執(zhí)行第6步；若匹配結(jié)果不為空，則執(zhí)行第5步。

(5)提取匹配結(jié)果中的列名，直接通過(guò)行健構(gòu)造Get在Faces表中查找。因?yàn)镵eyPoint表的匹配結(jié)果中提取出來(lái)的列名即為Faces表中的行鍵，通過(guò)行健檢索表直接構(gòu)造Get即可，執(zhí)行第6步。

(6)輸出結(jié)果。若執(zhí)行順序?yàn)?-6，則表示圖片中沒(méi)有檢測(cè)到人臉，輸出“圖片中未檢測(cè)到人臉”。若執(zhí)行順序?yàn)?-6，則表示數(shù)據(jù)庫(kù)中沒(méi)有匹配項(xiàng)，則輸出“數(shù)據(jù)庫(kù)中沒(méi)有匹配”。若執(zhí)行順序?yàn)?-6，提取查詢結(jié)果中的各個(gè)數(shù)據(jù)輸出結(jié)果：列值，轉(zhuǎn)換為圖片即為匹配到的人臉；列名，即為查詢到的人臉在視頻中出現(xiàn)的時(shí)間；行健，跳過(guò)7位數(shù)就可以得到文件名。

4 性能優(yōu)化與測(cè)評(píng)

4.1 處理性能優(yōu)化

要保證計(jì)算的速度，就要盡量使得協(xié)處理器(Coprocessor)的計(jì)算時(shí)間最少。文中框架加載了兩個(gè)協(xié)處理器：

(1)加載于Data表中，與CheckAndPut操作掛鉤用于人臉檢測(cè)的協(xié)處理器。即在寫入Data表之前判斷這一幀圖片中有沒(méi)有人臉，如果有則將提取出來(lái)的人臉存入Face表中，如果沒(méi)有，則拋棄。而OpenCV視覺(jué)庫(kù)中，用于人正臉檢測(cè)的分類器(CascadeClassifier)有3種,分別是frontface_alt，frontface_alt2，frontface_default。三種檢測(cè)的硬件環(huán)境完全相同，所處理的10幀圖片完全相同，三種分類器檢測(cè)用時(shí)如圖4所示。

如圖4所示，文中框架選擇了frontface_default分類器。

圖4 三種分類器檢測(cè)10幀圖片用時(shí)累積

(2)加載于Faces表中，同樣與掛鉤CheckAndPut操作用于計(jì)算關(guān)鍵點(diǎn)序列的協(xié)處理器。即所有檢測(cè)到的人臉圖片在寫入Faces表之前都計(jì)算關(guān)鍵點(diǎn)，計(jì)算結(jié)果存入KeyPoint表。OpenCV視覺(jué)庫(kù)中關(guān)鍵點(diǎn)提取算法有很多種，經(jīng)過(guò)實(shí)驗(yàn)，在已提取出的人臉圖片中始終可以檢測(cè)到關(guān)鍵點(diǎn)的算法有3種：DYNAMIC_FAST、PYNAMIC_FAST、FAST。只使用單一個(gè)頻率為2.0 GHz的CPU，分別用3種算法計(jì)算3 000幀圖片中關(guān)鍵點(diǎn)所用的時(shí)間，每次計(jì)算都是獨(dú)立運(yùn)行，三種算法計(jì)算用時(shí)如表1所示。

實(shí)驗(yàn)結(jié)果表明，DYNAMIC_FAST是最快的關(guān)鍵點(diǎn)提取算法。

4.2 查詢性能優(yōu)化

KeyPoint表中存儲(chǔ)的是每一張?zhí)崛〕鰜?lái)的人臉的關(guān)鍵點(diǎn)，相當(dāng)于人臉檢索的索引表。為保證查詢速度，就要保持KeyPoint表一直在內(nèi)存中，即要保證KeyPoint表中每條數(shù)據(jù)盡可能小。而OpenCV中每個(gè)關(guān)鍵點(diǎn)的坐標(biāo)由2個(gè)double，3個(gè)float，2個(gè)int組成。若不做變化直接存儲(chǔ)，那么每個(gè)關(guān)鍵點(diǎn)需要36 B空間，而經(jīng)過(guò)篩選簡(jiǎn)化之后，每個(gè)關(guān)鍵點(diǎn)只需要16 B，這樣就減少了55%的空間。3 000張人臉中的關(guān)鍵點(diǎn)數(shù)與平均關(guān)鍵點(diǎn)數(shù)如圖5所示。

表1 三種檢測(cè)算法用時(shí)

圖5 3 000張人臉中的關(guān)鍵點(diǎn)數(shù)與平均關(guān)鍵點(diǎn)數(shù)

實(shí)驗(yàn)結(jié)果顯示，每張?zhí)崛〕龅娜四樦衅潢P(guān)鍵點(diǎn)數(shù)平均為102個(gè)，即每張人臉的關(guān)鍵點(diǎn)需要1 632 B，加上入庫(kù)時(shí)的行健、列簇名、列名、時(shí)間戳，即KeyPoint表中每行數(shù)據(jù)大約為2 000 B，則一千萬(wàn)張人臉的關(guān)鍵點(diǎn)表所占的空間約為18.63 GB。這樣的內(nèi)存占用對(duì)于一個(gè)集群來(lái)說(shuō)沒(méi)有壓力。

4.3 查詢性能測(cè)評(píng)

測(cè)試環(huán)境：集群為8個(gè)HRegionServer+1個(gè)HMaster，所有的節(jié)點(diǎn)都部署在廣州天河2號(hào)云平臺(tái)上。其中，HRegionServer配置：4核CPU，內(nèi)存8 G，系統(tǒng)為Ubuntu 14.04；HMaster配置：8核CPU，內(nèi)存16 G，系統(tǒng)為Ubuntu 14.04。HMaster配置提高是為了通過(guò)多線程模擬多個(gè)客戶端并發(fā)提交入庫(kù)任務(wù)。待匹配的表中有人臉1 558 093張，實(shí)驗(yàn)所測(cè)得的時(shí)間包括兩次查表時(shí)間及結(jié)果返回時(shí)間，不包括與集群建立鏈接的時(shí)間。200幀圖片獨(dú)立查詢時(shí)間及平均查詢時(shí)間如圖6所示。

圖6 200幀圖片獨(dú)立查詢時(shí)間及平均查詢時(shí)間

實(shí)驗(yàn)結(jié)果顯示，在155萬(wàn)幀圖片中進(jìn)行查詢，文中框架有較好的性能，查詢一張圖片中人臉的平均查詢時(shí)間在1.5 s左右。而其中個(gè)別圖片的查詢時(shí)間接近3 s，可能是由于進(jìn)行近似全表掃描造成的。

5 結(jié)束語(yǔ)

文中基于HBase的非結(jié)構(gòu)化存儲(chǔ)特性和本身支持的Coprocessor計(jì)算框架，設(shè)計(jì)并實(shí)現(xiàn)了一個(gè)視頻處理框架，在86萬(wàn)圖片中平均查詢時(shí)間為1 s左右。文中對(duì)視頻處理框架進(jìn)行了介紹，視頻的處理時(shí)間的影響因素主要是OpenCV視覺(jué)庫(kù)中的處理算法用時(shí)，所以提高視頻處理速度的主要途徑是優(yōu)化OpenCV視覺(jué)庫(kù)中的視頻處理算法，而查詢時(shí)間則可以體現(xiàn)該框架的性能。實(shí)驗(yàn)結(jié)果表明，該框架運(yùn)用云資源或者PC集群來(lái)處理視頻是可行的，并有較好的效率。下一步即通過(guò)優(yōu)化OpenCV端的處理算法，來(lái)對(duì)該框架的整體性能進(jìn)行優(yōu)化。

[1] 戈悅迎,寇有觀,金江軍,等.大數(shù)據(jù)時(shí)代下城市應(yīng)急管理發(fā)展之路[J].中國(guó)信息界,2014(1):56-65.

[2] 張永民,杜忠潮.我國(guó)智慧城市建設(shè)的現(xiàn)狀及思考[J].中國(guó)信息界,2011(2):28-32.

[3] 郭 斌,蔡巍偉,王 鵬.海量視頻數(shù)據(jù)快速檢索[J].中國(guó)公共安全,2013(6):109-111.

[4] Garcia A,Kalva H,Furht B.A study of transcoding on cloud environments for video content delivery[C]//Proceedings of the 2010 ACM multimedia workshop on mobile cloud media computing.[s.l.]:ACM,2010:13-18.

[5] Chang F,Dean J,Ghemawat S,et al.Bigtable:a distributed storage system for structured data[J].ACM Transactions on Computer Systems,2008,26(2):4-4.

[6] 劉炳均,戴云松.基于超算平臺(tái)和Hadoop的并行轉(zhuǎn)碼方案設(shè)計(jì)[J].電視技術(shù),2014,38(7):123-126.

[7] Dutta H,Kamil A,Pooleery M,et al.Distributed storage of large-scale multidimensional electroencephalogram data using Hadoop and HBase[M]//Grid and cloud database management.Berlin:Springer,2011:331-347.

[8] George L.HBase:the definitive guide[M].[s.l.]:O'Reilly Media,Inc,2011.

[9] Han D,Stroulia E.A three-dimensional data model in HBase for large time-series dataset analysis[C]//Proc of IEEE 6th international workshop on the maintenance and evolution of service-oriented and cloud-based systems.[s.l.]:IEEE,2012:47-56.

[10] Vora M N.Hadoop-HBase for large-scale data[C]//Proc of international conference on computer science and network technology.[s.l.]:IEEE,2011:601-605.

[11] Bradski G,Kaehler A.Learning OpenCV:computer vision with the OpenCV library[M].[s.l.]:O'Reilly Media,Inc,2008.

[12] Hunt P,Konar M,Junqueira F P,et al.ZooKeeper:wait-free coordination for internet-scale systems[C]//Proc of USENIX annual technical conference.[s.l.]:USENIX,2010.

[13] Bertini M,del Bimbo A,Nunziati W.Video clip matching using MPEG-7 descriptors and edit distance[M]//Image and video retrieval.Berlin:Springer,2006:133-142.

[14] Nishimura S,Das S,Agrawal D,et al.MD-HBase:design and implementation of an elastic data infrastructure for cloud-scale location services[J].Distributed and Parallel Databases,2013,31(2):289-319.

Research and Implementation of Video Processing Framework Based on Cloud Storage

WANG Fa,TAN Yu-song,WU Fu-hui,ZHANG Jing-jing

(School of Computer,National University of Defense Technology,Changsha 410073，China)

With the rapid development of smart city,video technology has been widely used as a basic data collection method which has caused a problem that the massive video data generated in a short time wouldn’t process promptly,seriously affecting the timeliness of data value,becomes more and more serious.In this paper,a distributed processing framework based on HBase is proposed.It supports multi-client updated videos simultaneously,then extracts faces appeared in those videos and builds an index table stored in memory to increase query speed.Through processing a frame image which uploaded from client with special faces,the framework could locate those faces in those videos.In response to those functions which needs to be implemented,the details and design purpose of most important table in various parts of framework are described in this paper,meanwhile it outlines the specific processes of the face query,optimizing it from the perspective of entire cluster.Finally,an experiment that retrieves one special face in millions of magnitude of image data is used to reflect the effect of this framework.According to the experiment,this framework has good performance,and actual demand is satisfied completely.

HBase;Coprocessor;video retrieval;cloud storage

2015-08-14

2015-11-18

時(shí)間：2016-05-05

國(guó)家“863”高技術(shù)發(fā)展計(jì)劃項(xiàng)目(2013AA01A212);國(guó)家自然科學(xué)基金資助項(xiàng)目(61202121);廣州市科技計(jì)劃(2013Y2-00043)

王 法(1990-)，男，碩士研究生，研究方向?yàn)樵朴?jì)算、云存儲(chǔ)；譚郁松，博士，碩導(dǎo)，研究員，研究方向?yàn)椴僮飨到y(tǒng)、云計(jì)算。

http://www.cnki.net/kcms/detail/61.1450.TP.20160505.0829.090.html

TP39

A

1673-629X(2016)05-0001-06

10.3969/j.issn.1673-629X.2016.05.001