目錄

?

問題

問題原因分析

總結建議

---

問題

?前幾天朋友公司Hbase集群出現Compaction隊列持續處于比較大的情況，并且mem flush隊列也比較大，一起看了下問題，大概情況如下圖

從圖中可以看出來壓縮隊列總和持續在1000-2000，平對壓縮隊列在200左右，刷新隊列也比較高，當然壓縮隊列高的原因就是因為我們 MemStore?Flush?比較頻繁，導致寫入的StoreFile數量增加，觸發了Compcation。

問題原因分析

?

我們先說下什么情況下會觸發Compaction

1.后臺線程周期性檢查：

multiplier=1000，chore定期執行，每隔 hbase.server.thread.wakefrequency=10秒 默認 10 * 1000,也就是每隔10s*1000=10000s=2.77小時，會執行一次

具體介紹可以參考：https://datamining.blog.csdn.net/article/details/104711339

2.MemStore?Flush

觸發時機可以參考：https://datamining.blog.csdn.net/article/details/82745205

3.手動觸發

?

根據上面CDH的監控頁面我們推測是MemStore?Flush?刷新頻繁導致的問題

查看Hbase集群相關信息

當前配置參數為：

hbase.hregion.memstore.flush.size = 512M hbase.hregion.memstore.block.multiplier = 20 hbase.hstore.compactionThreshold (hbase.hstore.compaction.min) = 3 hbase.hstore.compaction.max = 10 hbase.hstore.blockingStoreFiles = 16 hbase.regionserver.global.memstore.size=0.4 hbase RegionServer 堆內存 16g

region個數為3000左右，平均每臺服務器300個region左右?

這里介紹下參數的含義

配置參數	默認值	含義
hbase.hregion.memstore.flush.size	128M	MemStore達到該值會Flush成StoreFile
hbase.hregion.memstore.block.multiplier	4	當region中所有MemStore大小超過hbase.hregion.memstore.flush.size*hbase.hregion.memstore.block.multiplier服務則停止寫入
hbase.hstore.compactionThreshold (hbase.hstore.compaction.min)	3	當一個 Store 中?HFile 文件數量超過該閾值就會觸發一次 Compaction（Minor Compaction）
hbase.hstore.compaction.max	10	一次 Compaction 最多合并的 HFile 文件數量，超過該值的文件會被過濾掉，本次不做Compcation
hbase.hstore.blockingStoreFiles	16	一個 Store 中 HFile 文件數量達到該值就會阻塞寫入，等待 Compaction 的完成
hbase.regionserver.global.memstore.size	0.4	regionServer的全局memstore的大小，超過該大小會觸發flush到磁盤的操作,默認是堆大小的40%,而且regionserver級別的flush會阻塞客戶端讀寫

?

?

?

?

?

?

?

?

?

?

?

對不合理的參數進行修改，修改后配置為

hbase.hregion.memstore.flush.size = 256M hbase.hregion.memstore.block.multiplier = 8 hbase.hstore.compactionThreshold (hbase.hstore.compaction.min) = 10 hbase.hstore.compaction.max = 20 hbase.hstore.blockingStoreFiles = 50 hbase RegionServer 堆內存 16g

hbase.hregion.memstore.flush.size

如果我們每個region寫入數據都比較平均的話，當每個region的MemStore?大小達到? 22M（下面有計算公式）就會觸發RegionServer級別的Flush，所以集群中沒有必要設置到512，我們改成256（其實改回默認128也不會影響）

16( RS JVM ) * 1024M * 0.4 / 300(region個數)?≈ 22?M?

hbase.hregion.memstore.block.multiplier?

該值是為了防止寫入數據量過大導致服務停止寫入，上面有解釋，該值不宜設置過大，一般使用默認即可，這里我們暫時設置為8

hbase.hstore.compactionThreshold (hbase.hstore.compaction.min)

MemStore?Flush?默認至少每一個小時會自動Flush一次數據（其他條件不滿足，會系統自動flush），當StoreFile達到該值會觸發Minor?Compaction，線上我們可以調大該參數，這里設置為10

hbase.hstore.compaction.max

最大合并文件數量，我們設置為20，該值要比hbase.hstore.compactionThreshold大

hbase.hstore.blockingStoreFiles

一個Store中文件數量大于該值就停止寫入，生產環境可以調整大一些，我們調整為50

?

重啟服務，持續觀察一段時間，看看效果如何

觀察了一段時間，發現每次MemStore?Flush?還是會導致隊列很大

用工具看了下當前的Compaction壓縮狀態，查看下正在壓縮的region，發現該region只有三個StoreFile就開始Compaction，再仔細一看正在執行的Compaction的Region都是在?hbase.hregion.majorcompaction?時間范圍內。

?

去看了下配置，MajorCompaction的確沒有關閉，實際生產環境我們可以根據每個Region下的StoreFile數量、大小，自行進行判斷何時執行MajorCompaction，設置為手動就可以，能更靈活的運用服務器，將?hbase.hregion.majorcompaction?設置為 0 ，等待一段時間觀察效果

?

總結建議

1.合理的控制MemStoreFlush頻率

2.合理的進行表的預分區，提前進行數據量預估，減少表的分裂（在某些特定的業務下，可以禁止Region分裂，比如該表的數據大小我們可以預估出來）

3.盡量手動執行MajorCompaction

4.Region個數不宜太多

最佳數量：((RS memory) * (total memstore fraction)) / ((memstore size)*(# column families))? =16 *1024 * 0.4 /（256*1）= 25.6

實際使用，我們一般不會用這么少，我們公司配置是32G，管理著400Region左右，目前來看沒什么影響

Hbase Compaction 源碼分析 - CompactionChecker：https://datamining.blog.csdn.net/article/details/104711339

Hbase Memstore刷新方式與Region的數目上限：https://datamining.blog.csdn.net/article/details/82745205

總結

以上是生活随笔為你收集整理的Hbase Compaction 队列数量较大分析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。