基于InfluxDB的橋梁監(jiān)測系統(tǒng)設計與實現(xiàn)

韓藝坤 李富年 陳志丹

摘? 要： 橋梁監(jiān)測系統(tǒng)可以有效保障服役橋梁的安全性、耐久性和完整性。長期穩(wěn)定的橋梁結構監(jiān)測數(shù)據(jù)是橋梁監(jiān)測系統(tǒng)安全運行的基礎。由于監(jiān)測數(shù)據(jù)的高采樣頻率的特性，導致現(xiàn)有的關系型數(shù)據(jù)庫無法完成實時、高頻、海量數(shù)據(jù)存儲的任務。該文以贛江特大橋為監(jiān)測對象，針對監(jiān)測傳感器數(shù)據(jù)中時間標簽的唯一性，采用基于時序數(shù)據(jù)的InfluxDB數(shù)據(jù)存儲引擎，為監(jiān)控、統(tǒng)計、分析、告警和管理等提供數(shù)據(jù)訪問服務，并在此基礎上設計實現(xiàn)了一套橋梁監(jiān)測系統(tǒng)。實踐表明，該時序數(shù)據(jù)存儲引擎能夠提供海量的存儲能力，同時兼顧極高的數(shù)據(jù)訪問性能，為橋梁監(jiān)測提供可行的數(shù)據(jù)存儲方案。

關鍵詞： 橋梁監(jiān)測; 系統(tǒng)設計; 數(shù)據(jù)存儲; 時序數(shù)據(jù)庫; InfluxDB; 數(shù)據(jù)訪問

Abstract： The bridge′s monitoring system can effectively guarantee the safety， durability and integrity of the existing bridges. The long?term stable monitoring data of bridge structure is the basis of safe operation of the bridge monitoring system. Due to the high sampling frequency of monitoring data， the existing relational database cannot complete the task of real?time， high?frequency and mass data storage. The Ganjiang Bridge is taken as the monitoring object in this paper. In allusion to the uniqueness of time label in the monitoring sensor data， InfluxDB data storage engine based on time series data is used to provide data access services for monitoring， statistics， analysis， alarm and management. On this basis， a set of bridge monitoring system is designed and implemented. The experiments show that the time?series data storage engine can provide massive storage capacity， meanwhile can take into account extremely high data access performance， which provides a feasible data storage solution for the bridge monitoring.

Keywords： bridge monitoring; system design; data storage; time series database; InfluxDB; data access

0? 引? 言

橋梁結構監(jiān)測系統(tǒng)的數(shù)據(jù)存儲模塊需要為監(jiān)控、統(tǒng)計、分析、告警和管理等提供數(shù)據(jù)訪問服務[1]。傳統(tǒng)的數(shù)據(jù)存儲方案普遍使用關系數(shù)據(jù)庫（如Oracle，MySQL等），大量使用關系型數(shù)據(jù)庫存儲時會帶來諸多問題：

1） 需要海量存儲設備。以采用頻率為50 Hz的加速度傳感器為例，每天有432萬條數(shù)據(jù)，單索引的情況下占用存儲約為4 GB，存儲1年則需要約2 TB的磁盤空間。而要更準確地反映橋梁結構振動，則采樣頻率一般遠高于50 Hz，其對磁盤空間的需求將呈指數(shù)級增長[2]。目前，普通磁盤陣列的容量很難滿足上述海量數(shù)據(jù)的存儲需求，需隨時間不斷添置磁盤陣列設備，會帶來存儲成本的不斷提升。

2） 數(shù)據(jù)檢索效率會逐漸變慢。為保證檢索效率，關系型數(shù)據(jù)庫常采用分區(qū)、索引等方式增強檢索效率，但隨著存儲容量指數(shù)級增長，其效率也會逐步下降[3]。因此，針對高密度的監(jiān)測數(shù)據(jù)訪問需求，要求存儲系統(tǒng)能夠提供海量的存儲能力，同時兼顧極高的數(shù)據(jù)訪問性能，能夠在秒級甚至毫秒級獲取所需要的數(shù)據(jù)斷面[4]。

