隨著互聯(lián)網(wǎng)、云計(jì)算及大數(shù)據(jù)等信息技術(shù)的發(fā)展,越來越多的應(yīng)用依賴于對海量數(shù)據(jù)的存儲和處理,如智能監(jiān)控、電子商務(wù)、地理信息等,這些應(yīng)用都需要對海量圖片的存儲和檢索。由于圖片大多是小文件(80%大小在數(shù)MB以內(nèi)),以GFS、HDFS為代表的適用于流式訪問大文件的分布式存儲系統(tǒng),若直接用來存儲圖片,由于元數(shù)據(jù)膨脹,在擴(kuò)展性和性能方面均存在嚴(yán)重問題。

為了解決HDFS在小文件存儲方面的問題,通常的做法是先將很多小文件合并成一個(gè)大文件再保存到HDFS,同時(shí)為這些小文件建立索引,以便進(jìn)行快速存取。典型技術(shù)包括Hadoop自帶的Archive、SequenceFile,但均需要用戶自己編寫程序,實(shí)現(xiàn)小文件的合并。為了實(shí)現(xiàn)小文件合并對用戶的透明,需從系統(tǒng)層面解決HDFS小文件問題。論文針對具體應(yīng)用場景進(jìn)行了探索,但不具有通用性。與前面方案不改變HDFS本身不同,淘寶TFS對HDFS的元數(shù)據(jù)存儲架構(gòu)進(jìn)行了調(diào)整。在元數(shù)據(jù)節(jié)點(diǎn)僅存放數(shù)據(jù)塊與數(shù)據(jù)節(jié)點(diǎn)的映射,而將文件與數(shù)據(jù)塊的映射關(guān)系保存到文件名,不再需要在元數(shù)據(jù)節(jié)點(diǎn)同時(shí)存放這兩類映射,最終實(shí)現(xiàn)了系統(tǒng)層面解決小文件問題。但由于文件名包含數(shù)據(jù)塊信息,為文件和數(shù)據(jù)塊建立了強(qiáng)關(guān)系,導(dǎo)致數(shù)據(jù)塊使用僵硬,TFS在文件的命名、移動方面帶來新的問題,限制了其應(yīng)用場景。
HBase是基于HDFS的簡單結(jié)構(gòu)化數(shù)據(jù)分布式存儲技術(shù),其可被用來存儲海量圖片小文件,并具有系統(tǒng)層小文件合并、全局名字空間等多種優(yōu)勢。但基于HBase的海量圖片存儲技術(shù)也存在一些問題。本文將介紹基于HBase的海量圖片存儲技術(shù),并針對其問題給出改進(jìn)方法。本文第1部分介紹了基于HBase的海量圖片存儲技術(shù)方案,并分析了原理及優(yōu)勢。第2部分介紹了該方案存在的問題及改進(jìn)方法。第3部介紹了改進(jìn)后方案的應(yīng)用效果。第4部分總結(jié)全文,并指明下一步工作。
一、基于HBase的海量圖片存儲技術(shù)
Google利用BigTable來存儲網(wǎng)頁快照及屬性信息,來支持網(wǎng)頁搜索。受此啟發(fā),在HBase中用同樣的方法來存儲圖片及其屬性信息。具體方法即建立一張大表,用一個(gè)單獨(dú)的列簇存儲圖片內(nèi)容,用其他列簇存儲圖片的類型、大小、創(chuàng)建時(shí)間、修改時(shí)間等標(biāo)準(zhǔn)屬性及應(yīng)用相關(guān)的屬性信息。HBase的列簇劃分除了考慮邏輯關(guān)系外,還需考慮數(shù)據(jù)類型,即將邏輯關(guān)系相近且數(shù)據(jù)類型相同的作為一個(gè)列簇。大表的具體設(shè)計(jì)如表1所示。
表1:基于HBase的海量圖片存儲技術(shù)的大表設(shè)計(jì)
HBase是采用面向列的存儲模型,按列簇來存儲和處理數(shù)據(jù),即同一列簇的數(shù)據(jù)會連續(xù)存儲。HBase在存儲每個(gè)列簇時(shí),會以Key-Value的方式來存儲每行單元格(Cell)中的數(shù)據(jù),形成若干數(shù)據(jù)塊,然后把數(shù)據(jù)塊保存到HFile中,最后把HFile保存到后臺的HDFS上。由于用單元格(Cell)存儲圖片小文件的內(nèi)容,上述存儲數(shù)據(jù)的過程實(shí)際上隱含了把圖片小文件打包的過程。
搭建HBase集群后,采用上面設(shè)計(jì)的大表即可存儲海量圖片。但由于HBase存在數(shù)據(jù)塊限制,還需要根據(jù)應(yīng)用進(jìn)行調(diào)整。默認(rèn)情況下,HBase數(shù)據(jù)塊限制為64KB。由于圖片內(nèi)容作為單元格(Cell)的值保存,其大小受制于數(shù)據(jù)塊的大小。在應(yīng)用中需根據(jù)大圖片大小對HBase數(shù)據(jù)塊大小進(jìn)行修改。具體修改方法是在表創(chuàng)建時(shí),用HColumnDescriptor指定數(shù)據(jù)塊大小,可分列簇指定,具體配置代碼如下。
代碼1:用HCoIumnDescriptor將數(shù)據(jù)塊限制調(diào)整為512KB

