HBase 壓縮佇列告警最佳化
線上告警現象
線上告警閾值大小是20，而平時的壓縮佇列大小能達到：50~100。
壓縮佇列大小怎麼算
那麼，這個壓縮佇列大小，是如何統計的呢？
查閱了很多資料，以下解釋都是錯誤的：
這三種解釋，都是錯誤的，也正是網上鋪天蓋地的這種文章，導致我在追查問題時，一直查不到。
那麼，真正的大小是如何統計的呢？
下面是官方文件：http://hbase.apache.org/2.2/book.html#hbase_metrics
hbase.regionserver.compactionQueueLength
Current depth of the compaction request queue. If increasing, we are falling behind with storefile compaction.
我們透過官方文件的關鍵詞來檢視它的統計規則。
在HBase原始碼中搜索關鍵詞“compactionQueueLength”
HBase在進行Compaction時，會通過當前需要合併的檔案個數來決定使用哪個執行緒池去進行compaction。
HBase中有兩個執行緒池：longThreadPool和smalThreadPool。所以，這裡有3個QueueLength，一個是總和。
而我們在監控看板看到的就是總和。
進一步搜尋它的引用，可以看到它的上報程式碼：
這兩個預設值大小都是1。
也就是說，當需要進行compaction時，去申請執行緒，當有可用執行緒時，去進行compaction操作。因為核心執行緒數為1，所以，後來的compaction request將會被加入到佇列中。
線上壓縮佇列比較高意味著，compaction動作很慢，而寫入速度很快，導致大部分compaction request都在佇列中等待。
造成壓縮佇列過大的原因是什麼
那麼是什麼原因造成Compaction動作很慢呢？
當待合併的檔案很大時，compaction動作會很慢。
compaction有minor compaction 和 major compaction兩種，minor compaction 一般很快，除非在進行minor compaction時，同時也在做major compaction，由於限速的原因導致minor compaction持續時間長。而major compaction是進行全部檔案的compaction，比較慢，持續時間久。
所以猜測，線上是發生了major compaction。
透過查詢線上hbase日誌，可以看到：
大部分時間都和告警相吻合。
也就是說，在進行 Major Compaction時，核心執行緒被佔用，導致後面的compaction request都被阻塞。
為了確定這個猜測是否正確，我選了一個時間點，來看這一個小時內的日誌是否和我們猜測一致。
我們看到，major compaction持續了23分鐘。而同時，這個時間段，還有一個1.6G的compaction。
這個持續了30分鐘。6.7G的major compaction 走的時候large執行緒池(大於2.5G)，1.6G的走的是small執行緒池(小於2.5G)，兩個大的compaction都佔用了核心執行緒池，導致flush後的資料發生compaction request時，只能等待。因此壓縮佇列會持續增高。
解決問題
上面分析了引起compaction阻塞的原因。
瞭解了原因，那麼，解決壓縮佇列大小的方法就很容易了。
以上幾點是對壓縮佇列過大的調整。
HBase 壓縮佇列告警最佳化
線上告警現象
線上告警閾值大小是20，而平時的壓縮佇列大小能達到：50~100。
壓縮佇列大小怎麼算
那麼，這個壓縮佇列大小，是如何統計的呢？
查閱了很多資料，以下解釋都是錯誤的：
正在進行壓縮的HFile數量正在壓縮的HStore數量等待壓縮的HFile數量這三種解釋，都是錯誤的，也正是網上鋪天蓋地的這種文章，導致我在追查問題時，一直查不到。
那麼，真正的大小是如何統計的呢？
下面是官方文件：http://hbase.apache.org/2.2/book.html#hbase_metrics
hbase.regionserver.compactionQueueLength
Current depth of the compaction request queue. If increasing, we are falling behind with storefile compaction.
我們透過官方文件的關鍵詞來檢視它的統計規則。
在HBase原始碼中搜索關鍵詞“compactionQueueLength”
HBase在進行Compaction時，會通過當前需要合併的檔案個數來決定使用哪個執行緒池去進行compaction。
HBase中有兩個執行緒池：longThreadPool和smalThreadPool。所以，這裡有3個QueueLength，一個是總和。
而我們在監控看板看到的就是總和。
進一步搜尋它的引用，可以看到它的上報程式碼：
這兩個預設值大小都是1。
也就是說，當需要進行compaction時，去申請執行緒，當有可用執行緒時，去進行compaction操作。因為核心執行緒數為1，所以，後來的compaction request將會被加入到佇列中。
線上壓縮佇列比較高意味著，compaction動作很慢，而寫入速度很快，導致大部分compaction request都在佇列中等待。
造成壓縮佇列過大的原因是什麼
那麼是什麼原因造成Compaction動作很慢呢？
當待合併的檔案很大時，compaction動作會很慢。
compaction有minor compaction 和 major compaction兩種，minor compaction 一般很快，除非在進行minor compaction時，同時也在做major compaction，由於限速的原因導致minor compaction持續時間長。而major compaction是進行全部檔案的compaction，比較慢，持續時間久。
所以猜測，線上是發生了major compaction。
透過查詢線上hbase日誌，可以看到：
大部分時間都和告警相吻合。
也就是說，在進行 Major Compaction時，核心執行緒被佔用，導致後面的compaction request都被阻塞。
為了確定這個猜測是否正確，我選了一個時間點，來看這一個小時內的日誌是否和我們猜測一致。
我們看到，major compaction持續了23分鐘。而同時，這個時間段，還有一個1.6G的compaction。
這個持續了30分鐘。6.7G的major compaction 走的時候large執行緒池(大於2.5G)，1.6G的走的是small執行緒池(小於2.5G)，兩個大的compaction都佔用了核心執行緒池，導致flush後的資料發生compaction request時，只能等待。因此壓縮佇列會持續增高。
解決問題
上面分析了引起compaction阻塞的原因。
待合併的檔案太大，導致持續時間久minor compaction觸發頻率高(預設3個則觸發)核心執行緒池數量太小，導致其他被阻塞瞭解了原因，那麼，解決壓縮佇列大小的方法就很容易了。
HBase 2.0 提供了in memory compaction開啟in memory compaction，具體哪種策略，根據業務場景決定，我們使用的是basic方式。從flush日誌可以瞭解到，heap size 達到128M的時候，data size只有50M，而刷盤以後經過壓縮，檔案大小隻有10~20M。之所以會出現這種情況，原因上一篇也介紹過，HBase的記憶體結果使用的是跳躍表，跳躍表是以空間換時間的一種方式，所以，記憶體會被浪費。而in memory compaction會讓記憶體更緊湊，它會使flush頻率降低，從而，會降低compaction頻率提高compaction執行緒池由於大檔案的compaction會阻塞小檔案的compaction執行，所以，可以增大核心執行緒數，將核心執行緒數由1調整為3。增大compaction的最小檔案數閾值預設HFile達到3個時會進行compaction，可以將3調整為5，讓compaction頻率降低全域性檢查RegionServer是否發生熱點檢查整個HBase叢集上的RegionServer是否發生了熱點。如果發生了熱點，讓RegionServer都均勻一點調整待合併檔案的最大閾值由於我們的資料是時間序列，由opentsdb寫入，大部分歷史資料很少被範圍查詢，所以，我們讓歷史資料不進行compaction，從而降低單次compaction的檔案總大小。目前我們由最大值更改為5G。即，超過5G的檔案都不進行compaction。調整compaction速度上一篇文章介紹過了compaction速度控制，可以通過幾個引數來調整compaction速度，讓compaction儘快完成。以上幾點是對壓縮佇列過大的調整。