業務背景

OpenTSDB 是一款非常適合存儲海量時間序列數據的開源軟件，使用 HBase 作為存儲讓它變的非常容易擴展。我們在建設美團性能監控平臺的過程中，每天需要處理數以億計的數據，經過幾番探索和調研，最終選取了 OpenTSDB 作為數據存儲層的重要組件。OpenTSDB 的安裝和配置過程都比較簡單，但是在實際的業務應用中，還是會出現這樣那樣的問題，本文詳細介紹我們在OpenTSDB 實際使用過程中遇到的 HBase 整點壓力過大的問題，期望對大家有些參考意義。

問題的出現

性能監控平臺使用 OpenTSDB 負責存儲之后不久（創建的表名稱是 tsdb-perf），數據平臺組的同事發現，tsdb-perf 這個表在最近這段時間每天上午 10 點左右有大量的讀操作，造成 HBase 集群壓力過大，但是想去分析問題的時候發現讀操作又降為 0 了，為了避免類似情況未來突然發生，需要我來排查下原因。

于是我就想：性能監控平臺目前只是個內部系統，用戶使用量不大，并且只有在用戶需要查看數據時去查詢，數據讀取量不應該造成 HBase 的壓力過大。

重現問題

如果要解決這個問題，穩定重現是個必要條件，根據數據平臺組同事的反饋，我們做了更詳細的監控，每隔兩分鐘采集性能監控平臺所用的 HBase 集群的讀操作數量，發現是下面的變化趨勢：

13:00:05 0 13:02:01 66372 13:04:01 96746 13:06:02 101784 13:08:01 99254 13:10:02 2814 13:12:01 93668 13:14:02 93224 13:16:02 90118 13:18:02 11376 13:20:01 85134 13:22:01 81880 13:24:01 80916 13:26:01 77694 13:28:02 76312 13:30:01 73310 13:32:02 0 13:34:01 0 13:36:01 0 13:38:02 0 13:40:01 0 13:42:02 0 13:44:01 0 13:46:02 0 13:48:01 0 13:50:02 0 13:52:01 0 13:54:02 0 13:56:01 0 13:58:02 0 14:00:01 0 14:02:01 36487 14:04:01 43946 14:06:01 53002 14:08:02 51598 14:10:01 54914 14:12:02 95784 14:14:04 53866 14:16:02 54868 14:18:01 54122 14:20:04 0 14:22:01 0 14:24:02 0 14:26:01 0 14:28:01 0 14:30:01 0 14:32:02 0 14:34:01 0

從圖上不難看出，每到整點開始 tsdb-perf 這個表的讀操作飚的很高，大約持續半個小時，之后恢復到 0 。到下個整點又出現類似的問題，并沒有像數據平臺組同事觀察到的突然回復正常了，可能他們連續兩次觀察的時間點剛好錯開了。

于是，真正的問題就變成了：OpenTSDB 到 HBase 的讀操作每到整點開始飚的很高，持續大約半小時后回復正常，這種類脈沖式的流量沖擊會給 HBase 集群的穩定性帶來負面影響。

定位問題所在

事出反常必有妖，OpenTSDB 到 HBase 的大量讀操作肯定伴隨很大的網絡流量，因為兩者用 HTTP 通信，我們得仔細梳理下可能造成這種情況的幾種原因。性能監控平臺的架構圖如下：

從架構圖可以看出，只有數據聚合服務和報表系統會和 OpenTSDB 交互，聚合服務向里面寫數據，報表系統從里面讀數據。然后 OpenTSDB 負責把數據發送到 HBase 中。從數據流動的方向來講，有可能是報表系統導致了大量的讀操作，也有可能是聚合服務里面存在不合理的讀請求，也有可能是 OpenTSDB 本身存在缺陷。

首先排除的是報表系統導致的大量讀操作，因為只會在用戶查看某些報表時才會從 OpenTSDB 讀取數據，目前報表系統每天的訪問量也才幾百，不足以造成如此大的影響。

其次，如何確認是否是聚合服務導致了大量的讀請求呢？可以從網絡流量的視角來分析，如果聚合服務到 OpenTSDB 的流量過大，完全有可能導致 OpenTSDB 到 HBase 的過大流量，但是由于目前聚合服務和 TSDB 寫實例是部署在相同的機器上，無法方便的統計到網絡流量的大小，于是我們把聚合服務和 TSDB 寫實例分開部署，得到下面的流量統計圖：

聚合服務只接收來自解析服務的數據包計算完畢之后發送給 TSDB，其網絡流量如下圖：

TSDB 服務只接收來自聚合服務的數據，然后發送到 HBase，卻出現了脈沖式的沖高回落，網絡流量如下圖：

