隨著互聯網、雲計算及大數據等信息技術的發展，越來越多的應用依賴於對海量數據的存儲和處理，如智能監控、電子商務、地理信息等，這些應用都需要對海量圖片的存儲和檢索。由於圖片大多是小文件(80%大小在數MB以內)，以GFS、HDFS為代表的適用於流式訪問大文件的分布式存儲系統，若直接用來存儲圖片，由於元數據膨脹，在擴展性和性能方面均存在嚴重問題。

為了解決HDFS在小文件存儲方面的問題，通常的做法是先將很多小文件合並成一個大文件再保存到HDFS，同時為這些小文件建立索引，以便進行快速存取。典型技術包括Hadoop自帶的Archive、SequenceFile，但均需要用戶自己編寫程序，實現小文件的合並。為了實現小文件合並對用戶的透明，需從系統層面解決HDFS小文件問題。論文針對具體應用場景進行了探索，但不具有通用性。與前面方案不改變HDFS本身不同，淘寶TFS對HDFS的元數據存儲架構進行了調整。在元數據節點僅存放數據塊與數據節點的映射，而將文件與數據塊的映射關系保存到文件名，不再需要在元數據節點同時存放這兩類映射，最終實現了系統層面解決小文件問題。但由於文件名包含數據塊信息，為文件和數據塊建立了強關系，導致數據塊使用僵硬，TFS在文件的命名、移動方面帶來新的問題，限制了其應用場景。

HBase是基於HDFS的簡單結構化數據分布式存儲技術，其可被用來存儲海量圖片小文件，並具有系統層小文件合並、全局名字空間等多種優勢。但基於HBase的海量圖片存儲技術也存在一些問題。本文將介紹基於HBase的海量圖片存儲技術，並針對其問題給出改進方法。本文第1部分介紹了基於HBase的海量圖片存儲技術方案，並分析了原理及優勢。第2部分介紹了該方案存在的問題及改進方法。第3部介紹了改進後方案的應用效果。第4部分總結全文，並指明下一步工作。

1. 基於HBase的海量圖片存儲技術

Google利用BigTable來存儲網頁快照及屬性信息，來支持網頁搜索。受此啟發，在HBase中用同樣的方法來存儲圖片及其屬性信息。具體方法即建立一張大表，用一個單獨的列簇存儲圖片內容，用其他列簇存儲圖片的類型、大小、創建時間、修改時間等標準屬性及應用相關的屬性信息。HBase的列簇劃分除了考慮邏輯關系外，還需考慮數據類型，即將邏輯關系相近且數據類型相同的作為一個列簇。大表的具體設計如表1所示。

表1：基於HBase的海量圖片存儲技術的大表設計

HBase是采用面向列的存儲模型，按列簇來存儲和處理數據，即同一列簇的數據會連續存儲。HBase在存儲每個列簇時，會以Key-Value的方式來存儲每行單元格(Cell)中的數據，形成若幹數據塊，然後把數據塊保存到HFile中，最後把HFile保存到後臺的HDFS上。由於用單元格(Cell)存儲圖片小文件的內容，上述存儲數據的過程實際上隱含了把圖片小文件打包的過程。

搭建HBase集群後，采用上面設計的大表即可存儲海量圖片。但由於HBase存在數據塊限制，還需要根據應用進行調整。默認情況下，HBase數據塊限制為64KB。由於圖片內容作為單元格(Cell)的值保存，其大小受制於數據塊的大小。在應用中需根據最大圖片大小對HBase數據塊大小進行修改。具體修改方法是在表創建時，用HColumnDescriptor指定數據塊大小，可分列簇指定，具體配置代碼如下。

代碼1：用HCoIumnDescriptor將數據塊限制調整為512KB

圖1 配置代碼

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

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

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

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

2. 基於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部分是純粹的二進制數據。

圖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是正確的。

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

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

3. 應用效果

某市交通管理部門擬建立一套城市交通監控系統，在轄區各路口安裝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後臺處理圖片打包，避免了二次開發。系統架構統一、簡單，易管理維護；智能檢索。支持根據圖片文件的多個屬性進行綜合檢索；智能糾錯。可自動發現文件讀寫錯誤，並進行糾正。

4. 結束語

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

參考：https://blog.csdn.net/u010670689/article/details/33737989

HBase解決海量圖片存儲方案