您好, 访客   登录/注册

基于InfluxDB的桥梁监测系统设计与实现

来源:用户上传      作者:

  摘  要: 桥梁监测系统可以有效保障服役桥梁的安全性、耐久性和完整性。长期稳定的桥梁结构监测数据是桥梁监测系统安全运行的基础。由于监测数据的高采样频率的特性,导致现有的关系型数据库无法完成实时、高频、海量数据存储的任务。该文以赣江特大桥为监测对象,针对监测传感器数据中时间标签的唯一性,采用基于时序数据的InfluxDB数据存储引擎,为监控、统计、分析、告警和管理等提供数据访问服务,并在此基础上设计实现了一套桥梁监测系统。实践表明,该时序数据存储引擎能够提供海量的存储能力,同时兼顾极高的数据访问性能,为桥梁监测提供可行的数据存储方案。
  关键词: 桥梁监测; 系统设计; 数据存储; 时序数据库; InfluxDB; 数据访问
  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  引  言
  橋梁结构监测系统的数据存储模块需要为监控、统计、分析、告警和管理等提供数据访问服务[1]。传统的数据存储方案普遍使用关系数据库(如Oracle,MySQL等),大量使用关系型数据库存储时会带来诸多问题:
  1) 需要海量存储设备。以采用频率为50 Hz的加速度传感器为例,每天有432万条数据,单索引的情况下占用存储约为4 GB,存储1年则需要约2 TB的磁盘空间。而要更准确地反映桥梁结构振动,则采样频率一般远高于50 Hz,其对磁盘空间的需求将呈指数级增长[2]。目前,普通磁盘阵列的容量很难满足上述海量数据的存储需求,需随时间不断添置磁盘阵列设备,会带来存储成本的不断提升。
  2) 数据检索效率会逐渐变慢。为保证检索效率,关系型数据库常采用分区、索引等方式增强检索效率,但随着存储容量指数级增长,其效率也会逐步下降[3]。因此,针对高密度的监测数据访问需求,要求存储系统能够提供海量的存储能力,同时兼顾极高的数据访问性能,能够在秒级甚至毫秒级获取所需要的数据断面[4]。
  针对传感器数据中时间标签的唯一性,采用时序数据库具备无可比拟的技术优势,其能存储高频变化的海量数据,同时还能实现对海量数据的快速访问。本文以赣江特大桥为监测对象,针对桥梁监测系统实时、高频和海量的存储需求,采用了先进开源的InfluxDB数据存储引擎。它是一个没有外部依赖的时间序列数据库,适用于记录度量、事件及执行分析。实践表明,相比于关系型数据库,InfluxDB时序数据库在采集存储桥梁结构数据方面具有明显的性能优势[5]。
  1  赣江特大桥监测系统总体结构
  赣州赣江特大桥位于赣江支流章江、贡江两江汇合口下游,全长2.156 km,主跨长300 m,主跨塔底以上索塔全高120.6 m,是国内首座时速350 km大跨度高速铁路斜拉桥。为了保证赣江特大桥的健康安全运行,需要监测大桥运营阶段在车辆与风载作用下主梁的振动、挠度和应变等响应,安装的较为完整的监测系统对桥梁进行实时监测和实时分析。赣江特大桥监测主要包括桥梁部分,桥梁用传感器376个,轨道用传感器76个,全桥合计有各类传感器467个。监测系统硬件拓扑图如图1所示。
  根据赣江特大桥监测系统的需求将系统分为数据存储服务与数据应用服务,如图2所示。实现桥梁传感器设备运行状态实时监测、实时分析、实时报警、桥梁构件维护、检修管理等功能。其中,数据存储服务系统由两部分组成,基于时间的传感器数据使用时序数据库InfluxDB数据库存储,按照“时标?值”的数据结构来存储。设备管理、用户管理、巡检管理等模块使用关系型数据库MySQL存储。   2  基于InfluxDB的监测数据存储系统
  2.1  InfluxDB数据存储系统
  本系统采用开源的InfluxDB为数据存储引擎,其内置HTTP API,方便存储和检索,数据可以被标记,允许非常灵活的查询。数据应用服务主要包括实时数据服务、历史数据服务、故障诊断预警服务、设备管理服务,巡检管理服务、用户管理服务。其中,实时、历史数据由InfluxDB提供数据支持,故障诊断预警服务通过Kapacitor进行分析诊断,分布式消息系统Kafka负责数据消息分发。Kapacitor为传感器数据提供实时监控服务,使用Kapacitor处理实时数据,按照桥梁监测规范监测传感器数据[6]。Kapacitor是一个开源框架,用来处理、监控和警告时间序列数据,可以重复在InfluxDB中运行查询,然后在查询结果上分析数据,将分析结果发送给InfluxDB存储。同时,为了将告警消息及时传给用户,使用分布式消息系统Kafka将告警数据传给在线用户。
  2.2  TSM存储架构
  InfluxDB的数据存储架构TSM(Timestamp Segments Merged)是在LSM(Log?Structured Merge)架构的基础上针对时序数据做了针对性的存储改进,LSM将数据保持在内存中,达到指定的大小限制后,将这些数据批量写入磁盘,读取需要合并磁盘与内存中的数据。所以写入性能大大提升,读取则需要访问较多的磁盘文件,LSM放弃了部分数据读能力,换取写入的最大化[7]。TSM为了优化LSM所存在的读取性能问题,基于时序数据的特点,优化读取写入的性能。TSM存储架构主要由Cache,Wal,TSM File,Compactor组成,其结构如图3所示。
  TSM存储结构中每一个分片(Share)都包含Cache,Wal,TSM File,Compactor四个部分。分片是为了通过时间快速定位要查询的数据,同时也可以通过分片批量删除数据。保留策略(Retention Policy,RP)中设置数据过期时间,数据过期时会批量删除指定时间分片的数据。
  Cache是存在于内存中的缓存数据,写入的数据会同时存入Cache和Wal中。Wal文件结构如图4所示。
  当Cache大小达到一定阈值时会将当前Cache进行一次快照,清空当前Cache,同时创建一个新的Wal文件,删除之前的Wal文件,将快照中的数据写入到TSM文件中。用Cache存储数据,一是为了加快数据写入,二是可以快速进行数据排序。Wal文件的作用是为了持久化数据,通过Wal文件恢复还没有写入到TSM文件中的数据到Cache中。
  Compactor组件在后台持续运行,每隔1 s会检查是否需要压缩合并数据。压缩合并数据分为两个操作:一是将Cache中大小达到阈值的数据,进行快照;二是合并当前的TSM文件,将多个小的TSM文件合并成一个,减少文件数量。
  2.3  TSM數据文件结构
  TSM文件结构如图5所示。数据是以Block为最小读取单元存储在文件中,文件数据块使用B+树索引,而且数据块和索引结构存储在同一个文件中[8]。TSM文件由Data Section以及Index Section两个部分组成,前者表示存储时序数据的Block,后者存储文件级别B+树索引Block,用于在文件中快速查询时间序列数据块。
  Data Block时序数据在内存中表示为一个哈希表,结构为<Key,List<Timestamp|Value>>,其中,Key=seriesKey+fieldKey。Map中一个Key对应一系列时序数据,在任何时候,同一个Block中只会存储同一种Key的数据,哈希表会按照Key顺序排列并执行持久化。
  Data Block结构如图6所示。
  Data Block由四部分构成:Type,Length,Timestamps以及Values。
  1) Type:seriesKey对应的时间序列的数据类型。
  2) Length:Timestamps的数量,用于读取Timestamps区域数据,解析Block。
  3) Timestamps:时间值存储在一起形成的数据集。
  4) Values:指标值存储在一起形成的数据集,同一种Key对应的指标值数据类型都是相同的。
  为了在不占用过多内存的前提下提高查询效率,TSM文件引入了索引Index Block结构,TSM文件索引和HFile文件索引基本相同[9]。TSM文件索引数据由一系列索引Block组成,每个索引Block的结构如图7所示。
  Index Block由Index Block Meta以及一系列Index Entry构成:
  1) Index Block Meta核心的字段是Key,表示索引Block内所有Index Entry索引的时序数据都是该Key对应的时序数据。
  2) Index Entry表示一个索引字段,指向对应的数据块,指向的数据块由Offset唯一确定,Offset表示该数据块在文件中的偏移量,Size表示数据块大小。Min Time和Max Time表示数据块中时序数据集合的最小时间以及最大时间,在以时间范围查找时可以根据这两个字段进行快速过滤[10]。
  2.4  InfluxDB性能对比结果与分析
  选取关系型数据库MySQL和时序数据库TimeScaleDB与InfluxDB对比时序数据的写入和读取速度,在相同数据量下对比存储空间占用。测试时写入每次插入数据量统一为5 000,使用Timestamp?Value表结构。测试环境:Ubuntu18.04 , Intel[?] CoreTM i5?4590 CPU @ 3.30 GHz,内存8 GB,硬盘50 GB SSD。实验结果如表1所示。   实验结果表明,针对时序数据来说,时序数据库在磁盘占用和数据读取方面很占优势,而且随着数据规模的扩大,查询速度没有明显的下降,拥有明显的优势。同时,InfluxDB使用的TSM数据存储引擎在使用相同的表结构且不做任何表结构层面的优化的情况下,InfluxDB的写入性能约为TimeScaleDB的2倍,InfluxDB的磁盘空间占用约为TimeScaleDB的50%。因此使用InfluxDB作为系统的数据存储工具,能够满足桥梁监测中对海量数据存储的需求,保证系统的实时稳定运行。
  3  赣江特大桥监测系统软件
  3.1  软件功能模块
  针对赣江特大桥监测的需求,利用传感器、无线通信和计算机等技术手段,开發设计出一套较为完善的实时监测平台。该监测平台能够有效地将测量点的实时数据传送给监测中心,通过智能传感器网络对环境内的突发事件进行准确的分析和判断。监测人员可以通过监控计算机主动查询监测点的实时状况,做出人为决策并发送控制指令。其软件功能结构图如图8所示。
  3.2  虚拟现实模块
  为了更好地展示各测量点的三维空间分布和监测数据之间的关系,利用虚拟现实技术,将数据变化与分析结果通过三维模型直观表达。本文采用Three.js框架实现桥梁虚拟现实开发。虚拟现实系统包括桥梁模型与场景、传感器布置位置、传感器信息、传感器实时数据、桥梁构件病害等信息。桥梁虚拟现实系统场景如图9所示。用户可通过模型直观地观察到布置在桥梁各个位置的传感器,包括风速、变形、应力、振动、索力等传感器,利用InfluxDB数据引擎可以直观地在三维空间显示传感器的实时数据。
  通过三维界面,可以将桥梁结构构件(包括桥面、桥墩、索塔、斜拉索等)与巡检病害信息相关联,用户可以通过点击桥梁结构查看桥梁对应结构的病害信息,如图10所示。
  3.3  数据监测与预警
  数据监测使用WebSocket技术实现实时显示。WebSocket是一种在单个TCP连接上进行全双工通信的协议,允许服务端主动向客户端推送数据。在高频率实时数据读取中使用Ajax轮询会造成大量的HTTP请求,浪费带宽资源。WebSocket能够更实时地进行通信,保证实时数据正常显示。实时加速度传感器数据显示如图11所示。
  数据预警使用Kapacitor与Kafka。Kapacitor是一个开源数据处理框架,可以创建警报和检测异常。使用Kapacitor监测InfluxDB,从InfluxDB数据流传输到Kapacitor后,聚合并对每个数据中心运行的每个传感器的使用情况进行分组,然后根据阈值触发警报。将警报数据写入预警表的同时,使用Kapacitor提供的Kafka接口,在检测到异常警报数据后,Kapacitor将数据发送给Kafka,服务端接收到Kafka的数据后再通过WebSocket将数据分发给在线用户,实现在线用户的实时预警。
  4  结  语
  本文根据桥梁监测中的海量数据需求,分析了时序数据库在桥梁监测系统中作为数据存储平台的可行性,并以时序数据库InfluxDB为数据存储基础,构建了一套桥梁监测系统,实现了桥梁结构数据的存储、实时数据监测、异常预警等基本功能。该在线监测系统已经投入实际运用,运行效果良好,为桥梁结构的长期稳定运行提供了有效的支撑。
  参考文献
  [1] 马宏伟,聂振华.桥梁安全监测最新研究进展与思考[J].力学与实践,2015(2):161?170.
  [2] 王卫彪.监测与监控技术在桥梁施工中的作用分析[J].交通世界,2016(1):82?83.
  [3] 俞姝颖,吴小兵,陈贵海,等.无线传感器网络在桥梁健康监测中的应用[J].软件学报,2015(6):1486?1498.
  [4] 陈纯.流式大数据实时处理技术、平台及应用[J].大数据,2017(4):1?8.
  [5] 刘金.大规模集群状态时序数据采集、存储与分析[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+树索引机制的研究及优化[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] 石磊,黄高攀,乔雄.基于内存数据库的索引算法研究[J].信息技术,2016(11):139?142.
  [11] 于承新,张国建,赵永谦,等.基于数字测量技术的桥梁监测及预警系统[J].山东大学学报(工学版),2020(1):115?122.
转载注明来源:https://www.xzbu.com/8/view-15291140.htm