交通擁堵成為大城市通病，改善城市出行條件已成為當(dāng)務(wù)之急。智能交通系統(tǒng)是緩解交通、提升交通效率的有效手段。數(shù)據(jù)是智能交通的核心，對交通數(shù)據(jù)深度處理與分析是其中關(guān)鍵。

引言

隨著經(jīng)濟(jì)發(fā)展、城市化進(jìn)程的加快以及城市規(guī)模不斷擴(kuò)大，機(jī)動車擁有量及道路交通流急劇增加，城市緊缺的土地資源和高密度的土地利用模式，使得交通供給與交通需求之間的矛盾日益突出，交通擁堵、停車?yán)щy、環(huán)境惡化等交通問題不斷加劇，影響了城市的可持續(xù)發(fā)展及人民生活水平的提高，阻礙了經(jīng)濟(jì)的發(fā)展。杭州市也面臨同樣的問題，近年來機(jī)動車保有量持續(xù)快速增長，高峰交通擁堵日益加劇，交通發(fā)展面臨嚴(yán)峻形勢和新的挑戰(zhàn)。杭州市政府決定自2011年10月在市區(qū)主要范圍內(nèi)實施“錯峰限行”等交通管理措施。采取調(diào)控交通需求削減交通需求總量其原因之一是杭州已經(jīng)難以通過基礎(chǔ)設(shè)施規(guī)劃建設(shè)來改善交通。另一方面,如何利用智能交通系統(tǒng)（ITS）來緩解交通、提升交通效率也是可以著力的一個方向。

目前杭州市交通管理部門建立了功能相對完善的交通指揮控制中心，包括交通信號控制系統(tǒng)、道路交通監(jiān)控系統(tǒng)、交通誘導(dǎo)顯示系統(tǒng)、停車管理系統(tǒng)、交通違章處理系統(tǒng)等，初步實現(xiàn)了交通信號控制、道路監(jiān)控、交通信息綜合查詢、有/無線指揮調(diào)度及交通誘導(dǎo)等基礎(chǔ)功能。ITS的各種信息采集技術(shù)（如微波采集技術(shù)、視頻采集技術(shù)、環(huán)形線圈感應(yīng)式采集技術(shù)等）被廣泛地運(yùn)用于交通數(shù)據(jù)采集，公安交管部門不僅具備了交通基礎(chǔ)信息，還擁有了各類動態(tài)數(shù)據(jù)，如車輛實時營運(yùn)信息、道路交通狀況等，采集的數(shù)據(jù)類型包括屬性數(shù)據(jù)、空間數(shù)據(jù)、影像數(shù)據(jù)等。對交通三要素（人流、車輛、道路）連續(xù)不斷采集的多源交通數(shù)據(jù)流產(chǎn)生了巨量的交通數(shù)據(jù)，具有典型的“3V”特性：大容量、多樣性、高速度，也具有價值、復(fù)雜性的特點，屬于名符其實的交通“大數(shù)據(jù)”。僅以杭州市內(nèi)道路卡口數(shù)據(jù)為例，每天達(dá)到約15GB的數(shù)據(jù)量，要實現(xiàn)對城市道路交通的整體運(yùn)營水平和人們出行規(guī)律的深度挖掘，就要以日、月甚至年為時間粒度對大數(shù)據(jù)進(jìn)行計算和分析。

數(shù)據(jù)是智能交通的核心，數(shù)據(jù)為王的大數(shù)據(jù)時代已經(jīng)到來。李國杰院士指出戰(zhàn)略需求發(fā)生了重大轉(zhuǎn)變，企業(yè)關(guān)注的重點轉(zhuǎn)向數(shù)據(jù)，計算機(jī)行業(yè)正在轉(zhuǎn)變?yōu)檎嬲男畔⑿袠I(yè)，從追求計算速度轉(zhuǎn)變?yōu)榇髷?shù)據(jù)處理能力，軟件也將從編程為主轉(zhuǎn)變?yōu)橐詳?shù)據(jù)為中心。如何高效地從海量數(shù)據(jù)中分析、挖掘所需的信息和規(guī)律，結(jié)合已有經(jīng)驗和數(shù)學(xué)模型等生成更高層次的決策支持信息，獲得各類分析、評價數(shù)據(jù)，為交通誘導(dǎo)、交通控制、交通需求管理、緊急事件管理等提供決策支持，為交通管理者、運(yùn)營者和個體出行者提供交通信息，成為當(dāng)務(wù)之急。交通數(shù)據(jù)分析的發(fā)展趨勢正如TDWI大數(shù)據(jù)分析報告指出的，由常規(guī)分析轉(zhuǎn)向深度分析，如圖1所示。

