基于TDengine的EAST工程數據監控系統

丁煦航，奚維斌，謝 杰，陳子鳴

（1.中國科學院 合肥物質科學研究院，合肥 230031；2.中國科學技術大學研究生院 科學島分院，合肥 230026）

EAST 超導托卡馬克裝置是我國設計的國際上第一個全超導托卡馬克裝置[1]，安全運行至今十幾年取得了顯著的成績，2021年實現了1.2 億攝氏度百秒等離子體運行和1056 s 長脈沖高參數等離子體運行，均打破了世界紀錄。隨著實驗邁向更高階段，對EAST 裝置安全運行的要求越來越高，目前EAST 安全運行通過關鍵運行參數閾值保護、計算機連鎖保護和各子系統值班人員的監控來保障[2]，其中工程數據在裝置運行安全分析中起著至關重要的作用。

工程數據主要是由各個子系統采集的工程信號組成，包括溫度、壓強、真空度等2500 多路，對聚變實驗分析有重要的分析價值。目前主要存儲實時值于MySQL 工程數據庫中并部分重構于MDSplus診斷數據庫中[3]，此外還有部分數據存儲在其他子系統數據庫中。異構多數據源導致數據孤島的形成，現有系統缺乏手段對歷史數據、異源數據等進行多維度計算分析且檢索效率不高，無法進一步保護EAST 裝置運行安全。除了現有的工程數據外，應力應變、絕緣性能等裝置采集數據和基于原始數據實時計算的結果也需要進行統一管理，因此建立一個EAST 工程數據監控系統對裝置運行實驗分析至關重要。

本文提出基于TDengine+Flink 流處理+Grafana可視化工具，將工程信號的數據特點和TDengine 存儲結構相結合，利用Flink 流式管道將海量散落在各個子系統中的工程數據實時計算清洗到數據庫中，建立一個中心化的工程數據倉庫，打破數據孤島，規范數據格式和提升數據質量，通過Grafana 的可視化模塊實時監控[4]，對超出閾值信號及時報警，挖掘信號之間內在關聯以對裝置運行狀況有更深入地了解。

1 系統設計

1.1 需求分析

EAST 裝置有診斷系統、電源系統、加熱系統等大量子系統，部分數據孤立且存儲格式各異形成一個個信息孤島，而工程數據作為裝置運行安全分析的重要數據來源，更是面向整機全鏈路分析的重要依據，需要重新建立一個統一格式的中心化數據倉庫并通過可視化模塊來滿足實際實驗分析需要。EAST 實驗流程一般包括降溫冷卻、穩態運行、回溫、系統維護4 個階段，以早期5 輪實驗運行時間為例，總運行天數為345 天[5]，整個階段都需要對幾千路工程信號進行采集監控以保證滿足放電實驗要求和實時了解裝置運行現狀。且工程數據一般為秒級采集頻率，單日采集可達千萬條數據，還需要對歷史數據進行存儲和原始數據二次計算挖掘，幫助實驗人員對實驗進行進一步調整。因此整個實驗運行周期的數據規模十分龐大，需要對存儲結構進行優化。

綜上所述，系統需要提供面向工程數據的數據服務，通過Flink 流式ETL 實時清洗計算數據，建立工程數據倉庫以滿足聚變實驗對于數據的分析需求，根據實際場景提供毫秒級的檢索能力和多樣的可視化監控報警模塊。

1.2 數據庫選型

EAST 工程數據具有明顯的物聯網數據特點，大多都是時序型且具有明顯的結構化特點，實際場景中很少有更新和刪除操作，查詢分析主要基于時間序列和信號名稱，且數據流量較為平穩不會出現某段時間的劇增情況，實際實驗分析中實驗人員更關注的是一段時間的數據趨勢和當前實時數值而非過去某一特定時間點的數值。

