時序數據庫IoTDB在城軌車輛智能運維系統中的應用研究

趙娜娜

摘要：隨著我國城市軌道交通的高速發展，城市軌道交通車輛運維壓力越來越大。傳統數據庫無法采集并存儲日益增長的海量數據，IoTDB數據庫具有優秀的數據壓縮性能、高效的數據查詢和寫入性能，能夠支撐城市軌道交通車輛日益增長的海量數據存儲。本文介紹了基于IoTDB的城軌車輛智能運維系統的整體架構，該架構在保障城軌車輛車輛安全、可靠運營的基礎上，有效降低了運營成本、提高了運營效率。

關鍵詞：時序數據、IoTDB、智能運維

1.引言

隨著我國城市軌道交通建設的快速發展，以人工為主的計劃修模式無法支撐網絡化運營帶來的檢修負載。智研咨詢發布的《2021-2027年中國地鐵行業發展現狀調查及投資戰略規劃報告》數據顯示：2020年中國地鐵配屬列車數量達7424列，其中北京地鐵配屬列車數量為1037列，全國排名第一;上海地鐵配屬列車數量為1023列，全國排名第二。我國目前處于經濟發展轉型期，地鐵建設數量持續增長，發展超大規模網絡給地鐵公司帶來了巨大的挑戰，對地鐵公司的運維管理來說，安全性、可靠性的要求越來越高，而軌道交通可持續發展則需要更低的運維成本，提高人車比，這就意味著設備可靠性需要更加智能健康的管理手段。

以網絡化、智能化、狀態修為特點的城軌車輛智能運維系統通過實時自動采集設備工況數據、運行故障數據，以及運行狀態數據，利用大數據和機器學習技術，實現設備的實時監控、故障預警，以及故障預測分析等。城軌車輛智能運維系統大多以關系型數據庫或時序數據庫用來存儲數據，雖然能夠實現時序數據的歷史存儲，但數據查詢和數據壓縮方面性能較差。本文提出的IoTDB時序數據庫，可以有效的提高數據查詢性能，降低數據存儲成本。

2.時序數據庫IoTDB的特點

時間序列數據庫簡稱時序數據庫（Time Series Database），用于處理帶時間標簽（按照時間的順序變化，即時間序列化）的數據，帶時間標簽的數據也稱為時間序列數據[1]。

2.1時許數據庫IoTDB的特點

Apache IoTDB是針對時間序列數據收集、存儲與分析一體化的數據管理引擎。它具有體量輕、性能高、易使用的特點，完美對接Hadoop與Spark生態，適用于工業物聯網應用中海量時間序列數據高速寫入和復雜分析查詢的需求。

IoTDB 是專門針對物聯網時序數據開發的數據庫，具有數據收集、存儲、管理和分析的功能。IoTDB具有部署方式靈活、讀寫性能高、存儲成本低、學習成本低、支持和Hadoop、spark、flink等開源大數據分析工具的集成等特點。

2.2 優勢對比

與傳統關系型數據比較，時序數據庫有以下幾點優勢：

（1）查詢性能高

時序數據庫數據存儲以時間戳為索引進行列式存儲，城軌車輛智能運維系統最常見的查詢是對一段時間的數據進行聚合查詢，查詢速度快。相比關系型數據庫，對這種大數據量的聚合查詢，性能較差。

（2）存儲成本低

IoTDB采用無損壓縮方式對數據進行存儲，城軌車輛智能運維系統數據采集頻率高，數據量大，采用時序數據庫可以有效的減少數據存儲空間，降低數據存儲成本。

（3）數據寫入性能高

時序數據庫支持ms級實時數據采集和存儲，城軌車輛智能運維系統數據采集頻率200/500ms，時序數據庫可以實現數據批量寫入，寫入性能高。

3.IoTDB在軌道交通智能運維系統中的應用

3.1智能運維系統車載設備數據的特點

智能運維系統中車載設備數據主要指車載通信設備通過無線通信協議將 MVB 總線數據發送至地面服務器的數據，這類數據有如下特點：

（1）數據量大

地鐵車輛每列車有上萬個傳感器，傳回地面的采集點按 4000點計算，采集頻率為200ms，每個變量至少需存儲的內容包括ID、時間戳和值，共占14字節。一列地鐵車輛一年的存儲空間為：

4000 *14（Byte） * 5 * 24（Hour） * 3600 * 365 =8830080000000（Byte）

約8.03TB。該數據是原始報文數據，解析后的數據量呈幾十倍增加。根據智研咨詢發布的《2021-2027年中國地鐵行業發展現狀調查及投資戰略規劃報告》數據，截止2020年底：中國地鐵數據總量約為58.22PB;北京地鐵數據量約為8.13PB;上海地鐵數據量約為8.02PB。隨著地鐵線路列車的增多，數據量會持續增長。

（2）數據協議復雜

車載設備通過車載設備發出的數據經過了三層數據協議的封裝：無線通信協議、車載設備私有通信協議、MVB 總線協議。其中車載設備私有通信協議與各車型 MVB 總線協議并沒有統一設計標準，導致數據接受后的解析較為復雜。

