TDengine助力順豐科技大數據監控改造

做者：尹飛

小T導讀 ：順豐科技大數據集羣天天須要採集海量監控數據，以確保集羣穩定運行。以前雖然採用了OpenTSDB+HBase做爲大數據監控平臺全量監控數據的存儲方案，但有很多痛點，必須對全量監控數據存儲方案進行改造。經過對IoTDB、Druid、ClickHouse、TDengine等時序數據存儲方案的調研，最終咱們選擇了TDengine。大數據監控平臺採用 TDengine 後，在穩定性、寫入性能、查詢性能等方面都有較大的提高，而且存儲成本下降爲原有方案的1/10。

 

場景與痛點

順豐科技致力於構建智慧大腦，建設智慧物流服務，持續深耕大數據及產品、人工智能及應用、綜合物流解決方案等領域，在中國物流科技行業處於領先地位。爲了保證各種大數據服務的平穩運行，咱們圍繞OpenFalcon搭建了大數據監控平臺。因爲OpenFalcon自己採用的是rrdtool做爲數據存儲，不適合作全量監控數據的存儲，因而咱們採用了OpenTSDB+HBase做爲大數據監控平臺全量監控數據的存儲方案。

目前整個平臺平均寫入數十億條/天。隨着大數據監控平臺接入的數據量愈來愈大，咱們有不少痛點須要解決，包括依賴多、使用成本高和性能不能知足等問題。

• 依賴多，穩定性較差 ：做爲底層大數據監控平臺，在數據存儲方面依賴Kafka、Spark和HBase等大數據組件。過長的數據處理鏈路會致使平臺可靠性下降，同時因爲平臺依賴大數據組件，而大數據組件的監控又依賴監控平臺，在大數據組件出現不可用問題時，沒法及時經過監控平臺對問題進行定位。
• 使用成本高 ：因爲監控數據寫入數據量巨大，且須要保存全量監控數據半年以上，用以追溯問題。因此依據容量規劃，咱們採用4節點OpenTSDB+21節點HBase做爲全量監控數據存儲集羣。壓縮後天天仍須要1.5T（3副本）左右空間存儲，總體成本較高。
• 性能不能知足需求 ：OpenTSDB做爲全量監控數據存儲方案，在寫入方面性能基本知足需求，可是在平常大跨度和高頻次查詢方面已沒法知足要求。一方面，OpenTSDB查詢返回結果慢，在時間跨度比較大的狀況下，須要十幾秒；另外一方面，OpenTSDB支持的QPS較低，隨着用戶愈來愈多，OpenTSDB容易崩潰，致使整個服務不可用。

技術選型

爲解決上述問題，咱們有必要對全量監控數據存儲方案進行升級。在數據庫選型方面，咱們對以下數據庫作了預研和分析：

• IoTDB ：剛孵化的Apache頂級項目，由清華大學貢獻，單機性能不錯，可是咱們在調研時發現不支持集羣模式，單機模式在容災和擴展方面，不能知足需求。
• Druid ：性能強大，可擴展的分佈式系統，自修復、自平衡、易於操做，可是依賴ZooKeeper和Hadoop做爲深度存儲，總體複雜度較高。
• ClickHouse ：性能最好，可是運維成本過高，擴展特別複雜，使用的資源較多。
• TDengine ：性能、成本、運維難度都知足，支持橫向擴展，且高可用。

經過綜合對比，咱們初步選定TDengine做爲監控數據存儲方案。TDengine支持多種數據導入方式，包括JDBC和HTTP模式，使用都比較方便。因爲監控數據寫入對性能要求比較高，咱們最後採用了Go Connector，接入過程須要作以下操做：

• 數據清洗，剔除格式不對的數據；
• 數據格式化，將數據轉化爲實體對象；
• SQL語句拼接，對數據進行判斷，肯定寫入的SQL語句；
• 批量寫入數據，爲提升寫入效率，單條數據完成SQL拼接後，按批次進行數據寫入。

數據建模

TDengine在接入數據前須要根據數據的特性設計schema，以達到最好的性能表現。大數據監控平臺數據特性以下：

• 數據格式固定，自帶時間戳；
• 上傳數據內容不可預測，新增節點或服務都會上傳新的標籤內容，這致使數據模型沒法前期統一建立，須要根據數據實時建立；
• 數據標籤列很少，可是標籤內容變化較多；數據數值列比較固定，包括時間戳，監控數值和採樣頻率；
• 單條數據數據量較小，100字節左右；
• 天天數據量大，超過50億；
• 保存6個月以上。

根據上述特色，咱們構建了以下的數據模型。

 

按照TDengine建議的數據模型，每一種類型的數據採集點須要創建一個超級表，例如磁盤利用率，每一個主機上的磁盤均可以採集到磁盤利用率，那麼就能夠將其抽象成爲超級表。結合咱們的數據特色和使用場景，建立數據模型以下：

• 以指標做爲超級表，方便對同一類型的數據進行聚合分析計算；
• 監控數據自己包括標籤信息，直接將標籤信息做爲超級表的標籤列，相同的標籤值組成一個子表。

庫結構以下：

超級表結構以下：

 

落地實施

大數據監控平臺是上層大數據平臺穩定運行的底座，須要確保整個系統的高可用性；隨着業務量增長，監控數據量持續增加，要保證存儲系統能方便的進行橫向擴展。基於以上兩點，TDengine落地整體架構以下：

 

