1、智能交通大数据 综合 服务平台 1. 概述 随着经济发展、城市化进程的加快以及城市规模不断扩大，机动车拥有量及道路交通流急剧增加，城市紧缺的土地资源和高密度的土地利用模式，使得交通供给与交通需求之间的矛盾日益突出，交通拥堵、停车困难、环境恶化等交通问题不断加剧，影响了城市的可持续发展及人民生活水平的提高，阻碍了经济的发展。 大城市 也面临同样的问题，近年来机动车保有量持续快速增长，高峰交通拥堵日益加剧，交通发展面临严峻形势和新的挑战。 很多城市 在市区主要范围内实施“错峰限行”等交通管理措施。采取调控交通需求削减交通需求总量其原因之一是 城市 道路 已经难以通过基础设施规划建设来改善交通。另一
2、方面 ,如何利用智能交通系统 (ITS)来缓解交通、提升交通效率也是可以着力的一个方向。 目前 各 交通管理部门建立了功能相对完善的交通指挥控制中心，包括交通信号控制系统、道路交通监控系统、交通诱导显示系统、停车管理系统、交通违章处理系统等，初步实现了交通信号控制 、道路监控、交通信息综合查询、有 /无线指挥调度及交通诱导等基础功能。 ITS 的各种信息采集技术（如微波采集技术、视频采集技术、环形线圈感应式采集技术等）被广泛地运用于交通数据采集，公安交管部门不仅具备了交通基础信息，还拥有了各类动态数据，如车辆实时营运信息、道路交通状况等，采集的数据类型包括属性数据、空间数据、影像数据等。对交通
3、三要素（人流、车辆、道路）连续不断采集的多源交通数据流产生了巨量的交通数据，具有典型的“ 3V”特性：大容量、多样性、高速度，也具有价值、复杂性的特点，属于名符其实的交通“大数据”。仅以 国内 某 城市 内道路卡口数据为例，每天达到约 15GB 的数据量，要实现对城市道路交通的整体运营水平和人们出行规律的深度挖掘，就要以日、月甚至年为时间粒度对大数据进行计算和分析。 数据是智能交通的核心，数据为王的大数据时代已经到来 。如何高效地从海量数据中分析、挖掘所需的信息和规律，结合已有经验和数学模型等生成更高层次的决策支持信息，获得各类分析、评价数据，为交通诱导、交通控制、交通需求管理、紧急事件管理等
4、提供决策支持，为交通管理者、运营者和个体出行者提供交通信息，成为当务之急。交通数据分析的发展趋势正如 TDWI 大数据分析报告指出的，由常规分析转向深度分析，如图 1 所示。 图 1分析的趋势 在交通数据分析方面，生昕格 7交流了交通云数据处理平台的一个具体应用实例，该平台基于廉价计算机构建集群，用 Hbase 存储大数据，采用 MapReduce进行分布式计算； Chen 等 8利用 MapReduce 框架对交通流预测；李磊等 9论述了基于云计算的铁路数据中心的逻辑结构。这些工作没有涉及交通大数据处理平台需要面对的各种应用场景以及系统构建应遵循的原则，如没有涉及实时数据流处理问题。面对交通
5、大数据，如何存储、组织和管理并提供服务是 ITS 面临的一个挑战。本文针对如何构建交通大数据处理平台开展研究，主要从使能技术方面展开论述，不对具体业务系统进行评述。 2. 交通大数据处理平台的功能需求及其逻辑框架 本节通过介绍智能交通系统大数据的特点 以及提供服务的要求分析了交通大数据分析平台需具备的特点，提出了交通大数据处理平台逻辑框架，并进一步阐述了平台构建的基本原则建议。 2.1 交通大数据处理平台需具备的特性 如前所述，交通服务要提供全面的路况，需要交通综合监测网络对城市道路交通状况、交通流信息、交通违法行为等的 全面监测，采集、处理 及分析大量的实时监测数据，具有数据量巨大的特点；随
6、着 城市机动车保有量 不断提高，城市道 路交通状况日趋复杂化 ，交通流特性呈现随时间变化大、 区域关联性强 的特点，需要根据实时的交通流数据及时全面采集、处理、分析等，因此具有系统负载时变性高、波动大的特点，应支持低延时、高并发事务；公众出行服务对交通信息发布的时效性要求高 ，需将准确的信息及时提供给不同需求的主体，信息处理、分析实时性要求高； ITS 需面向政府、社会和公众提供交通服务，为出行者提供安全、畅通、高品质的行程服务，保障交通运输的高安全、高时效和高准确性，要求 ITS 应用系统具有高可用性和高稳定性。这给交通大数据处理平台提出了挑战，平台需满足的特性如表 1 所示。 交通大数据处
7、理平台面对海量数据，系统不能仅依靠 少数几台机器的升级(Scale-up，纵向扩展 )满足数据量的增长， 必须做到横向可扩展 (Scale-out)，既满足性能的要求，也满足存储的要求（包括结构性数据、非结构形式、半结构性数据）；由于服务需求的多样性，平台既要支持 交通数据流的实时分析 与处理又要 支持复杂查询与深度分析 所需的高性能、低延迟需求。平台需具 有高度容错性 ，大数据的容错性要求在作业 (Job)执行过程中，一个参与节点失效不需要重做整个作业。机群节点数的增加会增加节点失效概率，在大规模机群环境下，节点的失效不再是稀有事件，因此在大规模机群环境下，系统不能依赖于硬件来保证容错性，要
8、更多地考虑软件级容错，同时增加系统的可用性。系统的开放性也是十分重要的，在下一小节会知道 ITS 是一个巨系统，各子系统之间数据交换 、共享以及服务集成是必不可少的，同时要求系统支持迭代开发，可不断更新 /增加功能；系统服务不但专业人员可以使用，业务人员也可以使用，分析可以实现大众化。 另外，平 台应支持异构环境 。交通大数据平台的建 设是分步骤、分阶段进行的，设备的采购、更新会造成硬件系统的异构，建设同构大规模机群难度较大；另外，对异构环境的支持可以有效地利用历史上积累的计算机资源，降低硬件成本的投入。 表 1交通大数据处理平台需具备的特性 特性 简要说明 高度可扩展性 横向大规模可扩展，大
9、规模并行处理 实时性 对交通数据流、事件的实时处理 高性能、低延迟分析 快速响应复杂查询与深度分析、实时分析结果 高度容错性 系统在硬件级、软件级实现容错 可用性 系统具有相当高的可靠性 支持异构环境 对硬件平台一致性要求不高，适应能力强 开放性、易用性 系统之间可实现数据共享、服务集成 较低成本 较高的性价比 2.2 交通大数据分析平台逻辑框架 ITS 是一个复杂的巨系统。中国 ITS 体系框架 6确定了以下内容：用户服务包括 9 个服务领域、 47 项服务、 179 项子服务；逻辑框架包括 10 个功能领域、57 项功能、 101 项子功能、 406 个过程、 161 张数据流图；物理框架
10、包括 10 个系统、 38 个子系统、 150 个系统模块、 51 张物理框架流图；应用系统有 58 个。 ITS内容庞多、结构复杂、技术含量高，需要多个领域、多个部门的长期合作。 ITS涉众面广，包括政府部门、企业、公众，由此决定了其信息服务需求的多样性：交通指挥部门需要实时连续交通监控（如流量、平均车速、饱和度、占有率等）；城市规划部门需要当前和历史路网交通流和交 通需求数据；出行者需要即席查询交通信息等。因此，涉及交通数据流实时分析处理（ RTAP）、联机事务处理（ OLTP）、联机分析处理（ OLAP）、联机分析与挖掘（ OLAM）等功能。 图 2 大数据分析与处理平台通用体系结构 为
11、此，构建交通大数据分析与处理平台需要结合分布式并行处理技术与实时数据流处理技术。其逻辑功能框架如图 2 所示。层次功能结构逻辑如图 2 右半部分所示，自底向上分别是分布式存储层、分布式处理层、元数据服务层、处理分析层（包括复杂事件处理 CEP、实时分析处理 RTAP、联机分析处理 OLAP、深度分析 OLAM）以及交通大数据分析处理应用层；同时，需要对分布式系统进行作业、资源调度、管理的协调与监控中间件的支持，支持工作流及其调度的设施。而在图 2 左半部分则展示了交通大数据分析与处理平台的部件结构图，在逻辑上可划分为实时数据流处理子系统与大数据深度分析（知识获取与模式发现）子系统。 实时数据流
12、处理子系统接受实时交通数据流，数据流元组记录随时间变化的空间（如位置、区域等）信息、以及车牌、卡口、速度等属性数据或视频、图像数据，具有动态、海量、高维、时效、连续、多源、无限等特性。该子系统是实现实时交通监控系统的数 据基础，能够为指挥调度、道路规划、事故预警等交通信息管理和决策提供支持，为交通用户提供更为全面和便捷的服务。该子系统包含数据流管理系统，提供对数据流的连续查询和混合查询支持。连续查询用于实时持续不断地监控，如“查询超速的车辆信息”以及“开始监控违法车辆行踪”是连续运行的查询，后者涉及空间数据库。用户可以指定连续查询的滑动时间窗口，对于进入窗口且符合查询条件的事件进行报警监控。混
13、合查询用于那些不仅需要涉及动态流数据还需要访问静态历史和空间数据的复杂查询，如“统计未来5 分钟内从西湖区流出的车流量”。 深度分析子 系统运用各种先进的数据处理技术，包括数据集成技术、人工智能与数据挖掘技术、决策支持与专家系统等，根据各交通子系统的需求和它们之间的内在联系，对来自多来源渠道、格式不一致的数据在综合交通信息的基础上进行抽取、集成，并进行深度分析与处理，获得可用于决策的模式、模型、规则和知识。需要改造传统的数据挖掘、机器学习算法，以适应大数据的需要。 平台对外提供各种交通信息服务，实现多种模式交通信息发布，包括 Web 交通信息服务、电台电视台、交通服务咨询热线、手机与车载导航等
14、移动终端、触摸屏查询终端、可变情报板、交通指南等载体 的交通信息发布。各种应用与服务之间通过一个统一的服务接口进行连接，服务接口向上层应用提供一致的调用接口，屏蔽底层细节，它是一个接口规范，用以隔离应用与服务，实现两者的独立性，以期达到平台功能扩展的灵活性。平台的数据则来自 ITS 交通数据采集监控网，该层包括网络层（信息传输）和感知层（信息感知与获取）。 3. 交通大数据处理平台的构建 本节阐述在当前计算技术下的一个可能的平台方案。据前述，平台必须具有高度可扩展性、实时性、高性能、低延迟分析、高度容错性、可用性、支持异构环境、开放性、易用性，同时也希望具有较低成本；其核心技术包括大规模数据流
15、处理技术以及大规模数据管理、分析技术。这要求我们在进行平台构建时作出合理的决策。 对大数据进行分析的基本策略是把计算推向数据，而不是移动大量的数据；对大数据处理、分析的性能优化，分布式并行是必然选择，并且软件系统性能的提升可以降低企业对硬件的投入成本、节省计算资源，提高系统吞吐量；但异构节点之间的性能差 异可能导致系统“木桶效应”，因此，异构机群需要特别关注负载均衡、任务调度等方面的设计；交通数据量及其多样性给数据管理系统提出了新的要求，在存储以及处理方式需要具备较好的扩展性，无共享结构(Shared-nothing)的存储方式是较好的候选方案，传统数据库缺少水平扩展的能力，在系统设计决策中根
16、据数据大小、性能瓶颈、处理能力等因素决定哪些数据由传统数据库来管理，哪些数据应当由新出现的 NoSQL11 (Not only SQL)存储管理系统来管理。 3.1 交通大数据分析平台 根据以上分析，新近云计算是一种可选方案。云计算是分布式处理、并行处理和网格计算的发展，是这些计算机科学概念的商业实现，具有分布式、大规模、虚拟化、高可靠性、通用性、高可扩展性、低廉等特点，它实现对共享可配置计算资源（包括网络、服务器、存储、应用和服务等）的按需服务。云计算中的平台（集群计算框架）有谷歌的 MapReduce12与微软的 Dryad13等，而 Hadoop 是一个实现了 MapReduce 的开源
17、分布式并行编程框架；专门针对迭代计算的编程框架有 Pregel14、 HaLoop15等，前者是一 个迭代图形计算系统，后者提供了一个迭代 MapReduce 接口。基于 Hadoop 的应用可以运行于机群上，实现对海量数据的处理。此外， Hadoop 平台已经形成了一个生态系统，提供一个分布式文件系统 (HDFS）， HBase 是基于 HDFS 的对 BigTable 的开源实现，是面向列、可伸缩的分布式存储系统，支持事务以及 B 树范围查询和排序； Hive 是基于 Hadoop的大型数据仓库，其目标是简化 Hadoop 上的数据聚集、即席查询及大数据集的分析等操作，以减轻程序员的负担；
18、 Pig 是 Yahoo!提出的类似于 Hive 的大数据集分 析平台 ,它提供的类 SQL 语言叫 Pig Latin，一种基于操作符的数据流式的接口 ,该语言的编译器会把类 SQL 的数据分析请求转换为一系列经过优化处理的MapReduce 运算； Mahout 是可伸缩的机器学习算法；工具 Sqoop 用于传统数据库和 HDFS 进行数据交换； Oozie 是工作流调度工具； ZooKeeper 是一个分布式的应用程序协调器，它包含一个简单的原语集，分布式应用程序可以基于它实现同步服务，配置维护和命名服务等。基于 Hadoop 的大数据分析平台构建如图 3所示。需要注意的是， Hadoo
19、p 适用于长顺序扫描，基于 Hadoop 的 Hive 会导致较高的延迟，因此不适用于需要快速响应的场景； Hive 基于只读的，不适用于事务处理的场景。 图 3 大数据分析与处理平台的一个实例 图 4 CAP理论的可视化图解 在平台构建中涉及分布式存储系统的选择。在分布式系统中，一致性 (即所有节点访问同一份最新的数据副本 )、可用性 (即对数据更新具备高可用性 )、分区容忍性 (即能容忍网络分区），这三个要素最多只能同时实现两个，这就是周知的 CAP 理论 10。但通过显式处理分区情形，系统设计师可以通过细致地管理分区期间的不变性约束优化数据的一致性和可用性，对三者进行平衡。 CAP 的
20、C仅指单一副本这个意义上的一致性，因此只是 ACID 一致性约束的一个严格的子集。 ACID 一致性不可能在分区过程中保持，因此分区恢复时需要重建 ACID 一致性。 CAP理论的可视化图解见图 4。而 NoSQL一般放弃 ACID事务策略的一致性，而是采用 BASE(基本可用、事务软状态以及最终一致性 )事务策略以换取高可用性和可伸缩性。 NoSQL 存储系统可分为键值存储 (如 Redis, Tokyo Cabinet)、列存储 (如 HBase, Cassandra)、文档数据库 (如 MongoDB, CouchDB)、图数据库 (如neo4j, FlockDB)等；对于具体应用，应当
21、根据需要支持的数据模型、一致性机制、存储机制、持久性保障、事务支持、可用性、查询能力、性能保障等方面来选择相应的 NoSQL 存储系统，不可一概而论。据统计，目前 NoSQL 存储系统有150 种之多。 3.2 实时数据流处理子系统 实时性是交通数据处理的关键也是其价值得以实现的基础。如交通流的实时监控、交通拥堵状况的实时信息、交通诱导等应用均要求系统能够返回当前的交通状态；在另一些场景则需要进行连续监控，在技术上涉及连续查询。这方面的功能需求已在第二节讲述。在构建交通大数据处理平台中，实时交通数据流处理子系统是关键系统之一。该系统中涉及的关键技术包括：高速数据转换，将获取的事件数据流由随机访
22、问格式转换为分布式并行分析格式，将几分钟前获取的交通数据即时处理呈现最新分析结果；灵活的资源分配方案，不同类型的数据处理组件（即事件处理服务）与可 伸缩分布式键值存储灵活连接，可以便捷地构造新的服务而不影响现有系统的运行；基于滑动窗口的连续计算技术；自适应负载平衡与资源分配优化。 开源的分布式实时流计算框架有 Twitter 的 Storm、 Yahoo！的 S4、基于 Hadoop的 HStreaming、 专门进行复杂事件处理和事件流处理的 Esper 等 。 Storm具有高容错性、水平扩展性好、快速、可靠处理消息等优点； S4 目前还处于半成品阶段，代码成熟度底，不支持动态部署； St
23、orm 支持节点在集群中动态增加或移除， S4 不支持； Storm 属于全内存计算，所需的内存资源多， HStreaming介于半内存和全磁盘计算，速度相对慢。本文以 Storm 为例来阐述交通数据实时平台的构建。 Storm 采用创建拓扑结构 (topology)来转换数据流，不同于 Hadoop 作业，这些转换会持续处理到达的数据。 Storm 为流转换提供的基本组件有：喷口 (Spout)和螺栓 (Bolt)。 Spout 是一个输入流 组件，负责将数据分发到多个 Bolts 执行处理任务 (如过滤、聚合、查询等 )， Bolts 执行 后可产生新的流作为下级 Bolts 的输入流。由
24、此形成的 整个处理结构即为一个 Topology(作业或应用 )如图 5 所示 。相应地，基于 Storm 的交通数据流处理逻辑以及软件结构分别如 图 6 与 图 7 所示。 图 5 一个 Storm的 Topology结构 图 6基于 Storm交通数据流处理逻辑框架 图 7 Storm交通数据流处理的软件结构 在一个基于 Storm 的交通数据处理集群中，有主从两种不同的节点，三种不同的守护进程： Nimbus 运行在主节点上，类似于 Hadoop 中的 Jobtracker，主要负责接收客户端提交的 Topology，进行相应的验证，分配任务，进而把任务相关的元数据写入 Zookeepe
25、r 相应目录，此外， Nimbus 还负责通过 Zookeeper 来监控任务执行情况，负责全局任务调度。从节点上运行 Supervisor，类似于TaskTracker，管理本地节点的任务，负责会监听任务分配情况，根据实际情况启动 /停止工作进程（ worker）。每个从节点上运行进程 worker，类似于 Hadoop中的 map/reduce 的任务， worker 进行 Spout/Bolt 数据处理。不同于 map/reduce任务， worker 是连续计算，不会停止。不同于 Hadoop，守护进程间并不直接发送心跳信息或者存在其他 RPC 控制协议，他们之间的信息交换是通过 Zo
26、okeeper来实现。其中 Storm 处理框架的处理结果可以在分布式存储系统中持久化存储。 3.3 资源统一管理与调度 交通大数据处理与分析平台涉及多种不同类型的应用，如本文所讲述的脱机应用（数据分析、数据挖掘）和联机应用（数据流实时处理），不同的应用可能采用了不同的计算框架。为提高资源利用率、降低运维成本，将不同计算框架部署到公共的集群中，对资源（内存， CPU，网络 IO 等）统一管理与调度，让不同计算框架共享集群资源。目前，这方面典型代表有 Mesos16和 YARN。本文采用Mesos 构建资源共享平台，如图 8 所示。 图 8 基于 Mesos平台的资源共享体系结构 16 Meso
27、s 是一种让多个计算框架有效共享机群资源的可伸缩弹性的“核心”集群资源管理器。它通过定义多个计算框架进行资源共享的最小接口，把任务调度与执行控制交给各个计算框架来负责。有利于适应机群框架的多样性和快速演化性。 Mesos 由 master 进程和框架组成。 master 进程负责管理运行于机群节点上的slave 守护进程，框架在 slave 节点上运行任务。 master 进程通过资源供应方式实施个计算框架之间的资源共享。每一份资源供应是各 slave 节点空闲资源表。master 进程采用某种策略（平等分享、优先共享等）决定分配多少资源给每个框架。每个运行于 Mesos 之上的计算框架均包含
28、两个组件：调度器和执行器。特定计算框架通过自身的调度器向 master 进程注册，选择是否接受 master 提供的资源，接受多少；而 slave 节点上的执行器（如 Hadoop 的执行器即 TaskTracker）运行框架的任务（ task）。 4. 原型系统实验 根据本文的论述，我们构建相应交通大数据处理与分析平台进行原型验证，分别构建了 Hadoop 和 Storm 集群对平均行车速度这个指标的计算。实验所采用的设备规格说明如表 2 所示。为每个虚拟节点分配了一个虚拟 CPU、 2GB 内存、30GB 外存，操作系统是 CentOS6.2。 表 2 实验所用设备规格说明 型号 CPU
29、内存 存储 VCPU/VMem/VDisk 关联虚拟机节点 Dell Inc.戴尔PowerEdge R910 6CPU 24 核 64G 500G 1/2G/30G master,slave1 Dell Inc.戴尔PowerEdge R910 6CPU 24 核 64G 500G 1/2G/30G slave2,slave3 4.1 交通大数据分析实验平台 所构分析平台采用 Hadoop-0.20.2-CDH。实验中所产生卡口仿真数据是指某个卡口某个时刻车辆通行的瞬时车速，产生了 8GB 共 399000000 条记录的卡口数据。相应作业采用 Java 语言实现，计算给定数据集的平均速度。
30、实验中计算所用时间是 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 与
31、Bolts 个数。在并行度上，在集群配置允许的情况下， Spout 的并行度越高，产生结果时间越短。但如果 spout 并行度超出了集群配置的允许范围， Spout 高并行度并不能缩短产生结果时间，反而很有可能延长产生结果时间。由结果可知，原型系统可以每秒处理 1 万条以上卡口数据。 表 3 Storm机群的运行结果 编号 Topology 名称 执行器中任务数 卡口记录数（万） 整体运行时间 Spouts Bolts 1 es 10 27 100 1m33s 2 fs 5 27 100 1m40s 3 gs 10 27 200 2m37s 4 hs 10 27 500 6m3s 5 js 10 27 1000 9m33s 5. 结论 本文围绕如何构建交通大数据处理平台开展讨论，主要从方法论角度展开论述。首先，对平台需求及其逻辑框架进行了讨论，提出了相应的方案，讲述了其涉及的核心技术；其次，提出了针对交通大数据分析平台以及交通数据流计算的实时计算平台一种可行构建方案；最后，通过原型系统论证了方案的可行性。目前，我们开展了前期的研究，没有涉及系统、代码的优化，也没有涉及具体业务子系统的构建细节。下一步将进行实际运行系统的构建，开展更深入一步的工作，包括实时交通数据流处理算法、交通大数据分析算法等方面的理论与实现技术的研究。
