小 T 導讀：禹為(wei)科技在現代灌區信(xin)息(xi)化(hua)平臺的(de)(de)(de)建設過程(cheng)(cheng)中，經歷(li)了(le)數(shu)據庫&定時任務的(de)(de)(de)架構、以(yi)流式計算為(wei)核(he)(he)心的(de)(de)(de)架構和以(yi) TDengine Database 為(wei)核(he)(he)心的(de)(de)(de)架構三個階段，最終選(xuan)用(yong) TDengine 幫(bang)助其對水(shui)位、流量、水(shui)量等(deng)實時指標數(shu)據分析。本文分享了(le)他們技術選(xuan)型的(de)(de)(de)過程(cheng)(cheng)，建庫建表的(de)(de)(de)思路以(yi)及使用(yong) TDengine 后的(de)(de)(de)收益(yi)。
公司簡介
成都(dou)禹為(wei)科(ke)(ke)技有限責任公司是一(yi)家基于(yu)多年水利(li)行(xing)業經驗成功(gong)孵化而出的高科(ke)(ke)技企業，專注于(yu)物(wu)聯網(wang)、大數據和數字孿生(sheng)技術在(zai)水利(li)行(xing)業中的應用，致力(li)于(yu)通(tong)過(guo)自身行(xing)業經驗和研發能力(li)為(wei)水利(li)行(xing)業管理者(zhe)與建設者(zhe)提供全方位(wei)的數字化解(jie)決(jue)方案和價(jia)值服務。
灌(guan)(guan)區(qu)信(xin)息化平臺是以灌(guan)(guan)區(qu)內建設物(wu)理網(wang)系統(tong)、無(wu)人機系統(tong)結合衛星遙感等感知系統(tong)為基礎，對灌(guan)(guan)區(qu)內的水(shui)(shui)雨情(qing)、土壤(rang)墑情(qing)、工程信(xin)息、氣象(xiang)信(xin)息及作物(wu)分(fen)布(bu)等信(xin)息進行監視，通過大數據分(fen)析(xi)，結合 GIS、數字孿(luan)生等技術為灌(guan)(guan)區(qu)提供量測水(shui)(shui)服務、供需(xu)水(shui)(shui)預報、水(shui)(shui)資(zi)源綜合調(diao)度(du)、水(shui)(shui)旱災害防御(yu)、供用水(shui)(shui)管理、重點區(qu)域視頻監視、遠程設備控制等功能(neng)。
相較于以(yi)往的水利信息化(hua)系統(tong)，現(xian)(xian)代灌區信息化(hua)平臺呈現(xian)(xian)以(yi)下(xia)特點：
- 設備廠家多，數據沒有統一規范，數據質量無法保障
- 數據多且存儲周期長，一個中型灌區一年數據量約為 300~500 億條，數據要求至少保存 10 年及以上，關鍵數據甚至要求保存 20 年及以上
- 數據類型較為集中，主要集中在水位、流量、閘門開度、環境溫濕度、土壤溫濕度、雨量等
- 需要實時展示的指標較多，一般有各關鍵節點上的實時水位、小時平均水位、5 分鐘水量、日水量等
- 個性化的數據 OLAP 需求較多，且對數據準確性要求較高
為了(le)解耦系統(tong)中的數據(ju)(ju)(ju)(ju)接(jie)(jie)入和數據(ju)(ju)(ju)(ju)分(fen)析，我(wo)們(men)將數據(ju)(ju)(ju)(ju)的接(jie)(jie)入和計算分(fen)析拆分(fen)為獨立(li)的通(tong)用物聯網(wang)平臺及大數據(ju)(ju)(ju)(ju)平臺，在整個系統(tong)的技術選型方案中，我(wo)們(men)經歷(li)了(le)數據(ju)(ju)(ju)(ju)庫&定時任務(wu)的架構、以(yi)流(liu)式(shi)計算為核心(xin)的架構和以(yi) TDengine 為核心(xin)的架構三個階段。
一、技術方案
1. 數據庫&定時任務的架構
在系統設(she)計之初，我們(men)(men)考慮直接使用 MySQL+MongoDB+定時任務(wu)的(de)方式來支撐我們(men)(men)的(de)系統：MySQL 存儲(chu)所有的(de)業務(wu)數(shu)據(ju)(ju)(ju)(ju)及維度信息；MongoDB 存儲(chu)設(she)備實時數(shu)據(ju)(ju)(ju)(ju)以(yi)及水量等(deng)業務(wu)數(shu)據(ju)(ju)(ju)(ju)；為了解決分鐘水量、日水量等(deng)數(shu)據(ju)(ju)(ju)(ju)的(de)計算(suan)，我們(men)(men)使用定時任務(wu)在計算(suan)時從(cong)(cong) MongoDB 中獲取實時數(shu)據(ju)(ju)(ju)(ju)，從(cong)(cong)MySQL中獲取維度數(shu)據(ju)(ju)(ju)(ju)，將處(chu)理(li)好(hao)的(de)數(shu)據(ju)(ju)(ju)(ju)再寫回(hui) MongoDB 中，通過(guo)提(ti)前預計算(suan)的(de)方式為前端提(ti)供數(shu)據(ju)(ju)(ju)(ju)。
但這(zhe)種方式有以下幾個問題：
- 無法對設備數據進行靈活的治理分析，設備數據亂序后需要通過人工干預或程序預處理的方式糾偏；
- 需要提前考慮多種維度的數據處理，以便滿足實時數據展示和 OLAP 查詢的需求；
- 5 分鐘水量、日水量等數據使用定時任務計算會導致數據庫負載過重；
- 在數據較多的情況下，MongoDB 必須使用更多的硬件資源搭建數據庫集群，才能滿足存儲和數據查詢的要求。
2. 以流式計算為核心的架構
鑒于(yu)在(zai)數(shu)據(ju)庫&定時(shi)任(ren)務(wu)的(de)架構(gou)方(fang)案(an)中出現的(de)數(shu)據(ju)處理(li)較慢的(de)問題，結合筆者在(zai)過(guo)往(wang)工作中所積累的(de)經驗(yan)，我(wo)們設計(ji)了流式計(ji)算數(shu)據(ju)架構(gou)方(fang)案(an)。
數(shu)據通過(guo)物(wu)聯網系統進(jin)入系統，經過(guo)處理(li)后(hou)會根據設備(bei)類型被標準(zhun)化(hua)為統一格式(shi)的(de)數(shu)據，然后(hou)數(shu)據被寫入 OpenTSDB 和(he) Kafka 中，供 Flink 消(xiao)費。Flink 按照(zhao) Job 定義消(xiao)費 Kafka 數(shu)據，并按照(zhao) MySQL 中的(de)維表(biao)信息進(jin)行加工處理(li)，然后(hou)寫入 MongoDB 中；同(tong)時還(huan)將數(shu)據處理(li)為分(fen)鐘水量(liang)、日數(shu)量(liang)等(deng)業務實時所需的(de)數(shu)據。
相較于上一版方案，數(shu)(shu)據亂(luan)序問題以及(ji)數(shu)(shu)據實時(shi)計算(suan)的(de)(de)(de)問題得到了(le)良好的(de)(de)(de)解決，同時(shi)也能很(hen)好地(di)滿足(zu) OLAP 等業(ye)務(wu)對數(shu)(shu)據的(de)(de)(de)查詢要(yao)求。但該(gai)方案增(zeng)加(jia)(jia)了(le) Flink、Kafka 以及(ji) OpenTSDB 三(san)個(ge)較為大型的(de)(de)(de)工具(ju)，無形中(zhong)增(zeng)加(jia)(jia)了(le)項目的(de)(de)(de)建設成(cheng)(cheng)本及(ji)運(yun)維成(cheng)(cheng)本。是(shi)否有一種平臺(tai)可以集數(shu)(shu)據存儲(chu)、消息隊(dui)列、大數(shu)(shu)據計算(suan)及(ji)分析(xi)于一身，且(qie)不(bu)會過多(duo)的(de)(de)(de)增(zeng)加(jia)(jia)硬(ying)件成(cheng)(cheng)本？TDengine 最(zui)終走(zou)進了(le)我(wo)們(men)的(de)(de)(de)視線(xian)。
3. 以 TDengine Database 為核心的架構
由于(yu)以(yi)上兩個(ge)(ge)方案都(dou)各自(zi)有(you)自(zi)己的(de)缺陷(xian)，我(wo)(wo)們(men)試著調研尋求一(yi)個(ge)(ge)更適合我(wo)(wo)們(men)的(de)平臺方案，偶然間(jian)筆者(zhe)從一(yi)位從事(shi)工(gong)業物聯網多(duo)年的(de)朋(peng)友(you)那(nei)里了(le)解到 TDengine 這個(ge)(ge)產(chan)品，于(yu)是(shi)我(wo)(wo)們(men)迅速從查(cha)詢效(xiao)(xiao)率(lv)、寫入效(xiao)(xiao)率(lv)、穩定性、容錯率(lv)以(yi)及功(gong)能完整性等方面對多(duo)個(ge)(ge)數據庫進行(xing)了(le)調研，最(zui)終我(wo)(wo)們(men)認為 TDengine 是(shi)當下最(zui)適合我(wo)(wo)們(men)的(de)。原(yuan)因(yin)如下：
- 查詢和寫入速度極快，億級數據瞬間查詢
- 豐富的查詢方案，能夠很好地滿足業務需求
- 使用和部署簡單，官方文檔齊全，類 SQL 語法可以降低學習成本
- 支持消息隊列、消息訂閱、緩存、流式計算等功能，優勢明顯
- 集群等高級功能均開源免費，集群擴容容易
- 數據庫資源需求較少，能夠顯著地減少系統的建設成本
系統架構如下(xia)圖所示。
相較于(yu)上(shang)兩版方案，整個架構在數據存儲和數據查詢分析環節更加簡潔，使用 TDengine 替代(dai)了(le) Flink、Kafka、OpenTSDB 三(san)個重量級工具。
4. 設備數據
原本我們的(de)系統(tong)中就有設(she)備(bei)模型(xing)的(de)概(gai)念，用(yong)以(yi)隔離設(she)備(bei)廠商之間設(she)備(bei)數據(ju)標準(zhun)不統(tong)一(yi)所帶來的(de)問題，而(er) TDengine 提供(gong)的(de)超級(ji)表概(gai)念與我們的(de)設(she)備(bei)模型(xing)概(gai)念不謀而(er)合！
create stable model_${設備類型編號}
(ts timestamp,${設備標準數據屬性})
tags
(devicesn binary(50));設備子表建表語句
create device_${devicesn} using model_${設備類型編號} tags (${devicesn});
實(shi)時數據的查詢(xun)語句如(ru)下
select last_value(*) from device_${devicesn};
聚合數據查詢也是(shi)非常方便，比如查詢某設(she)備一天內每小時的(de)平(ping)均值
select avg(val) from device_${devicesn} where ts>now-1d interval(1h);
5. 實時指標
在(zai)灌區信息化平臺(tai)中，幾乎所有(you)的(de)(de)實(shi)時指標數據分(fen)析源(yuan)數據都集中在(zai)水(shui)位(wei)、流(liu)量、水(shui)量上，為了解決業(ye)務中的(de)(de)需求，我(wo)們將水(shui)位(wei)、瞬時流(liu)量、累計(ji)流(liu)量從(cong)設(she)備數據中單(dan)獨抽取到一個獨立的(de)(de)水(shui)量專(zhuan)題表中。
create stable st_water
(ts timestamp,waterleve float,instantflow float,accumflow double)
tags
(devicesn binary(50));
改(gai)用(yong) TDengine 后，查詢(xun)(xun)各類指標(biao)數據，我們(men)不再使用(yong)任何預處理，而是(shi)在前端需(xu)要展示數據時，通過(guo) SQL 直接查詢(xun)(xun)所需(xu)要的數據。比如(ru) 5 分鐘水量查詢(xun)(xun)語句(ju)如(ru)下：
select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)
一(yi)(yi)條 SQL 解決了(le)以往需要一(yi)(yi)番周折才能(neng)解決的問題，太棒了(le)！！
6. 使用 TDengine 后的收益
- 簡化了系統架構
- TDengine 的消息訂閱、緩存、流式計算等諸多特性，可以代替 Kafka、OpenTSDB 和 Flink，減少業務代碼中定時計算（如用水量）等功能，簡化了整體架構
- 降低運維成本和開發成本
- 架構簡化以后，排查和定位問題能快速響應，節約開發和運維成本
- 降低數據存儲成本
- TDengine 表結構設計合理，可以節省存儲空間，進而節省存儲費用
- 提高數據實時性和一致性
- TDengine 替代了 OpenTSDB+Redis+MySQL，提高了數據實時性和一致性
二、未來展望
在(zai)現代灌區(qu)信息化平臺(tai)建設(she)過程中，由(you)于某些歷(li)史(shi)原因(yin)，我們(men)還有許多如閘門控制、狀(zhuang)態實時(shi)預(yu)警、水旱災(zai)害防御等(deng)業務功能依(yi)舊在(zai)使用定時(shi)任務來(lai)進(jin)行(xing)告(gao)警觸發。我們(men)準備(bei)在(zai)不久的將(jiang)來(lai)，將(jiang)以(yi)上業務與 TDengine 的告(gao)警功能結合(he)起來(lai)，逐步將(jiang)系統(tong)統(tong)一起來(lai)。也希望 TDengine 越來(lai)越好！
