高速鐵路道岔異構數據在Hbase上的云存儲方案

張志哲，徐田華，李 波

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

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

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

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

1 道岔數據分析

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

1.1 道岔現場數據

道岔現場采集數據是進行道岔健康管理研究的基礎。考慮數據復雜性，在傳統的關系數據庫中存儲時需要建立多個表格，每個表格分別建立多列表頭及約束，十分占用存儲空間。

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

圖1 道岔數據結構

1.2 道岔圖像數據

道岔圖像數據（非結構化）主要來自轉轍機中攝像機拍攝的缺口監測圖像數據以及監測系統軟件的設備狀態圖。為了更好地將其存儲并加以利用，也需云存儲技術加以解決。

2 Hbase介紹

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

2.1 HDFS分布式文件系統

HDFS作為Hadoop平臺的核心部分，采用了主/從架構對文件系統進行管理，由一個名字節點Name Node和多個數據節點Data Node組成。HDFS具有以下優點：

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

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

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

2.2 Hbase數據庫

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

3 基于Hbase的結構化數據存儲架構

對于道岔設備歷史數據的轉存使用Sqoop數據遷移工具。Sqoop既可以實現將 Hadoop 和 Hbase中的非結構化數據轉存到關系型數據庫中，也可以將MySQL及Oracle等關系型數據庫中的結構化數據存儲到 Hadoop的 HDFS中轉為非結構化數據[11]。通過局域網讀取集中監測系統數據庫，轉存方便且不影響設備正常工作。結構化數據的云存儲架構，如圖2所示。

圖2 結構化數據的云存儲架構

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

4 非結構化圖像數據云存儲策略

4.1 圖像數據存儲流程

對于道岔圖像數據，現階段并沒有對其提起重視，也應將其統一存儲管理。這里以道岔缺口監測圖像數據為例，其存儲所設計的流程，如圖3所示。

圖3 圖像數據存儲流程圖

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

4.2 圖像數據存儲表格設計

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

表1 Hbase圖像數據存儲結構

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

4.3 大圖像數據切割

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

4.3.1 算法可靠性分析

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

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

切割前圖像數據信息總量為：

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

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

4.3.2 圖像數據切割算法

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

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

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

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

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

圖4 圖像數據的分塊處理云存儲流程

4.3.3 MapReduce優化的圖像數據分割存儲

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

圖5 MapReduce優化的圖像數據分割存儲流程

5 實驗分析

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

5.1 現場數據存儲實驗過程

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

表2 MySQL中道岔動作電流數據結構

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

5.2 非結構化圖像數據實驗過程

5.2.1 缺口監測圖像數據存儲過程

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

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

5.2.2 分塊存儲實驗過程

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

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

再通過Java在Hbase讀取目標截圖并還原，未發生失真現象，與原始圖像數據一致。

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

圖6 MySQL與Hbase查詢性能對比

5.3 Hbase查詢性能測試

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

圖7 MySQL與Hbase查詢性能對比

6 結束語

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

本文是結合現階段鐵路電務部門實際情況提出的道岔異構數據云存儲策略，但在圖像數據查詢優化方面未進行深入研究，后續將通過算法對其優化改進。