爲保證整個系統的高可用和可擴展性，咱們前端採用nginx集羣進行負載均衡，保證高可用性；單獨分離出客戶端層，方便根據流量需求進行擴容縮容。

實施難點以下。

• 數據寫入 ：因爲監控指標的上傳接口是開放型的，只會對格式進行校驗，對於寫入的數據指標不肯定，不能預先建立好超級表和子表。這樣對於每條數據都要檢查判斷是否須要建立新的超級表。若是每次判斷都須要訪問TDengine的話，會致使寫入速度急劇降低，徹底沒法達到要求。爲了解決這個問題，在本地創建緩存，這樣只須要查詢一次TDengine，後續相關指標的寫入數據直接走批量寫入便可，大大提高了寫入速度。另外，2.0.10.0以前的版本批量建立表的速度很是慢，爲了保證寫入速度，須要按照建立表和插入數據分批插入，須要緩存子表的數據信息，後面的版本優化了子表建立功能，速度有了大幅提高，也簡化了數據插入流程。
• 查詢問題 ：1. 查詢bug。監控平臺數據主要是經過Grafana進行數據展現，可是在使用過程當中，咱們發現官方提供的插件不支持參數設置，根據咱們的自身需求，對其進行了改造，並提供給社區使用。另外在使用過程當中，觸發了一個比較嚴重的查詢bug：在設置較多看板時，刷新頁面會致使服務端崩潰。後經排查，發現是因爲Grafana中一個dashboard刷新時會同時發起多個查詢請求，處理併發查詢致使的，後經官方修復。2. 查詢單點問題。TDengine原生HTTP查詢是直接查詢特定服務端完成的。這個在生產環境是存在風險的。首先，全部的查詢都集中在一臺服務端，容易致使單臺機器過載；另外，沒法保證查詢服務的高可用。基於以上兩點，咱們在TDengine集羣前端使用Nginx集羣做反向代理，將查詢請求均勻分佈在各個節點，理論上能夠無限擴展查詢性能。
• 容量規劃 ：數據類型，數據規模對TDengine性能影響比較大，每一個場景最好根據本身的特性進行容量規劃，影響因素包括表數量，數據長度，副本數，表活躍度等。根據這些因素調整配置參數，確保最佳性能，例如blocks，caches，ratioOfQueryCores等。根據與濤思工程師溝通，肯定了TDengine的容量規劃計算模型。TDengine容量規劃的難點在於內存的規劃，通常狀況下，三節點256G內存集羣最多支持2000w左右的子表數目，若是繼續增長的話，會致使寫入速度降低，且須要預留一部分的內存空間做爲查詢緩存使用，通常保留10G左右。若是子表數量超過2000w，則能夠選擇擴展新節點來分擔壓力。

 

改造效果

完成改造後，TDengine集羣輕鬆扛住了全量監控數據寫入，目前運行穩定。改造後架構圖以下：

• 穩定性方面 ：完成改造後，大數據監控平臺擺脫了對大數據組件的依賴，有效縮短了數據處理鏈路。自上線以來，一直運行穩定，後續咱們也將持續觀察。
• 寫入性能 ：TDengine的寫入性能跟寫入數據有較大關係，在根據容量規劃完成相關參數調整後，在理想狀況下，集羣寫入速度最高達到90w條/s的寫入速度。在一般狀況下（存在新建表，混合插入），寫入速度在20w條/s。
• 查詢性能 ：在查詢性能方面，在使用預計算函數狀況下，查詢p99都在0.7秒之內，已經可以知足咱們平常絕大部分查詢需求；在作大跨度（6個月）非預計算查詢狀況下，首次查詢耗時在十秒左右，後續相似查詢耗時會有大幅降低（2-3s），主要緣由是TDengine會緩存最近查詢結果，相似查詢先讀取已有緩存數據，再結合新增數據作聚合。
• 成本方面 ：服務端物理機由21臺降至3臺，每日所需存儲空間爲93G（2副本），同等副本下僅爲OpenTSDB+HBase的約1/10，在下降成本方面相對通用性大數據平臺有很是大的優點。

總結

目前從大數據監控這個場景看，TDengine在成本，性能和使用便利性方面都有很是大的優點，尤爲是在成本方面帶來很大驚喜。在預研和項目落地過程當中，濤思的工程師提供了專業、及時的幫助，在此表示感謝。但願TDengine可以不斷提高性能和穩定性，開發新特性，咱們也會根據自身需求進行二次開發，向社區貢獻代碼。祝TDengine愈來愈好。對於TDengine，咱們也有一些期待改進的功能點：

• 對錶名支持更友好；
• 對其餘大數據平臺的支持，聯合查詢需求；
• 支持更加豐富的SQL語句；
• 灰度平滑升級；
• 子表自動清理功能；
• 集羣異常停機恢復速度。

後續咱們也將在順豐科技的更多場景中嘗試應用TDengine，包括：

• 物聯網平臺，做爲底層物聯網數據存儲引擎構建順豐科技大數據物聯網平臺；
• Hive on TDengine，經過Hive on TDengine實現與現有其餘數據源數據聯合查詢，使其能平滑的與現有系統使用，下降接入門檻。