1.compact

我們首先假設(shè)一個(gè)現(xiàn)象：當(dāng)寫請(qǐng)求非常多，導(dǎo)致不斷生成HFile，但compact的速度遠(yuǎn)遠(yuǎn)跟不上HFile生成的速度，這樣就會(huì)使HFile的數(shù)量會(huì)越來越多，導(dǎo)致讀性能急劇下降。為了避免這種情況，在HFile的數(shù)量過多的時(shí)候會(huì)限制寫請(qǐng)求的速度：在每次執(zhí)行MemStore flush的操作前，如果HStore的HFile數(shù)超過hbase.hstore.blockingStoreFiles （默認(rèn)7），則會(huì)阻塞flush操作hbase.hstore.blockingWaitTime時(shí)間，在這段時(shí)間內(nèi)，如果compact操作使得HStore文件數(shù)下降到回這個(gè)值，則停止阻塞。另外阻塞超過時(shí)間后，也會(huì)恢復(fù)執(zhí)行flush操作。這樣做就可以有效地控制大量寫請(qǐng)求的速度，但同時(shí)這也是影響寫請(qǐng)求速度的主要原因之一。

• minor compact
  HStore的storeFile數(shù)量 >=hbase.hstore.compactionThreshold配置的值，則可能會(huì)進(jìn)行compact，默認(rèn)值為3，可以調(diào)大，比如設(shè)置為6，在定期的major compact中進(jìn)行剩下文件的合并。
• major compact
  hbase.hregion.majorcompaction:配置major合并的間隔時(shí)間，默認(rèn)為1天，可設(shè)置為0，禁止自動(dòng)的major合并，可手動(dòng)或者通過腳本定期進(jìn)行major合并
• 選擇合適的HFile合并

  • 選取候選文件（排除不滿足條件的部分文件）
    1.排除當(dāng)前正在執(zhí)行compact的文件及其比這些文件更新的所有文件（sequenceld更大）
    2.排除某些過大的單個(gè)文件，如果文件大小大于hbase.hstore.compaction.max.size（默認(rèn)Long最大值），則被排除，否則會(huì)產(chǎn)生大量IO消耗

  • 判斷是否滿足major compaction條件
    1.用戶強(qiáng)制執(zhí)行major compaction
    2.長(zhǎng)時(shí)間沒有進(jìn)行（compactCompactionChecker的判斷條件2）且候選文件數(shù)小于hbase.hstore.compaction.max（默認(rèn)10）

    3. Store中含有Reference文件，Reference文件是split region產(chǎn)生的臨時(shí)文件，只是簡(jiǎn)單的引用文件，一般必須在compact過程中刪除

    如果不滿足major compaction條件，就必然為minor compaction，HBase主要有兩種minor策略：RatioBasedCompactionPolicy和ExploringCompactionPolicy，下面分別進(jìn)行介紹：

    RatioBasedCompactionPolicy

    從老到新逐一掃描所有候選文件，滿足其中條件之一便停止掃描：

    （1）當(dāng)前文件大小 < 比它更新的所有文件大小總和 * ratio，其中ratio是一個(gè)可變的比例，在高峰期時(shí)ratio為1.2，非高峰期為5，也就是非高峰期允許compact更大的文件。那什么時(shí)候是高峰期，什么時(shí)候是非高峰期呢？用戶可以配置參數(shù)hbase.offpeak.start.hour和hbase.offpeak.end.hour來設(shè)置高峰期

    （2）當(dāng)前所剩候選文件數(shù) <= hbase.store.compaction.min（默認(rèn)為3）

    停止掃描后，待合并文件就選擇出來了，即為當(dāng)前掃描文件+比它更新的所有文件

    ExploringCompactionPolicy

    該策略思路基本和RatioBasedCompactionPolicy相同，不同的是，Ratio策略在找到一個(gè)合適的文件集合之后就停止掃描了，而Exploring策略會(huì)記錄下所有合適的文件集合，并在這些文件集合中尋找最優(yōu)解。最優(yōu)解可以理解為：待合并文件數(shù)最多或者待合并文件數(shù)相同的情況下文件大小較小，這樣有利于減少compaction帶來的IO消耗。

2.hbase.hregion.max.filesize

