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實現與現有其他數據源數據聯合查詢，使其能平滑的與現有系統使用，降低接入門檻。