基于分布式技術(shù)的動車組車載大數(shù)據(jù)存儲與檢索技術(shù)研究

扈海軍

（1 中國鐵道科學(xué)研究院集團(tuán)有限公司 機(jī)車車輛研究所，北京 100081；2 北京縱橫機(jī)電科技有限公司，北京 100094）

近年來，隨著復(fù)興號智能型動車組的陸續(xù)上線運(yùn)營，監(jiān)測數(shù)據(jù)項點(diǎn)不斷擴(kuò)充，數(shù)據(jù)量不斷增加。國鐵集團(tuán)通過動車組車載信息無線傳輸系統(tǒng)（Wireless Transit Device System，WTDS）采集動車組運(yùn)行過程中的重要參數(shù)、故障數(shù)據(jù)及位置數(shù)據(jù)等實(shí)時運(yùn)行數(shù)據(jù)，為國鐵集團(tuán)及路內(nèi)用戶、主機(jī)企業(yè)的相關(guān)應(yīng)用提供數(shù)據(jù)支撐，保證了動車組的安全有效運(yùn)行［1-4］。

動車組運(yùn)營過程中，還存在大量非實(shí)時運(yùn)行數(shù)據(jù)，主要有采樣密度較大的運(yùn)行數(shù)據(jù)、自診斷和日志數(shù)據(jù)等，是動車組故障診斷與運(yùn)行維護(hù)的重要數(shù)據(jù)，以此為基礎(chǔ)進(jìn)行車輛故障預(yù)警、關(guān)鍵零部件性能監(jiān)測以及零部件剩余壽命預(yù)測，指導(dǎo)運(yùn)維部門對車輛子系統(tǒng)的預(yù)防修與計劃修，輔助優(yōu)化修程修制等［5］。

非實(shí)時數(shù)據(jù)到站后通過無線傳輸?shù)礁鲃榆囘\(yùn)用所，每列動車組（標(biāo)準(zhǔn)組）日均數(shù)據(jù)量為2 GB，年均數(shù)據(jù)量可達(dá)720 GB，復(fù)興號動車組數(shù)據(jù)量更大。如何提高地面系統(tǒng)的數(shù)據(jù)轉(zhuǎn)儲和集中整體能力，統(tǒng)一匯集、存儲、管理各車載數(shù)據(jù)，實(shí)現(xiàn)高密度、大容量的數(shù)據(jù)落地、存儲與管理，成為我國動車組在安全運(yùn)營與健康管理方面開展大數(shù)據(jù)應(yīng)用面臨的重大挑戰(zhàn)［6-8］。

云計算、大數(shù)據(jù)、物聯(lián)網(wǎng)等新興技術(shù)的快速發(fā)展為解決上述問題提供了可能［9-10］。針對上述問題，文中從實(shí)際工程應(yīng)用角度出發(fā)，結(jié)合最新分布式技術(shù)和大數(shù)據(jù)技術(shù)提出了一種支持存儲、檢索動車組車載海量數(shù)據(jù)的系統(tǒng)架構(gòu)，并設(shè)計了分布式存儲與檢索技術(shù)，提升了數(shù)據(jù)存儲能力和數(shù)據(jù)檢索能力。

1 系統(tǒng)體系結(jié)構(gòu)

分布式動車組車載大數(shù)據(jù)系統(tǒng)是一個可擴(kuò)展的數(shù)據(jù)平臺，文中采用主、子節(jié)點(diǎn)分布式系統(tǒng)架構(gòu)，如圖1 所示，在主節(jié)點(diǎn)部署數(shù)據(jù)服務(wù)器集群，匯集各動車運(yùn)用所存儲的非實(shí)時數(shù)據(jù)文件索引信息，并建立動車組車載數(shù)據(jù)資源目錄。主節(jié)點(diǎn)用于實(shí)現(xiàn)子節(jié)點(diǎn)管理及配置、主節(jié)點(diǎn)用戶查詢等主要功能，起到數(shù)據(jù)服務(wù)中心的功能定位；子節(jié)點(diǎn)實(shí)現(xiàn)動車組非實(shí)時數(shù)據(jù)接收、存儲及子節(jié)點(diǎn)用戶訪問等主要功能。

