基于大數據技術的鐵路工務檢測數據平臺方案研究

許丹亞 歐陽慎 齊晨虹 朱志 尹文志

摘要：當前，普速鐵路故障點檢測手段多樣，各種檢測數據的類型多樣，數據量大，查詢分析邏輯復雜。不同于以往基于關系型數據庫的數據處理，方案基于Hadoop大數據集群，采用低代碼的形式和多種數據處理工具，設計實現工務數據同步、存儲、查詢、共享流程，降低了數據存儲成本，提高了數據查詢效率。同時，有助于后續其他業務系統的海量數據開發流程優化，為鐵路各項業務提供穩定、高效數據處理方案。

關鍵詞：大數據；Phoenix；DataX；鐵路；Hadoop

中圖分類號：TP391? ? ? ? 文獻標識碼：A

文章編號：1009-3044（2023）13-0076-03

開放科學（資源服務）標識碼（OSID）

1 引言

我國鐵路系統正在進入大數據的時代，每天多個業務系統將產生海量數據，且數據量逐年增加[1-3]。近年來，中國鐵路鄭州局集團公司普速鐵路故障點檢測手段多樣，包括晃車儀、軌檢小車、人工添乘等。工務各種監測數據體量龐大，數據類型復雜，業務查詢頻繁，對后續海量數據的深度挖掘帶來了一定困難。特別是，晃車儀數據主要依靠人工分析，鄭州局全局192臺晃車儀設備，每天產生幾萬條數據。因此，急需建立工務數據平臺，優化工務各種檢測監測數據的存儲、分析、共享流程。

當前，有不少學者對鐵路業務的大數據應用進行研究。衛錚錚等人，研究了客運大數據平臺的鐵路客流預測系統，集成了各類客流預測算法模型，為各類客運業務分析人員提供定制化客流預測數據[4]。王沛然等人，研究了鐵路數據服務平臺存儲架構設計與應用[5]。王萬齊等人，研究了京張高鐵運營安全大數據平臺設計及關鍵技術，對京張高鐵安全數據共享共用、安全管理和安全預警能力提升，具有參考意義[6]。廉小親等人，研究了面向建設期鐵路大數據的分級存儲方法，有效地對鐵路建設期大數據進行存儲級別判定，實現了面向建設期鐵路大數據的分級存儲[7]。

面對工務檢測數據的數據量大、數據接入復雜、數據查詢分析復雜等問題，常用的數據流程設計方案通常以軟件代碼開發的形式接入數據，采用關系型數據庫實現對多種數據的存儲和查詢。但這種方案在應對超過千萬級數據量時，往往會出現查詢效率低下、存儲成本高等問題。因此，本文以低代碼的形式，基于Hadoop大數據集群和多種數據同步工具，設計并實現了工務大數據平臺，打通數據同步與清洗、數據存儲與查詢、數據共享等數據處理流程，優化了數據處理手段，降低了數據存儲成本，提高了數據查詢效率。

2 總體方案設計

當前工務車載分析系統可接入的數據源，種類多、總量大、查詢需求復雜，具體數據如下：

1） 數據種類多，同步情況不同

工務檢測數據種類多，當前可接入的數據包括，晃車數據、軌檢超限大值、便攜添乘、軌檢小車、人工添乘主表、人工添乘從表等。晃車數據，即晃車儀產生的數據，目前以每月幾十萬條的速度增加，同步頻率為每半小時。軌檢超限大值、便攜添乘、軌檢小車、人工添乘主表、人工添乘從表等其他檢測監測數據，同步頻率為每天，每天增量從幾十到幾百不等。

2） 數據查詢需求復雜

針對各種檢測監測數據，當前查詢內容主要以檢測時間、線別、行別、里程范圍、垂直加速度、水平加速度等為主。在查詢的形式上，大多是針對單一數據內容查詢，也有少許聯表查詢的需求，這些聯表查詢往往業務邏輯復雜。