（3）數據查詢實時性高

列車狀態數據作為故障預警、故障分析等應用的重要數據源，往往需要被即時查詢且交互性要求較高，即頁面響應及時性要求較高。

（4）數據展示時序性強

針對通過車載設備實時接入的列車狀態數據，往往需要在前臺進行實時監控， 因此應能夠及時將狀態數據推送至有監控需求的客戶端，并保障數據到達的時序性。

3.2智能運維系統總體架構設計

智能運維系統總體架構如圖3-1所示，分為數據采集層、數據處理層、數據應用層，以及平臺管理層四部分。多源異構數據通過網關解析、處理后進行存儲、查詢、展示。

3.3數據采集層

城軌車輛智能運維系統在設計時考慮到數據源的多樣性，將數據源分為：車載設備數據、流媒體數據、關系型數據庫數據以及文本數據。車載設備數據采集如圖3-2所示。城軌車輛車輛產生的傳感器數據通過4G/5G/wifi無線方式回傳到地面服務器。車載設備數據是經過加密、壓縮、通信協議封裝，地面服務器接收到數據后，在netty中通過報頭來識別協議，將協議信息以及報文數據發送到集群的kafka中。

3.4數據處理層

數據處理流程圖如圖3-2所示。Netty中的數據發送到kafka后，經過Spark Streaming進行解析，解析后數據存入IoTDB中，IoTDB的核心是TsFile，TsFile可以實現云端IoTDB的數據同步，支持Hadoop、Spark等大數據分析。前文提到一列車一年的數據量約為8.03TB。經過解析后數據量是現在的幾十倍，IoTDB采用了SNAPPY等無損壓縮算法，在數據寫入時對數據進行編碼，可以有效的降低數據存儲空間，減少數據讀寫過程中I/O操作的數據量，從而提高數據讀寫性能。解析后數據分為列車故障數據和列車實時狀態數據，列車故障數據經過flink批處理后推送到頁面進行預警，列車實時狀態數據經過Spark Streaming進行流式處理。IoTDB與spark、flink等開源大數據系統無縫打通，使得數據處理更加便捷。

實時數據處理：解析后數據寫入Kafka消息隊列，經過Spark Streaming進行流處理?？紤]到流計算需要頻繁的用到主數據，在設計時采用MySQL+Redis+Web Service構建了數據訪問服務，采用MySQL作為后臺數據庫，用來存儲主數據，Redis作為緩存數據庫，用來存儲最新實時數據滿足頁面的實時交互查詢和展示。

批數據處理：解析后數據寫入Kafka中，經過Flink有界流處理后，將數據推送到頁面展示，同時寫入Kudu中。在Kudu之前采用Hbase/Parquet+HDFS方式，實時數據寫入Hbase，數據的更新也在Hbase中，對于批量分析的需求，定時將Hbase數據導成Parquet再導入HDFS中，該方式架構復雜，時效性低，難以應對后續的更新。 Kudu的定位是提供”fast analytics on fast data”，也就是在快速更新的數據上進行快速的查詢[2]。Kudu能充分利用CPU和I/O資源，支持數據原地修改，支持簡單的、可擴展的數據模型。

3.5數據應用層

數據應用層主要有列車狀態實時監測、列車故障預警、列車故障診斷，及列車數據分析等功能。列車狀態實時監測包括列車數量、投運數量、在離線數量、故障列車數量、各等級故障數量、運營數據統計等。列車故障預警模塊主要指在發生故障時通過聲音和消息提示的方式進行預警。列車數據分析模塊為運營數據（總里程，牽引能耗，再生能耗等能耗，空壓機累計運行時間，空壓機轉率、門狀態等數據聚合）的分析，載荷數據的分析，旅速數據的分析，能耗數據的分析等。IoTDB數據庫具有很好的數據聚合查詢性能，十億點數十毫秒快速查詢，IoTDB的數據聚合查詢使得列車數據分析更加高效。

4.結束語

本文提出的基于時序數據庫IoTDB，結合大數據組件Kafka，Spark Streaming，Flink，Kudu等構建的城軌車輛智能運維系統，通過車輛系統狀態感知和設備泛在互聯，實現采集信息數字化，在保障城軌車輛在線運行安全、提高車輛檢修質量和提升運營管理整體效能等方面發揮了顯著的優勢，同時，有效的降低了數據存儲成本，提高了數據寫入和查詢的性能。本文提出的基于時序數據庫IoTDB的城軌車輛智能運維系統架構，為其它工業大數據系統的運維提供了很好的參考和借鑒。

參考文獻

[1]葉鵬. 時間序列數據庫在智能水電廠監控業務中的應用[J]. 水 電 廠 自 動 化， 2018年2月， 39（1）：58-60.

[2]曹成，陶繼群，鄭湃;. 基于Kudu的電力輔助設備實時監控業務解決方案[J]. 科技創新與應用 ，Technology Innovation and Application， 2021（8）：130-134.