基于数据仓库的北京轨道交通数据中心测试平台

张义鑫 杨 军 张 静 程丹丹

(1.北京城建设计研究总院有限责任公司 北京 100037;2.北京轨道交通路网指挥中心 北京 100101)

1 数据仓库的应用背景

随着数据仓库(data warehouse，DW)技术应用的不断深入，越来越多的企业开始使用数据仓库技术来搭建自己的数据库系统。但每个行业都有自己的运行特点、专属业务范围及特定的历史数据，因此企业在制订数据仓库的解决方案时，必须紧密结合本行业的特点及自身业务的发展需求，基于实际的测试案例，对不同设备进行认真比选后再做恰当的选择。

伴随着信息化项目建设的逐年增长，城市轨道交通也必将迈向“数字交通时代”。线网规模的扩大、网络化的运营，使线路和车站之间实现了互联、互通、资源共享，交通管理工作的压力日益增加，传统的单纯以数据为中心构造的数据库系统已经不能完全满足现代交通管理工作发展的需求，迫切需要以新的理念和新的技术构建新的数据中心。

具体到北京地铁，作为市内最重要的客运系统，过去几年，轨道交通指挥部门已积累了大量的数据，数据总量呈现出指数级别的增长。但目前各个系统相对独立，数据由各系统独立管理和使用，产生了诸如数据孤立、不能形成多维网络式数据对比、缺乏数据深入挖掘的状况，造成了一定程度的数据浪费。如何提升信息化水准，借助现代化、智能化的信息管理技术，对提高交通管理水平具有十分重要的意义。

目前，已有同行对道路交通数据中心的建设进行了研究:程新谦等从北京市道路交通管理系统的应用现状出发，分析了道路交通中数据中心的功能，并提出了具体的实现思路［1］;梁玉庆等针对北京市道路交通管理系统中信息资源孤立和浪费的问题，提出了基于数据仓库的交通信息发布系统，阐述了系统构架方案，并进行了系统实现分析［2］。但这些对数据仓库的应用研究大都还局限于道路交通领域，且只是对数据中心架构及功能实现进行了介绍，关于系统平台设计以及前期如何搭建测试环境都没有论述。可以说，数据仓库应用于轨道交通领域，国内还没有这方面的实践。

笔者从城市轨道交通信息中心项目对数据仓库技术的相关要求出发，结合业内在数据仓库选择前通常会进行的POC(proof of concept，概念原型验证)测试，基于对业界主流MPP(massive parallel processing，大规模并行处理)数据仓库的调研分析，搭建了轨道交通环境下完整的测试平台，并借此完成了对数据仓库主流厂家的实际测试，这对今后轨道交通信息中心项目的实施有一定的借鉴意义。

2 数据中心概况及存在的问题

随着北京市轨道交通建设的快速发展，轨道交通已经逐渐成网。为提高全市轨道交通网络的综合协调能力，合理有效地利用资源，实现网络化和多运营商的运营管理，北京市政府出台了有关规定，并于2008年奥运前构建并成立了一个可以协调指挥北京轨道交通全网的指挥中心，即北京市轨道交通路网指挥中心。该中心由轨道交通调度指挥中心(traffic control center，TCC)、自动售检票系统清算管理中心(AFC clearing center，ACC)两大核心业务系统构成，承担全线网信息的汇总及分析、运营监管、突发事件处置、票务清分清算等职责。

指挥中心建有辅助决策数据库系统，基于存储的轨道交通运营信息，可实现数据采集、综合监视、信息交换、资料管理、统计分析等功能。但目前北京市轨道交通内部各系统数据大多只具有某一专门用途，如“客流信息类数据”、“列车运行信息类数据”及“清算信息类数据”等都处于分散、独立的状态，不能得到统一的分析和处理，大大降低了它们的用途。随着交通管理人员对决策信息的需求日益广泛，传统的数据库系统已无法满足海量数据分析发展的需要。

1)数据库系统无法满足大量即席查询、复杂查询的需求。数据库系统可实现数据库内数据的增、删、改及简单查询、报表生成等工作，所执行的查询种类和报表内容/格式都需要信息系统管理人员预先设定。然而，业务人员的需求是不断变化的，随着对实时查询、复杂查询和新增报表需求的提出，信息系统管理人员不得不对原数据库系统进行修改，重新编写各种报表生成程序，浪费了大量的时间和精力。而且，开发更新的速度总滞后于用户需求的变化速度，开发瓶颈已成为信息管理人员及时、准确、灵活使用数据库系统的主要障碍。

2)现有数据库系统无法满足海量数据信息分析处理的需求。现有数据库系统都是联机事务处理系统(on-line transaction processing，OLTP)，而非联机分析处理系统(on-line analytical processing，OLAP)。OLTP 数据库系统的主要功能是对数据库内数据的收集、简单查询和报表生成，对查询得到的数据信息缺乏深入分析的能力。OLAP系统在拥有了完整的数据采集和存储过程后，除了需快速地对数据进行增、删、改、查之类的事务型处理，更关注的是长期运营信息的趋势及变化分析，能够在大量历史数据的支持下，对某一主题的相关数据进行多角度比较，从中找出数据之间的内在联系，得出科学的分析结果。目前，数据库系统难以满足对海量数据联机分析处理的需求。

