小 T 導(dǎo)讀：禹為科技在現(xiàn)代灌區(qū)信息化平臺的建設(shè)過程中，經(jīng)歷了數(shù)據(jù)庫&定時任務(wù)的架構(gòu)、以流式計算為核心的架構(gòu)和以 TDengine Database 為核心的架構(gòu)三個階段，最終選用 TDengine 幫助其對水位、流量、水量等實時指標數(shù)據(jù)分析。本文分享了他們技術(shù)選型的過程，建庫建表的思路以及使用 TDengine 后的收益。

公司簡介

成都禹為科技有限責(zé)任公司是一家基于多年水利行業(yè)經(jīng)驗成功孵化而出的高科技企業(yè)，專注于物聯(lián)網(wǎng)、大數(shù)據(jù)和數(shù)字孿生技術(shù)在水利行業(yè)中的應(yīng)用，致力于通過自身行業(yè)經(jīng)驗和研發(fā)能力為水利行業(yè)管理者與建設(shè)者提供全方位的數(shù)字化解決方案和價值服務(wù)。

灌區(qū)信息化平臺是以灌區(qū)內(nèi)建設(shè)物理網(wǎng)系統(tǒng)、無人機系統(tǒng)結(jié)合衛(wèi)星遙感等感知系統(tǒng)為基礎(chǔ)，對灌區(qū)內(nèi)的水雨情、土壤墑情、工程信息、氣象信息及作物分布等信息進行監(jiān)視，通過大數(shù)據(jù)分析，結(jié)合 GIS、數(shù)字孿生等技術(shù)為灌區(qū)提供量測水服務(wù)、供需水預(yù)報、水資源綜合調(diào)度、水旱災(zāi)害防御、供用水管理、重點區(qū)域視頻監(jiān)視、遠程設(shè)備控制等功能。

相較于以往的水利信息化系統(tǒng)，現(xiàn)代灌區(qū)信息化平臺呈現(xiàn)以下特點：

• 設(shè)備廠家多，數(shù)據(jù)沒有統(tǒng)一規(guī)范，數(shù)據(jù)質(zhì)量無法保障
• 數(shù)據(jù)多且存儲周期長，一個中型灌區(qū)一年數(shù)據(jù)量約為 300~500 億條，數(shù)據(jù)要求至少保存 10 年及以上，關(guān)鍵數(shù)據(jù)甚至要求保存 20 年及以上
• 數(shù)據(jù)類型較為集中，主要集中在水位、流量、閘門開度、環(huán)境溫濕度、土壤溫濕度、雨量等
• 需要實時展示的指標較多，一般有各關(guān)鍵節(jié)點上的實時水位、小時平均水位、5 分鐘水量、日水量等
• 個性化的數(shù)據(jù) OLAP 需求較多，且對數(shù)據(jù)準確性要求較高

為了解耦系統(tǒng)中的數(shù)據(jù)接入和數(shù)據(jù)分析，我們將數(shù)據(jù)的接入和計算分析拆分為獨立的通用物聯(lián)網(wǎng)平臺及大數(shù)據(jù)平臺，在整個系統(tǒng)的技術(shù)選型方案中，我們經(jīng)歷了數(shù)據(jù)庫&定時任務(wù)的架構(gòu)、以流式計算為核心的架構(gòu)和以 TDengine 為核心的架構(gòu)三個階段。

一、技術(shù)方案

1. 數(shù)據(jù)庫&定時任務(wù)的架構(gòu)

在系統(tǒng)設(shè)計之初，我們考慮直接使用 MySQL+MongoDB+定時任務(wù)的方式來支撐我們的系統(tǒng)：MySQL 存儲所有的業(yè)務(wù)數(shù)據(jù)及維度信息；MongoDB 存儲設(shè)備實時數(shù)據(jù)以及水量等業(yè)務(wù)數(shù)據(jù)；為了解決分鐘水量、日水量等數(shù)據(jù)的計算，我們使用定時任務(wù)在計算時從 MongoDB 中獲取實時數(shù)據(jù)，從MySQL中獲取維度數(shù)據(jù)，將處理好的數(shù)據(jù)再寫回 MongoDB 中，通過提前預(yù)計算的方式為前端提供數(shù)據(jù)。

但這種方式有以下幾個問題：

• 無法對設(shè)備數(shù)據(jù)進行靈活的治理分析，設(shè)備數(shù)據(jù)亂序后需要通過人工干預(yù)或程序預(yù)處理的方式糾偏；
• 需要提前考慮多種維度的數(shù)據(jù)處理，以便滿足實時數(shù)據(jù)展示和 OLAP 查詢的需求；
• 5 分鐘水量、日水量等數(shù)據(jù)使用定時任務(wù)計算會導(dǎo)致數(shù)據(jù)庫負載過重；
• 在數(shù)據(jù)較多的情況下，MongoDB 必須使用更多的硬件資源搭建數(shù)據(jù)庫集群，才能滿足存儲和數(shù)據(jù)查詢的要求。

2. 以流式計算為核心的架構(gòu)

鑒于在數(shù)據(jù)庫&定時任務(wù)的架構(gòu)方案中出現(xiàn)的數(shù)據(jù)處理較慢的問題，結(jié)合筆者在過往工作中所積累的經(jīng)驗，我們設(shè)計了流式計算數(shù)據(jù)架構(gòu)方案。

