在智慧水務(wù)系統(tǒng)中，往往需要對設(shè)備中產(chǎn)生的液位、電流、水量等實時指標數(shù)據(jù)進行存儲、分析及監(jiān)控操作，而這些都是典型的時序數(shù)據(jù)。面對這些數(shù)據(jù)的處理時，很多企業(yè)在前期選擇的大都是傳統(tǒng)的實時數(shù)據(jù)庫甚至關(guān)系型數(shù)據(jù)庫，隨著設(shè)備數(shù)量的增加，數(shù)據(jù)量也達到了百萬、千萬量級，傳統(tǒng)的數(shù)據(jù)庫解決方案已經(jīng)無法滿足業(yè)務(wù)需求。為了幫助有以上問題的企業(yè)更好地進行數(shù)據(jù)架構(gòu)整改，本篇文章匯總了三個典型智慧水務(wù)場景下的數(shù)據(jù)架構(gòu)升級實踐，給到大家參考。

禹為科技 x TDengine

“TDengine 的消息訂閱、緩存、流式計算等諸多特性，可以代替 Kafka、OpenTSDB 和 Flink，減少業(yè)務(wù)代碼中定時計算（如用水量）等功能，簡化了整體架構(gòu)。在架構(gòu)簡化以后，排查和定位問題也能得到快速響應(yīng)，開發(fā)和運維成本大大節(jié)約。同時，TDengine 替代了 OpenTSDB+Redis+MySQL，提高了數(shù)據(jù)實時性和一致性，其表結(jié)構(gòu)設(shè)計合理，可以節(jié)省存儲空間，進而節(jié)省存儲費用。”

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

相較于水利信息化系統(tǒng)，禹為科技灌區(qū)信息化平臺具有設(shè)備廠家多、數(shù)據(jù)多且存儲周期長、數(shù)據(jù)類型較為集中、需要實時展示的指標較多等特點。為了解耦系統(tǒng)中的數(shù)據(jù)接入和數(shù)據(jù)分析，禹為科技將數(shù)據(jù)的接入和計算分析拆分為獨立的通用物聯(lián)網(wǎng)平臺及大數(shù)據(jù)平臺，在現(xiàn)代灌區(qū)信息化平臺的建設(shè)過程中，經(jīng)歷了數(shù)據(jù)庫&定時任務(wù)的架構(gòu)、以流式計算為核心的架構(gòu)和以 TDengine 為核心的架構(gòu)三個階段，最終選用 TDengine 幫助其對水位、流量、水量等實時指標數(shù)據(jù)分析。

架構(gòu)圖

點擊案例查看更多技術(shù)細節(jié)

鼎藍水務(wù) x TDengine

“使用感受就是 TDengine 的數(shù)據(jù)處理性能非常高?，F(xiàn)在的接入網(wǎng)關(guān)的設(shè)備數(shù)是 23 個液位、9 個頻率計、9 個電流計、10 個攔蓄盾、3 個泵站、3 個截留井、1 個泵閘，總共有 40 張表，每張表每天新增 6 萬條數(shù)據(jù)，現(xiàn)在每張表的大約三百萬條數(shù)據(jù)。使用 TDengine 帶來的最大好處是不用再考慮 SQLServer 中的分庫分表操作，數(shù)據(jù)不斷寫入一個月后，查詢時延也沒有增加。而且我們發(fā)現(xiàn) TDengine 在處理 13 個設(shè)備、百萬量級的數(shù)據(jù)量寫入任務(wù)時，內(nèi)存開銷只有 1.5GB，查詢時內(nèi)存增長也覺察不出來，整體內(nèi)存開銷比 SQLServer 降低了 50%。”

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

