高速鐵路道岔異構(gòu)數(shù)據(jù)在Hbase上的云存儲方案

張志哲，徐田華，李 波

（1.北京交通大學 軌道交通控制與安全國家重點實驗室，北京 100044；2.中國中鐵電氣化局集團有限公司 智能交通技術(shù)分公司，北京 100161）

道岔是鐵路上保障列車安全運行的重要信號設(shè)備。目前，鐵路現(xiàn)場電務(wù)部門采用定期檢修與集中監(jiān)測系統(tǒng)相結(jié)合的方式對其進行維護，這種方式伴隨著大量的人工維護成本，存在著欠維修和過維修現(xiàn)象[1]。對工業(yè)設(shè)備通過健康管理的方式進行維護是目前設(shè)備維護的主流發(fā)展趨勢[2]，包括文獻[1] 中的航空領(lǐng)域和文獻[3]介紹的導(dǎo)彈武器系統(tǒng)領(lǐng)域在內(nèi)的許多領(lǐng)域，健康預(yù)測管理（PHM，Prognostics Health Management）已經(jīng)得到一定程度發(fā)展，PHM的核心即根據(jù)系統(tǒng)現(xiàn)在或歷史狀態(tài)預(yù)測未來的健康狀態(tài)，包括部件及系統(tǒng)的剩余壽命。

PHM對數(shù)據(jù)要求極高[4]，而其在道岔設(shè)備上還未實現(xiàn)的原因很大程度在于現(xiàn)階段道岔設(shè)備的數(shù)據(jù)獲取受現(xiàn)有道岔數(shù)據(jù)存儲架構(gòu)制約，難以滿足PHM海量異構(gòu)歷史數(shù)據(jù)存儲要求。在高速鐵路中道岔設(shè)備每天會產(chǎn)生大量相關(guān)數(shù)據(jù)，目前,鐵路電務(wù)部門的數(shù)據(jù)存儲模式為周期性覆蓋歷史數(shù)據(jù)，周期不超過3個月[5]，很多有價值的歷史數(shù)據(jù)尤其是故障前一段時間的數(shù)據(jù)不能有效保存，影響到道岔設(shè)備PHM的研究。傳統(tǒng)存儲方式受設(shè)備容量限制，可擴展性差，且升級維護成本高。因此，本文提出針對高速鐵路道岔設(shè)備海量異構(gòu)數(shù)據(jù)的云存儲及查詢管理方案。

很多學者對數(shù)據(jù)的云存儲做了相應(yīng)研究。文獻[6]提出了將大數(shù)據(jù)技術(shù)引入鐵路信號系統(tǒng)，通過設(shè)計接口將txt及csv等格式文件直接存儲到云存儲設(shè)備中。文獻[7]通過Hbase構(gòu)建了交通流數(shù)據(jù)實時存儲系統(tǒng)。文獻[8]通過Hbase和MapReduce對地理空間數(shù)據(jù)進行存儲。針對道岔設(shè)備的數(shù)據(jù)類型、結(jié)構(gòu)及現(xiàn)階段存儲方式，本文提出的高速鐵路道岔設(shè)備海量異構(gòu)數(shù)據(jù)的云存儲及查詢管理方案，以及基于MapReduce的優(yōu)化圖像分塊存儲算法，實現(xiàn)了高速鐵路道岔異構(gòu)數(shù)據(jù)的Hbase云存儲。這對于提高道岔系統(tǒng)的安全性、任務(wù)可靠性和降低系統(tǒng)維護成本有重要意義。

1 道岔數(shù)據(jù)分析

普速鐵路使用的道岔多為ZD-6及ZD-9，高速鐵路多使用S700K及ZYJ7。由于ZYJ7道岔結(jié)構(gòu)復(fù)雜，數(shù)據(jù)較之其他型號具有代表性，以其作為研究對象進行云存儲方案研究。道岔數(shù)據(jù)結(jié)構(gòu),如圖1所示。

