Hbase解決海量圖片存儲

Hbase解決海量圖片存儲


Hbase解決海量圖片存儲


圖1 配置代碼

上述基於HBase的海量圖片存儲技術具有如下優點:

(1)通過將圖片屬性信息與圖片內容存儲到一個大表中,可支持圖片的多屬性綜合查詢。此外,還可以根據應用需求,對列簇進行擴展以保存應用相關信息,從而支持應用相關的圖片查詢。可見,基於HBase的海量圖片存儲技術不僅解決了圖片存儲,還實現了靈活的圖片檢索。

(2)HBase隱含了小文件打包過程,無需進行二次開發即實現了系統層小文件合併。

(3)HBase採用分佈式B+樹對圖片元數據進行全局統一管理,實現了全局名字空間,方便了對圖片的管理。

二、基於HBase的海量圖片存儲技術存在問題及改進方法

基於HBase的海量圖片存儲技術雖有上述優點,但也存在一些問題。為了說明問題,首先分析HBase中圖片數據的存儲結構。在基於HBase的海量圖片存儲技術中,圖片內容數據1)2Key-Value的方式進行保存,每個Key-Value對就是一個簡單的字節數組。這個字節數組裡麵包含了很多項,並且有固定的結構,如圖2所示。開始是兩個固定長度的數值,分別表示Key的長度和Value的長度。緊接著是Key部分,在這一部分開始是一個固定長度的數值,表示RowKey的長度,接著是RowKey,然後是固定長度的數值,表示Family的長度,然後是Family,接著是Qualifier,然後是兩個固定長度的數值,表示Time Stamp和Key Type(Put/Delete)。Value部分是純粹的二進制數據。


Hbase解決海量圖片存儲


Hbase解決海量圖片存儲


圖2 HFile Cell的Key-Value存儲結構

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


Hbase解決海量圖片存儲


Hbase解決海量圖片存儲


圖3 HFile Cell的Key-Value改進存儲結構

基於HBase的海量圖片存儲技術另一個問題是存儲圖片的大小受到數據塊大小的限制。雖然可通過配置將數據塊大小調大,但由於HBase本身設計,當數據塊過大時,不適合隨機讀,從而影響圖片讀取性能。因此數據塊不能無限調大,推薦數據塊最大不超過1M。可在具體應用場景,即使大多圖片在1M以內,也可能存在少量圖片超過1M,從而需要對基於HBase的海量圖片存儲技術進行改進。解決思路是將超過數據塊限制的文件進行切片,使每片大小小於數據塊大小,然後將所有切片進行保存。需要設計一種機制來記錄同一圖片的所有切片,並記錄切片的順序,以便恢復圖片數據。分析HFile單元格的Key-Value字節數組,發現裡面的TimeStamp結構在圖片存儲時沒有很好的進行利用,且TimeStamp可很好的記錄存儲順序。將圖片的所有切片保存到同樣的RowKey、Family,並按照切片順序逐一保存,HBase會自動打上TimeStamp。如此以來,可根據RowKey+Family找到同一圖片的所有切片,然後按照每個切片TimeStamp的時間順序合併切片,即可恢復出原始圖片。

三、應用效果

某市交通管理部門擬建立一套城市交通監控系統,在轄區各路口安裝1500個攝像頭,對路口交通情況進行24小時監控,對通行車輛逐輛拍照。在拍照的同時,藉助圖片識別技術從圖片識別出車輛號牌信息。車輛號牌信息、拍攝時間、拍攝攝像頭ID等作為圖片元數據,與圖片一併集中保存到後臺數據中心,用於支持對圖片的綜合檢索和分析。在圖片存儲方面。平均每小時每個攝像頭拍照300張,每張圖片的大小約為500KB。6個月的圖片信息所佔的容量為0.5MB*300*1500*24*30*6=IPB。考慮到數據安全,則需要2.3倍的存儲空間。所需的存儲空間巨大,因此需在保證數據安全的前提下,儘可能節省成本,並支持容量擴展。基於改進後的HBase海量圖片存儲技術解決了這個問題。具體配置如下:HBase Master服務器。配置16核CPU、64G內存、1TB SSD硬盤。2臺Master服務器實現高可用,消除無單點故障;HBase HRegion服務器。配置16核CPU、64G內存、1TB SSD硬盤。共用了10臺;HDFS NameNode服務器。配置16核CPU、64G內存、1TB SSD硬盤。共用了2臺,其中一臺作為Secondary NameNode服務器;HDFS DataNode服務器。配置4核CPU、16G內存、2TB*12 SAS硬盤。共用了85臺;ZooKeeper服務器。4臺服務器(2臺HBase Master服務器、2臺HDFS NameNode服務器)複用後作為集群的ZooKeeper服務器。採用Paxos算法從4臺中推選一臺作為主服務器,其餘3臺作為備用服務器;核心交換機2臺,互為熱備。匯聚交換機6臺,分成3組,兩兩熱備。每臺48口。經驗證,系統完全滿足需求,實現預期目標,具有如下突出優勢;成本節省。採用分佈式存儲,比採用共享存儲方案,成本節省60%以上;擴展性好。元數據字段可根據應用情況靈活添加。系統存儲容量、並行處理能力可按需平滑擴展;

實施、管理方便。由HBase後臺處理圖片打包,避免了二次開發。系統架構統一、簡單,易管理維護;智能檢索。支持根據圖片文件的多個屬性進行綜合檢索;智能糾錯。可自動發現文件讀寫錯誤,並進行糾正。

四、結束語

本文設計並實現了基於HBase的海量圖片存儲技術方案,實現了系統層小文件合併、全局名字空間、並具有良好的通用性;通過對HFile Key-Value字節數組結構的完善,實現了圖片讀取時的自動糾錯,提高了系統可靠性。系統在某城市監控系統的設計中得到驗證。由於HBase採用分佈式B+樹存儲圖片內容元數據,使得讀操作在定位圖片數據的時候必須經歷多次網絡延遲,影響了圖片數據的讀取性能,下一步將研究該問題的改進方法。

Hbase解決海量圖片存儲

【1】想了解大數據知識,可以關注我下方評論轉發後,私信“資料”。

【2】部分資料有時間限制,抓緊時間吧!

感謝大家支持!


分享到:


相關文章: