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實現與現有其餘數據源數據聯合查詢,使其能平滑的與現有系統使用,下降接入門檻。
相關文章
相關標籤/搜索