1.1 道岔現(xiàn)場數(shù)據(jù)

道岔現(xiàn)場采集數(shù)據(jù)是進行道岔健康管理研究的基礎(chǔ)。考慮數(shù)據(jù)復(fù)雜性，在傳統(tǒng)的關(guān)系數(shù)據(jù)庫中存儲時需要建立多個表格，每個表格分別建立多列表頭及約束，十分占用存儲空間。

以某站現(xiàn)場數(shù)據(jù)為例，僅2天19個道岔的電流、電壓及功率數(shù)據(jù)導(dǎo)出的txt格式數(shù)據(jù)就達到了1.1 GB。而這些僅是道岔一年產(chǎn)生的數(shù)據(jù)存入txt中就達到200 GB（1.1/2 GB×365=200.75 GB）以上，如果存儲到關(guān)系數(shù)據(jù)庫中會占用更多空間。如果是一個大站全部數(shù)據(jù)積累會達到萬億字節(jié)（TB）甚至是千萬億字節(jié)（PB）級別，因此受設(shè)備容量限制，鐵路集中監(jiān)測系統(tǒng)會周期性覆蓋歷史數(shù)據(jù)，周期不超過3個月。在普通鐵路信號維護規(guī)則中規(guī)定集中監(jiān)測系統(tǒng)數(shù)據(jù)保存時間不低于30天[5]，但這并不能滿足道岔PHM對數(shù)據(jù)的需求，需要新的技術(shù)方案解決該問題。

圖1 道岔數(shù)據(jù)結(jié)構(gòu)

1.2 道岔圖像數(shù)據(jù)

道岔圖像數(shù)據(jù)（非結(jié)構(gòu)化）主要來自轉(zhuǎn)轍機中攝像機拍攝的缺口監(jiān)測圖像數(shù)據(jù)以及監(jiān)測系統(tǒng)軟件的設(shè)備狀態(tài)圖。為了更好地將其存儲并加以利用，也需云存儲技術(shù)加以解決。

2 Hbase介紹

Hbase數(shù)據(jù)庫是基于Hadoop大數(shù)據(jù)平臺的HDFS文件系統(tǒng)建立的。Hadoop是一個開源的分布式系統(tǒng)基本架構(gòu)，在云計算應(yīng)用框架中廣泛使用。云存儲計算作為一種大數(shù)據(jù)處理的關(guān)鍵技術(shù)，能很好的解決集中監(jiān)測系統(tǒng)中面臨的海量多元化信息存儲的問題[9]，為集中監(jiān)測系統(tǒng)的海量化信息處理提供有力支撐。

2.1 HDFS分布式文件系統(tǒng)

HDFS作為Hadoop平臺的核心部分，采用了主/從架構(gòu)對文件系統(tǒng)進行管理，由一個名字節(jié)點Name Node和多個數(shù)據(jù)節(jié)點Data Node組成。HDFS具有以下優(yōu)點：

（1）不會受集群中任意一個節(jié)點的磁盤大小的限制，便于處理超大文件。訪問數(shù)據(jù)請求是按照分布式方式進行的，所以可以滿足高吞吐量。

（2）當需擴充容量時只需增加一臺配置好環(huán)境變量的計算機，自動檢測新增設(shè)備，根據(jù)需求靈活擴展。

（3）Hadoop 的設(shè)計對硬件要求很低，可直接運行在廉價的計算機的集群上，方便搭建。

2.2 Hbase數(shù)據(jù)庫

Hbase即Hadoop平臺開發(fā)的專用分布式存儲系統(tǒng)。作為具有開源、分布式、可擴展及面向列存儲等特點的新型非結(jié)構(gòu)化數(shù)據(jù)庫，它能夠為大數(shù)據(jù)提供隨機、實時的讀寫訪問功能。其采用HDFS 作為自己的文件存儲系統(tǒng)，具有上述HDFS系統(tǒng)所具有的優(yōu)點。另外，Hbase支持 Hadoop 中的MapReduce以及新興的Spark來并行的處理海量數(shù)據(jù)，因此有很高的查詢速度[10]。

