基于大数据技术的铁路工务检测数据平台方案研究

(整期优先)网络出版时间:2023-10-18
/ 2

基于大数据技术的铁路工务检测数据平台方案研究

于慧

中国铁路呼和浩特局集团有限公司呼和浩特工务段 内蒙古自治区呼和浩特市  010000

摘要:近年来我国铁路建设发展迅速,运营里程逐年攀升,由此带来的经济和战略意义不言而喻,但同时也加剧了工务部门的负担,使检修作业量急剧增加。在这种现状下,工务部门对提高作业效率、优化作业模式和信息化建设都提出了更高的要求。我国铁路系统正在进入大数据的时代,每天多个业务系统将产生海量数据,且数据量逐年增加。近年来,中国铁路郑州局集团公司普速铁路故障点检测手段多样,包括晃车仪、轨检小车、人工添乘等。工务各种监测数据体量庞大,数据类型复杂,业务查询频繁,对后续海量数据的深度挖掘带来了一定困难。因此,急需建立工务数据平台,优化工务各种检测监测数据的存储、分析、共享流程。

关键词:铁路;工务;检测数据  

铁路工务部门通过各种检测设备来获得工务设备的状态信息,对设备进行多角度的动态检测和静态检测。这些检测方式虽然产生了大量的检测数据,但其信息载体陈旧、数据分散、数据集成度差,致使反映设备隐患的检测数据被忽视或丢掉,造成了检测数据的极大浪费。面对工务检测数据的数据量大、数据接人复杂、数据查询分析复杂等问题,常用的数据流程设计方案通常以软件代码开发的形式接人数据,采用关系型数据库实现对多种数据的存储和查询。但这种方案在应对超过千万级数据量时,往往会出现查询效率低下、存储成本高等问题。基于Hadoop大数据集群和多种数据同步工具,设计并实现了工务大数据平台,打通数据同步与清洗、数据存储与查询、数据共享等数据处理流程,优化了数据处理手段,降低了数据存储成本,提高了数据查询效率。

一、工务检测数据内容

1、数据分类。工务设备检测是利用一定工具和仪器对工务设备状态参数进行量测的活动,此过程产生的数据即为工务设备检测数据,包括线路检测数据和桥隧建筑物检测数据2大类。其中,线路检测数据又分为静态检测数据、动态检测数据、钢轨检查和春秋检数据。静态检测是利用手工检测工具沿线路逐点进行或用静态仪器进行检测;动态检测则是在给轨道产生动态荷载的情况下对轨道进行的检测,为简便,钢轨检查中的小型探伤仪检测划分为静态检测,探伤车检测划分为动态检测。桥隧建筑物检测主要分为经常检查、定期检查、水文观测、临时检查和专项检查等。

2、数据来源。目前我国工务生产实际工作中,各种检测方式得到的数据大致有:①检测仪器通过本身自带的计算机分析系统得到的电子数据,通过编写特定的数据入库程序导入数据库中;②人工检测过程中的数据,手动记录至纸质文 件中。工务检查方式多以静态检测为主,因此形成的数据格式也多为纸质格式。

二、铁路工务检测数据平台设计

基于关系型数据库的数据处理,方案基于Hadoop大数据集群,采用低代码的形式和多种数据处理工具,设计实现工务数据存储、查询、共享流程,降低了数据存储成本,提高了数据查询效率。

1、数据同步与清洗。通过Datax、Sq00p等数据同步工具,由于数据内容中单位名称、线路名、里程值等存在不规范的现象,所以需要额外的数据清洗工作,规范数据内容。首先,定时从远端Oracle服务器采集监测数据。之后,根据数据的种类、同步频率和查询需求,将采集后的数据分为晃车仪数据和其他检测数据。对于轨检超限大值、便携添乘、人工添乘主表、人工添乘从表、轨检小车等数据,数据总量最大约为百万级,增量数据较小。采用现有数据同步工具Datax,将远端Oracle数据库同步到本地MySQL中,并设置定时增量数据导人任务。Datax是阿里巴巴集团内被广泛使用的离线数据同步工具/平台,可实现包括MySQL、0racle、HDFS、Hive等各种异构数据源之间高效的数据同步功能。同时可集成插件,对同步的数据进行定制化开发,完成数据清洗功能。对于晃车仪数据,总量较大,为千万级,且随时在增加。所以,数据同步分为全量同步和增量同步。全量同步,是将过去五年内所有数据一次性导人。这种操作较为耗时,且校验数据完整性复杂。增量同步是随着时间变化,将新增数据同步到本地数据服务器中。同时,需要做到实时同步,频率较高,而远端数据库中新增数据的时间和数量不固定。另外,数据内容中存在单位名称、线路名称等不规范情况,需要在接人时进行数据清洗操作。

