0 引言

我国地震事业先后经历了模拟观测、“九五”数字化、“十五”网络化等阶段，积累了大量地震数据，并随着数据量的增长，其规模、价值和影响不断扩大。2018年，中国地震局印发了《地震信息化顶层设计》《地震信息化行动方案（2018—2020年）》，制定了地震信息化发展方向和蓝图框架。旨在改变多年发展形成的各业务间纵向贯通、横向隔离、烟囱林立、交互困难的现状，通过标准化、集约化、流程化、数字化建设，打造横向集约、纵向融合、资源共享、高效协同的全局全量地震数据中心。随着国家地震烈度速报与预警项目、“一带一路”项目、防震减灾信息化工程等重点项目的建设，我国地震台网规模不断扩大，地震数据存储量爆炸式增长。如何实现地震观测数据长期存储、数据快速访问和服务，成为目前数据管理面临的重要问题之一。基于大数据等信息技术，研究适合地震观测数据的统一存储模型，以提高数据存储效率和访问速度，显得愈发迫切。

1 地震观测数据存储现状

现网运行的地震观测与数据处理系统与“九五”“十五”期间的地震业务处理相适应，观测台站实时或准实时产出原始观测数据并传输至省数据处理中心，省中心汇聚存储省内各台站地震原始观测数据并进行加工处理，将原始观测数据传输到国家中心，国家中心汇聚存储全国各省地震原始观测数据，并进行数据处理，产出地震产品。国家中心对所有地震观测数据均进行持久化保存，数据量持续增长。在该模式下，地震数据被多级多节点同时存储，既浪费存储资源，也不利于地震数据的同步统一。

众所周知，省份只是国家的行政区划，地震事件的发生与省份的划分并无直接联系，很多地震发生在多省交界处，此时，跨省地震数据交换需要通过国家中心进行中转，而不能进行直接通信，这大大增加了骨干网数据传输的压力。目前，地震数据的生产、管理和服务依托于地震各业务领域，并按照业务职能流动于各业务领域，如测震台网原始观测数据格式主要为SEED或miniSEED，对于地球物理台网数据，主要采用Oracle数据库进行管理和存储（周克昌等，2013），不同学科地震原始观测数据存储的格式和模式存在较大差异。地震事件发生时，各类地震观测仪器均可能记录到地震异常，而跨业务领域的数据调度与协同处理尚难以实现。

此外，数据库表设计的逻辑维度与物理仪器是松耦合的。以地球物理场Oracle数据库为例，存储原始观测数据和预处理数据的库表是以“机构代码（默认为“QZ”）—测项代码—数据类型—采样率代码”的方式建表，将不同台站相同测项、相同采样率的数据放在同一表中，对同一测项按采样率分别建日值表、小时值表、分钟值表、秒值表和事件数据表，这导致一套仪器可能产生多个测项的数据，这些数据分散存储在多个数据表中。一套仪器的新增和淘汰会波及到多张库表，数据库的弹性扩缩能力、数据查询的灵活度、数据质量监控等方面均受到一定影响。

2 地震观测数据融合存储模型设计

针对地震观测数据的存储现状，结合地震观测数据的特征，选择合适的数据库，开展地震观测数据融合存储模型设计。参考相关研究（吴晗，2020；岳鹏昊，2020；刘刚等，2020），整合不同来源、不同规格的台站仪器数据，从不同维度进行地震数据的深度挖掘与分析。

2.1 地震观测数据特征分析

地震观测数据的空间属性和时间属性显著。地震观测仪器通过将模拟信号转换为数字信号而产出观测数据值。通过人为增加对观测仪器的空间位置描述，可唯一确定数据流；再通过记录数据的时间戳，即可唯一确定一条观测数据。

从空间属性来讲，地震观测数据是地震仪器在特定地点产出的连续波形数据。按照地震监测台网的业务管理模式，每一个数据流均具备“台网、台站、测点（仪器）、通道（测项分量）”的空间属性。其中，台网按照学科可分为测震台网、地球物理台网等，按照业务体系分为国家级台网、省级台网，按照省份分为31个省中心。台站是地震数据产出的源头，为不同学科数据的观测场所。测点是观测仪器所在的具体地理位置。通道是指每套仪器不同的观测分量，1个测点可以有多个通道，每个通道产生1个数据流，通道是确认数据流的最小单元。台网、台站、测点、通道的关系如图 1所示。

