怎么使用HBase優(yōu)化

本篇內(nèi)容介紹了“怎么使用HBase優(yōu)化”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

1. 高可用

在HBase中Hmaster負(fù)責(zé)監(jiān)控RegionServer的生命周期，均衡RegionServer的負(fù)載，如果Hmaster掛掉了，那么整個HBase集群將陷入不健康的狀態(tài)，并且此時的工作狀態(tài)并不會維持太久。所以HBase支持對Hmaster的高可用配置。

1. 關(guān)閉HBase集群（如果沒有開啟則跳過此步）

[atguigu@hadoop102 hbase]$ bin/stop-hbase.sh

2. 在conf目錄下創(chuàng)建backup-masters文件

[atguigu@hadoop102 hbase]$ touch conf/backup-masters

3. 在backup-masters文件中配置高可用HMaster節(jié)點

[atguigu@hadoop102 hbase]$ echo hadoop103 > conf/backup-masters  
將103設(shè)置為備份的master

4. 將整個conf目錄scp到其他節(jié)點

[atguigu@hadoop102 hbase]$ scp -r conf/ hadoop103:/opt/module/hbase/[atguigu@hadoop102 hbase]$ scp -r conf/ hadoop104:/opt/module/hbase/

5. 打開頁面測試查看

http://hadooo102:16010

其中這里面的選舉機制參考zookeeper的選舉功能。

2. 預(yù)分區(qū)(重要)

如果沒有設(shè)置好 分區(qū)規(guī)則 Region Split，就可能出現(xiàn)HBase老版本的時候 10G一份為2，新版本分區(qū)就是按照64,...10G這樣的分區(qū) ，絕對會數(shù)據(jù)傾斜。創(chuàng)建表的時候要設(shè)置好分區(qū)。根據(jù)就是數(shù)據(jù)大小跟機器規(guī)模。參考個 預(yù)分區(qū)技巧

1. 手動設(shè)定預(yù)分區(qū)

create 'staff1','info','partition1',SPLITS => ['1000','2000','3000','4000']

分區(qū)有負(fù)無窮跟正無窮，并且切記是按照rowKey的字符串比較順序來比較的，比如1512123就分到了 1000~2000這個分區(qū)中。但是 40，400這樣的存儲有點別扭，所以rowkey盡量要保證長度一致，高位補零,0040，0400這樣的。

2. 生成16進(jìn)制序列預(yù)分區(qū)