3 基于Hbase的結(jié)構(gòu)化數(shù)據(jù)存儲架構(gòu)

對于道岔設(shè)備歷史數(shù)據(jù)的轉(zhuǎn)存使用Sqoop數(shù)據(jù)遷移工具。Sqoop既可以實現(xiàn)將 Hadoop 和 Hbase中的非結(jié)構(gòu)化數(shù)據(jù)轉(zhuǎn)存到關(guān)系型數(shù)據(jù)庫中，也可以將MySQL及Oracle等關(guān)系型數(shù)據(jù)庫中的結(jié)構(gòu)化數(shù)據(jù)存儲到 Hadoop的 HDFS中轉(zhuǎn)為非結(jié)構(gòu)化數(shù)據(jù)[11]。通過局域網(wǎng)讀取集中監(jiān)測系統(tǒng)數(shù)據(jù)庫，轉(zhuǎn)存方便且不影響設(shè)備正常工作。結(jié)構(gòu)化數(shù)據(jù)的云存儲架構(gòu)，如圖2所示。

圖2 結(jié)構(gòu)化數(shù)據(jù)的云存儲架構(gòu)

圖2為集中監(jiān)測系統(tǒng)數(shù)據(jù)的云存儲實現(xiàn)模型。集中監(jiān)測系統(tǒng)將現(xiàn)場數(shù)據(jù)傳輸存儲到關(guān)系數(shù)據(jù)庫的過程可能根據(jù)不同車站夠通過 TCP/IP、串行通信和5G等多種通信方式與現(xiàn)場設(shè)備建立連接并實現(xiàn)數(shù)據(jù)傳輸。之后通過Sqoop與Hbase集群的主機相連，自動與各從屬節(jié)點的Region Server建立聯(lián)系后調(diào)用MapReduce機制將數(shù)據(jù)分布式存儲于各從屬節(jié)點設(shè)備中，即主節(jié)點讀取集中監(jiān)測系統(tǒng)關(guān)系數(shù)據(jù)庫中的歷史數(shù)據(jù)后分配給各從屬節(jié)點，各節(jié)點將數(shù)據(jù)轉(zhuǎn)換格式后存儲到HDFS文件系統(tǒng)。

4 非結(jié)構(gòu)化圖像數(shù)據(jù)云存儲策略

4.1 圖像數(shù)據(jù)存儲流程

對于道岔圖像數(shù)據(jù)，現(xiàn)階段并沒有對其提起重視，也應(yīng)將其統(tǒng)一存儲管理。這里以道岔缺口監(jiān)測圖像數(shù)據(jù)為例，其存儲所設(shè)計的流程，如圖3所示。

圖3 圖像數(shù)據(jù)存儲流程圖

現(xiàn)場拍攝的缺口監(jiān)測圖像數(shù)據(jù)大小通常在80～90 kB之間。為了防止其他數(shù)據(jù)混入被誤處理，無法正確存儲，在這里設(shè)置門限進行判斷再做出處理。判斷為大圖像數(shù)據(jù)后在對其進行切割后，分別對切割后產(chǎn)生的數(shù)據(jù)塊加標簽處理，最后統(tǒng)一存儲到Hbase數(shù)據(jù)庫中。

4.2 圖像數(shù)據(jù)存儲表格設(shè)計

在Hbase中存儲圖像數(shù)據(jù)及其屬性信息，應(yīng)使列族盡可能少。具體方法即建立大表，將所有列放入同一列族中，如表1所示[12]。

表1 Hbase圖像數(shù)據(jù)存儲結(jié)構(gòu)

