張春風(fēng), 申 飛, 張 俊, 陳 杰, 劉 靜

1(中國科學(xué)院 強(qiáng)磁場(chǎng)科學(xué)中心,合肥 230031)

2(中國科學(xué)技術(shù)大學(xué),合肥 230026)

車聯(lián)網(wǎng)云數(shù)據(jù)中心與綜合服務(wù)平臺(tái)匯聚了車輛位置、狀態(tài)、速度、加速度、路網(wǎng)等非結(jié)構(gòu)化的車聯(lián)網(wǎng)數(shù)據(jù),其規(guī)模己經(jīng)達(dá)到TP甚至BP級(jí)別. 傳統(tǒng)的數(shù)據(jù)分析技術(shù)已經(jīng)無法滿足該級(jí)別數(shù)據(jù)處理的需求,因此,引進(jìn)分布式計(jì)算技術(shù)和數(shù)據(jù)存儲(chǔ)技術(shù),構(gòu)建流式計(jì)算處理框架,對(duì)車輛進(jìn)行實(shí)時(shí)監(jiān)控和調(diào)度管理迫在眉睫.目前,不少流式大數(shù)據(jù)處理的方案被提出. 其中,Spark Streaming是Spark核心API的一個(gè)擴(kuò)展,不同于Storm一次一個(gè)地處理數(shù)據(jù)流,Spark Streaming在處理前按時(shí)間間隔預(yù)先將數(shù)據(jù)流切分為一段一段的批處理作業(yè).因此,Spark Streaming不是真正意義上的流式計(jì)算,而是批處理,相比于Storm,Spark Streaming存在延遲高,吞吐量較小等缺點(diǎn). 另外,Samza是由LinkedIn開源的一個(gè)分布式流處理系統(tǒng),它依賴于Hadoop的資源調(diào)度和Apache Kafka[1,2]. Samza的流單位既不是元組,也不是Dstream,而是一條條消息,在數(shù)據(jù)傳遞過程中,消息可能會(huì)多次發(fā)送,造成數(shù)據(jù)冗余. 針對(duì)車聯(lián)網(wǎng)數(shù)據(jù)處理分析的問題,以及其低延遲,增量計(jì)算的需求,本文設(shè)計(jì)了一種基于Storm技術(shù)的流式計(jì)算系統(tǒng),系統(tǒng)具有低延遲,高吞吐,分層且可擴(kuò)展的特性. 利用Kafka消息隊(duì)列將各層之間解耦,Storm進(jìn)行數(shù)據(jù)實(shí)時(shí)分析,Hbase和Redis對(duì)分析結(jié)果存儲(chǔ),從而實(shí)現(xiàn)對(duì)車輛狀態(tài)進(jìn)行實(shí)時(shí)監(jiān)控.

1 實(shí)時(shí)流相關(guān)技術(shù)

車聯(lián)網(wǎng)實(shí)時(shí)分析系統(tǒng)主要由Boost.Asio、Kafka、Storm、Redis、Hbase組成. 其中,Boost.Asio負(fù)責(zé)與車載終端建立連接,采集數(shù)據(jù). Kafka負(fù)責(zé)連接采集層和Storm. Redis和Hbase負(fù)責(zé)分析結(jié)果的存儲(chǔ). 系統(tǒng)的整個(gè)核心實(shí)時(shí)分析模塊由Storm擔(dān)當(dāng),對(duì)采集來的數(shù)據(jù)分析過濾,實(shí)時(shí)處理. 下文將介紹Storm流式計(jì)算框架.

1.1 Storm流式計(jì)算框架

Storm是一個(gè)分布式的、可靠的、容錯(cuò)的數(shù)據(jù)流處理系統(tǒng)[3]. 同Hadoop一樣,Storm可以處理大批量的數(shù)據(jù),并且Storm在保證高可靠性的前提下可以讓處理進(jìn)行的更加實(shí)時(shí); Storm同樣還具備容錯(cuò)和分布計(jì)算的特性,即可以擴(kuò)展到不同的機(jī)器上進(jìn)行大批量的數(shù)據(jù)處理. 除此之外,Storm同時(shí)還有以下的這些特性：

