智能交通大数据综合服务平台

智能交通大数据综合服务平台

1. 概述

随着经济发展、城市化进程的加快以及城市规模不断扩大，机动车拥有量及

道路交通流急剧增加，城市紧缺的土地资源和高密度的土地利用模式，使得交通

供给与交通需求之间的矛盾日益突出，交通拥堵、停车困难、环境恶化等交通问

题不断加剧，影响了城市的可持续发展及人民生活水平的提高，阻碍了经济的发

展。大城市也面临同样的问题，近年来机动车保有量持续快速增长，高峰交通拥

堵日益加剧，交通发展面临严峻形势和新的挑战。很多城市在市区主要范围内实

施“错峰限行”等交通管理措施。采取调控交通需求削减交通需求总量其原因之

一是城市道路已经难以通过基础设施规划建设来改善交通。另一方面,如何利用

智能交通系统(ITS)来缓解交通、提升交通效率也是可以着力的一个方向。

目前各交通管理部门建立了功能相对完善的交通指挥控制中心，包括交通信

号控制系统、道路交通监控系统、交通诱导显示系统、停车管理系统、交通违章

处理系统等，初步实现了交通信号控制、道路监控、交通信息综合查询、有/无

线指挥调度及交通诱导等基础功能。ITS的各种信息采集技术（如微波采集技术、

视频采集技术、环形线圈感应式采集技术等）被广泛地运用于交通数据采集，公

安交管部门不仅具备了交通基础信息，还拥有了各类动态数据，如车辆实时营运

信息、道路交通状况等，采集的数据类型包括属性数据、空间数据、影像数据等。

对交通三要素（人流、车辆、道路）连续不断采集的多源交通数据流产生了巨量

的交通数据，具有典型的“3V”特性：大容量、多样性、高速度，也具有价值、

复杂性的特点，属于名符其实的交通“大数据”。仅以国内某城市内道路卡口数

据为例，每天达到约15GB的数据量，要实现对城市道路交通的整体运营水平和

人们出行规律的深度挖掘，就要以日、月甚至年为时间粒度对大数据进行计算和

分析。

数据是智能交通的核心，数据为王的大数据时代已经到来。如何高效地从海

