海量GPR檢測數據負載均衡并行處理技術

杜翠 程遠水 張千里

1.中國鐵道科學研究院集團有限公司鐵道建筑研究所，北京 100081；

2.中國鐵道科學研究院集團有限公司高速鐵路軌道技術國家重點實驗室，北京 100081

探地雷達（Ground Penetrating Radar，GPR）是一種快速、無損、高效的地球物理探測方法，廣泛應用于交通設施檢測、地質勘察、環境工程等領域。作為一種高效的淺層地球物理檢測技術，GPR以高頻或超高頻電磁波為信息載體，利用不同介電常數傳播介質之間的界面對電磁波的反射特性和傳播速度變化規律，對目標物進行探測和定位，具有連續探測和實時顯示的特點［1］。GPR技術是鐵路路基、隧道等基礎設施檢測的重要手段［2-4］。隨著鐵路運營里程的迅速增長，GPR數據量呈指數增長趨勢。實現快速、智能的海量GPR數據處理與智能識別，為鐵路智能檢測監測提供技術支撐。

GPR數據處理技術在處理中小尺度數據集上已經相對成熟。但這些技術絕大部分基于單計算節點，涉及的算法往往高度串行化［5-6］。此外，已有的實現方法多基于傳統的單機計算機體系結構和計算模型，完全無法適用于當前大內存、多源異構、高度并行化的硬件架構體系。新一代高性能硬件架構體系的快速發展，給海量GPR數據快速處理的開展創造了新的機遇。目前，由于地震數據規模較大，已開展了較多基于集群模式的算法并行化研究［7-9］，采用了CPU并行、CPU+GPU異構并行、Hadoop等技術。大量高精度、大區域的GPR檢測數據可以利用并行技術進行處理，極大提高處理效率［10-12］。

本文提出海量GPR數據的分布式存儲方法，適應多種文件組成結構，提高數據I/O效率，研究具有較強適應性和較高擴展性的負載均衡并行技術，建立面向數據并行+算法并行的混合并行計算模式。

1 GPR數據分布式存儲方法

以高容錯性為特點的分布式文件系統HDFS（Hadoop Distributed File System）可以利用大量廉價PC機組建成一個來存儲超大文件的集群文件系統。當一臺服務器的存儲容量已經不能承載需要儲存的數據集時，數據集會被分成多個塊以分布存儲在機架的各個服務器上。在進行數據存儲時，HDFS是以數據流的方式寫入的，在實現分布式存儲的同時還具有一次寫入、多次讀取的高效訪問模式。

GPR原始數據為非結構化的特定文件格式，如意大利IDS雷達的*.dt格式，中國礦業大學（北京）GR雷達的*.gpr、*.raw、*.dat格式等。這些文件格式的共同點在于采用二進制存儲，分為文件頭和數據道2部分，數據道的道頭也包含特定的標記信息。在本文研究中，為適應HDFS分塊存儲的模式，將文件頭信息存入關系型數據庫MySQL中，數據道則分塊存儲到HDFS中。

2 混合并行計算模型

2.1 計算任務拆分方法

探地雷達數據劃分的主要目的是將待處理的探地雷達數據合理、均衡地劃分給計算環境包含的所有計算節點，使得不同計算節點承擔的計算任務量大體相當，從而在并行計算開始前盡可能保證負載均衡。數據劃分策略的有效性體現在：各計算節點分配的數據盡可能不相交，具有較小的劃分時間消耗比例及均衡的任務量分配比例。如果以原始文件為拆分顆粒度，有時導致單個計算單元過大，且無法動態調整，從而不能實現并行計算過程中的負載均衡。

首先，確定不同算法類型包含的數據粒度。探地雷達的數據特點在于各道數據間無依賴關系，可根據道號進行切分。根據不同算法原理，可將GPR信號處理算法中的數據粒度設置為單道A-scan較小的B-scan。假如以B-scan為計算單元，則應注意源文件大小或者分布式存儲單塊數據量應為B-scan大小的整數倍，以適應數據邊界。

然后，將算法按計算步驟合理拆分為子任務。從數據起點開始，沿里程方向逐個數據粒度移動，在各個數據粒度內按照規則對各個計算單元進行各個子任務的處理，從而完成全部計算。當數據粒度為B-scan時，假如單個節點劃分的數據量過大，容易產生物理內存不足的情況，從而導致其他節點等待，無法實現負載均衡。

因此，在任務拆分時，應驗證集群內存資源是否滿足數據粒度×節點數量的需求，從而得出數據粒度的最大閾值，并保留一定的冗余空間。

采用Hadoop平臺的MapReduce并行計算框架。MapReduce封裝了并行處理、容錯處理、數據本地化優化、負載均衡等技術難點的細節，這使得MapReduce庫易于使用。MapReduce處理數據流如圖1所示。數據流首先進行分片，與HDFS的分塊大小一致，然后每個分片會分配給用戶定義的map方法進行處理（通過JNI調用dsp_alg），之后針對reduce的數量產生對應的輸出分片，得到map方法輸出的＜key，value＞對后，把相同key值相同的放到一起，最后輸出結果。

