Hbase叢集運維及應用效能優化總結（hbase1.20+）
（一）. 作業系統
1. 足夠大的記憶體
2. 作業系統64位，jdk64位
3. 設定linux swap空間的swappiness=0
a1. 永久有效設定（需系統重啟） sudo vim /etc/sysctl.conf 在這個文件的最後加上這樣一行:
a2. 臨時修改 sudo sysctl vm.swappiness=0
4. CPU
Make sure you have set up your Hadoop to use native, hardware checksumming. See link:[hadoop.native.lib]
(二). 網路
1. 考慮資料傳輸,頻寬足夠大(因為主要和datanode節點之間做資料傳輸)
(三). Java
1. GC優化
a. CMS failure modes問題
b. old generation heap fragmentation brought問題(備註：因Region flush導致的記憶體碎片問題造成小記憶體塊無法使用，從而引起fullgc時間過長超過regionserver向hmaster心跳時間，最終導致regionserver誤判為掛掉)
hbase.hregion.memstore.mslab.enabled=true // 開啟MSLAB (備註: 記憶體小或單個server上region數少的情況下，可關閉)
hbase.hregion.memstore.mslab.chunksize=2m // chunk的大小，越大記憶體連續性越好，但記憶體平均利用率會降低
hbase.hregion.memstore.mslab.max.allocation=256K // 通過MSLAB分配的物件不能超過256K，否則直接在Heap上分配，256K夠大了
寫負載高場景--降低YGC的開銷---兩種調整引數方式:
A). hbase.hregion.memstore.chunkpool.maxsize=0.5 (備註: ; 0為禁用: 作用: 降低YGC的開銷，reuse chunk; 賦值區間為global memstore size的百分比0-1之間 )
B). -XX:PretenureSizeThreshold=？（備註： 作用：有物件的size超過該值，直接在老年代分配記憶體，避免大物件在s0-s1之間copy; 值設定略小於hbase.hregion.memstore.mslab.chunksize的值即可）
c. enabling the off-heap Block Cache
A). LruBlockCache （備註：全部使用的是Java heap； 預設）
B). BucketCache (備註: 儘量快取資料在 off-heap)
(四). Hbase配置調整(根據監控或壓測情況，謹慎調整)
1.
2. (hdfs-default.xml) dfs.datanode.failed.volumes.tolerated(備註：datanode可以忍受的磁碟損壞的個數)
3. hbase.regionserver.handler.count(regionServer 處理客戶端請求的執行緒數)
4. hfile.block.cache.size(備註： RegionServer 記憶體讀)
5. Prefetch Option for Blockcache (備註： 快速讀)
6. hbase.regionserver.global.memstore.size(設定過小，會造成RS響應遲鈍或頻繁的compaction)
7. hbase.regionserver.global.memstore.size.lower.limit
8. hbase.hstore.blockingStoreFiles
9. hbase.hregion.memstore.block.multiplier
10. hbase.regionserver.checksum.verify (啟用hbase的checksum，替代hdfs的)
11. Tuning callQueue Options(備註: 至少有一個寫佇列)
A). hbase.ipc.server.num.callqueue > 1
B). hbase.ipc.server.callqueue.read.ratio(0-1之間)
C). hbase.ipc.server.callqueue.scan.ratio(0-1之間;;; 備註: determine the ratio of read queues used for Gets and Scans; 至少有一個get佇列)
D). hbase.ipc.server.callqueue.handler.factor (備註： 0為所有的handler共用一個queue； 1為一個handler一個queue; 0-1之間，比如0.5為兩個handler共享一個queue;;; 影響：一個handler只處理他負責的queue，如果配置一個handler一個queue，則有長時間執行task的佇列，不能有已經空閒的handler來幫忙處理，只能負責他的handler獨自苦逼處理)
12. ZooKeeper (保證有一個專用的磁碟，具體看zooKeeper配置)
13. Schema Design
A). 列簇數決策（hbase官方說明一個列簇可以避免寫多讀少的場景下，多個列簇，在flush和compaction以region為單位的情況下，單個columnFamily達到資料量上限，造成所有columnFamily都被flush，從而引起頻繁的compaction，造成IO浪費；如果某些列被經常查詢，在讀多寫少的場景下，把這些列單獨建立一個列簇，提高訪問效能）
B). rowkey(設計儘可能短和保證查詢效率),列簇名和列名儘可能短
C). region個數決策(備註: region數越少，叢集執行越流暢； 一般20-200個比較合理)，最好建表的時候，Pre-splitting
1). region個數計算公式（HBase 0.98.x）: ((RS Xmx) * hbase.regionserver.global.memstore.size) / (hbase.hregion.memstore.flush.size * (# column families))
D). 手動管理split和compaction，根據業務忙閒來靈活調整，避免自動管理，影響業務
E).