基于Apache Spark的地震觀測數據噪聲功率譜計算①

郭 凱,黎建輝,溫亮明,2,韓振華

1(中國科學院 計算機網絡信息中心,北京 100190)

2(中國科學院大學,北京 100049)

3(中國地震臺網中心,北京 100045)

4(太原理工大學,太原 030024)

在隨著國內地震觀測臺站的持續布局,我國的地震觀測臺網不斷加密,截至2018年底,中國地震臺網中心實時匯集的測震臺站數量已經達到了1107 個,地震觀測數據每年匯集的量級已經達到數十TB 級別.如此海量級數據體量對數據的匯集和分析帶來了巨大的挑戰,采用傳統單機模式進行的計算和分析在時效性上已經無法滿足要求.

以數據質量評估為例,地震觀測臺站記錄系統瞬態變化、儀器毛刺、數據記錄的階躍、尖峰以及由于系統故障引起的信號失真和重大環境的干擾等,都是影響數據記錄質量的重要因素,國際上主要采用噪聲功率譜PSD[1]和功率譜密度概率密度函數PDF 等方法進行臺站的噪聲水平監測[2].目前美國地震學研究聯合會(IRIS)數據管理中心(DMC)將相關方法集成形成了單機運行的軟件PQLX和相關腳本程序,國內相關研究開發大多都采用Matlab 等單機程序開發編制[3].這些處理方法計算效率受限于單機處理能力,在面向海量地震觀測數據計算時均存在磁盤IO 瓶頸,主要原因在于其處理保存的數據量和計算結果非常有限,一般僅能處理半年到一年之內全國監測臺網的數據,不利于對地震觀測臺站進行長周期的數據質量評估和挖掘分析.

隨著大數據技術的高速發展,以Hadoop和Spark為代表的開源大數據平臺在處理海量數據的IO 并發和處理速度方面都體現了巨大優勢,它們為存儲和處理大數據提供了動態、彈性和可伸縮的數據存儲和分析解決方案,在密集科學數據處理和分析挖掘應用中取得了較好的效果[4],如生物學領域的密集計算[5]、海量行人軌跡數據的挖掘分析[6]、海量日志文件的分析等.在地震學領域也開展了相關研究[7],如基于MapReduce實現地震數據的成像[8],基于Apache Spark 實現地震事件的快速分類等[9].盡管相關研究工作已經表明大數據技術在海量地震觀測數據處理上具備可行性和應用性能優勢,但成果的重心偏向于海量數據計算速度上的提升,而對數據的全鏈條處理和分析較少關注.本文試圖從海量測震波形數據的分布式匯集、存儲到分布式計算架構構建開展數據全鏈條研究,選擇在地震觀測數據質量評估中需要密集計算的噪聲功率譜方法進行具體實現.

1 地震觀測數據分布式處理框架

1.1 地震觀測數據的分布式匯集和歸檔

中國地震臺網中心實時匯集的地震觀測數據采用國際標準的MiniSeed 格式,每一個文件中存儲了一個臺站一個分項的24 個小時觀測數據,數據匯集在磁盤陣列、網絡附屬存儲(NAS)等存儲介質中,全國1107個臺站的具體分布如圖1所示.

圖1 地震觀測臺站分布

按照NAS的存儲性能和網絡帶寬限制,一般每秒可處理的數據吞吐量在幾十MB 左右,顯然在面對TB 級別的業務計算場景時,該速度已經無法滿足要求.Hadoop是一種專門用于批處理的分布式系統基礎架構,其通過配合使用多個組件來實現批處理業務:① 分布式存儲層HDFS,協調集群節點間的存儲和復制,作用于數據來源,保障整個集群中發生故障時數據的冗余,用于存儲中間態的處理結果和計算的最終結果,完成海量數據的存儲;② 資源調度層YARN,協調并管理底層資源和調度作業的運行.Hadoop 廣闊的生態系統和與其他框架/引擎之間良好的兼容性與集成能力使其成為多種工作負載處理平臺的底層基礎.我們選取了2013年1月～2020年10月的地震觀測波形數據進行遷移,目前已遷移約數據體量約為70 TB,通過萬兆網絡將這些數據傳輸到分布式文件系統HDFS中,按照1:3的比例對數據進行副本設置以確保歸檔數據的安全性,即將一份數據分布存儲在3 個數據節點上(如圖2所示),歸檔數據按照年/月/日/臺站_測項的路徑進行存儲.

