时序数据库IoTDB在城轨车辆智能运维系统中的应用研究

赵娜娜

摘要：随着我国城市轨道交通的高速发展，城市轨道交通车辆运维压力越来越大。传统数据库无法采集并存储日益增长的海量数据，IoTDB数据库具有优秀的数据压缩性能、高效的数据查询和写入性能，能够支撑城市轨道交通车辆日益增长的海量数据存储。本文介绍了基于IoTDB的城轨车辆智能运维系统的整体架构，该架构在保障城轨车辆车辆安全、可靠运营的基础上，有效降低了运营成本、提高了运营效率。

关键词：时序数据、IoTDB、智能运维

1.引言

随着我国城市轨道交通建设的快速发展，以人工为主的计划修模式无法支撑网络化运营带来的检修负载。智研咨询发布的《2021-2027年中国地铁行业发展现状调查及投资战略规划报告》数据显示：2020年中国地铁配属列车数量达7424列，其中北京地铁配属列车数量为1037列，全国排名第一;上海地铁配属列车数量为1023列，全国排名第二。我国目前处于经济发展转型期，地铁建设数量持续增长，发展超大规模网络给地铁公司带来了巨大的挑战，对地铁公司的运维管理来说，安全性、可靠性的要求越来越高，而轨道交通可持续发展则需要更低的运维成本，提高人车比，这就意味着设备可靠性需要更加智能健康的管理手段。

以网络化、智能化、状态修为特点的城轨车辆智能运维系统通过实时自动采集设备工况数据、运行故障数据，以及运行状态数据，利用大数据和机器学习技术，实现设备的实时监控、故障预警，以及故障预测分析等。城轨车辆智能运维系统大多以关系型数据库或时序数据库用来存储数据，虽然能够实现时序数据的历史存储，但数据查询和数据压缩方面性能较差。本文提出的IoTDB时序数据库，可以有效的提高数据查询性能，降低数据存储成本。

2.时序数据库IoTDB的特点

时间序列数据库简称时序数据库（Time Series Database），用于处理带时间标签（按照时间的顺序变化，即时间序列化）的数据，带时间标签的数据也称为时间序列数据[1]。

2.1时许数据库IoTDB的特点

Apache IoTDB是针对时间序列数据收集、存储与分析一体化的数据管理引擎。它具有体量轻、性能高、易使用的特点，完美对接Hadoop与Spark生态，适用于工业物联网应用中海量时间序列数据高速写入和复杂分析查询的需求。

IoTDB 是专门针对物联网时序数据开发的数据库，具有数据收集、存储、管理和分析的功能。IoTDB具有部署方式灵活、读写性能高、存储成本低、学习成本低、支持和Hadoop、spark、flink等开源大数据分析工具的集成等特点。

2.2 优势对比

与传统关系型数据比较，时序数据库有以下几点优势：

（1）查询性能高

时序数据库数据存储以时间戳为索引进行列式存储，城轨车辆智能运维系统最常见的查询是对一段时间的数据进行聚合查询，查询速度快。相比关系型数据库，对这种大数据量的聚合查询，性能较差。

（2）存储成本低

IoTDB采用无损压缩方式对数据进行存储，城轨车辆智能运维系统数据采集频率高，数据量大，采用时序数据库可以有效的减少数据存储空间，降低数据存储成本。

（3）数据写入性能高

时序数据库支持ms级实时数据采集和存储，城轨車辆智能运维系统数据采集频率200/500ms，时序数据库可以实现数据批量写入，写入性能高。

3.IoTDB在轨道交通智能运维系统中的应用

3.1智能运维系统车载设备数据的特点

智能运维系统中车载设备数据主要指车载通信设备通过无线通信协议将 MVB 总线数据发送至地面服务器的数据，这类数据有如下特点：

（1）数据量大

地铁车辆每列车有上万个传感器，传回地面的采集点按 4000点计算，采集频率为200ms，每个变量至少需存储的内容包括ID、时间戳和值，共占14字节。一列地铁车辆一年的存储空间为：

4000 *14（Byte） * 5 * 24（Hour） * 3600 * 365 =8830080000000（Byte）

约8.03TB。该数据是原始报文数据，解析后的数据量呈几十倍增加。根据智研咨询发布的《2021-2027年中国地铁行业发展现状调查及投资战略规划报告》数据，截止2020年底：中国地铁数据总量约为58.22PB;北京地铁数据量约为8.13PB;上海地铁数据量约为8.02PB。随着地铁线路列车的增多，数据量会持续增长。

（2）数据协议复杂

车载设备通过车载设备发出的数据经过了三层数据协议的封装：无线通信协议、车载设备私有通信协议、MVB 总线协议。其中车载设备私有通信协议与各车型 MVB 总线协议并没有统一设计标准，导致数据接受后的解析较为复杂。

