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

王 法，譚郁松，伍復慧，張京京

(國防科學技術大學 計算機學院，湖南 長沙 410073)

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

王 法，譚郁松，伍復慧，張京京

(國防科學技術大學 計算機學院，湖南 長沙 410073)

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

HBase；Coprocessor；視頻檢索；云存儲

0 引 言

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

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

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

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

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

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

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

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

2 基于云存儲視頻處理框架

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

圖1 HBase表的邏輯結構

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

其中，行健、列簇都是不可重復的,而不同的列簇可以有相同的列，如圖中ColumnFamily1:Column1,ColumnFamily2：Column1。而要確定一個單元格的位置，就要通過來確定。

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

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

對于視頻的處理，采用OpenCV(OpensourceComputerVisionlibrary)開源計算機視覺庫來進行。OpenCV對于商業(yè)應用和非商業(yè)應用都是免費的，有C++，C，Python，Java版本的接口同時支持Windows，Linux，IOS，Android等平臺[11]。

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

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

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

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

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

3.1 表的設計

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

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

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

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

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

2)KeyPoint表中存儲的是每一張?zhí)崛〕鰜淼娜四樀年P鍵點序列，其設計為：

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

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

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

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

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

圖3 查詢的過程

查詢的過程如下：

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

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

(3)計算每張?zhí)崛〕龅娜四樀年P鍵點序列。為List中每一張?zhí)崛〕鰜淼娜四樣嬎汴P鍵點，經(jīng)過與加載在Faces表中的Coprocessor同樣過程的關鍵點序列提取轉化，生成用于查詢的字節(jié)數(shù)組。進行第4步。

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

(5)提取匹配結果中的列名，直接通過行健構造Get在Faces表中查找。因為KeyPoint表的匹配結果中提取出來的列名即為Faces表中的行鍵，通過行健檢索表直接構造Get即可，執(zhí)行第6步。

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

4 性能優(yōu)化與測評

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

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

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

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

圖4 三種分類器檢測10幀圖片用時累積

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

實驗結果表明，DYNAMIC_FAST是最快的關鍵點提取算法。

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

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

表1 三種檢測算法用時

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

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

4.3 查詢性能測評

測試環(huán)境：集群為8個HRegionServer+1個HMaster，所有的節(jié)點都部署在廣州天河2號云平臺上。其中，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配置提高是為了通過多線程模擬多個客戶端并發(fā)提交入庫任務。待匹配的表中有人臉1 558 093張，實驗所測得的時間包括兩次查表時間及結果返回時間，不包括與集群建立鏈接的時間。200幀圖片獨立查詢時間及平均查詢時間如圖6所示。

圖6 200幀圖片獨立查詢時間及平均查詢時間

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

5 結束語

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

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

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

[3] 郭 斌,蔡巍偉,王 鵬.海量視頻數(shù)據(jù)快速檢索[J].中國公共安全,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] 劉炳均,戴云松.基于超算平臺和Hadoop的并行轉碼方案設計[J].電視技術,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

時間：2016-05-05

國家“863”高技術發(fā)展計劃項目(2013AA01A212);國家自然科學基金資助項目(61202121);廣州市科技計劃(2013Y2-00043)

王 法(1990-)，男，碩士研究生，研究方向為云計算、云存儲；譚郁松，博士，碩導，研究員，研究方向為操作系統(tǒng)、云計算。

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