圖1 分析的趨勢

在交通數(shù)據(jù)分析方面，生昕格交流了交通云數(shù)據(jù)處理平臺的一個具體應(yīng)用實例，該平臺基于廉價計算機(jī)構(gòu)建集群，用Hbase存儲大數(shù)據(jù)，采用MapReduce進(jìn)行分布式計算；Chen等利用MapReduce框架對交通流預(yù)測；李磊等論述了基于云計算的鐵路數(shù)據(jù)中心的邏輯結(jié)構(gòu)。這些工作沒有涉及交通大數(shù)據(jù)處理平臺需要面對的各種應(yīng)用場景以及系統(tǒng)構(gòu)建應(yīng)遵循的原則，如沒有涉及實時數(shù)據(jù)流處理問題。面對交通大數(shù)據(jù)，如何存儲、組織和管理并提供服務(wù)是ITS面臨的一個挑戰(zhàn)。本文針對如何構(gòu)建交通大數(shù)據(jù)處理平臺開展研究，主要從使能技術(shù)方面展開論述，不對具體業(yè)務(wù)系統(tǒng)進(jìn)行評述。

交通大數(shù)據(jù)處理平臺的功能需求及其邏輯框架

本節(jié)通過介紹智能交通系統(tǒng)大數(shù)據(jù)的特點以及提供服務(wù)的要求分析了交通大數(shù)據(jù)分析平臺需具備的特點，提出了交通大數(shù)據(jù)處理平臺邏輯框架，并進(jìn)一步闡述了平臺構(gòu)建的基本原則建議。

交通大數(shù)據(jù)處理平臺需具備的特性

如前所述，交通服務(wù)要提供全面的路況，需要交通綜合監(jiān)測網(wǎng)絡(luò)對城市道路交通狀況、交通流信息、交通違法行為等的全面監(jiān)測，采集、處理及分析大量的實時監(jiān)測數(shù)據(jù)，具有數(shù)據(jù)量巨大的特點；隨著城市機(jī)動車保有量不斷提高，城市道路交通狀況日趨復(fù)雜化，交通流特性呈現(xiàn)隨時間變化大、區(qū)域關(guān)聯(lián)性強(qiáng)的特點，需要根據(jù)實時的交通流數(shù)據(jù)及時全面采集、處理、分析等，因此具有系統(tǒng)負(fù)載時變性高、波動大的特點，應(yīng)支持低延時、高并發(fā)事務(wù)；公眾出行服務(wù)對交通信息發(fā)布的時效性要求高，需將準(zhǔn)確的信息及時提供給不同需求的主體，信息處理、分析實時性要求高；ITS需面向政府、社會和公眾提供交通服務(wù)，為出行者提供安全、暢通、高品質(zhì)的行程服務(wù)，保障交通運(yùn)輸?shù)母甙踩?、高時效和高準(zhǔn)確性，要求ITS應(yīng)用系統(tǒng)具有高可用性和高穩(wěn)定性。這給交通大數(shù)據(jù)處理平臺提出了挑戰(zhàn)，平臺需滿足的特性如表1所示。

