作者：尹飛

小T導讀：順豐科技大數(shu)據(ju)(ju)集群(qun)每天(tian)需要采(cai)集海量監(jian)控(kong)數(shu)據(ju)(ju)，以確保(bao)集群(qun)穩(wen)定運行。之前雖(sui)然(ran)采(cai)用(yong)了OpenTSDB+HBase作為大數(shu)據(ju)(ju)監(jian)控(kong)平臺全量監(jian)控(kong)數(shu)據(ju)(ju)的(de)存(cun)儲(chu)(chu)(chu)方(fang)(fang)案，但有(you)不少痛點，必(bi)須對(dui)全量監(jian)控(kong)數(shu)據(ju)(ju)存(cun)儲(chu)(chu)(chu)方(fang)(fang)案進行改(gai)造(zao)。通過對(dui)IoTDB、Druid、ClickHouse、TDengine等時序數(shu)據(ju)(ju)存(cun)儲(chu)(chu)(chu)方(fang)(fang)案的(de)調研，最(zui)終(zhong)我們選擇了TDengine。大數(shu)據(ju)(ju)監(jian)控(kong)平臺采(cai)用(yong)TDengine后，在穩(wen)定性(xing)、寫入性(xing)能、查(cha)詢性(xing)能等方(fang)(fang)面(mian)都(dou)有(you)較大的(de)提升，并且(qie)存(cun)儲(chu)(chu)(chu)成本(ben)降低為原有(you)方(fang)(fang)案的(de)1/10。

場景與痛點

順豐科技致力(li)于構建智(zhi)慧大(da)腦(nao)，建設智(zhi)慧物流服務(wu)(wu)，持續深耕大(da)數(shu)(shu)據(ju)及(ji)產品、人工智(zhi)能及(ji)應(ying)用(yong)、綜合物流解決方案(an)等領(ling)域，在中(zhong)國(guo)物流科技行(xing)業處于領(ling)先地位。為了保證各類大(da)數(shu)(shu)據(ju)服務(wu)(wu)的(de)平(ping)穩運行(xing)，我(wo)們圍繞(rao)OpenFalcon搭建了大(da)數(shu)(shu)據(ju)監(jian)控平(ping)臺(tai)。由于OpenFalcon本身采用(yong)的(de)是rrdtool作(zuo)為數(shu)(shu)據(ju)存儲，不適合做全量監(jian)控數(shu)(shu)據(ju)的(de)存儲，于是我(wo)們采用(yong)了OpenTSDB+HBase作(zuo)為大(da)數(shu)(shu)據(ju)監(jian)控平(ping)臺(tai)全量監(jian)控數(shu)(shu)據(ju)的(de)存儲方案(an)。

目前(qian)整個平(ping)(ping)臺(tai)平(ping)(ping)均寫入(ru)數十億條(tiao)/天。隨著(zhu)大數據(ju)監控(kong)平(ping)(ping)臺(tai)接入(ru)的(de)數據(ju)量越來越大，我們有很多(duo)痛點(dian)需要(yao)解決，包括依賴多(duo)、使用成本(ben)高(gao)和性能不能滿足等問題(ti)。

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

技術選型

為解決(jue)上述問題(ti)，我們有必要(yao)對(dui)全量監控數(shu)據存(cun)儲方(fang)案進(jin)行升級(ji)。在數(shu)據庫選型方(fang)面(mian)，我們對(dui)如下數(shu)據庫做了預研和分析：

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

通過綜合(he)對比(bi)，我們初步選(xuan)定TDengine Database作為監(jian)(jian)控數(shu)據(ju)存儲方案。TDengine支持多種數(shu)據(ju)導入方式，包括JDBC和(he)HTTP模式，使用都(dou)比(bi)較(jiao)方便(bian)。由于(yu)監(jian)(jian)控數(shu)據(ju)寫入對性能要求比(bi)較(jiao)高(gao)，我們最后(hou)采用了Go Connector，接入過程需(xu)要做如下操作：

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

數據建模

TDengine Database在接入數據(ju)前需要(yao)根據(ju)數據(ju)的特性(xing)設計schema，以達到最(zui)好的性(xing)能表(biao)現。大數據(ju)監(jian)控平臺數據(ju)特性(xing)如下(xia)：

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

根據上述特點，我們(men)構建(jian)了如下的數據模(mo)型(xing)。

