分布式高鐵動車組PHM大數據架構設計與實現

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

?

分布式高鐵動車組PHM大數據架構設計與實現

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

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

在高鐵動車組的故障預測與健康管理系統設計中，采用傳統數據庫或單一的大數據平臺難以達到系統精確預測故障的業務功能設計的準確度要求，PHM大數據架構設計需綜合考慮海量數據的膨脹、數據協議的復雜度、在線機理模型的變化以及機器學習的訓練等因素。本文基于多組件的大數據生態技術分層架構體系進行設計與實現，詳細闡述了高鐵動車組的故障預測與健康管理大數據平臺架構設計的方法和實現過程。

大數據架構；軌跡回放；流計算；負載均衡；實體主機

0 引言

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

本文基于分布式大數據平臺架構設計滿足實時監控、在線規則引擎配置與計算、離線分析和數據挖掘，構建各業務部門各種業務機理模型和分析平臺。

1 技術選型

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

1.1 大數據平臺選型

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

表1對比各種大數據平臺的升級能力和社區活躍度，并結合PHM業務要求機理模型多、平臺升級快、擴展性強的特點，因此選擇hdp版本作為分布式存儲與分布式計算的基礎大數據平臺。

表1 主流大數據平臺關鍵點對比表

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

1.2 流計算引擎選型

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

同時從工程師擅長java/scala/python/R等多種編程語言的角度出發，結合高鐵動車組的流式二進制解析、結構化數據、文本、圖式json等格式消息，而且業務處理效率允許3秒延遲，因此綜合考慮流技術引擎選擇spark-streaming。

1.3 大數據低延遲高并發數據讀取

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

2 關鍵技術

根據高鐵動車組的業務模型和應用要求，PHM大數據平臺關鍵技術分為流式二進制解析、分布式計算資源負載均衡、在線規則引擎、集群資源虛擬化、數據鏈路可視化、海量數據聚合計算和大數據平臺調優。

2.1 流式二進制數據解析

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

2.2 分布式計算資源負載均衡

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

圖1 并行隊列資源負載均衡圖

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

由于PHM大數據平臺前端web訪問量不是海量訪問，因此負載均衡使用nginx的默認輪詢算法就能保障平臺的穩定性。

2.3 在線規則引擎

本系統在線挖掘業務要求數據流程可配置、算法可熱拔插、支持數學計算算法（含機器學習算法）、規則托拉拽配置。保證單條數據機理模型監控算法計算，并能實現分鐘級別的窗口數據聚合計算，因此后臺規則引擎采用apache camel實現數學計算公式，集成spark-mlib算法庫，數據流程采用streamsets進行配置管理，定制開發能托拉拽的在線規則引擎。

2.4 集群資源虛擬化

集群計算資源虛擬化是利用閑置資源和保障平臺穩定性的技術基礎，使用Docker實現元數據庫封裝、功能組模封裝、數據挖掘訓練資源封裝，可保障大數據集群資源在磁盤I/O、通信網絡、CPU內核線程數和內存合理的分配。

2.5 數據鏈路監控

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

2.6 大數據平臺調優

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

3 分布式高鐵PHM大數據架構設計

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

3.1 數據層

數據來源采用sqoop、flume、企業服務總線（Enterprise Service Bus，ESB）等組件配置采集，使用統一標準的數據采集校驗接口機制。同時將業務數據劃分為實時流式數據處理，在線規則引擎分析，離線數據統計分析。系統中流式數據劃分兩層：

圖2 分布式高鐵PHM大數據系統架構

第一層：非結構化基礎流式標簽和窗口數據標簽模型，主要進行二進制數據轉換、拆分、分揀等基礎傳感器邏輯值和模擬量。同時為復合型的需要時間窗口進行邏輯值的平均值、最值計算、累計值、連續性等基礎標簽。

第二層：業務主題結構化模型需將非結構化語言表述數據轉換成結構化主題模型，PHM采用流式計算與在線規則引擎以降低數據挖掘難度。

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

3.2 平臺層

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

3.3 功能層

關鍵業務功能需在海量數據里面提取部分數據進行軌跡回放仿真演示[3]，業務人員等待5秒之內，提取7天傳感器狀態和故障數據，并通過GIS地圖參數進行回放的方法可解決實時監控無法做仿真分析的技術難點。其列車軌跡回放仿真功能見 圖3。

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

通過圖3的列車軸溫與直流電壓、三次側電壓的狀態軌跡回放仿真功能圖，業務人員能過濾故障發生時的相關機理傳感器數值進行模擬仿真，可輔助檢修人員對故障發生時間段進行相關機理分析。

4 分布式高鐵PHM大數據系統實踐

PHM系統前期采用分布式的虛擬機環境，發現共享I/O會導致網絡通信異常問題，同時發現CPU和內存性能指標不穩定。因此后期采用X86物理機在私有云大數據平臺的硬件性能得到保障后，PHM系統穩定性大大提高，不會出現重啟大數據平臺情況，系統滿足實時機理模型、在線規則引擎挖掘和離線數據分析的業務要求。系統實施過程中對大數據組件產品和應用功能進行測試論證時需部署測試環境集群和PHM大數據生產平臺兩個集群，網絡拓撲如圖4所示。

圖4所示，測試環境采用docker虛擬10臺主機部署hadoop。生產環境部署了14臺計算/數據節點，2臺管理節點，2臺前置互聯網接口機，3臺kafka消息集群，3臺元數據服務器，3臺web服務器。

分布式大數據平臺上部署hadoop/hbase/hive/ spark/Elasticsearch等大數據組件產品，實測3T大小的高鐵狀態和故障數據性能指標見表2。

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

圖4 高鐵動車組PHM大數據平臺網絡拓撲圖

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

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

5 結論

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

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

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

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

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

[5] 王逸飛, 張行, 何迪等. 基于大數據平臺的電網防災調度系統功能設計與系統架構[J]. 電網技術, 2016, 40(10): 3213- 3219.

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

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

[8] 陳惠娟, 加云崗. 大數據時代下的信貸風險預警系統研究[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-)，女，碩士，講師，主要研究方向：信號與信息處理、大數據挖掘；王偉(1991-)，男，研究生，信息技術工程師，主要研究方向：大數據挖掘；姜喜民(1979-)，男，本科，大數據主管，主要研究方向：信息化規劃、大數據架構；劉光俊(1993-)，男，本科，助理工程師，主要研究方向：數據統計分析，大數據挖掘。

趙珂，王偉，姜喜民，等. 分布式高鐵動車組PHM大數據架構設計與實現[J]. 軟件，2018，39（12）：90-94