圖1 配置代碼
上述基于HBase的海量圖片存儲技術(shù)具有如下優(yōu)點(diǎn):
(1)通過將圖片屬性信息與圖片內(nèi)容存儲到一個(gè)大表中,可支持圖片的多屬性綜合查詢。此外,還可以根據(jù)應(yīng)用需求,對列簇進(jìn)行擴(kuò)展以保存應(yīng)用相關(guān)信息,從而支持應(yīng)用相關(guān)的圖片查詢。可見,基于HBase的海量圖片存儲技術(shù)不僅解決了圖片存儲,還實(shí)現(xiàn)了靈活的圖片檢索。
(2)HBase隱含了小文件打包過程,無需進(jìn)行二次開發(fā)即實(shí)現(xiàn)了系統(tǒng)層小文件合并。
(3)HBase采用分布式B+樹對圖片元數(shù)據(jù)進(jìn)行全局統(tǒng)一管理,實(shí)現(xiàn)了全局名字空間,方便了對圖片的管理。
二、基于HBase的海量圖片存儲技術(shù)存在問題及改進(jìn)方法
基于HBase的海量圖片存儲技術(shù)雖有上述優(yōu)點(diǎn),但也存在一些問題。為了說明問題,首先分析HBase中圖片數(shù)據(jù)的存儲結(jié)構(gòu)。在基于HBase的海量圖片存儲技術(shù)中,圖片內(nèi)容數(shù)據(jù)1)2Key-Value的方式進(jìn)行保存,每個(gè)Key-Value對就是一個(gè)簡單的字節(jié)數(shù)組。這個(gè)字節(jié)數(shù)組里面包含了很多項(xiàng),并且有固定的結(jié)構(gòu),如圖2所示。開始是兩個(gè)固定長度的數(shù)值,分別表示Key的長度和Value的長度。緊接著是Key部分,在這一部分開始是一個(gè)固定長度的數(shù)值,表示RowKey的長度,接著是RowKey,然后是固定長度的數(shù)值,表示Family的長度,然后是Family,接著是Qualifier,然后是兩個(gè)固定長度的數(shù)值,表示Time Stamp和Key Type(Put/Delete)。Value部分是純粹的二進(jìn)制數(shù)據(jù)。

