摘    要：介绍轨道交通领域综合监控系统数据的存 储、提取及运算过程，并以北京、南京等为例分析当前 存在的效率问题，提出采用 map -reduee分布式运算以 及窗口算法，解决中心大数据量信息处理的效率问题。 介绍 map -reduee算法原理以及窗口算法，对采用传统 方式解决大数据的同步问题进行分析，提出利用简化 的 map -reduee任务分发解决轨道交通数据的处理效 率问题，最后对其应用领域进行扩展，可推广到轨道交 通领域任何的分布式应用中。
关键词 ：城市轨道交通；大数据；map -reduee；分布式 运算；窗口算法；大数据量信息处理；运维指挥系统

中图分类号  ：  U231 -文献标志码    A
文章编号 ：1672 -6073(2016)06-0008-03


1   研究背景
       轨道交通综合监控系统由众多的车站和中心构 成，并且在每座车站都存在一个独立的数据域，中心域 是车站数据域的集合。 对中心的数据处理通常从中心 域获取数据并处理，当中心的数据量达到一定程度（ 受 车站数量、车站数据量、投运时间等影响），效率问题就 会影响运营体会［1J 。 例如：南京地铁 3 号线有 29 座车 站，重庆地铁 3 号线有 39 座车站，北京地铁 6  号线有 26 座车站，正常情况下中心每天产生 100 万条数据信 息，如果运行时间为 1 年，那么查询其中一天的数据会 消耗多少时间？ 即使优化后的查询也会碰到界面数据 长时间无法被展示的困扰［2J 。
既然每座车站都拥有一份完整的数 据，那 么 如 果采用分布式运算会产生什么样的效果？ 如何实现分布 式运算？ 本文将以事件处理为例详细介绍如何采用 map    reduee分布式运算以及窗口算法，解决大数据量 信息处理的效率问题。

2    算法介绍
2.1  map  reduce原理［3]
       MapReduee是现今一个非常流行的分布式计算框 架，它被用于并行计算海量数据。 第一个提出该技术 框架的是 G00g1e公司，而 G00g1e的灵感则来自于函数 式编程语言，如 LISP、Seheme、ML等。 MapReduee框架 的 核 心 步 骤 主 要 分 两 部 分： map  和  reduee。 当 向 MapReduee框架提交一个计算作业时，它首先会把计算 作业拆分成若干个 map 任务，然后分配到不同的节点上 执行，每个 map 任务处理输入数据中的一部分，当 map 任务完成后，会生成一些中间文件，这些中间文件将会 作为 reduee任务的输入数据。 reduee任务的主要目标 就是把前面若干个 map 的输出汇总到一起并输出。 从 高层抽象来看，MapReduee的数据流图如图 1 所示。

       详细的介绍在许多资料中都有，本文将针对特定的轨道交通领域的综合监控数据存储特点，简化实现map    reduee。

2.2  窗口算法
       本文的窗口算法是指设定指定大小的信息域，在 对信息的整理过程中只对该区域内的信息进行处理， 忽略对信息域外信息的一种优选算法，如图 2 所示。
 

3    传统实现分析
       在传统实现方式中，控制中心是一个大而全的数 据集，不仅在车站本地保存 1 份数据，而且需要通过同 步服务程序将数据同步到控制中心。 当提交一个计算 作业时，它直接从本地节点上执行并输出结果［4] 。
       在该实现方式中，如何保证数据完全同步是系统 设计的难点，例如骨干网中断一段时间后恢复，需要保 证数据不丢失，同时，由于需要保存 2 份数据，增加了 系统的负担。 当控制中心提交多个并发计算作业时， 由于这些计算作业都只能在本节点上处理，延长了并 发计算时间［5] 。

4       系统设计与实现［6]
       本设计充分利用轨道交通领域数据分布式存储的 特征，从而简化 map    reduee任务分发。
       首先，轨道交通数据按域（ 车站） 均匀分布；其次，轨道交通网络结构固定；再次，轨道交通服务器对等， 且运行服务统一；最后，轨道交通数据结构统一，且每个域都有相应的标识［7] 。
       由此可以看出，本设计执行条件：1 ） 所有节点具 有等同的服务，只能处理本域的数据；2 ） 所有的结果数据均可以有序汇总为特定数量（ 窗口大小） 的有效信息。 符合以上两点的，均可以采用本设计，不限于轨道 交通领域。
       所以，本设计对 map   reduee功能做了如下精简：1） 省略了对应处置数据的打包分发过程，因为数据本 来就是按照车站分布式存储的；2） 服务的分发是固定 的，分发到对应的车站，因为请求端明确知道请求该下 发给哪座车站，从而由系统服务分发给对应的车站服务器；3） 从车站服务器返回的结果本来就是按车站进 行分类的，因此可以省略返回数据的分类过程；4 ） 由 于轨道交通数据是结构化数据， 因此可以固化数 据 reduee的过程，从而提高处置效率；5） 将非实时的 map reduee功能改进为准实时功能。
       本文所使用的窗口算法是一种简化的窗口算法， 因为从各节点获取的信息组合已经是按规律排好的有 序列表，所以相应的插人处理会变得更加简 单。 详细 运 算 流 程 如 图 3 所示。
       窗口 算 法 的 实 现 如图 4  所示。 以事 件 查询为例，本文采用的 做法是从车站而不是 中心读取数据［8] 。 首 先客户端发出带有过 滤条件的事件查询指 令，由运行在中心服务 器上的事件服务程序 将其拆解为统一的查 询过滤语句，并向对应 的车站服务器发送请 求，车站服务器根据请 求访问自己的商用数 据库，得到有序的事件 列表并发给中心服务 器，中心服务器根据车 站服务器请求返回的 顺序，采用窗口算法按 时间排序的信息将其整理为目标结果集，发送到窗口显示。
 

5    应用领域扩展
       由于本设计针对轨道交通独有的网络、数据、服务 进行设计，因此可以类推到轨道交通领域任何的分布式 应用，例如在 Tcc（运营指挥系统发包方）上面的扩展。
       由于轨道交通运营指挥系统需要调度一个城市多 条线路的信息，因此需要处置的数据将是超级庞大的， 尤其是对北京、上海、广州这样的一线城市，由于其地 铁发展历史较久，线路多，具有较大的指导意义［9] 。
       首先，避免将数据收集到统一的数据仓库这一过程，不仅能够减少硬件投入，而且可以充分利用现有线 路的数据库;其次，极大地提高了信息处理的速度，将 对现代社会高效率处置突发事件产生巨大影响。 但是 由于多条线路由不同的运营商提供，所以在上一节提 到的结构化数据可能会变成异构数据［10］ ，那么需要由 Tcc提供统一的服务接口，通过线路服务提供方将异构数据转换为结构化数据输出。

6   结语
       采用该方法的主要特点是：充分整合现有线路服 务器的资源，降低中心服务器的负荷;完全使用分布式 的数据存储，简化数据同步过程;将集中式的任务进行 分布式处理，极大提高数据的处理效率，提升车站服务 器的利用率以及中心服务器的处理效率。

收稿日期， 2016 04 05 修回日期， 2016 05 09
作者简介，张浩，男，硕士，土程师，从事轨道交通自动化研究土作，zhanghaohzxt@163.com