基于Apache Spark的地震觀測數(shù)據(jù)噪聲功率譜計(jì)算①

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

1(中國科學(xué)院 計(jì)算機(jī)網(wǎng)絡(luò)信息中心,北京 100190)

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

3(中國地震臺(tái)網(wǎng)中心,北京 100045)

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

在隨著國內(nèi)地震觀測臺(tái)站的持續(xù)布局,我國的地震觀測臺(tái)網(wǎng)不斷加密,截至2018年底,中國地震臺(tái)網(wǎng)中心實(shí)時(shí)匯集的測震臺(tái)站數(shù)量已經(jīng)達(dá)到了1107 個(gè),地震觀測數(shù)據(jù)每年匯集的量級(jí)已經(jīng)達(dá)到數(shù)十TB 級(jí)別.如此海量級(jí)數(shù)據(jù)體量對(duì)數(shù)據(jù)的匯集和分析帶來了巨大的挑戰(zhàn),采用傳統(tǒng)單機(jī)模式進(jìn)行的計(jì)算和分析在時(shí)效性上已經(jīng)無法滿足要求.

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

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

1 地震觀測數(shù)據(jù)分布式處理框架

1.1 地震觀測數(shù)據(jù)的分布式匯集和歸檔

中國地震臺(tái)網(wǎng)中心實(shí)時(shí)匯集的地震觀測數(shù)據(jù)采用國際標(biāo)準(zhǔn)的MiniSeed 格式,每一個(gè)文件中存儲(chǔ)了一個(gè)臺(tái)站一個(gè)分項(xiàng)的24 個(gè)小時(shí)觀測數(shù)據(jù),數(shù)據(jù)匯集在磁盤陣列、網(wǎng)絡(luò)附屬存儲(chǔ)(NAS)等存儲(chǔ)介質(zhì)中,全國1107個(gè)臺(tái)站的具體分布如圖1所示.

圖1 地震觀測臺(tái)站分布

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

圖2 地震觀測數(shù)據(jù)的分布式存儲(chǔ)歸檔

1.2 噪聲功率譜的分布式計(jì)算實(shí)現(xiàn)

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

圖3中,處理模型從上至下共分為3 個(gè)層次.最上層為數(shù)據(jù)源層,主要來源于地震歷史觀測數(shù)據(jù)文件,這些文件存儲(chǔ)在臺(tái)網(wǎng)中心的NAS 存儲(chǔ)服務(wù)器上,通過HDFS的標(biāo)準(zhǔn)接口將NAS 系統(tǒng)上的數(shù)據(jù)推送到HDFS 文件系統(tǒng)中.

圖3 地震觀測數(shù)據(jù)的分布式處理模型設(shè)計(jì)

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

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

2 實(shí)驗(yàn)驗(yàn)證

2.1 測試環(huán)境構(gòu)建

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

表1 存儲(chǔ)型服務(wù)器基本配置信息

表2 計(jì)算型服務(wù)器基本配置信息

圖4 計(jì)算節(jié)點(diǎn)數(shù)據(jù)處理流程

圖5 軟硬件部署圖

2.2 性能測試

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

圖6 建立的分布式數(shù)據(jù)庫集群和Spark 計(jì)算集群環(huán)境

在計(jì)算結(jié)果的存儲(chǔ)和分析上,我們按照RowKey的方式進(jìn)行計(jì)算結(jié)果的存儲(chǔ),如圖7(a)所示,一條數(shù)據(jù)表示一個(gè)臺(tái)站單個(gè)分項(xiàng)某個(gè)小時(shí)的PSD 值,圖7(b)為對(duì)存儲(chǔ)計(jì)算結(jié)果的數(shù)量統(tǒng)計(jì),目前存儲(chǔ)條數(shù)已經(jīng)超過了2000 萬條.而如此海量計(jì)算結(jié)果的可以通過HBase Shell 或者HappyBase 等多種方式進(jìn)行高效的檢索和獲取,在大數(shù)據(jù)分析和處理上相對(duì)單機(jī)節(jié)點(diǎn)具有明顯優(yōu)勢.時(shí)間分布結(jié)果如圖8所示.

圖7 本文設(shè)計(jì)的HBase 存儲(chǔ)的PSD 計(jì)算結(jié)果和HBase 存儲(chǔ)數(shù)據(jù)表

圖8 集群處理不同數(shù)量級(jí)計(jì)算任務(wù)的時(shí)間分布

3 結(jié)論與展望

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