在(zai)智慧水務(wu)系統中(zhong)，往往需要對(dui)設備中(zhong)產生的液位(wei)、電流、水量(liang)(liang)等實時(shi)(shi)指標數(shu)(shu)(shu)(shu)(shu)據(ju)進行(xing)(xing)存儲(chu)、分析及監(jian)控(kong)操作，而(er)這些(xie)都(dou)是典型的時(shi)(shi)序數(shu)(shu)(shu)(shu)(shu)據(ju)。面對(dui)這些(xie)數(shu)(shu)(shu)(shu)(shu)據(ju)的處(chu)理時(shi)(shi)，很多(duo)企(qi)業(ye)在(zai)前期選(xuan)擇的大(da)都(dou)是傳統的實時(shi)(shi)數(shu)(shu)(shu)(shu)(shu)據(ju)庫(ku)甚至關(guan)系型數(shu)(shu)(shu)(shu)(shu)據(ju)庫(ku)，隨(sui)著設備數(shu)(shu)(shu)(shu)(shu)量(liang)(liang)的增加(jia)，數(shu)(shu)(shu)(shu)(shu)據(ju)量(liang)(liang)也達到(dao)了百萬、千(qian)萬量(liang)(liang)級(ji)(ji)，傳統的數(shu)(shu)(shu)(shu)(shu)據(ju)庫(ku)解決方案已經無法滿足業(ye)務(wu)需求(qiu)。為了幫助(zhu)有以(yi)上問題(ti)的企(qi)業(ye)更好地(di)進行(xing)(xing)數(shu)(shu)(shu)(shu)(shu)據(ju)架構(gou)整(zheng)改，本篇文(wen)章匯總了三(san)個典型智慧水務(wu)場景下的數(shu)(shu)(shu)(shu)(shu)據(ju)架構(gou)升級(ji)(ji)實踐(jian)，給到(dao)大(da)家參考。

禹為科技 x TDengine

“TDengine 的消息訂(ding)閱、緩存(cun)、流式計(ji)算等諸多(duo)特性(xing)，可以(yi)代(dai)替 Kafka、OpenTSDB 和(he) Flink，減少(shao)業務代(dai)碼中定(ding)時(shi)計(ji)算（如用水(shui)量）等功能(neng)，簡化了整體架構(gou)。在架構(gou)簡化以(yi)后，排查和(he)定(ding)位(wei)問題(ti)也能(neng)得到快速響應(ying)，開發(fa)和(he)運(yun)維成本(ben)大(da)大(da)節(jie)約(yue)。同時(shi)，TDengine 替代(dai)了 OpenTSDB+Redis+MySQL，提高了數據實(shi)時(shi)性(xing)和(he)一(yi)致性(xing)，其表結構(gou)設(she)計(ji)合理，可以(yi)節(jie)省存(cun)儲(chu)空間，進而節(jie)省存(cun)儲(chu)費(fei)用。”

業務背景

相較于水(shui)利信息化系(xi)統(tong)，禹為科技灌(guan)區信息化平臺(tai)具有設備(bei)廠(chang)家多(duo)、數(shu)(shu)據多(duo)且(qie)存儲周期長(chang)、數(shu)(shu)據類型較為集中、需要(yao)實時展示的(de)(de)指標較多(duo)等特點。為了(le)(le)解(jie)耦系(xi)統(tong)中的(de)(de)數(shu)(shu)據接(jie)入和(he)(he)數(shu)(shu)據分析(xi)，禹為科技將數(shu)(shu)據的(de)(de)接(jie)入和(he)(he)計算(suan)分析(xi)拆分為獨立的(de)(de)通用物(wu)聯網平臺(tai)及(ji)大數(shu)(shu)據平臺(tai)，在現代(dai)灌(guan)區信息化平臺(tai)的(de)(de)建設過程(cheng)中，經歷(li)了(le)(le)數(shu)(shu)據庫&定時任務的(de)(de)架構(gou)、以(yi)流式計算(suan)為核心(xin)的(de)(de)架構(gou)和(he)(he)以(yi) TDengine 為核心(xin)的(de)(de)架構(gou)三個階段(duan)，最終選用 TDengine 幫助其(qi)對水(shui)位、流量、水(shui)量等實時指標數(shu)(shu)據分析(xi)。

架構圖

點擊案例查看更多技術細節

鼎藍水務 x TDengine

“使用(yong)感(gan)受就(jiu)是(shi)(shi) TDengine 的(de)數(shu)(shu)據處理性(xing)能非(fei)常高。現(xian)在(zai)的(de)接入(ru)網關的(de)設備(bei)數(shu)(shu)是(shi)(shi) 23 個(ge)液位、9 個(ge)頻率計(ji)、9 個(ge)電(dian)流計(ji)、10 個(ge)攔蓄盾(dun)、3 個(ge)泵站、3 個(ge)截留(liu)井、1 個(ge)泵閘，總共有(you) 40 張表(biao)(biao)，每(mei)張表(biao)(biao)每(mei)天新(xin)增(zeng) 6 萬條數(shu)(shu)據，現(xian)在(zai)每(mei)張表(biao)(biao)的(de)大(da)約三百萬條數(shu)(shu)據。使用(yong) TDengine 帶來的(de)最大(da)好(hao)處是(shi)(shi)不用(yong)再(zai)考慮 SQLServer 中的(de)分庫分表(biao)(biao)操(cao)作，數(shu)(shu)據不斷寫入(ru)一個(ge)月(yue)后(hou)，查詢時(shi)(shi)延也沒有(you)增(zeng)加。而且(qie)我們發(fa)現(xian) TDengine 在(zai)處理 13 個(ge)設備(bei)、百萬量級的(de)數(shu)(shu)據量寫入(ru)任務時(shi)(shi)，內存(cun)開銷(xiao)只有(you) 1.5GB，查詢時(shi)(shi)內存(cun)增(zeng)長也覺察不出來，整(zheng)體內存(cun)開銷(xiao)比 SQLServer 降(jiang)低了(le) 50%。”