TDengine 是一個專為物聯網、工業互聯網設計和優化的全棧時序數據處理引擎，采用了兩大技術創新極大的優化存取效率[6]。第一大創新是單采集點對應單表，保證數據存儲的連續性，大幅減少隨機讀取操作。同時每張表對應一個信號避免了信號名等固定的靜態信息重復存儲。且對應的工程信號數值范圍一般會固定在一個大致范圍中，通過列式存儲結構和壓縮算法既提高了數據壓縮率，又優化了實際查詢更關注某一列數據或少數幾列場景下行式存儲逐行讀取導致讀取效率低下的問題，大幅度提高了檢索效率。第二大創新利用超級表對多個數據采集點進行高效聚合，將靜態標簽單獨k-v 存儲，多維聚合分析時先過濾標簽大幅減少聚合的數據量，根據靜態標簽進行高效多維檢索。且可以繼承超級表結構快速創建普通表，簡化了新表創建復雜度并建立了血緣聯系。

綜上所述，根據EAST 工程信號的數據特點和應用場景，TDengine 無論是列存儲、單信號單表的特殊存儲設計還是超級表和標簽對于聚合檢索的優化，都十分適合作為EAST 工程數據監控系統的底層數據庫。

1.3 系統架構

整個系統主要包括數據源、傳輸存儲層、應用層、顯示層4 層，整體架構如圖1所示。

圖1 系統整體架構Fig.1 Overall system architecture

數據源主要包括散落在各個子系統中的工程信號數據，無論是原MySQL 工程數據庫還是其他子系統的應力應變、絕緣性能等工程信號，對整機安全分析、歷史數據分析、異源關聯分析等都非常重要，需要通過傳輸存儲層進行清洗整合。

傳輸存儲層負責將各數據源數據通過Flink 流式ETL 實時寫入到數據庫中，按照規定的數據結構清洗，并通過各種轉換算子和自定義函數對數據進行計算轉化。基于TDengine 單采集點單表的設計思路，根據設計好的超級表結構按時間順序存儲各個信號點的數值到對應的普通表中。

應用層主要基于建立的工程數據庫向用戶提供數據服務，根據實際實驗場景需求，提供Busline進出口監控、縱場電流溫度對比等監控模塊。此外對關鍵工程信號設置閾值，通過報警規則和SMTP協議進行郵件報警并將報警信息寫入到數據庫中，實驗人員還可以進行即席查詢和自定義可視化模塊。

顯示層基于B/S 架構和Grafana 可視化工具給實驗人員提供工程數據的監控檢索界面，在EAST局域網環境中通過瀏覽器和權限控制訪問系統，提供各個模塊靈活直觀的顯示界面，并支持手機、電腦等多端設備訪問。

1.4 數據倉庫設計

首先設計超級表的數據結構，如圖2所示，新數據結構下數據列由采集時間和信號數值組成，將信號ID 等工程信號基本信息設置為靜態標簽，降低了存儲空間占用。根據超級表結構采用多列模型存儲，實驗人員可以根據靜態信息進行多維度聚合查詢，比如對某個子系統特定時間段的溫度數據變化進行排序等分析，更好地輔助聚變實驗進行安全性分析以便及時發現隱患信息。

圖2 存儲模型變化Fig.2 Storage model changes

接下來通過Flink 的DataStream Api 接口編寫數據源（Source）、轉換操作（Transformation）、結果接收（Sink）算子，根據各個子系統的數據存儲情況編寫計算傳輸作業，實時讀取各子系統中的數據并使用TDengine 提供的JDBC 接口根據超級表數據結構以信號名為表名自動創建普通表并寫入，如圖3所示。

圖3 數據清洗設計Fig.3 Data cleaning design

2 系統實現

2.1 系統工作流程

如圖4所示，系統通過上傳的Flink 作業來將不同子系統中的工程數據不斷傳輸到設計好的數據庫中并計算流量、熱負荷等關鍵參數。實驗人員通過工程數據監控系統提供的可視化模塊實時了解裝置運行狀況，比如監控關鍵進出口溫度并通過波形圖和閾值線分析有安全隱患的工程信號。監控報警模塊對海量工程信號設定閾值并實時自動監控，郵件告警并記錄到數據庫中，彌補了實驗人員人力監控的不足。

圖4 系統工作流程Fig.4 System work flow chart

2.2 工程數據庫搭建

工程數據基本以結構化數據為主，TDengine 采用的是關系存儲模型[7]，由于其獨有的單采集點對應單表設計和超級表概念，首先根據工程數據模型建立超級表engine_data 來代表工程數據采集點的集合、時間和數據值作為數據列，信號名稱等靜態信息作為標簽，結構如表1所示。