• 默認(rèn)值：256M
• 說明：在當(dāng)前RegionServer上單個(gè)Region的大小，單個(gè)Region超過這個(gè)閥值時(shí)，這個(gè)Region會(huì)被自動(dòng)split成更小的region
• 調(diào)優(yōu)：當(dāng)hbase.hregion.max.filesize比較小時(shí)，觸發(fā)split的幾率更大，而split的時(shí)候會(huì)將region offline，因?yàn)樵趕plit結(jié)束的時(shí)間前，訪問該region的請(qǐng)求將被block（阻塞）住，客戶端block的時(shí)間默認(rèn)為1s。當(dāng)大量的region同時(shí)發(fā)生split時(shí)，系統(tǒng)的整體訪問服務(wù)將大受影響。因此容易出現(xiàn)吞吐量及響應(yīng)時(shí)間的不穩(wěn)定現(xiàn)象。
  當(dāng)hbase.hregion.max.filesize比較大時(shí)，單個(gè)region中觸發(fā)split的幾率較小，大量region同時(shí)觸發(fā)split的幾率也較小，因此吞吐量較之設(shè)置比較小的額時(shí)候更加穩(wěn)定些。但是由于長(zhǎng)期得不到split，因此同一個(gè)region內(nèi)發(fā)生多次compaction的機(jī)會(huì)增加了，由于region比較大，所以做一次compact和split會(huì)產(chǎn)生較長(zhǎng)時(shí)間的停頓，對(duì)應(yīng)用的讀寫性能沖擊非常大，另外大的region意味著大的storefile，compaction時(shí)對(duì)內(nèi)存也是一個(gè)挑戰(zhàn)。
  compaction的原理是將原有數(shù)據(jù)讀一遍并重寫一遍到hdfs上，然后再刪除原有數(shù)據(jù)。這種行為無疑會(huì)降低以IO為瓶頸的系統(tǒng)的速度，因此平均吞吐量會(huì)受到一些影響而下降
  所以，我們應(yīng)該自己管理split，將閾值設(shè)置高一些，然后每天在訪問量小的時(shí)候定時(shí)進(jìn)行split。
• 調(diào)整：自己管理split，首先禁用split，講閾值設(shè)置成100G（一般單個(gè)region是不可能達(dá)到100G的，看自身業(yè)務(wù)情況來定），然后使用regionSplitter工具每天在訪問量小的時(shí)候（凌晨）定時(shí)進(jìn)行split。

3.zookeeper.session.timeout

• 默認(rèn)值：3分鐘
• 說明：RegionServer與Zookeeper間的連接超時(shí)時(shí)間。當(dāng)超過時(shí)間后，RegionServer會(huì)被Zookeeper從集群清單中移除，HMaser收到移除通知后，會(huì)對(duì)這臺(tái)server負(fù)責(zé)的regions重新balance，讓其他存活的RegionServer接管
• 調(diào)優(yōu)：這個(gè)timeout決定了RegionServer是否能夠及時(shí)的failover。設(shè)置成一分鐘或者更低，可以減少因等待超時(shí)而被延長(zhǎng)的failover時(shí)間。
  不過需要注意的是，對(duì)于一些online應(yīng)用，RegionServer的宕機(jī)到恢復(fù)時(shí)間本身就很短的（網(wǎng)絡(luò)閃退，crash（死機(jī)）等故障，運(yùn)維可快速介入），如果這種情況下調(diào)低timeout時(shí)間，就會(huì)得不償失。因?yàn)楫?dāng)RegionServer被正式從集群中移除時(shí)，HMaser就開始做balance，當(dāng)故障的RegionServer快速恢復(fù)后，這個(gè)balance動(dòng)作是毫無意義的，反而會(huì)使負(fù)載不均勻，給集群帶來更多負(fù)擔(dān)。

4.hbase.regionserver.handler.count

• 默認(rèn)值：10
• 說明：RegionServer端開啟的RPC監(jiān)聽器實(shí)例個(gè)數(shù)，也即RegionServer能夠處理的IO請(qǐng)求線程數(shù)
• 調(diào)優(yōu)：這個(gè)參數(shù)的調(diào)優(yōu)與內(nèi)存息息相關(guān)。較少的IO線程，適用于處理單詞請(qǐng)求內(nèi)存消耗較高的big put場(chǎng)景（大容量單詞put或設(shè)置了較大cache的scan，均屬于big put）或RegionServer的內(nèi)存比較緊張的場(chǎng)景。
  較多的IO線程，適用于單詞請(qǐng)求內(nèi)存消耗低，TPS要求非常高的場(chǎng)景。
  這里需要注意的是如果server的region數(shù)量較少，大量的請(qǐng)求都會(huì)落到一個(gè)region上，因快速充滿memstore觸發(fā)flush導(dǎo)致的讀寫鎖會(huì)影響全局TPS，不是IO線程數(shù)越高越好。
• 調(diào)整： 50

5.hbase.regionserver.global.memstore.upperLimit/lowerLimit