3） 數據量大

晃車數據的數據量為千萬級別，其他數據的總量在幾萬到幾百萬之間。隨著時間增加，各監測數據量在不斷增大，也增加了服務器存儲壓力。

根據以上數據特征，按照數據的處理流程，本文設計和實現了基于大數據技術的鐵路工務檢測數據平臺，主要包括數據同步、數據存儲與查詢、數據共享三部分，如圖1所示。

3 數據同步與清洗

通過DataX、Sqoop等數據同步工具，從物理和邏輯層次上，把各種監測數據集中匯聚，完成數據同步與清洗，為后續大數據應用開發提供數據支持。由于數據內容中單位名稱、線路名、里程值等存在不規范的現象，所以需要額外的數據清洗工作，規范數據內容。

首先，定時從遠端Oracle服務器采集監測數據。之后，根據數據的種類、同步頻率和查詢需求，將采集后的數據分為晃車儀數據和其他檢測數據。

對于軌檢超限大值、便攜添乘、人工添乘主表、人工添乘從表、軌檢小車等數據，數據總量最大約為百萬級，增量數據較小。采用現有數據同步工具DataX，將遠端Oracle數據庫同步到本地MySQL中，并設置定時增量數據導入任務[8]。DataX是阿里巴巴集團內被廣泛使用的離線數據同步工具/平臺，可實現包括MySQL、Oracle、HDFS、Hive等各種異構數據源之間高效的數據同步功能。同時可集成插件，對同步的數據進行定制化開發，完成數據清洗功能。

對于晃車儀數據，總量較大，為千萬級，且隨時在增加。所以，數據同步分為全量同步和增量同步。全量同步，是將過去五年內所有數據一次性導入。這種操作較為耗時，且校驗數據完整性復雜。增量同步是隨著時間變化，將新增數據同步到本地數據服務器中。同時，需要做到實時同步，頻率較高，而遠端數據庫中新增數據的時間和數量不固定。另外，數據內容中存在單位名稱、線路名稱等不規范情況，需要在接入時進行數據清洗操作。

根據晃車數據的數據量大和查詢復雜的特點，方便設計后續存儲和查詢方案，即將晃車數據存儲至Hadoop大數據平臺，使用HBase上層查詢引擎Phoenix提升查詢速度。故，在接入全量晃車數據時，使用Phoenix組件自帶lib庫的現有數據導入工具CsvBulkLoadTool，底層執行分布式MapReduce任務并行導入，并同時對Phoenix二級索引進行更新。經測試，Phoenix MR方式導入一千七百萬數據耗時10min左右，可快速導入大量數據，并保證數據的完整性。對于增量的晃車數據導入，采用數據同步工具DataX，定時獲取某個時間段內增量數據插入到大數據集群中，并且在插入到集群之前，集成數據清洗插件Transformer，定制化轉換數據內容。

4 數據存儲與查詢

對于軌檢超限大值、便攜添乘、人工添乘主表、人工添乘從表、軌檢小車等檢測數據，數據本身總量約為百萬級，增量數據較小，采用MySQL存儲，提供查詢服務。

對于晃車數據，總量為千萬級，增量相對較大。傳統的關系型數據庫MySQL難以支持數據的存儲，后期維護也越來越復雜，急需能夠存儲大量數據且查詢速度快的數據庫。因此，適合采用分布式大數據集群存儲。HBase底層應用分布式文件系統，在處理龐大表上十分有優勢。由于HBase是分布式存儲，為了優化存儲性能和后續查詢性能，防止數據傾斜問題，本文采用預分區HexStringSplit算法，根據Rowkey編碼，HBase也會通過算法將其分到不同的Region，實現均勻分布，避免熱點問題。

HBase本身是列存儲，僅能查詢單個字段值，不能滿足業務系統對一條數據所有字段的詳細查詢需求，而Phoenix可將多列數據聚合為行，同時查詢出多個字段值，使用體驗上和關系型數據庫類似。Phoenix是一個開源的HBase SQL層，支持二級索引、事務以及多種SQL層優化。二級索引可大幅度提升數據查詢速度。