圖1 分布式架構(gòu)

分布式動車組車載大數(shù)據(jù)系統(tǒng)服務(wù)架構(gòu)如圖2所示，自下而上主要包含4 層：

圖2 系統(tǒng)服務(wù)架構(gòu)

（1）硬件設(shè)備層

動車運(yùn)用所機(jī)房的服務(wù)器設(shè)備、網(wǎng)絡(luò)設(shè)備、存儲設(shè)備、負(fù)載均衡器、VPN/防火墻等硬件設(shè)備。

（2）數(shù)據(jù)采集層

通過無線端接入技術(shù)（WIFI6、AirFlash 等），將動車組非實(shí)時數(shù)據(jù)通過無線局域網(wǎng)發(fā)送到Rabbit-MQ 消息隊列，并依據(jù)訂閱的Topic 信息將數(shù)據(jù)分發(fā)給Kafka Connect 服務(wù)。Topic 主要承載動車組車載非實(shí)時數(shù)據(jù)的分發(fā)，部分?jǐn)?shù)據(jù)見表1。Kafka Connect 根據(jù)Topic 信息將數(shù)據(jù)寫入到對應(yīng)類型的Stream 中并存儲到相應(yīng)的Query 中，不同Topic 信息通過Kafka Connect 存儲到PostgreSQL 或Influx-DB 數(shù)據(jù)庫中。

表1 Topic 信息類型（車載運(yùn)行信息）

（3）數(shù)據(jù)服務(wù)層

數(shù)據(jù)層服務(wù)可分為主節(jié)點(diǎn)數(shù)據(jù)管理和子節(jié)點(diǎn)數(shù)據(jù)管理，主節(jié)點(diǎn)主要包括查詢服務(wù)、數(shù)據(jù)存儲、權(quán)限驗證等進(jìn)程服務(wù)，Web API 服務(wù)接收到主節(jié)點(diǎn)用戶查詢服務(wù)，對查詢條件進(jìn)行解析并首先訪問本地高速數(shù)據(jù)存儲或本地數(shù)據(jù)存儲，如果查詢到數(shù)據(jù)則返回給用戶，如果沒有查詢到數(shù)據(jù)，則將發(fā)起子節(jié)點(diǎn)查詢服務(wù)，最終從子節(jié)點(diǎn)返回結(jié)果數(shù)據(jù)。

（4）系統(tǒng)應(yīng)用層

系統(tǒng)應(yīng)用層是針對動車組非實(shí)時數(shù)據(jù)傳輸、存儲、查詢的過程系統(tǒng)服務(wù)，主要包括系統(tǒng)管理、數(shù)據(jù)處理存儲服務(wù)、數(shù)據(jù)查詢及檢索服務(wù)功能。系統(tǒng)管理平臺提供了管理的前端，管理人員定義動車組設(shè)備及類型、需要傳遞數(shù)據(jù)的屬性參數(shù)，以及數(shù)據(jù)源配置、數(shù)據(jù)目的配置、報警參數(shù)配置等。通過定義動車組類型及定義需要采集的屬性參數(shù)，自動生成Json 格式接口規(guī)范，所有此類型動車組通過此規(guī)范傳輸數(shù)據(jù)即可被平臺接收和解析。激活動車組設(shè)備類型時，管理平臺自動生成Rabbit-MQ 的Topic，并根據(jù)數(shù)據(jù)源配置和數(shù)據(jù)目的配置調(diào)用對應(yīng)的Kafka Connect；同時管理平臺會生成KSQL 腳本，并根據(jù)腳本自動在Kafka 中創(chuàng)建Stream 和Query。

2 系統(tǒng)關(guān)鍵使能技術(shù)

2.1 分布式存儲技術(shù)