業務背景

鼎藍水(shui)務智慧排水(shui)系統需要處(chu)理來自攔(lan)蓄盾檢測(ce)設備上報(bao)的數(shu)(shu)據(ju)(ju)(ju)。在這些監測(ce)數(shu)(shu)據(ju)(ju)(ju)的處(chu)理流程上，數(shu)(shu)據(ju)(ju)(ju)從網(wang)關推送過(guo)來后會有(you)一個(ge)判(pan)斷(duan)(duan)是否實(shi)時(shi)數(shu)(shu)據(ju)(ju)(ju)。此前(qian)所(suo)有(you)數(shu)(shu)據(ju)(ju)(ju)都是使(shi)用 SQL Server 存儲，數(shu)(shu)據(ju)(ju)(ju)量達到(dao) 2000 萬(wan)后 SQL Server 的查詢時(shi)延(yan)就變得非常慢，不得不做分(fen)(fen)庫分(fen)(fen)表操作來提高查詢速度，但這個(ge)解決方(fang)法遇到(dao)跨庫跨表的查詢非常不便。架(jia)構改造后，對(dui)于非實(shi)時(shi)數(shu)(shu)據(ju)(ju)(ju)，則會流經 Redis 去(qu)重，做報(bao)警(jing)判(pan)斷(duan)(duan)然后寫(xie)入 SQL Server；對(dui)于實(shi)時(shi)數(shu)(shu)據(ju)(ju)(ju)則直(zhi)接(jie)寫(xie)入 TDengine，不需要再(zai)經過(guo) Redis，之后前(qian)端(duan)需要的一些類似液位電流數(shu)(shu)據(ju)(ju)(ju)等(deng)就可(ke)以直(zhi)接(jie)從 TDengine 訪問。

數據處理流程圖

萬朗智水 x TDengine

“設(she)置參數(shu)為十萬張點(dian)表，每(mei)(mei)個(ge)(ge)點(dian)表 1s 需要存儲 1 條記錄。在實際測(ce)試過(guo)程中，使用(yong)(yong) HTTP 接口，采用(yong)(yong)單機 4C16GB 的(de)配置，8 線程每(mei)(mei)次寫 500 條記錄，10 萬條記錄寫入只需要 300ms（如果使用(yong)(yong) java 客戶(hu)端更快）；單變量采樣查(cha)詢(xun)基(ji)本在 2ms 內完(wan)成。整個(ge)(ge)測(ce)試持(chi)續了(le) 48 小時，測(ce)試期間(jian) CPU 在 20%-30% 之間(jian)，內存維持(chi)在 6GB 左(zuo)右(you)，寫入相當穩(wen)定，沒有出現超(chao)時。查(cha)詢(xun)方面，我們使用(yong)(yong) MySQL 查(cha)詢(xun) 3 個(ge)(ge)點(dian)一年的(de)數(shu)據(ju)直接請求超(chao)時，使用(yong)(yong) TDengine 基(ji)本 2s 左(zuo)右(you)就能返(fan)回(hui)給頁面進行渲染。寫入和查(cha)詢(xun)速度比 OpenTSDB 都還(huan)高一個(ge)(ge)級(ji)別。”

業務背景

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

數據傳輸路徑

傳(chuan)(chuan)感器采集(ji)的信(xin)息通過 MQTT 協議傳(chuan)(chuan)到網關(guan)，網關(guan)收集(ji)到信(xin)息后(hou)會定時推送到業務(wu)(wu)后(hou)臺服(fu)務(wu)(wu)，由服(fu)務(wu)(wu)層來(lai)做數據存儲和實時分析。設備運行業務(wu)(wu)數據放在(zai) MySQL 中(zhong)，液位、電流頻率、硫化氫、雨量物聯網數據則存儲在(zai) TDengine 中(zhong)。

點擊案例查看更多技術細節

結語

從(cong)以上(shang)案例不(bu)難看出，在智(zhi)慧(hui)水務場景下，面對不(bu)斷增長的(de)設備數(shu)(shu)量、龐大(da)的(de)時序(xu)數(shu)(shu)據處理(li)需求，專業的(de)時序(xu)數(shu)(shu)據庫顯(xian)然(ran)比傳(chuan)統數(shu)(shu)據庫解(jie)決方案效果(guo)更加(jia)明顯(xian)，不(bu)管是(shi)在寫入還(huan)是(shi)查詢(xun)抑或(huo)是(shi)存儲上(shang)都有(you)很大(da)改善，資源開銷成本也變得更低。如果(guo)你有(you)同(tong)樣的(de)困(kun)擾，歡(huan)迎添加(jia)小T vx：tdengine1，我們會邀(yao)請你進入TDengine 用(yong)戶(hu)交流群，和志(zhi)同(tong)道(dao)合(he)的(de)研發(fa)小伙(huo)伴(ban)共同(tong)解(jie)決數(shu)(shu)據難題。