本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：禁止轉載，歡迎學習。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。

網上的Hbase調優資料參差不齊，實在是不忍卒讀，有些都是拼湊且版本過時的東西，我這裡決定綜合所有優質資源進行整合，寫一份最全，最有深度，不過時的技術部落格。辛苦成文，各自珍惜，謝謝！版權宣告：禁止轉載，歡迎學習，侵權必究！

1 Compaction機制是惹事王

• 莫名其妙的出現IO突然降低，調查的最終結果肯定就是Compaction造成的，但是Compaction又是絕對不可或缺的。因為資料刪除的操作並不會真正的刪除。

2 吞吐量的獲得

• Hbase 是執行在JVM內部的程式，如何獲取吞吐量呢？HBase內部具體操作就是通過【要合併的檔案大小/處理時間】得出的，如果上一次合併沒有發生，是無法獲取吞吐量的。

3 HBase吞吐量引數控制

• hbase.regionserver.throughput.controller:是限制合併和刷寫控制器選擇，具體場景具體選擇：

  • 控制合併相關指標：PressureAwareCompactionThroughputController
  • 控制刷寫相關指標：PressureAwareFlushThroughputController

  預設值是：PressureAwareCompactionThroughputController

• hbase.hstore.blockingStoreFiles:當StoreFile數量達到該值時，阻塞MemStore刷寫動作，注意這裡不會阻塞寫入請求。

• hbase.hstore.compaction.throughput.lower.bound:合併佔用吞吐量下限。

• hbase.hstore.compaction.throughput.higher.bound:合併佔用吞吐量上限。

4 hbase.hstore.blockingStoreFiles 殺手鐗

• 預設值是7，當Store中的HFile數量達到這個數量的時候就會阻塞MemStore刷寫動作，注意這裡不會阻塞寫入請求。

• 當HFile數量達到這個阻塞值後，會發生MemStore的佔用記憶體數量急劇上升，因此，可能很快的到達Memstore的寫入上限：

        hbase.hregion.memstore.flush.size * hbase.hregion.memstore.block.multiplier
  

此時HBase叢集就崩潰了。所以需要適當的調大hbase.hstore.blockingStoreFiles數值，比如調到20，30，50都差不多，因為HFile檔案越多，資料的讀取效能會有所下降。但並不會產生致命的阻塞響應。

本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：禁止轉載，歡迎學習。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。

5 合併刷寫與吞吐量的權衡策略

• hbase.offpeak.start.hour: 每天非高峰的起始時間，取值為0-23的整數，包含0和23。

• hbase.offpeak.end.hour: 每天非高峰的結束時間，取值為0-23的整數，包含0和23。

• hbase.hstore.compaction.throughput.lower.bound: 預設是10MB/sec。

• hbase.hstore.compaction.throughput.higher.bound:預設是20MB/sec。

• pressureRatio:壓力比，限制合併時，該引數就是合併壓力，限制刷寫時，該引數就是刷寫壓力。這個值就是0-1.0。是一個監控計算值。當大於1時，說明壓力太大了，再不合並，叢集就不能工作了，pressureRatio越大，代表HFile堆積得越多，或者即將產生越多的HFile。

• 在非高峰期是不會進行吞吐量限速的，只有在高峰期期間當合並/刷寫佔用了太大的吞吐量才會休眠，休眠意味著為業務相應留出足夠的吞吐量。休眠吞吐量的計算方式為：

     lowerBound + (upperBound-lowerBound)*pressureRatio
  

• 因為保證業務響應的流暢度和合並刷寫穩定性（不至於因為HFile過多導致系統阻塞）同等重要，但是卻可以進行權衡出優先順序。

6 pressureRatio 的孵化

• 合併壓力（compactionPressure）
• 刷寫壓力（flushPressure）

合併壓力計算公式：

（storefileCount-minFilesToCompact）/(blockingFileCount-minFilesToCompact)

• storefileCount:當前StoreFile數量

• minFilesToCompact:單次合併檔案數量下限（hbase.hstore.compaction.min）

• blockingFileCount:就是hbase.hstore.blockingStoreFiles。

  結論: 當前StoreFile越大，或者阻塞上限越小，那麼合併的壓力就越大，因為可能發生阻塞。

刷寫壓力計算公式：

globalMemstoreSize/memstoreLowerLimitSize

• globalMemstoreSize:當前全域性的Memstore大小。
• memstoreLowerLimitSize：Memstore刷寫下限，當全域性Memstore達到這個記憶體佔用的數量的時候就會開始刷寫。
  
  結論：當前全域性的Memstore佔用的記憶體越大，或者刷寫的觸發條件越小，越有可能引發刷寫。最壞結果就是HFile檔案數量會越來越多，從而觸發阻塞。

結論

通過本文總結一切豁然開朗，你呢？

本套技術專欄是作者（秦凱新）平時工作的總結和昇華，通過從真實商業環境抽取案例進行總結和分享，並給出商業應用的調優建議和叢集環境容量規劃等內容，請持續關注本套部落格。版權宣告：禁止轉載，歡迎學習。QQ郵箱地址：[email protected]，如有任何學術交流，可隨時聯絡。

秦凱新 於深圳