考慮到高頻數(shù)據(jù)采集、海量數(shù)據(jù)存儲以及快速數(shù)據(jù)檢索等場景對分布式存儲系統(tǒng)在動態(tài)高并發(fā)、存儲可拓展性、數(shù)據(jù)可管理性、數(shù)據(jù)可重用性等方面的需求，文中采用關(guān)系數(shù)據(jù)庫（PostgreSQL）、高速數(shù)據(jù)存儲（Redis）、時序數(shù)據(jù)庫（InfluxDB）和實(shí)時數(shù)據(jù)流引擎（KsqlDB）等技術(shù)構(gòu)造支持分布式存儲、檢索動車組車載海量數(shù)據(jù)的系統(tǒng)架構(gòu)，其中PostgreSQL 關(guān)系數(shù)據(jù)庫用于各節(jié)點(diǎn)應(yīng)用服務(wù)及數(shù)據(jù)存儲功能，Redis 高速數(shù)據(jù)存儲用于應(yīng)用服務(wù)緩存及部分?jǐn)?shù)據(jù)存儲功能，InfluxDB 時序數(shù)據(jù)庫用于存儲動車組硬件采集的時序數(shù)據(jù)，KsqlDB 是基于Kafka 的實(shí)時數(shù)據(jù)流處理引擎。通過采用上述技術(shù)及主、子節(jié)點(diǎn)架構(gòu)，以滿足支撐動車組海量數(shù)據(jù)分布式存儲與檢索的需求。

動車組在運(yùn)行過程中駛進(jìn)某動車運(yùn)用所時，利用無線通信技術(shù)將動車組在前后子節(jié)點(diǎn)之間產(chǎn)生的非實(shí)時數(shù)據(jù)快速、有效地傳輸?shù)降孛鍾abbit-MQ 服務(wù)，后續(xù)依據(jù)訂閱的Topic 信息將數(shù)據(jù)發(fā)送給Kafka Connect。由于數(shù)據(jù)種類眾多，需要根據(jù)不同數(shù)據(jù)類型進(jìn)行分類處理，Kafka 消息系統(tǒng)根據(jù)不同的Topic 分別對數(shù)據(jù)進(jìn)行處理并寫入相應(yīng)Stream和Query 中，目的Kafka Connect 根據(jù)不同主題的Topic 對主題數(shù)據(jù)進(jìn)行相應(yīng)處理。處理方式主要分為兩類：一類是將核心數(shù)據(jù)信息以及數(shù)據(jù)目錄信息上傳至主節(jié)點(diǎn)關(guān)系數(shù)據(jù)庫中；另一類是將非實(shí)時數(shù)據(jù)存儲至PostgreSQL 或InfluxDB 數(shù)據(jù)庫中。

由于分布式關(guān)系數(shù)據(jù)庫在面向海量數(shù)據(jù)存儲時，受制于單節(jié)點(diǎn)存儲的容量及性能限制，需要對分布式關(guān)系數(shù)據(jù)庫的存儲進(jìn)行分片設(shè)計，常見的分片方式有哈希分片、范圍分片、垂直分片、水平分片等方式，文中整體存儲原則如下：

（1）對于數(shù)據(jù)量較小且數(shù)據(jù)集變化頻率相對較低的數(shù)據(jù)實(shí)體采用單表單節(jié)點(diǎn)的形式存儲，如車輛基礎(chǔ)信息、GPS 位置基礎(chǔ)信息、故障項信息等數(shù)據(jù)實(shí)體。

（2）對于數(shù)據(jù)量較大且數(shù)據(jù)變化頻率較高的數(shù)據(jù)實(shí)體則按照節(jié)點(diǎn)數(shù)量進(jìn)行分節(jié)點(diǎn)存儲，按節(jié)點(diǎn)劃分后，如果單表數(shù)據(jù)量依然較大，則可以按照時間再次進(jìn)行拆分，確保各數(shù)據(jù)表數(shù)據(jù)量保持在一個合理的水平，有利于提高數(shù)據(jù)檢索效率并便于數(shù)據(jù)存儲拓展。

2.2 分布式檢索算法設(shè)計