交通大數(shù)據(jù)處理平臺面對海量數(shù)據(jù)，系統(tǒng)不能僅依靠少數(shù)幾臺機(jī)器的升級（Scale-up，縱向擴(kuò)展）滿足數(shù)據(jù)量的增長，必須做到橫向可擴(kuò)展（Scale-out），既滿足性能的要求，也滿足存儲的要求（包括結(jié)構(gòu)性數(shù)據(jù)、非結(jié)構(gòu)形式、半結(jié)構(gòu)性數(shù)據(jù)）；由于服務(wù)需求的多樣性，平臺既要支持交通數(shù)據(jù)流的實時分析與處理又要支持復(fù)雜查詢與深度分析所需的高性能、低延遲需求。平臺需具有高度容錯性，大數(shù)據(jù)的容錯性要求在作業(yè)（Job）執(zhí)行過程中，一個參與節(jié)點失效不需要重做整個作業(yè)。機(jī)群節(jié)點數(shù)的增加會增加節(jié)點失效概率，在大規(guī)模機(jī)群環(huán)境下，節(jié)點的失效不再是稀有事件，因此在大規(guī)模機(jī)群環(huán)境下，系統(tǒng)不能依賴于硬件來保證容錯性，要更多地考慮軟件級容錯，同時增加系統(tǒng)的可用性。系統(tǒng)的開放性也是十分重要的，在下一小節(jié)會知道ITS是一個巨系統(tǒng)，各子系統(tǒng)之間數(shù)據(jù)交換、共享以及服務(wù)集成是必不可少的，同時要求系統(tǒng)支持迭代開發(fā)，可不斷更新/增加功能；系統(tǒng)服務(wù)不但專業(yè)人員可以使用，業(yè)務(wù)人員也可以使用，分析可以實現(xiàn)大眾化。

表1：交通大數(shù)據(jù)處理平臺需具備的特性

另外，平臺應(yīng)支持異構(gòu)環(huán)境。交通大數(shù)據(jù)平臺的建設(shè)是分步驟、分階段進(jìn)行的，設(shè)備的采購、更新會造成硬件系統(tǒng)的異構(gòu)，建設(shè)同構(gòu)大規(guī)模機(jī)群難度較大；另外，對異構(gòu)環(huán)境的支持可以有效地利用歷史上積累的計算機(jī)資源，降低硬件成本的投入。

交通大數(shù)據(jù)分析平臺邏輯框架

ITS是一個復(fù)雜的巨系統(tǒng)。中國ITS體系框架確定了以下內(nèi)容：用戶服務(wù)包括9個服務(wù)領(lǐng)域、47項服務(wù)、179項子服務(wù)；邏輯框架包括10個功能領(lǐng)域、57項功能、101項子功能、406個過程、161張數(shù)據(jù)流圖；物理框架包括10個系統(tǒng)、38個子系統(tǒng)、150個系統(tǒng)模塊、51張物理框架流圖；應(yīng)用系統(tǒng)有58個。ITS內(nèi)容龐多、結(jié)構(gòu)復(fù)雜、技術(shù)含量高，需要多個領(lǐng)域、多個部門的長期合作。ITS涉眾面廣，包括政府部門、企業(yè)、公眾，由此決定了其信息服務(wù)需求的多樣性：交通指揮部門需要實時連續(xù)交通監(jiān)控（如流量、平均車速、飽和度、占有率等）；城市規(guī)劃部門需要當(dāng)前和歷史路網(wǎng)交通流和交通需求數(shù)據(jù)；出行者需要即席查詢交通信息等。因此，涉及交通數(shù)據(jù)流實時分析處理（RTAP）、聯(lián)機(jī)事務(wù)處理（OLTP）、聯(lián)機(jī)分析處理（OLAP）、聯(lián)機(jī)分析與挖掘（OLAM）等功能。

圖2：大數(shù)據(jù)分析與處理平臺通用體系結(jié)構(gòu)

為此，構(gòu)建交通大數(shù)據(jù)分析與處理平臺需要結(jié)合分布式并行處理技術(shù)與實時數(shù)據(jù)流處理技術(shù)。其邏輯功能框架如圖2所示。層次功能結(jié)構(gòu)邏輯如圖右半部分所示，自底向上分別是分布式存儲層、分布式處理層、元數(shù)據(jù)服務(wù)層、處理分析層（包括復(fù)雜事件處理CEP、實時分析處理RTAP、聯(lián)機(jī)分析處理OLAP、深度分析OLAM）以及交通大數(shù)據(jù)分析處理應(yīng)用層；同時，需要對分布式系統(tǒng)進(jìn)行作業(yè)、資源調(diào)度、管理的協(xié)調(diào)與監(jiān)控中間件的支持，支持工作流及其調(diào)度的設(shè)施。而在圖2左半部分則展示了交通大數(shù)據(jù)分析與處理平臺的部件結(jié)構(gòu)圖，在邏輯上可劃分為實時數(shù)據(jù)流處理子系統(tǒng)與大數(shù)據(jù)深度分析（知識獲取與模式發(fā)現(xiàn)）子系統(tǒng)。

