智能交通大数据处理平台之构建

交通拥堵成为大城市通病，改善城市出行条件已成为当务之急。智能交通系统是缓解交通、提升交通效率的有效手段。数据是智能交通的核心，对交通数据深度处理与分析是其中关键。

引言

随着经济发展、城市化进程的加快以及城市规模不断扩大，机动车拥有量及道路交通流急剧增加，城市紧缺的土地资源和高密度的土地利用模式，使得交通供给与交通需求之间的矛盾日益突出，交通拥堵、停车困难、环境恶化等交通问题不断加剧，影响了城市的可持续发展及人民生活水平的提高，阻碍了经济的发展。杭州市也面临同样的问题，近年来机动车保有量持续快速增长，高峰交通拥堵日益加剧，交通发展面临严峻形势和新的挑战。杭州市政府决定自2011年10月在市区主要范围内实施“错峰限行”等交通管理措施。采取调控交通需求削减交通需求总量其原因之一是杭州已经难以通过基础设施规划建设来改善交通。另一方面,如何利用智能交通系统（ITS）来缓解交通、提升交通效率也是可以着力的一个方向。

目前杭州市交通管理部门建立了功能相对完善的交通指挥控制中心，包括交通信号控制系统、道路交通监控系统、交通诱导显示系统、停车管理系统、交通违章处理系统等，初步实现了交通信号控制、道路监控、交通信息综合查询、有/无线指挥调度及交通诱导等基础功能。ITS的各种信息采集技术（如微波采集技术、视频采集技术、环形线圈感应式采集技术等）被广泛地运用于交通数据采集，公安交管部门不仅具备了交通基础信息，还拥有了各类动态数据，如车辆实时营运信息、道路交通状况等，采集的数据类型包括属性数据、空间数据、影像数据等。对交通三要素（人流、车辆、道路）连续不断采集的多源交通数据流产生了巨量的交通数据，具有典型的“3V”特性：大容量、多样性、高速度，也具有价值、复杂性的特点，属于名符其实的交通“大数据”。仅以杭州市内道路卡口数据为例，每天达到约15GB的数据量，要实现对城市道路交通的整体运营水平和人们出行规律的深度挖掘，就要以日、月甚至年为时间粒度对大数据进行计算和分析。

数据是智能交通的核心，数据为王的大数据时代已经到来。李国杰院士指出战略需求发生了重大转变，企业关注的重点转向数据，计算机行业正在转变为真正的信息行业，从追求计算速度转变为大数据处理能力，软件也将从编程为主转变为以数据为中心。如何高效地从海量数据中分析、挖掘所需的信息和规律，结合已有经验和数学模型等生成更高层次的决策支持信息，获得各类分析、评价数据，为交通诱导、交通控制、交通需求管理、紧急事件管理等提供决策支持，为交通管理者、运营者和个体出行者提供交通信息，成为当务之急。交通数据分析的发展趋势正如TDWI大数据分析报告指出的，由常规分析转向深度分析，如图1所示。

图1 分析的趋势

在交通数据分析方面，生昕格交流了交通云数据处理平台的一个具体应用实例，该平台基于廉价计算机构建集群，用Hbase存储大数据，采用MapReduce进行分布式计算；Chen等利用MapReduce框架对交通流预测；李磊等论述了基于云计算的铁路数据中心的逻辑结构。这些工作没有涉及交通大数据处理平台需要面对的各种应用场景以及系统构建应遵循的原则，如没有涉及实时数据流处理问题。面对交通大数据，如何存储、组织和管理并提供服务是ITS面临的一个挑战。本文针对如何构建交通大数据处理平台开展研究，主要从使能技术方面展开论述，不对具体业务系统进行评述。

交通大数据处理平台的功能需求及其逻辑框架

本节通过介绍智能交通系统大数据的特点以及提供服务的要求分析了交通大数据分析平台需具备的特点，提出了交通大数据处理平台逻辑框架，并进一步阐述了平台构建的基本原则建议。

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

如前所述，交通服务要提供全面的路况，需要交通综合监测网络对城市道路交通状况、交通流信息、交通违法行为等的全面监测，采集、处理及分析大量的实时监测数据，具有数据量巨大的特点；随着城市机动车保有量不断提高，城市道路交通状况日趋复杂化，交通流特性呈现随时间变化大、区域关联性强的特点，需要根据实时的交通流数据及时全面采集、处理、分析等，因此具有系统负载时变性高、波动大的特点，应支持低延时、高并发事务；公众出行服务对交通信息发布的时效性要求高，需将准确的信息及时提供给不同需求的主体，信息处理、分析实时性要求高；ITS需面向政府、社会和公众提供交通服务，为出行者提供安全、畅通、高品质的行程服务，保障交通运输的高安全、高时效和高准确性，要求ITS应用系统具有高可用性和高稳定性。这给交通大数据处理平台提出了挑战，平台需满足的特性如表1所示。