針對傳感器數(shù)據(jù)中時間標簽的唯一性，采用時序數(shù)據(jù)庫具備無可比擬的技術優(yōu)勢，其能存儲高頻變化的海量數(shù)據(jù)，同時還能實現(xiàn)對海量數(shù)據(jù)的快速訪問。本文以贛江特大橋為監(jiān)測對象，針對橋梁監(jiān)測系統(tǒng)實時、高頻和海量的存儲需求，采用了先進開源的InfluxDB數(shù)據(jù)存儲引擎。它是一個沒有外部依賴的時間序列數(shù)據(jù)庫，適用于記錄度量、事件及執(zhí)行分析。實踐表明，相比于關系型數(shù)據(jù)庫，InfluxDB時序數(shù)據(jù)庫在采集存儲橋梁結構數(shù)據(jù)方面具有明顯的性能優(yōu)勢[5]。

1? 贛江特大橋監(jiān)測系統(tǒng)總體結構

贛州贛江特大橋位于贛江支流章江、貢江兩江匯合口下游，全長2.156 km，主跨長300 m，主跨塔底以上索塔全高120.6 m，是國內首座時速350 km大跨度高速鐵路斜拉橋。為了保證贛江特大橋的健康安全運行，需要監(jiān)測大橋運營階段在車輛與風載作用下主梁的振動、撓度和應變等響應，安裝的較為完整的監(jiān)測系統(tǒng)對橋梁進行實時監(jiān)測和實時分析。贛江特大橋監(jiān)測主要包括橋梁部分，橋梁用傳感器376個，軌道用傳感器76個，全橋合計有各類傳感器467個。監(jiān)測系統(tǒng)硬件拓撲圖如圖1所示。

根據(jù)贛江特大橋監(jiān)測系統(tǒng)的需求將系統(tǒng)分為數(shù)據(jù)存儲服務與數(shù)據(jù)應用服務，如圖2所示。實現(xiàn)橋梁傳感器設備運行狀態(tài)實時監(jiān)測、實時分析、實時報警、橋梁構件維護、檢修管理等功能。其中，數(shù)據(jù)存儲服務系統(tǒng)由兩部分組成，基于時間的傳感器數(shù)據(jù)使用時序數(shù)據(jù)庫InfluxDB數(shù)據(jù)庫存儲，按照“時標?值”的數(shù)據(jù)結構來存儲。設備管理、用戶管理、巡檢管理等模塊使用關系型數(shù)據(jù)庫MySQL存儲。

2? 基于InfluxDB的監(jiān)測數(shù)據(jù)存儲系統(tǒng)

2.1? InfluxDB數(shù)據(jù)存儲系統(tǒng)

本系統(tǒng)采用開源的InfluxDB為數(shù)據(jù)存儲引擎，其內置HTTP API，方便存儲和檢索，數(shù)據(jù)可以被標記，允許非常靈活的查詢。數(shù)據(jù)應用服務主要包括實時數(shù)據(jù)服務、歷史數(shù)據(jù)服務、故障診斷預警服務、設備管理服務，巡檢管理服務、用戶管理服務。其中，實時、歷史數(shù)據(jù)由InfluxDB提供數(shù)據(jù)支持，故障診斷預警服務通過Kapacitor進行分析診斷，分布式消息系統(tǒng)Kafka負責數(shù)據(jù)消息分發(fā)。Kapacitor為傳感器數(shù)據(jù)提供實時監(jiān)控服務，使用Kapacitor處理實時數(shù)據(jù)，按照橋梁監(jiān)測規(guī)范監(jiān)測傳感器數(shù)據(jù)[6]。Kapacitor是一個開源框架，用來處理、監(jiān)控和警告時間序列數(shù)據(jù)，可以重復在InfluxDB中運行查詢，然后在查詢結果上分析數(shù)據(jù)，將分析結果發(fā)送給InfluxDB存儲。同時，為了將告警消息及時傳給用戶，使用分布式消息系統(tǒng)Kafka將告警數(shù)據(jù)傳給在線用戶。

2.2? TSM存儲架構

