CN103500173A - 一种轨道交通监测数据的查询方法 - Google Patents

Abstract

本发明公开了一种轨道交通监测数据的查询方法。本方法为：1）数据存储***实时检查新存储的监测数据文件，并将其转换为二进制形式进行存储；其中，数据存储***采用云计算平台，其包括一分布式存储***和一索引查询***；2）数据存储***对所述监测数据文件进行并行处理，对每一检测数据文件创建一索引，并将每个监测数据文件对应的索引数据***到所述索引查询***中；3）所述索引查询***根据输入的检测查询请求，查询得到监测数据文件列表，然后根据该检测数据文件列表从所述分布式存储***的监测数据文件中读取监测数据记录。本发明大大提高了索引的创建速度和查询的效率。

Description

一种轨道交通监测数据的查询方法

技术领域

本发明提供一种轨道交通监测数据的查询方法，属于云计算技术领域。

背景技术

随着我国铁路包括国有铁路、企业铁路和城市轨道交通***的大规模建设，铁路设备,特别是铁路通信信号设备的技术越来越先进,但铁路电务维修维护技术并没有伴随铁路的大规模建设而同步发展，导致铁路电务维修维护技术成为铁路领域的技术薄弱环节。铁路电务的两个市场主体：铁路电务部门（铁路总公司、铁路局、电务段、电务车间、电务工区）和铁路通信信号设备厂商，在承担着巨大上线压力的同时，又承担着日益繁重的已上线设备的运维压力，他们对于提高铁路电务维修维护技术水平和安全生产能力的信息化生产工具有着亟待满足的市场需求。

目前针对铁路通信信号设备已存在多种监测***,包括高铁信号监测的车载计算机(ATP)、铁路无线网络(GSM-R)、无线闭塞中心(RBC)、临时限速(TSRS)和既有信号监测(CSM)：联锁(CBI)、调度集中(CTC)和列控中心(TCC)以及其它基础信号监测，包括道岔、轨道电路、信号机和电源屏等，除了这些设备监测***之外，在车站、电务段、城轨集中站\车辆段以及城轨线路中心也都部署了CSM***，用来集中管理各种设备的监测数据和告警信息，并根据这些信息通知电务人员进行维修维护。

目前,铁路电务部门存在的主要问题是在电务生产过程中沿用传统的计划修和故障修的电务生产方式，维护着众多先进的通信信号设备，不可避免地照成了设备隐患的盲区、盲点，电务生产领域普遍存在着过剩修和失修现象。过剩修，带来的是人财物力的巨大浪费；而失修，则可能带来车毁人亡的行车事故。广大铁路电务人员，在沉重的心理压力和劳动强度负荷下、以人力维护着通信信号设备的正常运行，不堪重负。他们迫切需要一套能够解放电务生产力的生产工具---综合化、智能化的电务监测运维***，从而将当前以故障修、计划修为导向的传统的电务安全生产运维模式，逐步转变为以状态修为导向的信息化的电务安全生产运维模式，从而实现查隐患、治隐患，将设备隐患消除在萌芽状态、实现保障行车安全的电务安全生产目标。

铁路通信信号设备厂商目前存在的主要问题在于，监测信息的相对分散和孤立，使得监测信息的利用非常不方便，利用率不高。部分监测***产生的监测信息之间彼此是相对独立的信息孤岛，还没有完全实现集中监测；现有的轨道交通监测数据的管理方法是将所用的数据都采用关系数据库，如Oracle数据库，进行存储和管理。为了应对海量的数据，通常采用由多个数据库服务器所组成的集群，如Oracle RAC。在关系数据库中，数据是高度独立的，随着监测和存储数据量的逐渐增加，关系数据库集群的数据存储和管理方式具有以下的不足：

对于海量数据库进行存储当前最主要的方法是使用3级存储器进行存储和并行存储和查询技术。但是这些方法对于数据的存储最大的不足之处在于对于硬件的开销比较大，而且需要开发专门的数据库***对其进行管理，而且他们最本质的思路就是以扩充硬件设备来获取大的存储空间，加大存储容量的同时大大增加的查询的处理时间。

并行数据库技术虽然利用多个处理机获取的高速的处理速度，但代价是增加硬件开销，而且处理的增长速度要低于硬件设备的处理速度。当数据量很大时，数据查询和分析等操作需要花费的时间开销很大，无法满足快速数据浏览和分析处理的需要。

发明内容