在動車組運(yùn)行過程中，其產(chǎn)生的非實(shí)時運(yùn)行數(shù)據(jù)分別存儲于運(yùn)行途徑的各動車運(yùn)用所節(jié)點(diǎn)中，具有典型的時空特性，因此動車組運(yùn)行數(shù)據(jù)的檢索包含時間屬性、空間屬性和數(shù)據(jù)屬性的過濾過程。其中，時間屬性表征動車組的運(yùn)行時態(tài)信息，其時間區(qū)間范圍較小或者僅包含某個時間采樣點(diǎn)，由采集數(shù)據(jù)的種類和頻次決定；空間屬性表征動車組運(yùn)行的地理位置信息，屬于隨時間不斷變化的動態(tài)空間信息；數(shù)據(jù)屬性則表征動車組靜態(tài)數(shù)據(jù)以及動車組運(yùn)行過程的動態(tài)數(shù)據(jù)（狀態(tài)參數(shù)信息等）。

動車組時空數(shù)據(jù)集通過時間、空間和數(shù)據(jù)屬性三個階段的過濾篩選最終可以獲取動車組運(yùn)行數(shù)據(jù)集，動車組運(yùn)行數(shù)據(jù)集的分布式檢索采用如下模式進(jìn)行，以從子節(jié)點(diǎn)檢索為例，主要步驟如下：

（1）用戶通過主節(jié)點(diǎn)服務(wù)根據(jù)業(yè)務(wù)需求發(fā)起檢索需求，首先主節(jié)點(diǎn)加載動車組運(yùn)行過程數(shù)據(jù)模型信息，根據(jù)用戶輸入的檢索條件進(jìn)行映射并生成時間屬性、空間屬性和數(shù)據(jù)屬性等檢索約束集，作為下一步檢索的依據(jù)。

（2）生成檢索約束集后，主節(jié)點(diǎn)根據(jù)空間約束條件向本地存儲服務(wù)發(fā)送數(shù)據(jù)請求，未檢索到結(jié)果數(shù)據(jù)，則向子節(jié)點(diǎn)發(fā)送數(shù)據(jù)請求，并將檢索約束集信息作為數(shù)據(jù)請求參數(shù)。

（3）子節(jié)點(diǎn)獲取數(shù)據(jù)請求后，解析檢索約束集并根據(jù)時間屬性約束條件篩選符合條件的數(shù)據(jù)集。

（4）子節(jié)點(diǎn)獲取數(shù)據(jù)請求后，解析檢索約束集并根據(jù)數(shù)據(jù)屬性約束條件篩選符合條件的數(shù)據(jù)集。

（5）各子節(jié)點(diǎn)準(zhǔn)備相關(guān)數(shù)據(jù)、分批分量多次將完整數(shù)據(jù)逐步反饋至主節(jié)點(diǎn)，主節(jié)點(diǎn)收集返回的數(shù)據(jù)并形成完整的動車運(yùn)行數(shù)據(jù)集。

3 系統(tǒng)運(yùn)行流程

通過在動車運(yùn)用所建設(shè)無線端接入技術(shù)地面配套系統(tǒng)（包括地面基站、數(shù)據(jù)服務(wù)站點(diǎn)），實(shí)現(xiàn)將列車非實(shí)時數(shù)據(jù)傳輸?shù)降孛嫦到y(tǒng)；在數(shù)據(jù)中心部署地面服務(wù)器匯集各動車運(yùn)用所存儲的非實(shí)時數(shù)據(jù)文件索引信息，并建立車載數(shù)據(jù)資源目錄，供各方用戶使用，整體系統(tǒng)的運(yùn)行流程如圖3 所示。

圖3 系統(tǒng)運(yùn)行架構(gòu)

當(dāng)動車組進(jìn)入動車運(yùn)用所無線覆蓋區(qū)域后，能夠通過無線端接入技術(shù)連入動車運(yùn)用所局域網(wǎng)，自動實(shí)現(xiàn)將動車組非實(shí)時數(shù)據(jù)從車載數(shù)據(jù)中心高速傳輸?shù)絼榆囘\(yùn)用所數(shù)據(jù)服務(wù)站點(diǎn)。后續(xù)動車運(yùn)用所按照自身的數(shù)據(jù)運(yùn)用需求，對非實(shí)時數(shù)據(jù)進(jìn)行存儲、解析、運(yùn)用。

