以下是小编为大家准备的简析基于大数据平台的动态票额智能预分系统的研究与实现论文(共含2篇），欢迎大家前来参阅。同时，但愿您也能像本文投稿人“我喜欢ta”一样，积极向本站投稿分享好文章。
简析基于大数据平台的动态票额智能预分系统的研究与实现论文
从起，铁路在全路实行旅客列车票额智能预分，采用客流预测方法生成列车席位预分方案，达到了票额管理合理化、科学化、趟车效益增加，并且自预售之日起，保证始发长途票额分配合理，兼顾沿途需求，保障中间站的旅客发送，充分提高了中间站组织客流的积极性。为各铁路局客运组织实现挖潜提效、精细化管理起到关键作用作用。随着参与预分的列车不断增多，动车组列车购票习惯的变化，现有的预分方法和实现机制也存在以下问题：
(1)铁路列车近年来调图频繁，车次急剧增加，并且预售期延长，由调图带来的停站方案、开点变更、编组调整变化较大，导致预测计算量巨大，系统负载较重。
(2)以往的票额预分为预售期外一次预测并预分，预售期内调整完全依据人工调整，不容易及时发现问题，票额调整工作被动，且临近开车期间销售情况难以掌握。
因此，有必要针对参考期内席位售出情况和预售期内余票概貌等情况进行动态监测，研究票额动态预分的方法，并对预测数据、调整依据的计算进行基础架构改造，适应海量数据变化的需要。
1铁路客票大数据平台的研究与实现
随着客运历史数据的累积，以及全国铁路客运规模的快速扩展，全国铁路客票历史数据规模越来越大，数据种类也越来越多，仅仅依靠关系型数据库进行数据的管理和操作，已经不能满足需要。因此，以客运营销数据为基础，结合由客票生产系统产生的实时数据，采用开源分布式数据库构建大数据平台，实现铁路客票大数据平台的研究具有重要意义。
1.1Hadoop分布式并行处理
Hadoop是近年来炙手可热的开源分布式并行处理框架，用户可忽略对底层并行实现的细节高效的构建出并行的分布式程序。Hadoop主要包括2个组件：(1)与GFS类似的分布式文件系统，简称HDFS;(2)并行计算模型MapReduce，由JobTracker、TaskTracker等组件组成。
Hadoop的工作原理是将数据拆成片，并将每个“分片”分配到特定的集群节点上进行分析，每个数据分片都是在独立的集群节点上进行单独处理的，因此非常适合处理大数据量、非结构化数据。Hadoop集群的另一个特点是具有较好的可扩展性，随着数据量的增加，集群的处理能力将会受到影响，可通过添加额外的集群节点有效地扩充集群以解决问题。Hadoop集群的并行处理能力可显著提高计算效率，能达到实时或准实时数据处理的时效性。此外，Hadoop所需软件为开源软件，并能够很好的`支持商用硬件从而客运很好的控制成本，此外，Hadoop集群还具有故障容错的优点，当一个数据分片发送到某个节点进行计算时，该数据在集群其他节点上会保留副本，即使一个节点发生故障，该策略也能保证该节点数据的副本数据正常处理。
1.2铁路客票大数据平台数据源
铁路客票大数据平台主要来源于历史数据和实时数据两类。历史数据包括互联网订票数据、运能数据以及售票、退票、废票和改签数据。客票系统实时数据包括实时余票数据、实时存量数据以及取票轨迹数据。其中，实时余票数据从互联网售票的余票查询集群获得，实时存量数据和取票轨迹数据从铁路局中心的客票系统获得。
客票历史数据和客票系统实时数据通过ETL服务，进入铁路总公司营销数据仓库，通过数据建模组成数据集市提供报表、查询应用等服务;同时上述数据也进入Hadoop平台的HDFS，数据提供Hbase和Hive两种访问方式。
在票额预分应用服务层中，由客流预测应用服务器从Hbase中提取预测需要的样本数据，应用MapReduce实现客流预测算法，以实现客流预测结果。
客流预测结果通过铁路总公司客票系统服务器实现往18个铁路局(公司)分发。各铁路局客票系统服务器上部署预测执行子系统，将预测结果与席位实时存量数据结合生成预分方案，对铁路局中心席位库进行预分操作。
2基于客票大数据平台的票额预分系统
各铁路局售票历史数据通过传输软件进入铁路总公司营销系统，实时售票数据通过数据同步技术进入到铁路总公司营销系统，另外，来自于互联网售票查询集群的余票相关数据也进入到营销数据库，多个渠道的数据形成所需分析的数据源，通过Hadoop平台ETL装置进入铁路总公司营销数据仓库，在客流预测子系统中进行预测并且形成预测数据进入票额预分执行子系统，票额预分执行子系统形成预分方案通过传输下发到各铁路局形成预分方案，通过票额预分执行子系统作用于席位库，对生成的初始票额进行预分。在各铁路局通过票额预分优化子系统对预分效果进行实时反馈，形成优化方案供铁路局客运决策者进行调整，实现智能调整流程。
2.1客流预测子系统
客流预测子系统是该系统的核心系统。历史数据是对未来计划预测的重要依据，有效数据量越大、越全面，得到的预测结果也会与实际更为接近。目前，文献中最常见的客流预测方法是外推法，该方法有很多成熟的模型，如指数平滑、ARIMA模型、非线性回归模型、神经网络模型等。Vlahogianni,GoliasandKarlaftis指出神经网络在短期交通预测领域是最有潜力的技术，并且一些文献也归纳了神经网络的优点，如分布自由、全局最优逼近和容错性等，还有一些学者基于神经网络使用定量的方法建立了铁路客运量预测模型，因此，本系统采用神经网络构造预测模型。
2.2票额预分执行子系统
票额预分执行子系统的主要功能包括预分车次定义、预分天数定义、专家参数定义、预分方案审核、预分模板交路维护、预分方案查询及修改、预分结果查询等功能。其核心概念如下：
(1)预测数据。预测数据是通过Hadoop平台的MapReduce并行预测算法计算得出的分车次数据，其存在形式为始发站—终点站(OD)客流矩阵。
(2)预分方案。预分方案是基于预测数据生成的票额分配方案，是结合实际票额情况通过票额分配算法调整而生成的实际票额OD矩阵。
(3)预分模板。预分模板是历史预分方案经过专家经验确定的内置预分方案。铁路局客票管理人员可自定义预分模板。预分模板可通过经验值人工指定，也可以通过“模板复制”功能获取一段时间内的预分数据后，参考得出模板值。预分模板分为精确模板和模糊模板，精确模板与预分方案OD区间一致，设置了每个预分站票额的可售区间，模糊模板是对车站分组并按以远站分块分配票额。
(4)预分方式。由于淡旺季客流的不同，决定了预分方案的不同。一般来说按模板预分管理更加严谨，而按预测预分更贴近客流实际情况。针对各铁路局淡旺季的不同，操作员可通过此功能对预分方式进行定义。操作员可以在此查询到本局所有车次的预分方式定义，并对相关车次的预分方式定义进行追加和删除，并查看相对应的操作日志。
(5)预分车次分组定义。对一些具有相同管理需求的车次，操作员可以将这些车次分成一组进行统一定义，同一组内的车次可一并添加到预分方式定义中。此功能避免可避免客运管理人员对同一类车的重复定义。
预分结果记录在预分结果表中，再回传至票额预分优化子系统。计划预分的数据也可以来源于铁路局客票生产库中的预分模板和模板交路，这样可以得到一个相对稳定的预分方案。
2.3票额预分优化子系统
2.3.1动态票额预分
由于客票系统预售期较长，传统的票额预分方案是基于预售期外1次预测结果生成的，预售期之内不再重新预分，因此，无法适应预售期内偶然事件的影响。从开始，票额预分系统引入了动态票额预分，可在预售期内进行周期性的动态客流预测及多次动态调整，如图6所示。以206月17日为例，这一天预测子系统将产生年7月10日始发列车的OD客流预测，同时调整2014年6月30日和2014年6月23日的始发终到预测数据(这两日初始预测数据分别在2014年6月8日和2014年6月1日生成)，在票额预分执行子系统中将预分2014年7月6日始发列车的席位，并对2014年6月29日和2014年6月22日始发列车的票额进行重新预分。
票额动态预分是基于客流按周变化的规律较为显著的特点进行的。在预售期为20天时，最多通过3次预分即可达到非常满意效果，但在预售期延长至60天的时候，由于客流变化较大，且高铁、城际列车在开车前一日和当天的预售情况变化非常显著，仅靠预售期之外的动态调整也不能很好的满足预测需求，结合余票快照分析技术实现敏捷票额调整。
2.3.2敏捷票额调整
余票快照分析模块能记录每个时刻余票历史截面的可售能力。由余票快照分析模块取得的余票情况可通过图表观察得知，图表的横坐标为观察日(观察点)，纵坐标为对应的观察点的余票快照数据。一条折线表示对应某一下车站的余票变化趋势。余票波动图用于显示在车次、日期、席别、上车站确定的情况下，到各站的可售剩余票数随时间的变化情况。在预售期内距离发车时间3天以外的取数时间间隔为1天，3天以内的时间间隔为1h。
2014年5月12日7:00始发的G101次列车各区间的余票消逝情况，默认为北京南—上海虹桥这一始发终到区间的余票，可得知该区间首次售完在2014年5月11日23:00。说明次日首列始发的京沪高铁动车始发长途票在前一日晚间23:00全部售罄，由于首班高铁旅客一般不会在开车前即买即走，而夜间高铁旅客购票相对较少，相当于既能保证始发长途票在开车前有票可买，又能保证始发长途票及时卖完。因此该结果符合预分的初衷。若开车前始发长途票既未卖完，而沿途区间在开车前一直无票可售，则说明始发长途预留过多，因调配一些到沿途站销售。
3结束语
实际应用中Hadoop集群使用了16台HPDL380的服务器，操作系统是RedHat6.4，每台服务器上安装了JDK1.6和Intel的Hadoop稳定版IDH2.3。16台服务器中，1台机器作为Master节点，剩余机器作为Slave节点。客流预测子系统开发环境采用Eclipse，开发语言使用Java;票额预分执行子系统前台应用采用PowerBuilder开发，与客票核心系统保持一致;预分优化子系统采用.net开发。
通过对京沪、京广等干线经过一段时间的试用及跟踪分析，可看出旅客发送量、客运收入都有5%以上的提升。尤其是在传统的客运淡季，其增收的效果更为明显。
在铁路运输企业改革推动下，铁路客运业务快速发展，对新一代客票系统对票额管理精细化和智能化以及提高铁路运输企业效益等方面提出了更高的要求，基于大数据平台构建了动态票额智能预分系统，形成了“预测、预分、监控、调整、再预测”的闭环流程。进一步提高了票额预分系统的可用性和有效性，为铁路实施收益管理提供理论依据和技术储备。
浅析TDCS3.0车站子系统数据平台的设计与实现论文
TDCS3.0系统是原TDCS2.0系统的优化升级版，自2013年中国铁路总公司颁布《列车调度指挥系统(3.0)技术条件》后开始实施。TDCS3.0系统中的车站子系统是整个系统的核心子系统。目前车站子系统需要维护大量的线路和车站设备基础数据，如站场信号设备、站细数据、车站出入口、站间连接关系、里程数据、电力臂、车次编订表、机车类型等。车站子系统的相关子模块(如车站值班员、信号员、电务维修机、车站处理单元TPU)均需要使用这些基础数据。由于原TDCS2.0系统在架构和软件设计时，采用的是读取配置文件的方法，各子模块需进行独立配置和维护，易造成重复性工作，且容易出错。为此，针对TDCS3.0车站子系统建立一个数据平台，采用合理的系统架构，方便运输指挥人员和系统维护人员进行数据维护和管理，避免重复性工作，提高数据的可用性、准确率。
1结构设计
数据平台由数据平台服务器、数据维护管理终端、TDCS3.0车站子系统三部分组成。
1.1数据平台服务器
数据平台服务器运行3个子进程：业务数据服务进程、资源文件服务进程、TDCS3.0程序配置数据服务进程。
1.业务数据服务进程：负责所有业务数据后台集中存储、维护和分发。数据采用文件方式存储，并采用WebService方式提供数据的查询、导入、编辑操作。业务数据包括通用数据和车站数据。
通用数据(全局数据)：列车运行类型、列车运行优先级、列车类型(车次编订表)、机车类型、车站列表、区段列表、区间列表、电力臂、列车路径、干线定义等。
车站数据(每个站不同)：车站股道、车站正线、股道分组、车站出入口、冲突限制定义、列车固定径路等。
2.资源文件服务进程：配置数据后台服务进程，并与业务数据服务进程和配置数据服务进程进行通信，采用WebService方式提供数据下载。TDCS3.0车站子系统，可与本进程连接，通过WebService接口获取本站所需的通用数据和车站数据。
3.TDCS3.0程序配置数据服务进程：配置数据的后台服务进程，负责配置数据的集中存储、维护、分发。包括：车站子系统各终端实体号列表、通信配置、车站子系统各终端的权限配置、TDCS3.0错办报警功能定制配置。
1.2数据维护管理终端
数据维护管理终端运行业务数据维护软件和配置数据维护软件2个程序。
1.业务数据维护软件：提供人机交互界面，行车运输指挥人员或系统维护人员通过人机界面前台终端进行车站业务数据的维护和管理。为减少工作量，可以对车站站细、列车类型(车次编订表)、列车固定径路等进行批量导入。通过增加不同工作区的方式对业务数据进行版本管理，确保数据的可追溯性。
2.配置数据维护软件：提供人机交互界面，系统维护人员通过人机界面前台终端进行车站配置数据的维护和管理。此软件与数据平台服务器中的“资源文件服务进程”和“TDCS3.0程序配置数据服务进程”进行通信，编制各站的通信配置、车站子系统各终端的权限配置、TDCS3.0错办报警功能定制配置，并存储在后台数据平台服务器中。
1.3TDCS3.0车站子系统
车站子系统的相关子模块通过调用“数据下载软件”与“资源文件服务进程”通信，下载本站所需的业务数据和配置数据，并以xml文件形式保存到指定目录。车站子系统应用程序启动时，将从指定的目录读取本程序需要的业务数据和配置数据。这种方式避免了手工制作的重复性，下载的文件格式统一，降低了人工修改配置文件的出错风险。
2功能实现
数据平台的功能分为三部分：数据的前台维护和管理、数据的后台存储和分发，数据的下载和使用。
2.1数据的前台维护和管理
数据的前台维护和管理主要功能如下。
1.用户登录及权限识别：对用户修改数据的权限进行管理，不同用户授予不同的权限，如系统维护人员的权限可以设置很高，可以进行系统参数设置、用户信息管理(分配用户权限)和选择工作区进行数据维护。行车运输指挥人员仅开放车站运输数据的维护，如车站站细、车站里程数据、列车固定径路等的维护。
2.工作区的设置：工作区设置很多个(如工作区1，2，3，…n)，不同工作区代表数据的一个版本，从而对数据进行版本管理。这样数据就有了可追溯性，维护人员可以很容易查询到数据的上一个版本的内容，并且可以通过“比对”的方法，来比较本次的修改内容。
3.基础数据的导入：基础数据如车站站细、车次编订表、机车类型、列车固定径路等，可以由原TDCS2.0的配置文件进行批量导入，以减少维护人员手工输入的工作量。
4.模板导入：不同的车站配置数据、通用数据和车站数据都有一定的相似性，可通过“其他车站模板导入”和“其他工作区模板导入”的方式进行复制，再根据本站特性进行加工，减少了维护人员手工输入的工作量。
5.数据导出备份：在数据维护完成后，可人工将数据以文件的方式导出备份，备份到人工指定位置的文件夹进行备份管理。
6.保存到数据平台：数据在人工导出备份的同时，也保存到数据平台的后台服务器，避免数据丢失。
2.2数据的后台存储和分发
通过“数据平台服务器”进行数据的后台存储和分发，主要有如下功能。
1.数据的存储：通过WebService方式，接受前台维护软件的合法连接，并响应前台软件的指令，进行数据的增加、修改、删除等操作，进行数据的合理性检查，并及时存储在本地服务器硬盘上。
2.数据的分发：通过Web-Service方式，接受“数据下载软件”的合法连接，并响应“数据下载软件”的下载配置请求，对请求合法性进行检查，并分发对应车站的配置数据至“数据下载软件”。
2.3数据的下载和使用
数据的下载和使用分为主动下载和后台推送2种模式。
2.3.1主动下载模式
通过远程调用和响应的方式完成数据的主动下载，其中远程调用方是“数据下载软件”，远程响应方是数据平台服务器中的“资源文件服务进程”。
由“数据下载软件”发出车站数据的下载请求，“资源文件服务进程”将收到的下载请求进行一系列的核对、匹配和合法性验证工作，确保分发的配置数据是之前请求的数据。分发的数据有车站的相关配置文件、文件的版本号及文件的数量。“数据下载软件”在收到分发过来的数据后，进行一系列的检查验证工作，如配置文件是否与本站号一致、配置文件个数和发送过来的数量是否一致，配置文件内置的版本号与发送过来的版本号是否一致等，然后将检查验证的'结果反馈给“资源文件服务进程”。“资源文件服务进程”收到检查验证结果后，进行检查判断，如果发现对方接收成功则发送一个“成功”的回执信息，如果发现对方接收数据失败则重新整理一份该站所需数据再次发送，分发数据流程结束。如果第二次分发的数据，“数据下载软件”检查仍然有误，直接将错误信息反馈给前台的TDCS3.0车站子系统应用软件，由系统维护人员人工干预处理。
2.3.2后台推送模式
后台推送模式，通过数据后台推送完成TDCS3.0车站子系统应用软件配置数据的更新，其中数据推送方是数据平台服务器中的“资源文件服务进程”，数据接收方是TDCS3.0车站子系统应用软件。
由“资源文件服务进程”定时或实时发送指定版本号的配置文件的更新;“应用软件”在收到更新指令后，进行一系列的核对、匹配和合法性验证工作，确保分发的配置数据是本站的合法数据;若配置数据合法，则“应用软件”及时更新软件内存中的数据，并同时替换软件本地的配置文件。及时更新内存中数据，是在不需要申请“铁路维修天窗点”的情况下完成。替换软件本地配置文件，确保“应用软件”下次重启后读取的是最新的配置文件。
“资源文件服务进程”最多进行二次分发，若第二次分发后“应用程序”仍检查出有误，直接将错误信息反馈给前台的“应用软件”，由系统维护人员人工干预处理。
3软件应用
截止2016年2月底，济南铁路局完成了兖州、白家店等6个站的TDCS2.0向TDCS3.0软件的升级改造工作，西安铁路局完成了宝成、宝中、陇海线19个站的TDCS2.0向TDCS3.0软件的升级改造工作，目前系统运行稳定。
综上所述，使用数据平台对TDCS3.0车站子系统的配置数据进行统一维护和管理，避免了配置制作等大量重复工作，提高了系统维护人员的工作效率，降低了配置文件出错的概率，方便了配置数据的版本维护和管理，提升了TDCS3.0车站子系统数据配置制作的自动化、智能化水平，对于保证系统的持续稳定运行具有现实意义。
