物聯(lián)網(wǎng)IoT平臺企業(yè)案例

至數(shù)搖光 x TDengine

目前改造工作已經(jīng)全部完成，改造后有大約 80% 左右的指標(biāo)模型放到了 TDengine 中，20% 左右的主數(shù)據(jù)或維表數(shù)據(jù)存放在 MySQL 數(shù)據(jù)庫中。相較于改造前的 80% 指標(biāo)模型存放在 MySQL 中，20% 指標(biāo)數(shù)據(jù)存放在 OpenTSDB 數(shù)據(jù)庫中，結(jié)果剛好進(jìn)行了顛倒，服務(wù)器資源使用情況也有所下降。應(yīng)用整體的頁面影響速度顯著提高，數(shù)據(jù)模型及數(shù)據(jù)指標(biāo)上也可以更加地靈活多變。^[5]

業(yè)務(wù)背景

至數(shù)物聯(lián)網(wǎng)平臺場景多、數(shù)據(jù)模型復(fù)雜，改造前數(shù)據(jù)庫采用 OpenTSDB+MySQL 結(jié)合的方式實現(xiàn)，由于 OpenTSDB 無法滿足復(fù)雜查詢場景，因此 80% 的場景指標(biāo)只能基于 MySQL 數(shù)據(jù)庫來實現(xiàn)，這樣帶來的問題就是 MySQL 數(shù)據(jù)庫的數(shù)據(jù)增長迅速，需要定時做冷熱數(shù)據(jù)分離及數(shù)據(jù)庫表維護(hù)動作。在對 TDengine 進(jìn)行充分調(diào)研后，至數(shù)搖光決定從時序數(shù)據(jù)庫 OpenTSDB 遷移到 TDengine，并基于 TDengine 的特性對系統(tǒng)進(jìn)行徹底性的改造。

架構(gòu)圖

華自科技 x TDengine

當(dāng)前項目數(shù)據(jù)測點大概在 18 萬左右，改造后數(shù)據(jù)存儲周期由原來的 5 分鐘減少到 1 秒鐘，存儲的數(shù)據(jù)維度更精細(xì)了，能為平臺的智能診斷、智能分析服務(wù)提供更準(zhǔn)確的數(shù)據(jù)支持，同時各業(yè)務(wù)場景下的計算查詢性能也提升了不少，數(shù)據(jù)庫服務(wù)器由原來的 6 臺減少到目前的 3 個節(jié)點集群。^[6]

業(yè)務(wù)背景

華自科技旗下的物聯(lián)網(wǎng)數(shù)據(jù)平臺是電站及泵站智慧運維平臺的核心組成。在數(shù)據(jù)存儲上，此前其采用 MySQL 分庫分表方案來存儲歷史數(shù)據(jù)，使用 Redis 來存儲實時數(shù)據(jù)，在測點數(shù)較少或者集控需求不是很多的場景下，基本滿足需求，但隨著平臺業(yè)務(wù)的發(fā)展，接入的站點越來越多，運維難、開發(fā)難、成本高等問題逐漸凸顯。為了解決這些問題，華自科技決定重新進(jìn)行技術(shù)選型，尋找替代方案，升級目前數(shù)據(jù)庫存儲方案。結(jié)合平臺實際需要，其調(diào)研了 InfluxDB、庚頓、麥杰、TimescaleDB、TDengine 這幾款數(shù)據(jù)庫產(chǎn)品，最終選擇了 TDengine。

改造遷移

由于 TDengine 采用了類 SQL 的語法，支持 MyBatis 等 ORM 框架，因此老業(yè)務(wù)在代碼層面的改動非常少，改動最多的就是將原來的 MySQL 函數(shù)結(jié)合應(yīng)用代碼的一些計算邏輯直接用 TDengine 的函數(shù)替換掉。在通過業(yè)務(wù)系統(tǒng)觀察和驗證各項功能正常之后，就可以進(jìn)行歷史數(shù)據(jù)的遷移了。由于 TDengine 的表結(jié)構(gòu)與原來的 MySQL 存儲結(jié)構(gòu)基本類似，因此物聯(lián)網(wǎng)數(shù)據(jù)平臺開發(fā)人員直接采用 DataX 的 TDengine 插件，歷史數(shù)據(jù)就很輕松地遷移過來了。

睿信物聯(lián)網(wǎng)平臺 x TDengine