• 默認(rèn)值：0.4/0.35
• upperlimit說明：hbase.hregion.memstore.flush.size這個(gè)參數(shù)的作用是當(dāng)單個(gè)memstore達(dá)到指定值時(shí)，flush該memstore。但是，一臺(tái)RegionServer可能有成百上千個(gè)memstore，每個(gè)memstore也許未達(dá)到flush.size，但是jvm的heap就不夠用。該參數(shù)就是為了限制memstore占用的總內(nèi)存。
• lowerlimit說明：同upperlimit，只不過當(dāng)全局memstore的內(nèi)存達(dá)到35%時(shí)，它不會(huì)flush所有的memstore，它會(huì)找一些內(nèi)存占用較大的memstore，個(gè)別flush，當(dāng)然更新時(shí)還是會(huì)被block。lowerlimit算是一個(gè)在全局flush前的補(bǔ)救措施。可以想象一下，如果memstore需要在一段時(shí)間內(nèi)全部flush，且這段時(shí)間內(nèi)無法接受寫請(qǐng)求，對(duì)hbase集群的性能影響是很大的。
• 調(diào)優(yōu)：這個(gè)一個(gè)Heap內(nèi)存保護(hù)參數(shù)，默認(rèn)值已經(jīng)能適用于大多數(shù)場(chǎng)景。它的調(diào)整一般是為了配合某些專屬優(yōu)化，比如讀密集型應(yīng)用，將讀緩存開大，降低該值，騰出更多內(nèi)存給其他模塊使用。
  這個(gè)參數(shù)會(huì)給使用者帶來什么影響？
  比如，10G內(nèi)存，100個(gè)region，每個(gè)memstore 64M，假設(shè)每個(gè)region只有一個(gè)memstore，那么當(dāng)100個(gè)memstore平均占用到50%左右，就會(huì)達(dá)到lowerlimit的限制。假設(shè)此時(shí)，其他memstore同樣有很多的寫請(qǐng)求進(jìn)來，在哪些大的region未flush完，就可能又超過upperlimit，則所有region都會(huì)被block，開始觸發(fā)全局flush

6.hfile.block.cache.size

• 默認(rèn)值：0.2
• 說明：storefile的讀緩存占用heap的大小百分比，0.2表示20%，該值直接影響數(shù)據(jù)讀的性能
• 調(diào)優(yōu)：當(dāng)然是越大越好，如果讀比寫多，可以設(shè)置到0.4到0.5。如果讀寫均衡，可以設(shè)置0.3左右，如果寫比讀多，保持默認(rèn)。設(shè)置這個(gè)值的時(shí)候，同時(shí)要參考hbase.regionserver.global.memstore.upperlimit，該值是memstore占heap的最大百分比，兩個(gè)參數(shù)一個(gè)影響讀，一個(gè)影響寫。如果兩值加起來超過80%~90%，會(huì)有OOM的風(fēng)險(xiǎn)，謹(jǐn)慎設(shè)置。

7.hbase.hstore.blockingStoreFiles

• 默認(rèn)值：7
• 說明：在compaction時(shí)，如果一個(gè)store（column family）內(nèi)有超過7個(gè)storefile需要合并，則block（阻塞）所有的寫請(qǐng)求進(jìn)行flush操作前進(jìn)行split或者compact，除非超過hbase.hstore.blockingWaitTime配置的時(shí)間，限制storefile數(shù)量增長(zhǎng)過快。
  compaction執(zhí)行結(jié)束之后會(huì)生成臨時(shí)文件，臨時(shí)文件的意義在于，在compaction執(zhí)行期間，對(duì)原數(shù)據(jù)的訪問沒有影響。compaction執(zhí)行合并操作生成的文件生效過程，需要對(duì)store的寫操作加鎖，阻塞store內(nèi)的更新操作，直到更新store的storefile完成為止
• 調(diào)優(yōu)：block請(qǐng)求會(huì)影響大年region的讀寫性能，最好可以將值設(shè)為單個(gè)region可以支撐的最大storefile數(shù)量。最大storefile數(shù)量可通過region size/memstore size來計(jì)算。如果你將region size 設(shè)為無限大，那么你需要預(yù)估一個(gè)region可能產(chǎn)生的最大storefile數(shù)。

8.hbase.hregion.memstore.block.multiplier

• 默認(rèn)值：2
• 說明：當(dāng)一個(gè)region里的memstore超過單個(gè)memstore.size兩倍的大小時(shí)，block該region的所有請(qǐng)求，進(jìn)行flush，釋放內(nèi)存。雖然我們?cè)O(shè)置了memstore的總大小，比如64M，但是如果在即將達(dá)到64M的時(shí)候，我們put了一個(gè)100M的數(shù)據(jù)或?qū)懻?qǐng)求量暴增，此時(shí)memstore的大小會(huì)瞬間暴漲到超過預(yù)期的memstore.size。這個(gè)參數(shù)的作用是當(dāng)memstore的大小增至超過memstore.size時(shí)，block所有請(qǐng)求，遏制風(fēng)險(xiǎn)進(jìn)一步擴(kuò)大。
• 調(diào)優(yōu)：這個(gè)參數(shù)的默認(rèn)值是比較靠譜的。如果你預(yù)估你正常場(chǎng)景下不會(huì)出現(xiàn)突發(fā)寫或?qū)懙牧靠煽?，那么保持默認(rèn)值即可。如果正常情況下，你的寫量就會(huì)經(jīng)常暴增，那么你應(yīng)該調(diào)大這個(gè)倍數(shù)并調(diào)整其他參數(shù)值，比如hfile.block.cache.size和hbase.regionserver.global.memstore.upperlimit/lowerlimit,以預(yù)留更多內(nèi)存，防止hbase server OOM