Hbase在存儲每個列族時，以Key-Value的方式存儲每行單元格的數(shù)據(jù)，形成若干數(shù)據(jù)塊后把數(shù)據(jù)塊存儲到HFile中，最后將HFile保存于后臺HDFS上。由于圖像數(shù)據(jù)內(nèi)容作為單元格的值保存，其大小受制于數(shù)據(jù)塊的大小，需要在開始時對數(shù)據(jù)塊的大小進行設(shè)置調(diào)整。默認情況下，Hbase數(shù)據(jù)塊限制為64 kB，在不同存儲時要根據(jù)最大圖像數(shù)據(jù)大小對Hbase數(shù)據(jù)塊大小進行修改。對于道岔缺口監(jiān)測照片，大小不會超過90 kB。綜合考慮，將數(shù)據(jù)塊大小設(shè)定為90 kB。

4.3 大圖像數(shù)據(jù)切割

上面講到了一般小圖像數(shù)據(jù)的存儲方式，但集中監(jiān)測系統(tǒng)中的軟件截圖數(shù)據(jù)遠大于幾十kB的小圖像數(shù)據(jù)，而將數(shù)據(jù)塊依照截圖大小設(shè)置又造成了存儲空間的浪費，因此本文對其處理后再存儲。現(xiàn)在主流的大圖像數(shù)據(jù)存儲處理方法是壓縮和切割兩種方式，用壓縮方法處理后圖像數(shù)據(jù)還是過大，不易存儲在數(shù)據(jù)塊中[13]。割方式存儲在存儲效率及可靠性等方面都具有一定優(yōu)勢。

4.3.1 算法可靠性分析

如果將一張圖像數(shù)據(jù)切割成若干份，分別存儲在m個服務(wù)器節(jié)點上，其中，第i個節(jié)點上存儲Ni份切割后的圖像數(shù)據(jù)。設(shè)每份切割后的圖像數(shù)據(jù)擁有的信息量為INFij，其丟失的概率為Pij，其中，i代表該圖像數(shù)據(jù)塊位于第i（0≤i≤m）個服務(wù)器節(jié)點上，j代表存儲于該節(jié)點的第j（0≤j≤Ni）個圖像數(shù)據(jù)塊。

切割存儲完成后，圖像數(shù)據(jù)在云端的信息量為：

切割前圖像數(shù)據(jù)信息總量為：

若為不切割直接存儲，圖像數(shù)據(jù)在最壞丟失的情況下保存的剩余總量為：

顯然，INFhold≥INF*hold， 因此，對圖像數(shù)據(jù)切割后云存儲相對于直接云存儲的方式顯著提高了圖像數(shù)據(jù)的信息總量， 進而提高了圖像數(shù)據(jù)云存儲的可靠性，適用于對可靠性有極大要求的鐵路領(lǐng)域。

4.3.2 圖像數(shù)據(jù)切割算法

通常把一張圖像數(shù)據(jù)用像素矩陣來表示，分別設(shè)圖像數(shù)據(jù)的寬和高為W和H，其單位為像素。使用二元函數(shù)f(x, y)來表示一張圖像數(shù)據(jù)，把像素點的坐標(x, y)作為分割依據(jù)，將圖像數(shù)據(jù)分割為若干大小相同的塊，然后再存儲于不同的云端服務(wù)器中，其中， f表示在任意坐標點(x, y)處振幅為該點亮度[14]。

基于分塊的圖像數(shù)據(jù)分割算法使用(δx, δy)來表示分割粒度，δx, δy都是正整數(shù)。圖像數(shù)據(jù)分塊數(shù)量用 C 表示，則有 ：C=W/(δx·H/δy)。設(shè)每塊分割后的圖像數(shù)據(jù)大小為 M ，則有 ：M=(W/δx, H/δy)。

設(shè)分割后的圖像數(shù)據(jù)用矩陣表示位置，則第(i, j)塊圖像數(shù)據(jù)像素點的坐標(x, y)需滿足：

x ∈ [iW/δx, (i+1)W/δx], y ∈ [jH/δy, (j+1)H/δy]x 及 y 均為正整數(shù)，i=0, 1, …, δx ；j= 0, 1, …, δy。