交通大数据处理平台面对海量数据，系统不能仅依靠少数几台机器的升级（Scale-up，纵向扩展）满足数据量的增长，必须做到横向可扩展（Scale-out），既满足性能的要求，也满足存储的要求（包括结构性数据、非结构形式、半结构性数据）；由于服务需求的多样性，平台既要支持交通数据流的实时分析与处理又要支持复杂查询与深度分析所需的高性能、低延迟需求。平台需具有高度容错性，大数据的容错性要求在作业（Job）执行过程中，一个参与节点失效不需要重做整个作业。机群节点数的增加会增加节点失效概率，在大规模机群环境下，节点的失效不再是稀有事件，因此在大规模机群环境下，系统不能依赖于硬件来保证容错性，要更多地考虑软件级容错，同时增加系统的可用性。系统的开放性也是十分重要的，在下一小节会知道ITS是一个巨系统，各子系统之间数据交换、共享以及服务集成是必不可少的，同时要求系统支持迭代开发，可不断更新/增加功能；系统服务不但专业人员可以使用，业务人员也可以使用，分析可以实现大众化。

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

另外，平台应支持异构环境。交通大数据平台的建设是分步骤、分阶段进行的，设备的采购、更新会造成硬件系统的异构，建设同构大规模机群难度较大；另外，对异构环境的支持可以有效地利用历史上积累的计算机资源，降低硬件成本的投入。

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

ITS是一个复杂的巨系统。中国ITS体系框架确定了以下内容：用户服务包括9个服务领域、47项服务、179项子服务；逻辑框架包括10个功能领域、57项功能、101项子功能、406个过程、161张数据流图；物理框架包括10个系统、38个子系统、150个系统模块、51张物理框架流图；应用系统有58个。ITS内容庞多、结构复杂、技术含量高，需要多个领域、多个部门的长期合作。ITS涉众面广，包括政府部门、企业、公众，由此决定了其信息服务需求的多样性：交通指挥部门需要实时连续交通监控（如流量、平均车速、饱和度、占有率等）；城市规划部门需要当前和历史路网交通流和交通需求数据；出行者需要即席查询交通信息等。因此，涉及交通数据流实时分析处理（RTAP）、联机事务处理（OLTP）、联机分析处理（OLAP）、联机分析与挖掘（OLAM）等功能。

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

为此，构建交通大数据分析与处理平台需要结合分布式并行处理技术与实时数据流处理技术。其逻辑功能框架如图2所示。层次功能结构逻辑如图右半部分所示，自底向上分别是分布式存储层、分布式处理层、元数据服务层、处理分析层（包括复杂事件处理CEP、实时分析处理RTAP、联机分析处理OLAP、深度分析OLAM）以及交通大数据分析处理应用层；同时，需要对分布式系统进行作业、资源调度、管理的协调与监控中间件的支持，支持工作流及其调度的设施。而在图2左半部分则展示了交通大数据分析与处理平台的部件结构图，在逻辑上可划分为实时数据流处理子系统与大数据深度分析（知识获取与模式发现）子系统。

实时数据流处理子系统接受实时交通数据流，数据流元组记录随时间变化的空间（如位置、区域等）信息、以及车牌、卡口、速度等属性数据或视频、图像数据，具有动态、海量、高维、时效、连续、多源、无限等特性。该子系统是实现实时交通监控系统的数据基础，能够为指挥调度、道路规划、事故预警等交通信息管理和决策提供支持，为交通用户提供更为全面和便捷的服务。该子系统包含数据流管理系统，提供对数据流的连续查询和混合查询支持。连续查询用于实时持续不断地监控，如“查询超速的车辆信息”以及“开始监控违法车辆行踪”是连续运行的查询，后者涉及空间数据库。用户可以指定连续查询的滑动时间窗口，对于进入窗口且符合查询条件的事件进行报警监控。混合查询用于那些不仅需要涉及动态流数据还需要访问静态历史和空间数据的复杂查询，如“统计未来5分钟内从西湖区流出的车流量”。

