趙 珂，王 偉，姜喜民，劉光俊

?

分布式高鐵動車組PHM大數(shù)據(jù)架構(gòu)設(shè)計與實現(xiàn)

趙 珂1，王 偉2，姜喜民2，劉光俊2

（1. 昆明理工大學(xué) 城市學(xué)院，云南 昆明 650051；2. 中車青島四方機(jī)車車輛股份有限公司，山東 青島 266111）

在高鐵動車組的故障預(yù)測與健康管理系統(tǒng)設(shè)計中，采用傳統(tǒng)數(shù)據(jù)庫或單一的大數(shù)據(jù)平臺難以達(dá)到系統(tǒng)精確預(yù)測故障的業(yè)務(wù)功能設(shè)計的準(zhǔn)確度要求，PHM大數(shù)據(jù)架構(gòu)設(shè)計需綜合考慮海量數(shù)據(jù)的膨脹、數(shù)據(jù)協(xié)議的復(fù)雜度、在線機(jī)理模型的變化以及機(jī)器學(xué)習(xí)的訓(xùn)練等因素。本文基于多組件的大數(shù)據(jù)生態(tài)技術(shù)分層架構(gòu)體系進(jìn)行設(shè)計與實現(xiàn)，詳細(xì)闡述了高鐵動車組的故障預(yù)測與健康管理大數(shù)據(jù)平臺架構(gòu)設(shè)計的方法和實現(xiàn)過程。

大數(shù)據(jù)架構(gòu)；軌跡回放；流計算；負(fù)載均衡；實體主機(jī)

0 引言

在高鐵動車組的車載故障預(yù)測與健康管理系統(tǒng)（Prognostic and Health Management，PHM）中難以實時實現(xiàn)多工況機(jī)理模型關(guān)聯(lián)對比分析、長時序分析、多平臺數(shù)據(jù)融合分析。因此路局服務(wù)站和主機(jī)廠檢修維護(hù)只能采用線下PHM大數(shù)據(jù)平臺實現(xiàn)高鐵動車組的實時監(jiān)控與在線決策的方法來實時掌控運(yùn)營中的高鐵動車組狀態(tài)和故障情況。PHM大數(shù)據(jù)平臺使用移動通信網(wǎng)絡(luò)或互聯(lián)網(wǎng)實時與非實時兩種方式采集車地數(shù)據(jù)傳輸系統(tǒng)/高鐵檢修服務(wù)系統(tǒng)/數(shù)據(jù)離線采集系統(tǒng)/線路資源系統(tǒng)等多系統(tǒng)平臺的數(shù)據(jù)進(jìn)行智能診斷和信息分析[1]。只有綜合利用車載數(shù)據(jù)、地面監(jiān)控數(shù)據(jù)才能構(gòu)建更為高效的高鐵動車組的地面PHM系統(tǒng)。

本文基于分布式大數(shù)據(jù)平臺架構(gòu)設(shè)計滿足實時監(jiān)控、在線規(guī)則引擎配置與計算、離線分析和數(shù)據(jù)挖掘，構(gòu)建各業(yè)務(wù)部門各種業(yè)務(wù)機(jī)理模型和分析平臺。

1 技術(shù)選型

技術(shù)選型需綜合考慮項目實施工期、工程師大數(shù)據(jù)技能、業(yè)務(wù)應(yīng)用要求、計算效率、安全性、高可用、Nosql、結(jié)構(gòu)化與非結(jié)構(gòu)化、可擴(kuò)展算法等，并滿足PHM監(jiān)控、流計算、海量數(shù)據(jù)聚合計算、長時序查詢、在線挖掘、在線規(guī)則引擎與離線分析挖掘，而使用關(guān)系型數(shù)據(jù)庫（Relational Database Management System，RMDBS）或大規(guī)模并行處理數(shù)據(jù)庫（Mass-ively Parallel Processor，MPP）都很難滿足應(yīng)用多樣性要求。因此只能采用分布式計算與分布式存儲的大數(shù)據(jù)架構(gòu)才能滿足業(yè)務(wù)要求。

1.1 大數(shù)據(jù)平臺選型

