1.背景

由于種種原因，最近將核心業(yè)務(wù)生產(chǎn)使用的HBase遷移到了云上的彈性MapReduce(EMR)集群上，并使用了EMR的HBase組件默認(rèn)參數(shù)配置。

結(jié)果在流量高峰期出現(xiàn)了宿主機(jī)故障，掛掉了兩個(gè)core節(jié)點(diǎn)(部署了region server和datanode)，大量region rit，花了15分鐘才自動(dòng)恢復(fù)，硬生生吃了一個(gè)P0故障。

復(fù)盤(pán)的時(shí)候發(fā)現(xiàn)，由于云上EMR對(duì)hdfs的socket超時(shí)參數(shù)默認(rèn)設(shè)置了900000(15min),導(dǎo)致了region重新上線讀取故障節(jié)點(diǎn)WAL日志的時(shí)候足足等待了15分鐘才去重試下個(gè)節(jié)點(diǎn)。這樣的自愈時(shí)間顯然是不滿足「在線業(yè)務(wù)」的需求的，需要將這個(gè)超時(shí)時(shí)間調(diào)整到60000(1min)，實(shí)現(xiàn)快速自愈的目的。

因此，結(jié)合HBase自身組件特性與 「在線業(yè)務(wù)」高可用、低抖動(dòng) 訴求，全面整理了HBase參數(shù)調(diào)優(yōu)的最佳實(shí)踐。

2.先回顧下HBase基礎(chǔ)架構(gòu)

這里只是簡(jiǎn)單回顧下整體架構(gòu)，方便對(duì)照各個(gè)組件聊一聊需要優(yōu)化的參數(shù)。

2.1 整體架構(gòu)

從物理結(jié)構(gòu)上，HBase包含了三種類型的server，zookeeper、HMaster、RegionServer，從而形成了一種主從模式的結(jié)構(gòu)。

• RegionServer主要用來(lái)服務(wù)讀和寫(xiě)操作。當(dāng)用戶通過(guò)client訪問(wèn)數(shù)據(jù)時(shí)，client會(huì)和HBase RegionServer 進(jìn)行直接通信。
• HMaster主要進(jìn)行RegionServer的管理、DDL(創(chuàng)建、刪除表)操作等。
• Zookeeper是HDFS(Hadoop Distributed File System)的一部分，主要用來(lái)維持整個(gè)集群的存活，保障了HA，故障自動(dòng)轉(zhuǎn)移。
• 底層的存儲(chǔ)，還是依賴于HDFS的。Hadoop的DataNode存儲(chǔ)了RegionServer所管理的數(shù)據(jù)，所有HBase的數(shù)據(jù)都是存在HDFS中的。Hadoop的NameNode維護(hù)了所有物理數(shù)據(jù)塊的metadata。

2.2 RegionServer組成

一個(gè)RegionServer運(yùn)行在一個(gè)HDFS的DataNode上，并且擁有以下組件：

• WAL：全稱Write Ahead Log，屬于分布式系統(tǒng)上的文件。主要用來(lái)存儲(chǔ)還未被持久化到磁盤(pán)上的新數(shù)據(jù)。如果新數(shù)據(jù)還未持久化，節(jié)點(diǎn)發(fā)生宕機(jī)，那么就可以用WAL來(lái)恢復(fù)這些數(shù)據(jù)。
• BlockCache：是一個(gè)讀緩存。它存儲(chǔ)了被高頻訪問(wèn)的數(shù)據(jù)。當(dāng)這個(gè)緩存滿了后，會(huì)清除最近最少訪問(wèn)的數(shù)據(jù)。
• MenStore: 是一個(gè)寫(xiě)緩存。它存儲(chǔ)了還未被寫(xiě)入磁盤(pán)的數(shù)據(jù)。它會(huì)在寫(xiě)入磁盤(pán)前，對(duì)自身數(shù)據(jù)進(jìn)行排序，從而保證數(shù)據(jù)的順序?qū)懭?。每個(gè)region的每個(gè)colum family會(huì)有一份對(duì)應(yīng)的memstore。
• HFiles：按照字典序存儲(chǔ)各個(gè)row的鍵值。