(1) 簡(jiǎn)單的編程模型. 類似于MapReduce降低了并行批處理復(fù)雜性,降低了進(jìn)行實(shí)時(shí)處理的復(fù)雜性.

(2) 容錯(cuò)性. Storm會(huì)管理工作進(jìn)程和節(jié)點(diǎn)的故障.

(3) 水平擴(kuò)展. 計(jì)算是在多個(gè)線程、進(jìn)程和服務(wù)器之間并行進(jìn)行的. Storm使用Zookeeper進(jìn)行集群協(xié)調(diào),這樣可以充分的保證大型集群的良好運(yùn)行[3-5].

(4) 可靠的消息處理. Storm保證每個(gè)消息至少能得到一次完整處理. 任務(wù)失敗時(shí),它會(huì)負(fù)責(zé)從消息源重試消息.

(5) 快速. 系統(tǒng)的設(shè)計(jì)保證了消息能得到快速的處理,使用ZeroMQ作為其底層消息隊(duì)列[6-10].

為了更好的體現(xiàn)Storm在流式計(jì)算方面獨(dú)特的優(yōu)越性,對(duì)比Spark計(jì)算框架. 如表1所示二者的主要區(qū)別表現(xiàn)在,Storm是純實(shí)時(shí)的,來一條數(shù)據(jù),處理一條數(shù)據(jù),后者是準(zhǔn)實(shí)時(shí),對(duì)一個(gè)時(shí)間段內(nèi)的數(shù)據(jù)收集起來,作為一個(gè)RDD,再處理. 而且,Storm的事務(wù)機(jī)制、健壯性/容錯(cuò)性、動(dòng)態(tài)調(diào)整并行度等方面的表現(xiàn),都要比Spark Streaming更加優(yōu)秀.

表1 Spark和Storm流數(shù)據(jù)計(jì)算框架比較

2 系統(tǒng)架構(gòu)設(shè)計(jì)

系統(tǒng)架構(gòu)如圖1所示,主要包含數(shù)據(jù)采集、數(shù)據(jù)轉(zhuǎn)發(fā)、實(shí)時(shí)分析、數(shù)據(jù)存儲(chǔ)、可視化展示.

圖1 系統(tǒng)架構(gòu)圖

系統(tǒng)采用層次化結(jié)構(gòu)的設(shè)計(jì)原理,每個(gè)部分的主要功能如下：

(1) 數(shù)據(jù)采集： 負(fù)責(zé)與智能終端(OBD)建立TCP連接,驗(yàn)證校驗(yàn),獲取報(bào)文數(shù)據(jù).

(2) 數(shù)據(jù)轉(zhuǎn)發(fā)： 對(duì)數(shù)據(jù)類型進(jìn)行劃分,放在Kafka消息隊(duì)列中,實(shí)現(xiàn)數(shù)據(jù)的分類管理和高并發(fā)接入.

(3) 實(shí)時(shí)分析： 創(chuàng)建 KafkaSpout,從 Kafka 中獲取數(shù)據(jù),并以數(shù)據(jù)流的形式發(fā)送給bolt,bolt負(fù)責(zé)轉(zhuǎn)化這些數(shù)據(jù)流,在bolt中完成過濾,分析計(jì)算.

(4) 數(shù)據(jù)存儲(chǔ)： 將實(shí)時(shí)分析結(jié)果存儲(chǔ)至Redis和Hbase,利用分布式文件系統(tǒng)的優(yōu)勢(shì)可以實(shí)現(xiàn)高并發(fā)的讀寫速度.

(5) 可視化展示： 使用Dubbo分布式服務(wù)提供實(shí)時(shí)定位,軌跡查詢和速度報(bào)警等服務(wù),同時(shí)利用百度地圖動(dòng)態(tài)顯示.

2.1 數(shù)據(jù)采集

