1. 程式人生 > >HBase 的MOB壓縮分割槽策略介紹

HBase 的MOB壓縮分割槽策略介紹

       HBase應用場景很廣泛。社群前面有一系列文章。

大家能夠到社群看看看。張少華同學本篇主要講HBase的MOB壓縮分割槽策略介紹,很贊。大力推薦!

  社群系列文章:

新數倉系列:HBase關鍵能力和特性梳理

HBase 和 Cassandra的淺談

新數倉系列:Hbase周邊生態梳理(1)

HBase設計之rowkey設計



 

介紹

HBase中等物件(MOB---MediumObject)儲存特性引入是源自社群HBASE-11339

對於中等大小的文件、影象等檔案的儲存(檔案大小從100K

到10MB)。可降低讀取延遲和寫入訪問時間[1]。

通過分離檔案的IO路徑和MOB檔案物件。對檔案採取不同的壓縮策略,從而降低因為HBase壓縮造成的寫入擴大。

若一個表的MOB檔案儲存在MOB區域(MOB region)中,則意味著該區域中將存在大量的MOB檔案。請參考下圖中HBase MOB架構。


640?wx_fmt=png&wxfrom=5&wx_lazy=1

MOB體系結構

 

從上圖我們能夠看出MOB檔案相對較小(小於1或者2個HDFS塊)。為了提高HDFS的效率。通過MOB壓縮方法將MOB檔案定期合併為較大的檔案,而且這樣的壓縮方法與正常的壓縮過程相互獨立。MOB壓縮最初是將當天多個

MOB檔案合併為較大的MOB檔案。通過以下演示樣例我們能夠更清楚瞭解這一過程。表t1有兩個兩個分割槽(r1,r2),一個列族f1,而且啟用了MOB功能。

你能夠看到例如以下兩個字首:

D279186428a75016b17e4df5ea43d080  相應分割槽r1startkey的雜湊值

D41d8cd98f00b204e9800998ecf8427e  相應分割槽r2startkey的雜湊值

 

MOB區域中,從2016.1.1-2016.1.2。r1分割槽中每天有兩個MOB檔案。2016.1.1當天。分割槽r2中有三個MOB檔案

通過MOB

壓縮後,r1r2分割槽中同一日期的檔案合併為一個檔案,例如以下:

640?</p><p>wx_fmt=png


因為僅僅有在同一區而且為同一天的MOB檔案才可壓縮。因此在一個MOB區域中的資料夾下一年產生的MOB檔案數量為365乘以分割槽數目。若有1000個分割槽,通過MOB壓縮,10年後將會有365 x 1000 x 10,3.65(百萬)個檔案產生而且檔案數量會一直增長。可是,因為HDFS中一個資料夾下檔案儲存受限[2]。若MOB檔案數超過HDFS限制後。MOB表將不再可寫入檔案。HDFS的一個資料夾下預設的最大檔案數為100萬,那麼對於1000個分割槽來說,檔案儲存數目將在3年左右達到這個極限值。

分割槽越多,最大檔案數會越快達到這個極限。

 

HBASE-16981引入按周和月的MOB壓縮分割槽策略。對此MOB檔案存放比例相應提高了7%和30%。

HBASE-16981基本思路是將一週或者一個月的MOB檔案壓縮合併為更大的檔案。

依據ISO8601定義的周(起始為週一結束為週日),若採用周策略進行MOB壓縮後,則每一個分割槽每週會產生一個檔案,同理,用壓縮方法按月壓縮,每月會生成一個檔案,終於在一個MOB區域資料夾下的檔案數分別為52 乘以分割槽數和12乘以分割槽數。這樣就大大降低了壓縮後MOB檔案的數量。

 

最初的方法

 

依據MOB壓縮發生的頻率,檔案可能多次被壓縮。比如。第一天全部的MOB檔案被壓縮為一個檔案。第二天將第一天和第二天的MOB檔案壓縮為一個新的檔案,第三天將第二天和第三天產生的檔案壓縮為一個新檔案。以此類推,一個月後,第1天的檔案壓縮會超過30次,因此也就將寫的IO數量擴大了30倍以上。

HBase MOB的設計目標是降低因為MOB壓縮而導致的寫入擴大。上述的這樣的方法沒能達到設計目標。

 

