HBase快速入門系列(9) | HBase優化

  大家好,我是不溫卜火,是一名計算機學院大數據專業大二的學生,暱稱來源於成語—不溫不火,本意是希望自己性情溫和。作爲一名互聯網行業的小白,博主寫博客一方面是爲了記錄自己的學習過程,另一方面是總結自己所犯的錯誤希望能夠幫助到很多和自己一樣處於起步階段的萌新。但由於水平有限,博客中難免會有一些錯誤出現,有紕漏之處懇請各位大佬不吝賜教!暫時只有csdn這一個平臺,博客主頁:https://buwenbuhuo.blog.csdn.net/

  此篇爲大家帶來的是HBase優化。


標註:
此處爲反爬蟲標記:讀者可自行忽略

20
原文地址:https://buwenbuhuo.blog.csdn.net/

1. HBase HA(高可用)

  在HBase中Hmaster負責監控RegionServer的生命週期,均衡RegionServer的負載,如果Hmaster掛掉了,那麼整個HBase集羣將陷入不健康的狀態,並且此時的工作狀態並不會維持太久。所以HBase支持對Hmaster的高可用配置。

  • 1. 關閉HBase集羣(如果沒有開啓則跳過此步)
[bigdata@hadoop002 hbase]$ bin/stop-hbase.sh 
  • 2. 在conf目錄下創建backup-masters文件(要整個集羣都有)
[bigdata@hadoop002 conf]$ vim backup-masters

// 想讓誰稱爲備用機就填誰
hadoop003
  • 3. 將整個conf目錄scp到其他節點
[bigdata@hadoop002 hbase]$ scp -r conf/ hadoop003:/opt/module/hbase/
[bigdata@hadoop002 hbase]$ scp -r conf/ hadoop004:/opt/module/hbase/

  • 4. 啓動測試
[bigdata@hadoop002 hbase]$ bin/start-hbase.sh 

1
http://hadooo002:16010
2

2. 預分區

  每一個region維護着startRow與endRowKey,如果加入的數據符合某個region維護的rowKey範圍,則該數據交給這個region維護。那麼依照這個原則,我們可以將數據所要投放的分區提前大致的規劃好,以提高HBase性能。

  • 1. 手動設定預分區
// 分區鍵 SPLITS
hbase> create 'staff','info','partition',SPLITS => ['1000','2000','3000']

  查看分區情況(web)
3

  • 2. 生成16進制序列預分區
// 指定分區自動生成分區
hbase> create 'staff1','info',{NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}

  查看分區情況(web)
4
  放入一條數據

hbase(main):003:0> put 'staff1','abc','info:name','101010'

5

  • 3. 按照文件中設置的規則預分區

① 創建splits.txt文件內容如下:

[bigdata@hadoop002 hbase]$ vim split.txt

// 下列爲分區鍵
aaaa
bbbb
cccc
dddd

② 然後執行

hbase(main):005:0> create 'staff2','partition2',SPLITS_FILE => './split.txt'

6

  • 4. 使用JavaAPI創建預分區
    public static void main(String[] args) throws IOException {
        Admin admin = connection.getAdmin();

        byte[][] splitKeys = new byte[3][];

        splitKeys[0]=Bytes.toBytes("1000");
        splitKeys[1]=Bytes.toBytes("2000");
        splitKeys[2]=Bytes.toBytes("3000");

        HTableDescriptor desc = new HTableDescriptor(TableName.valueOf("staff3"));

        desc.addFamily(new HColumnDescriptor("info"));

        admin.createTable(desc,splitKeys);

        admin.close();

    }

7
8
9

3. RowKey設計

  一條數據的唯一標識就是rowkey,那麼這條數據存儲於哪個分區,取決於rowkey處於哪個一個預分區的區間內,設計rowkey的主要目的 ,就是讓數據均勻的分佈於所有的region中,在一定程度上防止數據傾斜。接下來我們就談一談rowkey常用的設計方案。

  • 1. 生成隨機數、hash、散列值
比如:
原本rowKey爲1001的,SHA1後變成:dd01903921ea24941c26a48f2cec24e0bb0e8cc7
原本rowKey爲3001的,SHA1後變成:49042c54de64a1e9bf0b33e00245660ef92dc7bd
原本rowKey爲5001的,SHA1後變成:7b61dec07e02c188790670af43e717f0f46e8913
在做此操作之前,一般我們會選擇從數據集中抽取樣本,來決定什麼樣的rowKey來Hash後作爲每個分區的臨界值。

  • 2. 字符串反轉