數(shù)據(jù)采集主要負(fù)責(zé)接收車載終端發(fā)送過來的實(shí)時(shí)車輛信息數(shù)據(jù),車載終端通過無線網(wǎng)絡(luò)與數(shù)據(jù)采集層建立通信連接. 數(shù)據(jù)采集層會(huì)維護(hù)一個(gè)連接請(qǐng)求隊(duì)列,面對(duì)高并發(fā)連接的需求,模塊在開發(fā)過程中使用Boost.Asio基礎(chǔ)網(wǎng)絡(luò)庫作為通信基礎(chǔ),使用Boost.Asio庫的異步接口函數(shù)來實(shí)現(xiàn)全異步的事件處理,包括TCP鏈接監(jiān)聽、TCP數(shù)據(jù)發(fā)送、TCP數(shù)據(jù)接收. 數(shù)據(jù)采集層提供車載終端統(tǒng)一的信號(hào)接收服務(wù),避免了數(shù)據(jù)的重復(fù),缺失,從而保證數(shù)據(jù)采集的質(zhì)量和可靠性,.

2.2 數(shù)據(jù)轉(zhuǎn)發(fā)

數(shù)據(jù)轉(zhuǎn)發(fā)作為平臺(tái)各層之間的通信層,將系統(tǒng)各層之間進(jìn)行有效地解耦,提高平臺(tái)的健壯性. 目前用于消息傳遞的方案主要包括RabbitMQ和Kafka. 其中RabbitMQ是流行的開源消息隊(duì)列系統(tǒng),開發(fā)語言為erlang. Kafka則是一個(gè)分布式的高吞吐量的消息系統(tǒng)[11-13]. 與kafka相比,RabbitMQ協(xié)議復(fù)雜,參數(shù)較多,因此其僅適用于數(shù)據(jù)量較小的場(chǎng)景. 而Kafka具有透明、易擴(kuò)展和吞吐量較高的優(yōu)點(diǎn),更適合處理海量的車聯(lián)網(wǎng)數(shù)據(jù). 基于此,本系統(tǒng)采用Kafka消息隊(duì)列實(shí)現(xiàn)數(shù)據(jù)緩存與轉(zhuǎn)發(fā),利用其能夠提供消息持久化能力和具有容錯(cuò)性保障的優(yōu)勢(shì),達(dá)到系統(tǒng)數(shù)據(jù)緩沖的目的.

作為基于log File的消息系統(tǒng),Kafka更加可靠,減少了數(shù)據(jù)丟失的現(xiàn)象. 另外,Kafka可以記錄數(shù)據(jù)的消費(fèi)位置,同時(shí)可以自定義消息消費(fèi)的起始位置,從而保證了重復(fù)消費(fèi)消息的實(shí)現(xiàn). 而且,Kafka同時(shí)具有隊(duì)列和發(fā)布訂閱兩種消息消費(fèi)模式,與Storm(實(shí)時(shí)分析層)的契合度很高,充分利用Linux系統(tǒng)的I/O提高讀寫速度等. 轉(zhuǎn)發(fā)層的架構(gòu)如圖2所示.

圖2 緩存轉(zhuǎn)發(fā)架構(gòu)

采集層作為Producer(生產(chǎn)者),將采集到的車載終端數(shù)據(jù)以終端標(biāo)識(shí)為區(qū)分標(biāo)準(zhǔn),建立多個(gè)topic,用來管理不同種類的消息,不同類別的消息會(huì)記錄在到其對(duì)應(yīng)的topic池中,而這些進(jìn)入到topic中的消息會(huì)被Kafka寫入磁盤的log文件中進(jìn)行持久化處理. 實(shí)時(shí)分析層作為Consumer(消費(fèi)者),Storm集群從Kakfa中獲取實(shí)時(shí)流進(jìn)行處理分析. 數(shù)據(jù)處理分析的速度可以慢于數(shù)據(jù)采集的速度,Storm集群有空余時(shí)再拉取那些沒拉取到的數(shù)據(jù),從而保證數(shù)據(jù)不丟失.

2.3 實(shí)時(shí)分析層

數(shù)據(jù)實(shí)時(shí)分析層是系統(tǒng)的核心層. 車載終端所采集的數(shù)據(jù)是沒有被解析的原始數(shù)據(jù),使用單字節(jié)、雙字節(jié)或四字節(jié)來進(jìn)行物理量的表示. 所采集到的數(shù)據(jù)格式為：