3、讀優(yōu)化

3.1 優(yōu)化讀/寫(xiě)內(nèi)存比例

一個(gè)RegionServer上有一個(gè)BlockCache和N個(gè)Memstore，它們的大小之和必須小于HeapSize* 0.8，否則HBase不能啟動(dòng)，因?yàn)槿匀灰粲幸恍﹥?nèi)存保證其它任務(wù)的執(zhí)行。

BlockCache作為讀緩存，對(duì)于讀的性能比較重要，如果讀比較多，建議內(nèi)存使用1:4的機(jī)器，比如：8cpu32g或者16pu64g的機(jī)器。

讀多寫(xiě)少的場(chǎng)景下，可以調(diào)高BlockCache的數(shù)值，降低Memstore的數(shù)值來(lái)提高讀場(chǎng)景性能。

核心調(diào)整參數(shù)如下：

- hfile.block.cache.size = 0.5
- hbase.regionserver.global.memstore.size = 0.3

3.2 減少HFile數(shù)量

因?yàn)镠Base讀取時(shí)沒(méi)有命中緩存，就需要打開(kāi)HFile。如果HFile文件越多，IO次數(shù)就越多，讀取的延遲就越高。

因此，HBase通過(guò)compaction機(jī)制來(lái)合并HFile。

但是，對(duì)于「在線業(yè)務(wù)」來(lái)說(shuō)，白天流量高峰做compact會(huì)嚴(yán)重影響磁盤(pán)IO，造成讀寫(xiě)毛刺，因此需要對(duì)compact限速。

3.3 開(kāi)啟「短路讀」特性

HBase數(shù)據(jù)是存儲(chǔ)在HDFS，從HDFS讀取數(shù)據(jù)需要經(jīng)過(guò)DataNode，開(kāi)啟Short-Circuit Local Read后，客戶端可以直接讀取本地?cái)?shù)據(jù)。

假設(shè)現(xiàn)有兩個(gè)用戶User1和User2，User1擁有訪問(wèn)HDFS目錄上/appdata/hbase1文件的權(quán)限，而User2用戶沒(méi)有該權(quán)限，但是User2用戶又需要訪問(wèn)這個(gè)文件，那么可以借助UNIX中「文件描述符傳遞」的機(jī)制，可以讓User1用戶打開(kāi)文件得到一個(gè)文件描述符，然后把文件描述符傳遞給User2用戶，那么User2用戶就可以讀取文件里面的內(nèi)容了，即使User2用戶沒(méi)有權(quán)限。

這種關(guān)系映射到HDFS中，可以把DataNode看作User1用戶，客戶端DFSClient看作User2用戶，需要讀取的文件就是DataNode目錄中的/appdata/hbase1文件。實(shí)現(xiàn)如下圖所示：

核心參數(shù)如下：

- dfs.client.read.shortcircuit = true

3.4 開(kāi)啟「對(duì)沖讀」特性(需要評(píng)估磁盤(pán)IO)

當(dāng)我們開(kāi)啟「短路讀」特性后，優(yōu)先會(huì)通過(guò)Short-Circuit Local Read功能嘗試本地讀。但是在某些特殊情況下，有可能會(huì)出現(xiàn)因?yàn)榇疟P(pán)問(wèn)題或者網(wǎng)絡(luò)問(wèn)題引起的短時(shí)間本地讀取失敗。

為了應(yīng)對(duì)這類問(wèn)題，HBase實(shí)現(xiàn)了「對(duì)沖讀」特性Hedged Read。

該機(jī)制基本工作原理為：

客戶端發(fā)起一個(gè)本地讀，一旦一段時(shí)間之后還沒(méi)有返回，客戶端將會(huì)向其他DataNode發(fā)送相同數(shù)據(jù)的請(qǐng)求。哪一個(gè)請(qǐng)求先返回，另一個(gè)就會(huì)被丟棄。

當(dāng)然，這個(gè)特性顯然會(huì)放大磁盤(pán)IO的壓力，需要謹(jǐn)慎評(píng)估使用。