實時數(shù)據(jù)流處理子系統(tǒng)接受實時交通數(shù)據(jù)流，數(shù)據(jù)流元組記錄隨時間變化的空間（如位置、區(qū)域等）信息、以及車牌、卡口、速度等屬性數(shù)據(jù)或視頻、圖像數(shù)據(jù)，具有動態(tài)、海量、高維、時效、連續(xù)、多源、無限等特性。該子系統(tǒng)是實現(xiàn)實時交通監(jiān)控系統(tǒng)的數(shù)據(jù)基礎(chǔ)，能夠為指揮調(diào)度、道路規(guī)劃、事故預(yù)警等交通信息管理和決策提供支持，為交通用戶提供更為全面和便捷的服務(wù)。該子系統(tǒng)包含數(shù)據(jù)流管理系統(tǒng)，提供對數(shù)據(jù)流的連續(xù)查詢和混合查詢支持。連續(xù)查詢用于實時持續(xù)不斷地監(jiān)控，如“查詢超速的車輛信息”以及“開始監(jiān)控違法車輛行蹤”是連續(xù)運(yùn)行的查詢，后者涉及空間數(shù)據(jù)庫。用戶可以指定連續(xù)查詢的滑動時間窗口，對于進(jìn)入窗口且符合查詢條件的事件進(jìn)行報警監(jiān)控?；旌喜樵冇糜谀切┎粌H需要涉及動態(tài)流數(shù)據(jù)還需要訪問靜態(tài)歷史和空間數(shù)據(jù)的復(fù)雜查詢，如“統(tǒng)計未來5分鐘內(nèi)從西湖區(qū)流出的車流量”。

深度分析子系統(tǒng)運(yùn)用各種先進(jìn)的數(shù)據(jù)處理技術(shù)，包括數(shù)據(jù)集成技術(shù)、人工智能與數(shù)據(jù)挖掘技術(shù)、決策支持與專家系統(tǒng)等，根據(jù)各交通子系統(tǒng)的需求和它們之間的內(nèi)在聯(lián)系，對來自多來源渠道、格式不一致的數(shù)據(jù)在綜合交通信息的基礎(chǔ)上進(jìn)行抽取、集成，并進(jìn)行深度分析與處理，獲得可用于決策的模式、模型、規(guī)則和知識。需要改造傳統(tǒng)的數(shù)據(jù)挖掘、機(jī)器學(xué)習(xí)算法，以適應(yīng)大數(shù)據(jù)的需要。

平臺對外提供各種交通信息服務(wù)，實現(xiàn)多種模式交通信息發(fā)布，包括Web交通信息服務(wù)、電臺電視臺、交通服務(wù)咨詢熱線、手機(jī)與車載導(dǎo)航等移動終端、觸摸屏查詢終端、可變情報板、交通指南等載體的交通信息發(fā)布。各種應(yīng)用與服務(wù)之間通過一個統(tǒng)一的服務(wù)接口進(jìn)行連接，服務(wù)接口向上層應(yīng)用提供一致的調(diào)用接口，屏蔽底層細(xì)節(jié)，它是一個接口規(guī)范，用以隔離應(yīng)用與服務(wù)，實現(xiàn)兩者的獨(dú)立性，以期達(dá)到平臺功能擴(kuò)展的靈活性。平臺的數(shù)據(jù)則來自ITS交通數(shù)據(jù)采集監(jiān)控網(wǎng)，該層包括網(wǎng)絡(luò)層（信息傳輸）和感知層（信息感知與獲取）。

交通大數(shù)據(jù)處理平臺的構(gòu)建

本節(jié)闡述在當(dāng)前計算技術(shù)下的一個可能的平臺方案。據(jù)前述，平臺必須具有高度可擴(kuò)展性、實時性、高性能、低延遲分析、高度容錯性、可用性、支持異構(gòu)環(huán)境、開放性、易用性，同時也希望具有較低成本；其核心技術(shù)包括大規(guī)模數(shù)據(jù)流處理技術(shù)以及大規(guī)模數(shù)據(jù)管理、分析技術(shù)。這要求我們在進(jìn)行平臺構(gòu)建時作出合理的決策。