因此,實(shí)時(shí)分析層需將采集到的車輛實(shí)時(shí)信息進(jìn)行過濾、解析、坐標(biāo)轉(zhuǎn)換. 解析海量數(shù)據(jù)存在延遲阻塞、高并發(fā)等問題. 為了解決這些問題,本文拋棄了Java線程池、無限隊(duì)列等傳統(tǒng)的方法,突破集中式單節(jié)點(diǎn)運(yùn)算的限制,采用分布式,高容錯(cuò)的實(shí)時(shí)計(jì)算系統(tǒng)Storm. 實(shí)時(shí)分析拓?fù)淙鐖D3所示.

首先,建立實(shí)時(shí)分析拓?fù)鋱D(Topology)并提交給Storm集群,由集群中主節(jié)點(diǎn)Master的守護(hù)進(jìn)程“Nimbus”分發(fā)代碼,將任務(wù)分配給工作節(jié)點(diǎn)(Worker)執(zhí)行,同時(shí)監(jiān)控任務(wù)和工作節(jié)點(diǎn)的運(yùn)行情況等; Worker節(jié)點(diǎn)上運(yùn)行的守護(hù)進(jìn)程“Supervisor”,負(fù)責(zé)接收Nimbus分發(fā)的任務(wù)并運(yùn)行,每一個(gè)Worker上都會(huì)運(yùn)行著Topology程序的一部分. 因此,Topology程序的運(yùn)行就是由集群上多個(gè)Worker一起協(xié)同工作的.Topology的部分代碼如下所示：

圖3 實(shí)時(shí)分析拓?fù)?/p>

拓?fù)渲邪琒pout和Bolt兩種角色,系統(tǒng)中KafkaSpout從Kafka消息隊(duì)列中獲取數(shù)據(jù),通過nextTuple()方法以數(shù)據(jù)流Tuple元組的形式發(fā)送給下游的MsgPreDealBolt,Spout的ack和fail方法分別在元組被成功處理和處理失敗時(shí)調(diào)用,保證數(shù)據(jù)處理的完整性. MsgPreDealBolt完成過濾工作,根據(jù)指令校驗(yàn)碼進(jìn)行篩選出符合要求的軌跡數(shù)據(jù),按照FieldsGrouping的分組策略,通過execute()方法發(fā)送到解析模塊. 解析模塊GpsDealbolt主要完成分析處理邏輯,包括2進(jìn)制的轉(zhuǎn)化,終端識(shí)別,分析終端發(fā)送數(shù)據(jù)的類型,并做出相應(yīng)的處理,最后按照FieldsGrouping的分組策略發(fā)送至下一處理模塊. 轉(zhuǎn)換模塊主要是北斗坐標(biāo)轉(zhuǎn)換為百度坐標(biāo)的處理(方便使用百度地圖功能),從而以次完成數(shù)據(jù)的解析處理,轉(zhuǎn)換等工作. Storm通過實(shí)現(xiàn)不同的Bolt來完成計(jì)算結(jié)果的多樣化存儲(chǔ). 本系統(tǒng)中對(duì)分析結(jié)果處理有HbaseBolt和RedisBolt. HbaseBolt將結(jié)果保存到HDFS分布式文件系統(tǒng)中,RedisBolt將計(jì)算結(jié)果保存到緩存中,便于查詢檢索.

2.4 數(shù)據(jù)存儲(chǔ)

基于傳統(tǒng)關(guān)系型數(shù)據(jù)庫存儲(chǔ)的車輛信息表日漸增大,接近單表存儲(chǔ)的上限,且數(shù)據(jù)的查詢和寫入性能會(huì)呈現(xiàn)指數(shù)級(jí)別地下降. 為了實(shí)現(xiàn)高性能的并發(fā)讀寫操作,數(shù)據(jù)存儲(chǔ)層采用硬盤存儲(chǔ)和內(nèi)存存儲(chǔ)兩種模式. 硬盤存儲(chǔ)使用分布式的、面向列的開源數(shù)據(jù)庫Hbase,存儲(chǔ)離線數(shù)據(jù)以及將處理后的流數(shù)據(jù)進(jìn)行落地. 目前主流的內(nèi)存數(shù)據(jù)庫有Memcached和Redis. Memcached是一個(gè)高性能的,具有分布式內(nèi)存對(duì)象的緩存系統(tǒng);Redis是一個(gè)基于內(nèi)存的高性能Key/Value數(shù)據(jù)庫.