从时间属性来讲，地震观测仪器7×24 h不间断产出观测数据，数据被实时、准实时地汇聚到省中心和国家中心。不同仪器的数据采样率不同，包括毫秒级、秒级、分钟级、小时级等。所记录的观测数据具有连续性，一旦开始产出，不会自行中断，除非受到人为干预、网络或机器故障等外界因素的影响。同时，观测数据具有上下文相关性，当处理1个时间段的数据时才具有实际意义，当仅处理某一时间点的数据时则是无意义的。

2.2 数据库选取

本研究需基于大数据及分布式技术搭建数据存储集群。笔者调研了HBase、ClickHouse、TDengine等多种分布式数据库技术，发现每种数据库具有不同特点。因HBase数据库的优势与地震业务的契合度较高，故选用HBase数据库进行模型设计。单条地震观测数据的数据量较小，以测震数据来说，单条数据量仅为512 B或256 B，然而覆盖全国的地震台站规模庞大且还在不断扩建中，因此，整体数据写入量及数据存量较大，在数据源源不断产出过程中，要求数据存储低延迟，以避免产生数据拥塞。在存储量级方面，HBase数据库可处理超大规模数据集，适用于未来海量的地震观测数据存储场景；在存储空间利用方面，我国地震台站的历史数据存在着大量纸质材料数据或尚未补足的数据，实时数据和基础数据中也存在着很多空值，而HBase数据库中值为空的列不占用存储空间，对稀松数据集较友好；在重复数据处理方面，由于数据的多源汇集和补数机制，会出现一定的重复记录，而HBase的幂等机制允许对相同主键的数据进行覆盖读入，以保证数据的完整性和准确性，并降低数据的重复率；在稳定性方面，HBase数据库是一种基于分布式的列式存储数据库，在众多分布式场景下，HBase数据库的应用较普遍，在多个行业的应用均证实其稳定可靠（陈清，2021；夏正龙等，2021；张昊等，2021；杨力等，2022），在地震行业也多次被应用于地震大数据存储科学研究（刘坚等，2015；王丹宁等，2016；李建桥，2021）。

2.3 数据库表结构设计

根据HBase的逻辑存储结构，1条记录由RowKey、列、timestamp等3个维度进行区分。综合分析不同学科的地震观测数据结构特征，设计HBase数据库表结构为“RowKey（主键）+ data（原始观测数据或预处理数据）+ timestamp”的形式。其中，RowKey作为数据存储和检索的关键，其设计尤为重要。

一般来说，地震数据的检索需求主要为获取某个或某些台站在某个时间段内的数据。因此，在RowKey的设计中，首先要考虑数据流的唯一确定性，以便精确定位数据来源。通过前文分析可知，空间特征“networkID—stationID—location—channel”明确了这一点，这4类数据均可通过miniSEED包头解析而得，我们将此信息作为组成RowKey的一部分。其次，将数据采样时间作为RowKey的另一部分，以便在检索时利用时间戳来精确定位指定时间段的地震数据。由于HBase数据库默认是按照RowKey正序排序的，而在实际使用时，常常是最新的数据被检索的频率更高，因而采用对数据开始时间戳进行取反处理的方式构建RowKey，使得在检索时新存入数据库的数据先被检索到，在一定程度上能提高数据检索效率。时间戳以采样率最高的毫秒级数据时间戳位数最多，有13位数字，RowKey中设计time值，其计算公式为

$ \text { time }=1 \times 10^{14} \text {-starttimestamp } $

(1)

同时，数据会根据RowKey存入规定的region节点，数据的networkID、stationID等信息越接近，越容易被存入到相同region节点。当地震发生时，相邻台站均监测到地震事件，它们的数据很可能存放于某几个region，出现某些region高负荷工作而其他region闲置的情况。通过负载均衡优化可提高数据存储性能，利用哈希算法将数据流分散存储到不同region中，设计RowKey首位为1个十六进制数字hash，其计算公式为