InfluxDB的數(shù)據(jù)存儲架構TSM（Timestamp Segments Merged）是在LSM（Log?Structured Merge）架構的基礎上針對時序數(shù)據(jù)做了針對性的存儲改進，LSM將數(shù)據(jù)保持在內存中，達到指定的大小限制后，將這些數(shù)據(jù)批量寫入磁盤，讀取需要合并磁盤與內存中的數(shù)據(jù)。所以寫入性能大大提升，讀取則需要訪問較多的磁盤文件，LSM放棄了部分數(shù)據(jù)讀能力，換取寫入的最大化[7]。TSM為了優(yōu)化LSM所存在的讀取性能問題，基于時序數(shù)據(jù)的特點，優(yōu)化讀取寫入的性能。TSM存儲架構主要由Cache，Wal，TSM File，Compactor組成，其結構如圖3所示。

TSM存儲結構中每一個分片（Share）都包含Cache，Wal，TSM File，Compactor四個部分。分片是為了通過時間快速定位要查詢的數(shù)據(jù)，同時也可以通過分片批量刪除數(shù)據(jù)。保留策略（Retention Policy，RP）中設置數(shù)據(jù)過期時間，數(shù)據(jù)過期時會批量刪除指定時間分片的數(shù)據(jù)。

Cache是存在于內存中的緩存數(shù)據(jù)，寫入的數(shù)據(jù)會同時存入Cache和Wal中。Wal文件結構如圖4所示。

當Cache大小達到一定閾值時會將當前Cache進行一次快照，清空當前Cache，同時創(chuàng)建一個新的Wal文件，刪除之前的Wal文件，將快照中的數(shù)據(jù)寫入到TSM文件中。用Cache存儲數(shù)據(jù)，一是為了加快數(shù)據(jù)寫入，二是可以快速進行數(shù)據(jù)排序。Wal文件的作用是為了持久化數(shù)據(jù)，通過Wal文件恢復還沒有寫入到TSM文件中的數(shù)據(jù)到Cache中。

Compactor組件在后臺持續(xù)運行，每隔1 s會檢查是否需要壓縮合并數(shù)據(jù)。壓縮合并數(shù)據(jù)分為兩個操作：一是將Cache中大小達到閾值的數(shù)據(jù)，進行快照;二是合并當前的TSM文件，將多個小的TSM文件合并成一個，減少文件數(shù)量。

2.3? TSM數(shù)據(jù)文件結構

TSM文件結構如圖5所示。數(shù)據(jù)是以Block為最小讀取單元存儲在文件中，文件數(shù)據(jù)塊使用B+樹索引，而且數(shù)據(jù)塊和索引結構存儲在同一個文件中[8]。TSM文件由Data Section以及Index Section兩個部分組成，前者表示存儲時序數(shù)據(jù)的Block，后者存儲文件級別B+樹索引Block，用于在文件中快速查詢時間序列數(shù)據(jù)塊。

Data Block時序數(shù)據(jù)在內存中表示為一個哈希表，結構為>，其中，Key=seriesKey+fieldKey。Map中一個Key對應一系列時序數(shù)據(jù)，在任何時候，同一個Block中只會存儲同一種Key的數(shù)據(jù)，哈希表會按照Key順序排列并執(zhí)行持久化。

Data Block結構如圖6所示。

Data Block由四部分構成：Type，Length，Timestamps以及Values。

1） Type：seriesKey對應的時間序列的數(shù)據(jù)類型。

2） Length：Timestamps的數(shù)量，用于讀取Timestamps區(qū)域數(shù)據(jù)，解析Block。

3） Timestamps：時間值存儲在一起形成的數(shù)據(jù)集。

4） Values：指標值存儲在一起形成的數(shù)據(jù)集，同一種Key對應的指標值數(shù)據(jù)類型都是相同的。

為了在不占用過多內存的前提下提高查詢效率，TSM文件引入了索引Index Block結構，TSM文件索引和HFile文件索引基本相同[9]。TSM文件索引數(shù)據(jù)由一系列索引Block組成，每個索引Block的結構如圖7所示。

Index Block由Index Block Meta以及一系列Index Entry構成：