業(yè)務(wù)數(shù)據(jù)來源主要從動車組車載信息無線傳輸系統(tǒng)（Wireless Transmission System ,WTD）的二進(jìn)制通信數(shù)據(jù)包，圖紙數(shù)據(jù)文件，辦公文件，高鐵檢修系統(tǒng)（Maintenance, Repair & Operations，MRO），生產(chǎn)制造質(zhì)量系統(tǒng)（Quality Management System，QMS），生產(chǎn)制造工藝管理系統(tǒng)（Manufacturing Exe-cution System，MES），企業(yè)采購系統(tǒng)（Enterprise Resource Planning，ERP）等業(yè)務(wù)系統(tǒng)的業(yè)務(wù)數(shù)據(jù)。采用傳統(tǒng)RMDBS數(shù)據(jù)庫是無法實現(xiàn)高鐵動車組PHM大數(shù)據(jù)平臺的業(yè)務(wù)要求。因此PHM大數(shù)據(jù)平臺需具備很強(qiáng)的升級能力和擴(kuò)展性。

表1對比各種大數(shù)據(jù)平臺的升級能力和社區(qū)活躍度，并結(jié)合PHM業(yè)務(wù)要求機(jī)理模型多、平臺升級快、擴(kuò)展性強(qiáng)的特點，因此選擇hdp版本作為分布式存儲與分布式計算的基礎(chǔ)大數(shù)據(jù)平臺。

表1 主流大數(shù)據(jù)平臺關(guān)鍵點對比表

Tab.1 Key point comparison table of mainstream big data platform

1.2 流計算引擎選型

從apache社區(qū)可選擇Storm、Samza和spark- streaming等流計算引擎。Samza使用一個嵌入的key-value存儲；storm可使用類sql進(jìn)行流式數(shù)據(jù)操作，而這兩種引擎對二進(jìn)制解析、圖操作和機(jī)器學(xué)習(xí)等業(yè)務(wù)就比較困難。但spark-streaming不僅能實現(xiàn)二進(jìn)制解析、圖操作和機(jī)器學(xué)習(xí)，并能結(jié)合SQL，Mllib，GraphX實現(xiàn)機(jī)理模型和在線挖掘。

同時從工程師擅長java/scala/python/R等多種編程語言的角度出發(fā)，結(jié)合高鐵動車組的流式二進(jìn)制解析、結(jié)構(gòu)化數(shù)據(jù)、文本、圖式j(luò)son等格式消息，而且業(yè)務(wù)處理效率允許3秒延遲，因此綜合考慮流技術(shù)引擎選擇spark-streaming。

1.3 大數(shù)據(jù)低延遲高并發(fā)數(shù)據(jù)讀取

高鐵動車組的傳感器和邏輯開關(guān)每天產(chǎn)生大于40億條邏輯值和模擬量數(shù)據(jù)。檢修運(yùn)維人員需結(jié)合歷史數(shù)據(jù)對比分析高鐵動車組的實時狀態(tài)和故障情況。根據(jù)系統(tǒng)一次寫入多次讀取的使用特點，選擇基于hdfs分布式存儲的KV數(shù)據(jù)庫引擎hbase，作為低延遲高并發(fā)的數(shù)據(jù)存儲數(shù)據(jù)庫[2]。

2 關(guān)鍵技術(shù)

根據(jù)高鐵動車組的業(yè)務(wù)模型和應(yīng)用要求，PHM大數(shù)據(jù)平臺關(guān)鍵技術(shù)分為流式二進(jìn)制解析、分布式計算資源負(fù)載均衡、在線規(guī)則引擎、集群資源虛擬化、數(shù)據(jù)鏈路可視化、海量數(shù)據(jù)聚合計算和大數(shù)據(jù)平臺調(diào)優(yōu)。

2.1 流式二進(jìn)制數(shù)據(jù)解析

上千列高鐵每秒產(chǎn)生4 MB以上的二進(jìn)制消息，解析后達(dá)到40 MB/s以上。使用spark-streaming進(jìn)行二進(jìn)制解析、規(guī)則映射、數(shù)學(xué)計算、數(shù)據(jù)過濾、數(shù)據(jù)分揀、數(shù)據(jù)關(guān)聯(lián)、時序計算和聚合計算等過程，在不重啟流計算引擎的情況下，可滿足機(jī)理模型熱部署和消息流分層的復(fù)雜性要求，也能滿足海量數(shù)據(jù)聚合計算效率。

