HBase 經驗小結 （Based on 1.x）

1. HBase
   1.1 存儲

• Phoenix
  Schema qualifier管理方便、偶爾的SQL查數方便
  用不到二級索引實際沒必要要，會有必定的性能損耗

• 列族劃分
  粗粒度劃分對於schema管理及上層取數十分方便
  列劃分過大容易頻繁觸發flush，且對於部分不須要全列數據影響查詢性能

• 預分區
  極大緩解在業務讀寫中Split和數據傾斜帶來的開銷
  有些業務場景的rowkey須要hash作適配預分區，要求不高的好比md5等

• 壓縮與編碼
  壓縮可能採用Snappy，冷備集羣能夠考慮Gzip
  編碼慎用所謂推薦的prefixTree，1.x版本有bug。ref: HBASE-12959

• 多版本存儲
  利用timestamp能夠作版本冗餘、一致性問題緩解等事情
  注意磁盤壓力，尤爲是還有按期作snapshot的，archive有可能回收會比較慢

1.2 寫入

• 注意List 批次大小
  適當聚合請求會加速一樣數量的請求速度，減小請求IO次數
  批次太大會形成slow multi request，這類慢請求過多會影響吞吐率，後來的請求只能在客戶端輪詢wait

• 寫請求較多的場景注意控制compaction
  若有必要能夠手動關閉major compact，在閒時手動觸發
  刪改請求較多的，能夠適當縮小major compact的間隔，以避免讀性能影響

1.3 讀取

• 注意List 批次大小
  適當聚合請求會加速一樣數量的請求速度，減小請求IO次數
  批次太大會形成slow multi request，這類慢請求過多會影響吞吐率，後來的請求只能在客戶端輪詢wait
  Get所請求的字節數過大(超過數組上限)的話會沒法返回，1.2.0以前的版本甚至會致使RegionServer OOM 宕機。

• 注意Version、ttl的特殊性，區分數據的邏輯刪除與物理刪除
  用戶視角的HBase自身一致性問題80%都是搞不清楚邏輯刪除。
  邏輯刪除：HBase會讀到這個數據，可是在RS層根據策略不返回給用戶
  物理刪除：真的從HDFS刪除此數據，發生於compact階段

• Scan的Filter
  善用Filter作下推減小返回的數據數量
  Filter也不要嵌套太複雜，使得RegionServer處理負載較重
  注意設置到Filter的qualifier首先要能取出來，所以scan若是顯示設置了addColumn/addFamily，須要記得包括filter的qualifier
  注意指定qualifier是否爲null，有可能致使想拿的數據沒拿到；結合 filter.setFilterIfMissing 使用。

• Scan優化
  適當設置caching，通常爲100
  blockCache設爲false
  只取本身關注的列
  考慮設置 hbase.mapreduce.input.autobalance = true 以解決預期Region取數不太均衡或數據傾斜的scan問題

• BlockCache緩存配置
  強烈建議用BucketCache的offheap模式，配置計算方式參考：http://hbasefly.com/2016/04/08/hbase-blockcache-1/

1.4 GC優化

• JDK 1.7+ && CMS優化 (netease) :
  -Xmx20g -Xms20g -Xmn512m -Xss256k
  -XX:MaxPermSize=256m -XX:SurvivorRatio=2
  -XX:+UseConcMarkSweepGC -XX:+UseParNewGC
  -XX:+CMSParallelRemarkEnabled -XX:MaxTenuringThreshold=15
  -XX:+UseCMSCompactAtFullCollection -XX:+UseCMSInitiatingOccupancyOnly
  -XX:CMSInitiatingOccupancyFraction=75 -XX:-DisableExplicitGC

• JDK 1.8+ && G1GC (XIaomi):
  -Xmx20g -Xms20g -XX:MaxDirectMemorySize=20g
  -XX:+UseG1GC
  -XX:+UnlockExperimentalVMOptions 
  -XX:MaxGCPauseMillis=90
  -XX:G1NewSizePercent=2 
  -XX:InitiatingHeapOccupancyPercent=65 
  -XX:+ParallelRefProcEnabled
  -XX:ConcGCThreads=4 -XX:ParallelGCThreads=16 -XX:MaxTenuringThreshold=1 
  -XX:G1HeapRegionSize=32m -XX:G1MixedGCCountTarget=64 -XX:G1OldCSetRegionThresholdPercent=5
  -verbose:gc -XX:+PrintGC -XX:+PrintGCDetails -XX:+PrintGCApplicationStoppedTime 
  -XX:+PrintHeapAtGC -XX:+PrintGCDateStamps -XX:+PrintAdaptiveSizePolicy 
  -XX:+PrintTenuringDistribution -XX:+PrintSafepointS

GC狀況最後依然還需根據實際本身的狀況進行調整。

1.5 監控
方案：ELK、Grafana + 時序數據庫(Opentsdb)/監控系統(OpenFalcon)等
指標：JVM (GC、Heap、OffHeap等)、Compact、Split、緩存命中數、各種請求count、slow request count、集羣基礎監控。（注：以上監控除了JVM和集羣基礎，有條件的表級別和RegionServer級別都作一份）

另：記得對RegionServer作自動拉起的守護進程。

1.6 Linux

• 關閉大頁 Tuning transparent huge pages (THP) off
• 禁止swap Set vm.swappiness = 0
• 關閉NUMA vm.zone_reclaim_mode = 0

以上操做系統配置基本適用於持續服務的高讀性能數據存儲集羣，包括但不只限於HBase、ES等。

1.7 備份與容災
數據層面目前官方版本只支持異步式的冷備。

• Snapshot/Export 機制
  每次都是全量備份
  自行維護WAL回放（或業務重放）
• HBase 2.0 增量備份
  利用WAL作增量備份
  不支持對備份作compact，增量太多時恢復速度須要關注
• 主從一致性（備份自己也可能由於網絡等緣由失敗）

1.8 部署

• Master HA
• Region預留足夠offheap內存給BucketCache讀緩存，2.x會更多的利用offheap以緩解GC