如何解析HBase大合并與小合并

今天就跟大家聊聊有關(guān)如何解析HBase大合并與小合并，可能很多人都不太了解，為了讓大家更加了解，小編給大家總結(jié)了以下內(nèi)容，希望大家根據(jù)這篇文章可以有所收獲。

   下面這種圖是HBase的存儲(chǔ)架構(gòu)圖，網(wǎng)上也有很多我這里就不講了：

    隨著用戶的持續(xù)寫入,磁盤HFile文件就會(huì)越來越多，元數(shù)據(jù)也越來越多，單次HBase的查詢就需要越來越多的IO操作，增加上查詢的耗時(shí)，為了優(yōu)化查詢性能，HBase會(huì)合并小的HFile以減少文件數(shù)量，HBase設(shè)計(jì)了Compaction機(jī)制。

HBase Compaction機(jī)制介紹：

    HBase Compaction分類：

a.Minor Compaction  小合并

    指選取一些小的、相鄰的StoreFile將他們合并成一個(gè)更大的StoreFile，在這個(gè)過程中不會(huì)處理已經(jīng)Deleted或Expired的Cell。一次 Minor Compaction 的結(jié)果是更少并且更大的StoreFile。

 b.Major Compaction 大合并

    將所有的StoreFile合并成一個(gè)StoreFile，這個(gè)過程會(huì)清理三種數(shù)據(jù)：被刪除的數(shù)據(jù)、TTL過期數(shù)據(jù)、版本號(hào)超過設(shè)定版本號(hào)的數(shù)據(jù)(VERSION）。

    注意：

    major compaction一般執(zhí)行時(shí)間比較長，且耗資源比較大，由參數(shù)hbase.hregion.majorcompaction控制默認(rèn)的執(zhí)行周期是7天，生產(chǎn)集群一般將其關(guān)閉，等業(yè)務(wù)量較少或者晚上執(zhí)行。

    設(shè)置hbase.hregion.majorcompaction = 0可以關(guān)閉CompactionChecke觸發(fā)的major compaction，但是無法關(guān)閉用戶調(diào)用級(jí)別的mc。

Compaction的作用：

    a.合并文件

    b.清除刪除、過期、多余版本的數(shù)據(jù)

    c.提高讀寫數(shù)據(jù)的效率

Compaction的觸發(fā)條件

    a.hbase shell中的compact或者major_compact請(qǐng)求

   b..memstore flush后,都會(huì)判斷是否要進(jìn)行compaction，一旦滿足minor compaction或major compaction的條件便會(huì)觸發(fā)執(zhí)行。

    c.響應(yīng)api中的majorCompact（ ） 

    d.后臺(tái)線程輪詢 ，HBase后臺(tái)線程CompactionChecker 會(huì)定期檢查是否需要執(zhí)行compaction，檢查周期為兩個(gè)參數(shù)乘積：

 hbase.server.thread.wakefrequency*hbase.server.compactchecker.interval.multiplier

參數(shù)解釋：

    hbase.server.thread.wakefrequency 默認(rèn)值 10000 即 10s，是HBase服務(wù)端線程喚醒時(shí)間間隔，用于log roller、memstore flusher等操作周期性檢查；

  hbase.server.compactchecker.interval.multiplier 默認(rèn)值1000s，是compaction操作周期性檢查乘數(shù)因子。

所以執(zhí)行周期默認(rèn)是：

        10 * 1000 s 時(shí)間上約等于2hrs, 46mins, 40sec。

我這里從源碼中截了兩張圖，有興趣你可以去看下HBase的源碼：

這里默認(rèn)取值就是10*1000就是10秒：

注意：

    這里需要注意的是CompactionChecker線程即使到了執(zhí)行的時(shí)間，也不一定執(zhí)行major compaction，還需要滿足另外一個(gè)條件：

    對(duì)每個(gè)HStore進(jìn)行一次判斷，needsCompaction()判斷是否足夠多的文件觸發(fā)了Compaction的條件。

    條件為：

    HStore中StoreFIles的個(gè)數(shù) – 正在執(zhí)行Compacting的文件個(gè)數(shù) > minFilesToCompact

minFilesToCompact：默認(rèn)為3,即超過3個(gè)hfile文件則啟動(dòng)合并。

CompactionChecker線程中會(huì)有個(gè)函數(shù)needsCompaction()，先去判斷是否需要執(zhí)行，代碼如下：

Minor Compaction和Major Compaction有一些相關(guān)的參數(shù)，網(wǎng)上有很多 ，我覺得這幾個(gè)可能需要調(diào)整，其他都默認(rèn)比較好：

1).hbase.hregion.majorcompaction:

    配置major合并的間隔時(shí)間，默認(rèn)為7天，可設(shè)置為0，禁止自動(dòng)的major合并，可手動(dòng)或者通過腳本定期進(jìn)行major合并。