2.2 分布式計算資源負(fù)載均衡

高鐵動車組PHM大數(shù)據(jù)平臺業(yè)務(wù)訪問并發(fā)數(shù)大和計算復(fù)雜，需計算資源的CPU核數(shù)（線程數(shù)）與內(nèi)存分配比較合理，按照平臺資源劃分為后臺任務(wù)并行隊列資源負(fù)載均衡與前端web訪問負(fù)載均衡，如圖1所示。

圖1 并行隊列資源負(fù)載均衡圖

圖1中后臺任務(wù)并行隊列主要使用yarn的多租戶計算資源管理方法進(jìn)行分配，劃分為spark streaming計算資源，hbase計算資源，hive計算資源，ES計算資源，后臺業(yè)務(wù)程序計算資源。后臺業(yè)務(wù)程序計算主要依賴yarn進(jìn)行分配和調(diào)度，但由于存在本地單節(jié)點計算，因此在單一租戶的情況下，采用加權(quán)輪詢調(diào)度算法（Weighted Round Robin，WRR）進(jìn)行任務(wù)負(fù)載均衡動態(tài)申請集群計算資源，可以實現(xiàn)不同節(jié)點的計算資源空閑情況進(jìn)行加權(quán)負(fù)載均衡。

由于PHM大數(shù)據(jù)平臺前端web訪問量不是海量訪問，因此負(fù)載均衡使用nginx的默認(rèn)輪詢算法就能保障平臺的穩(wěn)定性。

2.3 在線規(guī)則引擎

本系統(tǒng)在線挖掘業(yè)務(wù)要求數(shù)據(jù)流程可配置、算法可熱拔插、支持?jǐn)?shù)學(xué)計算算法（含機(jī)器學(xué)習(xí)算法）、規(guī)則托拉拽配置。保證單條數(shù)據(jù)機(jī)理模型監(jiān)控算法計算，并能實現(xiàn)分鐘級別的窗口數(shù)據(jù)聚合計算，因此后臺規(guī)則引擎采用apache camel實現(xiàn)數(shù)學(xué)計算公式，集成spark-mlib算法庫，數(shù)據(jù)流程采用streamsets進(jìn)行配置管理，定制開發(fā)能托拉拽的在線規(guī)則引擎。

2.4 集群資源虛擬化

集群計算資源虛擬化是利用閑置資源和保障平臺穩(wěn)定性的技術(shù)基礎(chǔ)，使用Docker實現(xiàn)元數(shù)據(jù)庫封裝、功能組模封裝、數(shù)據(jù)挖掘訓(xùn)練資源封裝，可保障大數(shù)據(jù)集群資源在磁盤I/O、通信網(wǎng)絡(luò)、CPU內(nèi)核線程數(shù)和內(nèi)存合理的分配。

2.5 數(shù)據(jù)鏈路監(jiān)控

傳統(tǒng)離線數(shù)據(jù)采集技術(shù)實現(xiàn)數(shù)據(jù)鏈路監(jiān)控比較容易，但若基于大數(shù)據(jù)流式實時計算時會經(jīng)常出現(xiàn)多種原因的數(shù)據(jù)丟失。因此需采用kafka的消息緩存機(jī)制，每天定時進(jìn)行數(shù)據(jù)鏈路比對，自動觸發(fā)從kafka提取二進(jìn)制消息數(shù)據(jù)進(jìn)行處理和計算，并將每個流計算環(huán)節(jié)的日志寫入hbase日志中。部署數(shù)據(jù)鏈路展示前端功能進(jìn)行實時監(jiān)控，發(fā)生問題及時通過短信提醒運(yùn)維人員并進(jìn)行人工干預(yù)分析。

2.6 大數(shù)據(jù)平臺調(diào)優(yōu)

