大数据处理技术在智能交通中的应用.docx
《大数据处理技术在智能交通中的应用.docx》由会员分享，可在线阅读，更多相关《大数据处理技术在智能交通中的应用.docx（12页珍藏版）》请在冰豆网上搜索。
大数据处理技术在智能交通中的应用
大数据处理技术在智能交通中的应用
1. 引言
当前各种交通信息采集技术（如微波、视频、环形感应线圈等）已被广泛地运用于城市、高速等交通路段或卡口，并且这些交通信息采集系统每天都会产生海量的实时交通数据。
实时交通数据以数据流的形式记录着随时间变化的空间（位置、区域等）信息REF_Ref353979273\r\h\*MERGEFORMAT[1]，具有大量、连续、不断变化和要求即时响应的特点。
交通领域所涉及的数据具有大数据4VREF_Ref353981853\r\h\*MERGEFORMAT[2]REF_Ref353984272\r\h\*MERGEFORMAT[3]特点：
规模性（volume），数据的规模从TB级别向PB，甚至ZB级别跃进；多样性（variety），除了传统的关系型数据，如视频、音频和图片等非关系型数据量也越来越大；高速性（velocity），大数据处理对时效性的要求非常的高；价值性（value），从海量数据中得到支持决策的信息是一个很大挑战。
如何对TB、PB、ZB级别的交通数据进行准确、高效地处理和分析及预测，做出即时和正确的交通诱导和疏通以有效改善实际交通拥堵状况是目前亟待解决的关键问题。
本文第2节介绍和分析了目前流行的实时大数据处理平台；第3节提出了面向交通大数据的处理平台设计方案；第4节对平均行车速度这个评价指标进行了相应的实验分析；最后，进行了总结。
2. 大数据实时处理技术
随着大数据时代的来临，各种应对大数据处理的解决方案应时代而生，7年前，雅虎创建了一个用于管理、存储和分析大量数据的分布式计算平台Hadoop，它作为一个批处理系统具有吞吐量大、自动容错等优点，目前在海量数据处理方面已得到了广泛应用。
但是，Hadoop本身存在的缺点是不能有效适应实时数据处理需求，为了克服该局限，一些实时处理平台如S4,Storm等随之产生了，他们在处理不间断的流式数据方面有较大的优势，下面将介绍和分析目前比较流行的大数据处理平台。
2.1 Hadoop
Hadoop是一个由Apache基金会开发的分布式系统基础架构REF_Ref355626015\r\h\*MERGEFORMAT[10]，允许用户在不了解分布式底层细节的情况下，开发分布式应用程序。
Hadoop主要由分布式文件系统（HadoopDistributedFileSystem，HDFS）和MapReduce计算框架两部分组成。
HDFS结构如图1所示，三类节点Namenode，Datanode，Client之间的通信都是建立在TCP/IP的基础之上的。
Client执行读或写操作时首先在本机临时文件夹中缓存数据，当缓冲数据块达到设定的Block值（默认64M），Client通知Namenode，Namenode响应Client的RPC请求，将新文件名插入到分布式文件系统结构层次中，并在Datanode中找到存放该数据的Block，同时将该Datanode及对应的数据块信息告诉Client，Client便将数据块写入指定的数据节点。
HDFS有着高容错性的特点，可以部署在低廉的（low-cost）硬件上，并且能提供高传输率（highthroughput）来访问应用程序的数据。
图1HDFS结构图
图2MapReduce框架
MapReduce是一种并行处理模型，主要有两个处理步骤：
map和reduceREF_Ref355625400\r\h\*MERGEFORMAT[9]。
如图2所示工作流程如下。
Map端处理流程如下:
1）计算框架先将要处理的数据进行分片，方便map任务处理。
2）分片完毕后，多台机器就可以同时进行map工作。
map对每条记录的处理结果以的形式输出中间结果，map输出的结果会暂且放在一个环形内存缓冲区中，当该缓冲区快要溢出时，会在本地文件系统中创建一个溢出文件，将该缓冲区中的数据写入这个文件。
3）写入磁盘之前，线程根据reduce任务个数生成相同数量的分区。
当map任务输出记录时，会产生溢出文件，这时需将这些文件合并。
文件不断排序归并后，最后生成一个已分区且有序的数据文件。
最后将相应分区中的数据拷贝给相应的reduce任务。
Reduce端处理流程如下:
1） Reduce会接收到不同map任务传来的数据，如果reduce端接受的数据量相当小，则直接存储在内存中，如果数据量超过了该缓冲区大小的一定比例，则对数据合并后溢写到磁盘中。
2） 随着溢写文件的增多，后台线程会将它们合并成一个更大的有序的文件，然后交给reduce函数处理，reduce函数安装用户定义的业务逻辑对数据进行处理并输出结果。
Hadoop在本质上是一个批处理系统。
数据被引入Hadoop文件系统（HDFS）并分发到各个节点进行处理。
最后将处理结果汇总，生成的结果文件存放在HDFS上。
2.2 Storm
Storm是Twitter开源的分布式实时计算系统REF_Ref354672642\r\h\*MERGEFORMAT[8]，Storm具有高容错性，水平扩展性好，快速，可靠处理消息的优点。
Storm的核心概念是“流（stream）”，流是一个无限的元组序列。
Strom为流转换提供两个基本组件：
“Spouts”和“Bolts”。
Spout是一个输入流组件，Spout将数据传递给另一个组件（Bolt）。
Bolt执行任务并创建新的流作为下一个Bolt的输入流。
整个过程就是一个“topology”REF_Ref355897436\r\h\*MERGEFORMAT[4]如图3中Storm框架图所示。
图3Storm框架原理图
Strom集群有主要有两类节点：
主节点和工作节点。
主节点上运行一个叫做“Nimbus”的守护进程，它负责在集群分发代码、分配任务和故障监测。
而每个工作节点运行一个叫做“Supervisor”的守护进程。
Supervisor监听分配给它任务的机器，根据Nimbus的委派在必要时启动和关闭工作进程，每个工作进程执行topology的一个子集，一个topology由很多运行在机器上的工作进程组成。
Nimbus和Supervisors之间所有的协调工作是通过一个Zookeeper集群，Nimbus的守护进程和Supervisors守护进程的状态维持在Zookeeper中或保存在本地磁盘上。
这意味着Nimbus或Supervisors进程杀掉，而不需要做备份，这种设计结构使得Storm集群具有很高的稳定性。
2.3 S4
S4REF_Ref354673081\r\h\*MERGEFORMAT[5]（SimpleScalableStreamingSystem）是Yahoo的一个开源流计算平台，它是一个通用的、分布式的、可扩展性良好、具有分区容错能力、支持插件的分布式流计算平台。
S4将流的处理分为多个流事件ProcessElement（PE），每个PE唯一处理一种流事件。
S4将用户定制的PE放在名为ProcessingElementContainer（PEC）的容器中。
PEC加上通信处理模块就形成了逻辑主机ProcessingNode（PN）。
PN负责监听事件，PEC接收源event，event经一系列PE处理后，在通信层CommunicationLayer的协助下分发事件或输出事件处理结果。
在分发事件的过程中，S4会通过hash函数，将事件路由到目标PN上，这个hash函数作用于事件的所有已知属性值上。
通信层有“集群管理”，“故障恢复到备用节点”，“逻辑节点到物理节点映射”的作用。
同时通信层还使用一个插件式的架构来选择网络协议，使用zookeeper在S4集群节点之间做一致性协作。
图4S4processingnode结构图
2.4 Hstreaming
HStreaming是一个构建于Hadoop之上的实时分析平台REF_Ref354673171\r\h\*MERGEFORMAT[6]。
HStreaming为Hadoop提供复杂事件处理中间件，为实时低延迟的Hadoop应用程序提供解决方案。
HStreaming提供支持使用高层语言开发流分析程序的组件。
平台使用流增强增版本的ApachePig对数据流的进行加载，处理，存储和管理。
平台支持两种不同数据处理方式：
常规的基于文件的批处理方式和基于流处理方式。
Pig会自动从数据的输入源和相应的子任务调度方式来推断数据处理方式（流或批处理）。
图5HStreaming结构图
HStreaming提供了一个名叫HStream的负载、存储功能函数。
HStream函数能从TCP，UDP或HTTP流中加载数据，并将处理完的数据以HTTP数据流格式进行传输或者以AmazonS3的对象的形式存储。
用户可以设置的一次处理流数据的批量大小REF_Ref354673208\r\h\*MERGEFORMAT[7]。
数据经由MapReduce计算框架处理后会将结果和图表参数传递给VisStream（图标生成组件）生成图表。
HStreaming目前主要利用实时的引擎来处理视频、服务器、传感器以及其他机器上生成的数据流，并完全兼容Hadoop作为一个归档和批量处理系统，对于Hadoop用户，不用做任何改变，HStreaming能够通过利用相同的MapReduce算法和用户已经编写好的Pig脚本进行流处理。
2.5 各大数据处理平台比较
Storm与Hadoop之间的比较：
Hadoop是将大量的离线数据进行数据切片处理，处理前要将处理的数据存放在hdfs上，其优势就是将计算工作放到拥有数据的结点上，提高效率。
Storm则是将要处理的数据放在实时消息队列中的，用户只需写好topology逻辑，然后接收数据来处理。
与Hadoop相比，Storm不用将数据预先存放在文件系统上，就可以直接进行数据实时处理REF_Ref354672642\r\h\*MERGEFORMAT[8]。
Hadoop的优点是处理数据量大，分析灵活，缺点就是慢，具体表现为：
每次执行前要分发jar包，如果map数据超出了阈值，那么Hadoop就会将数据写入本地文件系统，然后在reduce的时候再读进来。
Storm的优点是全内存计算，因为内存寻址速度是硬盘的百万倍以上，所以Storm的速度相比较Hadoop快。
缺点就是需要很多的内存在支持高速计算。
S4和Storm之间的比较：
S4目前还处于半成品阶段，代码成熟度底，不支持动态部署，也没有提供很好的管理界面（如web管理界面）且只支持Java语言开发，相反，Storm的代码成熟度高，开发部署，管理都很方便并支持多语言开发（支持Java,Clojure，其他非JVM语言）。
S4和Storm都不完全支持failover。
在一个服务器故障时，处理自动的转移到稳定的服务器。
在交接中，S4存储在本地内存中的处理状态会丢失，而Storm会将节点处理状态维持在Zookeeper中，虽然两者都会丢失节点上的数据。
Storm支持节点从正在运行的集群中增加或移除，而S4不支持。
Storm与HStreaming之间的比较：
HStreaming在实时Hadoop中功能强大，并支持复杂事件处理（CEP），但其缺乏一些关键解决方案组件包括Hadoop建模工具、设备或云/SaaS版本以及业务应用程序REF_Ref354673171\r\h\*MERGEFORMAT[6]的支持。
相对而言，Storm则较成熟。
Storm属于全内存计算，速度快，但所需的内存资源多，HStreaming基于Hadoop,介于半内存和全磁盘计算，速度相对慢。
3. 面向交通大数据处理解决方案
3.1 总体框架结构设计
交通数据的一个特点就是异构源多、数据量大，例如感应线圈、微波测速、视频监控、红绿灯调控系统等诸多设备每天产生了大量的原始数据。
如何利用好这些多源的大量数据为交通决策与诱导提供便利，有效缓解城市拥堵难题显得尤为有价值。
为此，在综合考虑了交通数据的特性以及应用需求的基础上，本文设计了如图6所示的交通大数据解决方案，该方案是一个基于现有的开源软件、硬件以及应用系统上低成本的可靠的大数据处理平台，所包含的六层结构具体描述如下：
1） 交通异构数据源主要包括感应线圈、微波测速、视频监控、红绿灯调控系统等诸多设备产生的交通数据，根据不同的需求可分为实时处理数据和非实时处理数据。
2） 数据传输和同步层的主要实现数据的同步和数据传输，针对不同的数据特征分为实时数据和非实时数据两种类型。
对于非实时数据，一般用作历史分析或者数据仓库操作，可以采取如Sqoop这样的数据传输工具，完成数据传输和同步的要求。
而对于实时数据，一般采用发布订阅这种方式处理这种流计算数据是比较有效的，类似的工具有TimeTunnel。
3） 数据处理层是大数据处理平台的核心层，为了能够同时应付处理实时数据流以及用作历史分析或者数据仓库的批处理数据，分别设计了两套计算框架：
一种是Hadoop生态系统计算框架。
另一种以Storm为基础的实时计算框架。
实时计算框架和非实时计算框架都有自己相应的任务，这些任务都由集群资源管理器Mesos管理。
4） 数据存储层用于保存数据处理层的最终或临时结果，该层主要有关系型数据库和非关系型数据库适应不同类型的数据。
5） 在存储层之下额外附加了一层——对外接口层，其两个优点一是屏蔽了异构的存储逻辑，使得存储对高层应用透明；另一点则是对不同的组件（比如Impala,Hive等等）使用提供一个封装，对开放人员提供一个统一的接口。
6） 应用层包含一些和交通数据相关的应用，比较常见的有流量分析、实时拥堵预测、交通诱导等。
图6交通大数据处理框架
3.2 数据处理层设计
本节将详细描述数据处理核心层的非实时数据和实时数据处理两种框架的内部结构和
处理过程。
（1）Hadoop批处理平台
Hadoop是目前一种比较成熟的分布式数据处理平台，用来解决传统的大数据处理能力不足。
采用Hadoop平台主要有以下优点：
● 开源的免费软件，易于改造和更新；
● 相对来说比较成熟，XX、淘宝等大公司已经在实际生产环境中已经使用；
● Hadoop分布式平台有许多可以集成在一起的组件，为我们处理交通数据提供了便利。
综合实际情况，可以按以下表1的组合方式构建Hadoop批处理平台。
表1Hadoop批处理平台上的组件
组件
功能
MapReduce
计算框架
Hbase
存储管理提高读写性能
Sqoop
数据抽取
Impala
交互式查询
Hive
数据仓库
图7描述了表1中Hadoop各组件间关系结构。
数据源通过数据抽取工具Sqoop抽取到HDFS上由HBASE数据库来进行管理，批处理任务的具体执行任务从HBASE中提取数据然后进行相应的计算，常见的有MapReduce、Impala等任务。
图7Hadoop批处理平台处理细节
（2）Storm实时处理平台
Storm是Twitter正在使用的实时流计算处理平台，对实时需求高的场合非常适用。
采用Storm作为我们实时计算平台的核心是因为它有如2.5节所说的诸多优点。
图8描述了Storm平台的交通数据处理细节。
图8Storm处理细节
最左侧是数据来源，这些数据来源都是异构的，一种方式自然采取直接从数据源获取的方式，但是这样的方式扩展性和维护性不好，我们在中间增加一个中间件，即封装的一个数据抽取服务，可以看成一个信息队列，流计算框架从这里抽取信息。
而由这个信息队列完成数据抽取的工作。
这个数据抽取的服务即为整体架构中的数据传输平台。
流计算框架再将处理完的数据放入分布式数据库中。
（3）集群资源管理器Mesos
Mesos是一种集群资源管理器。
根据交通数据计算的需要，使用两种类型的计算框架，一种作为离线处理，即Hadoop，主要做一些历史数据分析。
另外一种则是流计算框架，直接对数据源的数据进行处理，然后给出相应结果并进行持久化存储。
采用Mesos的优势主要是以下几点：
● 对资源的高利用率。
● 无需针对不同的计算框架部署两套集群，节约了成本。
Mesos的组成结构如图9所示。
原本框架有本身的调度器来调度任务，资源分配，然后这个功能交给了MesosMaster然后由MesosMaster做出资源分配的方案，交给每个节点上的Slave中的执行器，按Master要求的方法来分配资源，由执行器来完成具体的任务。
图9Mesos组成结构
4. 实验
在本小节中，我们将在Hadoop和Storm集群上对平均行车速度这个评价指标进行计算，表2是实验集群中一个Master节点和三个Slave节点的配置：
表2实验集群配置
名字
CPU（个）
硬盘
操作系统
内存
Master节点
1
30G
CentOS6.2
2G
Slave1节点
1
30G
CentOS6.2
2G
Slave2节点
1
30G
CentOS6.2
2G
Slave3节点
1
30G
CentOS6.2
2G
（1）Hadoop实验平台
在Hadoop的实验中，我们使用的Hadoop版本为Hadoop-0.20.2-CDH。
实验中所用的卡口仿真数据是指：
在某个卡口，某个时刻，车辆经过该卡口点的瞬时速度。
通过对一段时间内，某一卡口点上平均速度的计算，可以得到该卡口点位上那一瞬间的通行情况。
表3Hadoop实验结果
记录数（条）
数据大小（B）
运行时间（s）
399000000
8355840
557
上面中是在Hadoop实验平台上处理大小为8G的文本类型的卡口仿真数据的结果。
从结果中可以看到,该CDH版本的Hadoop在处理8G的数据时要花费的时间为557秒，处理效率较高。
（2）Storm实验平台
实验使用Storm0.8.1版本，其他辅助软件的版本及功能如下，Zookeeper-3.4.5，主要用来实现Nimbus和Supervisor两者间的协调工作，管理集群中的不同组件；ZEROMQ-2.1.7，是内部消息系统，用于节点或进程间的通信，JZMQ是ZEROMQ的JavaBinding。
在Storm集群中，共使用4个Workers，每个Worker有4个Slots。
本实验的仿真功能是对三个卡口点位产生的行车模拟数据计算对应卡口的平均行车速度，同时能将结果保存并实时更新平均行车速度，实验参数见表4所示，处理结果表明Storm展示了很迅速的数据并行处理能力，并且该平台还能实时更新数据结果。
表4Storm实验结果
编号
Topology名称
Numexecutor
记录数（万）
数据大小（B）
运行时间
Spouts
Bolts
1
fs
5
27
100
368539
1m40s
2
es
10
27
100
368533
1m33s
3
gs
10
27
200
748580
2m37s
4
hs
10
27
500
1908536
6m3s
5
js
10
27
1000
3885862
12m30s
5. 总结
本文在分析和比较了目前流行的大数据处理平台和技术的基础上，针对异构交通数据源设计了同时满足批处理和实时处理功能的交通大数据处理平台，并在此框架上对交通大数据进行实验测试和计算，实验结果表明本文提出的框架结构能实时、快速、准确地处理和计算交通大数据各项需求指标。
参考文献
[1] 孟小峰，周龙骧，王珊．数据库技术发展趋势[J]．软件学报，2004，15（12）：
1822—1836．
[2] Grobelnik,Marko.BigDataTutorial[EB/OL].[2012-10-02].
[3] BarwickH.The“fourVs”ofBigData.ImplementingInformationInfrastructureSymposium[EB/OL].[2012-10-02]..au/article/396198/iiis_four_vs_big_data/
[4] JonathanLeibiusky,GabrielEisbruch,DarioSimonassi.GettingStartedwithStorm.[M].[2012-09-17].O'ReillyMedia,Inc,USA．
[5] LeonardoNeumeyer,BruceRobbins,AnishNair,AnandKesari.S4:
DistributedStreamComputingPlatform[J].[2010].ICDMW'10Proceedingsofthe2010IEEEInternationalConferenceonDataMiningWorkshopsPages170-177.
[6] JamesG.Kobielus,StephenPowers,BrianHopkins,BorisEvelson,ShannonCoyne.TheForresterWave:
EnterpriseHadoopSolutions,Q12012[M].[2012].ForresterResearch,Inc.
[7] HStreaming.HStreamingGettingStartedGuide[EB/OL].[2011-12-20].
[8] Strom:
http:
//storm-
[9] JensDittrich.Jorge-ArnulfoQuiane-Ruiz.EfficientBigDataProcessinginHadoopMapReduce[J].[2012-08].ProceedingsoftheVLDBEndowmentVLDBEndowmentHompagearchiveVolume5Issue12,August2012Pages2014-2015
[10] TomWhite.Hadoop权威指南（第二版）[M].[2011-6-1].清华大学出版社
全文完
升级会员 