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

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

   下面這種圖是HBase的存儲架構圖，網上也有很多我這里就不講了：

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

HBase Compaction機制介紹：

    HBase Compaction分類：

a.Minor Compaction  小合并

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

 b.Major Compaction 大合并

    將所有的StoreFile合并成一個StoreFile，這個過程會清理三種數據：被刪除的數據、TTL過期數據、版本號超過設定版本號的數據(VERSION）。

    注意：

    major compaction一般執行時間比較長，且耗資源比較大，由參數hbase.hregion.majorcompaction控制默認的執行周期是7天，生產集群一般將其關閉，等業務量較少或者晚上執行。

    設置hbase.hregion.majorcompaction = 0可以關閉CompactionChecke觸發的major compaction，但是無法關閉用戶調用級別的mc。

Compaction的作用：

    a.合并文件

    b.清除刪除、過期、多余版本的數據

    c.提高讀寫數據的效率

Compaction的觸發條件

    a.hbase shell中的compact或者major_compact請求

   b..memstore flush后,都會判斷是否要進行compaction，一旦滿足minor compaction或major compaction的條件便會觸發執行。

    c.響應api中的majorCompact（ ） 

    d.后臺線程輪詢 ，HBase后臺線程CompactionChecker 會定期檢查是否需要執行compaction，檢查周期為兩個參數乘積：

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

參數解釋：

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

  hbase.server.compactchecker.interval.multiplier 默認值1000s，是compaction操作周期性檢查乘數因子。

所以執行周期默認是：

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

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

這里默認取值就是10*1000就是10秒：

注意：

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

    對每個HStore進行一次判斷，needsCompaction()判斷是否足夠多的文件觸發了Compaction的條件。

    條件為：

    HStore中StoreFIles的個數 – 正在執行Compacting的文件個數 > minFilesToCompact

minFilesToCompact：默認為3,即超過3個hfile文件則啟動合并。

CompactionChecker線程中會有個函數needsCompaction()，先去判斷是否需要執行，代碼如下：

Minor Compaction和Major Compaction有一些相關的參數，網上有很多 ，我覺得這幾個可能需要調整，其他都默認比較好：

1).hbase.hregion.majorcompaction:

    配置major合并的間隔時間，默認為7天，可設置為0，禁止自動的major合并，可手動或者通過腳本定期進行major合并。

2).hbase.hstore.compaction.max:

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

3).hbase.hstore.compactionThreshold:

    設置執行Compaction(Major && Minor)操作的閾值，默認是3，如果想降低過頻繁的合并操作，可以稍微調大一點，對于HBase負載較重的系統，可以設置成5。

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

    文件大小 > 該參數值的StoreFile將會被排除，不會加入minor compaction，默認值Long.MAX_VALUE，表示沒有什么限制。一般情況下也不建議調整該參數。

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

    默認值為1，regionserver做Minor Compaction時線程池里線程數目,可以設置為5。

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

    默認值為1，regionserver做Major Compaction時線程池里線程數目，可以設置為8。

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

    默認值10，compaction過程中，每次從Hfile中讀取kv的個數，內存夠的話可適當調大。

Minor Compaction和Major Compaction對讀寫的影響：

 1).首先Compaction涉及到磁盤的讀寫，肯定會增加了整個集群的io負擔。

 2).對寫的影響：

  這里主要有兩個參數：

    hbase.hstore.blockingStoreFiles

    hbase.hstore.blockingWaitTime

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

3).對讀的影響：

    Compaction操作會帶來很大的帶寬壓力以及短時間IO壓力。因此compaction就是使用短時間的IO消耗以及帶寬消耗換取后續查詢的低延遲。這種短時間的壓力就會造成讀請求在延時上會有比較大的波動。

看完上述內容，你們對如何解析HBase大合并與小合并有進一步的了解嗎？如果還想了解更多知識或者相關內容，請關注億速云行業資訊頻道，感謝大家的支持。