終於的方法

為了克服最初提出方案的不足,在HBASE-16981中採用了新的按周和月壓縮策略。

圖2展示了怎樣按月壓縮策略。同一時候按周壓縮策略與此相似。

640?wx_fmt=png

圖2 按月MOB壓縮策略

 

圖2所看到的的MOB壓縮發生在2016.11.15。

依據配置的MOB閾值,每日分割槽中的檔案按周進行壓縮。上圖中11.14和11.15的兩天的檔案各自壓縮。

當前月份(11月)中過去的幾周的檔案基於每週閾值分割槽進行壓縮(MOB閾值 x 7)。如11.1-11.6和11.7-11.13的檔案分別壓縮。11月之前的檔案按月進行壓縮,比如10.1-10.31檔案壓縮在一起。須要注意的是11月的第一週是從10.31-11.6結束。

因為2016.10.31是10月的最後一天。因此當天的檔案壓縮是依照月分割槽進行壓縮,這樣11月的第一週壓縮的天數僅僅剩下6天(11.1-11.6),假設MOB壓縮閾值和壓縮大小設定合理,那麼第一週會有5個壓縮檔案。

 

通過這樣的設計模式,MOB檔案能夠通過2個階段或3個階段完畢壓縮。在每一個階段,日、周、月分割槽都會隨著MOB壓縮閾值的新增而變化。通常情況下。MOB檔案按月最多3次壓縮,按周最多壓縮2次。

具體的設計細節能夠參考[3]。

 

使用方法

在預設情況下。MOB壓縮分割槽策略是每日一次。

若要用周或月策略,能夠在MOB列族中加入了一個新屬性欄位:MOB_COMPACT_PARTITION_POLICY。使用者可通過HBase shell建立表時設定該屬性。比如:

640?wx_fmt=png


同一時候也能夠改變該屬性欄位值

640?wx_fmt=png

假設壓縮策略從每日改為每週或每月,或從每週改為每月。則下一個MOB壓縮將又一次壓縮之前壓縮的MOB檔案。假設策略從每月或每週改為每日或每月更新。則對已使用先前策略壓縮的MOB檔案將不會與新策略再次執行壓縮。

 

結束語

HBASE-16981攻克了檔案數大量新增的問題。並在Apache HBase 2.0.0版本號中使用。CDHCDH5.4.0+及以後的版本號開始使用HBase MOB特性。當中從5.11.0開始使用HBASE-16981修復的版本號。

 

因為譯者水平有限,有翻譯不當之處還請大大家多多指出。互相學習。

 

參考

[1]https://blog.cloudera.com/blog/2015/06/inside-apache-hbases-new-support-for-MOBs/

[2] https://blog.cloudera.com/blog/2009/02/the-small-files-problem/

[3] https://issues.apache.org/jira/browse/HBASE-16981

原文地址:http://blog.cloudera.com/blog/2017/06/introducing-apache-hbase-medium-object-storage-MOB-compaction-partition-policies/#/


 

猜你喜歡




#大資料和雲端計算機技術社群#部落格精選(2017)

猜一猜全球未來5朵雲會是誰?

NoSQL 還是 SQL ?這一篇講清楚

阿里的OceanBase解密

#大資料和雲端計算技術#: "四有"社群介紹

大資料和雲端計算技術週報(第33期)

新數倉系列:Hbase周邊生態梳理(1)

《大資料架構具體解釋》第2次修訂說明

雲觀察系列:漫談運營商公有云發展史

雲觀察系列:百度雲的一波三折

雲觀察系列:阿里雲戰略觀察

超融合方案分析系列(7)思科超融合方案分析

加入技術討論群




《大資料和雲端計算技術》社群群人數已經3000+,歡迎大家加以下助手微信。拉大家進群。自由交流。

640?</p><p>wx_fmt=jpeg

喜歡釘釘掃碼以下的群:

640?wx_fmt=jpeg

喜歡QQ群的。能夠掃描以下二維碼:

640?</p><p>wx_fmt=jpeg

歡迎大家通過二維碼打賞支援技術社群(英雄請留名。社群感謝您,打賞次數超過108+):

640?</p><p>wx_fmt=jpeg