二者主要的區(qū)別為： Redis會(huì)周期性地把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件,并且在此基礎(chǔ)上實(shí)現(xiàn)了master-slave(主從)同步. 與Memcached相比,Redis的優(yōu)勢(shì)在于其具有高效的讀寫效率以及豐富的數(shù)據(jù)類型所帶來的快速開發(fā). 另外,Redis作為緩存具有更高的安全性. 因此,本文選用Redis數(shù)據(jù)庫作為系統(tǒng)的緩存,用于保存整個(gè)系統(tǒng)的分析結(jié)果,實(shí)現(xiàn)緩存數(shù)據(jù)的持久化. 在節(jié)點(diǎn)宕機(jī)或者斷電的情況下,系統(tǒng)仍能夠從硬盤中獲取備份的數(shù)據(jù),從而保證了系統(tǒng)的健壯性. 以下分別介紹兩種模式的具體實(shí)現(xiàn)：

(1) 將Storm中分析的實(shí)時(shí)數(shù)據(jù)存儲(chǔ)到Hbase中,為后期的查詢和離線分析做數(shù)據(jù)支持. 采用HBase大數(shù)據(jù)存儲(chǔ)框架,在保證足夠的存儲(chǔ)空間的前提下,利用HBase的分布式特點(diǎn)來提高數(shù)據(jù)的存取速度,解決數(shù)據(jù)的單點(diǎn)存儲(chǔ)隱患,保障數(shù)據(jù)的高可用性. 系統(tǒng)中實(shí)時(shí)車輛信息表如表2所示.

表2 實(shí)時(shí)車輛信息表

Hbase以表Table形式存儲(chǔ)數(shù)據(jù),每行包括一個(gè)RowKey和多個(gè)Column Family,且每行通過RowKey唯一標(biāo)記,行按照RowKey的字典序排列. 實(shí)時(shí)車輛信息表根據(jù)Hbase表的設(shè)計(jì)要求,RowKey為車牌號(hào)的反轉(zhuǎn)+“_”+時(shí)間戳,要盡量縮小 RowKey的長度,提高檢索效率,columnfamily要盡量的少,原因是過多的columnfamily之間會(huì)互相影響,所以設(shè)計(jì)了一個(gè)列簇CarInfo,在CarInfo下分為很多列,如車牌號(hào),定位時(shí)間,經(jīng)緯度等車輛軌跡信息.

(2) 將Storm中分析的最新實(shí)時(shí)數(shù)據(jù)緩存到內(nèi)存數(shù)據(jù)庫Redis中,利用Redis高性能操作和運(yùn)算上的優(yōu)勢(shì),為數(shù)據(jù)展示層提供既方便又快捷的數(shù)據(jù)檢索. 由于Redis數(shù)據(jù)庫容量受到物理內(nèi)存的限制,不能用作海量數(shù)據(jù)的高性能讀寫,只能將最新的數(shù)據(jù)緩存到內(nèi)存中,數(shù)據(jù)展示層首先查詢Redis,如果數(shù)據(jù)存在,直接從Redis獲取數(shù)據(jù),否則從Hbase中獲取,如此以來提高數(shù)據(jù)的查詢檢索速度,優(yōu)化系統(tǒng)性能.

2.5 可視化展示

可視化展示為數(shù)據(jù)存儲(chǔ)層中所有車輛實(shí)時(shí)信息提供統(tǒng)一的查詢?nèi)肟?將車輛軌跡分析結(jié)果以可視化的形式展現(xiàn). 本系統(tǒng)使用Dubbo分布式服務(wù)框架,將核心業(yè)務(wù)抽取出來,作為獨(dú)立的服務(wù),使前端應(yīng)用能更快速和穩(wěn)定的響應(yīng),解決了服務(wù)器單點(diǎn)故障,方便后期的拓展和維護(hù). 可視化展示主要包括以下幾個(gè)方面：

