容长生,刘波
(1. 中国铁路总公司 运输局,北京 100844;2. 株洲中车时代电气股份有限公司,湖南 株洲 412001)
中国机车远程监测与诊断系统(CMD系统)后台数据处理技术
容长生1,刘波2
(1. 中国铁路总公司 运输局,北京 100844;2. 株洲中车时代电气股份有限公司,湖南 株洲 412001)
中国机车远程监测与诊断系统(CMD系统)后台处理系统接收机车数据,通过转储与解析程序将处理后的数据存储至数据库服务器,并对数据和故障进行分析,是CMD系统不可或缺的部分,为整个系统提供强有力的数据支撑。结合CMD系统,从实践使用角度出发,对其后台数据处理技术的应用进行探讨。
机车;远程监测;诊断;CMD系统;数据解析;MQ消息队列技术;Oracle数据库存储技术;Mongo数据库分片集群技术
随着计算机与网络通信技术的快速发展及全球定位系统定位准确性的提高,使得铁路交通运输领域的监控、定位、展示逐步走向电子化、数字化和可视化。为适应我国铁路机务管理实际业务需要,中国铁路总公司(简称总公司)于2015年立项开展机车车辆安全运用技术研究——机车远程监测与诊断信息地面综合应用研究。
机车数据通过铁路统一传输平台进入铁路内网,经过解析处理后存入地面综合应用子系统的数据库服务器中。在中国机车远程监测与诊断系统(CMD系统)运行过程中,后台数据解析与存储是整个系统的核心环节,设计人员通过对数据解析与存储处理技术进行优化,解决了数据实时性、系统稳定性及安全存储方面的问题[1-2]。
1.1 MQ消息队列技术
MQ消息队列技术是应用程序之间交换信息的一种技术,消息队列可驻留在内存或磁盘上,队列存储消息直到它们被应用程序读走。通过消息队列,应用程序可独立执行,在继续执行前也不需等待接收程序接收此消息。此技术具有可靠传输、不重复传输、异步传输、消息驱动与支持事务等优点。
1.2 Oracle海量存储技术
Oracle数据库系统是目前最流行的关系数据库管理系统之一,拥有可移植性好、功能强等优点,是一种可靠性好、数据安全性强且适应高吞吐量的数据库。其存储技术分2种:合的技术与分的技术,合的技术将各分层存储的数据整合在一起,分的技术则是将数据分布式存储。在存储与优化方面,Oracle涉及到的技术有分布式技术、Cache技术、数据库范式设计、数据库SQL并行执行技术等;此外,数据解析入库时,Oracle还支持批量更新、多表插入技术等。
1.3 Mongo数据库分片集群技术
Mongo数据库是基于NoSQL技术实现,为分布式文件存储的数据库,主要是解决海量数据的访问效率问题,为Web应用提供可扩展的高性能数据库存储解决方案。
现行Mongo数据库存储主要是通过分片集群技术实现,此技术分片包括3个组成部分:Mongod集合数据容器、Mongos路由器进程和配置服务器。
(1)Mongod集合数据容器:将数据库中的数据进行拆分保存在不同机器上,即分片,包括手动分片和自动分片;Mongo数据库则支持自动分片。
(2)Mongos路由器进程:Mongos管理所有数据的存放位置,应用连接Mongos发送请求;Mongos对应用隐藏分片细节,将请求转发到相应数据库服务器。
(3)配置服务器:即片键,其存储集群配置信息,是作为数据拆分的依据;Mongo数据库依据片键将数据拆分,在机器数量添加和删除时,数据库会重新平衡数据,使其流量自动趋于均衡。
2.1 后台处理系统
2.1.1 数据分类与传输方式
在CMD系统中,传输的数据按照时效性可分为:(1)实时数据,即指机车运行过程中实时发送到地面的数据,主要包括地面系统点播的数据和实时运行及故障信息;(2)非实时数据,即故障记录文件和事件记录文件等大容量数据,这些信息在机车入库时转储到地面服务器。实时数据传输方式分为时间触发(传输频率可设置的定时传输方式)、故障触发的传输方式,以及由地面远程触发数据点播方式;非实时数据传输方式分为无线自动转储和人工手动转储。
2.1.2 后台处理系统架构设计
CMD系统后台系统包括总公司、铁路局、机务段3级数据处理中心,具体实现对机车数据的处理及存储功能。铁路的3级用户可以在铁路内网访问CMD系统地面系统,CMD系统后台系统物理架构见图1。机车作为数据源头,分别通过3G/4G/北斗通道将实时数据通过MTUP安全平台传送到部署在铁路内网的服务器;非实时数据通过无线自动转储方式将记录文件自动转储到段级机务信息平台[3-4]。
图1 CMD系统后台系统物理架构
2.2 总公司级后台系统数据处理
总公司级后台处理系统主要包括3个部分:数据接收分发、MQ队列管理和数据解析入库。处理的数据为实时数据,包括3类数据:机车状态信息、北斗数据与基本信息,如机车速度、工况、机车位置、机车号、车次、经纬度等信息;机车故障和相关环境数据;根据地面综合应用子系统的历史点播指令传输的机车数据。
后台处理实时数据时,iComServ分发程序处理数据接收与分发;MQ队列管理由IBM WebSphere MQ资源管理器软件实现;数据解析入库可分成2个程序集,包括Oracle与Mongo解析入库程序集(见图2)。
2.2.1 数据分发处理
数据分发处理由iComServ分发程序实现,处理流程见图3。
图2 总公司级后台处理架构
图3 iComServ分发程序处理流程
此程序连接MQ队列管理器,接收来自MTUP的数据包,通过复制数据转发的方式,将数据包分别存入各队列中,是Oracle与Mongo解析入库等程序的数据源中转站。程序还设置有错误处理机制与日志功能,记录处理队列的异常情况,如异常队列的故障时间与原因、机车数据的概要信息等。
2.2.2 MQ队列管理
MQ队列管理由IBM WebSphere MQ资源管理器软件实现,通过建立本地或远程队列,管理与应用程序间数据包的接收或发送(见图4)。此外,各队列通过设置最大队列深度、消息长度、优先级、各类触发器等参数来实现消息数据的独立管理。在CMD系统中,使用此MQ队列管理器软件建立了10多个队列,以供后台数据解析程序使用。
图4 MQ队列管理程序架构
2.2.3 解析入库处理
解析入库处理为系统后台处理的重点,可分成两大模块:Oracle与Mongo解析。Oracle解析入库包含按车型分类的多个实时数据解析与历史点播处理,其中实时数据解析程序分别从各自队列中读取数据,解析后写入Oracle数据库对应的表中,其处理流程见图5。
历史数据点播处理时,由地面远程触发,根据地面综合应用子系统的指令传输相应类型机车数据,再通过实时数据解析程序,将历史点播请求到的高密实时数据解析写入数据库。整个历史数据点播处理流程见图6。
Mongo解析包括实时数据与机车轨迹解析2个子程序,读取MQ管理器中对应队列的数据后,再解析入库到Mongo数据库相关的表中。以机车轨迹程序为例,程序读取TEST85Q中的实时数据,解析出车型、车号、时间、机车经纬度、司机等轨迹相关的信息,写入数据库此机车的轨迹表中,其处理流程见图7。
图5 Oracle实时数据解析流程
图6 Oracle历史数据点播处理流程
图7 Mongo实时数据处理流程
2.3 铁路局级后台系统数据处理
铁路机务管理信息系统在总公司、铁路局级利用已经部署的统一传输平台,为铁路综合IT网中各专业应用系统提供统一的传输服务。在CMD系统中,铁路局级数据处理中心主要是通过搭建的传输平台作为传输通道,保证数据的安全传输。铁路局级数据流来源与总公司级相同,数据通过MQ管理软件及相关解析程序解析后,发送给所在局的应用服务器。
以机车检修程序为例,程序解析出所需的故障数据,按协议生成对应的格式报文,发送到铁路局所属远程队列,以供铁路局中机车检修系统使用,其数据处理流程见图8。
2.4 机务段级后台系统数据处理
2.4.1 机务段系统结构设计
CMD系统机务段级后台处理主要包括WLAN无线转储、FTP服务器、分发管理、数据库软件和文件解析等功能,通过机务段级统一传输平台与其他系统接口进行数据交互,其系统物理架构见图9。
2.4.2 WLAN转储解析处理
在CMD系统中,机车入段后,通过WLAN无线转储软件实现车地非实时信息双向传输,将车载综合信息监测装置(LDP)等车载设备的记录数据、机车电子履历等大容量信息发送到无线转储服务器中,机务段用户可通过文件解析软件分析所下载的数据文件。其中WLAN转储处理软件主要功能由WLAN下载程序的客户端与服务器端实现,相比于总公司解析的实时数据,其数据更全面、数据量更大。以WLAN下载程序服务器端为例,其数据处理流程见图10。
图8 机车检修程序数据处理流程
图9 机务段系统物理架构
图10 机务段WLAN下载程序处理流程
3.1 数据存储需求
目前CMD系统中,每台设备10 s上传一包数据,则每天的数据量将会达到2亿条。在现有运行4 000余台机车的情况下,每天可产生超过50G的数据。这些数据需要通过解析存储后才能呈现,数据库负载压力将会非常大。面对如此大量的数据及逐渐增多的业务场景,系统运行速度会逐渐减慢,响应时间逐渐变长,效率变低,稳定性变差。
针对CMD系统数据存储面临的情况,设计人员对比各类数据库存储特点,将系统业务进行分解,将机车历史数据(包括实时、故障与事件等数据)存入Oracle数据库;机车实时数据存放于Mongo数据库,且只更新存放一条最新的实时数据。
3.2 数据存储技术应用
3.2.1 Oracle数据库存储及优化
在CMD系统中,机车Oracle历史数据存储面临几个问题:一是存储数据容量不断增加,如何削减每天实时数据的开支,节约成本,以保证较高的可用性;二是越来越复杂的环境使得存储的数据无法有效管理。数据库存储设计过程中,设计人员通过一系列Oracle数据库优化技术的应用,使得CMD系统能够高效稳定运行,为CMD系统进一步推广和实施奠定基础。
(1)对海量数据进行分库分区操作。在CMD系统Oracle数据库中,将数据更新频率较低的表和数据更新频率较高的表分别建库;对于数据量比较庞大的表进行分表,根据实际情况采取按天分表、按月分表,如车载设备下发的数据基本都是基于时间序列的数据,所以针对大部分实时数据信息表可使用按天分区或按月分区的策略;也可根据机车属性进行分表,如按车型分表。分库分区技术的使用不仅改善了数据库的查询性能,而且设计人员也可搜索自己关心的分区,提高检索速度;增强数据可用性,如果表的某个分区出现故障,表在其他分区的数据仍可用,且只需修复该数据分区即可;此外还可把不同分区映射到磁盘以平衡I/O,改善整个数据库系统性能。
(2)建立广泛的索引。索引是一个单独的物理数据库结构,是某个表中一列或若干列值的集合和指向表中物理标识这些值的数据列的逻辑指针清单。在CMD系统Oracle数据库存储过程中,索引设计遵循以下规则:首先,大部分索引应是WHERE子句中最频繁使用的字段,同时尽量避免在用到函数的字段上建立索引;其次,在多个表上用到复合索引技术时,索引建立在小字段上,对于大的文本字段甚至超长字段,一般不建索引;最后,在经常与其他表进行连接的表中,在连接字段上跨表建立索引。
(3)定制强大的清洗规则和出错处理机制。利用存储过程和定时任务将一段时间内重要的历史数据定时备份,并根据自身需求,定时删除一些不需要的数据,减少每个表中数据的大小,提升写入和查询效率。
(4)后台解析程序的优化,多表插入技术与建立缓存机制。在后台解析程序写入数据前,尽量将一些基础数据(如司机信息、线路、车站等)信息缓存到内存中,在后台程序中完成相应数据的抽取及整合,大量减少数据库访问次数,提高数据库运行效率。Oracle还支持多表插入技术。解析程序将数据插入到多个目标表中,或根据特殊业务转换规则,将数据插入多个可能的目标表中的一个。
(5)其他海量数据存储的处理方法。数据库在使用过程中还引进了一些其他技术。例如,选用优秀的数据库工具;建立缓存机制;加大虚拟内存;分批处理;使用临时表和中间表;优化查询SQL语句;建立视图或物化视图等[5-7]。
3.2.2 Mongo数据库存储及优化
考虑到机车实时数据在CMD系统前端展示时分成了十几个网页模块,即平均每秒2万多条数据进行读写的情况,设计人员在使用Mongo数据库进行存储时,每一页面模块对应设计一个数据表,提高系统的读写速度。
单个Mongo数据库服务器容易在CPU、内存或I/O资源上出现瓶颈,后台设计人员使用分片集群与读写分离的技术,即将数据分布到多个数据库实例上来分散访问压力。每个数据库实例即分片都是一个独立数据库,所有分片组合则是一个完整数据库。此外,为提高数据库系统的稳定性,还使用了Replica set方式实现数据库系统的故障转移、切换与灾难恢复。Mongo数据库存储设计见图11。
可见,在Mongo数据库中,有Primary和2个 Secondary共3个副本集,Secondary副本集会自动复制Primary数据集中的全部数据。Replica set方式自动选择Primary数据集为主节点,其余2个副本集为从节点。主节点上能够完成读写操作,从节点仅能用于读操作。每个副本集由3个Mongo数据库实例组成,分布在3个不同IP地址,即尾地址为84、85和86的物理机上。其中84、85上的节点主要完成写操作,86上的节点主要用于读操作。当实时解析程序连接数据库写数据时,根据配置服务器,由84与85机器上的Mongos将数据均衡到其管理的Mongod集群,即84、85上的数据库实例;而当前端查询实时数据时,则会由86机器上的Mongos将数据分配到其管理的Mongod(86)集群。
图11 Mongo数据库存储设计
Mongo数据库分片集群心跳设计见图12,3个副本集中对应节点间通过传递心跳来检测各自健康状况,其心跳信息默认每2 s传递一次。当Primary数据集主节点故障时,系统自动从2个Secondary从节点中选举出新的Primary节点,从而避免单点故障的发生,确保Mongo数据库系统的高可用性与稳定性。
图12 Mongo数据库分片集群心跳设计
综上所述,CMD系统后台数据处理技术解决了机车在实际运行过程中的数据解析与存储问题,满足实时监控机车运行状态、提高列车安全性能等要求,对铁路信息化建设具有重要意义。
但考虑到实时运行数据呈快速增长趋势,且在以后可能会有新的需求,要对如此海量数据进行大量数据挖掘分析操作,现行数据库在实时性上可能无法满足。为避免此类情况,后台处理系统未来可使用以Hadoop为核心的大数据平台技术[8]。相比于传统关系型数据库,如果将大数据技术运用到CMD系统中,如基于Spark Streaming的实时数据计算技术、基于Hbase的海量数据存储技术及基于Phoenix的数据查询引擎技术等,不仅能够解决大数据存储、检索的问题,其分布式的计算能力还可为新的数据挖掘开发提供强有力的支持。
[1] 申瑞源.构建大功率机车整备体系的研究与思考[J].中国铁路,2012(6):7-10.
[2] 张大勇.提升我国机车技术水平的路径探讨[J].中国铁路,2015(6):1-4.
[3] TJ/JW 023—2014 中国机车远程监测与诊断系统(CMD系统)总体暂行技术规范[S].
[4] TJ/JW 027—2014 中国机车远程监测与诊断系统(CMD系统)地面综合应用子系统暂行技术规范[S].[5] 王庆武,唐国平.机车远程监视与诊断系统研究与设计[J].机车电传动,2012(3):42-44.
[6] 唐国平,李国华.LAIS列车运行状态信息系统[J].机车电传动,2007(4):52-56.
[7] 龚利.铁路机车远程监控与故障诊断系统设计[J].计算机工程,2012(4):227-229.
[8] 颜昌盛,高明星,赵珅,等.基于Hadoop的铁路货运历史数据分析解决方案[J].中国铁路,2014(4):94-97.
责任编辑 高红义
Background Data Processing Technology of CMD System
RONG Zhangsheng1,LIU Bo2
(1. Transportation Bureau,CHINA RAILWAY,Beijing 100844,China;2. Zhuzhou CRRC Times Electric Co Ltd,Zhuzhou Hunan 412001,China)
The background data processing technology of CMD system receives the locomotive data and stores the processed data through dump and analytic program. Comparing the data and faults is the indispensable part for the CMD system, providing the data support for the whole system. This paper discusses the application of its background data processing technology combined with the whole system in the practical operation.
locomotive;remote monitoring;diagnosis;CMD system;data analysis;Message Queue technology;Oracle database storage technology;Mongo database partition and cluster technology
U26;TP277
A
1001-683X(2017)03-0028-07
10.19549/j.issn.1001-683x.2017.03.028
2016-12-16
容长生(1975—),男,高级工程师。
刘波(1989—),男,助理工程师。E-mail:damonlb@163.com