大數(shù)據(jù)平臺調(diào)優(yōu)劃分操作系統(tǒng)、集群資源、任務(wù)隊列和功能代碼四個方向。操作系統(tǒng)調(diào)優(yōu)包含網(wǎng)絡(luò)通信、防火墻策略、文件權(quán)限、文件夾目錄、I/O讀寫規(guī)劃、CPU規(guī)劃、內(nèi)存規(guī)劃和系統(tǒng)補(bǔ)丁與關(guān)聯(lián)內(nèi)核調(diào)整等。集群資源調(diào)優(yōu)主要采用多租戶的計算資源分配、平臺軟件參數(shù)調(diào)整、吞吐量優(yōu)化等。任務(wù)隊列調(diào)優(yōu)采用將24小時按照分鐘級時間片段、作業(yè)優(yōu)先級、依賴關(guān)系等進(jìn)行執(zhí)行計劃編排，防止單租戶在同一時間的集群資源利用率達(dá)到90%以上。功能代碼調(diào)優(yōu)采用測試環(huán)境論證資源開銷情況，并進(jìn)行代碼級檢查分析程序異常和執(zhí)行效率。

3 分布式高鐵PHM大數(shù)據(jù)架構(gòu)設(shè)計

分布式高鐵PHM大數(shù)據(jù)架構(gòu)設(shè)計既要滿足實時流式計算、長時序聚合計算、在線規(guī)則引擎挖掘、離線分析計算，也要滿足歷史數(shù)據(jù)過濾搜索，同時要求保障大數(shù)據(jù)平臺在規(guī)定的年限內(nèi)不做存儲和計算資源擴(kuò)容。其平臺架構(gòu)分層設(shè)計如圖2所示。

3.1 數(shù)據(jù)層

數(shù)據(jù)來源采用sqoop、flume、企業(yè)服務(wù)總線（Enterprise Service Bus，ESB）等組件配置采集，使用統(tǒng)一標(biāo)準(zhǔn)的數(shù)據(jù)采集校驗接口機(jī)制。同時將業(yè)務(wù)數(shù)據(jù)劃分為實時流式數(shù)據(jù)處理，在線規(guī)則引擎分析，離線數(shù)據(jù)統(tǒng)計分析。系統(tǒng)中流式數(shù)據(jù)劃分兩層：

圖2 分布式高鐵PHM大數(shù)據(jù)系統(tǒng)架構(gòu)

第一層：非結(jié)構(gòu)化基礎(chǔ)流式標(biāo)簽和窗口數(shù)據(jù)標(biāo)簽?zāi)Ｐ停饕M(jìn)行二進(jìn)制數(shù)據(jù)轉(zhuǎn)換、拆分、分揀等基礎(chǔ)傳感器邏輯值和模擬量。同時為復(fù)合型的需要時間窗口進(jìn)行邏輯值的平均值、最值計算、累計值、連續(xù)性等基礎(chǔ)標(biāo)簽。

第二層：業(yè)務(wù)主題結(jié)構(gòu)化模型需將非結(jié)構(gòu)化語言表述數(shù)據(jù)轉(zhuǎn)換成結(jié)構(gòu)化主題模型，PHM采用流式計算與在線規(guī)則引擎以降低數(shù)據(jù)挖掘難度。

數(shù)據(jù)鏈路主要按照實時流式計算主要采用spark- streaming封裝數(shù)據(jù)模型。運(yùn)用kafka存儲流式數(shù)據(jù)， 通過ETL工具和開源組件將數(shù)據(jù)輸出到hbase、hive和Elasticsearch中。

3.2 平臺層

高鐵動車組的機(jī)理模型訓(xùn)練和監(jiān)控算法閥值多次迭代訓(xùn)練都需要很多平臺資源，因此采用多租戶資源管理、作業(yè)計劃編排與資源權(quán)重監(jiān)控工具實時監(jiān)控平臺運(yùn)行的工作運(yùn)行效率和資源開銷。

3.3 功能層

關(guān)鍵業(yè)務(wù)功能需在海量數(shù)據(jù)里面提取部分?jǐn)?shù)據(jù)進(jìn)行軌跡回放仿真演示[3]，業(yè)務(wù)人員等待5秒之內(nèi)，提取7天傳感器狀態(tài)和故障數(shù)據(jù)，并通過GIS地圖參數(shù)進(jìn)行回放的方法可解決實時監(jiān)控?zé)o法做仿真分析的技術(shù)難點。其列車軌跡回放仿真功能見 圖3。

