張春風, 申 飛, 張 俊, 陳 杰, 劉 靜

1(中國科學院 強磁場科學中心,合肥 230031)

2(中國科學技術大學,合肥 230026)

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

1 實時流相關技術

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

1.1 Storm流式計算框架

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

(1) 簡單的編程模型. 類似于MapReduce降低了并行批處理復雜性,降低了進行實時處理的復雜性.

(2) 容錯性. Storm會管理工作進程和節(jié)點的故障.

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

(4) 可靠的消息處理. Storm保證每個消息至少能得到一次完整處理. 任務失敗時,它會負責從消息源重試消息.

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

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

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

2 系統(tǒng)架構設計

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

圖1 系統(tǒng)架構圖

系統(tǒng)采用層次化結構的設計原理,每個部分的主要功能如下：

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

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

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

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

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

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

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

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

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

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

圖2 緩存轉發(fā)架構

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

2.3 實時分析層

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

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

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

圖3 實時分析拓撲

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

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

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

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

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

表2 實時車輛信息表

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

(2) 將Storm中分析的最新實時數(shù)據(jù)緩存到內(nèi)存數(shù)據(jù)庫Redis中,利用Redis高性能操作和運算上的優(yōu)勢,為數(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ù)存儲層中所有車輛實時信息提供統(tǒng)一的查詢?nèi)肟?將車輛軌跡分析結果以可視化的形式展現(xiàn). 本系統(tǒng)使用Dubbo分布式服務框架,將核心業(yè)務抽取出來,作為獨立的服務,使前端應用能更快速和穩(wěn)定的響應,解決了服務器單點故障,方便后期的拓展和維護. 可視化展示主要包括以下幾個方面：

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

(2) 根據(jù)車輛行使的路段,利用百度地圖查詢該地段的限速大小,并與車輛當前速度進行比較,檢測是否超速,如果超速,給予駕駛員警告.

(3) 電子圍欄,將車輛的位置信息與規(guī)定行使區(qū)域實時進行比較,檢測是否超出預定的行駛路線.

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

3 實驗分析

實驗主要驗證系統(tǒng)的功能和Storm實時分析的效率. 通過部署局域網(wǎng)的10臺PC機,搭建集群進行測試. 實驗環(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,單機計算機節(jié)點配置： 內(nèi)存大?。?8 G,CPU型號： intel Core i5,磁盤500 G. 本次實驗系統(tǒng)部署架構,集群各個節(jié)點的配置和功能描述如表3所示. 數(shù)據(jù)源是網(wǎng)約車平臺共享的數(shù)據(jù),將數(shù)據(jù)源以日志的形式存儲在本地硬盤中,通過讀取文件來模擬車載終端發(fā)送的大量數(shù)據(jù)流.

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

3.1 功能測試

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

圖4 實時定位圖

圖5 軌跡查詢圖

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

3.2 性能測試

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

圖6 Java線程池與Storm運行時間對比

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

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

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

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

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

4 結論與展望

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

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

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

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

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

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

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

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

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

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

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