（3）数据查询实时性高

列车状态数据作为故障预警、故障分析等应用的重要数据源，往往需要被即时查询且交互性要求较高，即页面响应及时性要求较高。

（4）数据展示时序性强

针对通过车载设备实时接入的列车状态数据，往往需要在前台进行实时监控， 因此应能够及时将状态数据推送至有监控需求的客户端，并保障数据到达的时序性。

3.2智能运维系统总体架构设计

智能运维系统总体架构如图3-1所示，分为数据采集层、数据处理层、数据应用层，以及平台管理层四部分。多源异构数据通过网关解析、处理后进行存储、查询、展示。

3.3数据采集层

城轨车辆智能运维系统在设计时考虑到数据源的多样性，将数据源分为：车载设备数据、流媒体数据、关系型数据库数据以及文本数据。车载设备数据采集如图3-2所示。城轨车辆车辆产生的传感器数据通过4G/5G/wifi无线方式回传到地面服务器。车载设备数据是经过加密、压缩、通信协议封装，地面服务器接收到数据后，在netty中通过报头来识别协议，将协议信息以及报文数据发送到集群的kafka中。

3.4数据处理层

数据处理流程图如图3-2所示。Netty中的数据发送到kafka后，经过Spark Streaming进行解析，解析后数据存入IoTDB中，IoTDB的核心是TsFile，TsFile可以实现云端IoTDB的数据同步，支持Hadoop、Spark等大数据分析。前文提到一列车一年的数据量约为8.03TB。经过解析后数据量是现在的几十倍，IoTDB采用了SNAPPY等无损压缩算法，在数据写入时对数据进行编码，可以有效的降低数据存储空间，减少数据读写过程中I/O操作的数据量，从而提高数据读写性能。解析后数据分为列车故障数据和列车实时状态数据，列车故障数据经过flink批处理后推送到页面进行预警，列车实时状态数据经过Spark Streaming进行流式处理。IoTDB与spark、flink等开源大数据系统无缝打通，使得数据处理更加便捷。

实时数据处理：解析后数据写入Kafka消息队列，经过Spark Streaming进行流处理。考虑到流计算需要频繁的用到主数据，在设计时采用MySQL+Redis+Web Service构建了数据访问服务，采用MySQL作为后台数据库，用来存储主数据，Redis作为缓存数据库，用来存储最新实时数据满足页面的实时交互查询和展示。

批数据处理：解析后数据写入Kafka中，经过Flink有界流处理后，将数据推送到页面展示，同时写入Kudu中。在Kudu之前采用Hbase/Parquet+HDFS方式，实时数据写入Hbase，数据的更新也在Hbase中，对于批量分析的需求，定时将Hbase数据导成Parquet再导入HDFS中，该方式架构复杂，时效性低，难以应对后续的更新。 Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的数据上进行快速的查询[2]。Kudu能充分利用CPU和I/O资源，支持数据原地修改，支持简单的、可扩展的数据模型。

3.5数据应用层

数据应用层主要有列车状态实时监测、列车故障预警、列车故障诊断，及列车数据分析等功能。列车状态实时监测包括列车数量、投运数量、在离线数量、故障列车数量、各等级故障数量、运营数据统计等。列车故障预警模块主要指在发生故障时通过声音和消息提示的方式进行预警。列车数据分析模块为运营数据（总里程，牵引能耗，再生能耗等能耗，空压机累计运行时间，空压机转率、门状态等数据聚合）的分析，载荷数据的分析，旅速数据的分析，能耗数据的分析等。IoTDB数据库具有很好的数据聚合查询性能，十亿点数十毫秒快速查询，IoTDB的数据聚合查询使得列车数据分析更加高效。

4.结束语

本文提出的基于时序数据库IoTDB，结合大数据组件Kafka，Spark Streaming，Flink，Kudu等构建的城轨车辆智能运维系统，通过车辆系统状态感知和设备泛在互联，实现采集信息数字化，在保障城轨车辆在线运行安全、提高车辆检修质量和提升运营管理整体效能等方面发挥了显著的优势，同时，有效的降低了数据存储成本，提高了数据写入和查询的性能。本文提出的基于时序数据库IoTDB的城轨车辆智能运维系统架构，为其它工业大数据系统的运维提供了很好的参考和借鉴。

参考文献

[1]叶鹏. 时间序列数据库在智能水电厂监控业务中的应用[J]. 水 电 厂 自 動 化， 2018年2月， 39（1）：58-60.

[2]曹成，陶继群，郑湃;. 基于Kudu的电力辅助设备实时监控业务解决方案[J]. 科技创新与应用 ，Technology Innovation and Application， 2021（8）：130-134.