(1) 前端借助百度地圖,將查詢車輛的軌跡信息,包括已經(jīng)行駛的時(shí)間,行駛過程中的停留點(diǎn),速度等在整個(gè)地圖上動(dòng)態(tài)的顯示.

(2) 根據(jù)車輛行使的路段,利用百度地圖查詢?cè)摰囟蔚南匏俅笮?并與車輛當(dāng)前速度進(jìn)行比較,檢測(cè)是否超速,如果超速,給予駕駛員警告.

(3) 電子圍欄,將車輛的位置信息與規(guī)定行使區(qū)域?qū)崟r(shí)進(jìn)行比較,檢測(cè)是否超出預(yù)定的行駛路線.

(4) 根據(jù)車牌號(hào)實(shí)時(shí)定位當(dāng)前車輛的位置信息,行駛速度,急加速等信息,有效地監(jiān)控當(dāng)前車輛狀態(tài).

3 實(shí)驗(yàn)分析

實(shí)驗(yàn)主要驗(yàn)證系統(tǒng)的功能和Storm實(shí)時(shí)分析的效率. 通過部署局域網(wǎng)的10臺(tái)PC機(jī),搭建集群進(jìn)行測(cè)試. 實(shí)驗(yàn)環(huán)境配置如下： Storm版本： 0.10.2,系統(tǒng)版本：centos6.7,JDK1.8.0_45-b14,Kafka2.11-0.10.0.1,Zookerper3.4.9,Hbase1.0.3,,Redis-3.2.3,Dubbo2.8.4,單機(jī)計(jì)算機(jī)節(jié)點(diǎn)配置： 內(nèi)存大?。?8 G,CPU型號(hào)： intel Core i5,磁盤500 G. 本次實(shí)驗(yàn)系統(tǒng)部署架構(gòu),集群各個(gè)節(jié)點(diǎn)的配置和功能描述如表3所示. 數(shù)據(jù)源是網(wǎng)約車平臺(tái)共享的數(shù)據(jù),將數(shù)據(jù)源以日志的形式存儲(chǔ)在本地硬盤中,通過讀取文件來模擬車載終端發(fā)送的大量數(shù)據(jù)流.

表3 集群節(jié)點(diǎn)配置表

3.1 功能測(cè)試

首先進(jìn)行功能的測(cè)試,測(cè)試系統(tǒng)能否從終端獲取數(shù)據(jù),并利用Storm實(shí)時(shí)解析并可視化的展視. 在web端根據(jù)車牌號(hào)對(duì)車輛進(jìn)行定位查詢,后臺(tái)從緩存或數(shù)據(jù)庫中獲取當(dāng)前車輛最新的數(shù)據(jù),利用百度地圖實(shí)時(shí)定位,然后進(jìn)行可視化展現(xiàn). 圖4為實(shí)時(shí)定位效果的實(shí)例展示.個(gè)人軌跡的查詢,根據(jù)車牌號(hào)可以查詢某一時(shí)間段的車輛行駛軌跡. 后臺(tái)根據(jù)時(shí)間段和車牌號(hào),從緩存或數(shù)據(jù)庫拿到車輛軌跡信息,并在地圖上繪制出來,軌跡查詢的效果圖如5所示.

圖4 實(shí)時(shí)定位圖

圖5 軌跡查詢圖

從效果圖可以看出實(shí)時(shí)分析層已經(jīng)實(shí)現(xiàn)了將采集層采集的數(shù)據(jù),過濾,解析,經(jīng)緯度轉(zhuǎn)換,存儲(chǔ)到數(shù)據(jù)庫中,并通過展示層可視化的展現(xiàn)出來. 從而說明基于Storm的車聯(lián)網(wǎng)數(shù)據(jù)實(shí)時(shí)分析系統(tǒng)的功能基本實(shí)現(xiàn),對(duì)數(shù)據(jù)的采集,轉(zhuǎn)發(fā),解析,落地存儲(chǔ)功能均無問題.