圖3 列車軌跡回放仿真功能圖

通過圖3的列車軸溫與直流電壓、三次側(cè)電壓的狀態(tài)軌跡回放仿真功能圖，業(yè)務(wù)人員能過濾故障發(fā)生時的相關(guān)機(jī)理傳感器數(shù)值進(jìn)行模擬仿真，可輔助檢修人員對故障發(fā)生時間段進(jìn)行相關(guān)機(jī)理分析。

4 分布式高鐵PHM大數(shù)據(jù)系統(tǒng)實踐

PHM系統(tǒng)前期采用分布式的虛擬機(jī)環(huán)境，發(fā)現(xiàn)共享I/O會導(dǎo)致網(wǎng)絡(luò)通信異常問題，同時發(fā)現(xiàn)CPU和內(nèi)存性能指標(biāo)不穩(wěn)定。因此后期采用X86物理機(jī)在私有云大數(shù)據(jù)平臺的硬件性能得到保障后，PHM系統(tǒng)穩(wěn)定性大大提高，不會出現(xiàn)重啟大數(shù)據(jù)平臺情況，系統(tǒng)滿足實時機(jī)理模型、在線規(guī)則引擎挖掘和離線數(shù)據(jù)分析的業(yè)務(wù)要求。系統(tǒng)實施過程中對大數(shù)據(jù)組件產(chǎn)品和應(yīng)用功能進(jìn)行測試論證時需部署測試環(huán)境集群和PHM大數(shù)據(jù)生產(chǎn)平臺兩個集群，網(wǎng)絡(luò)拓?fù)淙鐖D4所示。

圖4所示，測試環(huán)境采用docker虛擬10臺主機(jī)部署hadoop。生產(chǎn)環(huán)境部署了14臺計算/數(shù)據(jù)節(jié)點，2臺管理節(jié)點，2臺前置互聯(lián)網(wǎng)接口機(jī)，3臺kafka消息集群，3臺元數(shù)據(jù)服務(wù)器，3臺web服務(wù)器。

分布式大數(shù)據(jù)平臺上部署hadoop/hbase/hive/ spark/Elasticsearch等大數(shù)據(jù)組件產(chǎn)品，實測3T大小的高鐵狀態(tài)和故障數(shù)據(jù)性能指標(biāo)見表2。

表2對比可見分布式高鐵動車組PHM大數(shù)據(jù)平臺若采用單機(jī)版或虛擬機(jī)集群系統(tǒng)穩(wěn)定性得不到保障，同時效率和并發(fā)數(shù)都不能滿足業(yè)務(wù)要求，只有采用實體機(jī)集群能滿足業(yè)務(wù)部門的效率要求。服務(wù)檢修部門和工程中心在PHM上部署60多個機(jī)理模型，為保障計算資源的合理分配，PHM大數(shù)據(jù)平臺使用多租戶分配資源，以能充分保障平臺的穩(wěn)定性和較高的并發(fā)計算效率。

圖4 高鐵動車組PHM大數(shù)據(jù)平臺網(wǎng)絡(luò)拓?fù)鋱D

表2 單機(jī)版/虛擬機(jī)集群/實體機(jī)集群性能對比表

Tab.2 Single machine / virtual machine cluster/entity cluster performance comparison table

5 結(jié)論

本方案采用大數(shù)據(jù)生態(tài)技術(shù)分層架構(gòu)體系的方法，運(yùn)用成熟穩(wěn)定的開源hadoop大數(shù)據(jù)平臺，實現(xiàn)了高鐵動車組PHM系統(tǒng)的業(yè)務(wù)功能擴(kuò)展要求，滿足了業(yè)務(wù)上要求的流式計算、在線規(guī)則引擎數(shù)據(jù)挖掘和離線機(jī)理模型訓(xùn)練。在不影響業(yè)務(wù)數(shù)據(jù)分析與挖掘的運(yùn)算效率的情況下，能進(jìn)行核心部件多工況機(jī)理模型的長時序數(shù)據(jù)挖掘和離線機(jī)理模型訓(xùn)練。業(yè)務(wù)數(shù)據(jù)大小從每天0.6TB以上膨脹到1.3TB的情況，并且在不斷擴(kuò)展機(jī)理模型的情況下也不影響業(yè)務(wù)應(yīng)用性能。