1） Index Block Meta核心的字段是Key，表示索引Block內所有Index Entry索引的時序數(shù)據(jù)都是該Key對應的時序數(shù)據(jù)。

2） Index Entry表示一個索引字段，指向對應的數(shù)據(jù)塊，指向的數(shù)據(jù)塊由Offset唯一確定，Offset表示該數(shù)據(jù)塊在文件中的偏移量，Size表示數(shù)據(jù)塊大小。Min Time和Max Time表示數(shù)據(jù)塊中時序數(shù)據(jù)集合的最小時間以及最大時間，在以時間范圍查找時可以根據(jù)這兩個字段進行快速過濾[10]。

2.4? InfluxDB性能對比結果與分析

選取關系型數(shù)據(jù)庫MySQL和時序數(shù)據(jù)庫TimeScaleDB與InfluxDB對比時序數(shù)據(jù)的寫入和讀取速度，在相同數(shù)據(jù)量下對比存儲空間占用。測試時寫入每次插入數(shù)據(jù)量統(tǒng)一為5 000，使用Timestamp?Value表結構。測試環(huán)境：Ubuntu18.04 ， Intel[?] CoreTM i5?4590 CPU @ 3.30 GHz，內存8 GB，硬盤50 GB SSD。實驗結果如表1所示。

實驗結果表明，針對時序數(shù)據(jù)來說，時序數(shù)據(jù)庫在磁盤占用和數(shù)據(jù)讀取方面很占優(yōu)勢，而且隨著數(shù)據(jù)規(guī)模的擴大，查詢速度沒有明顯的下降，擁有明顯的優(yōu)勢。同時，InfluxDB使用的TSM數(shù)據(jù)存儲引擎在使用相同的表結構且不做任何表結構層面的優(yōu)化的情況下，InfluxDB的寫入性能約為TimeScaleDB的2倍，InfluxDB的磁盤空間占用約為TimeScaleDB的50%。因此使用InfluxDB作為系統(tǒng)的數(shù)據(jù)存儲工具，能夠滿足橋梁監(jiān)測中對海量數(shù)據(jù)存儲的需求，保證系統(tǒng)的實時穩(wěn)定運行。

3? 贛江特大橋監(jiān)測系統(tǒng)軟件

3.1? 軟件功能模塊

針對贛江特大橋監(jiān)測的需求，利用傳感器、無線通信和計算機等技術手段，開發(fā)設計出一套較為完善的實時監(jiān)測平臺。該監(jiān)測平臺能夠有效地將測量點的實時數(shù)據(jù)傳送給監(jiān)測中心，通過智能傳感器網(wǎng)絡對環(huán)境內的突發(fā)事件進行準確的分析和判斷。監(jiān)測人員可以通過監(jiān)控計算機主動查詢監(jiān)測點的實時狀況，做出人為決策并發(fā)送控制指令。其軟件功能結構圖如圖8所示。

3.2? 虛擬現(xiàn)實模塊

為了更好地展示各測量點的三維空間分布和監(jiān)測數(shù)據(jù)之間的關系，利用虛擬現(xiàn)實技術，將數(shù)據(jù)變化與分析結果通過三維模型直觀表達。本文采用Three.js框架實現(xiàn)橋梁虛擬現(xiàn)實開發(fā)。虛擬現(xiàn)實系統(tǒng)包括橋梁模型與場景、傳感器布置位置、傳感器信息、傳感器實時數(shù)據(jù)、橋梁構件病害等信息。橋梁虛擬現(xiàn)實系統(tǒng)場景如圖9所示。用戶可通過模型直觀地觀察到布置在橋梁各個位置的傳感器，包括風速、變形、應力、振動、索力等傳感器，利用InfluxDB數(shù)據(jù)引擎可以直觀地在三維空間顯示傳感器的實時數(shù)據(jù)。

通過三維界面，可以將橋梁結構構件（包括橋面、橋墩、索塔、斜拉索等）與巡檢病害信息相關聯(lián)，用戶可以通過點擊橋梁結構查看橋梁對應結構的病害信息，如圖10所示。

3.3? 數(shù)據(jù)監(jiān)測與預警