针对上述问题，本发明的目的是提供一种轨道交通监测数据的查询方法，通过云平台、云存储技术提高各种资源和轨道交通监测数据的查询效率。

为实现上述目的，本发明采用的技术方案如下：

一种轨道交通监测数据的查询方法，其步骤为：

1）数据存储***实时检查新存储的数值型监测数据文件，并将其转换为二进制形式进行存储；其中，数据存储***采用云计算平台，其包括一分布式存储***和一索引查询***；

2）数据存储***对所述监测数据文件进行并行处理，对每一检测数据文件创建一索引，并将每个监测数据文件对应的索引数据***到所述索引查询***中；

3）所述索引查询***根据输入的检测查询请求，查询得到监测数据文件列表，然后根据该检测数据文件列表从所述分布式存储***的监测数据文件中读取监测数据记录。

进一步的，所述分布式存储***为HDFS存储***，所述索引查询***为Hbase索引查询***。

进一步的，所述云计算平台设置有主节点和若干子节点；利用主节点检查分布式HDFS存储***中新存储的监测数据文件，并创建该检测数据文件的索引数据；所述云计算平台将所述监测数据文件分发给不同的子节点进行索引的并行创建。

进一步的，所述分布式存储***包括一元数据文件，所述分布式存储***提取监测数据文件的元数据，将其作为一条数据记录存储在该元数据文件中。

进一步的，所述元数据包括文件名、监测数据文件中的字段在该监测数据文件中的偏移量、监测文件大小。

进一步的，所述对每一检测数据文件创建一索引的方法为：

1)子节点对所分配的每一监测数据文件索引创建任务新建一数据流，同时记录下该监测数据文件的文件名；

2）子节点根据该文件名从所述元数据文件中提取元数据，并根据该元数据记录对该监测文件数据进行解析，利用所述偏移量提取设定的索引字段将其添加到索引数据列表中；

3）子节点对索引数据列表中每一索引字段建立一索引表；所述索引表中的信息包括：索引字段、数据采集时间、监测数据记录的存储地址。

进一步的，所述索引表的行键按照字节序顺序排列。

进一步的，所述云计算平台采用Zookeeper设置主节点和子节点，并对所述云计算平台进行负载均衡。

进一步的，所述监测数据文件包括若干采集的设备状态记录；所述设备状态记录包括数据采集的时间，以及该时间下所对应的设备监测信号的若干开关量和模拟量的值。

进一步的，所述监测查询请求包括监测数据的时间范围和监测参数。

轨道交通监测数据是以设备监测信号的开关量和模拟量的形式产生和保存的。然后数据采集***将某一时刻的开关量和模拟量数据合并成一条设备状态记录，存储于各电务段的集中监测***。该设备状态记录包括了数据采集的时间，以及该时间下所对应的设备监测信号的若干开关量和模拟量的值。综合运维平台对各电务段的监测数据进行收集并集中存储于数据存储***。本发明中的数据存储***采用云计算平台，利用众多X86架构计算机，建立具有良好可靠性和可扩展性的分布式云计算平台，能够对高达PB级的监测数据进行实时监测处理，提供监测数据的实时查询分析等多种业务支持，图1所示是设备数据监测***中监测数据采集和查询***的框架。

如图1所示，监测数据源源不断地从设备信号采集***采集出来，然后这些原始数据将经过合成***处理，以生成监测数据记录。合成的监测数据记录是以接近于文本数据的形式表示的，每个记录中包含数十个数据字段，如轨道电路电压、轨道电路相位角等信息。监测数据通常以一个固定的时间（如一分钟）为单位保持在数据采集***的数据库中。因此，每分钟都会有监测数据产生，而根据设备采集频率的不同，每天的监测数据库中可包含很多的监测数据记录。集中存储这些数据的存储***更需要维护多个电务段中存储的监测数据。

为了能对这些监测数据记录进行查询，需要将其转换为二进制形式。采用二进制存储的优点是可以节省存储空间，而且可以以固定字节长度来存储数据。由于二进制形式的记录之间偏移量是固定值，因此便于创建索引和进行相关的查询。表1是原始记录结构化存储的一种具体形式，将其转换为二进制形式。对于这些结构化数据的存储和管理，本发明的解决方案是：将监测数据以每天为单位合成一个数据文件，存储在HDFS***中，同时为了提供快速查询处理能力，将针对监测数据记录建立查询索引，并将这些查询索引存放在HBase中。

表1为原始记录结构化存储的具体形式

