张 铭

(中国铁道科学研究院集团有限公司电子计算技术研究所 北京 100081)

0 引 言

近年大城市轨道交通快速进入规模化和网络化格局，为日常生产调度、运营、管理服务的各类信息系统快速积累了大量的数据资源，陆续建设了数据中心或信息中心，对大数据技术和数据资源效益的挖潜日益重视[1-4]。目前城市轨道交通部分企业采用了传统数据仓库一体机的模式，以北京、广州、深圳为代表，围绕线网运营业务建立数据结构和主题域，该模式以数据资源的存储为目标。但随着硬件设备、软件版本的更新换代，须同步更新历史数据管理方式，且难以适应于不断变化和弹性扩展的应用需求，投资成本高，逐步显现出它的劣势。随着大数据和云计算技术的探索应用，文献[5-6]总结了基于Hadoop各项大数据技术及应用创新。池亚平等[7]研究了大数据平台海量监控数据的存储效率改进方法。李敏等[8]就物联网环境下的数据时空特性提出了异构大数据处理的时效性改进模型，这些为大数据平台的建设和应用优化提供了借鉴。一些新建和规划数据中心的轨道交通企业，如上海、南京、重庆，采用了新型的大数据平台技术，如基于MPP(Massively Parallel Processor)架构、基于虚拟化共享硬件的方式，基于Hadoop大数据平台模式，均不同程度地兼顾了远期硬件扩容的投入，以及数据挖掘、商务智能方面应用的灵活扩展性。

针对城市轨道交通数据资源在业务、生产、经营、管理、服务方面的差异性，将数据运用于不同应用场景的需求，本文提出建立基于混合式架构的大数据平台模式，以可扩展、自适应、可定制为目标导向，深化平台的系统架构、数据架构、分层管控机制，并在运营管理与决策支持中加以运用，为运营信息化基础大数据平台提供一套实用的综合解决方案。

1 运营信息化业务数据特征分析

1.1 数据类型多样与时空特性

城市轨道交通运营信息化类系统作为企业数据资产的基础数据源，根据业务归属和关联关系划分为生产类、管理类、业务类、线网级管理与基础平台类四种类型。具体如下：

1) 生产信息化系统，包括信号ATS、通信、综合监控ISCS、电力PSCADA、火灾报警FAS、环控BAS、自动售检票AFC、清分中心ACC等系统[9]，主要服务于日常的生产调度与安全保障。

2) 办公管理信息化系统，包括办公自动化、人力资源管理、财务管理、合同管理、档案管理等系统。

3) 运营业务信息化系统，包括票务管理、站务管理、乘务管理、资产管理、运营计划管理、施工调度、维修管理等系统。

4) 线网级管理与基础平台系统，包括线网指挥中心、线网应急处置、信息发布等，以及统一认证、门户网站、BIM系统等。

产生的数据类型包括结构化数据、非结构化数据、半结构化数据，例如存储于关系型数据库的数据表，视频监控的多媒体数据，接口传输的文件类数据等，需要配置不同的存储模式和空间与之相适应。实时数据存储时间要求不一，如历史报警、突发事件等数据需要长期保存，而常规视频数据一般存储15～30日，接口文件一般存储0.5～1年。数据的时空差异性决定了统一数据资源管理需要因地制宜，结合业务和数据本身的特性制定策略。

1.2 数据处理的复杂性

根据各类业务系统数据的时效性差异，数据采集时间和方式也不同，包括实时数据(采集周期1 s以内)、近线数据(5 min以内)、离线数据(小时、日、周不等)、随机数据(一般不固定时间，数据产生时自行抽取或推送)。接口方式包括专用的接口协议或通信机制，如Modbus TCP/IP协议，文件消息队列(Message Queue)方式、FTP文件传输、报文、Web service等，实现用于数据表交换的监控数据静态点、状态点、监测点、控制点，及客流文件、多媒体数据等的获取，再根据业务特点统一清洗、抽取、加载为可共享的数据形式存储。

1.3 应用面广与数据多重交互

共享数据资源经过整合后为各种业务系统调用，同时各系统之间存在数据交互，如调度监控系统为运营管理和应急处置系统提供设备报警的数据，及时预防灾害或处理大型故障；资产管理系统为物资管理、维修管理系统提供统一的编码；统一认证和门户系统为各类业务系统提供统一的企业用户名录和角色保障数据同步更新。分析性数据为指标统计、效益核算、成本分析、线路规划及建设后评估等提供决策依据。

