> 小 T 導讀：禹為科技在現代灌區資訊化平臺的建設過程中，經歷了資料庫&定時任務的架構、以流式計算為核心的架構和以 TDengine 為核心的架構三個階段，最終選用 TDengine 幫助其對水位、流量、水量等實時指標資料分析。本文分享了他們技術選型的過程，建庫建表的思路以及使用 TDengine 後的收益。

**公司簡介**
成都禹為科技有限責任公司是一家基於多年水利行業經驗成功孵化而出的高科技企業，專注於物聯網、大資料和數字孿生技術在水利行業中的應用，致力於透過自身行業經驗和研發能力為水利行業管理者與建設者提供全方位的數字化解決方案和價值服務。
![](http://img.blog.itpub.net/blog/2022/03/30/25984f18a8972021.png?x-oss-process=style/bb)
灌區資訊化平臺是以灌區內建設物理網系統、無人機系統結合衛星遙感等感知系統為基礎，對灌區內的水雨情、土壤墒情、工程資訊、氣象資訊及作物分佈等資訊進行監視，透過大資料分析，結合 GIS、數字孿生等技術為灌區提供量測水服務、供需水預報、水資源綜合排程、水旱災害防禦、供用水管理、重點區域影片監視、遠端裝置控制等功能。

相較於以往的水利資訊化系統，現代灌區資訊化平臺呈現以下特點：

- 裝置廠家多，資料沒有統一規範，資料質量無法保障
- 資料多且儲存週期長，一箇中型灌區一年資料量約為 300~500 億條，資料要求至少儲存 10 年及以上，關鍵資料甚至要求儲存 20 年及以上
- 資料型別較為集中，主要集中在水位、流量、閘門開度、環境溫溼度、土壤溫溼度、雨量等
- 需要實時展示的指標較多，一般有各關鍵節點上的實時水位、小時平均水位、5 分鐘水量、日水量等
- 個性化的資料 OLAP 需求較多，且對資料準確性要求較高

![](http://img.blog.itpub.net/blog/2022/03/30/ae9a24b8d886f96e.png?x-oss-process=style/bb)
產品架構圖

為了解耦系統中的資料接入和資料分析，我們將資料的接入和計算分析拆分為獨立的通用物聯網平臺及大資料平臺，在整個系統的技術選型方案中，我們經歷了資料庫&定時任務的架構、以流式計算為核心的架構和以 TDengine 為核心的架構三個階段。

**一、技術方案**

**1. 資料庫&定時任務的架構**

在系統設計之初，我們考慮直接使用 MySQL+MongoDB+定時任務的方式來支撐我們的系統：MySQL 儲存所有的業務資料及維度資訊；MongoDB 儲存裝置實時資料以及水量等業務資料；為了解決分鐘水量、日水量等資料的計算，我們使用定時任務在計算時從 MongoDB 中獲取實時資料，從MySQL中獲取維度資料，將處理好的資料再寫回 MongoDB 中，透過提前預計算的方式為前端提供資料。

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

- 無法對裝置資料進行靈活的治理分析，裝置資料亂序後需要透過人工干預或程式預處理的方式糾偏；
- 需要提前考慮多種維度的資料處理，以便滿足實時資料展示和 OLAP 查詢的需求；
- 5 分鐘水量、日水量等資料使用定時任務計算會導致資料庫負載過重；
- 在資料較多的情況下，MongoDB 必須使用更多的硬體資源搭建資料庫叢集，才能滿足儲存和資料查詢的要求。

**2. 以流式計算為核心的架構**

鑑於在資料庫&定時任務的架構方案中出現的資料處理較慢的問題，結合筆者在過往工作中所積累的經驗，我們設計了流式計算資料架構方案。
![](http://img.blog.itpub.net/blog/2022/03/30/54837757091832ed.png?x-oss-process=style/bb)
資料透過物聯網系統進入系統，經過處理後會根據裝置型別被標準化為統一格式的資料，然後資料被寫入 OpenTSDB 和 Kafka 中，供 Flink 消費。Flink 按照 Job 定義消費 Kafka 資料，並按照 MySQL 中的維表資訊進行加工處理，然後寫入 MongoDB 中；同時還將資料處理為分鐘水量、日數量等業務實時所需的資料。

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

**3. 以 TDengine 為核心的架構**

由於以上兩個方案都各自有自己的缺陷，我們試著調研尋求一個更適合我們的平臺方案，偶然間筆者從一位從事工業物聯網多年的朋友那裡瞭解到 TDengine 這個產品，於是我們迅速從查詢效率、寫入效率、穩定性、容錯率以及功能完整性等方面對多個資料庫進行了調研，最終我們認為 TDengine 是當下最適合我們的。原因如下：

- 查詢和寫入速度極快，億級資料瞬間查詢
- 豐富的查詢方案，能夠很好地滿足業務需求
- 使用和部署簡單，官方文件齊全，類 SQL 語法可以降低學習成本
- 支援訊息佇列、訊息訂閱、快取、流式計算等功能，優勢明顯
- 叢集等高階功能均開源免費，叢集擴容容易
- 資料庫資源需求較少，能夠顯著地減少系統的建設成本

系統架構如下圖所示。
![](http://img.blog.itpub.net/blog/2022/03/30/26a82d912d1f8f29.png?x-oss-process=style/bb)

相較於上兩版方案，整個架構在資料儲存和資料查詢分析環節更加簡潔，使用 TDengine 替代了 Flink、Kafka、OpenTSDB 三個重量級工具。

**4. 裝置資料**

原本我們的系統中就有裝置模型的概念，用以隔離裝置廠商之間裝置資料標準不統一所帶來的問題，而 TDengine 提供的超級表概念與我們的裝置模型概念不謀而合！

> create stable model_${裝置型別編號} 
 (ts timestamp,${裝置標準資料屬性}) 
tags 
 (devicesn binary(50));

裝置子表建表語句
> create device_${devicesn} using model_${裝置型別編號} tags (${devicesn});

實時資料的查詢語句如下
> select last_value(*) from device_${devicesn};

聚合資料查詢也是非常方便，比如查詢某裝置一天內每小時的平均值
> select avg(val) from device_${devicesn} where ts>now-1d interval(1h);

**5. 實時指標**

在灌區資訊化平臺中，幾乎所有的實時指標資料分析源資料都集中在水位、流量、水量上，為了解決業務中的需求，我們將水位、瞬時流量、累計流量從裝置資料中單獨抽取到一個獨立的水量專題表中。
> create stable st_water
 (ts timestamp,waterleve float,instantflow float,accumflow double)
tags
 (devicesn binary(50));

改用 TDengine 後，查詢各類指標資料，我們不再使用任何預處理，而是在前端需要展示資料時，透過 SQL 直接查詢所需要的資料。比如 5 分鐘水量查詢語句如下：
> select last(accumflow)-first(accumflow) from st_water where ts>now-1d and devicesn=xxxx interval(5m)

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

**6. 使用 TDengine 後的收益**

-  **簡化了系統架構 **
- TDengine 的訊息訂閱、快取、流式計算等諸多特性，可以代替 Kafka、OpenTSDB 和 Flink，減少業務程式碼中定時計算（如用水量）等功能，簡化了整體架構
- **降低運維成本和開發成本 **
- 架構簡化以後，排查和定位問題能快速響應，節約開發和運維成本 
- **降低資料儲存成本 **
- TDengine 表結構設計合理，可以節省儲存空間，進而節省儲存費用 
- **提高資料實時性和一致性 **
- TDengine 替代了 OpenTSDB+Redis+MySQL，提高了資料實時性和一致性

**二、未來展望**

在現代灌區資訊化平臺建設過程中，由於某些歷史原因，我們還有許多如閘門控制、狀態實時預警、水旱災害防禦等業務功能依舊在使用定時任務來進行告警觸發。我們準備在不久的將來，將以上業務與 TDengine 的告警功能結合起來，逐步將系統統一起來。也希望 TDengine 越來越好！

------------

想了解更多 TDengine 的具體細節，歡迎大家在[GitHub](https://github.com/taosdata/TDengine "GitHub")上檢視相關原始碼。
[![](http://img.blog.itpub.net/blog/2022/03/28/36f3ecc653e3892c.jpeg?x-oss-process=style/bb)](https://www.taosdata.com?utm_source=itpub&utm_medium=tdengine&utm_campaign=techarti&utm_term=20220330)

減少計算、簡化架構——TDengine在灌區資訊化平臺中的應用

相關文章