在創建索引時，根據業務查詢需求，將常用的查詢字段，包括檢測時間、線編號、行別等，加入索引列中。同時，需要使用include語法，將其他未在索引中的字段包含[9]。之后，在查詢過程中即可包含所有字段，滿足對詳細數據的查詢需求。隨著Phoenix表中數據持續增加，創建新的索引往往耗費大量時間。索引的底層原理仍是通過HBase特性，建立數據表，表的key由多個索引字段構成，value是對應數據的rowkey。因此，隨著數據量的增加，索引的存儲量也會增加。如果創建索引的時間超過Phoenix客戶端的固定時間，將出現創建超時的問題。在后續使用中，如果需要創建其他業務相關的索引時，可以通過Phoenix的lib庫中IndexTool工具，執行Mapreduce任務，創建異步索引。另外，在使用Phoenix提高查詢效率時，需要注意時間類型的時區問題。Phoenix的數據類型默認時區是UTC，而日常多用GMT+8時區。在具體使用時，需要進行時區的轉換操作。

為了進一步提升查詢性能，根據HBase運行原理，進行修改HBase部分配置。對于HBase的Master，最大內存設置為當前機器內存的60%左右，最小設置為2G即可滿足運行需求。對于HBase的RegionServer，內存設置為服務器內存的50%～70%。對于HBase的HFile，設置hfile.block.cache.size為0.5甚至0.6。同時參考hbase.regionserver.global.memstore.upperlimit，如果兩值加起來超過80%～90%，會有內存溢出的風險。

5 數據共享

對于軌檢超限大值、便攜添乘、人工添乘主表、人工添乘從表、軌檢小車等檢測數據，數據存儲在MySQL中，直接通過MySQL查詢，使用JDBC連接共享至下游工務車載數據分析業務系統即可。

對于晃車數據，存儲于大數據集群中，并通過HBase上層組件Phoenix優化查詢。在數據共享時，雖然Phoenix提供通過JDBC連接的形式訪問數據，但是，這種方式功能不夠全面，多個系統之間集成交互困難，也不具備權限驗證功能。因此，采用HTTP接口形式，可以較好地解決不同系統之間的交互需求。在傳輸數據時，采用POST方法而不是GET方法，對傳輸數據內容的大小更寬容。

由于查詢條件不固定，如果根據不同的查詢請求開發不同的接口，接口不具有靈活性，開發周期長，后續擴展性差。所以，參考常用持久層框架MyBatis，將通用查詢功能總結為三種，查詢所有詳細信息list、查詢分頁信息page、和查詢數據總量count，并將這三種功能開放為3個訪問接口。

在傳遞查詢參數上，本文封裝了查詢參數。查詢參數內部包括查詢屬性和分頁屬性。查詢屬性中可包含多個查詢條件。每個查詢條件包括查詢字段、查詢關系、查詢數值。分頁屬性包括頁面大小和頁碼。因此，根據查詢參數，即可組合多種查詢條件，滿足不同需求。

針對具有復雜業務邏輯的聯表查詢，需要額外的設計方式。雖然Phoenix本身提供聯表查詢功能，但是，在實際使用時發現Phoenix在聯表查詢時的一些缺陷。比如，聯表查詢的聯查條件不能為大于或者小于，只能是等于。隨著聯表查詢的復雜度增加，查詢效率也會隨之下降。因此，結合Phoenix索引查詢效率高的優點和Java內存處理快的優點，本方案根據實際業務邏輯，先從大數據集群中，通過索引，以毫秒級速度獲取單一表結構數據到內存中，然后，以代碼的形式，根據聯查條件，從內存中使用stream流篩選合適的數據。

6 應用結果分析

