北京2021年11月30日 /美通社/ -- 為了構建更為完整的物聯網大數據處理生態，支持簡單高效地從其他時序數據庫遷移到TDengine，濤思數據研發并正式發布了taosAdapter。

TDengine是濤思數據專為物聯網(wang)、車聯網(wang)、工業互聯網(wang)、IT運(yun)維(wei)等設計和優(you)化的(de)(de)(de)大(da)(da)數據平臺(tai)(tai)。除核(he)心的(de)(de)(de)快(kuai)10倍以(yi)上的(de)(de)(de)時(shi)序數據庫(ku)功(gong)(gong)能外，還提供緩存、數據訂(ding)閱、流式計算(suan)等功(gong)(gong)能，最(zui)大(da)(da)程度減少研發和運(yun)維(wei)的(de)(de)(de)復雜度，且核(he)心代(dai)(dai)碼(ma)，包括集群功(gong)(gong)能全(quan)部(bu)開源。自(zi)TDengine于(yu)2019年7月宣布(bu)開源以(yi)來，在(zai)世界(jie)最(zui)大(da)(da)的(de)(de)(de)代(dai)(dai)碼(ma)托管平臺(tai)(tai)GitHub上已(yi)經(jing)已(yi)經(jing)獲(huo)得非常積極的(de)(de)(de)反(fan)饋(kui)，有17,300多(duo)人給(gei)了(le)star，4,100多(duo)人fork了(le)代(dai)(dai)碼(ma)。越(yue)來越(yue)多(duo)的(de)(de)(de)用戶開始采用TDengine。

taosAdapter是一個新(xin)的獨(du)立(li)程(cheng)序(xu)，可(ke)以包含在TDengine 2.3.0.0及(ji)以上版(ban)本中。taosAdapter的核(he)心出發點是解決(jue)用戶的痛點，降低遷移成本。

在(zai)物聯(lian)網和運(yun)維監(jian)控(kong)等領域，有些用(yong)戶還在(zai)使用(yong)傳統解決方案或者比(bi)較(jiao)老的(de)產(chan)品(pin)解決時序(xu)(xu)數據處理(li)問題，比(bi)如OpenTSDB。OpenTSDB也(ye)是一款開源的(de)分布式時序(xu)(xu)數據庫，它沒有自己的(de)存儲引擎，相關(guan)功能完全(quan)基于(yu)HBase。因為產(chan)生(sheng)時間較(jiao)早(zao)，所以很(hen)多運(yun)維監(jian)控(kong)項目選擇了該系統。

以某物流科技公司(si)為例，他們采(cai)用(yong)了OpenTSDB+HBase作為(wei)大數(shu)據監控(kong)平臺全量監控(kong)數(shu)據的(de)存儲方(fang)案。但(dan)是(shi)隨著該(gai)平臺接入(ru)的(de)數(shu)據量越來越大，他們(men)遇到了很多痛點(dian)，像系統依賴多、使用成本高(gao)和性能不如意等。

具體而言：

• 依賴多，穩定性較差：大數據監控平臺是底層的基礎設施，在數據存儲方面又要依賴Kafka、Spark和HBase等大數據組件。這樣數據處理鏈路就會很長，而數據鏈路越長，要保證系統的可靠性，挑戰也就越大。如果監控系統本身出現問題，也就無從基于它來發現和定位業務系統的問題了。
  
• 使用成本高：監控數據的寫入量非常大，而且為了追溯歷史問題，他們需要將全量監控數據保存半年以上。數據存儲成本居高不下。
  
• 性能不能滿足需求：OpenTSDB作為全量監控數據存儲方案，在寫入方面性能基本滿足需求，但是在日常大跨度和高頻次查詢方面已無法滿足要求。

為了解決這(zhe)些痛點，當時(shi)順豐科技的(de)工程師們認為有(you)必要對(dui)全量(liang)監控(kong)數據(ju)存儲方案進(jin)行升級。他們調研了多(duo)款(kuan)時(shi)序數據(ju)庫(ku)產品，最終決定(ding)選擇(ze)TDengine。之后他們基于TDengine對(dui)系統進(jin)行了改造。改造完成后，TDengine集群(qun)輕(qing)松扛住了全量(liang)監控(kong)數據(ju)寫入，目前運行穩定(ding)。