表1 超級表engine_data 存儲模型字段Tab.1 Storage model field of super table engine_data

其次EAST 裝置相同表結構的工程數據多達幾千路，如果每次手動創建新表十分繁瑣，系統根據超級表結構自動建表，提高構建效率。通過針對不同子系統數據編寫不同流處理作業，根據不同的存儲結構如MySQL，MongoDB 等自定義數據源Source，將讀取的數據流經過Transformation 轉換輸出到數據接收器Sink 中，利用JDBC 接口將數據從源子系統清洗計算到數據庫中，根據超級表結構自動創建新表，將信號名作為子表名，具體語法為

insert into ＜子表名＞using ＜超級表名＞tags（＜tag1

value＞，…）values（value1，…）（value2，…）…；

2.3 數據庫性能

本文對工程數據庫性能進行分析，通過對比TDengine，MySQL 分區有索引和MySQL 不分區無索引三者存取性能進行對比，因查詢場景主要以1～2個月時間為主，所以數據測試范圍取最近2 個月進行對比分析。TDengine 版本為2.0，測試場景為官方提供的docker 環境，MySQL 版本為8.0.22，在Windows Server2012 環境下進行測試。針對常用的查詢場景MySQL 基于工程信號名稱和信號采集時間建立索引，并以周為跨度時間分區，性能對比如表2所示。

表2 三種環境下性能對比Tab.2 Performance comparison in three environments

由性能對比可知，TDengine 通過列式存儲特性和靜態信息以鍵值對形式存儲的方式，將工程數據的存儲占用壓縮到MySQL 的近二十分之一，并通過連續存放相同采集點數據、列存儲等特性優化了查詢性能，與建立索引和設置分區后的MySQL 性能相近，甚至在時間跨度更大的情況下性能更好。

2.4 監控可視化實現

系統基于搭建的數據庫使用Grafana 實現監控可視化，通過折線圖、餅狀圖等可視化模塊[8]完成數據庫中實驗數據和計算數據的顯示，以實際實驗場景為背景搭建不同的監控界面，比如關鍵信號進出口溫度實時監控如圖5所示，實時刷新并通過顏色顯示根據閾值判定的危險程度，直觀顯示信號情況。并配置SMTP 協議設置發件服務器，超出閾值后通過郵件傳輸協議和告警郵件規則發送信息給監控人員，通過Webhook 配置的URL 發送報警信息，后端接收到請求后記錄到報警日志數據表中并顯示在圖表中。

圖5 關鍵進出口溫度監控模塊Fig.5 Inlet & outlet temperature monitoring module

EAST 縱場超導磁體是約束等離子體使其穩態運行的重要裝置，其中縱場電流對于裝置安全分析十分重要[9]。系統通過對比縱場電流和其他工程信號如TF_BLineO 溫度波形圖，如圖6所示，幫助實驗人員進行異源數據分析，探索工程信號關聯性。

圖6 縱場電流和其他工程信號對比監控模塊Fig.6 TF current and other engineering signal comparison monitoring module

除了以上兩個模塊，系統基于建立的工程數據庫還開發了大量實驗分析模塊，如信號波形監控、歷史降溫對比等，既滿足了日常實驗對于工程信號的監控需求又幫助實驗人員對數據進行多維度計算分析，從中摸索異源工程數據潛在的關聯性，進而幫助實驗人員挖掘聚變實驗數據價值。

3 結語

系統基于EAST 工程信號的數據特點和實際實驗監控分析場景，結合TDengine 特殊的存儲結構和Flink 流處理優勢，整合多源異構的工程信號數據，建立EAST 工程信號數據倉庫，解決了目前工程數據之間相互孤立、格式不統一的現象，高效支撐實驗對歷史數據、異源數據等多維度分析需求。經過驗證通過列存儲、單信號單表、超級表等數據存儲優化措施，既降低了存儲空間成本又提高了檢索效率。同時使用Grafana 提供了一套EAST 工程信號監控系統，滿足了聚變實驗中的數據監控可視化和告警推送需求，并通過豐富的可視化模塊挖掘工程信號之間潛在關聯和數據價值。目前系統已成功部署并應用在EAST 最近一輪工程實驗中，證明了系統的可行性。