核心參數(shù)如下：(根據(jù)實(shí)際環(huán)境對(duì)參數(shù)進(jìn)行調(diào)整)。

- dfs.client.hedged.read.threadpool.size = 10 //指定有多少線程用于服務(wù)hedged reads。如果此值設(shè)置為0（默認(rèn)），則hedged reads為disabled狀態(tài)
- dfs.client.hedged.read.threshold.millis：默認(rèn)為500（0.5秒）：在spawning 第二個(gè)線程前，等待的時(shí)間。

4、寫(xiě)優(yōu)化

4.1 增大MemStore的內(nèi)存

面對(duì)「寫(xiě)多讀少」的場(chǎng)景， 可以考慮調(diào)高M(jìn)emStore 的內(nèi)存占比，降低BlockCache的內(nèi)存占比，跟讀優(yōu)化3.1的思路正好相反。

具體可以根據(jù)讀寫(xiě)比例來(lái)評(píng)估。

4.2 適當(dāng)增加HFile產(chǎn)生

本條與3.2并不沖突，需要權(quán)衡。

數(shù)據(jù)寫(xiě)入過(guò)程中，MemStore在滿足一定條件時(shí)會(huì)flush刷寫(xiě)到磁盤(pán)，生成一個(gè)HFile文件。當(dāng)一個(gè)Store下的HFile文件數(shù)量大于某個(gè)閾值時(shí)，就會(huì)引起寫(xiě)入或更新阻塞。

RS日志中會(huì)有類似 “has too many store files...” 的信息。當(dāng)出現(xiàn)這種情況時(shí)，需要等待Compaction合并以減少HFile數(shù)量，這里主要是Minor Compaction即小合并。

所以我們盡量調(diào)大這個(gè)閾值，減少compaction。

核心參數(shù)：

- hbase.hstore.blockingStoreFiles = 100

如果寫(xiě)很快，很容易帶來(lái)大量的HFile，因?yàn)榇藭r(shí)HFile合并的速度還沒(méi)有寫(xiě)入的速度快。

需要在業(yè)務(wù)低峰期做major compaction，充分利用系統(tǒng)資源。如果HFile降低不下來(lái)，則需要添加節(jié)點(diǎn)。

4.3 適當(dāng)增大Memstore阻塞倍數(shù)

當(dāng)MemStore大小達(dá)到刷寫(xiě)閾值(hbase.hregion.memstore.flush.size，默認(rèn)128M)時(shí)，就會(huì)flush刷寫(xiě)到磁盤(pán)，這個(gè)操作基本沒(méi)有阻塞。但當(dāng)一個(gè)Region的所有MemStore大小達(dá)到一個(gè)阻塞倍數(shù)(hbase.hregion.memstore.block.multiplier，默認(rèn)值為4，即4倍的刷寫(xiě)閾值 默認(rèn)4*128=512M)時(shí)，就會(huì)阻塞該Region所有的更新請(qǐng)求，并強(qiáng)制flush?？蛻舳丝赡軙?huì)拋出RegionTooBusyException異常。

為了盡量避免寫(xiě)入阻塞，可以適當(dāng)調(diào)整這兩個(gè)參數(shù)。

核心參數(shù)包括：

- hbase.hregion.memstore.flush.size = 128
- hbase.hregion.memstore.block.multiplier = 4

5.IO優(yōu)化

HBase利用compaction機(jī)制，通過(guò)大量的讀延遲毛刺和一定的寫(xiě)阻塞，來(lái)?yè)Q取整體上的讀取延遲的平穩(wěn)。

為了綜合權(quán)衡 性能 與 穩(wěn)定性，需要對(duì)compation做限速處理。

核心調(diào)整參數(shù)如下：