$ \text { hash }=\text {mod}\;\text { [ HashCode('networkID' + 'stationID' + 'location' +'channel' +'time), 16] } $

(2)

综上所述，可以设计RowKey为“hash—networkID—stationID—location—channel—time”。该设计的优势在于：①数据库表RowKey的逻辑结构与数据流的时间、空间属性对应，可唯一标识数据流及数据，字段可读性强；②便于仪器故障定位，且可将仪器故障恢复对存储模型的影响范围降到最小；③便于对多维度的数据灵活查询和快速检索；④便于数据的统一存储管理。

对于data，测震、强震学科的data为二进制miniSEED格式的观测数据，地球物理场的data为观测值，每个观测值数据单独作为一列存放。对于timestamp，设置测震、强震数据为结束时间戳，通过与RowKey中的time进行计算可得出该行数据的时间范围，地球物理场数据则使用默认值，以便应对后期补数等情况。

3 地震观测数据融合存储模型验证 3.1 基础环境配置

本研究以地球物理场观测数据为例开展模型验证。对照组为地球物理台网管理系统Oracle数据库。实验组利用5台相同配置的服务器搭建HBase验证环境，每台服务器配置为：2U机架式服务器，产品型号为H3C R4900 G3，操作系统为CentOS Linux release 7.9.2009（Core），处理器为2颗Intel Xeon Gold 6248 CPU，内存512 GB，数据盘作raid 5配置后有效存储空间为60.6 TB，交换空间100 GB，数据以3副本方式存储，其中，2台做master节点，3台做region server，所搭建的HBase版本为1.2.0，jdk版本为1.8.0_111。所有指令均由同一台计算机发出并执行。

3.2 模型验证与分析

地震观测数据由仪器端产生后存储至数据库表中，业务人员在对地震观测数据进行处理时，较频繁的操作主要是数据的查询。针对数据查询的业务场景，开展以下实验，通过对比查询时效性进行模型验证。

（1）相同数据查询比较。分别使用Oracle、HBase数据库，查询相同条目、相同内容的观测数据，用时情况如图 2所示。

由图 2可见，查询相同数据条目时，HBase数据库查询用时小于Oracle数据库，且用时差距随着数据量的增多而变大。HBase数据库查询效率优于Oracle数据库，表明基于分布式的数据处理系统在查询效率上要优于传统系统，且数据量越大，其优势越明显。

（2）相同维度查询比较。按照台站维度，查询stationID为“11001”的观测数据。在HBase数据库中可一次性查询到112 366条数据。在Oracle数据库中，仅能查询到某一个表中的29 346条观测数据。这是由于Oracle数据库是以“测项分量+采样率”进行建表，而同一台站可能具有多个测项分量，所以同一台站产生的地震数据可能分散在多个表中，难以实现台站维度的数据查询。改进模型的HBase数据库，跨越了测项分量的限制，数据查询的灵活度有所提升，这对于仪器运维也具有一定指导意义。

4 实际应用成效及意义

将地震观测数据融合存储模型试应用于地震数据资源平台建设，现有数据总量约15.4 TB，其中，测震观测数据约6.0 TB，强震动数据约7.9 TB，地球物理场数据约1.5 TB。该集群的建设，提高了数据查询检索时效，方便了台站仪器的弹性增减；消除了地震学科间的数据烟囱，将所有地震数据集中存放，便于地震数据统一运维管理；弱化了学科概念，便于跨学科调度地震事件数据，便于地震数据的多维分析和深度挖掘，促进了协同、高效地开展地震业务工作，更好发挥地震业务工作的价值。将地震数据作为一种特殊的“资产”管理，形成以数据为中心的管理模式，促进并实现了数据的资产化、业务化管理和地震业务的数字化升级。

地震信息化是一个持续发展、与时俱进的学科。未来，在各信息化项目的支撑下，利用分布式、云计算、大数据等信息技术，将进一步整合和扩充国家地震中心的多元存储服务能力，满足地震数据处理和存储需要，建设全局全量的地震数据资源池。