2 运营信息大数据平台的构建

2.1 混合式架构的数据平台框架

平台定位于建立面向多用户的信息集中共享、资源高效利用的轨道交通数据服务和综合信息管理平台，实现统一采集、长期存储、统计分析、数据挖掘的功能。根据各种业务的数据共享和使用需求，首先搭建定制化的基础数据平台，基于数据仓库MPP架构、大数据Hadoop架构及关系型数据结构混合的数据管理模式，实现分级分类的数据共享。构建总体规划的分层体系，即数据采集层、数据融合层、技术组件层、分析模型层、应用访问层的五层系统架构。如图1所示。

图1 运营信息大数据平台的层次架构

(1) 数据采集与融合层 完成各类系统基础数据和设备级系统数据的接入，包括与车站层、线路层、车辆段、控制中心等系统的接口，与外部信息的边界安全防护，保障实时、非实时数据的采集和处理。按照实时库、非实时的业务主题数据、公共数据对象抽取，并根据结构化、非结构化数据类型区分存储周期和更新机制。

(2) 技术组件与分析模型层 将通用的组件和工具形成资源模型库，将工作流、接口标准化、微服务、流计算、数据发布、单元建模、画面组件等通用组件集以调用模式统一管理，并封装便捷的调用接口。将单元业务应用包划分为最小单元，进行多维度分析和业务流程建模，浓缩和汇聚主要的业务单元，成为信息化系统调用的最直接资源库。

(3) 业务应用访问层 作为日常生产、管理、经营、企业资源利用等方面数据服务的系统工具，实现信息流转和办公支撑，构建标准、安全、高效的信息共享模式。面向车站、线路、线网各级别的系统，覆盖城市轨道交通数据资源需求的各个业务面。

2.2 数据流规划与分级存储

数据处理系统作为大数据平台的核心，通过对业务数据的有效集成，满足对海量数据的存储、管理和使用需要，需根据业务类型进行数据流规划与存储机制的设计，如图2所示。

图2 混合式数据管理模式及数据流

数据资源归纳为以下四种类型：

(1) 实时数据库 用于采集实时数据，设计快速提取和计算服务模块，将获取的实时数据标准化处理后转入实时监控的可视化展示，如设备状态实时监控。

(2) 关系型数据库 设置一定存储空间的关系型数据库，用于多元业务流程及可扩展应用的数据管理和事务型分析的应用，如资产、维修、调度管理等。

(3) 基于MPP架构的数据仓库 设置基于主题域和元数据管理的数据仓库，围绕定向型业务定义数据结构，如历史报警综合查询、多维统计、客流预测、仿真回放，并统一进行数据质量、数据治理、数据模型、数据维护管理。利用数据仓库的数据分析能力支持运营效果评估和运营仿真应用。

(4) 基于Hadoop架构的大数据应用库 将所有采集的数据汇总存入，非结构化数据独立管理，并定义索引用于智能检索。采用分布式Kafka消息队列的方式采集数据后，定制可扩展的存储逻辑单元管理，为长期数据存储扩容提供条件，运用处理、查询、读取的各类工具集管理数据，为业务系统提供数据服务，如客流预测、云管理等。

2.3 数据采集与计算服务标准化

传统的数据共享方式，经过数据采集后直接存储，为业务系统提供数据时呈现出松散、繁杂的原始特征。由于城市轨道交通专业众多，数据内容和类型多样，所以数据经采集后处理的方式对数据分发的时效性、根据时间片存储数据的同步性和一致性等都会产生影响。而接口采集的数据一般都是现场设备状态及系统运行数据，实际业务需要呈现的数据，往往要根据数据形式进行数学运算和逻辑判断。未经过以业务需求为出发点处理的数据，使用的效率低，而为了单一业务需求涉及多个数据表的访问和关联，对系统的负载和数据读取的效率均产生不利影响。