编号	设备名称	功出电压（伏）	功出电流（毫安）	载频（赫兹）	低频（赫兹）
						1	3DG	114.40	358.00	2298.70	27.80
2	7DG	114.40	415.00	2598.70	27.90
						3	9DG	78.60	173.00	1701.40	26.70
4	13DG	76.20	202.00	2001.40	27.90
						5	17DG	111.50	355.00	2298.70	27.80

为此，对来自采集和合成***，每分钟源源不断产生的监测数据文件，需要实时地检查这些数据文件，并及时进行索引创建处理。索引数据包括监测数据的采集时间、监测参数以及对应的存储地址。

由于监测数据量巨大，需要使用多台服务器进行并行处理，这样就需要一个管理者来扫描检查新生成的监测数据文件，并将不同的监测数据文件的索引创建任务分配给不同节点去处理。因此，需要考虑在计算集群上进行并行化任务调度和负载均衡处理，来完成以上的查询索引处理任务。

在具体的设计上，整体方案可以分为两大部分。

第一部分是监测数据文件的读取和基于HBase的查询索引创建。此过程中，需要设置一个主节点用于检测HDFS中新的监测数据文件，然后，该主节点将把检测到的监测数据文件分发给不同的子节点完成查询索引创建，并将每条监测记录对应的索引数据***到HBase中。为了防止主节点单节点失效、并处理好负载均衡，使用Zookeeper来管理整个计算集群。

第二部分是基于HBase的查询索引，接收并处理用户的监测查询请求（查询请求包括监测数据的时间范围和监测参数），到HBase中完成具体的查询处理，在获得结果监测数据记录查询列表后，再到存储在HDFS的监测数据文件中读出详细的监测数据记录，并逐一返回给客户端。

与现有技术相比，本发明的积极效果为：

（1）采用文件数据库***来存储大规模数据，解决了关系数据库集群维护和扩展的代价。

（2）将结构型数据按二进制的形式进行存储，减小了占用存储的空间。

（3）采用并行方法建立数据索引，提高了索引的创建速度，并提高了查询的效率。

附图说明

图1轨道交通监测数据管理***结构框架图；

图2展示了以上的监测数据查询处理流程。

具体实施方式

下面通过具体实施例和附图，对本发明做详细的说明。

如图1所示的轨道交通监测数据管理***的结构框架包括以下主要部分：

（1）基于HDFS的分布式文件存储

该部分的主要作用是提供监测数据的存储平台。分布式文件***位于整个***的底层，它向计算模型层、数据库层提供统一的访存接口，其它模块通过接口的调用可以很方便地在分布式文件***中存取数据。同时，该层提供的副本策略、负载均衡等机制也保证了存储平台的可用性和可靠性，为整个***提供稳定的、可依赖的存储空间。

（2）基于HBase的索引管理

该部分的主要作用是提供数据存储支持，能够向业务层和计算层提供数据持久化功能。并通过合理的主键设置和索引机制，向上层提供高效的数据访问能力。采用HBase作为数据库，能够满足***高并发、高可扩展性的需求。同时关于监测设备信息的数据存储也在HBase中。

（3）基于Zookeeper的分布式调度管理

该部分的主要作用是对整个***的服务器集群进行管理，同时提供全局配置信息管理功能。通过调用索引生成算法，对存储在分布式文件***中的数据并行地生成索引。

（4）基于MapReduce的数据分析

该部分的主要作用是采用数据分析算法对存储在分布式文件***中的数据进行分析，并输出分析结果。

（5）数据存储接口

该部分的主要作用是从数据采集***接收采集的设备状态监测数据，将数据存储到分布式文件***。

（6）数据查询接口

该部分的主要作用是从数据展现层接收数据查询请求，通过数据索引从分布式文件***中查询所需的数据，将数据返回数据展现层。

本发明的实施步骤如下：

（1）监测数据的存储

从数据采集***获得的监测数据，其存储的形式如表1中所示。为了节省存储的空间和提高查询的效率，将这些结构化的数据以一个固定格式的结构数据类型来作为存储的类型。这些结构数据类型中包括了每一项的数据类型和在结构中的偏移量，这些信息连同每一个文件中存储数据的起始时间一起保存在元数据文件中。数据存储接口将得到的每一时刻的数据追加存储到分布式文件***的对应文件的结尾。当文件大小达到限定值时，将数据存储到一个新的文件，并在元数据中生成一条新的数据记录。

（2）监测数据文件的检测与索引创建任务调度。