圖2 HFile Cell的Key-Value存儲結(jié)構(gòu)
可見,(1)無校驗(yàn)碼設(shè)計(jì),導(dǎo)致存儲圖片數(shù)據(jù)的正確性無法驗(yàn)證;(2)Key-Value字節(jié)數(shù)組沒有進(jìn)行對齊,影響讀寫效率。為了解決此兩個(gè)問題,需對Key-Value存儲結(jié)構(gòu)進(jìn)行完善,在Valu域部分后面增加校驗(yàn)和及補(bǔ)白兩個(gè)域。校驗(yàn)和為8個(gè)字節(jié)(64位)。通過補(bǔ)白部分,使每個(gè)Key-Value字節(jié)數(shù)組大小為8字節(jié)的整數(shù)倍,從而更加適合64位系統(tǒng),如圖3所示。做了上述調(diào)整后,在讀寫數(shù)據(jù)時(shí)都要進(jìn)行相應(yīng)改變。在寫數(shù)據(jù)時(shí),首先對Value域進(jìn)行校驗(yàn)和計(jì)算,并寫入校驗(yàn)和域;然后,計(jì)算Key-Value字節(jié)數(shù)組總大小,如果不是8的整數(shù)倍,則在補(bǔ)白域存儲一定數(shù)量的0x00字節(jié),使之總大小為8的整數(shù)倍。在讀數(shù)據(jù)時(shí),讀Key和Value后,對Value進(jìn)行校驗(yàn)和計(jì)算,并與校驗(yàn)域存儲的值進(jìn)行比較,如果相當(dāng),則說明讀出的Value是正確的。

