基于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 瓶颈和计算瓶颈,大规模提升了计算能力和可处理数据能力;在普适性方面,本文设计的方法更适用于海量数据的计算和管理,随着数据量的增加不需要频繁建立新表和选择存储环境,单机环境下计算和处理存储的数据量有限,数据量较大时需要投入更多人力处理环节.