業(yè)務(wù)背景

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

問題的出現(xiàn)

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

于是我就想：性能監(jiān)控平臺目前只是個內(nèi)部系統(tǒng)，用戶使用量不大，并且只有在用戶需要查看數(shù)據(jù)時去查詢，數(shù)據(jù)讀取量不應(yīng)該造成 HBase 的壓力過大。

重現(xiàn)問題

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

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 這個表的讀操作飚的很高，大約持續(xù)半個小時，之后恢復(fù)到 0 。到下個整點又出現(xiàn)類似的問題，并沒有像數(shù)據(jù)平臺組同事觀察到的突然回復(fù)正常了，可能他們連續(xù)兩次觀察的時間點剛好錯開了。

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

定位問題所在

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

從架構(gòu)圖可以看出，只有數(shù)據(jù)聚合服務(wù)和報表系統(tǒng)會和 OpenTSDB 交互，聚合服務(wù)向里面寫數(shù)據(jù)，報表系統(tǒng)從里面讀數(shù)據(jù)。然后 OpenTSDB 負責(zé)把數(shù)據(jù)發(fā)送到 HBase 中。從數(shù)據(jù)流動的方向來講，有可能是報表系統(tǒng)導(dǎo)致了大量的讀操作，也有可能是聚合服務(wù)里面存在不合理的讀請求，也有可能是 OpenTSDB 本身存在缺陷。

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

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

聚合服務(wù)只接收來自解析服務(wù)的數(shù)據(jù)包計算完畢之后發(fā)送給 TSDB，其網(wǎng)絡(luò)流量如下圖：

TSDB 服務(wù)只接收來自聚合服務(wù)的數(shù)據(jù)，然后發(fā)送到 HBase，卻出現(xiàn)了脈沖式的沖高回落，網(wǎng)絡(luò)流量如下圖：

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

這讓我更加確信問題是在 OpenTSDB 內(nèi)部，也就是它的工作機制導(dǎo)致了這種問題。

查找問題原因

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

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

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 內(nèi)部的工作原理比這個更復(fù)雜，下面我說下我通俗的理解：

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

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

如何解決問題

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

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

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

經(jīng)驗和教訓(xùn)

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

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

至此，本文完~

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。