按照(zhao)TDengine建(jian)議的數據(ju)模型，每一種類型的數據(ju)采集點(dian)需要建(jian)立一個(ge)超級表(biao)，例如磁盤利用率(lv)，每個(ge)主機上的磁盤都可(ke)以(yi)采集到磁盤利用率(lv)，那么就可(ke)以(yi)將其抽象成為超級表(biao)。結合我(wo)們的數據(ju)特點(dian)和使用場(chang)景，創(chuang)建(jian)數據(ju)模型如下：

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

庫結構如下：

超級表結構如下：

落地實施

大數據(ju)監(jian)控(kong)平(ping)臺是上層(ceng)大數據(ju)平(ping)臺穩定(ding)運行的(de)底(di)座，需要確保整(zheng)個系(xi)統的(de)高(gao)可用性；隨著業務量(liang)增(zeng)加，監(jian)控(kong)數據(ju)量(liang)持續增(zeng)長，要保證存儲系(xi)統能方便的(de)進行橫(heng)向擴展。基(ji)于以上兩點，TDengine落地總(zong)體架構如下：

為保(bao)證整個系統的高可(ke)用和可(ke)擴(kuo)展性(xing)，我(wo)們前端(duan)采用nginx集群進(jin)行負(fu)載(zai)均(jun)衡，保(bao)證高可(ke)用性(xing)；單獨分(fen)離出客戶(hu)端(duan)層，方便根據流(liu)量需求進(jin)行擴(kuo)容縮(suo)容。

實施難點如下。

• 數據寫入：由于監控指標的上傳接口是開放型的，只會對格式進行校驗，對于寫入的數據指標不確定，不能預先創建好超級表和子表。這樣對于每條數據都要檢查判斷是否需要創建新的超級表。如果每次判斷都需要訪問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，則可以選擇擴展新節點來分擔壓力。

改造效果

完(wan)成改造(zao)后，TDengine集(ji)群(qun)輕松扛住了全(quan)量監控數據(ju)寫入，目前運行穩定(ding)。改造(zao)后架構圖如下：

• 穩定性方面：完成改造后，大數據監控平臺擺脫了對大數據組件的依賴，有效縮短了數據處理鏈路。自上線以來，一直運行穩定，后續我們也將持續觀察。

• 寫入性能：TDengine的寫入性能跟寫入數據有較大關系，在根據容量規劃完成相關參數調整后，在理想情況下，集群寫入速度最高達到90w條/s的寫入速度。在通常情況下（存在新建表，混合插入），寫入速度在20w條/s。

• 查詢性能：在查詢性能方面，在使用預計算函數情況下，查詢p99都在0.7秒以內，已經能夠滿足我們日常絕大部分查詢需求；在做大跨度（6個月）非預計算查詢情況下，首次查詢耗時在十秒左右，后續類似查詢耗時會有大幅下降（2-3s），主要原因是TDengine會緩存最近查詢結果，類似查詢先讀取已有緩存數據，再結合新增數據做聚合。

• 成本方面：服務端物理機由21臺降至3臺，每日所需存儲空間為93G（2副本），同等副本下僅為OpenTSDB+HBase的約1/10，在降低成本方面相對通用性大數據平臺有非常大的優勢。

總結

目前從大(da)數(shu)據監(jian)控這個(ge)場景(jing)看(kan)，TDengine Database在成本、性能(neng)和使用(yong)便利性方面都有非常大(da)的(de)(de)(de)優勢，尤其是在成本方面帶來很大(da)驚喜。在預(yu)研(yan)和項(xiang)目落地過程中，濤思的(de)(de)(de)工程師提(ti)供了專業、及時(shi)的(de)(de)(de)幫助(zhu)，在此表示(shi)感謝。希望(wang)TDengine能(neng)夠(gou)不(bu)斷提(ti)升性能(neng)和穩定性，開(kai)發新特性，我們(men)也(ye)會(hui)根(gen)據自身需求進行二(er)次開(kai)發，向社區(qu)貢(gong)獻(xian)代碼。祝TDengine越來越好。對于TDengine，我們(men)也(ye)有一些期待(dai)改進的(de)(de)(de)功能(neng)點(dian)：

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

后(hou)續我(wo)們也將(jiang)在順(shun)豐科技的更多場景(jing)中嘗試(shi)應用(yong)TDengine，包(bao)括：

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