[

量数据中分析、挖掘所需的信息和规律，结合已有经验和数学模型等生成更高层

次的决策支持信息，获得各类分析、评价数据，为交通诱导、交通控制、交通需

求管理、紧急事件管理等提供决策支持，为交通管理者、运营者和个体出行者提

供交通信息，成为当务之急。交通数据分析的发展趋势正如TDWI大数据分析报

告指出的，由常规分析转向深度分析，如图1所示。

图1分析的趋势

在交通数据分析方面，生昕格交流了交通云数据处理平台的一个具体应用

[7]

实例，该平台基于廉价计算机构建集，用Hbase存储大数据，采用MapReduce

进行分布式计算；Chen等利用MapReduce框架对交通流预测；李磊等论述了

[8][9]

基于云计算的铁路数据中心的逻辑结构。这些工作没有涉及交通大数据处理平台

需要面对的各种应用场景以及系统构建应遵循的原则，如没有涉及实时数据流处

理问题。面对交通大数据，如何存储、组织和管理并提供服务是ITS面临的一个

挑战。本文针对如何构建交通大数据处理平台开展研究，主要从使能技术方面展

开论述，不对具体业务系统进行评述。

2.交通大数据处理平台的功能需求及其逻

辑框架

本节通过介绍智能交通系统大数据的特点以及提供服务的要求分析了交通

大数据分析平台需具备的特点，提出了交通大数据处理平台逻辑框架，并进一步

阐述了平台构建的基本原则建议。

2.1交通大数据处理平台需具备的特性

如前所述，交通服务要提供全面的路况，需要交通综合监测网络对城市道路

交通状况、交通流信息、交通违法行为等的全面监测，采集、处理及分析大量的

实时监测数据，具有数据量巨大的特点；随着城市机动车保有量不断提高，城市

道路交通状况日趋复杂化，交通流特性呈现随时间变化大、区域关联性强的特点，

需要根据实时的交通流数据及时全面采集、处理、分析等，因此具有系统负载时

变性高、波动大的特点，应支持低延时、高并发事务；公众出行服务对交通信息

发布的时效性要求高，需将准确的信息及时提供给不同需求的主体，信息处理、

分析实时性要求高；ITS需面向政府、社会和公众提供交通服务，为出行者提供

安全、畅通、高品质的行程服务，保障交通运输的高安全、高时效和高准确性，

要求ITS应用系统具有高可用性和高稳定性。这给交通大数据处理平台提出了挑

战，平台需满足的特性如表1所示。

交通大数据处理平台面对海量数据，系统不能仅依靠少数几台机器的升级

(Scale-up，纵向扩展)满足数据量的增长，必须做到横向可扩展(Scale-out)，

既满足性能的要求，也满足存储的要求（包括结构性数据、非结构形式、半结构

性数据）；由于服务需求的多样性，平台既要支持交通数据流的实时分析与处理

又要支持复杂查询与深度分析所需的高性能、低延迟需求。平台需具有高度容错

性，大数据的容错性要求在作业(Job)执行过程中，一个参与节点失效不需要重

做整个作业。机节点数的增加会增加节点失效概率，在大规模机环境下，节

点的失效不再是稀有事件，因此在大规模机环境下，系统不能依赖于硬件来保

证容错性，要更多地考虑软件级容错，同时增加系统的可用性。系统的开放性也

是十分重要的，在下一小节会知道ITS是一个巨系统，各子系统之间数据交换、

共享以及服务集成是必不可少的，同时要求系统支持迭代开发，可不断更新/增

加功能；系统服务不但专业人员可以使用，业务人员也可以使用，分析可以实现

大众化。

另外，平台应支持异构环境。交通大数据平台的建设是分步骤、分阶段进行

的，设备的采购、更新会造成硬件系统的异构，建设同构大规模机难度较大；

另外，对异构环境的支持可以有效地利用历史上积累的计算机资源，降低硬件成

本的投入。

表1交通大数据处理平台需具备的特性

特性简要说明

高度可扩展性横向大规模可扩展，大规模并行处理

实时性对交通数据流、事件的实时处理

高性能、低延迟分析快速响应复杂查询与深度分析、实时分析结果

高度容错性系统在硬件级、软件级实现容错

可用性系统具有相当高的可靠性

支持异构环境对硬件平台一致性要求不高，适应能力强

开放性、易用性系统之间可实现数据共享、服务集成

较低成本较高的性价比

2.2交通大数据分析平台逻辑框架

ITS是一个复杂的巨系统。中国ITS体系框架确定了以下内容：用户服务

包括9个服务领域、47项服务、179项子服务；逻辑框架包括10个功能领域、

57项功能、101项子功能、406个过程、161张数据流图；物理框架包括10个系

统、38个子系统、150个系统模块、51张物理框架流图；应用系统有58个。ITS

内容庞多、结构复杂、技术含量高，需要多个领域、多个部门的长期合作。ITS

涉众面广，包括政府部门、企业、公众，由此决定了其信息服务需求的多样性：

交通指挥部门需要实时连续交通监控（如流量、平均车速、饱和度、占有率等）；

城市规划部门需要当前和历史路网交通流和交通需求数据；出行者需要即席查询

[6]

交通信息等。因此，涉及交通数据流实时分析处理（RTAP）、联机事务处理（OLTP）、

联机分析处理（OLAP）、联机分析与挖掘（OLAM）等功能。

图2 大数据分析与处理平台通用体系结构

为此，构建交通大数据分析与处理平台需要结合分布式并行处理技术与实时

数据流处理技术。其逻辑功能框架如图2所示。层次功能结构逻辑如图2右半部

分所示，自底向上分别是分布式存储层、分布式处理层、元数据服务层、处理分

析层（包括复杂事件处理CEP、实时分析处理RTAP、联机分析处理OLAP、深度

分析OLAM）以及交通大数据分析处理应用层；同时，需要对分布式系统进行作

业、资源调度、管理的协调与监控中间件的支持，支持工作流及其调度的设施。

而在图2左半部分则展示了交通大数据分析与处理平台的部件结构图，在逻辑上

可划分为实时数据流处理子系统与大数据深度分析（知识获取与模式发现）子系

统。

实时数据流处理子系统接受实时交通数据流，数据流元组记录随时间变化的

空间（如位置、区域等）信息、以及车牌、卡口、速度等属性数据或视频、图像

数据，具有动态、海量、高维、时效、连续、多源、无限等特性。该子系统是实

现实时交通监控系统的数据基础，能够为指挥调度、道路规划、事故预警等交通

信息管理和决策提供支持，为交通用户提供更为全面和便捷的服务。该子系统包

含数据流管理系统，提供对数据流的连续查询和混合查询支持。连续查询用于实

时持续不断地监控，如“查询超速的车辆信息”以及“开始监控违法车辆行踪”

是连续运行的查询，后者涉及空间数据库。用户可以指定连续查询的滑动时间窗

口，对于进入窗口且符合查询条件的事件进行报警监控。混合查询用于那些不仅

需要涉及动态流数据还需要访问静态历史和空间数据的复杂查询，如“统计未来

5分钟内从西湖区流出的车流量”。

深度分析子系统运用各种先进的数据处理技术，包括数据集成技术、人工智

能与数据挖掘技术、决策支持与专家系统等，根据各交通子系统的需求和它们之

间的内在联系，对来自多来源渠道、格式不一致的数据在综合交通信息的基础上

进行抽取、集成，并进行深度分析与处理，获得可用于决策的模式、模型、规则

和知识。需要改造传统的数据挖掘、机器学习算法，以适应大数据的需要。

平台对外提供各种交通信息服务，实现多种模式交通信息发布，包括Web交

通信息服务、电台电视台、交通服务、手机与车载导航等移动终端、触

摸屏查询终端、可变情报板、交通指南等载体的交通信息发布。各种应用与服务

之间通过一个统一的服务接口进行连接，服务接口向上层应用提供一致的调用接

口，屏蔽底层细节，它是一个接口规范，用以隔离应用与服务，实现两者的独立

性，以期达到平台功能扩展的灵活性。平台的数据则来自ITS交通数据采集监控

网，该层包括网络层（信息传输）和感知层（信息感知与获取）。

3.交通大数据处理平台的构建

本节阐述在当前计算技术下的一个可能的平台方案。据前述，平台必须具有

高度可扩展性、实时性、高性能、低延迟分析、高度容错性、可用性、支持异构

环境、开放性、易用性，同时也希望具有较低成本；其核心技术包括大规模数据

流处理技术以及大规模数据管理、分析技术。这要求我们在进行平台构建时作出

合理的决策。

对大数据进行分析的基本策略是把计算推向数据，而不是移动大量的数据；

对大数据处理、分析的性能优化，分布式并行是必然选择，并且软件系统性能的

提升可以降低企业对硬件的投入成本、节省计算资源，提高系统吞吐量；但异构

节点之间的性能差异可能导致系统“木桶效应”，因此，异构机需要特别关注

负载均衡、任务调度等方面的设计；交通数据量及其多样性给数据管理系统提出

了新的要求，在存储以及处理方式需要具备较好的扩展性，无共享结构

(Shared-nothing)的存储方式是较好的候选方案，传统数据库缺少水平扩展的能

力，在系统设计决策中根据数据大小、性能瓶颈、处理能力等因素决定哪些数据

由传统数据库来管理，哪些数据应当由新出现的oSQL (ot only SQL)存储

[11]

管理系统来管理。

3.1交通大数据分析平台

根据以上分析，新近云计算是一种可选方案。云计算是分布式处理、并行处

理和网格计算的发展，是这些计算机科学概念的商业实现，具有分布式、大规模、

虚拟化、高可靠性、通用性、高可扩展性、低廉等特点，它实现对共享可配置计

算资源（包括网络、服务器、存储、应用和服务等）的按需服务。云计算中的平

台（集计算框架）有谷歌的MapReduce与微软的Dryad等，而Hadoop是

[12][13]

一个实现了MapReduce的开源分布式并行编程框架；专门针对迭代计算的编程

框架有Pregel、HaLoop等，前者是一个迭代图形计算系统，后者提供了一

[14][15]

个迭代MapReduce接口。基于Hadoop的应用可以运行于机上，实现对海量数

据的处理。此外，Hadoop平台已经形成了一个生态系统，提供一个分布式文件

系统(HDFS），HBase是基于HDFS的对BigTable的开源实现，是面向列、可伸

缩的分布式存储系统，支持事务以及B树范围查询和排序；Hive是基于Hadoop

的大型数据仓库，其目标是简化Hadoop上的数据聚集、即席查询及大数据集的

分析等操作，以减轻程序员的负担；Pig是Yahoo!提出的类似于Hive的大数据

集分析平台,它提供的类SQL语言叫Pig Latin，一种基于操作符的数据流式的接

口,该语言的编译器会把类SQL的数据分析请求转换为一系列经过优化处理的

MapReduce运算；Mahout是可伸缩的机器学习算法；工具Sqoop用于传统数据

库和HDFS进行数据交换；Oozie是工作流调度工具；ZooKeeper是一个分布式

的应用程序协调器，它包含一个简单的原语集，分布式应用程序可以基于它实现

同步服务，配置维护和命名服务等。基于Hadoop的大数据分析平台构建如图3

所示。需要注意的是，Hadoop适用于长顺序扫描，基于Hadoop的Hive会导致

较高的延迟，因此不适用于需要快速响应的场景；Hive基于只读的，不适用于

事务处理的场景。

图3 大数据分析与处理平台的一个实例

图4 CAP理论的可视化图

解

在平台构建中涉及分布式存储系统的选择。在分布式系统中，一致性(即所

有节点访问同一份最新的数据副本)、可用性(即对数据更新具备高可用性)、分

区容忍性(即能容忍网络分区），这三个要素最多只能同时实现两个，这就是周

知的CAP理论。但通过显式处理分区情形，系统设计师可以通过细致地管理分

[10]

区期间的不变性约束优化数据的一致性和可用性，对三者进行平衡。CAP的C

仅指单一副本这个意义上的一致性，因此只是ACID一致性约束的一个严格的子

集。ACID一致性不可能在分区过程中保持，因此分区恢复时需要重建ACID一

致性。CAP理论的可视化图解见图4。而oSQL一般放弃ACID事务策略的一致性，

而是采用BASE(基本可用、事务软状态以及最终一致性)事务策略以换取高可用

性和可伸缩性。oSQL存储系统可分为键－值存储(如Redis, Tokyo Cabinet)、

列存储(如HBase, Cassandra)、文档数据库(如MongoDB, CouchDB)、图数据库(如

neo4j, FlockDB)等；对于具体应用，应当根据需要支持的数据模型、一致性机

制、存储机制、持久性保障、事务支持、可用性、查询能力、性能保障等方面来

选择相应的oSQL存储系统，不可一概而论。据统计，目前oSQL存储系统有

150种之多。

3.2实时数据流处理子系统

实时性是交通数据处理的关键也是其价值得以实现的基础。如交通流的实时

监控、交通拥堵状况的实时信息、交通诱导等应用均要求系统能够返回当前的交

通状态；在另一些场景则需要进行连续监控，在技术上涉及连续查询。这方面的

功能需求已在第二节讲述。在构建交通大数据处理平台中，实时交通数据流处理

子系统是关键系统之一。该系统中涉及的关键技术包括：高速数据转换，将获取

的事件数据流由随机访问格式转换为分布式并行分析格式，将几分钟前获取的交

通数据即时处理呈现最新分析结果；灵活的资源分配方案，不同类型的数据处理

组件（即事件处理服务）与可伸缩分布式键值存储灵活连接，可以便捷地构造新

的服务而不影响现有系统的运行；基于滑动窗口的连续计算技术；自适应负载平

衡与资源分配优化。

开源的分布式实时流计算框架有Twitter的Storm、Yahoo！的S4、基于Hadoop

的HStreaming、专门进行复杂事件处理和事件流处理的Esper等。Storm

具有高容错性、水平扩展性好、快速、可靠处理消息等优点；S4目前还处于半

成品阶段，代码成熟度底，不支持动态部署；Storm支持节点在集中动态增加

或移除，S4不支持；Storm属于全内存计算，所需的内存资源多，HStreaming

介于半内存和全磁盘计算，速度相对慢。本文以Storm为例来阐述交通数据实时

平台的构建。

Storm采用创建拓扑结构(topology)来转换数据流，不同于Hadoop作业，这

些转换会持续处理到达的数据。Storm为流转换提供的基本组件有：喷口(Spout)

和螺栓(Bolt)。Spout是一个输入流组件，负责将数据分发到多个Bolts执行处理

任务(如过滤、聚合、查询等)，Bolts执行后可产生新的流作为下级Bolts的输入

流。由此形成的整个处理结构即为一个Topology(作业或应用)如图5所示。相应

地，基于Storm的交通数据流处理逻辑以及软件结构分别如图6与图7所示。

图5 一个Storm的T

opology结构

图6基于Storm交通数据流处

理逻辑框架

图7 Storm交通数据流处理的软件结构

在一个基于Storm的交通数据处理集中，有主从两种不同的节点，三种不

同的守护进程：imbus运行在主节点上，类似于Hadoop中的Jobtracker，主要

负责接收客户端提交的Topology，进行相应的验证，分配任务，进而把任务相

关的元数据写入Zookeeper相应目录，此外，imbus还负责通过Zookeeper来

监控任务执行情况，负责全局任务调度。从节点上运行Supervisor，类似于

TaskTracker，管理本地节点的任务，负责会监听任务分配情况，根据实际情况

启动/停止工作进程（worker）。每个从节点上运行进程worker，类似于Hadoop

中的map/reduce的任务，worker进行Spout/Bolt数据处理。不同于map/reduce

任务，worker是连续计算，不会停止。不同于Hadoop，守护进程间并不直接发

送心跳信息或者存在其他RPC控制协议，他们之间的信息交换是通过Zookeeper

来实现。其中Storm处理框架的处理结果可以在分布式存储系统中持久化存储。

3.3资源统一管理与调度

交通大数据处理与分析平台涉及多种不同类型的应用，如本文所讲述的脱机

应用（数据分析、数据挖掘）和联机应用（数据流实时处理），不同的应用可能

采用了不同的计算框架。为提高资源利用率、降低运维成本，将不同计算框架部

署到公共的集中，对资源（内存，CPU，网络IO等）统一管理与调度，让不同

计算框架共享集资源。目前，这方面典型代表有Mesos和YAR。本文采用

[16]

Mesos构建资源共享平台，如图8所示。

图8 基于Mesos平台的资源共享体系结构

[16]

Mesos是一种让多个计算框架有效共享机资源的可伸缩弹性的“核心”集

资源管理器。它通过定义多个计算框架进行资源共享的最小接口，把任务调度

与执行控制交给各个计算框架来负责。有利于适应机框架的多样性和快速演化

性。Mesos由master进程和框架组成。master进程负责管理运行于机节点上的

slave守护进程，框架在slave节点上运行任务。master进程通过资源供应方式实

施个计算框架之间的资源共享。每一份资源供应是各slave节点空闲资源表。

master进程采用某种策略（平等分享、优先共享等）决定分配多少资源给每个框

架。每个运行于Mesos之上的计算框架均包含两个组件：调度器和执行器。特

定计算框架通过自身的调度器向master进程注册，选择是否接受master提供的

资源，接受多少；而slave节点上的执行器（如Hadoop的执行器即TaskTracker）

运行框架的任务（task）。

4.原型系统实验

根据本文的论述，我们构建相应交通大数据处理与分析平台进行原型验证，

分别构建了Hadoop和Storm集对平均行车速度这个指标的计算。实验所采用

的设备规格说明如表2所示。为每个虚拟节点分配了一个虚拟CPU、2GB内存、

30GB外存，操作系统是CentOS6.2。

表2 实验所用设备规格说明

型号CPU内存存储VCPU/VMem/VDisk关联虚拟机节点

Dell Inc.戴尔

PowerEdge R910

Dell Inc.戴尔

PowerEdge R910

6CPU 24核64G500G1/2G/30Gmaster,slave1

6CPU 24核64G500G1/2G/30Gslave2,slave3

4.1交通大数据分析实验平台

所构分析平台采用Hadoop-0.20.2-CDH。实验中所产生卡口仿真数据是指某

个卡口某个时刻车辆通行的瞬时车速，产生了8GB 共399000000条记录的卡口数

据。相应作业采用Java语言实现，计算给定数据集的平均速度。实验中计算所

用时间是557秒。

4.2实时交通数据流实验平台

所构实验平台使用Storm 0.8.1、Zookeeper-3.4.5、ZEROMQ-2.1.7（内部消息

系统，用于节点或进程间的通信）和JZMQ（ZEROMQ的Java 绑定）。作业采

用Java语言实现，对卡口平均车速的持续监控。在Storm集中，共使用4个

Workers，每个Worker有4个Slots。在实验过程中每个Worker上使用1个Slot。

实验中，产生了三个卡口点位的仿真数据。实验结果见表3。

实验考察了并行度和执行效率，分别对相应作业配置了不同的Spouts与

Bolts个数。在并行度上，在集配置允许的情况下，Spout的并行度越高，产

生结果时间越短。但如果spout并行度超出了集配置的允许范围，Spout高并

行度并不能缩短产生结果时间，反而很有可能延长产生结果时间。由结果可知，

原型系统可以每秒处理1万条以上卡口数据。

表3 Storm机的运行结果

编号Topology名称卡口记录数（万）整体运行时间

1es10271001m33s

2fs5271001m40s

3gs10272002m37s

4hs10275006m3s

5js102710009m33s

5.结论

执行器中任务数

SpoutsBolts

本文围绕如何构建交通大数据处理平台开展讨论，主要从方法论角度展开论

述。首先，对平台需求及其逻辑框架进行了讨论，提出了相应的方案，讲述了其

涉及的核心技术；其次，提出了针对交通大数据分析平台以及交通数据流计算的

实时计算平台一种可行构建方案；最后，通过原型系统论证了方案的可行性。目

前，我们开展了前期的研究，没有涉及系统、代码的优化，也没有涉及具体业务

子系统的构建细节。下一步将进行实际运行系统的构建，开展更深入一步的工作，

包括实时交通数据流处理算法、交通大数据分析算法等方面的理论与实现技术的

研究。