這種分塊算法及其簡單有效且不需對像素點計算，還原過程也較方便。圖4為將分塊算法用于一般圖像數(shù)據(jù)云存儲工作過程的示意流程圖。

圖4 圖像數(shù)據(jù)的分塊處理云存儲流程

4.3.3 MapReduce優(yōu)化的圖像數(shù)據(jù)分割存儲

考慮在圖像數(shù)據(jù)切割及格式轉(zhuǎn)換的計算開銷，利用MapReduce對其過程進行優(yōu)化。由于圖像數(shù)據(jù)行分割較少，先對其進行處理，再通過Map機制分配給計算節(jié)點進行列分割并格式轉(zhuǎn)換后存入Hbase，需要注意的是在Map的過程中對其標簽進行處理，防止存儲時數(shù)據(jù)塊混亂，其流程，如圖5所示。

圖5 MapReduce優(yōu)化的圖像數(shù)據(jù)分割存儲流程

5 實驗分析

在實驗室中通過5臺普通計算機搭建了分布式集群，兩臺作為管理節(jié)點主副機，3臺作為計算節(jié)點。下面分別對現(xiàn)場數(shù)據(jù)存儲及圖像數(shù)據(jù)存儲的實驗過程進行分析。

5.1 現(xiàn)場數(shù)據(jù)存儲實驗過程

先以道岔動作電流數(shù)據(jù)作為數(shù)據(jù)示例進行說明。表2為其在MySQL中的數(shù)據(jù)形式。在這里由于道岔動作電路為三相電路，電流數(shù)據(jù)1、2、3即分別為A、B、C相電流數(shù)據(jù)，每相電流數(shù)據(jù)即按照采樣間隔采集的230個左右浮點數(shù)。這里用的該組數(shù)據(jù)為某站部分道岔20天的動作產(chǎn)生，在MySQL數(shù)據(jù)庫中大小為10 259 MB。

表2 MySQL中道岔動作電流數(shù)據(jù)結(jié)構(gòu)

對上文提到的164號道岔動作電流數(shù)據(jù)進行遷移，耗時925.74 s，驗證了通過Sqoop進行數(shù)據(jù)轉(zhuǎn)存的方便快捷性。存儲后在Hbase中通過scan語法掃描顯示如下。

5.2 非結(jié)構(gòu)化圖像數(shù)據(jù)實驗過程

5.2.1 缺口監(jiān)測圖像數(shù)據(jù)存儲過程

在創(chuàng)建圖像數(shù)據(jù)大表過程中，行列名盡可能短以提高系統(tǒng)性能。由于道岔缺口監(jiān)測圖像數(shù)據(jù)名字即為圖像數(shù)據(jù)拍攝時間，具有唯一性且是查詢時的依據(jù)，故將其作為行鍵，用T（time）表示。其他列信息包括圖像數(shù)據(jù)內(nèi)容用CON（content）表示；圖像數(shù)據(jù)的來源，即是缺口監(jiān)測還是軟件截圖，用TY（type）表示；存入數(shù)據(jù)庫時間即當前網(wǎng)絡(luò)時間，用T1表示；修改時間即以后圖像數(shù)據(jù)若發(fā)生修改或替換的時間，用T2表示。

在這里采用某站19個道岔一天的缺口監(jiān)測圖像數(shù)據(jù)進行試驗。文件總大小622 MB，共7 362張圖像數(shù)據(jù)，耗時117.43 s。在存儲結(jié)束后，通過Hbase的get類查詢圖像數(shù)據(jù)并讀取出來，與原圖像數(shù)據(jù)大小像素均未變化，在Hbase中存儲并不會對圖像數(shù)據(jù)造成影響。

5.2.2 分塊存儲實驗過程

考慮集中監(jiān)測系統(tǒng)中為了不使圖像數(shù)據(jù)失真，通常在電務(wù)段保存下來的設(shè)備狀態(tài)圖像數(shù)據(jù)大小在3 MB左右，不會超過3.6 MB。出于對圖像數(shù)據(jù)的比例及大小與數(shù)據(jù)塊大小的綜合考慮，我們采用柵格化分割的方法將圖像數(shù)據(jù)分割為5行8列的形式，每份分割后的圖像數(shù)據(jù)剛好不會超過90 kB。