這次(ci)改造帶(dai)來的效果提(ti)升非常亮眼：服務端物理(li)機由21臺降至3臺，每(mei)日所需存(cun)儲(chu)空間同等條件下(xia)(xia)僅為OpenTSDB+HBase的約(yue)1/10，大(da)大(da)降低了硬件成(cheng)本(ben)。在(zai)(zai)(zai)查(cha)詢(xun)性(xing)能方面，在(zai)(zai)(zai)使(shi)用預(yu)計(ji)算函數情(qing)況下(xia)(xia)，查(cha)詢(xun)p99都在(zai)(zai)(zai)0.7秒以內，已經能夠滿(man)足日常絕大(da)部分查(cha)詢(xun)需求；在(zai)(zai)(zai)做大(da)跨度（6個月(yue)）非預(yu)計(ji)算查(cha)詢(xun)情(qing)況下(xia)(xia)，首次(ci)查(cha)詢(xun)耗時在(zai)(zai)(zai)10秒左右，后(hou)續(xu)類似查(cha)詢(xun)耗時會有大(da)幅下(xia)(xia)降（2-3s）。

某物聯網平臺也遇到了類似問題，他們(men)之前采用OpenTSDB存儲時序數(shu)據，功能上是能夠滿足需(xu)求(qiu)的；但是由(you)于OpenTSDB架構復雜，體(ti)量過重，給開(kai)發測(ce)試(shi)、安(an)裝部署(shu)以(yi)及(ji)運維管理(li)等工作帶來了(le)(le)不小的麻(ma)煩，隨(sui)著業務規模的發展(zhan)，問題愈發嚴重。同樣在經過調研之后，他們也選擇(ze)了(le)(le)TDengine。在升(sheng)級改造(zao)的過程中，他們需(xu)要保留歷史數(shu)據，所以(yi)需(xu)要將歷史數(shu)據從OpenTSDB遷移(yi)到TDengine。為此他們還專門開(kai)發了(le)(le)一個數(shu)據遷移(yi)工具，并進行了(le)(le)詳盡的測(ce)試(shi)。

用(yong)戶的(de)(de)(de)需求(qiu)就是產品(pin)演進的(de)(de)(de)動(dong)力。TDengine的(de)(de)(de)研發團隊開始思考這(zhe)個問(wen)題：既然很多用(yong)戶都有這(zhe)種遷移需求(qiu)，那(nei)是不是可以官(guan)方給出一(yi)個統一(yi)的(de)(de)(de)解決(jue)方案呢？

taosAdapter就(jiu)是(shi)他們的答案。taosAdapter主要有以下功能：

• RESTful接口
• 兼容InfluxDB v1 write接口
• 兼容OpenTSDB JSON和Telnet格式寫入
• 無縫連接Telegraf、collectd、StatsD、Icinga、TCollector

它(ta)能(neng)夠兼容OpenTSDB的Telnet/JSON寫(xie)(xie)入協議(yi)，對(dui)于運維監控(kong)類業(ye)務，用(yong)戶可(ke)以(yi)將(jiang)collectd和(he)StatsD收集的數(shu)據(ju)通過(guo)taosAdapter直接(jie)推送到TDengine。在數(shu)據(ju)能(neng)夠正常寫(xie)(xie)入TDengine后(hou)，可(ke)以(yi)調整適配Grafana，將(jiang)寫(xie)(xie)入TDengine的數(shu)據(ju)以(yi)可(ke)視(shi)化(hua)方式(shi)呈現出(chu)來。TDengine也為(wei)Grafana提(ti)供了(le)連(lian)接(jie)插件。如果要遷(qian)移(yi)歷(li)史數(shu)據(ju)，濤(tao)思數(shu)據(ju)還開(kai)發了(le)數(shu)據(ju)同步(bu)工(gong)具DataX的插件，能(neng)夠幫助(zhu)用(yong)戶將(jiang)數(shu)據(ju)自(zi)動寫(xie)(xie)入到TDengine中。用(yong)戶無(wu)需(xu)修改(gai)(gai)任何(he)一行代碼(ma)，只(zhi)需(xu)要改(gai)(gai)幾(ji)個配置，即可(ke)無(wu)縫遷(qian)移(yi)。

下一(yi)步(bu)，taosAdapter也將(jiang)繼續完(wan)善，支(zhi)持(chi)從更多平臺(tai)向TDengine遷移(yi)。