對大數(shù)據(jù)進(jìn)行分析的基本策略是把計算推向數(shù)據(jù)，而不是移動大量的數(shù)據(jù)；對大數(shù)據(jù)處理、分析的性能優(yōu)化，分布式并行是必然選擇，并且軟件系統(tǒng)性能的提升可以降低企業(yè)對硬件的投入成本、節(jié)省計算資源，提高系統(tǒng)吞吐量；但異構(gòu)節(jié)點之間的性能差異可能導(dǎo)致系統(tǒng)“木桶效應(yīng)”，因此，異構(gòu)機(jī)群需要特別關(guān)注負(fù)載均衡、任務(wù)調(diào)度等方面的設(shè)計；交通數(shù)據(jù)量及其多樣性給數(shù)據(jù)管理系統(tǒng)提出了新的要求，在存儲以及處理方式需要具備較好的擴(kuò)展性，無共享結(jié)構(gòu)（Sharednothing）的存儲方式是較好的候選方案，傳統(tǒng)數(shù)據(jù)庫缺少水平擴(kuò)展的能力，在系統(tǒng)設(shè)計決策中根據(jù)數(shù)據(jù)大小、性能瓶頸、處理能力等因素決定哪些數(shù)據(jù)由傳統(tǒng)數(shù)據(jù)庫來管理，哪些數(shù)據(jù)應(yīng)當(dāng)由新出現(xiàn)的NoSQL（Not only SQL）存儲管理系統(tǒng)來管理。

交通大數(shù)據(jù)分析平臺

根據(jù)以上分析，新近云計算是一種可選方案。云計算是分布式處理、并行處理和網(wǎng)格計算的發(fā)展，是這些計算機(jī)科學(xué)概念的商業(yè)實現(xiàn)，具有分布式、大規(guī)模、虛擬化、高可靠性、通用性、高可擴(kuò)展性、低廉等特點，它實現(xiàn)對共享可配置計算資源（包括網(wǎng)絡(luò)、服務(wù)器、存儲、應(yīng)用和服務(wù)等）的按需服務(wù)。云計算中的平臺（集群計算框架）有谷歌的MapReduce與微軟的Dryad等，而Hadoop是一個實現(xiàn)了MapReduce的開源分布式并行編程框架；專門針對迭代計算的編程框架有Pregel、HaLoop等，前者是一個迭代圖形計算系統(tǒng)，后者提供了一個迭代MapReduce接口?；贖adoop的應(yīng)用可以運(yùn)行于機(jī)群上，實現(xiàn)對海量數(shù)據(jù)的處理。此外，Hadoop平臺已經(jīng)形成了一個生態(tài)系統(tǒng)，提供一個分布式文件系統(tǒng)（HDFS），HBase是基于HDFS的對BigTable的開源實現(xiàn)，是面向列、可伸縮的分布式存儲系統(tǒng)，支持事務(wù)以及B樹范圍查詢和排序；Hive是基于Hadoop的大型數(shù)據(jù)倉庫，其目標(biāo)是簡化Hadoop上的數(shù)據(jù)聚集、即席查詢及大數(shù)據(jù)集的分析等操作，以減輕程序員的負(fù)擔(dān)；Pig是Yahoo!提出的類似于Hive的大數(shù)據(jù)集分析平臺,它提供的類SQL語言叫Pig Latin，一種基于操作符的數(shù)據(jù)流式的接口,該語言的編譯器會把類SQL的數(shù)據(jù)分析請求轉(zhuǎn)換為一系列經(jīng)過優(yōu)化處理的MapReduce運(yùn)算；Mahout是可伸縮的機(jī)器學(xué)習(xí)算法；工具Sqoop用于傳統(tǒng)數(shù)據(jù)庫和HDFS進(jìn)行數(shù)據(jù)交換；Oozie是工作流調(diào)度工具；ZooKeeper是一個分布式的應(yīng)用程序協(xié)調(diào)器，它包含一個簡單的原語集，分布式應(yīng)用程序可以基于它實現(xiàn)同步服務(wù)，配置維護(hù)和命名服務(wù)等?；贖adoop的大數(shù)據(jù)分析平臺構(gòu)建如圖3所示。需要注意的是，Hadoop適用于長順序掃描，基于Hadoop的Hive會導(dǎo)致較高的延遲，因此不適用于需要快速響應(yīng)的場景；Hive基于只讀的，不適用于事務(wù)處理的場景。在平臺構(gòu)建中涉及分布式存儲系統(tǒng)的選擇。在分布式系統(tǒng)中，一致性（即所有節(jié)點訪問同一份最新的數(shù)據(jù)副本）、可用性（即對數(shù)據(jù)更新具備高可用性）、分區(qū)容忍性（即能容忍網(wǎng)絡(luò)分區(qū)），這三個要素最多只能同時實現(xiàn)兩個，這就是周知的CAP理論。但通過顯式處理分區(qū)情形，系統(tǒng)設(shè)計師可以通過細(xì)致地管理分區(qū)期間的不變性約束優(yōu)化數(shù)據(jù)的一致性和可用性，對三者進(jìn)行平衡。CAP的C僅指單一副本這個意義上的一致性，因此只是ACID一致性約束的一個嚴(yán)格的子集。ACID一致性不可能在分區(qū)過程中保持，因此分區(qū)恢復(fù)時需要重建ACID一致性。CAP理論的可視化圖解見圖4。而NoSQL一般放棄ACID事務(wù)策略的一致性，而是采用BASE（基本可用、事務(wù)軟狀態(tài)以及最終一致性）事務(wù)策略以換取高可用性和可伸縮性。NoSQL存儲系統(tǒng)可分為鍵－值存儲（如Redis, Tokyo Cabinet）、列存儲（如HBase, Cassandra）、文檔數(shù)據(jù)庫（如MongoDB, CouchDB）、圖數(shù)據(jù)庫（如neo4j, FlockDB）等；對于具體應(yīng)用，應(yīng)當(dāng)根據(jù)需要支持的數(shù)據(jù)模型、一致性機(jī)制、存儲機(jī)制、持久性保障、事務(wù)支持、可用性、查詢能力、性能保障等方面來選擇相應(yīng)的NoSQL存儲系統(tǒng)，不可一概而論。據(jù)統(tǒng)計，目前NoSQL存儲系統(tǒng)有150種之多。