3.2 性能測(cè)試

測(cè)試系統(tǒng)實(shí)時(shí)處理的性能,主要指標(biāo)是數(shù)據(jù)處理的吞吐量,數(shù)據(jù)處理延遲. 吞吐量反映系統(tǒng)單位時(shí)間內(nèi)處理數(shù)據(jù)的規(guī)模. 對(duì)比分析Storm集群和Java線程池的吞吐能力. 不斷增加任務(wù)執(zhí)行的數(shù)據(jù)量,記錄處理完成所需的時(shí)間,為了提高實(shí)驗(yàn)結(jié)果的準(zhǔn)確性,測(cè)試的數(shù)據(jù)保持一致,每項(xiàng)結(jié)果是經(jīng)過5次測(cè)試取平均值,對(duì)比結(jié)果如圖6.

圖6 Java線程池與Storm運(yùn)行時(shí)間對(duì)比

當(dāng)數(shù)據(jù)規(guī)模較小時(shí),利用Storm集群計(jì)算需要更長的時(shí)間,這是因?yàn)樵诩褐腥蝿?wù)的分發(fā),數(shù)據(jù)的傳輸都要經(jīng)過網(wǎng)絡(luò),需要消耗部分系統(tǒng)資源和時(shí)間. 隨著數(shù)據(jù)規(guī)模的增大,集群的處理能力明顯提升,這是因?yàn)镾torm中計(jì)算任務(wù)被劃分為不同的組件,在多個(gè)Worker節(jié)點(diǎn)上的Executor執(zhí)行. 因此,隨著數(shù)據(jù)規(guī)模進(jìn)一步擴(kuò)大,單機(jī)版的Java多線程處理的耗時(shí)將更加難以接受,甚至出現(xiàn)卡頓死機(jī)的情況,而Storm集群支持水平擴(kuò)展,添加了Worker節(jié)點(diǎn),能夠滿足更大規(guī)模的數(shù)據(jù)處理要求. 因此,Storm在流式計(jì)算方面的性能遠(yuǎn)遠(yuǎn)超過傳統(tǒng)的Java多線程平臺(tái).

Storm集群和傳統(tǒng)Java多線程平臺(tái)在延遲性方面沒有可比性. 數(shù)據(jù)處理延遲與數(shù)據(jù)處理模塊的并行任務(wù)數(shù)有關(guān). 一般來說,并行任務(wù)數(shù)越多,Tuple等待被處理的時(shí)間就越短,處理延遲越小.

通過實(shí)驗(yàn)對(duì)比分析,將KafkaSpout的組件數(shù)目設(shè)置為2,分析處理模塊的Bolt分別設(shè)置為2,8. 測(cè)試結(jié)果如圖7所示,隨著處理的數(shù)據(jù)量越大,當(dāng)處理模塊Bolt數(shù)目為2時(shí),處理延遲越來越大,這是因?yàn)镾pout不斷產(chǎn)生新的數(shù)據(jù),分析處理模塊不能及時(shí)處理,導(dǎo)致數(shù)據(jù)積累,處理延遲呈上升趨勢(shì). 當(dāng)處理模塊的Bolt數(shù)目為8時(shí),處理延遲都在毫秒級(jí). 因此合理的設(shè)置各組件的任務(wù)數(shù)是優(yōu)化Storm性能的有效途徑,提高Storm并行處理能力.

圖7 并行數(shù)Bolt為2,8處理時(shí)間對(duì)比

本系統(tǒng)還具備快速部署,易拓展的優(yōu)點(diǎn). 隨著業(yè)務(wù)的發(fā)展,數(shù)據(jù)量和計(jì)算量越來越大,僅需要增加Worker節(jié)點(diǎn)便可提高任務(wù)的計(jì)算能力. 具體地,新增節(jié)點(diǎn)首先解壓Zookeeper和Storm安裝包,修改配置文件,然后運(yùn)行Zookeeper和Storm集群. 無需修改程序,在集群?jiǎn)?dòng)后,重新提交topology即可完成部署. 隨著部署節(jié)點(diǎn)的數(shù)量不斷增加,系統(tǒng)易拓展的優(yōu)勢(shì)將更加明顯.