圖2 地震觀測數據的分布式存儲歸檔

1.2 噪聲功率譜的分布式計算實現

目前主流的開源分布式計算系統主要有MapReduce、Spark、Flink、Storm 等[10],MapReduce 在數據處理過程中需要在硬盤進行讀取和寫入,降低了運行速度,而隨著硬件性能的不斷提升,基于內存計算的分布式計算框架相對MapReduce 有了明顯提升.針對海量地震觀測數據進行高并發的計算與分析,建立一套具有高可靠、高處理性能、可在線彈性伸縮、可不間斷接收任務的處理模型,由于本文要實現的數據密集計算場景一般以小時為單位進行計算,所以在計算架構上不考慮應用與實時數據解析計算相關的Storm和Flink 系統.同時由于PSD 算法包含了復雜的迭代過程,相對于Hadoop的MapReduce 而言,Spark 在這方面有著較明顯的優勢[11].綜合以上多種因素,我們的數據處理模型采用分布式內存計算平臺Spark,聚焦海量地震觀測數據的分布式噪聲功率譜計算進行模型設計和實現,如圖3所示.

圖3中,處理模型從上至下共分為3 個層次.最上層為數據源層,主要來源于地震歷史觀測數據文件,這些文件存儲在臺網中心的NAS 存儲服務器上,通過HDFS的標準接口將NAS 系統上的數據推送到HDFS 文件系統中.

圖3 地震觀測數據的分布式處理模型設計

中間層為數據處理層,主要完成數據計算和數據處理過程,提供基于地震觀測數據的預處理、臺站儀器基礎數據以及分布式架構的PSD 數值計算.Spark的主節點在接收到前臺傳遞需要處理計算的參數后(日期、臺站以及通道)分配處理任務所需的資源后,將任務分發到各個工作節點,由各個節點完成計算過程并將結果反饋給主節點.當處理層在接收到PSD 計算請求時,算法調度模塊根據請求參數中的時間范圍、臺網以及臺站等參數查詢出需要計算的每個文件的具體位置,同時將文件位置以及任務ID 推送至計算模塊的sever 端;計算模塊在接收到計算請求后,通過參數中的路徑直接從HDFS 上獲取需要處理的mseed文件,并對每個mseed 文件進行計算.這里PSD的計算模塊主要采用美國地震學研究聯合會(IRIS)數據管理中心(DMC)提供的PSD 計算程序,數據計算完成后,計算模塊將計算結果生成在一個臨時文件中(頻率和PSD 數據值),并通過sever 將計算結果和臨時文件的路徑通知算法調度模塊,算法調度模塊根據臨時文件路徑去解析臨時文件并與查詢參數組成的RowKey一起存入HBase 數據表中.

最下層為數據存儲層,主要提供處理層中各類計算結果的存儲,包括PSD 值和PDF 值.由于全國臺站每個分項的觀測數據計算頻率為每小時一次,因此需要將這些大量的結果數據存儲在分布式數據庫HBase中,通過HBase 接口進行存儲和訪問處理.當大量的計算結果到HBase 數據庫時,由于HBase 表會被劃分為1,…,n個Region,被托管在RegionServer中.Region 兩個重要的屬性:start-key與end-key 表示這個Region維護的RowKey 范圍,當我們要讀/寫數據時,如果RowKey 落在某個start-end key 范圍內,那么就會定位到目標region 并且讀/寫到相關的數據.鑒于幾點,在設計表將計算結果按照臺站首寫字母進行排序存放在一個region 里面,使得數據檢索更加快捷方便,尤其在scan 某個通道的數據設置start-key和end-key 時,只需在某個Region 里面檢索就可以了;各個Region 分散在集群的各個位置,增加了數據讀寫的并發量.這里數據處理模塊按照小時對地震觀測數據的PSD 值進行計算,采用RowKey 格式為“臺網代碼_臺站代碼_測項代碼_年_月_日_小時”,colum為”value”,儲存值為以某個小時的PSD 數值.

