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

扈海軍

（1 中國鐵道科學研究院集團有限公司 機車車輛研究所，北京 100081；2 北京縱橫機電科技有限公司，北京 100094）

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

動車組運營過程中，還存在大量非實時運行數據，主要有采樣密度較大的運行數據、自診斷和日志數據等，是動車組故障診斷與運行維護的重要數據，以此為基礎進行車輛故障預警、關鍵零部件性能監測以及零部件剩余壽命預測，指導運維部門對車輛子系統的預防修與計劃修，輔助優化修程修制等［5］。

非實時數據到站后通過無線傳輸到各動車運用所，每列動車組（標準組）日均數據量為2 GB，年均數據量可達720 GB，復興號動車組數據量更大。如何提高地面系統的數據轉儲和集中整體能力，統一匯集、存儲、管理各車載數據，實現高密度、大容量的數據落地、存儲與管理，成為我國動車組在安全運營與健康管理方面開展大數據應用面臨的重大挑戰［6-8］。

云計算、大數據、物聯網等新興技術的快速發展為解決上述問題提供了可能［9-10］。針對上述問題，文中從實際工程應用角度出發，結合最新分布式技術和大數據技術提出了一種支持存儲、檢索動車組車載海量數據的系統架構，并設計了分布式存儲與檢索技術，提升了數據存儲能力和數據檢索能力。

1 系統體系結構

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

圖1 分布式架構

分布式動車組車載大數據系統服務架構如圖2所示，自下而上主要包含4 層：

圖2 系統服務架構

（1）硬件設備層

動車運用所機房的服務器設備、網絡設備、存儲設備、負載均衡器、VPN/防火墻等硬件設備。

（2）數據采集層

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

表1 Topic 信息類型（車載運行信息）

（3）數據服務層

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

（4）系統應用層

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

2 系統關鍵使能技術

2.1 分布式存儲技術

考慮到高頻數據采集、海量數據存儲以及快速數據檢索等場景對分布式存儲系統在動態高并發、存儲可拓展性、數據可管理性、數據可重用性等方面的需求，文中采用關系數據庫（PostgreSQL）、高速數據存儲（Redis）、時序數據庫（InfluxDB）和實時數據流引擎（KsqlDB）等技術構造支持分布式存儲、檢索動車組車載海量數據的系統架構，其中PostgreSQL 關系數據庫用于各節點應用服務及數據存儲功能，Redis 高速數據存儲用于應用服務緩存及部分數據存儲功能，InfluxDB 時序數據庫用于存儲動車組硬件采集的時序數據，KsqlDB 是基于Kafka 的實時數據流處理引擎。通過采用上述技術及主、子節點架構，以滿足支撐動車組海量數據分布式存儲與檢索的需求。

動車組在運行過程中駛進某動車運用所時，利用無線通信技術將動車組在前后子節點之間產生的非實時數據快速、有效地傳輸到地面Rabbit-MQ 服務，后續依據訂閱的Topic 信息將數據發送給Kafka Connect。由于數據種類眾多，需要根據不同數據類型進行分類處理，Kafka 消息系統根據不同的Topic 分別對數據進行處理并寫入相應Stream和Query 中，目的Kafka Connect 根據不同主題的Topic 對主題數據進行相應處理。處理方式主要分為兩類：一類是將核心數據信息以及數據目錄信息上傳至主節點關系數據庫中；另一類是將非實時數據存儲至PostgreSQL 或InfluxDB 數據庫中。

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

（1）對于數據量較小且數據集變化頻率相對較低的數據實體采用單表單節點的形式存儲，如車輛基礎信息、GPS 位置基礎信息、故障項信息等數據實體。

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

2.2 分布式檢索算法設計

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

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

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

（2）生成檢索約束集后，主節點根據空間約束條件向本地存儲服務發送數據請求，未檢索到結果數據，則向子節點發送數據請求，并將檢索約束集信息作為數據請求參數。

（3）子節點獲取數據請求后，解析檢索約束集并根據時間屬性約束條件篩選符合條件的數據集。

（4）子節點獲取數據請求后，解析檢索約束集并根據數據屬性約束條件篩選符合條件的數據集。

（5）各子節點準備相關數據、分批分量多次將完整數據逐步反饋至主節點，主節點收集返回的數據并形成完整的動車運行數據集。

3 系統運行流程

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

圖3 系統運行架構

當動車組進入動車運用所無線覆蓋區域后，能夠通過無線端接入技術連入動車運用所局域網，自動實現將動車組非實時數據從車載數據中心高速傳輸到動車運用所數據服務站點。后續動車運用所按照自身的數據運用需求，對非實時數據進行存儲、解析、運用。

各動車運用所數據服務站點通過鐵路內部網絡，將非實時數據文件索引信息同步至數據中心，當數據中心發起數據查詢檢索請求時，訪問本地高速數據存儲或本地數據存儲，未檢索到相應的數據，則依據數據文件索引信息找相應的動車運用所，并通過內部網絡向對應的動車運用所數據服務站點發起數據請求。各動車運用所間的非實時數據查詢請求，則以數據服務中心為中轉，基于其數據目錄服務，向對應動車運用所數據服務站點請求所需的數據，數據處理流程如圖4 所示。

圖4 數據處理流程

4 系統部署

為保證非實時數據應用的穩定性和可靠性，充分利用既有資源，提高共用性和集約型，并保證未來功能擴展的可行性，文中構建的原型系統平臺提供了強大的在線水平擴展功能，無需停機維護即可實現運算節點及存儲節點的增加，實現在線擴展。節點添加完成之后即可對節點進行角色的分配，新加的節點即刻投入運行。

4.1 服務配置管理

文中采用Helm 對RabbitMQ 消息隊列、Kafka Connect 服務、Gitlab 等服務進行統一部署包的模板管理，各節點均可通過模板腳本參數快速完成節點服務的環境搭建及部署。通過Kubernetes 平臺的Dashboard 進行資源的統一管理維護，并通過KubeView 資源可視化工具監控所有資源對象的狀態和故障。

4.2 節點服務部署

數據服務中心主節點通過功能看板對各節點資源、狀態進行統一監控，包括可視化展示主、子節點連接情況及各節點CPU、內存、存儲等資源使用信息和功能報警。數據服務中心支持用戶查詢業務操作，并且可通過數據約束條件匯總查詢主節點及相關子節點數據信息，數據服務中心看板如圖5 所示、匯總查詢結果界面如圖6 所示。

圖5 數據服務中心看板

圖6 數據服務中心匯總查詢界面

4.3 系統性能測試

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

基于此，文中標準測試環境是由1 個主節點和6 個子節點組成，子節點用以模擬各動車運用所，各子節點默認1 個計算節點和1 個存儲節點（存儲容量為40 TB），各節點配置相同，節點之間采用鐵路辦公內部服務網絡（帶寬為100 Mbps）。測試內容見表2，系統性能和子節點數量的關系成負相關性，性能變化情況如圖7 所示。

表2 測試內容列表

圖7 子節點數對系統性能的影響

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

圖8 子節點數對數據索引同步時間的影響

5 結論

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

為進一步支撐動車組安全運營與健康管理的開展，深化動車組大數據的應用，在后續的研究中將繼續對系統進行優化，接入更多動車組全生命周期數據。