在圖像數(shù)據(jù)分割后進行5.2.1的操作將圖像數(shù)據(jù)存入Hbase中。本實驗采用300張、600張、1 000張和2 000張某電務(wù)段道岔設(shè)備圖像數(shù)據(jù)分別進行5次試驗，結(jié)果取平均數(shù)，數(shù)據(jù)大小分別為889 MB、1.81 GB、2.95 GB、5.86 GB，存儲后均未發(fā)生數(shù)據(jù)塊溢出現(xiàn)象。調(diào)用MapReduce與不調(diào)用MapReduce進行圖像數(shù)據(jù)分割存儲耗時對比如圖6，結(jié)果表明通過MapReduce優(yōu)化圖像數(shù)據(jù)分塊算法存儲速度提升約一倍，若增加節(jié)點速度還會有所提升。

再通過Java在Hbase讀取目標截圖并還原，未發(fā)生失真現(xiàn)象，與原始圖像數(shù)據(jù)一致。

MySQL與Hbase查詢性能對比，如圖6所示。

圖6 MySQL與Hbase查詢性能對比

5.3 Hbase查詢性能測試

Hbase的存儲目的最終是為了進行PHM的分析，因此對其查詢性能要求較高。下面通過與在MySQL中查詢對比對其使用時查詢數(shù)據(jù)的性能進行測試。分別在Hbase和MySQL中分別存入5組數(shù)據(jù)量不同的數(shù)據(jù)后（由于真實數(shù)據(jù)不足，驗證查詢性能時采用相同格式的隨機數(shù)據(jù)補充），每組數(shù)據(jù)分別讀取規(guī)定的300條數(shù)據(jù)10次對其時間取平均值，產(chǎn)生的結(jié)果對比如圖7所示。當數(shù)據(jù)較少時Habse表現(xiàn)不如傳統(tǒng)的Sql數(shù)據(jù)庫，但當數(shù)據(jù)量達到20萬條以上后，Hbase的性能優(yōu)于MySQL。這說明通過Hbase查詢性能符合預(yù)期，在積累大量歷史數(shù)據(jù)后對道岔設(shè)備PHM的深入研究有重要幫助。

圖7 MySQL與Hbase查詢性能對比

6 結(jié)束語

本文分析高速鐵路道岔數(shù)據(jù)對PHM的意義，針對目前高速鐵路道岔監(jiān)測數(shù)據(jù)存儲架構(gòu)難以滿足健康管理海量異構(gòu)歷史數(shù)據(jù)存儲的問題，結(jié)合道岔監(jiān)控數(shù)據(jù)以及道岔缺口監(jiān)測圖像等異構(gòu)數(shù)據(jù)，引入了大數(shù)據(jù)技術(shù)中的Hbase非結(jié)構(gòu)化數(shù)據(jù)存儲理念，提出了高速鐵路道岔設(shè)備海量異構(gòu)數(shù)據(jù)的云存儲及查詢管理方案。針對圖像數(shù)據(jù)尺寸不一致的問題，提出了基于MapReduce的優(yōu)化圖像分塊存儲算法，實現(xiàn)了高速鐵路道岔異構(gòu)數(shù)據(jù)的Hbase云存儲。通過對某段采集的數(shù)據(jù)進行存儲和查詢性能實驗以及圖像數(shù)據(jù)的分塊存儲實驗，驗證了本方案可行性高，對后續(xù)道岔PHM的深入研究具有重要意義。

本文是結(jié)合現(xiàn)階段鐵路電務(wù)部門實際情況提出的道岔異構(gòu)數(shù)據(jù)云存儲策略，但在圖像數(shù)據(jù)查詢優(yōu)化方面未進行深入研究，后續(xù)將通過算法對其優(yōu)化改進。