3)现有数据库系统无法适应对研究对象进行多维灵活查询。对于轨道交通信息分析人员，统计查询分析需要灵活地指定时间维度、空间维度、票种维度等维度信息。如在粒度选择中，可设定需要查询指标的时间粒度、空间粒度、票种粒度，可以选择的时间粒度最小到1 min，最大到年;可以选择的空间“粒度”最小到设备，最大到线网;可选择票种的“粒度”最小为单一票种的罗列，最大为全票种输出。目前，数据库系统难以适应用户的“多粒度”要求。

4)现有数据库系统无法满足轨道交通运营信息膨胀、数据一体化整合的需求。随着北京市轨道交通建设迎来新的发展，2010年新开通5条线之后，TCC、ACC系统的数据容量及分析处理能力接近饱和，需要更为强大的系统支持业务分析的发展。同时，由于目前TCC、ACC分属于不同的业务领域，数据的分开存储不利于数据进行一体化分析，难以形成客流、行车、设备管理等方面的合力，难以提高轨道交通网络化运营管理水平，因此需要进行一体化整合。

当前，北京市轨道交通又掀起了新一轮建设高潮。轨道交通线路建设的规模、时序均超过了原来的预期，线网规模的扩大和发展，对网络化的集中指挥、智能化管理、资源共享等提出了更高的要求。为了更好地科学管理网络化的轨道交通系统，北京市交通委在《北京市交通科技创新规划(2010—2015)》中，明确提出要开展轨道交通网络化技术研究，以科技创新方式来确保轨道交通的规划、建设、运营、维护的科学性、先进性和可靠性。可以说，以新的理念和技术构建基于数据仓库的数据中心，使其具备足够的灵活性和可扩展性，为交通管理的业务工作和领导的指挥决策提供支持，在整个交通管理信息化建设工作中具有重要的意义。

3 数据仓库测试平台的搭建

3.1 数据仓库的关键技术

数据仓库技术作为数据库领域的分支，是后续的数据分析和数据挖掘的基础，目的是把信息访问从一种非结构化的或发展中的环境改变成一种结构化的或规划良好的环境［3-4］。数据仓库是面向主题的、集成的、不可更新的，它随时间的变化而不断变化，数据仓库的构建方法［5］如图1所示。

图1 数据仓库构建方法

可以说，数据仓库是整个基于信息整合和数据挖掘的交通信息系统的核心，在数据源系统和后续的数据分析、挖掘中起着关键作用，合理的利用可以很好地解决OLTP和OLAP系统在计算资源和存储信息方面的不同应用要求，更有效地实现数据挖掘和分析。

从数据仓库的建模可引申出数据仓库的运行架构，主要包括数据采集接口、ETL(extract transform and load)模块、数据仓库管理模块、ODS(operational data store)系统、数据仓库和数据集市以及为后续数据分析和挖掘提供的数据访问接口。

本测试平台的设计尽量经历数据仓库建模的全过程，旨在了解主流数据仓库的新技术、新特点，加深对主流数据仓库的认识;在熟悉主流数据仓库的安装、配置和使用的基础上，研究不同数据仓库产品的性能;最终为信息中心系统方案设计提供参考。

3.2 测试系统的拓扑设计

测试以信息中心项目需求为导向，从技术角度研究主流数据仓库产品满足需求的情况;按照公平公正的原则，到指定地点、按统一模式进行集中测试。

测试模拟了数据从源系统经加载至数据仓库本地，进行建库、建表，最终完成整套测试流程的全过程，测试拓扑见图2。

图2 测试平台拓扑结构

测试硬件环境包括测试加载服务器、压力测试服务器、磁盘阵列、千兆网络交换机、各厂家的数据仓库设备，以及准备的测试数据、测试用例及其他必要条件。

从测试系统拓扑设计可看出，信息中心数据仓库体系大体可包括数据源、数据的获取与集成、仓库数据管理和数据应用服务4方面。

1)数据源(磁盘阵列)。主要以地铁进/出站数据、计划行车时刻表、行车时刻统计信息表为基础，获取各种动、静态交通信息。这些数据存放于磁盘阵列的不同目录下，需通过建表、建库模型，对不同源数据进行抽取和聚集，形成多维视角［6］，为后续性能测试提供一个综合的、面向分析的决策支持数据环境。

2)数据获取与集成(数据加载服务器)。即ETL过程［7］，实际系统中不同数据源都是为各自应用而建立的，数据管理手段、硬件设备不尽相同，数据在编码、命名、类型和语义等方面不可避免地存在冲突。本次测试在原始表结构基础上进行相应改动，模拟了原始数据，通过ETL对数据进行转换、清洗的预处理，再将数据加载到DW中。