圖3 大數(shù)據(jù)分析與處理平臺的一個實例

圖4 CAP理論的可視化圖解

實時數(shù)據(jù)流處理子系統(tǒng)

實時性是交通數(shù)據(jù)處理的關(guān)鍵也是其價值得以實現(xiàn)的基礎(chǔ)。如交通流的實時監(jiān)控、交通擁堵狀況的實時信息、交通誘導(dǎo)等應(yīng)用均要求系統(tǒng)能夠返回當(dāng)前的交通狀態(tài)；在另一些場景則需要進(jìn)行連續(xù)監(jiān)控，在技術(shù)上涉及連續(xù)查詢。這方面的功能需求已在第二節(jié)講述。在構(gòu)建交通大數(shù)據(jù)處理平臺中，實時交通數(shù)據(jù)流處理子系統(tǒng)是關(guān)鍵系統(tǒng)之一。該系統(tǒng)中涉及的關(guān)鍵技術(shù)包括：高速數(shù)據(jù)轉(zhuǎn)換，將獲取的事件數(shù)據(jù)流由隨機(jī)訪問格式轉(zhuǎn)換為分布式并行分析格式，將幾分鐘前獲取的交通數(shù)據(jù)即時處理呈現(xiàn)最新分析結(jié)果；靈活的資源分配方案，不同類型的數(shù)據(jù)處理組件（即事件處理服務(wù)）與可伸縮分布式鍵值存儲靈活連接，可以便捷地構(gòu)造新的服務(wù)而不影響現(xiàn)有系統(tǒng)的運(yùn)行；基于滑動窗口的連續(xù)計算技術(shù)；自適應(yīng)負(fù)載平衡與資源分配優(yōu)化。

開源的分布式實時流計算框架有Twitter的Storm、Yahoo！的S4、基于Hadoop的HStreaming、專門進(jìn)行復(fù)雜事件處理和事件流處理的Esper等。Storm具有高容錯性、水平擴(kuò)展性好、快速、可靠處理消息等優(yōu)點；S4目前還處于半成品階段，代碼成熟度底，不支持動態(tài)部署；Storm支持節(jié)點在集群中動態(tài)增加或移除，S4不支持；Storm屬于全內(nèi)存計算，所需的內(nèi)存資源多，HStreaming介于半內(nèi)存和全磁盤計算，速度相對慢。本文以Storm為例來闡述交通數(shù)據(jù)實時平臺的構(gòu)建。