2).hbase.hstore.compaction.max:

    設(shè)置執(zhí)行Compaction(包括Major &Minor)的待合并文件的最大個(gè)數(shù)。默認(rèn)值為10，如果超過該設(shè)置值，會(huì)對(duì)部分文件執(zhí)行一次MinorCompaction,線上一般配置值30。

3).hbase.hstore.compactionThreshold:

    設(shè)置執(zhí)行Compaction(Major && Minor)操作的閾值，默認(rèn)是3，如果想降低過頻繁的合并操作，可以稍微調(diào)大一點(diǎn)，對(duì)于HBase負(fù)載較重的系統(tǒng)，可以設(shè)置成5。

4).hbase.hstore.compaction.max.size

    文件大小 > 該參數(shù)值的StoreFile將會(huì)被排除，不會(huì)加入minor compaction，默認(rèn)值Long.MAX_VALUE，表示沒有什么限制。一般情況下也不建議調(diào)整該參數(shù)。

5).hbase.regionserver.thread.compaction.small:

    默認(rèn)值為1，regionserver做Minor Compaction時(shí)線程池里線程數(shù)目,可以設(shè)置為5。

6).hbase.regionserver.thread.compaction.large:

    默認(rèn)值為1，regionserver做Major Compaction時(shí)線程池里線程數(shù)目，可以設(shè)置為8。

7).hbase.hstore.compaction.kv.max

    默認(rèn)值10，compaction過程中，每次從Hfile中讀取kv的個(gè)數(shù)，內(nèi)存夠的話可適當(dāng)調(diào)大。

Minor Compaction和Major Compaction對(duì)讀寫的影響：

 1).首先Compaction涉及到磁盤的讀寫，肯定會(huì)增加了整個(gè)集群的io負(fù)擔(dān)。

 2).對(duì)寫的影響：

  這里主要有兩個(gè)參數(shù)：

    hbase.hstore.blockingStoreFiles

    hbase.hstore.blockingWaitTime

    如果底層HFile數(shù)量超過hbase.hstore.blockingStoreFiles 配置值，默認(rèn)10,flush操作將會(huì)受到阻塞，阻塞時(shí)間為hbase.hstore.blockingWaitTime，默認(rèn)90000,在這段時(shí)間內(nèi)，如果compaction操作使得HFile下降到blockingStoreFiles配置值，則停止阻塞。另外阻塞超過時(shí)間后，也會(huì)恢復(fù)執(zhí)行flush操作。這樣做可以有效地控制大量寫請(qǐng)求的速度，但同時(shí)這也是影響寫請(qǐng)求速度的主要原因之一。

3).對(duì)讀的影響：

    Compaction操作會(huì)帶來很大的帶寬壓力以及短時(shí)間IO壓力。因此compaction就是使用短時(shí)間的IO消耗以及帶寬消耗換取后續(xù)查詢的低延遲。這種短時(shí)間的壓力就會(huì)造成讀請(qǐng)求在延時(shí)上會(huì)有比較大的波動(dòng)。

看完上述內(nèi)容，你們對(duì)如何解析HBase大合并與小合并有進(jìn)一步的了解嗎？如果還想了解更多知識(shí)或者相關(guān)內(nèi)容，請(qǐng)關(guān)注億速云行業(yè)資訊頻道，感謝大家的支持。