20170524000001轉成10000042507102
20170524000002轉成20000042507102

// 這樣也可以在一定程度上散列逐步put進來的數據。
  • 3. 字符串拼接
20170524000001_a12e
20170524000001_93i7

4. 內存優化

  HBase操作過程中需要大量的內存開銷,畢竟Table是可以緩存在內存中的,一般會分配整個可用內存的70%給HBase的Java堆。但是不建議分配非常大的堆內存,因爲GC過程持續太久會導致RegionServer處於長期不可用狀態,一般16~48G內存就可以了,如果因爲框架佔用內存過高導致系統內存不足,框架一樣會被系統服務拖死。

5. 基礎優化

  • 1. 允許在HDFS的文件中追加內容

hdfs-site.xml、hbase-site.xml
屬性:dfs.support.append
解釋:開啓HDFS追加同步,可以優秀的配合HBase的數據同步和持久化。默認值爲true。

  • 2. 優化DataNode允許的最大文件打開數

hdfs-site.xml
屬性:dfs.datanode.max.transfer.threads
解釋:HBase一般都會同一時間操作大量的文件,根據集羣的數量和規模以及數據動作,設置爲4096或者更高。默認值:4096

  • 3. 優化延遲高的數據操作的等待時間

hdfs-site.xml
屬性:dfs.image.transfer.timeout
解釋:如果對於某一次數據操作來講,延遲非常高,socket需要等待更長的時間,建議把該值設置爲更大的值(默認60000毫秒),以確保socket不會被timeout掉。

  • 4. 優化數據的寫入效率

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

  • 5. 設置RPC監聽數量

hbase-site.xml
屬性:hbase.regionserver.handler.count
解釋:默認值爲30,用於指定RPC監聽的數量,可以根據客戶端的請求數進行調整,讀寫請求較多時,增加此值。

  • 6. 優化HStore文件大小

hbase-site.xml
屬性:hbase.hregion.max.filesize
解釋:默認值10737418240(10GB),如果需要運行HBase的MR任務,可以減小此值,因爲一個region對應一個map任務,如果單個region過大,會導致map任務執行時間過長。該值的意思就是,如果HFile的大小達到這個數值,則這個region會被切分爲兩個Hfile。

  • 7. 優化hbase客戶端緩存

hbase-site.xml
屬性:hbase.client.write.buffer
解釋:用於指定HBase客戶端緩存,增大該值可以減少RPC調用次數,但是會消耗更多內存,反之則反之。一般我們需要設定一定的緩存大小,以達到減少RPC次數的目的。

  • 8. 指定scan.next掃描HBase所獲取的行數

hbase-site.xml
屬性:hbase.client.scanner.caching
解釋:用於指定scan.next方法獲取的默認行數,值越大,消耗內存越大。

  • 9. flush、compact、split機制

  當MemStore達到閾值,將Memstore中的數據Flush進Storefile;compact機制則是把flush出來的小文件合併成大的Storefile文件。split則是當Region達到閾值,會把過大的Region一分爲二。
涉及屬性:
即:128M就是Memstore的默認閾值

hbase.hregion.memstore.flush.size:134217728

  即:這個參數的作用是當單個HRegion內所有的Memstore大小總和超過指定值時,flush該HRegion的所有memstore。RegionServer的flush是通過將請求添加一個隊列,模擬生產消費模型來異步處理的。那這裏就有一個問題,當隊列來不及消費,產生大量積壓請求時,可能會導致內存陡增,最壞的情況是觸發OOM。

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

  即:當MemStore使用內存總量達到hbase.regionserver.global.memstore.upperLimit指定值時,將會有多個MemStores flush到文件中,MemStore flush 順序是按照大小降序執行的,直到刷新到MemStore使用內存略小於lowerLimit

  本次的分享就到這裏了,


11

  好書不厭讀百回,熟讀課思子自知。而我想要成爲全場最靚的仔,就必須堅持通過學習來獲取更多知識,用知識改變命運,用博客見證成長,用行動證明我在努力。
  如果我的博客對你有幫助、如果你喜歡我的博客內容,請“點贊” “評論”“收藏”一鍵三連哦!聽說點讚的人運氣不會太差,每一天都會元氣滿滿呦!如果實在要白嫖的話,那祝你開心每一天,歡迎常來我博客看看。
  碼字不易,大家的支持就是我堅持下去的動力。點贊後不要忘了關注我哦!

13
12

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章