深度分析子系统运用各种先进的数据处理技术，包括数据集成技术、人工智能与数据挖掘技术、决策支持与专家系统等，根据各交通子系统的需求和它们之间的内在联系，对来自多来源渠道、格式不一致的数据在综合交通信息的基础上进行抽取、集成，并进行深度分析与处理，获得可用于决策的模式、模型、规则和知识。需要改造传统的数据挖掘、机器学习算法，以适应大数据的需要。

平台对外提供各种交通信息服务，实现多种模式交通信息发布，包括Web交通信息服务、电台电视台、交通服务咨询热线、手机与车载导航等移动终端、触摸屏查询终端、可变情报板、交通指南等载体的交通信息发布。各种应用与服务之间通过一个统一的服务接口进行连接，服务接口向上层应用提供一致的调用接口，屏蔽底层细节，它是一个接口规范，用以隔离应用与服务，实现两者的独立性，以期达到平台功能扩展的灵活性。平台的数据则来自ITS交通数据采集监控网，该层包括网络层（信息传输）和感知层（信息感知与获取）。

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

本节阐述在当前计算技术下的一个可能的平台方案。据前述，平台必须具有高度可扩展性、实时性、高性能、低延迟分析、高度容错性、可用性、支持异构环境、开放性、易用性，同时也希望具有较低成本；其核心技术包括大规模数据流处理技术以及大规模数据管理、分析技术。这要求我们在进行平台构建时作出合理的决策。

对大数据进行分析的基本策略是把计算推向数据，而不是移动大量的数据；对大数据处理、分析的性能优化，分布式并行是必然选择，并且软件系统性能的提升可以降低企业对硬件的投入成本、节省计算资源，提高系统吞吐量；但异构节点之间的性能差异可能导致系统“木桶效应”，因此，异构机群需要特别关注负载均衡、任务调度等方面的设计；交通数据量及其多样性给数据管理系统提出了新的要求，在存储以及处理方式需要具备较好的扩展性，无共享结构（Sharednothing）的存储方式是较好的候选方案，传统数据库缺少水平扩展的能力，在系统设计决策中根据数据大小、性能瓶颈、处理能力等因素决定哪些数据由传统数据库来管理，哪些数据应当由新出现的NoSQL（Not only SQL）存储管理系统来管理。

交通大数据分析平台

根据以上分析，新近云计算是一种可选方案。云计算是分布式处理、并行处理和网格计算的发展，是这些计算机科学概念的商业实现，具有分布式、大规模、虚拟化、高可靠性、通用性、高可扩展性、低廉等特点，它实现对共享可配置计算资源（包括网络、服务器、存储、应用和服务等）的按需服务。云计算中的平台（集群计算框架）有谷歌的MapReduce与微软的Dryad等，而Hadoop是一个实现了MapReduce的开源分布式并行编程框架；专门针对迭代计算的编程框架有Pregel、HaLoop等，前者是一个迭代图形计算系统，后者提供了一个迭代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基于只读的，不适用于事务处理的场景。在平台构建中涉及分布式存储系统的选择。在分布式系统中，一致性（即所有节点访问同一份最新的数据副本）、可用性（即对数据更新具备高可用性）、分区容忍性（即能容忍网络分区），这三个要素最多只能同时实现两个，这就是周知的CAP理论。但通过显式处理分区情形，系统设计师可以通过细致地管理分区期间的不变性约束优化数据的一致性和可用性，对三者进行平衡。CAP的C仅指单一副本这个意义上的一致性，因此只是ACID一致性约束的一个严格的子集。ACID一致性不可能在分区过程中保持，因此分区恢复时需要重建ACID一致性。CAP理论的可视化图解见图4。而NoSQL一般放弃ACID事务策略的一致性，而是采用BASE（基本可用、事务软状态以及最终一致性）事务策略以换取高可用性和可伸缩性。NoSQL存储系统可分为键－值存储（如Redis, Tokyo Cabinet）、列存储（如HBase, Cassandra）、文档数据库（如MongoDB, CouchDB）、图数据库（如neo4j, FlockDB）等；对于具体应用，应当根据需要支持的数据模型、一致性机制、存储机制、持久性保障、事务支持、可用性、查询能力、性能保障等方面来选择相应的NoSQL存储系统，不可一概而论。据统计，目前NoSQL存储系统有150种之多。

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

图4 CAP理论的可视化图解

实时数据流处理子系统