针对这一问题，为大数据平台的数据采集模块设计基于数据实时计算的快速标准化的数据处理方法。数据采集后即做快速处理，以最小通用单元的形式，为业务系统提供便捷、可直接应用的数据单元。通过设定统一的数据处理模板，将单元数据的业务需求归纳并加以屏蔽，经过实时计算和解析为标准化的基础数据单元，可大幅减轻在大规模数据接入后处理过程的繁杂性，提高数据的应用效率。并进一步引入统一的数据模型、制定报警处理规则等方式，将不同专业系统的业务流程归一化。从实时数据接入后进行标准化处理过程规划、实时计算处理原则、功能、性能保障角度对数据处理服务设计，确保数据的业务适用性、实效性和可靠性。主要包括三个阶段：数据提取，数据计算及服务、自动分析与报警服务。

2.3.1 数据提取服务

数据提取模块包括：专业数据、时间数据提取。从消息中间件获取数据采集层提供的实时数据，如设备状态、客流监测数据，经数据提取过滤的时间数据，根据表达式进行实时计算，并将计算结果推送给报警管理业务功能和实时可视化监控模块，严格区分各自接收的专项数据内容。

数据采集层定义Producer(接口甲方)，计算服务模块定义为Consumer(接口乙方)。如果有请求信息，数据采集层接收则为Consumer(接口甲方)，计算服务模块则为Producer(接口乙方)。例如监控系统的数据载入按每条地铁线路创建二个通道(Topic)，为多副本单分区形式。以客流数据计算服务为例说明计算方法如下。

(1) 初始化定义。定义过程(DatalogicWorker)：周期性地向数据计算服务模块提供客流数据，包括：进出站客流、断面客流、各类客流数据排名、各类客流数据报警状态。流程如下：

定义数据提取任务(Job)：每个数据提取任务实现不同数据的提取，定义过程(PassengerFlowLogicJob)，该任务用于提取进出站客流、区间客流。具体业务逻辑在private static void GetPassengerFlowData()方法中实现。计算逻辑如下：

var pfstmeList=PassengerFlowDataCollection.GetInstance().GetPassengerFlowStation();

foreach(var pfsm in pfstmeList)

{

PfstmeMaps.Add(ConvetTools.LongTryParse(pfsm.Stationid.Trim()+pfsm.Flowtype), pfsm);

//作为字典Key，标示客流状态

PfstmeMaps.Add(ConvetTools.LongTryParse("10000"+pfsm.Stationid.Trim()+pfsm.Flowtype),pfsm);

}

(2) 将数据提取服务(ScheduleService)注册为系统服务。

(3) 定义数据提取服务的启动、停止方法，并在启动方法中初始化所有数据提取任务。

定义过程(Periodic)：周期性的向数据计算服务提供所需的时间数据，包括：当前时间(到s级，每隔10 s更新一次)、当日运营时间(到min级，每日更新一次)。

首先定义时间数据提取与发送机制：

private void StartEtlAction(SqlEtlInfo sqlEtlInfo, string timeRequest)

{

var config=sqlEtlInfo.DatabaseTypeConnQuery;

if(config.Trim().Length<1) return;

var sqlconfig=JsonHelper.DeserializeJsonToList(config);

var sqlTimeRequest=sqlconfig.Where(s=>s.TimeRequest.ToLower()==timeRequest.ToLower());

foreach(var item in sqlTimeRequest)

{

var type=GetDbType(item.DatabaseType);

try

{

using(var db=SugarDao.GetInstance(type, item.DatabaseConn))

{

var datast=db.SqlQuery(item.DatabaseQuery).ToList();

//System.Diagnostics.Debug.WriteLine(string.Join(";",

//datast));

var sendData=string.Join(";", datast);

ServiceProvider.GetService().

ActiveMqWorker.Send(sendData);

log.Info(＄"Send to MQ:{sendData}");

}

}

catch(Exception ex)

{

ExceptionHelper.HandleException(ex);

}

}

}

再经初始化，将时间数据提取服务添加到服务容器。

2.3.2 数据计算服务

将各类数据调取需求归纳为统一、可识别的表达式模板，转换为数据表定义，对应不同的列形成机器识别的数据类目，并进一步对应到数据计算过程中。

定义过程(Bridge)：接收数据提取服务模块发送的数据，实时计算相关的表达式，并将计算结果推送至消息中间件或报警管理服务。流程如下：

(1) 服务启动入口；

(2) 将服务添加到服务容器内；

(3) 启动数据计算服务；

(4) 数据分发。

具体计算过程包括：

初始化：

public void InitialzeResultExpDict(DbType dbType, string connStr, BlockingCollection