您好,登錄后才能下訂單哦!
本篇內容介紹了“怎么使用HBase優化”的有關知識,在實際案例的操作過程中,不少人都會遇到這樣的困境,接下來就讓小編帶領大家學習一下如何處理這些情況吧!希望大家仔細閱讀,能夠學有所成!
在HBase中Hmaster
負責監控RegionServer
的生命周期,均衡RegionServer
的負載,如果Hmaster掛掉了,那么整個HBase集群將陷入不健康的狀態,并且此時的工作狀態并不會維持太久。所以HBase支持對Hmaster的高可用配置。
關閉HBase集群(如果沒有開啟則跳過此步)
[atguigu@hadoop102 hbase]$ bin/stop-hbase.sh
在conf目錄下創建backup-masters文件
[atguigu@hadoop102 hbase]$ touch conf/backup-masters
在backup-masters文件中配置高可用HMaster節點
[atguigu@hadoop102 hbase]$ echo hadoop103 > conf/backup-masters 將103設置為備份的master
將整個conf目錄scp到其他節點
[atguigu@hadoop102 hbase]$ scp -r conf/ hadoop103:/opt/module/hbase/[atguigu@hadoop102 hbase]$ scp -r conf/ hadoop104:/opt/module/hbase/
打開頁面測試查看
http://hadooo102:16010
其中這里面的選舉機制參考zookeeper的選舉功能。
如果沒有設置好 分區規則 Region Split,就可能出現HBase老版本的時候 10G一份為2,新版本分區就是按照64,...10G
這樣的分區 ,絕對會數據傾斜
。創建表的時候要設置好分區。根據就是數據大小跟機器規模。參考個 預分區技巧
create 'staff1','info','partition1',SPLITS => ['1000','2000','3000','4000']
分區有負無窮跟正無窮,并且切記是按照rowKey的字符串比較順序來比較的,比如1512123就分到了 1000~2000這個分區中。但是 40,400這樣的存儲有點別扭,所以rowkey盡量要保證長度一致,高位補零,0040,0400這樣的。
create 'staff2','info','partition2',{ NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}
這個是按照16進制的數據來分區的,
創建splits.txt文件內容如下:
aaaa bbbb cccc dddd
然后執行:
create 'staff3','partition3',SPLITS_FILE => 'splits.txt'
下面的分區內容不符合哦
。
aa bbddcc
hAdmin.createTable(tableDesc); // 默認創建表hAdmin.createTable(tableDesc, start,end,numsplit);// 根據start 跟end 均有分成numsplithAdmin.createTable(tableDesc, splitKeys);//
PS:
在命令行中我們傳入的比如是[100,200,300],,但是HBase底層只認識字節數組,所以會把數據組合成[[],[],[]] 這樣的
二維數組
。
//自定義算法,產生一系列Hash散列值存儲在二維數組中byte[][] splitKeys = 某個散列值函數//創建HBaseAdmin實例HBaseAdmin hAdmin = new HBaseAdmin(HBaseConfiguration.create());//創建HTableDescriptor實例HTableDescriptor tableDesc = new HTableDescriptor(tableName);//通過HTableDescriptor實例和散列值二維數組創建帶有預分區的HBase表hAdmin.createTable(tableDesc, splitKeys);
一條數據的唯一標識就是rowkey,那么這條數據存儲于哪個分區,取決于rowkey處于哪個一個預分區的區間內,設計rowkey的主要目的 ,就是讓數據均勻
的分布于所有的region中(散列性
,唯一性
,長度
(生產中甚至可能70~100位)),在一定程度上防止數據傾斜。接下來我們就談一談rowkey常用的設計方案。
生成隨機數、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
原則就是遵從 散列性、唯一性、長度。然后根據實際的業務需求來設定rowkey。
比如分區一共300個 分區鍵 000_ 001_ 002_... 298_ 手機號 % 299 分區位 000_手機號(手機號 + 年月) % 299 尋找分區 000_手機號_年月 hash(手機號 + 年月) % 299 尋找分區 總之就是規劃好分區,然后把重要的數據排在前面。這樣來搞。
HBase操作過程中需要大量的內存開銷,畢竟Table是可以緩存在內存中的,一般會分配整個可用內存的70%給HBase的Java堆。但是不建議分配非常大的堆內存
,有一個RegionServer
級別的刷新,因為GC過程持續太久會導致RegionServer處于長期不可用狀態,一般16~48G內存就可以了,如果因為框架占用內存過高導致系統內存不足,框架一樣會被系統服務拖死。
允許在HDFS的文件中追加內容
hdfs-site.xml、hbase-site.xml 屬性:dfs.support.append 解釋:開啟HDFS追加同步,可以優秀的配合HBase的數據同步和持久化。默認值為true。
優化DataNode允許的最大文件打開數
hdfs-site.xml 屬性:dfs.datanode.max.transfer.threads 解釋:HBase一般都會同一時間操作大量的文件,根據集群的數量和規模以及數據動作,設置為4096或者更高。默認值:4096
優化延遲高的數據操作的等待時間
hdfs-site.xml 屬性:dfs.image.transfer.timeout 解釋:如果對于某一次數據操作來講,延遲非常高,socket需要等待更長的時間,建議把該值設置為更大的值(默認60000毫秒),以確保socket不會被timeout掉。
優化數據的寫入效率
mapred-site.xml 屬性: mapreduce.map.output.compress mapreduce.map.output.compress.codec 解釋:開啟這兩個數據可以大大提高文件的寫入效率,減少寫入時間。第一個屬性值修改為true,第二個屬性值修改為:org.apache.hadoop.io.compress.GzipCodec或者其他壓縮方式。
設置RPC監聽數量
hbase-site.xml 屬性:hbase.regionserver.handler.count 解釋:默認值為30,用于指定RPC監聽的數量,可以根據客戶端的請求數進行調整,讀寫請求較多時,增加此值。
優化HStore文件大小
hbase-site.xml 屬性:hbase.hregion.max.filesize 解釋:默認值10737418240(10GB),如果需要運行HBase的MR任務,可以減小此值,因為一個region對應一個map任務,如果單個region過大,會導致map任務執行時間過長。該值的意思就是,如果HFile的大小達到這個數值,則這個region會被切分為兩個Hfile。
優化hbase客戶端緩存
hbase-site.xml 屬性:hbase.client.write.buffer 解釋:用于指定HBase客戶端緩存,增大該值可以減少RPC調用次數,但是會消耗更多內存,反之則反之。一般我們需要設定一定的緩存大小,以達到減少RPC次數的目的。
指定scan.next掃描HBase所獲取的行數
hbase-site.xml 屬性:hbase.client.scanner.caching 解釋:用于指定scan.next方法獲取的默認行數,值越大,消耗內存越大。
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
“怎么使用HBase優化”的內容就介紹到這里了,感謝大家的閱讀。如果想了解更多行業相關的知識可以關注億速云網站,小編將為大家輸出更多高質量的實用文章!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。