針對海量圖片存儲，已有若干個基于Hadoop的方案被設(shè)計出來。這些方案在系統(tǒng)層小文件合并、全局名字空間以及通用性方面存在不足。本文基于HBase提出了一種海量圖片存儲技術(shù)，成功解決了上述問題。本文將介紹基于HBase海量圖片存儲技術(shù)方案，分析其原理及優(yōu)勢，該方案在城市交通監(jiān)控中得到應(yīng)用驗證。

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

成都創(chuàng)新互聯(lián)公司 - 中國電信云錦天府，四川服務(wù)器租用，成都服務(wù)器租用，四川網(wǎng)通托管,綿陽服務(wù)器托管，德陽服務(wù)器托管，遂寧服務(wù)器托管，綿陽服務(wù)器托管，四川云主機，成都云主機，西南云主機，中國電信云錦天府，西南服務(wù)器托管，四川/成都大帶寬，機柜大帶寬租用·托管，四川老牌ＩＤＣ服務(wù)商

   為了解決HDFS在小文件存儲方面的問題，通常的做法是先將很多小文件合并成一個大文件再保存到HDFS，同時為這些小文件建立索引，以便進行快速存取。典型技術(shù)包括Hadoop自帶的Archive、SequenceFile，但均需要用戶自己編寫程序，實現(xiàn)小文件的合并。為了實現(xiàn)小文件合并對用戶的透明，需從系統(tǒng)層面解決HDFS小文件問題。論文針對具體應(yīng)用場景進行了探索，但不具有通用性。與前面方案不改變HDFS本身不同，淘寶TFS對HDFS的元數(shù)據(jù)存儲架構(gòu)進行了調(diào)整。在元數(shù)據(jù)節(jié)點僅存放數(shù)據(jù)塊與數(shù)據(jù)節(jié)點的映射，而將文件與數(shù)據(jù)塊的映射關(guān)系保存到文件名，不再需要在元數(shù)據(jù)節(jié)點同時存放這兩類映射，最終實現(xiàn)了系統(tǒng)層面解決小文件問題。但由于文件名包含數(shù)據(jù)塊信息，為文件和數(shù)據(jù)塊建立了強關(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ù)，并針對其問題給出改進方法。本文第1部分介紹了基于HBase的海量圖片存儲技術(shù)方案，并分析了原理及優(yōu)勢。第2部分介紹了該方案存在的問題及改進方法。第3部介紹了改進后方案的應(yīng)用效果。第4部分總結(jié)全文，并指明下一步工作。

   一、基于HBase的海量圖片存儲技術(shù)

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

表1：基于HBase的海量圖片存儲技術(shù)的大表設(shè)計

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

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

代碼1：用HCoIumnDescriptor將數(shù)據(jù)塊限制調(diào)整為512KB

圖1 配置代碼

   上述基于HBase的海量圖片存儲技術(shù)具有如下優(yōu)點：

   (1)通過將圖片屬性信息與圖片內(nèi)容存儲到一個大表中，可支持圖片的多屬性綜合查詢。此外，還可以根據(jù)應(yīng)用需求，對列簇進行擴展以保存應(yīng)用相關(guān)信息，從而支持應(yīng)用相關(guān)的圖片查詢?？梢?，基于HBase的海量圖片存儲技術(shù)不僅解決了圖片存儲，還實現(xiàn)了靈活的圖片檢索。

   (2)HBase隱含了小文件打包過程，無需進行二次開發(fā)即實現(xiàn)了系統(tǒng)層小文件合并。

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

   二、基于HBase的海量圖片存儲技術(shù)存在問題及改進方法

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

圖2 HFile Cell的Key-Value存儲結(jié)構(gòu)

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