圖1 MapReduce處理數據流

2.2 動態負載均衡方法

Hadoop平臺中以Slot作為計算資源的分配單位，map任務和reduce任務都是在Slot上運行。Slot可以理解為單位計算資源，與CPU對應。由于存在數據傾斜或者計算傾斜，每個任務的運行時間不同，可能會出現某個Slot任務完成空閑了，而其他的Slot上還有大量的任務沒有完成。顯而易見，如果此時能夠把其他Slot的任務放到這個Slot上來運行會大大提高系統的資源使用率，同時能夠提升任務的處理效率及系統的吞吐量。

解決方法整體上分靜態負載均衡和動態負載均衡兩類。靜態負載均衡大多是進行算法優化，改變用戶程序，使得整個作業的執行時間盡可能降低。這樣的負載均衡一般都是需要對于當前的作業任務、輸入數據特征和各個機器節點資源有先驗知識。

相比于靜態負載均衡，動態負載均衡不需要改變用戶的應用代碼，也不要針對不同的輸入數據做算法定制優化，系統能夠自動地完成均衡工作。動態負載均衡關注的是Slot的空閑與否，在運行時根據當前運行狀況做出負載分配決策。當系統中出現空閑Slot時，從正在運行的task中挑選一個作為Straggler，即系統中節點的任務，從計算任務重的Slot中遷移一部分任務到空閑Slot中。

3 試驗與分析

為驗證本文提出的GPR數據并行處理方法的應用效果，利用某線路路基檢測數據進行測試。測試數據集由5個40 000道數據的雷達文件組成，執行的算法工作流包含背景去噪、增益、一維濾波、二維濾波、滑動平均共5個步驟。Hadoop集群測試環境見表1，由9個節點組成，其中1個節點為主節點，8個節點為計算節點。

表1 Hadoop集群測試環境

3.1 并行顆粒度測試

將計算任務拆分為不同大小的顆粒度，計算效率見圖2。可知：當最小顆粒度為單個原始文件（40 000道）時，共耗時9 min 42 s。將雷達文件采用本文方法進行分布式存儲，以支撐任意大小道集的并行顆粒度，切片道數從640到3 200，計算耗時變化不大，為1 min 13 s~1 min 31 s。通過對并行顆粒度進一步細分，大幅優化了計算性能，提升了集群資源的利用率。

圖2 不同顆粒度并行的計算效率對比

3.2 負載均衡測試

對本文采用的動態負載均衡效果進行測試，測試結果見表2。可知：場景1設置全部節點執行1次二維濾波算法，耗時31 min27 s；場景2設置全部節點執行2次二維濾波算法，耗時60 min17 s，約為場景1的1.92倍。場景3設置1/2的計算節點（A類）執行1次二維濾波算法，1/2的計算節點（B類）執行2次二維濾波算法。假如采用靜態負載均衡，將數據平均分配至各節點，則B類節點耗時將約為A類節點的2倍，最后運行時間與場景2近似，很明顯這種情況下A類節點的算力未充分利用。采用本文設計的動態負載均衡方法，將會有2/3的數據流轉到A類節點，1/3的數據流轉到B類節點，使得所有節點的計算量大致相等。場景3耗時42 min 6 s，約為場景1的1.34倍，達到了很好的負載均衡效果。

表2 負載均衡測試結果

3.3 進程數測試

對10 GB數據運行二維濾波算法，計算時間與加速比見圖3。可知：當進程數小于物理核數16時，啟動的進程數加倍，計算耗時減少接近1/2。當進程數大于物理核數時，計算性能只有微小的提升。通過測試集群，在8臺物理服務器計算集群上多進程并行可以使二維濾波性能提升100倍左右（相對于單機單進程）。通過8臺服務器一共8×16核=128核，可知集群并行本身框架調度數據讀寫等有一定的消耗，并不能完全達到實際核數使用上的性能翻倍。鑒于集群并行計算環境為Linux，并不運行其他軟件，故可以按照實際物理核數來設置單服務器的并行數，以獲取最大的性能加速比。

圖3 二維濾波并行計算時間與加速比

4 結語

隨著鐵路運營里程的快速增長以及檢測頻次的增加，路基、隧道等基礎設施探地雷達檢測數據量呈指數增長，傳統的單機處理模式無法滿足時效性要求。本文設計了GPR數據的分布式存儲方法，采用Hadoop平臺的MapReduce并行計算框架，基于動態負載均衡方法建立了混合并行計算模型，并搭建了9節點集群環境進行了測試試驗。對并行顆粒度進一步細分大幅優化了計算性能，在模擬迭代算法場景下取得了較好的負載均衡效果，服務器的進程數可按照實際物理核數設置，以獲取最大的加速比。在未來的研究中，將探究各類算法的細粒度拆分方法，進一步完善數據+算法的混合并行計算模式。