趙娜娜

摘要：隨著我國(guó)城市軌道交通的高速發(fā)展，城市軌道交通車輛運(yùn)維壓力越來(lái)越大。傳統(tǒng)數(shù)據(jù)庫(kù)無(wú)法采集并存儲(chǔ)日益增長(zhǎng)的海量數(shù)據(jù)，IoTDB數(shù)據(jù)庫(kù)具有優(yōu)秀的數(shù)據(jù)壓縮性能、高效的數(shù)據(jù)查詢和寫(xiě)入性能，能夠支撐城市軌道交通車輛日益增長(zhǎng)的海量數(shù)據(jù)存儲(chǔ)。本文介紹了基于IoTDB的城軌車輛智能運(yùn)維系統(tǒng)的整體架構(gòu)，該架構(gòu)在保障城軌車輛車輛安全、可靠運(yùn)營(yíng)的基礎(chǔ)上，有效降低了運(yùn)營(yíng)成本、提高了運(yùn)營(yíng)效率。

關(guān)鍵詞：時(shí)序數(shù)據(jù)、IoTDB、智能運(yùn)維

1.引言

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

以網(wǎng)絡(luò)化、智能化、狀態(tài)修為特點(diǎn)的城軌車輛智能運(yùn)維系統(tǒng)通過(guò)實(shí)時(shí)自動(dòng)采集設(shè)備工況數(shù)據(jù)、運(yùn)行故障數(shù)據(jù)，以及運(yùn)行狀態(tài)數(shù)據(jù)，利用大數(shù)據(jù)和機(jī)器學(xué)習(xí)技術(shù)，實(shí)現(xiàn)設(shè)備的實(shí)時(shí)監(jiān)控、故障預(yù)警，以及故障預(yù)測(cè)分析等。城軌車輛智能運(yùn)維系統(tǒng)大多以關(guān)系型數(shù)據(jù)庫(kù)或時(shí)序數(shù)據(jù)庫(kù)用來(lái)存儲(chǔ)數(shù)據(jù)，雖然能夠?qū)崿F(xiàn)時(shí)序數(shù)據(jù)的歷史存儲(chǔ)，但數(shù)據(jù)查詢和數(shù)據(jù)壓縮方面性能較差。本文提出的IoTDB時(shí)序數(shù)據(jù)庫(kù)，可以有效的提高數(shù)據(jù)查詢性能，降低數(shù)據(jù)存儲(chǔ)成本。

2.時(shí)序數(shù)據(jù)庫(kù)IoTDB的特點(diǎn)

時(shí)間序列數(shù)據(jù)庫(kù)簡(jiǎn)稱時(shí)序數(shù)據(jù)庫(kù)（Time Series Database），用于處理帶時(shí)間標(biāo)簽（按照時(shí)間的順序變化，即時(shí)間序列化）的數(shù)據(jù)，帶時(shí)間標(biāo)簽的數(shù)據(jù)也稱為時(shí)間序列數(shù)據(jù)[1]。

2.1時(shí)許數(shù)據(jù)庫(kù)IoTDB的特點(diǎn)

Apache IoTDB是針對(duì)時(shí)間序列數(shù)據(jù)收集、存儲(chǔ)與分析一體化的數(shù)據(jù)管理引擎。它具有體量輕、性能高、易使用的特點(diǎn)，完美對(duì)接Hadoop與Spark生態(tài)，適用于工業(yè)物聯(lián)網(wǎng)應(yīng)用中海量時(shí)間序列數(shù)據(jù)高速寫(xiě)入和復(fù)雜分析查詢的需求。

IoTDB 是專門(mén)針對(duì)物聯(lián)網(wǎng)時(shí)序數(shù)據(jù)開(kāi)發(fā)的數(shù)據(jù)庫(kù)，具有數(shù)據(jù)收集、存儲(chǔ)、管理和分析的功能。IoTDB具有部署方式靈活、讀寫(xiě)性能高、存儲(chǔ)成本低、學(xué)習(xí)成本低、支持和Hadoop、spark、flink等開(kāi)源大數(shù)據(jù)分析工具的集成等特點(diǎn)。

2.2 優(yōu)勢(shì)對(duì)比

與傳統(tǒng)關(guān)系型數(shù)據(jù)比較，時(shí)序數(shù)據(jù)庫(kù)有以下幾點(diǎn)優(yōu)勢(shì)：

（1）查詢性能高

時(shí)序數(shù)據(jù)庫(kù)數(shù)據(jù)存儲(chǔ)以時(shí)間戳為索引進(jìn)行列式存儲(chǔ)，城軌車輛智能運(yùn)維系統(tǒng)最常見(jiàn)的查詢是對(duì)一段時(shí)間的數(shù)據(jù)進(jìn)行聚合查詢，查詢速度快。相比關(guān)系型數(shù)據(jù)庫(kù)，對(duì)這種大數(shù)據(jù)量的聚合查詢，性能較差。

（2）存儲(chǔ)成本低

