基于大數據的電動汽車報文實時分析系統設計與實現

周佳佳

(南通市測繪院有限公司 江蘇 南通 226000)

1 引 言

隨著新能源技術的日漸成熟，電動汽車的市場占有量越來越大，在安全以及補貼的標準上，國家明確車企需要實時監控電動汽車的電池狀況、電壓狀況、車輛狀態、溫度狀況和地理位置(地理位置獲取只限公共汽車)等信息，對故障信息等進行分析、預警處理。而面對海量的電動汽車報文數據，常規的分析系統已無法滿足其性能要求，因此本文采用基于大數據框架Flume+Kafka+Storm+HBase的組合來組建實時分析系統。Flume+Kafka+Storm+HBase的組合技術，是一個流程化的組合，涉及報文數據實時分析的完整生命流程，詳細流程包含數據采集、數據緩沖、數據清洗-分析計算、結果入庫四個步驟。

2 電動汽車報文實時分析系統設計

電動汽車報文實時分析系統相比較傳統的分析系統，實時分析系統具備了高并發、低延時、高可擴展、高可用的特性。

系統核心結構由數據源、數據緩沖區、實時數據清洗-分析器、結果存儲區四部分組成。其系統總體結構如圖1所示。

圖1 系統總體結構圖

系統的整個流程包含采集報文數據、報文數據緩沖、實時分析、結果入庫四個步驟，其詳細流程為：

(1)平臺將數據源中需要處理的數據推送到數據緩沖區。

(2)實時數據清洗-分析器的入口線程以輪詢的方式從數據緩沖區拉取數據。

(3)實時數據清洗-分析器的入口線程拉取數據后，轉發到數據清洗線程，進行數據清洗。如遇到無效數據，則將數據轉回數據緩沖區的無效數據區進行存儲，實時主流程繼續從數據緩沖區拉取新數據處理。

(4)實時數據清洗-分析器清洗完成后，將結果轉發到分析計算線程，進行實時分析。

(5)實時數據清洗-分析器分析計算完成后，將結果數據轉發到入庫線程。

(6)入庫線程最終將結果數據存入結果存儲區。

2.1 數據源

在數據源層中，將所有數據分為主動數據和被動數據兩類：

(1)主動數據：可以主動向緩沖區發送數據的稱為主動數據，如坐標轉換接口中需要被轉換的原始坐標數據，在接口中可以直接將數據推入緩沖區。

(2)被動數據：需要借助外界手段將數據推送到緩沖區的稱為被動數據。如電動汽車報文數據，它是一個不斷累加的文本數據，它無法直接進入緩沖區，因此是被動數據。

當前系統采用Flume集群來對被動數據進行推送。

2.2 數據緩沖區

數據緩沖區需要滿足分布式、高可用、數據容災、高吞吐量、多計算共用數據的特點，因此實現時采用Kafka組件作為基礎運行環境，在此基礎上，針對不同的實時計算業務，可以建立不同的消息隊列，也可以使用同一個消息隊列，這取決于具體的業務。

在電動汽車報文實時分析系統中，基于Kafka建立一個Topics，該Topics負責接收數據源端的數據，進行分區存儲以及被后續流程消費數據。該Topics被分為100個Partition。

2.3 實時數據清洗-分析器

實時數據清洗-分析器包含兩部分：數據清洗、分析計算。數據清洗主要是將接收到的報文數據進行基本校驗、完整性校驗、有效性校驗，分析計算主要是將數據在業務上進行分析判斷、歸類。

采用Storm組件作為該層的基礎運行環境，其內容包含數據拉取器、數據分析線程組。分析器的執行流程為：數據拉取→報文分析→存儲。

2.4 結果存儲區

由于整個平臺需要處理海量數據，對于計算結果，可能會比原始數據更為龐大，因此采用列式數據庫HBase。實時數據清洗-分析器將數據分析后，分類進行存儲在HBase中。

3 電動汽車報文實時分析系統實現

3.1 基礎環境

軟件基礎設施包含Flume、Kafka、Storm、HBase四個功能性集群。

3.2 實時分析系統開發

3.3.1 表結構

