基于云計算和大數(shù)據(jù)的模擬車輛行車監(jiān)控系統(tǒng)

草綠色 2019-10-25

展開全文

一、系統(tǒng)架構(gòu)

這是基于云計算和大數(shù)據(jù)的模擬車輛行車監(jiān)控系統(tǒng)，可模擬實現(xiàn)在線遠程對車輛行車的信息記錄以及數(shù)據(jù)處理。其中，記錄信息其中包括車輛的id、經(jīng)過的地點（經(jīng)緯度）、時間，數(shù)據(jù)處理包括對數(shù)據(jù)的排序、錯誤數(shù)據(jù)的排查、通過時間以及地點在地圖上獲得車輛行駛的軌跡、車輛相遇次數(shù)。

系統(tǒng)包括數(shù)據(jù)產(chǎn)生模塊、數(shù)據(jù)接受與處理模塊、數(shù)據(jù)庫模塊、客戶端模塊。其中kafka進行數(shù)據(jù)的接收,并進行數(shù)據(jù)過濾，將過濾后的數(shù)據(jù)傳遞給Redis，Redis再將數(shù)據(jù)存入Hbase數(shù)據(jù)庫，Spark從Hbase中獲得數(shù)據(jù)，將處理后的數(shù)據(jù)再傳遞回Hbase，客戶端從Hbase中獲得數(shù)據(jù)并將其展示在前端。

邏輯架構(gòu)如下：
這里寫圖片描述
物理架構(gòu)圖如下：

二、數(shù)據(jù)流程分析

1. 數(shù)據(jù)采集過程分析

數(shù)據(jù)采集過程包括Kafka數(shù)據(jù)采集、Redis數(shù)據(jù)過濾、Hbase數(shù)據(jù)入庫三部分，其中包括三個實體：Kafka生產(chǎn)者、Kafka消費者兼Redis發(fā)布者、Redis訂閱者。

數(shù)據(jù)采集
各自的作用如下：
Kafka生產(chǎn)者：負責(zé)從json文件中以行為單位讀取數(shù)據(jù)源，通過Kafka生產(chǎn)者代碼編寫生產(chǎn)消息，將json讀取的消息發(fā)布在topic上。

Kafka消費者兼Redis發(fā)布者：負責(zé)從topic上消費Kafka生產(chǎn)者生產(chǎn)的消息，將消息通過Redis發(fā)布訂閱功能發(fā)布到一個信道，等待訂閱者接受消息。

Redis訂閱者：負責(zé)訂閱發(fā)布者相應(yīng)的信道，接受發(fā)布者的消息，將消息存入Hbase數(shù)據(jù)庫。
數(shù)據(jù)過濾過程使用了Kafka streams對原始數(shù)據(jù)進行過濾，本小組采用HIGH-LEVEL STREAMS DSL進行處理。Kafka創(chuàng)建一個Filter流，流的源綁定filter-before topic，同時Kafka生成者將消息生產(chǎn)在這個topic上；流的出口綁定filter-after topic，Kafka消費者綁定這個topic消費消息。過濾器消息選擇條件過濾掉不正確的經(jīng)緯度數(shù)據(jù)，并將這部分數(shù)據(jù)存放在Redis filter 鍵里，合格的數(shù)據(jù)傳送到filter-after topic上。

Redis的緩沖作用
在Redis訂閱者上，由于生產(chǎn)者生產(chǎn)消息過快，如果選擇一條一條的存入數(shù)據(jù)庫，會出現(xiàn)存取數(shù)據(jù)過慢，導(dǎo)致生產(chǎn)者的消息經(jīng)過規(guī)定的時間(本小組設(shè)置的時間是90秒)沒有被消費，報出Timeout錯誤。為避免這樣的問題，選擇每1000條數(shù)據(jù)存入數(shù)據(jù)庫一次，這樣的方式優(yōu)點在于每1000條數(shù)據(jù)才請求連接數(shù)據(jù)庫一次。請求連接數(shù)據(jù)庫是較耗時的一個步驟，頻繁的請求連接數(shù)據(jù)庫會拖慢程序的運行時長。在基礎(chǔ)項時，選擇將所有數(shù)據(jù)存入list，然后一次請求數(shù)據(jù)庫連接，將所有數(shù)據(jù)存入數(shù)據(jù)庫，請求數(shù)據(jù)庫連接的時間占比很小。

出現(xiàn)的問題以及解決方案
1000條數(shù)據(jù)一次存入無法達到實時的記錄，這是本小組項目的一個缺點，但同時，這個問題可以通過選擇storm 流式框架數(shù)據(jù)處理來解決，直接在Kafka消費階段對數(shù)據(jù)進行流式處理能達到實時效果。

2.數(shù)據(jù)查詢和離線處理分析

數(shù)據(jù)查詢：數(shù)據(jù)采集完成，所有數(shù)據(jù)存入Hbase數(shù)據(jù)庫的‘Record’表中，行鍵設(shè)計為eid、placeid、time組合鍵，在數(shù)據(jù)查詢時，需要將行鍵截取，獲取對應(yīng)的數(shù)據(jù)，與查詢條件比較，返回滿足條件的數(shù)據(jù)。