3)仓库数据管理(管理主机+节点服务器)。地铁数据中心要求实现运营数据的实时监测，能做到分钟级源数据加载和展示，要求操作界面良好，系统升级方便、高效。该处旨在查看系统本身是否具备对服务器、磁盘资源的监测管理功能，是否可动态管理系统各类资源，以保证系统性能的最优化。

4)数据应用服务(应用服务器)。主要包括:一是检验DW的整体性能，考察数据仓库平台是否支持线性扩展，且同时满足OLTP/OLAP性能;二是模拟今后大量的前端应用、仿真建模对数据仓库的数据高并发访问;三是作为地铁运营指挥中心，需提供7×24 h的不间断服务，因此数据仓库需具备高可用性。

3.3 测试内容及用例

3.3.1 测试内容

结合地铁实际业务需求及本次测试重点，设计了以下内容，测试内容说明如图3所示，各阶段用例设计见表1。

图3 测试内容说明

表1 测试步骤及内容设计

1)数据装载/卸载测试。考察大数据量装载/卸载效率，查看在加载一定数据量情况下的数据装载(单独装载、并发装载、实时装载)效率和数据卸载效率。

2)SQL性能测试。对数据仓库进行高并发、大数据量的操作，查看在此压力情况下，数据仓库的请求响应时间和资源消耗情况。

3)可扩展性测试。在计算、存储、网络资源一定的情况下，进行数据量线性扩展，其扩展过程能否做到快速高效、性能是否线性变化。

4)高可用性测试。在模拟服务器出现故障(系统盘、数据盘、网络、存储节点)的情况下，对服务的影响及快速恢复能力如何。

5)数据压缩测试:测试数据仓库对压缩功能的支持程度(性能调优后的压缩比为准)，以及压缩后的能力及效率。

6)易管理性测试:考察系统安装配置时间和可管理的程度。

3.3.2 测试用例

测试用例基于设计的数据表结构，以规范的SQL语句描述，一方面结合业务要求设计了地铁实时业务、近线业务、离线业务的逻辑功能，另一方面也尽可能体现不同数据仓库系统性能差异及自身特点。设计的测试ACC、TCC测试用例见表2～表3。

3.4 测试流程及结果记录

数据仓库是一个复杂的系统，要对系统功能进行全面测试，测试场景的构建将会十分复杂，并且可能存在测试案例重复与覆盖不全面的问题。本次设计的测试流程如图4所示。

表2 TCC测试用例设计

表3 ACC测试用例设计

本次测试基于3次大的数据量加载，分别进行性能特征的测试;数据加载与性能测试按序进行，每一次数据记载后都轮询测试案例，提取每轮独立的性能特征。这样，在测试一定铺底数据下个别业务性能的同时，又可纵向体现出大数据压力下数据仓库的扩展能力，保证了测试工作省时、省力、高效地运行。

整个测试严格按照流程图所排的顺序进行，性能测试对应的测试案例以规范的SQL形式给出。针对不同的测试内容，提取相关的测试用例，测试内容见表1，测试用例说明见表2～表3，测试结果记录见表4。

4 结语

数据仓库系统是一项综合性的技术和解决方案，集成了数据存储统计、联机分析处理等多种数据处理技术。作为数字化城市轨道交通系统中的重要一环，北京轨道交通路网指挥中心在长期工作中积累了大量数据，利用数据仓库技术实现了运营信息的高度集成共享，能为决策者提供完整、及时、准确、可信的决策信息，对提高业务决策水平及加速全市交通信息化发展具有重大的推动作用。

图4 测试流程设计

表4 测试用例结果记录

笔者结合当前北京轨道交通路网指挥中心建设信息中心的现状，分析了数据仓库建设的必要性，并提炼和总结了适于轨道交通行业数据仓库测试的一般流程;从业务需求出发，完成了数据仓库测试系统的拓扑设计、测试内容、测试案例及总体测试方案设计。测试平台设计可以为企业数据仓库的实际应用及现场测试方案的设计提供参考，为今后轨道交通信息中心类项目的实施提供一定的借鉴。

［1］程新谦.基于数据仓库的北京智能交通管理数据中心系统分析［J］.道路交通与安全，2009，9(5):22-26.

［2］梁玉庆，沙滨.基于数据仓库的交通信息发布系统［J］.道路交通与安全，2008(6):1-3.

［3］Inmon W H.Building the data warehouse［M］，4 ed.John Wiley＆Sons Inc，2005:21-23

［4］陈兰芳.智能数据仓库的设计方法［J］.中国计算机用户，2006(5):48-48.

［5］彭晓刚.建设企业级数据仓库［J］.金融电子化，2007:52-54.

［6］樊涓筑，张凡.数据仓库技术在地铁交通系统中的应用［J］.贵州工业大学学报:自然科学版，2006，35(2):83-87.

［7］缪嘉嘉，邓苏，刘青宝.ETL 综述［J］.计算机工程，2004，30(3):14-22.