表結構包含：主報文表、報警報文表、心跳校時報文表、錯誤表，其中主報文表存儲所有分析后的報文數據，其結構如表1所示。

主報文表 表1

3.3.2 程序結構

程序以jar包的形式運行在Storm環境中。程序結構包含公用庫(common)、實時計算(realcalcmsg)、查詢接口(webapi)三部分，如圖2所示。

圖2 結果存儲區結構圖

(1)公用庫

公用庫中包含配置項、工具包、報文解析算法。

(2)數據清洗-實時計算

實時計算中包含topology、spout、bolt、utils四類代碼。

①topology為RealCalcMessageTopology類，用來組織、管理spout和bolt程序；

②spout為CarMsgSpout類，用來輪詢地拉取kafka中的數據；

③bolt中分為報文分析(TopicMessageRichBolt為數據清洗-分析)、結果存儲(MainMessageBolt為主報文結果存儲，AlertMessageBolt為報警報文結果存儲，OtherMessageBolt為心跳終端校時報文結果存儲，FailMessageBolt為非法報文結果存儲)兩類。

(3)查詢接口

查詢接口中主要包含controller、mapper、model、service、test、utils六類代碼，基于Spring boot、MyBatis框架為基礎實現。

3.3.3 關鍵技術實現

(1)基于Storm的數據清洗-實時計算程序流程

CarMsgSpout程序對kafka的topic進行監聽，如果topic中有新的報文數據，則取出一條，將報文數據傳遞給TopicMessageRichBolt程序；TopicMessageRichBolt得到數據后，對該條報文進行解析，將字符串報文拆分成多個具有業務意義的字段，再對字段進行有效性驗證，根據驗證結果，分發到對應的存儲bolt(Main、Alert、Other、Fail)中。實時計算的流程如圖3所示。

圖3 電動汽車報文實時計算流程圖

(2)報文解析

電動汽車報文以16進制的字符串形式進行傳輸。報文數據的解析基于有限狀態機的思想設計程序。

解析程序的狀態機有三種狀態：

①CHECK_STATE_MESSAGE，解析報文；

②CHECK_STATE_HEADER，解析報文頭部信息；

③CHECK_STATE_CONTENT，解析報文正文。

報文進入解析時，初始狀態為CHECK_STATE_MESSAGE，每個狀態下都會執行對應的解析任務，只有解析正常的，才能夠進入下一個狀態，否則，即解析完成。模型如圖4所示。

圖4 基于有限狀態機的報文解析模型圖

4 案例應用

某車企基于本系統對電動汽車進行實時數據的監控與預警(圖5)，該應用綜合指標：

圖5 數據清洗-分析器性能監控圖

(1)高并發：支持10萬輛車每秒一次的頻率發送報文數據；

(2)低延時：10萬輛車同時在線的情況下，單條報文計算耗時 2 ms，存儲小于 600 ms；

(3)高擴展性：目前計算節點3個，存儲節點5個，并支持計算節點、存儲節點的橫向擴展；

(4)高可用性：計算節點或主控節點出現故障導致無法計算時，自動將任務轉移到計算節點或備用主控節點上。

支持同時處理10萬輛車的實時報文數據，其單條報文的分析耗時 2 ms，單條報文的存儲 100 ms；當前計算節點3個，支持計算節點的橫向擴展。

某車企基于本系統對電動汽車進行實時數據的監控與預警，如圖6所示。

圖6 電動汽車實時數據的監控與預警圖

本文采用的組合技術方案與常用的方案進行了比較，如表2所示。

技術方案比較表 表2

經過對比發現，本文技術在實時性、可擴展性、高可用性方面較常用方案有很大的優勢。

5 結論與展望

本文采用基于Flume+Kafka+Storm+HBase的大數據技術，實現了電動汽車報文實時分析系統，其優勢主要有三點，一是低延時性，保證了車輛分析和預警的及時性；二是高并發性，保證了最大在線車輛監控的性能需求；三是高可用性，在某些基礎設施發生故障后，依然可以保證系統的正常運行；四是高可擴展性，為將來電動汽車擁有量越來越大提供了擴展空間。

本文所闡述的技術與系統不僅僅能應用在電動汽車領域，也可應用在其他有高實時性需求的行業。