实时性是交通数据处理的关键也是其价值得以实现的基础。如交通流的实时监控、交通拥堵状况的实时信息、交通诱导等应用均要求系统能够返回当前的交通状态；在另一些场景则需要进行连续监控，在技术上涉及连续查询。这方面的功能需求已在第二节讲述。在构建交通大数据处理平台中，实时交通数据流处理子系统是关键系统之一。该系统中涉及的关键技术包括：高速数据转换，将获取的事件数据流由随机访问格式转换为分布式并行分析格式，将几分钟前获取的交通数据即时处理呈现最新分析结果；灵活的资源分配方案，不同类型的数据处理组件（即事件处理服务）与可伸缩分布式键值存储灵活连接，可以便捷地构造新的服务而不影响现有系统的运行；基于滑动窗口的连续计算技术；自适应负载平衡与资源分配优化。

开源的分布式实时流计算框架有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（作业或应用）如图4所示。相应地，基于Storm的交通数据流处理逻辑以及软件结构分别如图5与图6所示。

图1 一个Storm的Topology结构

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

在一个基于Storm的交通数据处理集群中，有主从两种不同的节点，三种不同的守护进程：Nimbus运行在主节点上，类似于Hadoop中的Jobtracker，主要负责接收客户端提交的Topology，进行相应的验证，分配任务，进而把任务相关的元数据写入Zookeeper相应目录，此外，Nimbus还负责通过Zookeeper来监控任务执行情况，负责全局任务调度。从节点上运行Supervisor，类似于TaskTracker，管理本地节点的任务，负责会监听任务分配情况，根据实际情况启动/停止工作进程（worker）。每个从节点上运行进程worker，类似于Hadoop中的map/reduce的任务，worker进行Spout/Bolt数据处理。不同于map/reduce任务，worker是连续计算，不会停止。不同于Hadoop，守护进程间并不直接发送心跳信息或者存在其他RPC控制协议，他们之间的信息交换是通过Zookeeper来实现。其中Storm处理框架的处理结果可以在分布式存储系统中持久化存储。

资源统一管理与调度

交通大数据处理与分析平台涉及多种不同类型的应用，如本文所讲述的脱机应用（数据分析、数据挖掘）和联机应用（数据流实时处理），不同的应用可能采用了不同的计算框架。为提高资源利用率、降低运维成本，将不同计算框架部署到公共的集群中，对资源（内存，CPU，网络IO等）统一管理与调度，让不同计算框架共享集群资源。目前，这方面典型代表有Mesos和YARN。本文采用Mesos构建资源共享平台，如图8所示。

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

Mesos是一种让多个计算框架有效共享机群资源的可伸缩弹性的“核心”集群资源管理器。它通过定义多个计算框架进行资源共享的最小接口，把任务调度与执行控制交给各个计算框架来负责。有利于适应机群框架的多样性和快速演化性。Mesos由master进程和框架组成。master进程负责管理运行于机群节点上的slave守护进程，框架在slave节点上运行任务。master进程通过资源供应方式实施个计算框架之间的资源共享。每一份资源供应是各slave节点空闲资源表。master进程采用某种策略（平等分享、优先共享等）决定分配多少资源给每个框架。每个运行于Mesos之上的计算框架均包含两个组件：调度器和执行器。特定计算框架通过自身的调度器向master进程注册，选择是否接受master提供的资源，接受多少；而slave节点上的执行器（如Hadoop的执行器即TaskTracker）运行框架的任务（task）。

原型系统实验

根据本文的论述，我们构建相应交通大数据处理与分析平台进行原型验证，分别构建了Hadoop和Storm集群对平均行车速度这个指标的计算。实验所采用的设备规格说明如表2所示。为每个虚拟节点分配了一个虚拟CPU、2GB内存、30GB外存，操作系统是CentOS6.2。

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

交通大数据分析实验平台

所构分析平台采用Hadoop-0.20.2-CDH。实验中所产生卡口仿真数据是指某个卡口某个时刻车辆通行的瞬时车速，产生了8GB 共399000000条记录的卡口数据。相应作业采用Java语言实现，计算给定数据集的平均速度。实验中计算所用时间是557秒。

实时交通数据流实验平台

所构实验平台使用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机群的运行结果

五、结论

本文围绕如何构建交通大数据处理平台开展讨论，主要从方法论角度展开论述。首先，对平台需求及其逻辑框架进行了讨论，提出了相应的方案，讲述了其涉及的核心技术；其次，提出了针对交通大数据分析平台以及交通数据流计算的实时计算平台一种可行构建方案；最后，通过原型系统论证了方案的可行性。目前，我们开展了前期的研究，没有涉及系统、代码的优化，也没有涉及具体业务子系统的构建细节。下一步将进行实际运行系统的构建，开展更深入一步的工作，包括实时交通数据流处理算法、交通大数据分析算法等方面的理论与实现技术的研究。