數(shù)據(jù)通過物聯(lián)網(wǎng)系統(tǒng)進入系統(tǒng)，經(jīng)過處理后會根據(jù)設(shè)備類型被標準化為統(tǒng)一格式的數(shù)據(jù)，然后數(shù)據(jù)被寫入 OpenTSDB 和 Kafka 中，供 Flink 消費。Flink 按照 Job 定義消費 Kafka 數(shù)據(jù)，并按照 MySQL 中的維表信息進行加工處理，然后寫入 MongoDB 中；同時還將數(shù)據(jù)處理為分鐘水量、日數(shù)量等業(yè)務(wù)實時所需的數(shù)據(jù)。

相較于上一版方案，數(shù)據(jù)亂序問題以及數(shù)據(jù)實時計算的問題得到了良好的解決，同時也能很好地滿足 OLAP 等業(yè)務(wù)對數(shù)據(jù)的查詢要求。但該方案增加了 Flink、Kafka 以及 OpenTSDB 三個較為大型的工具，無形中增加了項目的建設(shè)成本及運維成本。是否有一種平臺可以集數(shù)據(jù)存儲、消息隊列、大數(shù)據(jù)計算及分析于一身，且不會過多的增加硬件成本？TDengine 最終走進了我們的視線。

3. 以 TDengine Database 為核心的架構(gòu)

由于以上兩個方案都各自有自己的缺陷，我們試著調(diào)研尋求一個更適合我們的平臺方案，偶然間筆者從一位從事工業(yè)物聯(lián)網(wǎng)多年的朋友那里了解到 TDengine 這個產(chǎn)品，于是我們迅速從查詢效率、寫入效率、穩(wěn)定性、容錯率以及功能完整性等方面對多個數(shù)據(jù)庫進行了調(diào)研，最終我們認為 TDengine 是當下最適合我們的。原因如下：

• 查詢和寫入速度極快，億級數(shù)據(jù)瞬間查詢
• 豐富的查詢方案，能夠很好地滿足業(yè)務(wù)需求
• 使用和部署簡單，官方文檔齊全，類 SQL 語法可以降低學(xué)習(xí)成本
• 支持消息隊列、消息訂閱、緩存、流式計算等功能，優(yōu)勢明顯
• 集群等高級功能均開源免費，集群擴容容易
• 數(shù)據(jù)庫資源需求較少，能夠顯著地減少系統(tǒng)的建設(shè)成本

系統(tǒng)架構(gòu)如下圖所示。

相較于上兩版方案，整個架構(gòu)在數(shù)據(jù)存儲和數(shù)據(jù)查詢分析環(huán)節(jié)更加簡潔，使用 TDengine 替代了 Flink、Kafka、OpenTSDB 三個重量級工具。

4. 設(shè)備數(shù)據(jù)

原本我們的系統(tǒng)中就有設(shè)備模型的概念，用以隔離設(shè)備廠商之間設(shè)備數(shù)據(jù)標準不統(tǒng)一所帶來的問題，而 TDengine 提供的超級表概念與我們的設(shè)備模型概念不謀而合！

create stable model_${設(shè)備類型編號} 
 (ts timestamp,${設(shè)備標準數(shù)據(jù)屬性}) 
tags 
 (devicesn binary(50));

設(shè)備子表建表語句

create device_${devicesn} using model_${設(shè)備類型編號} tags (${devicesn});

實時數(shù)據(jù)的查詢語句如下

select last_value(*) from device_${devicesn};

聚合數(shù)據(jù)查詢也是非常方便，比如查詢某設(shè)備一天內(nèi)每小時的平均值

select avg(val) from device_${devicesn} where ts>now-1d interval(1h);

5. 實時指標

在灌區(qū)信息化平臺中，幾乎所有的實時指標數(shù)據(jù)分析源數(shù)據(jù)都集中在水位、流量、水量上，為了解決業(yè)務(wù)中的需求，我們將水位、瞬時流量、累計流量從設(shè)備數(shù)據(jù)中單獨抽取到一個獨立的水量專題表中。

create stable st_water
 (ts timestamp,waterleve float,instantflow float,accumflow double)
tags
 (devicesn binary(50));

改用 TDengine 后，查詢各類指標數(shù)據(jù)，我們不再使用任何預(yù)處理，而是在前端需要展示數(shù)據(jù)時，通過 SQL 直接查詢所需要的數(shù)據(jù)。比如 5 分鐘水量查詢語句如下：

select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)

一條 SQL 解決了以往需要一番周折才能解決的問題，太棒了??！

6. 使用 TDengine 后的收益

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

二、未來展望

在現(xiàn)代灌區(qū)信息化平臺建設(shè)過程中，由于某些歷史原因，我們還有許多如閘門控制、狀態(tài)實時預(yù)警、水旱災(zāi)害防御等業(yè)務(wù)功能依舊在使用定時任務(wù)來進行告警觸發(fā)。我們準備在不久的將來，將以上業(yè)務(wù)與 TDengine 的告警功能結(jié)合起來，逐步將系統(tǒng)統(tǒng)一起來。也希望 TDengine 越來越好！