- hbase.offpeak.end.hour = 6 //允許不限速compact的結(jié)束時(shí)間
- hbase.offpeak.start.hour = 22 //允許不限速compact的開(kāi)始時(shí)間
- hbase.hstore.compaction.throughput.higher.bound = 15728640 //限速compact最大為15M
- hbase.hstore.compaction.throughput.lower.bound = 10485760 //限速compact最小為10M
- hbase.hregion.majorcompactio = 0 //關(guān)閉定時(shí)major compaction
- hbase.regionserver.thread.compaction.large = 1 //compation線程
- hbase.regionserver.thread.compaction.small = 1//compaction線程
- hbase.hstore.compaction.max = 3 //一次Minor Compaction最多合并的HFile文件數(shù)

需要注意的是，白天compaction限速，并且關(guān)閉了定時(shí)major compaction后，可能會(huì)導(dǎo)致HFile合并不足，因此，可以考慮外部控制(如java api)定時(shí)在夜間做major compaction來(lái)減少HFile數(shù)量。

6.故障恢復(fù)優(yōu)化

引起RegionServer宕機(jī)的原因各種各樣，有因?yàn)镕ull GC導(dǎo)致、網(wǎng)絡(luò)異常導(dǎo)致、官方Bug導(dǎo)致(close wait端口未關(guān)閉)以及DataNode異常導(dǎo)致等等。

這些場(chǎng)景下一旦RegionServer發(fā)生宕機(jī)，HBase都會(huì)馬上檢測(cè)到這種宕機(jī)，并且在檢測(cè)到宕機(jī)之后會(huì)將宕機(jī)RegionServer上的所有Region重新分配到集群中其他正常RegionServer上去，再根據(jù)HLog進(jìn)行丟失數(shù)據(jù)恢復(fù)，恢復(fù)完成之后就可以對(duì)外提供服務(wù)，整個(gè)過(guò)程都是自動(dòng)完成的，并不需要人工介入?；驹砣缦聢D所示：

當(dāng)datanode異常時(shí)，如果讀取超時(shí)設(shè)置過(guò)大(dfs.client.socket-timeout和dfs.socket.timeout)，region無(wú)法正常讀取WAL日志，就會(huì)導(dǎo)致恢復(fù)耗時(shí)增加。

核心參數(shù)如下：

- dfs.client.socket-timeout = 60000
- dfs.datanode.socket.write.timeout = 480000
- dfs.socket.timeout = 60000

7.其他優(yōu)化

7.1 split策略

HBase 2.0.0 以上版本采用的 split 策略是 SteppingSplitPolicy。

SteppingSplitPolicy 在初期 region 數(shù)量較少的時(shí)候，split 的閾值較低，會(huì)比較頻繁地觸發(fā) split。

我們已經(jīng)給表做了預(yù)分區(qū)，所以可以將split策略設(shè)置為固定大小(大小由參數(shù)hbase.hregion.max.filesize 決定)。

核心參數(shù)：

- hbase.regionserver.region.split.policy = org.apache.hadoop.hbase.regionserver.ConstantSizeRegionSplitPolicy

7.2 開(kāi)啟rsgroup

rsgroup對(duì)于擴(kuò)縮容等運(yùn)維操作有很大的幫助，可以很好的控制region移動(dòng)造成的影響。move_servers_rsgroup 命令的 for 循環(huán)里會(huì)將 region 逐個(gè)移動(dòng)。

- hbase.coprocessor.master.classes = org.apache.hadoop.hbase.rsgroup.RSGroupAdminEndpointhbase.master.loadbalancer.class = org.apache.hadoop.hbase.rsgroup.RSGroupBasedLoadBalancer

另外，為了避免rs故障導(dǎo)致的meta表的「重試風(fēng)暴」，region漂移失敗(異常opening狀態(tài))，可以給meta表設(shè)置獨(dú)立的rsgroup，與業(yè)務(wù)rsgroup進(jìn)行隔離。同時(shí)，增大meta表的handler數(shù)量。

- hbase.regionserver.metahandler.count = 400 //建議根據(jù)客戶端數(shù)量進(jìn)行評(píng)估設(shè)置

8.小結(jié)

本文從HBase「基礎(chǔ)架構(gòu)」出發(fā)，梳理各個(gè)組件、讀寫(xiě)流程的參數(shù)調(diào)優(yōu)，期望能滿足「在線業(yè)務(wù)」的高可用、低抖動(dòng)的需求。