[1] 田歆, 汪壽陽, 鄂爾江等. 零售大數(shù)據(jù)與商業(yè)智能系統(tǒng)的設(shè)計、實現(xiàn)與應(yīng)用[J]. 系統(tǒng)工程理論與實踐, 2017, 37(5): 1282-1293.

[2] 葛磊蛟, 王守相, 瞿海妮等. 智能配用電大數(shù)據(jù)存儲架構(gòu)設(shè)計[J]. 電力自動化設(shè)備, 2016, 36(6): 194-202.

[3] 黃聰. 基于大數(shù)據(jù)分析的城軌列車運(yùn)行路線追蹤研究[J]. 現(xiàn)代電子技術(shù), 2018, 41(5): 110-115.

[4] 羅偉雄, 時東曉, 劉嵐等. 數(shù)據(jù)虛擬化平臺的設(shè)計與實現(xiàn)[J]. 計算機(jī)應(yīng)用, 2017(37): 225-228.

[5] 王逸飛, 張行, 何迪等. 基于大數(shù)據(jù)平臺的電網(wǎng)防災(zāi)調(diào)度系統(tǒng)功能設(shè)計與系統(tǒng)架構(gòu)[J]. 電網(wǎng)技術(shù), 2016, 40(10): 3213- 3219.

[6] 趙征凡, 劉睛波, 黃萌等. 某型火炮預(yù)測與健康管理技術(shù)(PHM)體系結(jié)構(gòu)設(shè)計與應(yīng)用[J]. 計算機(jī)測量與控制, 2017, 25(12): 114-116.

[7] 李勇, 常天慶, 白帆等. 面向服務(wù)的裝甲裝備PHM體系結(jié)構(gòu)研究[J]. 計算機(jī)測量與控制, 2012, 20(7): 1880-1903.

[8] 陳惠娟, 加云崗. 大數(shù)據(jù)時代下的信貸風(fēng)險預(yù)警系統(tǒng)研究[J]. 軟件, 2018, 39(1): 39-44.

Design and Implementation of PHM Big Data Architecture for Distributed High-speed Rail EMU

ZHAO Ke1, WANG Wei2, JIANG Xi-min2, LIU Guang-jun2

(1. City College, Kunming University of Science and Technology, Kunming 650051, China; 2. China Railway Rolling Stock Corporation Qingdao Sifang Co. LTD, Qingdao 266111, China)

In the fault prediction of high-speed EMU and health management system design, the accuracy requirements of business function design using big data platform for traditional database or single system is difficult to achieve the accurate prediction of the fault, the design of PHM large data structure should be considered in massive data expansion, data protocol complexity, online mechanism model Type changes and machine learning training and other factors. In this paper, the hierarchical architecture system of big data components of ecological technology based on the design and implementation, and describes the methods for fault prediction of high-speed EMU and health management of big data platform architecture design and implementation process.

Big data architecture; Track replay; Stream computing; Load balancing; Entity host

TP391

A

10.3969/j.issn.1003-6970.2018.12.021

趙珂(1978-)，女，碩士，講師，主要研究方向：信號與信息處理、大數(shù)據(jù)挖掘；王偉(1991-)，男，研究生，信息技術(shù)工程師，主要研究方向：大數(shù)據(jù)挖掘；姜喜民(1979-)，男，本科，大數(shù)據(jù)主管，主要研究方向：信息化規(guī)劃、大數(shù)據(jù)架構(gòu)；劉光俊(1993-)，男，本科，助理工程師，主要研究方向：數(shù)據(jù)統(tǒng)計分析，大數(shù)據(jù)挖掘。

趙珂，王偉，姜喜民，等. 分布式高鐵動車組PHM大數(shù)據(jù)架構(gòu)設(shè)計與實現(xiàn)[J]. 軟件，2018，39（12）：90-94