1 HBase Compact 功能剖析

Compaction會從一個region的一個store中選擇一些hfile檔案進行合併。合併說來原理很簡單，先從這些待合併的資料檔案中讀出KeyValues，再按照由小到大排列後寫入一個新的檔案中。之後，這個新生成的檔案就會取代之前待合併的所有檔案對外提供服務。HBase根據合併規模將Compaction分為了兩類：MinorCompaction和MajorCompaction

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

• Major Compaction是指將所有的StoreFile合併成一個StoreFile，這個過程還會清理三類無意義資料：被刪除的資料、TTL過期資料、版本號超過設定版本號的資料。另外，一般情況下，Major Compaction時間會持續比較長，整個過程會消耗大量系統資源，對上層業務有比較大的影響。因此線上業務都會將關閉自動觸發Major Compaction功能，改為手動在業務低峰期觸發。

• 下列三個條件可能會觸發compaction請求：

  1. memstore flush之後觸發；

  2. 客戶端通過shell或者API觸發；

  3. 後臺執行緒CompactionChecker定期觸發，週期為：

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

  4. 對於MajorCompact，觸發了compaction請求後，真正的compaction操作能否執行，還要進行一系列的條件驗證， 即由hbase.hregion.majorcompaction和hbase.hregion.majorcompaction.jitter控制的一組條件。

  5. 對於MiniCompact當檔案大小小於hbase.hstore.compaction.min.size 則會立即被新增到合併佇列，當storeFile數量超過hbase.hstore.compaction.min時，minor compaction才會啟動。

1.1 Hbase MinorCompact 引數設定

hbase.hregion.memstore.flush.size：640M
hbase.hregion.max.filesize  :100M  觸發split
hbase.hstore.compaction.min : 滿足條件 3 minor compaction才會啟動
hbase.hstore.compaction.ratio ：預設為1.2
hbase.hregion.majorcompaction : 0 關掉major compact
hbase.hstore.compaction.max : 預設值為10，表示一次minor compaction中最多選取10個store file
hbase.hstore.compaction.min : 預設值為 3
hbase.hstore.compaction.min.size ：640M （未壓縮？為memestoreFlushSize）

• hbase.hstore.compaction.ratio ：預設為1.2 ，將store file 按照檔案年齡排序（older to younger），minor compaction總是從older store file開始選擇，如果該檔案的size 小於它後面hbase.hstore.compaction.max 個store file size 之和乘以 該ratio，則該store file 也將加入到minor compaction 中。

• hbase.hstore.blockingStoreFiles：HStore的storeFile的檔案數大於配置值，則在flush memstore前先進行split或者compact，除非超過hbase.hstore.blockingWaitTime配置的時間，預設為7，可調大，比如：100，避免memstore不及時flush，當寫入量大時，觸發memstore的block，從而阻塞寫操作。

• hbase.hregion.max.filesize ：預設值是256M 當hbase.hregion.max.filesize比較小時，觸發split的機率更大，而split的時候會將region offline，因此在split結束的時間前，訪問該region的請求將被block住，客戶端自我block的時間預設為1s。當大量的region同時發生split時，系統的整體訪問服務將大受影響。因此容易出現吞吐量及響應時間的不穩定現象

• hbase.hregion.max.filesize ： 當hbase.hregion.max.filesize比較大時，單個region中觸發split的機率較小，大量region同時觸發split的機率也較小，因此吞吐量較之小hfile尺寸更加穩定些。但是由於長期得不到split，因此同一個region內發生多次compaction的機會增加了。compaction的原理是將原有資料讀一遍並重寫一遍到hdfs上，然後再刪除原有資料。無疑這種行為會降低以io為瓶頸的系統的速度，因此平均吞吐量會受到一些影響而下降

• hbase.hregion.max.filesize 這個值過大，讀寫hbase的速度會變慢，因為底層對hdfs的讀寫操作由於檔案數量少，很難做到高併發，高吞吐，過小會發生頻繁的檔案split，split過程會使資料短暫離線，會對資料的訪問有一定影響，不太穩定，所以這個值不能太小也不能太大，100-200MB基本能滿足需求

• 基於檔案大小進行合併

    hbase.hstore.compaction.min.size 表示檔案大小小於該值的store file 一定會加入到minor compaction的store file中
    hbase.hstore.compaction.max.size Long.MAX_VALUE  表示檔案大小大於該值的store file 一定會被minor compaction排除
  

• 基於檔案數量進行合併

    hbase.hstore.compaction.min :預設值為 3，表示至少需要三個滿足條件的store file時，minor compaction才會啟動
    hbase.hstore.compaction.max :預設值為10，表示一次minor compaction中最多選取10個store file
  

• hbase.hstore.blockingWaitTime block的等待時間 線上配置：90000（90s） 預設配置：90000（90s）

1.2 Hbase MinorCompact 功能

    為了本文的主題，此處參考了一篇非常好的部落格，僅限該小節：https://blog.csdn.net/u014297175/article/details/50456147

• 刷入一個54.4M的檔案，在此觸發一次Minor合併。從最早的檔案，66.5G的開始，它顯然比它後面幾個檔案（按配置是10個檔案Ratio的大小），但他後面本不足10個檔案，因此直接計入所有檔案大小總和1.2。顯然，它的大小超過了這個值，因此不納入Minor合併，同理一直到666.4M檔案，它也不小於54.3M*1.2所以不納入合併，因此這波參與合併的只有54.3M檔案，暫且等待下一個刷寫檔案。

• 刷入一個54M的檔案，這時進入合併流程，因為hbase.hstore.compaction.min=3，兩個54M檔案並未參與到合併。

• 最後刷入一個54M的檔案，3個54M檔案合併成為一個150M的檔案，其實這是3個54M一起合併的檔案。但是那個666.4M的檔案仍然不能納入合併佇列。

         注意：後面會不斷判斷進行Older to younger 的合併，但是這個154M的檔案會納入合併佇列，因為當檔案大小小於
         hbase.hstore.compaction.min.size（為memestoreFlushSize） 則會立即被新增到合併佇列。

1.2 Hbase MajorCompact 引數設定

MajorCompact 條件：

• hbase.hregion.majorcompaction：預設是24小時 hbase.hregion.majorcompaction.jitter：抖動，預設是20% 以上兩個引數意味著major合併週期為隨機取19.2小時~28.8小時之間的數值。當major合併週期還未到達時，執行minor合併。

1.3 split 引數設定

一個reion達到一定的大小，他會自動split稱兩個region。如果我們的Hbase版本是0.94 ，那麼預設的有三種自動split的策略，ConstantSizeRegionSplitPolicy,IncreasingToUpperBoundRegionSplitPolicy還有 KeyPrefixRegionSplitPolicy.

1.4 MVCC 多版本控制