create 'staff2','info','partition2',{
   
   
   NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

這個是按照16進(jìn)制的數(shù)據(jù)來分區(qū)的，

3. 按照文件中設(shè)置的規(guī)則預(yù)分區(qū)

創(chuàng)建splits.txt文件內(nèi)容如下：

aaaa
bbbb
cccc
dddd

然后執(zhí)行：

create 'staff3','partition3',SPLITS_FILE => 'splits.txt'

下面的分區(qū)內(nèi)容不符合哦。

aa
bbddcc

4. API 分區(qū)

hAdmin.createTable(tableDesc); // 默認(rèn)創(chuàng)建表hAdmin.createTable(tableDesc, start,end,numsplit);// 根據(jù)start 跟end 均有分成numsplithAdmin.createTable(tableDesc, splitKeys);//

PS:

在命令行中我們傳入的比如是[100,200,300],，但是HBase底層只認(rèn)識字節(jié)數(shù)組，所以會把數(shù)據(jù)組合成[[],[],[]] 這樣的二維數(shù)組。

//自定義算法，產(chǎn)生一系列Hash散列值存儲在二維數(shù)組中byte[][] splitKeys = 某個散列值函數(shù)//創(chuàng)建HBaseAdmin實例HBaseAdmin hAdmin = new HBaseAdmin(HBaseConfiguration.create());//創(chuàng)建HTableDescriptor實例HTableDescriptor tableDesc = new HTableDescriptor(tableName);//通過HTableDescriptor實例和散列值二維數(shù)組創(chuàng)建帶有預(yù)分區(qū)的HBase表hAdmin.createTable(tableDesc, splitKeys);

3.RowKey設(shè)計(重要)

一條數(shù)據(jù)的唯一標(biāo)識就是rowkey，那么這條數(shù)據(jù)存儲于哪個分區(qū)，取決于rowkey處于哪個一個預(yù)分區(qū)的區(qū)間內(nèi)，設(shè)計rowkey的主要目的 ，就是讓數(shù)據(jù)均勻的分布于所有的region中(散列性，唯一性，長度(生產(chǎn)中甚至可能70~100位))，在一定程度上防止數(shù)據(jù)傾斜。接下來我們就談一談rowkey常用的設(shè)計方案。

1. 生成隨機數(shù)、hash、散列值

原本rowKey為1001的，SHA1后變成：dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey為3001的，SHA1后變成：49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey為5001的，SHA1后變成：7b61dec07e02c188790670af43e717f0f46e8913

在做此操作之前，一般我們會選擇從數(shù)據(jù)集中抽取樣本，來決定什么樣的rowKey來Hash后作
為每個分區(qū)的臨界值。
2. 字符串反轉(zhuǎn)(時間戳翻轉(zhuǎn))

20170524000001轉(zhuǎn)成10000042507102
20170524000002轉(zhuǎn)成20000042507102

這樣也可以在一定程度上散列逐步put進(jìn)來的數(shù)據(jù)。
3. 字符串拼接

20170524000001_a12e
20170524000001_93i7

原則就是遵從 散列性、唯一性、長度。然后根據(jù)實際的業(yè)務(wù)需求來設(shè)定rowkey。

比如分區(qū)一共300個
分區(qū)鍵
000_
001_
002_...
298_

手機號 % 299  分區(qū)位    000_手機號(手機號 + 年月) % 299 尋找分區(qū)  000_手機號_年月
hash(手機號 + 年月) % 299 尋找分區(qū)
總之就是規(guī)劃好分區(qū)，然后把重要的數(shù)據(jù)排在前面。這樣來搞。

4. 內(nèi)存優(yōu)化

HBase操作過程中需要大量的內(nèi)存開銷，畢竟Table是可以緩存在內(nèi)存中的，一般會分配整個可用內(nèi)存的70%給HBase的Java堆。但是不建議分配非常大的堆內(nèi)存，有一個RegionServer級別的刷新，因為GC過程持續(xù)太久會導(dǎo)致RegionServer處于長期不可用狀態(tài)，一般16~48G內(nèi)存就可以了，如果因為框架占用內(nèi)存過高導(dǎo)致系統(tǒng)內(nèi)存不足，框架一樣會被系統(tǒng)服務(wù)拖死。

5. 基礎(chǔ)優(yōu)化

1. 允許在HDFS的文件中追加內(nèi)容

hdfs-site.xml、hbase-site.xml
屬性：dfs.support.append
解釋：開啟HDFS追加同步，可以優(yōu)秀的配合HBase的數(shù)據(jù)同步和持久化。默認(rèn)值為true。

2. 優(yōu)化DataNode允許的最大文件打開數(shù)

hdfs-site.xml
屬性：dfs.datanode.max.transfer.threads
解釋：HBase一般都會同一時間操作大量的文件，根據(jù)集群的數(shù)量和規(guī)模以及數(shù)據(jù)動作，設(shè)置為4096或者更高。默認(rèn)值：4096

3. 優(yōu)化延遲高的數(shù)據(jù)操作的等待時間

hdfs-site.xml
屬性：dfs.image.transfer.timeout
解釋：如果對于某一次數(shù)據(jù)操作來講，延遲非常高，socket需要等待更長的時間，建議把該值設(shè)置為更大的值（默認(rèn)60000毫秒），以確保socket不會被timeout掉。

4. 優(yōu)化數(shù)據(jù)的寫入效率

mapred-site.xml
屬性：
mapreduce.map.output.compress
mapreduce.map.output.compress.codec
解釋：開啟這兩個數(shù)據(jù)可以大大提高文件的寫入效率，減少寫入時間。第一個屬性值修改為true，第二個屬性值修改為：org.apache.hadoop.io.compress.GzipCodec或者其他壓縮方式。

5. 設(shè)置RPC監(jiān)聽數(shù)量

hbase-site.xml
屬性：hbase.regionserver.handler.count
解釋：默認(rèn)值為30，用于指定RPC監(jiān)聽的數(shù)量，可以根據(jù)客戶端的請求數(shù)進(jìn)行調(diào)整，讀寫請求較多時，增加此值。

6. 優(yōu)化HStore文件大小

hbase-site.xml
屬性：hbase.hregion.max.filesize
解釋：默認(rèn)值10737418240（10GB），如果需要運行HBase的MR任務(wù)，可以減小此值，因為一個region對應(yīng)一個map任務(wù)，如果單個region過大，會導(dǎo)致map任務(wù)執(zhí)行時間過長。該值的意思就是，如果HFile的大小達(dá)到這個數(shù)值，則這個region會被切分為兩個Hfile。

7. 優(yōu)化hbase客戶端緩存

hbase-site.xml
屬性：hbase.client.write.buffer
解釋：用于指定HBase客戶端緩存，增大該值可以減少RPC調(diào)用次數(shù)，但是會消耗更多內(nèi)存，反之則反之。一般我們需要設(shè)定一定的緩存大小，以達(dá)到減少RPC次數(shù)的目的。

8. 指定scan.next掃描HBase所獲取的行數(shù)

hbase-site.xml
屬性：hbase.client.scanner.caching
解釋：用于指定scan.next方法獲取的默認(rèn)行數(shù)，值越大，消耗內(nèi)存越大。

9. flush、compact、split機制
   當(dāng)MemStore達(dá)到閾值，將Memstore中的數(shù)據(jù)Flush進(jìn)Storefile；compact機制則是把flush出來的小文件合并成大的Storefile文件。split則是當(dāng)Region達(dá)到閾值，會把過大的Region一分為二。
   涉及屬性：
   即：128M就是Memstore的默認(rèn)閾值

hbase.hregion.memstore.flush.size：134217728

即：這個參數(shù)的作用是當(dāng)單個HRegion內(nèi)所有的Memstore大小總和超過指定值時，flush該HRegion的所有memstore。RegionServer的flush是通過將請求添加一個隊列，模擬生產(chǎn)消費模型來異步處理的。那這里就有一個問題，當(dāng)隊列來不及消費，產(chǎn)生大量積壓請求時，可能會導(dǎo)致內(nèi)存陡增，最壞的情況是觸發(fā)OOM。

hbase.regionserver.global.memstore.upperLimit：0.4
hbase.regionserver.global.memstore.lowerLimit：0.38

即：當(dāng)MemStore使用內(nèi)存總量達(dá)到hbase.regionserver.global.memstore.upperLimit指定值時，將會有多個MemStores flush到文件中，MemStore flush 順序是按照大小降序執(zhí)行的，直到刷新到MemStore使用內(nèi)存略小于lowerLimit

“怎么使用HBase優(yōu)化”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！