圖3 HFile Cell的Key-Value改進(jìn)存儲結(jié)構(gòu)
基于HBase的海量圖片存儲技術(shù)另一個(gè)問題是存儲圖片的大小受到數(shù)據(jù)塊大小的限制。雖然可通過配置將數(shù)據(jù)塊大小調(diào)大,但由于HBase本身設(shè)計(jì),當(dāng)數(shù)據(jù)塊過大時(shí),不適合隨機(jī)讀,從而影響圖片讀取性能。因此數(shù)據(jù)塊不能無限調(diào)大,推薦數(shù)據(jù)塊大不超過1M。可在具體應(yīng)用場景,即使大多圖片在1M以內(nèi),也可能存在少量圖片超過1M,從而需要對基于HBase的海量圖片存儲技術(shù)進(jìn)行改進(jìn)。解決思路是將超過數(shù)據(jù)塊限制的文件進(jìn)行切片,使每片大小小于數(shù)據(jù)塊大小,然后將所有切片進(jìn)行保存。需要設(shè)計(jì)一種機(jī)制來記錄同一圖片的所有切片,并記錄切片的順序,以便恢復(fù)圖片數(shù)據(jù)。分析HFile單元格的Key-Value字節(jié)數(shù)組,發(fā)現(xiàn)里面的TimeStamp結(jié)構(gòu)在圖片存儲時(shí)沒有很好的進(jìn)行利用,且TimeStamp可很好的記錄存儲順序。將圖片的所有切片保存到同樣的RowKey、Family,并按照切片順序逐一保存,HBase會自動打上TimeStamp。如此以來,可根據(jù)RowKey+Family找到同一圖片的所有切片,然后按照每個(gè)切片TimeStamp的時(shí)間順序合并切片,即可恢復(fù)出原始圖片。
三、應(yīng)用效果
某市交通管理部門擬建立一套城市交通監(jiān)控系統(tǒng),在轄區(qū)各路口安裝1500個(gè)攝像頭,對路口交通情況進(jìn)行24小時(shí)監(jiān)控,對通行車輛逐輛拍照。在拍照的同時(shí),借助圖片識別技術(shù)從圖片識別出車輛號牌信息。車輛號牌信息、拍攝時(shí)間、拍攝攝像頭ID等作為圖片元數(shù)據(jù),與圖片一并集中保存到后臺數(shù)據(jù)中心,用于支持對圖片的綜合檢索和分析。在圖片存儲方面。平均每小時(shí)每個(gè)攝像頭拍照300張,每張圖片的大小約為500KB。6個(gè)月的圖片信息所占的容量為0.5MB*300*1500*24*30*6=IPB。考慮到數(shù)據(jù)安全,則需要2.3倍的存儲空間。所需的存儲空間巨大,因此需在保證數(shù)據(jù)安全的前提下,盡可能節(jié)省成本,并支持容量擴(kuò)展。基于改進(jìn)后的HBase海量圖片存儲技術(shù)解決了這個(gè)問題。具體配置如下:HBase Master服務(wù)器。配置16核CPU、64G內(nèi)存、1TB SSD硬盤。2臺Master服務(wù)器實(shí)現(xiàn)高可用,消除無單點(diǎn)故障;HBase HRegion服務(wù)器。配置16核CPU、64G內(nèi)存、1TB SSD硬盤。共用了10臺;HDFS NameNode服務(wù)器。配置16核CPU、64G內(nèi)存、1TB SSD硬盤。共用了2臺,其中一臺作為Secondary NameNode服務(wù)器;HDFS DataNode服務(wù)器。配置4核CPU、16G內(nèi)存、2TB*12 SAS硬盤。共用了85臺;ZooKeeper服務(wù)器。4臺服務(wù)器(2臺HBase Master服務(wù)器、2臺HDFS NameNode服務(wù)器)復(fù)用后作為集群的ZooKeeper服務(wù)器。采用Paxos算法從4臺中推選一臺作為主服務(wù)器,其余3臺作為備用服務(wù)器;核心交換機(jī)2臺,互為熱備。匯聚交換機(jī)6臺,分成3組,兩兩熱備。每臺48口。經(jīng)驗(yàn)證,系統(tǒng)完全滿足需求,實(shí)現(xiàn)預(yù)期目標(biāo),具有如下突出優(yōu)勢;成本節(jié)省。采用分布式存儲,比采用共享存儲方案,成本節(jié)省60%以上;擴(kuò)展性好。元數(shù)據(jù)字段可根據(jù)應(yīng)用情況靈活添加。系統(tǒng)存儲容量、并行處理能力可按需平滑擴(kuò)展;
實(shí)施、管理方便。由HBase后臺處理圖片打包,避免了二次開發(fā)。系統(tǒng)架構(gòu)統(tǒng)一、簡單,易管理維護(hù);智能檢索。支持根據(jù)圖片文件的多個(gè)屬性進(jìn)行綜合檢索;智能糾錯。可自動發(fā)現(xiàn)文件讀寫錯誤,并進(jìn)行糾正。
四、結(jié)束語
本文設(shè)計(jì)并實(shí)現(xiàn)了基于HBase的海量圖片存儲技術(shù)方案,實(shí)現(xiàn)了系統(tǒng)層小文件合并、全局名字空間、并具有良好的通用性;通過對HFile Key-Value字節(jié)數(shù)組結(jié)構(gòu)的完善,實(shí)現(xiàn)了圖片讀取時(shí)的自動糾錯,提高了系統(tǒng)可靠性。系統(tǒng)在某城市監(jiān)控系統(tǒng)的設(shè)計(jì)中得到驗(yàn)證。由于HBase采用分布式B+樹存儲圖片內(nèi)容元數(shù)據(jù),使得讀操作在定位圖片數(shù)據(jù)的時(shí)候必須經(jīng)歷多次網(wǎng)絡(luò)延遲,影響了圖片數(shù)據(jù)的讀取性能,下一步將研究該問題的改進(jìn)方法。
分享文章:一種基于HBase韻海量圖片存儲技術(shù)-創(chuàng)新互聯(lián)
網(wǎng)站網(wǎng)址:http://chinadenli.net/article20/geejo.html
成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián),為您提供網(wǎng)站制作、靜態(tài)網(wǎng)站、營銷型網(wǎng)站建設(shè)、微信小程序、網(wǎng)站維護(hù)、手機(jī)網(wǎng)站建設(shè)
聲明:本網(wǎng)站發(fā)布的內(nèi)容(圖片、視頻和文字)以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主,如果涉及侵權(quán)請盡快告知,我們將會在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載,或轉(zhuǎn)載時(shí)需注明來源: 創(chuàng)新互聯(lián)
猜你還喜歡下面的內(nèi)容