4 結(jié)論與展望

為了對(duì)海量車聯(lián)網(wǎng)數(shù)據(jù)進(jìn)行實(shí)時(shí)分析及可視化展示,本文設(shè)計(jì)了基于Storm的車聯(lián)網(wǎng)數(shù)據(jù)實(shí)時(shí)分析系統(tǒng),系統(tǒng)融合了Kafka消息隊(duì)列、Storm流式計(jì)算框架、Hbase分布式數(shù)據(jù)庫、Redis內(nèi)存持久化數(shù)據(jù)庫、Dubbo分布式框架等技術(shù). 通過測(cè)試驗(yàn)證,與傳統(tǒng)的多線程處理平臺(tái)相比,系統(tǒng)有高吞吐和低延遲的特性,

實(shí)現(xiàn)車輛狀態(tài)實(shí)時(shí)監(jiān)控,從而提高車輛監(jiān)管效率.系統(tǒng)的分布式負(fù)載均衡,調(diào)度優(yōu)化等問題將是我們下一步重點(diǎn)關(guān)注的問題.

1周國亮,朱永利,王桂蘭,等. 實(shí)時(shí)大數(shù)據(jù)處理技術(shù)在狀態(tài)監(jiān)測(cè)領(lǐng)域中的應(yīng)用. 電工技術(shù)學(xué)報(bào),2014,29(S1)： 432-437.

2戴菲. 基于Storm的實(shí)時(shí)計(jì)算系統(tǒng)的研究與實(shí)現(xiàn)[碩士學(xué)位論文]. 西安： 西安電子科技大學(xué),2014.

3李勁松. 一種基于Storm的分布式實(shí)時(shí)增量計(jì)算框架的研究與實(shí)現(xiàn)[碩士學(xué)位論文]. 成都： 電子科技大學(xué),2015.

4孫朝華. 基于Storm的數(shù)據(jù)分析系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文]. 北京： 北京郵電大學(xué),2014.

5王銘坤,袁少光,朱永利,等. 基于Storm的海量數(shù)據(jù)實(shí)時(shí)聚類. 計(jì)算機(jī)應(yīng)用,2014,34(11)： 3078-3081.

6李慶華,陳球霞,蔣盛益. 基于數(shù)據(jù)流的實(shí)時(shí)處理框架模型. 計(jì)算機(jī)工程,2005,31(16)： 59-60,63. [doi： 10.3969/j.issn.1000-3428.2005.16.023]

7屈國慶. 基于Storm的實(shí)時(shí)日志分析系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)[碩士學(xué)位論文]. 南京： 南京大學(xué),2016.

8楊素素. 基于Storm的城市消防聯(lián)網(wǎng)遠(yuǎn)程監(jiān)控系統(tǒng)的實(shí)時(shí)數(shù)據(jù)處理應(yīng)用. 計(jì)算機(jī)測(cè)量與控制,2017,25(3)： 55-59.

9楊婷婷. 基于出租車GPS軌跡數(shù)據(jù)的實(shí)時(shí)交通狀態(tài)獲取和現(xiàn)有實(shí)時(shí)路況系統(tǒng)評(píng)估[碩士學(xué)位論文]. 上海： 華東師范大學(xué),2016.

10McCreadie R,Macdonald C,Ounis I,et al. Scalable distributed event detection for twitter. 2013 IEEE International Conference on Big Data. Silicon Valley,CA,USA.2013. 543-549.

11Namiot D. On big data stream processing. International Journal of Open Information Technologies,2015,3(8)：48-51.

12Maarala AI,Rautiainen M,Salmi M,et al. Low latency analytics for streaming traffic data with Apache Spark. 2015 IEEE International Conference on Big Data (Big Data). Santa Clara,CA,USA. 2015. 2855-2858.

13Nair LR,Shetty SD,Shetty SD. Applying spark based machine learning model on streaming big data for health status prediction. Computers & Electrical Engineering,2018,65(1)： 393-399. [doi： 10.1016/j.compeleceng.2017.03.009]