硬吃一個P0故障，「在線業務」應該如何調優HBase參數？
1.背景
由于種種原因，最近將核心業務生產使用的HBase遷移到了云上的彈性MapReduce(EMR)集群上，并使用了EMR的HBase組件默認參數配置。
結果在流量高峰期出現了宿主機故障，掛掉了兩個core節點(部署了region server和datanode)，大量region rit，花了15分鐘才自動恢復，硬生生吃了一個P0故障。
復盤的時候發現，由于云上EMR對hdfs的socket超時參數默認設置了900000(15min),導致了region重新上線讀取故障節點WAL日志的時候足足等待了15分鐘才去重試下個節點。這樣的自愈時間顯然是不滿足「在線業務」的需求的，需要將這個超時時間調整到60000(1min)，實現快速自愈的目的。
因此，結合HBase自身組件特性與 「在線業務」高可用、低抖動 訴求，全面整理了HBase參數調優的最佳實踐。
2.先回顧下HBase基礎架構
這里只是簡單回顧下整體架構，方便對照各個組件聊一聊需要優化的參數。
2.1 整體架構
從物理結構上，HBase包含了三種類型的server，zookeeper、HMaster、RegionServer，從而形成了一種主從模式的結構。
- RegionServer主要用來服務讀和寫操作。當用戶通過client訪問數據時，client會和HBase RegionServer 進行直接通信。
- HMaster主要進行RegionServer的管理、DDL(創建、刪除表)操作等。
- Zookeeper是HDFS(Hadoop Distributed File System)的一部分，主要用來維持整個集群的存活，保障了HA，故障自動轉移。
- 底層的存儲，還是依賴于HDFS的。Hadoop的DataNode存儲了RegionServer所管理的數據，所有HBase的數據都是存在HDFS中的。Hadoop的NameNode維護了所有物理數據塊的metadata。
2.2 RegionServer組成
一個RegionServer運行在一個HDFS的DataNode上，并且擁有以下組件：
- WAL：全稱Write Ahead Log，屬于分布式系統上的文件。主要用來存儲還未被持久化到磁盤上的新數據。如果新數據還未持久化，節點發生宕機，那么就可以用WAL來恢復這些數據。
- BlockCache：是一個讀緩存。它存儲了被高頻訪問的數據。當這個緩存滿了后，會清除最近最少訪問的數據。
- MenStore: 是一個寫緩存。它存儲了還未被寫入磁盤的數據。它會在寫入磁盤前，對自身數據進行排序，從而保證數據的順序寫入。每個region的每個colum family會有一份對應的memstore。
- HFiles：按照字典序存儲各個row的鍵值。
3、讀優化
3.1 優化讀/寫內存比例
一個RegionServer上有一個BlockCache和N個Memstore，它們的大小之和必須小于HeapSize* 0.8，否則HBase不能啟動，因為仍然要留有一些內存保證其它任務的執行。
BlockCache作為讀緩存，對于讀的性能比較重要，如果讀比較多，建議內存使用1:4的機器，比如：8cpu32g或者16pu64g的機器。
讀多寫少的場景下，可以調高BlockCache的數值，降低Memstore的數值來提高讀場景性能。
核心調整參數如下：
- hfile.block.cache.size = 0.5
- hbase.regionserver.global.memstore.size = 0.3
3.2 減少HFile數量
因為HBase讀取時沒有命中緩存，就需要打開HFile。如果HFile文件越多，IO次數就越多，讀取的延遲就越高。
因此，HBase通過compaction機制來合并HFile。
但是，對于「在線業務」來說，白天流量高峰做compact會嚴重影響磁盤IO，造成讀寫毛刺，因此需要對compact限速。
3.3 開啟「短路讀」特性
HBase數據是存儲在HDFS，從HDFS讀取數據需要經過DataNode，開啟Short-Circuit Local Read后，客戶端可以直接讀取本地數據。
假設現有兩個用戶User1和User2，User1擁有訪問HDFS目錄上/appdata/hbase1文件的權限，而User2用戶沒有該權限，但是User2用戶又需要訪問這個文件，那么可以借助UNIX中「文件描述符傳遞」的機制，可以讓User1用戶打開文件得到一個文件描述符，然后把文件描述符傳遞給User2用戶，那么User2用戶就可以讀取文件里面的內容了，即使User2用戶沒有權限。
這種關系映射到HDFS中，可以把DataNode看作User1用戶，客戶端DFSClient看作User2用戶，需要讀取的文件就是DataNode目錄中的/appdata/hbase1文件。實現如下圖所示：
核心參數如下：
- dfs.client.read.shortcircuit = true
3.4 開啟「對沖讀」特性(需要評估磁盤IO)
當我們開啟「短路讀」特性后，優先會通過Short-Circuit Local Read功能嘗試本地讀。但是在某些特殊情況下，有可能會出現因為磁盤問題或者網絡問題引起的短時間本地讀取失敗。
為了應對這類問題，HBase實現了「對沖讀」特性Hedged Read。
該機制基本工作原理為：
客戶端發起一個本地讀，一旦一段時間之后還沒有返回，客戶端將會向其他DataNode發送相同數據的請求。哪一個請求先返回，另一個就會被丟棄。
當然，這個特性顯然會放大磁盤IO的壓力，需要謹慎評估使用。
核心參數如下：(根據實際環境對參數進行調整)。
- dfs.client.hedged.read.threadpool.size = 10 //指定有多少線程用于服務hedged reads。如果此值設置為0（默認），則hedged reads為disabled狀態
- dfs.client.hedged.read.threshold.millis：默認為500（0.5秒）：在spawning 第二個線程前，等待的時間。
4、寫優化
4.1 增大MemStore的內存
面對「寫多讀少」的場景， 可以考慮調高MemStore 的內存占比，降低BlockCache的內存占比，跟讀優化3.1的思路正好相反。
具體可以根據讀寫比例來評估。
4.2 適當增加HFile產生
本條與3.2并不沖突，需要權衡。
數據寫入過程中，MemStore在滿足一定條件時會flush刷寫到磁盤，生成一個HFile文件。當一個Store下的HFile文件數量大于某個閾值時，就會引起寫入或更新阻塞。
RS日志中會有類似 “has too many store files...” 的信息。當出現這種情況時，需要等待Compaction合并以減少HFile數量，這里主要是Minor Compaction即小合并。
所以我們盡量調大這個閾值，減少compaction。
核心參數：
- hbase.hstore.blockingStoreFiles = 100
如果寫很快，很容易帶來大量的HFile，因為此時HFile合并的速度還沒有寫入的速度快。
需要在業務低峰期做major compaction，充分利用系統資源。如果HFile降低不下來，則需要添加節點。
4.3 適當增大Memstore阻塞倍數
當MemStore大小達到刷寫閾值(hbase.hregion.memstore.flush.size，默認128M)時，就會flush刷寫到磁盤，這個操作基本沒有阻塞。但當一個Region的所有MemStore大小達到一個阻塞倍數(hbase.hregion.memstore.block.multiplier，默認值為4，即4倍的刷寫閾值 默認4*128=512M)時，就會阻塞該Region所有的更新請求，并強制flush。客戶端可能會拋出RegionTooBusyException異常。
為了盡量避免寫入阻塞，可以適當調整這兩個參數。
核心參數包括：
- hbase.hregion.memstore.flush.size = 128
- hbase.hregion.memstore.block.multiplier = 4
5.IO優化
HBase利用compaction機制，通過大量的讀延遲毛刺和一定的寫阻塞，來換取整體上的讀取延遲的平穩。
為了綜合權衡 性能 與 穩定性，需要對compation做限速處理。
核心調整參數如下：
- hbase.offpeak.end.hour = 6 //允許不限速compact的結束時間
- hbase.offpeak.start.hour = 22 //允許不限速compact的開始時間
- hbase.hstore.compaction.throughput.higher.bound = 15728640 //限速compact最大為15M
- hbase.hstore.compaction.throughput.lower.bound = 10485760 //限速compact最小為10M
- hbase.hregion.majorcompactio = 0 //關閉定時major compaction
- hbase.regionserver.thread.compaction.large = 1 //compation線程
- hbase.regionserver.thread.compaction.small = 1//compaction線程
- hbase.hstore.compaction.max = 3 //一次Minor Compaction最多合并的HFile文件數
需要注意的是，白天compaction限速，并且關閉了定時major compaction后，可能會導致HFile合并不足，因此，可以考慮外部控制(如java api)定時在夜間做major compaction來減少HFile數量。
6.故障恢復優化
引起RegionServer宕機的原因各種各樣，有因為Full GC導致、網絡異常導致、官方Bug導致(close wait端口未關閉)以及DataNode異常導致等等。
這些場景下一旦RegionServer發生宕機，HBase都會馬上檢測到這種宕機，并且在檢測到宕機之后會將宕機RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根據HLog進行丟失數據恢復，恢復完成之后就可以對外提供服務，整個過程都是自動完成的，并不需要人工介入。基本原理如下圖所示：
當datanode異常時，如果讀取超時設置過大(dfs.client.socket-timeout和dfs.socket.timeout)，region無法正常讀取WAL日志，就會導致恢復耗時增加。
核心參數如下：
- dfs.client.socket-timeout = 60000
- dfs.datanode.socket.write.timeout = 480000
- dfs.socket.timeout = 60000
7.其他優化
7.1 split策略
HBase 2.0.0 以上版本采用的 split 策略是 SteppingSplitPolicy。
SteppingSplitPolicy 在初期 region 數量較少的時候，split 的閾值較低，會比較頻繁地觸發 split。
我們已經給表做了預分區，所以可以將split策略設置為固定大小(大小由參數hbase.hregion.max.filesize 決定)。
核心參數：
- hbase.regionserver.region.split.policy = org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy
7.2 開啟rsgroup
rsgroup對于擴縮容等運維操作有很大的幫助，可以很好的控制region移動造成的影響。move_servers_rsgroup 命令的 for 循環里會將 region 逐個移動。
- hbase.coprocessor.master.classes = org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpointhbase.master.loadbalancer.class = org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer
另外，為了避免rs故障導致的meta表的「重試風暴」，region漂移失敗(異常opening狀態)，可以給meta表設置獨立的rsgroup，與業務rsgroup進行隔離。同時，增大meta表的handler數量。
- hbase.regionserver.metahandler.count = 400 //建議根據客戶端數量進行評估設置
8.小結
本文從HBase「基礎架構」出發，梳理各個組件、讀寫流程的參數調優，期望能滿足「在線業務」的高可用、低抖動的需求。