2、数据存储与查询。对于轨检超限大值、便携添乘、人工添乘主表、人工添乘从表、轨检小车等检测数据,数据本身总量约为百万级,增量数据较小,采用MySQL存储,提供查询服务。对于晃车数据,总量为千万级,增量相对较大。传统的关系型数据库MySQL难以支持数据的存储,后期维护也越来越复杂,急需能够存储大量数据且查询速度快的数据库。因此,适合采用分布式大数据集群存储。HBase底层应用分布式文件系统,在处理庞大表上十分有优势。由于HBase是分布式存储,为了优化存储性能和后续查询性能,防止数据倾斜问题,本文采用预分区HexStringSplit算法,根据Rowkey编码,HBase也会通过算法将其分到不同的Region,实现均匀分布,避免热点问题。HBase本身是列存储,仅能查询单个字段值,不能满足业务系统对一条数据所有字段的详细查询需求,而Phoenix可将多列数据聚合为行,同时查询出多个字段值,使用体验上和关系型数据库类似。Phoenix是一个开源的HBase SOL层,支持二级索引、事务以及多种SQL层优化。二级索引可大幅度提升数据查询速度。在创建索引时,根据业务查询需求,将常用的查询字段,包括检测时间、线编号、行别等,加入索引列中。在查询过程中即可包含所有字段,满足对详细数据的查询需求。随着Phoenix表中数据持续增加,创建新的索引往往耗费大量时间。索引的底层原理仍是通过HBase特性,建立数据表,表的kev由多个索引字段构成,value是对应数据的row—kev。因此,随着数据量的增加,索引的存储量也会增加。如果创建索引的时间超过Phoenix客户端的固定时间,将出现创建超时的问题。在后续使用中,如果需要创建其他业务相关的索引时,可以通过Phoenix的1ib库中IndexT001工具,执行Mapreduce任务,创建异步索引。另外,在使用Phoenix提高查询效率时,需要注意时间类型的时区问题。Phoenix的数据类型默认时区是uTc,而日常多用GMT+8时区。在具体使用时,需要进行时区的转换操作。为了进一步提升查询性能,根据HBase运行原理,进行修改HBase部分配置。对于HBase的Master,最大内存设置为当前机器内存的60%左右,最小设置为2G即可满足运行需求。对于HBase的Region.server,内存设置为服务器内存的50%~70%。对于HBase的HFile,设置hfile.b10ck.cache.size为0.5甚至0.6。同时差参考hbase.regionsenrer.global.memstore.up.perlimit,如果两值加起来超过80%~90%,会有内存溢出的风险。

3、数据共享。对于轨检超限大值、便携添乘、人工添乘主表、人工添乘从表、轨检小车等检测数据,数据存储在MySQL中,直接通过MySQL查询,使用JDBC连接共享至下游工务车载数据分析业务系统即可。对于晃车数据,存储于大数据集群中,并通过HBase上层组件Phoenix优化查询。在数据共享时,虽然Phoenix提供通过JDBC连接的形式访问数据,但是,这种方式功能不够全面,多个系统之间集成交互困难,也不具备权限验证功能。因此,采用H1TrP接口形式,可以较好地解决不同系统之间的交互需求。在传输数据时,采用POST方法而不是GET方法,对传输数据内容的大小更宽容。由于查询条件不固定,如果根据不同的查询请求开发不同的接口,接口不具有灵活性,开发周期长,后续扩展性差。所以,参考常用持久层框架MyBati8,将通用查询功能总结为三种,查询所有详细信息list、查询分页信息page、和查询数据总量count,并将这三种功能开放为3个访问接口。在传递查询参数上,每个查询条件包括查询字段、查询关系、查询数值。分页属性包括页面大小和页码。因此,根据查询参数,即可组合多种查询条件,满足不同需求。

该方案统一管理多种数据接人,降低了存储压力,提高了查询效率。方案经验证和试运行,使用便捷、性能出色,具有一定的应用和参考价值。

参考文献:

[1] 刘 俊,王福田,刘仍奎.铁路工务检测数据综合信息平台的设计与实现[J].铁路计算机应用,2019,15(8):26-28.

[2] 朱 冀.基于数据仓库的统计报表系统的设计与实现[D].成都:电子科技大学,2018.

[3] 王建西,王明生.铁路数据服务平台存储架构设计与应用[D].河北:石家庄铁道学院,2019.