這樣，就可以排除聚合服務造成的問題，出問題的地方就在 OpenTSDB 和 HBase 集群之間，其他業務線并沒有造成 HBase 的壓力過大，看來問題應該出在 OpenTSDB 里面，如果這個問題是 OpenTSDB 內部存在的，那么其他使用了 OpenTSDB 的系統肯定也存在類似的問題，下面是另外一個組部署的 OpenTSDB 的機器的網絡流量圖（注意，這臺機器上只部署了 OpenTSDB 服務）：

這讓我更加確信問題是在 OpenTSDB 內部，也就是它的工作機制導致了這種問題。

查找問題原因

于是我先后查閱了 OpenTSDB 的官方文檔和 Google Group 討論組里的大部分帖子，還下載來了 OpenTSDB 的源代碼，探個究竟，另外在從讀操作從 0 到暴漲的過程中仔細盯著 OpenTSDB 的 stat 頁面特別關注下面紅色方框中的幾個指標：

讓我感覺比較詭異的是，與大量讀操作同時發生的還有大量的刪除操作，官方文檔上的這段話很好的解釋了我的疑惑：

If compactions have been enabled for a TSD, a row may be compacted after it’s base hour has passed or a query has run over the row. Compacted columns simply squash all of the data points together to reduce the amount of overhead consumed by disparate data points. Data is initially written to individual columns for speed, then compacted later for storage efficiency. Once a row is compacted, the individual data points are deleted. Data may be written back to the row and compacted again later.

這段話很好的解釋了 OpenTSDB 的 Compaction 機制的工作原理，OpenTSDB 內部的工作原理比這個更復雜，下面我說下我通俗的理解：

• 為了節省存儲空間和提高數據讀取速度，OpenTSDB 內部有個數據壓縮（即 Compaction）的機制，將設定的某個時間段內某個指標的所有數據壓縮成單行，重新寫到 HBase；
• OpenTSDB 運行時默認把收到的數據（原始數據點）每秒1次的速度批量寫到 HBase 上，然后會周期性的觸發上面提到的數據壓縮機制，把原始數據點拿出來，壓縮后重新寫回HBase，然后把原始數據點刪除，這就雖然我們只往 OpenTSDB 寫數據但大量的讀和刪操作還是會發生的原因；
• OpenTSDB 默認的配置是以 3600 秒為區間壓縮，實際運行時就是整點觸發，這樣整點發生的大量讀、刪操作就可以解釋了；

至此，線上 OpenTSDB 實例整點大量讀操作造成 HBase 集群壓力過大的問題原因基本明了。

如何解決問題

找到問題的原因之后，我們想到了以下 2 種解決方案：

• 禁用 OpenTSDB 的 Compaction 機制，這樣 OpenTSDB 就變成了 1 個純粹的寫實例，數據讀取速度會有犧牲，因為每次讀取需要掃描更多的數據，這個對于業務數據量很大的系統來說可能并不合適；
• 想辦法讓 OpenTSDB 的數據壓縮過程緩慢進行，這樣到 HBase 的流量壓力就會平緩很多，但是這樣做還是有風險，因為如果從業務系統到 OpenTSDB 的流量暴漲仍然有可能會 HBase 壓力過大，不過這就是另外1個問題了，HBase 需要擴容；

實際操作過程中，我們使用了第 2 種方案，修改 OpenTSDB 的源代碼中 src/core/CompactionQueue.java 中的 FLUSH_SPEED 常量為 1，重新編譯即可。這樣改動的實際影響是：默認壓縮速度是 2 倍速，即最多半個小時內完成前 1 個小時數據的壓縮，重新寫回到 HBase，可以把這個調成 1 倍速，給它 1 個小時的時間來完成前 1 個小時數據的 Compaction，這樣到 HBase 的流量會平緩很多。

經驗和教訓

幾經輾轉，終于找到問題原因所在（離解決問題還有距離），下面是我的幾點感受：

• 解決問題之前，要能夠穩定重現，找到真正的問題所在，不能停留在表面，如果不進行幾個小時的 HBase 讀操作監控，不會發現整點暴漲持續半小時然后回落的問題；
• 系統的運行環境很復雜，必要的時候要想辦法把問題隔離到影響因素更少的環境中，更容易發現問題，比如性能監控平臺各組件的混合部署給機器間的流量分析造成了困難；
• 使用開源軟件，最好能深入了解下運行機制，用起來才得心應手，不然出了問題就很麻煩，這次的排查過程讓我更加詳細的了解了 OpenTSDB 的運行機制；

至此，本文完~

總結

以上是生活随笔為你收集整理的OpenTSDB 造成 Hbase 整点压力过大问题的排查和解决的全部內容，希望文章能夠幫你解決所遇到的問題。

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