一種基于HBase韻海量圖片存儲技術-創(chuàng)新互聯(lián)

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

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

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

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

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

   一、基于HBase的海量圖片存儲技術

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

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

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

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

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

圖1 配置代碼

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

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

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

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

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

   基于HBase的海量圖片存儲技術雖有上述優(yōu)點，但也存在一些問題。為了說明問題，首先分析HBase中圖片數(shù)據(jù)的存儲結構。在基于HBase的海量圖片存儲技術中，圖片內容數(shù)據(jù)1)2Key-Value的方式進行保存，每個Key-Value對就是一個簡單的字節(jié)數(shù)組。這個字節(jié)數(shù)組里面包含了很多項，并且有固定的結構，如圖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存儲結構

   可見，(1)無校驗碼設計，導致存儲圖片數(shù)據(jù)的正確性無法驗證；(2)Key-Value字節(jié)數(shù)組沒有進行對齊，影響讀寫效率。為了解決此兩個問題，需對Key-Value存儲結構進行完善，在Valu域部分后面增加校驗和及補白兩個域。校驗和為8個字節(jié)(64位)。通過補白部分，使每個Key-Value字節(jié)數(shù)組大小為8字節(jié)的整數(shù)倍，從而更加適合64位系統(tǒng)，如圖3所示。做了上述調整后，在讀寫數(shù)據(jù)時都要進行相應改變。在寫數(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改進存儲結構

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

   三、應用效果

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

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

   四、結束語

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

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

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

廣告

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