第四天：HBase 優化

1. 高可用

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

1. 關閉HBase集羣（如果沒有開啓則跳過此步）

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

2. 在conf目錄下創建backup-masters文件

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

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

[atguigu@hadoop102 hbase]$ echo hadoop103 > conf/backup-masters  
將103設置爲備份的master

4. 將整個conf目錄scp到其他節點

[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. 預分區(重要)

如果沒有設置好 分區規則 Region Split，就可能出現HBase老版本的時候 10G一份爲2，新版本分區就是按照64,...10G這樣的分區 ，絕對會數據傾斜。創建表的時候要設置好分區。根據就是數據大小跟機器規模。參考個 預分區技巧

1. 手動設定預分區

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

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

2. 生成16進制序列預分區

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

這個是按照16進制的數據來分區的，

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

創建splits.txt文件內容如下：

aaaa
bbbb
cccc
dddd

然後執行：

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

下面的分區內容不符合哦。

aa
bb
dd
cc

4. API 分區

hAdmin.createTable(tableDesc); // 默認創建表
hAdmin.createTable(tableDesc, start,end,numsplit);// 根據start 跟end 均有分成numsplit
hAdmin.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);

3.RowKey設計(重要)

一條數據的唯一標識就是rowkey，那麼這條數據存儲於哪個分區，取決於rowkey處於哪個一個預分區的區間內，設計rowkey的主要目的 ，就是讓數據均勻的分佈於所有的region中(散列性，唯一性，長度(生產中甚至可能70~100位))，在一定程度上防止數據傾斜。接下來我們就談一談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

原則就是遵從 散列性、唯一性、長度。然後根據實際的業務需求來設定rowkey。

比如分區一共300個
分區鍵
000_
001_
002_
...
298_

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

4. 內存優化

HBase操作過程中需要大量的內存開銷，畢竟Table是可以緩存在內存中的，一般會分配整個可用內存的70%給HBase的Java堆。但是不建議分配非常大的堆內存，有一個RegionServer級別的刷新，因爲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