spark處理：spark分析過程包含三個階段——程序源碼發(fā)布到master節(jié)點、master將map程序分配給map節(jié)點進行map操作、master將reduce程序分配給reduce節(jié)點進行reduce操作。數(shù)據(jù)流向是map節(jié)點從master節(jié)點獲取Hbase數(shù)據(jù)索引，進而獲取數(shù)據(jù)，接著運行map程序?qū)?shù)據(jù)分散處理。Map程序處理完的數(shù)據(jù)流入reduce進行聚合處理，最后將reduce結(jié)果存入Hbase數(shù)據(jù)庫中。
問題：在進行spark分析時，限于物理機，整個集群僅有一個master節(jié)點、一個map worker節(jié)點、一個reduce worker節(jié)點，在數(shù)據(jù)分析時出現(xiàn)的情況是map worker節(jié)點的工作任務(wù)量遠遠大于reduce worker的工作任務(wù)量。在任務(wù)啟動時，集群中各個節(jié)點使用top命令查看當(dāng)前節(jié)點的CPU占比，發(fā)現(xiàn)在整個任務(wù)中map worker 節(jié)點長時間高CPU占比工作，而reduce worker節(jié)點在map worker節(jié)點處理完成后有10秒左右的高CPU占比工作期，然后整個數(shù)據(jù)分析完成。鑒于上述的問題，考慮在主機充足的情況下，選擇為map任務(wù)分配多臺主機。使得任務(wù)執(zhí)行量較均勻分布。

三、軟件功能分析

1、完成基本搭建系統(tǒng)，完成過車統(tǒng)計功能

系統(tǒng)可根據(jù)輸入的地點ID進行檢索，顯示通過該地點的車輛ID、時間、地點以及經(jīng)緯度；或者根據(jù)輸入的車輛ID，顯示出該車輛經(jīng)過的地點、經(jīng)過時間以及對應(yīng)地點的經(jīng)緯度。
結(jié)果展示：
這里寫圖片描述

2.系統(tǒng)附加功能分析

（1）原始信息過濾

原始數(shù)據(jù)包含若干條錯誤記錄，如經(jīng)緯度不合法等，需要實時對kafka中接收到的數(shù)據(jù)進行過濾處理，將處理后的數(shù)據(jù)傳遞給Redis。
這里寫圖片描述

（2）車輛行駛軌跡重現(xiàn)

實現(xiàn)方式：我們想出了兩種方法實現(xiàn)其軌跡重新。
A、hbase方式
建立一張新表，重新編排行鍵。
在hbaseTest類中完成具體操作。首先使用HBaseConf類中的getConnection()方法與HBase數(shù)據(jù)庫進行連接。然后利用HBaseConf類中g(shù)etTableByName()方法得到對表“Record”表的操作句柄。同時使用相同的方法得到對Trace表的操作句柄。之后，使用Table類中的getScanner（）方法得到Record表中的所有數(shù)據(jù)，并記錄中“result”中。因為重現(xiàn)軌跡的時候只需要車輛的標(biāo)識信息（Eid）和車輛經(jīng)過的時間（time）和經(jīng)過地方的經(jīng)緯度（latitude，longitude）所以我們只需要在“Trace”表中存入這些數(shù)據(jù)即可。
現(xiàn)在我們已經(jīng)將得到的所有的“Record”表中的數(shù)據(jù)都存在了“result”中。然后將result中的所有數(shù)據(jù)掃描一遍，同時將每條記錄中的“Eid,time,latitude,longitude”信息記錄下來，同時將每一條記錄的這些信息作為新的一條記錄，以“Eid”為rowKey且以“time”為列族的第一列放在Put類的對象中，最后通過Table類的put()方法將新的記錄存在“Trace”表中。這樣得到的“Trace”表中的數(shù)據(jù)即會以“time”自動排序。
當(dāng)所有數(shù)據(jù)被讀取并被重新放入“Trace”表中后，關(guān)閉與數(shù)據(jù)庫的連接，所有的信息即被重新規(guī)劃好。

B、spark的MapReduce方式
展示結(jié)果：
輸入要查詢的車輛的ID，顯示其行駛軌跡。鼠標(biāo)點擊地點，可顯示其經(jīng)緯度。

軌跡展示結(jié)果：
這里寫圖片描述

（3）車輛相遇次數(shù)統(tǒng)計

我們定義相遇為“兩車之間出現(xiàn)在同一地點的時間間隔小于一分鐘”。
首先，通過Spark從Hbase表中讀取數(shù)據(jù)，自身以地點為鍵進行join操作，計算除自身外的車輛是否相遇；再以地點為鍵進行分組，同一組內(nèi)的數(shù)據(jù)按照時間進行排序，遍歷整個列表，找出滿足小于一分鐘的數(shù)據(jù)。

結(jié)果展示：
輸入要查詢的車輛Id，查詢結(jié)果顯示與之相遇過的車輛的ID以及次數(shù)。
這里寫圖片描述

四、實驗感受及收獲

在選修這門課之前，就已經(jīng)對云計算與大數(shù)據(jù)產(chǎn)生了濃厚的興趣，通過這學(xué)期對這個項目的完成，更加深了我對云計算與大數(shù)據(jù)的理解以及實際的應(yīng)用。此次我負責(zé)的部分是hbase對數(shù)據(jù)的存儲，通過這個項目我了解了nosql的特點以及運用。雖然在這個項目過程中，遇到了很多困難，但與隊友們一起不厭其煩地解決了，我在這個過程中學(xué)到了很多。希望在今后的云計算與大數(shù)據(jù)的學(xué)習(xí)道路上，可以克服重重困難，加深對其的學(xué)習(xí)。