為了構建更為完整的物聯網大數據處理生態，支持簡單高效地從其他時序數據庫遷移到TDengine，濤思數據研發并正式發布了taosAdapter。
TDengine是濤思數據專為物聯網、車聯網、工業互聯網、IT運維等設計和優化的大數據平臺。除核心的快10倍以上的時序數據庫功能外，還提供緩存、數據訂閱、流式計算等功能，最大程度減少研發和運維的復雜度，且核心代碼，包括集群功能全部開源。自TDengine于2019年7月宣布開源以來，在世界最大的代碼托管平臺GitHub上已經已經獲得非常積極的反饋，有17,300多人給了star，4,100多人fork了代碼。越來越多的用戶開始采用TDengine。
TDengine 在 GitHub 上開源
taosAdapter是一個新的獨立程序，可以包含在TDengine 2.3.0.0及以上版本中。taosAdapter的核心出發點是解決用戶的痛點，降低遷移成本。
在物聯網和運維監控等領域，有些用戶還在使用傳統解決方案或者比較老的產品解決時序數據處理問題，比如OpenTSDB。OpenTSDB也是一款開源的分布式時序數據庫，它沒有自己的存儲引擎，相關功能完全基于HBase。因為產生時間較早，所以很多運維監控項目選擇了該系統。
以某物流科技公司為例，他們采用了OpenTSDB+HBase作為大數據監控平臺全量監控數據的存儲方案。但是隨著該平臺接入的數據量越來越大，他們遇到了很多痛點，像系統依賴多、使用成本高和性能不如意等。
具體而言：
依賴多，穩定性較差：大數據監控平臺是底層的基礎設施，在數據存儲方面又要依賴Kafka、Spark和HBase等大數據組件。這樣數據處理鏈路就會很長，而數據鏈路越長，要保證系統的可靠性，挑戰也就越大。如果監控系統本身出現問題，也就無從基于它來發現和定位業務系統的問題了。
使用成本高：監控數據的寫入量非常大，而且為了追溯歷史問題，他們需要將全量監控數據保存半年以上。數據存儲成本居高不下。
性能不能滿足需求：OpenTSDB作為全量監控數據存儲方案，在寫入方面性能基本滿足需求，但是在日常大跨度和高頻次查詢方面已無法滿足要求。
為了解決這些痛點，當時順豐科技的工程師們認為有必要對全量監控數據存儲方案進行升級。他們調研了多款時序數據庫產品，最終決定選擇TDengine。之后他們基于TDengine對系統進行了改造。改造完成后，TDengine集群輕松扛住了全量監控數據寫入，目前運行穩定。
這次改造帶來的效果提升非常亮眼：服務端物理機由21臺降至3臺，每日所需存儲空間同等條件下僅為OpenTSDB+HBase的約1/10，大大降低了硬件成本。在查詢性能方面，在使用預計算函數情況下，查詢p99都在0.7秒以內，已經能夠滿足日常絕大部分查詢需求；在做大跨度（6個月）非預計算查詢情況下，首次查詢耗時在10秒左右，后續類似查詢耗時會有大幅下降（2-3s）。
某物聯網平臺也遇到了類似問題，他們之前采用OpenTSDB存儲時序數據，功能上是能夠滿足需求的；但是由于OpenTSDB架構復雜，體量過重，給開發測試、安裝部署以及運維管理等工作帶來了不小的麻煩，隨著業務規模的發展，問題愈發嚴重。同樣在經過調研之后，他們也選擇了TDengine。在升級改造的過程中，他們需要保留歷史數據，所以需要將歷史數據從OpenTSDB遷移到TDengine。為此他們還專門開發了一個數據遷移工具，并進行了詳盡的測試。
用戶的需求就是產品演進的動力。TDengine的研發團隊開始思考這個問題：既然很多用戶都有這種遷移需求，那是不是可以官方給出一個統一的解決方案呢？
taosAdapter就是他們的答案。taosAdapter主要有以下功能：
RESTful接口
兼容InfluxDB v1 write接口
兼容OpenTSDB JSON和Telnet格式寫入
無縫連接Telegraf、collectd、StatsD、Icinga、TCollector
它能夠兼容OpenTSDB的Telnet/JSON寫入協議，對于運維監控類業務，用戶可以將collectd和StatsD收集的數據通過taosAdapter直接推送到TDengine。在數據能夠正常寫入TDengine后，可以調整適配Grafana，將寫入TDengine的數據以可視化方式呈現出來。TDengine也為Grafana提供了連接插件。如果要遷移歷史數據，濤思數據還開發了數據同步工具DataX的插件，能夠幫助用戶將數據自動寫入到TDengine中。用戶無需修改任何一行代碼，只需要改幾個配置，即可無縫遷移。
下一步，taosAdapter也將繼續完善，支持從更多平臺向TDengine遷移。