Storm采用創(chuàng)建拓?fù)浣Y(jié)構(gòu)（topology）來轉(zhuǎn)換數(shù)據(jù)流，不同于Hadoop作業(yè)，這些轉(zhuǎn)換會持續(xù)處理到達(dá)的數(shù)據(jù)。Storm為流轉(zhuǎn)換提供的基本組件有：噴口（Spout）和螺栓（Bolt）。Spout是一個輸入流組件，負(fù)責(zé)將數(shù)據(jù)分發(fā)到多個Bolts執(zhí)行處理任務(wù)（如過濾、聚合、查詢等），Bolts執(zhí)行后可產(chǎn)生新的流作為下級Bolts的輸入流。由此形成的整個處理結(jié)構(gòu)即為一個Topology（作業(yè)或應(yīng)用）如圖4所示。相應(yīng)地，基于Storm的交通數(shù)據(jù)流處理邏輯以及軟件結(jié)構(gòu)分別如圖5與圖6所示。

圖1 一個Storm的Topology結(jié)構(gòu)

圖6 Storm交通數(shù)據(jù)流處理的軟件結(jié)構(gòu)

在一個基于Storm的交通數(shù)據(jù)處理集群中，有主從兩種不同的節(jié)點，三種不同的守護(hù)進(jìn)程：Nimbus運(yùn)行在主節(jié)點上，類似于Hadoop中的Jobtracker，主要負(fù)責(zé)接收客戶端提交的Topology，進(jìn)行相應(yīng)的驗證，分配任務(wù)，進(jìn)而把任務(wù)相關(guān)的元數(shù)據(jù)寫入Zookeeper相應(yīng)目錄，此外，Nimbus還負(fù)責(zé)通過Zookeeper來監(jiān)控任務(wù)執(zhí)行情況，負(fù)責(zé)全局任務(wù)調(diào)度。從節(jié)點上運(yùn)行Supervisor，類似于TaskTracker，管理本地節(jié)點的任務(wù)，負(fù)責(zé)會監(jiān)聽任務(wù)分配情況，根據(jù)實際情況啟動/停止工作進(jìn)程（worker）。每個從節(jié)點上運(yùn)行進(jìn)程worker，類似于Hadoop中的map/reduce的任務(wù)，worker進(jìn)行Spout/Bolt數(shù)據(jù)處理。不同于map/reduce任務(wù)，worker是連續(xù)計算，不會停止。不同于Hadoop，守護(hù)進(jìn)程間并不直接發(fā)送心跳信息或者存在其他RPC控制協(xié)議，他們之間的信息交換是通過Zookeeper來實現(xiàn)。其中Storm處理框架的處理結(jié)果可以在分布式存儲系統(tǒng)中持久化存儲。

資源統(tǒng)一管理與調(diào)度

交通大數(shù)據(jù)處理與分析平臺涉及多種不同類型的應(yīng)用，如本文所講述的脫機(jī)應(yīng)用（數(shù)據(jù)分析、數(shù)據(jù)挖掘）和聯(lián)機(jī)應(yīng)用（數(shù)據(jù)流實時處理），不同的應(yīng)用可能采用了不同的計算框架。為提高資源利用率、降低運(yùn)維成本，將不同計算框架部署到公共的集群中，對資源（內(nèi)存，CPU，網(wǎng)絡(luò)IO等）統(tǒng)一管理與調(diào)度，讓不同計算框架共享集群資源。目前，這方面典型代表有Mesos和YARN。本文采用Mesos構(gòu)建資源共享平臺，如圖8所示。

圖8 基于Mesos平臺的資源共享體系結(jié)構(gòu)