數(shù)據(jù)監(jiān)測使用WebSocket技術實現(xiàn)實時顯示。WebSocket是一種在單個TCP連接上進行全雙工通信的協(xié)議，允許服務端主動向客戶端推送數(shù)據(jù)。在高頻率實時數(shù)據(jù)讀取中使用Ajax輪詢會造成大量的HTTP請求，浪費帶寬資源。WebSocket能夠更實時地進行通信，保證實時數(shù)據(jù)正常顯示。實時加速度傳感器數(shù)據(jù)顯示如圖11所示。

數(shù)據(jù)預警使用Kapacitor與Kafka。Kapacitor是一個開源數(shù)據(jù)處理框架，可以創(chuàng)建警報和檢測異常。使用Kapacitor監(jiān)測InfluxDB，從InfluxDB數(shù)據(jù)流傳輸?shù)終apacitor后，聚合并對每個數(shù)據(jù)中心運行的每個傳感器的使用情況進行分組，然后根據(jù)閾值觸發(fā)警報。將警報數(shù)據(jù)寫入預警表的同時，使用Kapacitor提供的Kafka接口，在檢測到異常警報數(shù)據(jù)后，Kapacitor將數(shù)據(jù)發(fā)送給Kafka，服務端接收到Kafka的數(shù)據(jù)后再通過WebSocket將數(shù)據(jù)分發(fā)給在線用戶，實現(xiàn)在線用戶的實時預警。

4? 結? 語

本文根據(jù)橋梁監(jiān)測中的海量數(shù)據(jù)需求，分析了時序數(shù)據(jù)庫在橋梁監(jiān)測系統(tǒng)中作為數(shù)據(jù)存儲平臺的可行性，并以時序數(shù)據(jù)庫InfluxDB為數(shù)據(jù)存儲基礎，構建了一套橋梁監(jiān)測系統(tǒng)，實現(xiàn)了橋梁結構數(shù)據(jù)的存儲、實時數(shù)據(jù)監(jiān)測、異常預警等基本功能。該在線監(jiān)測系統(tǒng)已經(jīng)投入實際運用，運行效果良好，為橋梁結構的長期穩(wěn)定運行提供了有效的支撐。

參考文獻

[1] 馬宏偉，聶振華.橋梁安全監(jiān)測最新研究進展與思考[J].力學與實踐，2015（2）：161?170.

[2] 王衛(wèi)彪.監(jiān)測與監(jiān)控技術在橋梁施工中的作用分析[J].交通世界，2016（1）：82?83.

[3] 俞姝穎，吳小兵，陳貴海，等.無線傳感器網(wǎng)絡在橋梁健康監(jiān)測中的應用[J].軟件學報，2015（6）：1486?1498.

[4] 陳純.流式大數(shù)據(jù)實時處理技術、平臺及應用[J].大數(shù)據(jù)，2017（4）：1?8.

[5] 劉金.大規(guī)模集群狀態(tài)時序數(shù)據(jù)采集、存儲與分析[D].北京：北京郵電大學，2018.

[6] MAHMOUDREZA Tahmassebpour. A new method for time?series big data effective storage [J]. IEEE access， 2017， 5： 10694?10699.

[7] ZHANG Weitao， XU Yinlong， LI Yongkun， et al. Improving write performance of LSMT?based key?value store [J]. IEEE computer society， 2016（1）： 553?560.

[8] 施恩，顧大權，馮徑，等.B+樹索引機制的研究及優(yōu)化[J].計算機應用研究，2017（6）：1766?1769.

[9] ZHOU Wei， LU Jin， LUAN Zhongzhi， et al. SNB?index： a SkipNet and B+ tree based auxiliary cloud index [J]. Cluster computing， 2014， 17（2）： 453?462.

[10] 石磊，黃高攀，喬雄.基于內存數(shù)據(jù)庫的索引算法研究[J].信息技術，2016（11）：139?142.

[11] 于承新，張國建，趙永謙，等.基于數(shù)字測量技術的橋梁監(jiān)測及預警系統(tǒng)[J].山東大學學報（工學版），2020（1）：115?122.