天數潤科開源貢獻 OpenTSDB-Keeper
東方網 2018-04-10 09:31:51
OpenTSDB是一款社群的時序資料庫產品，其構建與HBase之上的設計使得它擁有很好的可擴充套件性，尤其適合於監控領域，然而，OpenTSDB仍存在幾個問題：(1)作為一箇中間件，其穩定性、可靠性與底層HBase的表現休慼相關，基於Hadoop生態也決定其在運維方面的複雜性。(2)儘管OpenTSDB可以多節點部署，但這完全依賴於HBase本身的分散式設計，其自身僅僅被設計為一個單體應用，並沒有定義或實現節點間互動的細節，沒有充分發揮分散式多節點的能力。因此，我們希望針對這兩點展開一些工作，打造一個可靠的、穩定的、分散式的TSDB叢集，這就是我們規劃中的OpenTSDB-Keeper元件。它將作為OpenTSDB叢集的大腦，監控各節點狀態，平衡各節點間負載，組織節點間在讀寫方面的協作。從2016年開始，我們採用實時計算+時序資料庫的儲存平臺架構來解決IoT場景的資料儲存需求。上千臺裝置的感測器資料實時接入，需要每秒能響應百萬點以上的併發寫需求。多層的流式計算/儲存架構，需要充分考慮每層通道提供的讀寫頻寬。技術上，我們使用自研的SkyCompute高效能運算引擎中的SparkStreaming作為流計算引擎，OpenTSDB作為儲存引擎，資料架構參考下圖：圖1 基於SparkStreaming+OpenTSDB的流式時序資料儲存架構如上圖所示，單個節點的OpenTSDB無法滿足一個Spark叢集的併發寫入，也無法保障實時寫的高可用。因此，我們採用分散式的方式，啟動多個OpenTSDB節點來響應SparkStreaming寫請求。為了均勻分散寫請求的負載，在每1個計算節點都部署了1個OpenTSDB節點，這樣每個計算節點只寫往本機的OpenTSDB節點，同時還節省了部分網路通訊的開銷。圖2 簡單的負載均衡架構在上線執行驗證期間，我們發現，整個Spark Streaming的任務經常受OpenTSDB+HBase儲存層的響應拖累，既無法發揮系統的全部效能，也無法達到承諾的資料穩定落盤。主要表現在，受更底層HBase的響應影響以及OpenTSDB自身負載，導致了響應時間不穩定，乃至出現OpenTSDB節點崩潰。我們一方面著力於解決OpenTSDB與HBase之間的連線問題，調節OpenTSDB資源，一方面認為叢集形式的OpenTSDB同樣需要一個監控以及資源分配元件。我們需要在OpenTSDB節點負載過程或出現故障時，及時將計算節點連線到另一個健康的OpenTSDB節點，並且對這樣的故障增加報警與錯誤記錄，以通知到運維人員，併為錯誤分析、調優提供原始記錄。於是，我們開發了一個非常輕量的元件OpenTSDB-Keeper。在我們的業務場景中，該元件的加入，顯著地提高了從計算節點到儲存節點的效率、減少了IO等待時間，且避免了OpenTSDB節點無響應導致的持續的儲存失敗，將整個系統的處理效率提高了三倍。本文來源：東方網責任編輯：王曉易_NE0011
OpenTSDB是一款社群的時序資料庫產品，其構建與HBase之上的設計使得它擁有很好的可擴充套件性，尤其適合於監控領域，然而，OpenTSDB仍存在幾個問題：
(1)作為一箇中間件，其穩定性、可靠性與底層HBase的表現休慼相關，基於Hadoop生態也決定其在運維方面的複雜性。
(2)儘管OpenTSDB可以多節點部署，但這完全依賴於HBase本身的分散式設計，其自身僅僅被設計為一個單體應用，並沒有定義或實現節點間互動的細節，沒有充分發揮分散式多節點的能力。
因此，我們希望針對這兩點展開一些工作，打造一個可靠的、穩定的、分散式的TSDB叢集，這就是我們規劃中的OpenTSDB-Keeper元件。它將作為OpenTSDB叢集的大腦，監控各節點狀態，平衡各節點間負載，組織節點間在讀寫方面的協作。
從2016年開始，我們採用實時計算+時序資料庫的儲存平臺架構來解決IoT場景的資料儲存需求。上千臺裝置的感測器資料實時接入，需要每秒能響應百萬點以上的併發寫需求。多層的流式計算/儲存架構，需要充分考慮每層通道提供的讀寫頻寬。技術上，我們使用自研的SkyCompute高效能運算引擎中的SparkStreaming作為流計算引擎，OpenTSDB作為儲存引擎，資料架構參考下圖：
圖1 基於SparkStreaming+OpenTSDB的流式時序資料儲存架構
如上圖所示，單個節點的OpenTSDB無法滿足一個Spark叢集的併發寫入，也無法保障實時寫的高可用。因此，我們採用分散式的方式，啟動多個OpenTSDB節點來響應SparkStreaming寫請求。為了均勻分散寫請求的負載，在每1個計算節點都部署了1個OpenTSDB節點，這樣每個計算節點只寫往本機的OpenTSDB節點，同時還節省了部分網路通訊的開銷。
圖2 簡單的負載均衡架構
在上線執行驗證期間，我們發現，整個Spark Streaming的任務經常受OpenTSDB+HBase儲存層的響應拖累，既無法發揮系統的全部效能，也無法達到承諾的資料穩定落盤。主要表現在，受更底層HBase的響應影響以及OpenTSDB自身負載，導致了響應時間不穩定，乃至出現OpenTSDB節點崩潰。
我們一方面著力於解決OpenTSDB與HBase之間的連線問題，調節OpenTSDB資源，一方面認為叢集形式的OpenTSDB同樣需要一個監控以及資源分配元件。我們需要在OpenTSDB節點負載過程或出現故障時，及時將計算節點連線到另一個健康的OpenTSDB節點，並且對這樣的故障增加報警與錯誤記錄，以通知到運維人員，併為錯誤分析、調優提供原始記錄。
資源
健康
於是，我們開發了一個非常輕量的元件OpenTSDB-Keeper。在我們的業務場景中，該元件的加入，顯著地提高了從計算節點到儲存節點的效率、減少了IO等待時間，且避免了OpenTSDB節點無響應導致的持續的儲存失敗，將整個系統的處理效率提高了三倍。