Mesos是一種讓多個計算框架有效共享機(jī)群資源的可伸縮彈性的“核心”集群資源管理器。它通過定義多個計算框架進(jìn)行資源共享的最小接口，把任務(wù)調(diào)度與執(zhí)行控制交給各個計算框架來負(fù)責(zé)。有利于適應(yīng)機(jī)群框架的多樣性和快速演化性。Mesos由master進(jìn)程和框架組成。master進(jìn)程負(fù)責(zé)管理運(yùn)行于機(jī)群節(jié)點上的slave守護(hù)進(jìn)程，框架在slave節(jié)點上運(yùn)行任務(wù)。master進(jìn)程通過資源供應(yīng)方式實施個計算框架之間的資源共享。每一份資源供應(yīng)是各slave節(jié)點空閑資源表。master進(jìn)程采用某種策略（平等分享、優(yōu)先共享等）決定分配多少資源給每個框架。每個運(yùn)行于Mesos之上的計算框架均包含兩個組件：調(diào)度器和執(zhí)行器。特定計算框架通過自身的調(diào)度器向master進(jìn)程注冊，選擇是否接受master提供的資源，接受多少；而slave節(jié)點上的執(zhí)行器（如Hadoop的執(zhí)行器即TaskTracker）運(yùn)行框架的任務(wù)（task）。

原型系統(tǒng)實驗

根據(jù)本文的論述，我們構(gòu)建相應(yīng)交通大數(shù)據(jù)處理與分析平臺進(jìn)行原型驗證，分別構(gòu)建了Hadoop和Storm集群對平均行車速度這個指標(biāo)的計算。實驗所采用的設(shè)備規(guī)格說明如表2所示。為每個虛擬節(jié)點分配了一個虛擬CPU、2GB內(nèi)存、30GB外存，操作系統(tǒng)是CentOS6.2。

表2：實驗所用設(shè)備規(guī)格說明

交通大數(shù)據(jù)分析實驗平臺

所構(gòu)分析平臺采用Hadoop-0.20.2-CDH。實驗中所產(chǎn)生卡口仿真數(shù)據(jù)是指某個卡口某個時刻車輛通行的瞬時車速，產(chǎn)生了8GB 共399000000條記錄的卡口數(shù)據(jù)。相應(yīng)作業(yè)采用Java語言實現(xiàn)，計算給定數(shù)據(jù)集的平均速度。實驗中計算所用時間是557秒。

實時交通數(shù)據(jù)流實驗平臺

所構(gòu)實驗平臺使用Storm 0.8.1、Zookeeper-3.4.5、ZEROMQ-2.1.7（內(nèi)部消息系統(tǒng)，用于節(jié)點或進(jìn)程間的通信）和JZMQ（ZEROMQ的Java 綁定）。作業(yè)采用Java語言實現(xiàn)，對卡口平均車速的持續(xù)監(jiān)控。在Storm集群中，共使用4個Workers，每個Worker有4個Slots。在實驗過程中每個Worker上使用1個Slot。實驗中，產(chǎn)生了三個卡口點位的仿真數(shù)據(jù)。實驗結(jié)果見表3。

實驗考察了并行度和執(zhí)行效率，分別對相應(yīng)作業(yè)配置了不同的Spouts與Bolts個數(shù)。在并行度上，在集群配置允許的情況下，Spout的并行度越高，產(chǎn)生結(jié)果時間越短。但如果spout并行度超出了集群配置的允許范圍，Spout高并行度并不能縮短產(chǎn)生結(jié)果時間，反而很有可能延長產(chǎn)生結(jié)果時間。由結(jié)果可知，原型系統(tǒng)可以每秒處理1萬條以上卡口數(shù)據(jù)。

表3：Storm機(jī)群的運(yùn)行結(jié)果

五、結(jié)論

本文圍繞如何構(gòu)建交通大數(shù)據(jù)處理平臺開展討論，主要從方法論角度展開論述。首先，對平臺需求及其邏輯框架進(jìn)行了討論，提出了相應(yīng)的方案，講述了其涉及的核心技術(shù)；其次，提出了針對交通大數(shù)據(jù)分析平臺以及交通數(shù)據(jù)流計算的實時計算平臺一種可行構(gòu)建方案；最后，通過原型系統(tǒng)論證了方案的可行性。目前，我們開展了前期的研究，沒有涉及系統(tǒng)、代碼的優(yōu)化，也沒有涉及具體業(yè)務(wù)子系統(tǒng)的構(gòu)建細(xì)節(jié)。下一步將進(jìn)行實際運(yùn)行系統(tǒng)的構(gòu)建，開展更深入一步的工作，包括實時交通數(shù)據(jù)流處理算法、交通大數(shù)據(jù)分析算法等方面的理論與實現(xiàn)技術(shù)的研究。