IoTDB采用無(wú)損壓縮方式對(duì)數(shù)據(jù)進(jìn)行存儲(chǔ)，城軌車輛智能運(yùn)維系統(tǒng)數(shù)據(jù)采集頻率高，數(shù)據(jù)量大，采用時(shí)序數(shù)據(jù)庫(kù)可以有效的減少數(shù)據(jù)存儲(chǔ)空間，降低數(shù)據(jù)存儲(chǔ)成本。

（3）數(shù)據(jù)寫(xiě)入性能高

時(shí)序數(shù)據(jù)庫(kù)支持ms級(jí)實(shí)時(shí)數(shù)據(jù)采集和存儲(chǔ)，城軌車輛智能運(yùn)維系統(tǒng)數(shù)據(jù)采集頻率200/500ms，時(shí)序數(shù)據(jù)庫(kù)可以實(shí)現(xiàn)數(shù)據(jù)批量寫(xiě)入，寫(xiě)入性能高。

3.IoTDB在軌道交通智能運(yùn)維系統(tǒng)中的應(yīng)用

3.1智能運(yùn)維系統(tǒng)車載設(shè)備數(shù)據(jù)的特點(diǎn)

智能運(yùn)維系統(tǒng)中車載設(shè)備數(shù)據(jù)主要指車載通信設(shè)備通過(guò)無(wú)線通信協(xié)議將 MVB 總線數(shù)據(jù)發(fā)送至地面服務(wù)器的數(shù)據(jù)，這類數(shù)據(jù)有如下特點(diǎn)：

（1）數(shù)據(jù)量大

地鐵車輛每列車有上萬(wàn)個(gè)傳感器，傳回地面的采集點(diǎn)按 4000點(diǎn)計(jì)算，采集頻率為200ms，每個(gè)變量至少需存儲(chǔ)的內(nèi)容包括ID、時(shí)間戳和值，共占14字節(jié)。一列地鐵車輛一年的存儲(chǔ)空間為：

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

約8.03TB。該數(shù)據(jù)是原始報(bào)文數(shù)據(jù)，解析后的數(shù)據(jù)量呈幾十倍增加。根據(jù)智研咨詢發(fā)布的《2021-2027年中國(guó)地鐵行業(yè)發(fā)展現(xiàn)狀調(diào)查及投資戰(zhàn)略規(guī)劃報(bào)告》數(shù)據(jù)，截止2020年底：中國(guó)地鐵數(shù)據(jù)總量約為58.22PB;北京地鐵數(shù)據(jù)量約為8.13PB;上海地鐵數(shù)據(jù)量約為8.02PB。隨著地鐵線路列車的增多，數(shù)據(jù)量會(huì)持續(xù)增長(zhǎng)。

（2）數(shù)據(jù)協(xié)議復(fù)雜

車載設(shè)備通過(guò)車載設(shè)備發(fā)出的數(shù)據(jù)經(jīng)過(guò)了三層數(shù)據(jù)協(xié)議的封裝：無(wú)線通信協(xié)議、車載設(shè)備私有通信協(xié)議、MVB 總線協(xié)議。其中車載設(shè)備私有通信協(xié)議與各車型 MVB 總線協(xié)議并沒(méi)有統(tǒng)一設(shè)計(jì)標(biāo)準(zhǔn)，導(dǎo)致數(shù)據(jù)接受后的解析較為復(fù)雜。

（3）數(shù)據(jù)查詢實(shí)時(shí)性高

列車狀態(tài)數(shù)據(jù)作為故障預(yù)警、故障分析等應(yīng)用的重要數(shù)據(jù)源，往往需要被即時(shí)查詢且交互性要求較高，即頁(yè)面響應(yīng)及時(shí)性要求較高。

（4）數(shù)據(jù)展示時(shí)序性強(qiáng)

針對(duì)通過(guò)車載設(shè)備實(shí)時(shí)接入的列車狀態(tài)數(shù)據(jù)，往往需要在前臺(tái)進(jìn)行實(shí)時(shí)監(jiān)控， 因此應(yīng)能夠及時(shí)將狀態(tài)數(shù)據(jù)推送至有監(jiān)控需求的客戶端，并保障數(shù)據(jù)到達(dá)的時(shí)序性。

3.2智能運(yùn)維系統(tǒng)總體架構(gòu)設(shè)計(jì)

智能運(yùn)維系統(tǒng)總體架構(gòu)如圖3-1所示，分為數(shù)據(jù)采集層、數(shù)據(jù)處理層、數(shù)據(jù)應(yīng)用層，以及平臺(tái)管理層四部分。多源異構(gòu)數(shù)據(jù)通過(guò)網(wǎng)關(guān)解析、處理后進(jìn)行存儲(chǔ)、查詢、展示。

3.3數(shù)據(jù)采集層