圖3 HFile Cell的Key-Value改進存儲結(jié)構(gòu)

   基于HBase的海量圖片存儲技術(shù)另一個問題是存儲圖片的大小受到數(shù)據(jù)塊大小的限制。雖然可通過配置將數(shù)據(jù)塊大小調(diào)大，但由于HBase本身設(shè)計，當數(shù)據(jù)塊過大時，不適合隨機讀，從而影響圖片讀取性能。因此數(shù)據(jù)塊不能無限調(diào)大，推薦數(shù)據(jù)塊大不超過1M?？稍诰唧w應(yīng)用場景，即使大多圖片在1M以內(nèi)，也可能存在少量圖片超過1M，從而需要對基于HBase的海量圖片存儲技術(shù)進行改進。解決思路是將超過數(shù)據(jù)塊限制的文件進行切片，使每片大小小于數(shù)據(jù)塊大小，然后將所有切片進行保存。需要設(shè)計一種機制來記錄同一圖片的所有切片，并記錄切片的順序，以便恢復(fù)圖片數(shù)據(jù)。分析HFile單元格的Key-Value字節(jié)數(shù)組，發(fā)現(xiàn)里面的TimeStamp結(jié)構(gòu)在圖片存儲時沒有很好的進行利用，且TimeStamp可很好的記錄存儲順序。將圖片的所有切片保存到同樣的RowKey、Family，并按照切片順序逐一保存，HBase會自動打上TimeStamp。如此以來，可根據(jù)RowKey+Family找到同一圖片的所有切片，然后按照每個切片TimeStamp的時間順序合并切片，即可恢復(fù)出原始圖片。

   三、應(yīng)用效果

   某市交通管理部門擬建立一套城市交通監(jiān)控系統(tǒng)，在轄區(qū)各路口安裝1500個攝像頭，對路口交通情況進行24小時監(jiān)控，對通行車輛逐輛拍照。在拍照的同時，借助圖片識別技術(shù)從圖片識別出車輛號牌信息。車輛號牌信息、拍攝時間、拍攝攝像頭ID等作為圖片元數(shù)據(jù)，與圖片一并集中保存到后臺數(shù)據(jù)中心，用于支持對圖片的綜合檢索和分析。在圖片存儲方面。平均每小時每個攝像頭拍照300張，每張圖片的大小約為500KB。6個月的圖片信息所占的容量為0.5MB*300*1500*24*30*6=IPB?？紤]到數(shù)據(jù)安全，則需要2．3倍的存儲空間。所需的存儲空間巨大，因此需在保證數(shù)據(jù)安全的前提下，盡可能節(jié)省成本，并支持容量擴展。基于改進后的HBase海量圖片存儲技術(shù)解決了這個問題。具體配置如下：HBase Master服務(wù)器。配置16核CPU、64G內(nèi)存、1TB SSD硬盤。2臺Master服務(wù)器實現(xià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ù)器；核心交換機2臺，互為熱備。匯聚交換機6臺，分成3組，兩兩熱備。每臺48口。經(jīng)驗證，系統(tǒng)完全滿足需求，實現(xiàn)預(yù)期目標，具有如下突出優(yōu)勢；成本節(jié)省。采用分布式存儲，比采用共享存儲方案，成本節(jié)省60%以上；擴展性好。元數(shù)據(jù)字段可根據(jù)應(yīng)用情況靈活添加。系統(tǒng)存儲容量、并行處理能力可按需平滑擴展；

   實施、管理方便。由HBase后臺處理圖片打包，避免了二次開發(fā)。系統(tǒng)架構(gòu)統(tǒng)一、簡單，易管理維護；智能檢索。支持根據(jù)圖片文件的多個屬性進行綜合檢索；智能糾錯?？勺詣影l(fā)現(xiàn)文件讀寫錯誤，并進行糾正。

   四、結(jié)束語

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

分享文章：一種基于HBase韻海量圖片存儲技術(shù)-創(chuàng)新互聯(lián)
網(wǎng)站網(wǎng)址：http://www.rwnh.cn/article20/geejo.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站制作、靜態(tài)網(wǎng)站、營銷型網(wǎng)站建設(shè)、微信小程序、網(wǎng)站維護、手機網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)