鼎藍水務(wù)智慧排水系統(tǒng)需要處理來自攔蓄盾檢測設(shè)備上報的數(shù)據(jù)。在這些監(jiān)測數(shù)據(jù)的處理流程上，數(shù)據(jù)從網(wǎng)關(guān)推送過來后會有一個判斷是否實時數(shù)據(jù)。此前所有數(shù)據(jù)都是使用 SQL Server 存儲，數(shù)據(jù)量達到 2000 萬后 SQL Server 的查詢時延就變得非常慢，不得不做分庫分表操作來提高查詢速度，但這個解決方法遇到跨庫跨表的查詢非常不便。架構(gòu)改造后，對于非實時數(shù)據(jù)，則會流經(jīng) Redis 去重，做報警判斷然后寫入 SQL Server；對于實時數(shù)據(jù)則直接寫入 TDengine，不需要再經(jīng)過 Redis，之后前端需要的一些類似液位電流數(shù)據(jù)等就可以直接從 TDengine 訪問。

數(shù)據(jù)處理流程圖

萬朗智水 x TDengine

“設(shè)置參數(shù)為十萬張點表，每個點表 1s 需要存儲 1 條記錄。在實際測試過程中，使用 HTTP 接口，采用單機 4C16GB 的配置，8 線程每次寫 500 條記錄，10 萬條記錄寫入只需要 300ms（如果使用 java 客戶端更快）；單變量采樣查詢基本在 2ms 內(nèi)完成。整個測試持續(xù)了 48 小時，測試期間 CPU 在 20%-30% 之間，內(nèi)存維持在 6GB 左右，寫入相當穩(wěn)定，沒有出現(xiàn)超時。查詢方面，我們使用 MySQL 查詢 3 個點一年的數(shù)據(jù)直接請求超時，使用 TDengine 基本 2s 左右就能返回給頁面進行渲染。寫入和查詢速度比 OpenTSDB 都還高一個級別?！?/p>

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

萬朗智水水環(huán)境綜合治理運維系統(tǒng)需要對截流井設(shè)備中的液位、電流、硫化氫等進行監(jiān)測，并通過 PLC 程序進行自動化管理設(shè)備的啟停與報警短信推送。系統(tǒng)前期版本使用了 MySQL 來存儲設(shè)備上報數(shù)據(jù)。但接入系統(tǒng)的設(shè)備量日益增長、用戶對數(shù)據(jù)實時性反饋的要求也越來越高，MySQL已經(jīng)無法滿足業(yè)務(wù)需求——隨著業(yè)務(wù)在不斷擴張，站點在不斷增加的情況下，頻繁的跨表操作 MySQL 查詢出現(xiàn)了延時甚至超時死鎖的情況。隨后在數(shù)據(jù)庫調(diào)研中，萬朗智水發(fā)現(xiàn)將設(shè)備數(shù)據(jù)轉(zhuǎn)移到時序數(shù)據(jù)庫（Time Series Database） TDengine 中存儲是個更好的解決方案。

數(shù)據(jù)傳輸路徑

傳感器采集的信息通過 MQTT 協(xié)議傳到網(wǎng)關(guān)，網(wǎng)關(guān)收集到信息后會定時推送到業(yè)務(wù)后臺服務(wù)，由服務(wù)層來做數(shù)據(jù)存儲和實時分析。設(shè)備運行業(yè)務(wù)數(shù)據(jù)放在 MySQL 中，液位、電流頻率、硫化氫、雨量物聯(lián)網(wǎng)數(shù)據(jù)則存儲在 TDengine 中。

點擊案例查看更多技術(shù)細節(jié)

結(jié)語

從以上案例不難看出，在智慧水務(wù)場景下，面對不斷增長的設(shè)備數(shù)量、龐大的時序數(shù)據(jù)處理需求，專業(yè)的時序數(shù)據(jù)庫顯然比傳統(tǒng)數(shù)據(jù)庫解決方案效果更加明顯，不管是在寫入還是查詢抑或是存儲上都有很大改善，資源開銷成本也變得更低。如果你有同樣的困擾，歡迎添加小T vx：tdengine1，我們會邀請你進入TDengine 用戶交流群，和志同道合的研發(fā)小伙伴共同解決數(shù)據(jù)難題。