各動車運(yùn)用所數(shù)據(jù)服務(wù)站點(diǎn)通過鐵路內(nèi)部網(wǎng)絡(luò)，將非實(shí)時數(shù)據(jù)文件索引信息同步至數(shù)據(jù)中心，當(dāng)數(shù)據(jù)中心發(fā)起數(shù)據(jù)查詢檢索請求時，訪問本地高速數(shù)據(jù)存儲或本地數(shù)據(jù)存儲，未檢索到相應(yīng)的數(shù)據(jù)，則依據(jù)數(shù)據(jù)文件索引信息找相應(yīng)的動車運(yùn)用所，并通過內(nèi)部網(wǎng)絡(luò)向?qū)?yīng)的動車運(yùn)用所數(shù)據(jù)服務(wù)站點(diǎn)發(fā)起數(shù)據(jù)請求。各動車運(yùn)用所間的非實(shí)時數(shù)據(jù)查詢請求，則以數(shù)據(jù)服務(wù)中心為中轉(zhuǎn)，基于其數(shù)據(jù)目錄服務(wù)，向?qū)?yīng)動車運(yùn)用所數(shù)據(jù)服務(wù)站點(diǎn)請求所需的數(shù)據(jù)，數(shù)據(jù)處理流程如圖4 所示。

圖4 數(shù)據(jù)處理流程

4 系統(tǒng)部署

為保證非實(shí)時數(shù)據(jù)應(yīng)用的穩(wěn)定性和可靠性，充分利用既有資源，提高共用性和集約型，并保證未來功能擴(kuò)展的可行性，文中構(gòu)建的原型系統(tǒng)平臺提供了強(qiáng)大的在線水平擴(kuò)展功能，無需停機(jī)維護(hù)即可實(shí)現(xiàn)運(yùn)算節(jié)點(diǎn)及存儲節(jié)點(diǎn)的增加，實(shí)現(xiàn)在線擴(kuò)展。節(jié)點(diǎn)添加完成之后即可對節(jié)點(diǎn)進(jìn)行角色的分配，新加的節(jié)點(diǎn)即刻投入運(yùn)行。

4.1 服務(wù)配置管理

文中采用Helm 對RabbitMQ 消息隊列、Kafka Connect 服務(wù)、Gitlab 等服務(wù)進(jìn)行統(tǒng)一部署包的模板管理，各節(jié)點(diǎn)均可通過模板腳本參數(shù)快速完成節(jié)點(diǎn)服務(wù)的環(huán)境搭建及部署。通過Kubernetes 平臺的Dashboard 進(jìn)行資源的統(tǒng)一管理維護(hù)，并通過KubeView 資源可視化工具監(jiān)控所有資源對象的狀態(tài)和故障。

4.2 節(jié)點(diǎn)服務(wù)部署

數(shù)據(jù)服務(wù)中心主節(jié)點(diǎn)通過功能看板對各節(jié)點(diǎn)資源、狀態(tài)進(jìn)行統(tǒng)一監(jiān)控，包括可視化展示主、子節(jié)點(diǎn)連接情況及各節(jié)點(diǎn)CPU、內(nèi)存、存儲等資源使用信息和功能報警。數(shù)據(jù)服務(wù)中心支持用戶查詢業(yè)務(wù)操作，并且可通過數(shù)據(jù)約束條件匯總查詢主節(jié)點(diǎn)及相關(guān)子節(jié)點(diǎn)數(shù)據(jù)信息，數(shù)據(jù)服務(wù)中心看板如圖5 所示、匯總查詢結(jié)果界面如圖6 所示。

圖5 數(shù)據(jù)服務(wù)中心看板

圖6 數(shù)據(jù)服務(wù)中心匯總查詢界面

4.3 系統(tǒng)性能測試