监测数据以文件的形式组织，现阶段的处理是直接将数据以二进制的形式存放到文件里，不包含任何的冗余数据。后续的查询将通过文件名和偏移量来获取数据。由于监测数据是每时每刻都在产生的，我们必须实时地扫描***中新的监测文件，然后将监测数据文件分配到不同的索引创建节点。为了实现***的负载均衡和单点容错，将监测文件扫描服务和索引创建服务分布在不同的节点上，这样就需要一个管理者Zookeeper来管理这些集群。

基于计算集群，用Zookeeper完成统一控制的基本设计和实现方法是，将计算集群中所有的节点都纳入Zookeeper的管理，选择其中两个计算节点注册为Zookeeper的Master服务节点（负责新的监测数据文件的扫描和索引创建任务的调度分发），Zookeeper将自动在两个服务器节点中选举一个主服务器节点。当主服务器节点出现故障时，Zookeeper将能自动将剩下的一个服务器节点提升为主服务器节点来接管失效的主服务器，以此，保证并行计算任务的分发和调度处理不会出现单点失效。

主服务器在Zookeeper中所维护的当前有效地子节点中挑选一个空闲的节点，并把一个索引创建任务分发给该节点；当多个索引创建任务到达时，主节点能有效地将计算任务分发给不同的计算节点，实现并行计算任务在整个集群节点上的负载均衡。

（3）从HDFS读取数据并创建索引。

为了创建查询索引，将需要读取存储在HDFS中的监测数据文件，并将文件中的每个监测数据记录逐行扫描，提取出需要建立索引的常用字段并导入HBase中。

该步骤包括：

1）对监测数据逐行扫描。

每当子节点接收到一个监测数据文件索引创建任务，程序就会新建一个数据流，将从HDFS中读取的监测文件数据读取内存中，同时在程序中记录下该文件的名称（设为fileName）。通过调用请求解析接口，从分布式存储***的元数据文件中提取元数据：文件名、监测数据文件中字段在监测数据文件中的偏移量、监测文件大小，将这些元数据传递给原始数据文件解析接口方法，通过原始数据文件解析接口可以对数据进行处理。

2）对常用字段建表。

根据元数据对原始检测数据文件进行解析，提取监测数据记录，对提取出来的监测数据记录进行逐行扫描，将从HDFS中读取的指定fileName文件中的监测数据记录读入内存中。监测数据记录中有些字段对查找处理不起作用，因此，仅需将与设备状态相关的电压、电流等常用索引字段提取出来，并添加到索引数据列表中。

3）建立索引表。

每条监测数据记录有十几个字段，而其中用于查询的字段只有几个，因此只需要根据这几个字段在HBase中建立几张索引表。以下以按轨道电路电压建立索引表为例。在索引表ConstructRailVoltageIndexItem中，每个索引表中的信息包括“索引字段（比如轨道电路电压）+数据采集时间+记录的存储地址（即Index）”。

（4）查询监测数据信息。

在HBase里，一张表的行键（rowkey）按照字节序顺序排列。

这里对索引表的设计如下：rowkey为：查询的字段。一个列簇：Offset：监测数据记录在监测数据文件中的位置，即文件名加偏移量。这里的列名置为空，以便减小数据量，提高***速度。

查询步骤如下：

1）对于指定查询条件，拼接成合理的查询字节序（与rowkey），通过HBase的API能够直接定位到该rowkey或者该rowkey的上一个rowkey，这样就快速定位到满足条件的监测数据索引数据。

2）读取后续的数据，读取满足条件的监测数据位置信息，依次查询索引记录，当发现rowkey不满足条件时，则查询索引完毕。

3）根据所获得的所有满足条件的监测数据位置信息集合，从HDFS上的相应监测数据文件中读取出所有的监测数据记录。

本例的开发和运行环境，主要使用了HDFS、HBase以及Zookeeper。HDFS用于存储原始监测数据，HBase用于存储查询索引，Zookeeper用于管理集群、调度索引创建任务。其中接口模块的功能如下：

（1）监测数据文件检测和索引创建任务调度程序。

主节点服务器负责监测数据文件检测和索引创建任务调度，其主要处理功能为：

1）检测是否产生新的监测数据文件；

2）将新监测数据文件的文件名整合成索引创建请求，分发给子节点处理；

3）如果子节点失效，则将子节点上的索引创建请求转移到其他子节点上。

主节点服务程序部分的功能如下：

1）某一时刻，只有一个服务程序提供服务。

2）解决单点故障。