2 實驗驗證

2.1 測試環境構建

為了驗證以上分析處理框架的有效性,我們搭建了測試系統進行實驗驗證.設計的系統總體軟硬件部署如圖4所示,采用14 臺高性能服務器搭建了具體的系統集群環境(如圖5所示).14 臺服務器的具體部署情況為:2 臺作為管理節點,8 臺存儲型服務器作為存儲節點,4 臺服務器作為計算節點.各類型服務器的基本配置信息如表1、表2所示.所有服務器均為機架式服務器,配置12 個可熱拔插的硬盤接口,其中存儲服務節點掛載12 塊4 TB SATA 硬盤,計算節點配置4 塊600 GB 高速SSD 硬盤.

表1 存儲型服務器基本配置信息

表2 計算型服務器基本配置信息

圖4 計算節點數據處理流程

圖5 軟硬件部署圖

2.2 性能測試

基于上述搭建的環境,我們以不同數據量開展了計算測試.為了對系統整體計算性能進行充分測試,按照4 個計算節點,以不同數據集計算時間來進行評估.如圖6所示,Data Number為計算任務包含的單個臺站24 小時記錄的連續波形數據數量,每一條數據量約12 MB.計算結果顯示,集群在數據處理能力上處理時間與任務量呈現很好的線性關系,處理速度并不會因為數據量的極速增加而變慢,處理完成1 個月全國匯集的地震觀測數據,數據量約1 TB的計算約需要60 個小時,而基于單節點,采用IRIS DMC的PSD 程序開展同樣計算需要處理的時間可能會超過了10 天,且在海量數據的處理和計算結果存儲上會受到單機計算節點性能的影響.通過整體評估以及已有研究工作[12],單機節點計算與本文采用的方法計算速度比值約為1:N,N為計算節點的數量,即集群可以直接通過增加計算節點提升集群處理速度,具有很好的擴展性,面向數據密級型的業務計算和存儲分析具有很好的性能表現.

圖6 建立的分布式數據庫集群和Spark 計算集群環境

在計算結果的存儲和分析上,我們按照RowKey的方式進行計算結果的存儲,如圖7(a)所示,一條數據表示一個臺站單個分項某個小時的PSD 值,圖7(b)為對存儲計算結果的數量統計,目前存儲條數已經超過了2000 萬條.而如此海量計算結果的可以通過HBase Shell 或者HappyBase 等多種方式進行高效的檢索和獲取,在大數據分析和處理上相對單機節點具有明顯優勢.時間分布結果如圖8所示.

圖7 本文設計的HBase 存儲的PSD 計算結果和HBase 存儲數據表

圖8 集群處理不同數量級計算任務的時間分布

3 結論與展望

本文采用目前主流的Hadoop和Spark 技術,基于海量地震觀測數據的業務應用場景,設計了基于HDFS的地震觀測數據分布式歸檔和基于Spark 分布式計算架構,適用于數據密級業務場景的計算和分析.從開展的不同數量級計算任務來看,本文所提出的方法在原始程序數據處理流程上優化了數據的接入和處理環節,計算速度不會因數據量的大幅度提升而下降,解決了單機節點處理海量數據的IO 瓶頸和計算瓶頸,大規模提升了計算能力和可處理數據能力;在普適性方面,本文設計的方法更適用于海量數據的計算和管理,隨著數據量的增加不需要頻繁建立新表和選擇存儲環境,單機環境下計算和處理存儲的數據量有限,數據量較大時需要投入更多人力處理環節.