不同動車運(yùn)用所保有的動車組數(shù)量不同，因此需存儲數(shù)據(jù)量也有所不同。假設(shè)1 個典型動車運(yùn)用所配屬20 列動車組，包含10 列復(fù)興號動車組和10 列和諧號動車組，由于非實(shí)時數(shù)據(jù)主要用于健康管理及故障預(yù)測數(shù)據(jù)建模，原始數(shù)據(jù)不必按照動車組全生命周期進(jìn)行存儲。假設(shè)動車運(yùn)用所以1 年為周期管理非實(shí)時數(shù)據(jù)，按上文列舉的動車組日均數(shù)據(jù)量進(jìn)行測算，則1 個典型動車運(yùn)用所存儲1 年非實(shí)時數(shù)據(jù)文件所需數(shù)據(jù)存儲量約為30 TB。

基于此，文中標(biāo)準(zhǔn)測試環(huán)境是由1 個主節(jié)點(diǎn)和6 個子節(jié)點(diǎn)組成，子節(jié)點(diǎn)用以模擬各動車運(yùn)用所，各子節(jié)點(diǎn)默認(rèn)1 個計算節(jié)點(diǎn)和1 個存儲節(jié)點(diǎn)（存儲容量為40 TB），各節(jié)點(diǎn)配置相同，節(jié)點(diǎn)之間采用鐵路辦公內(nèi)部服務(wù)網(wǎng)絡(luò)（帶寬為100 Mbps）。測試內(nèi)容見表2，系統(tǒng)性能和子節(jié)點(diǎn)數(shù)量的關(guān)系成負(fù)相關(guān)性，性能變化情況如圖7 所示。

表2 測試內(nèi)容列表

圖7 子節(jié)點(diǎn)數(shù)對系統(tǒng)性能的影響

此外，對于動車組車載大數(shù)據(jù)應(yīng)用來說，分布式節(jié)點(diǎn)的非實(shí)時數(shù)據(jù)同步時間也是較為重要的指標(biāo)，因此以某系列動車組為例，單組動車組日數(shù)據(jù)量約為7 GB，數(shù)據(jù)類型參照表1，將數(shù)據(jù)均分至各個子節(jié)點(diǎn)，將數(shù)據(jù)文件索引信息同步至主節(jié)點(diǎn)，測試子節(jié)點(diǎn)數(shù)對同步時間的影響，測試結(jié)果如圖8 所示，可見，同步時間隨著子節(jié)點(diǎn)數(shù)線性增加。

圖8 子節(jié)點(diǎn)數(shù)對數(shù)據(jù)索引同步時間的影響

5 結(jié)論

基于動車組車載海量數(shù)據(jù)地面系統(tǒng)面臨的問題及實(shí)際應(yīng)用場景，從系統(tǒng)架構(gòu)方面論證了分布式系統(tǒng)架構(gòu)的可行性，并針對應(yīng)用場景的特殊性和系統(tǒng)技術(shù)特點(diǎn)，采用基于分布式技術(shù)和Kubernetes 云原生技術(shù)，設(shè)計及搭建了一種由數(shù)據(jù)服務(wù)中心主節(jié)點(diǎn)和各動車運(yùn)用所數(shù)據(jù)服務(wù)站點(diǎn)子節(jié)點(diǎn)組成的動車組車載大數(shù)據(jù)系統(tǒng)，通過原型系統(tǒng)部署及測試，實(shí)現(xiàn)了支持分布式數(shù)據(jù)存儲、檢索及數(shù)據(jù)服務(wù)功能，驗證了文中提出技術(shù)方案的可行性和有效性，為更好地對運(yùn)行中的動車組進(jìn)行健康管理、進(jìn)一步強(qiáng)化動車組安全保障能力、改善運(yùn)維經(jīng)濟(jì)性提供數(shù)據(jù)基礎(chǔ)。

為進(jìn)一步支撐動車組安全運(yùn)營與健康管理的開展，深化動車組大數(shù)據(jù)的應(yīng)用，在后續(xù)的研究中將繼續(xù)對系統(tǒng)進(jìn)行優(yōu)化，接入更多動車組全生命周期數(shù)據(jù)。