傳統的業務系統存儲數據時常用關系型數據庫，例如MySQL、Oracle等。為了提高查詢效率和緩解存儲壓力，本方案通過Phoenix組件，數據進行存儲、查詢、共享等流程。本章從存儲壓力和查詢性能兩個方面，對MySQL和Phoenix方式進行對比。

在存儲層面上，對于存儲相同數據量的晃車數據，使用MySQL存儲容量為10.35GB，包含數據6.7GB，索引3.65GB。使用HBase存儲容量為10.2GB，包含數據5.4GB，索引4.79GB。其中，HBase中的數據存儲在HDFS中，副本為3。對于相同的數據，采用HBase存儲容量略小于MySQL存儲容量；采用HBase存儲數據三重備份，容災性更強。

在查詢性能上，使用4個測試用例，即根據里程范圍查詢、根據報警級別查詢、根據報警值范圍查詢、根據線路查詢，分別測試查詢所有明細數據list、查詢分頁數據page、查詢數據總量count的時間，如表1所示。對于MySQL，各個測試用例的查詢時間范圍在0到5秒。對于Phoenix二級索引，大部分測試用例的查詢時間在500毫秒內，可做到秒級響應。

另外，隨著數據量的增長，在MySQL中查詢數據的時間將逐漸增加，而在HBase中存儲的數據，借助Phoenix二級索引分布式查詢，查詢速度隨著數據量的增加仍然保持恒定。

可得出結論，相比MySQL，使用HBase分布式數據庫更適合存儲晃車數據，使用相同的存儲容量，HBase可存儲更多數據，同時三重備份，提高了數據容災性；使用Phoenix二級索引比MySQL索引平均提升查詢效率為5倍，最高提升18倍，最低提升1.14倍。

7 總結與展望

本文提出一種針對工務監測數據的數據同步與清洗、數據存儲與查詢、數據共享各流程的技術方案。在數據同步與清洗方面，采用數據集成工具DataX，將多種監測數據匯聚接入。對于軌檢超限大值、便攜添乘、人工添乘主表、人工添乘從表、軌檢小車表，使用關系型數據庫MySQL進行數據存儲和數據查詢。對于晃車數據，使用分布式存儲HDFS和HBase，使用Phoenix優化查詢效率，并針對查詢特點，設置數據共享HTTP接口。本文方案統一管理多種數據接入，降低了存儲壓力，提高了查詢效率。方案經驗證和試運行，使用便捷、性能出色，具有一定的應用和參考價值。

參考文獻：

[1] 何欣玲，劉宇，趙天，等.鐵路數據中心基礎設施管理系統的研究[J].鐵路計算機應用，2020，29（10）：21-25.

[2] 馬小寧，李平，史天運.鐵路大數據應用體系架構研究[J].鐵路計算機應用，2016，25（9）：7-13.

[3] 宋一凡，張玉福.鐵路運輸清算系統運行實踐研究[J].鐵道運輸與經濟，2013，35（9）：38-42.

[4] 衛錚錚，單杏花，王洪業，等. 基于客運大數據平臺的鐵路客流預測系統[J]. 鐵路計算機應用，2022，31（1）：37-42.

[5] 王沛然，馬小寧，王喆，等. 鐵路數據服務平臺存儲架構設計與應用[J]. 鐵路計算機應用， 2021，30（5）：5.

[6] 王萬齊，劉軍，李平，等.京張高鐵運營安全大數據平臺設計及關鍵技術[J].鐵路計算機應用，2021，30（7）：61-65.

[7] 廉小親，楊凱，程智博，等.面向建設期鐵路大數據的分級存儲方法研究[J].鐵路計算機應用，2022，31（2）：17-22.

[8] 陳宇收.基于Datax的數據同步方案研究[J].電腦編程技巧與維護，2018（9）：97-98，13.

[9] 劉文東. 基于Phoenix平臺的空間數據索引與查詢技術研究[D].西安電子科技大學，2018.

【通聯編輯：王力】