TDengine 的安裝部署非常簡單，配合 Docker 容器，在幾分鐘內(nèi)就能完成。遷移到 TDengine 之后，我們的運營監(jiān)控工作也變簡單了，只需要對 TDengine 的幾個進(jìn)程進(jìn)行監(jiān)控，占用的磁盤空間減少到了原來的 1/5，使用的主機也減少到原來的 1/5，極大節(jié)省了資源開銷。遇到技術(shù)難題，不僅可以直接在官方渠道 https://github.com/taosdata/TDengine 提 issue，也可以在 TDengine 的技術(shù)社區(qū)提問，TDengine 的技術(shù)專家響應(yīng)非?？?。^[7]

業(yè)務(wù)背景

睿信物聯(lián)網(wǎng)平臺此前采用 OpenTSDB 進(jìn)行時序數(shù)據(jù)的存儲，功能上基本滿足現(xiàn)有需求，但是由于 OpenTSDB 架構(gòu)復(fù)雜，體量過重，給開發(fā)測試、安裝部署以及運維管理等工作帶來了不小的麻煩。隨著業(yè)務(wù)的發(fā)展，問題逐漸凸顯，開始影響工作效率，具體可以歸納為安裝難、調(diào)試難、運維難、成本高四大問題。從業(yè)務(wù)發(fā)展的角度出發(fā)，睿信開發(fā)人員決定重新進(jìn)行技術(shù)選型，尋找 OpenTSDB 的替代方案，分別對 InfluxDB、TimescaleDB 和 TDengine 三款時序數(shù)據(jù)庫進(jìn)行調(diào)研。

架構(gòu)圖

蒼穹數(shù)碼 x TDengine

我們以近 10 年全省的雨量站小時雨量數(shù)據(jù)為測試數(shù)據(jù)，從常用的應(yīng)用場景對 TimescaleDB 和 TDengine 兩款數(shù)據(jù)庫進(jìn)行對比分析，歷史數(shù)據(jù)批量入庫場景中 TimescaleDB 用時 24 小時，TDengine 用時僅僅 2 小時；入庫后數(shù)據(jù)文件大小對比結(jié)果中 TimescaleDB 是 38GB，TDengine 是 698MB；常見查詢場景比對中 TDengine 也均優(yōu)于 TimescaleDB。從入庫、壓縮比及查詢 3 個維度來看，TDengine 都是完勝。^[8]

業(yè)務(wù)背景

在地災(zāi)專業(yè)監(jiān)測物聯(lián)網(wǎng)平臺項目中，首先需要解決的就是海量時序數(shù)據(jù)的存儲和計算問題，其有著體量大、時間長，寫入、查詢要求高等特點，傳統(tǒng)關(guān)系型數(shù)據(jù)庫已經(jīng)無法滿足實時寫入與高性能查詢要求。該項目在 2018 年創(chuàng)建之初采用的是大型企業(yè)級數(shù)據(jù)庫 Oracle，目前已經(jīng)無法滿足實時寫入與高性能查詢要求，特別是當(dāng)雨季來臨，傳感器數(shù)據(jù)采集頻率提高到秒級、毫秒級別，數(shù)據(jù)入庫就會阻塞，效率非常低下。蒼穹數(shù)碼選擇接入 TDengine 以解決海量時序數(shù)據(jù)的存儲和計算問題。

架構(gòu)圖

通過上面幾個實踐我們也能看到，時序數(shù)據(jù)積累得非?？?，每秒產(chǎn)生數(shù)百萬條數(shù)據(jù)，通用數(shù)據(jù)庫并不是為處理這種規(guī)模的數(shù)據(jù)而設(shè)計的——關(guān)系數(shù)據(jù)庫在非常大的數(shù)據(jù)集上表現(xiàn)很差，NoSQL 數(shù)據(jù)庫雖然解決了擴展能力，但是其通用的數(shù)據(jù)組織方式并不完全適用于對時序數(shù)據(jù)存儲和查詢需求，用戶必須根據(jù)實際應(yīng)用場景，進(jìn)行特殊設(shè)計甚至大量數(shù)據(jù)冗余存儲才能較好的利用資源處理請求。

而在時序數(shù)據(jù)庫（Time Series Database）的選擇上，企業(yè)也要擦亮雙眼，進(jìn)行充分的調(diào)研測試，選擇性能最好資源使用率最高的產(chǎn)品，此前我們基于第三方性能基準(zhǔn)測試平臺 TSBS 測試發(fā)布的 IoT 場景下 TDengine 3.0 性能對比分析報告，大家也可做參考。如果你正面臨數(shù)據(jù)處理難題，歡迎添加小T微信（tdengine）尋求幫助。