通过Zookeeper解决了主节点的单点故障问题：如果正在扫描的主服务器节点失效了，则其他备用主节点接替它的工作，继续扫描新文件；如果某一主节点失效了，则/APP/Server/TMP下面的文件目标将变化，正在监视该目录的各个备用主节点将收到一个事件请求，然后重新选取新的主节点；没有被选上的备用主节点继续等待新的事件的到来。

子节点部分监测处理请求的功能如下：

1）基于Zookeeper检测请求是否到来。

2）检测本次请求是否为合理的请求。

（2）读取监测数据和索引创建处理。

正对接受的索引创建任务请求，子节点读取HDFS的监测数据，具体功能如下：

1）读取HDFS文件。

2）处理HDFS文件里的数据并***HBase索引表中。

对监测数据扫描并创建索引的功能如下：

生成索引数据，并***HBase里。

说明：索引表的每行包含如下数据：

1）rowkey：格式为rail_voltage（8个字节）+sample_time_s（4个字节）+index（4个字节）。

2）列簇：Offset，列簇里包含一列（该列未命名）。格式为：文件名ID（8个字节）+数据在文件里的偏移量（8个字节）。

（3）监测数据查询。

监测数据查询的主要功能如下：

查询HBase里的索引表。

说明：

（1）通过行键值生成接口将监测数据字段（如，轨道电路电压）和时间转化为与索引表的rowKey格式相同的字节序，例如，轨道电路电压+数据采集时间。通过数据文件扫描接口找到rowkey与该字节序相同的一行，如果不存在则指向前一行。

（2）设置查询指向符合条件的行。

（3）向后遍历数据，如果数据不满足查询条件（轨道电路电压和采样时间），则查询完毕。

（4）在本例里，索引的格式是：轨道电路电压+采样时间+index。如果号码超过了，则直接退出；如果轨道电路电压符合条件，则检测时间是否符合条件。

Claims (10)

1.一种轨道交通监测数据的查询方法，其步骤为：

1）数据存储***实时检查新存储的数值型监测数据文件，并将其转换为二进制形式进行存储；其中，数据存储***采用云计算平台，其包括一分布式存储***和一索引查询***；

2）数据存储***对所述监测数据文件进行并行处理，对每一检测数据文件创建一索引，并将每个监测数据文件对应的索引数据***到所述索引查询***中；

3）所述索引查询***根据输入的检测查询请求，查询得到监测数据文件列表，然后根据该检测数据文件列表从所述分布式存储***的监测数据文件中读取监测数据记录。

2.如权利要求1所述的方法，其特征在于所述分布式存储***为HDFS存储***，所述索引查询***为Hbase索引查询***。

3.如权利要求2所述的方法，其特征在于所述云计算平台设置有主节点和若干子节点；利用主节点检查分布式HDFS存储***中新存储的监测数据文件，并创建该检测数据文件的索引数据；所述云计算平台将所述监测数据文件分发给不同的子节点进行索引的并行创建。

4.如权利要求1或3所述的方法，其特征在于所述分布式存储***包括一元数据文件，所述分布式存储***提取监测数据文件的元数据，将其作为一条数据记录存储在该元数据文件中。

5.如权利要求4所述的方法，其特征在于所述元数据包括文件名、监测数据文件中的字段在该监测数据文件中的偏移量、监测文件大小。

6.如权利要求5所述的方法，其特征在于所述对每一检测数据文件创建一索引的方法为：

1)子节点对所分配的每一监测数据文件索引创建任务新建一数据流，同时记录下该监测数据文件的文件名；

2）子节点根据该文件名从所述元数据文件中提取元数据，并根据该元数据记录对该监测文件数据进行解析，利用所述偏移量提取设定的索引字段将其添加到索引数据列表中；

3）子节点对索引数据列表中每一索引字段建立一索引表；所述索引表中的信息包括：索引字段、数据采集时间、监测数据记录的存储地址。

7.如权利要求6所述的方法，其特征在于所述索引表的行键按照字节序顺序排列。

8.如权利要求3所述的方法，其特征在于所述云计算平台采用Zookeeper设置主节点和子节点，并对所述云计算平台进行负载均衡。

9.如权利要求1或2或3所述的方法，其特征在于所述监测数据文件包括若干采集的设备状态记录；所述设备状态记录包括数据采集的时间，以及该时间下所对应的设备监测信号的若干开关量和模拟量的值。

10.如权利要求1或2或3所述的方法，其特征在于所述监测查询请求包括监测数据的时间范围和监测参数。

Images