城軌車輛智能運(yùn)維系統(tǒng)在設(shè)計(jì)時(shí)考慮到數(shù)據(jù)源的多樣性，將數(shù)據(jù)源分為：車載設(shè)備數(shù)據(jù)、流媒體數(shù)據(jù)、關(guān)系型數(shù)據(jù)庫(kù)數(shù)據(jù)以及文本數(shù)據(jù)。車載設(shè)備數(shù)據(jù)采集如圖3-2所示。城軌車輛車輛產(chǎn)生的傳感器數(shù)據(jù)通過(guò)4G/5G/wifi無(wú)線方式回傳到地面服務(wù)器。車載設(shè)備數(shù)據(jù)是經(jīng)過(guò)加密、壓縮、通信協(xié)議封裝，地面服務(wù)器接收到數(shù)據(jù)后，在netty中通過(guò)報(bào)頭來(lái)識(shí)別協(xié)議，將協(xié)議信息以及報(bào)文數(shù)據(jù)發(fā)送到集群的kafka中。

3.4數(shù)據(jù)處理層

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

實(shí)時(shí)數(shù)據(jù)處理：解析后數(shù)據(jù)寫(xiě)入Kafka消息隊(duì)列，經(jīng)過(guò)Spark Streaming進(jìn)行流處理?？紤]到流計(jì)算需要頻繁的用到主數(shù)據(jù)，在設(shè)計(jì)時(shí)采用MySQL+Redis+Web Service構(gòu)建了數(shù)據(jù)訪問(wèn)服務(wù)，采用MySQL作為后臺(tái)數(shù)據(jù)庫(kù)，用來(lái)存儲(chǔ)主數(shù)據(jù)，Redis作為緩存數(shù)據(jù)庫(kù)，用來(lái)存儲(chǔ)最新實(shí)時(shí)數(shù)據(jù)滿足頁(yè)面的實(shí)時(shí)交互查詢和展示。

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

3.5數(shù)據(jù)應(yīng)用層

數(shù)據(jù)應(yīng)用層主要有列車狀態(tài)實(shí)時(shí)監(jiān)測(cè)、列車故障預(yù)警、列車故障診斷，及列車數(shù)據(jù)分析等功能。列車狀態(tài)實(shí)時(shí)監(jiān)測(cè)包括列車數(shù)量、投運(yùn)數(shù)量、在離線數(shù)量、故障列車數(shù)量、各等級(jí)故障數(shù)量、運(yùn)營(yíng)數(shù)據(jù)統(tǒng)計(jì)等。列車故障預(yù)警模塊主要指在發(fā)生故障時(shí)通過(guò)聲音和消息提示的方式進(jìn)行預(yù)警。列車數(shù)據(jù)分析模塊為運(yùn)營(yíng)數(shù)據(jù)（總里程，牽引能耗，再生能耗等能耗，空壓機(jī)累計(jì)運(yùn)行時(shí)間，空壓機(jī)轉(zhuǎn)率、門(mén)狀態(tài)等數(shù)據(jù)聚合）的分析，載荷數(shù)據(jù)的分析，旅速數(shù)據(jù)的分析，能耗數(shù)據(jù)的分析等。IoTDB數(shù)據(jù)庫(kù)具有很好的數(shù)據(jù)聚合查詢性能，十億點(diǎn)數(shù)十毫秒快速查詢，IoTDB的數(shù)據(jù)聚合查詢使得列車數(shù)據(jù)分析更加高效。

4.結(jié)束語(yǔ)

本文提出的基于時(shí)序數(shù)據(jù)庫(kù)IoTDB，結(jié)合大數(shù)據(jù)組件Kafka，Spark Streaming，F(xiàn)link，Kudu等構(gòu)建的城軌車輛智能運(yùn)維系統(tǒng)，通過(guò)車輛系統(tǒng)狀態(tài)感知和設(shè)備泛在互聯(lián)，實(shí)現(xiàn)采集信息數(shù)字化，在保障城軌車輛在線運(yùn)行安全、提高車輛檢修質(zhì)量和提升運(yùn)營(yíng)管理整體效能等方面發(fā)揮了顯著的優(yōu)勢(shì)，同時(shí)，有效的降低了數(shù)據(jù)存儲(chǔ)成本，提高了數(shù)據(jù)寫(xiě)入和查詢的性能。本文提出的基于時(shí)序數(shù)據(jù)庫(kù)IoTDB的城軌車輛智能運(yùn)維系統(tǒng)架構(gòu)，為其它工業(yè)大數(shù)據(jù)系統(tǒng)的運(yùn)維提供了很好的參考和借鑒。

參考文獻(xiàn)

[1]葉鵬. 時(shí)間序列數(shù)據(jù)庫(kù)在智能水電廠監(jiān)控業(yè)務(wù)中的應(yīng)用[J]. 水 電 廠 自 動(dòng) 化， 2018年2月， 39（1）：58-60.

[2]曹成，陶繼群，鄭湃;. 基于Kudu的電力輔助設(shè)備實(shí)時(shí)監(jiān)控業(yè)務(wù)解決方案[J]. 科技創(chuàng)新與應(yīng)用 ，Technology Innovation and Application， 2021（8）：130-134.