0 引言

2007年我国建成“十五”数字地震观测网络，中国地震台网中心作为该网络的数据汇集与存储中心，共汇集地下流体、地电、形变、重力、地磁5个学科的全国地球物理观测数据。“十五”地震前兆数据管理系统(以下简称“管理系统”)是全国地震地球物理观测网络的核心软件系统，其作用是将仪器采集的观测数据入库，通过各级节点逐级交换到国家中心，并提供给预报人员使用(周克昌等，2013)。运行十多年来，管理系统较为稳定，但也存在不少问题，如Oracle10g漏洞较多(绕过登录访问控制漏洞、远程Core RDBMS漏洞、Data Pump Metadata API SQL注入漏洞等)、数据库读写和统计性能较差、系统架构僵化、数据服务能力弱(不能灵活地按需求向外系统提供服务)等。随着信息技术的发展，分布式组件和时序数据库等软件技术已较为成熟。借助公共安全信息化工程(中国地震局)建设项目，中国地震台网中心开发了基于大数据架构和消息中间件技术的地球物理观测数据管理系统，并使用开源的ClickHouse时序数据库作为系统的数据存储底座，极大地提升了系统的读写性能，通过多副本技术保证了数据的安全性并提升数据库的可用性。

1 平台的技术构成 1.1 技术路线

(1) 平台采用IT业界成熟的前后端分离技术架构(叶小艳等，2018)，支持后端的微服务化弹性扩展。前端引入专用大数据绘图技术，交互层采用HTML、Less、Bootstrap实现视觉交互，采用Vue、JavaScript、Node.js实现业务逻辑和页面呈现，并调用平台服务接口进行业务处理。

(2) 采用高性能的大数据处理技术作为系统公共组件，满足地球物理观测数据管理系统海量数据接入和处理需求，包括支持高性能、并发实时数据处理的Pulsar和支持大规模时序数据存取的ClickHouse。使用MySQL作为基础数据和元数据管理数据库，使用SpringCloud作为微服务管理组件。实现按业务处理需求微服务化拆分，结合分布式调度的微服务处理框架，使数据处理能按使用场景弹性部署和扩容、缩容。基于容器云平台实现大数据处理流程快速、敏捷部署，增强可管控性。

(3) 基于API网关的数据交换技术。后端业务模块实现微服务拆分，基于微服务和API网关技术构建系统的统一API网关，用标准化的RESTFul服务实现数据的授权、交换、订阅，避免暴露后端微服务接口，增强服务安全性(Belqasmi et al，2011)。结合Pulsar消息中间件进行异步消息集成(梁国斌，2022)，将消息发布能力封装成RESTFul API，针对各个订阅端提供RESTFul API的导入数据接口服务，由代理组件来完成消息的订阅和分发。

(4) 数据服务开发。按照DevOps思想对数据服务进行开发和管理，实现数据服务按不同阶段需求和场景快速开发和迭代。基于Pulsar IO和Client，结合RESTFul API技术封装实时订阅数据服务。基于ClickHouse Client，结合SpringCoud技术封装离线数据查取服务。基于EChart等前后端技术定制数据展现交互服务。通过DevOps CICD套件实现数据服务的持续改进、新增和更替。

1.2 平台的技术架构

整体技术架构设计分为6层：数据汇集层、数据传输层、数据处理层、资源池层、数据服务层、前端交互层，如 图 1所示。数据汇集层主要使用HTTP和JDBC从仪器和Oracle数据库采集数据。数据传输层通过分布式消息中间件Pulsar实现消息传输。数据处理层主要使用Pulsar Function对进入到Pulsar的数据进行解析与封装(林琳，2021)。资源池层将实时数据存储在Pulsar中，非实时数据存储在ClickHouse中。数据服务层以Pulsar客户端、ClickHouse客户端、RESTFul API向外提供服务接口，以ECharts进行数据展现。前端交互层使用Vue和RESTFul等进行用户界面交互。

1.3 部署架构

系统的部署架构见 图 2，系统主要由MySQL集群、ClickHouse集群、消息中间件集群和应用集群组成。MySQL数据库有两个节点，互为备份。ClickHouse设计为两分片、两副本的存储方式，共有4个节点。消息中间件使用中国地震台网中心公用的Pulsar集群。应用节点使用Kubernetes创建3个实例以实现应用负载均衡。

1.4 系统功能架构

平台的主要功能有数据采集、数据同步、数据管理、数据查询、数据可视化等，软件功能结构见 图 3。数据采集包括仪器数据采集、仪器日志采集和工作日志、观测日志的填写维护等。数据同步包括Oracle历史数据和增量数据的同步及校验。数据管理包括基础信息维护、仪器停测与备案管理及节点管理等。数据查询包括观测数据、产品数据和日志类数据及设备运行指标的查询。数据可视化主要是数据到达情况、仪器故障情况和实时数据的可视化展示。

2 数据库设计 2.1 数据库选型

原地震前兆数据管理系统使用的Oracle10g数据库版本安全漏洞较多。且Oracle数据库没有针对时序数据进行优化，和时序数据库相比，读写性能相对较差。尽管前人提出各种优化方式来提升读写性能，总的来说仍是治标不治本(李井冈等，2008；刘坚等，2009；王建军等，2019)。在去除IOE和国产化的信息技术发展趋势下，使用采购方式升级Oracle数据库已不可行。随着时序数据库等新兴技术的出现，Oracle作为OLTP数据库的佼佼者在需要读取大量历史数据的地震分析预报服务的应用场景中还是显得较为吃力。项目实施与开发团队重点调研了ClickHouse、TDengine、DolphinDB、IOTDB等时序数据库，从性能、易用性、SQL支持程度等方面综合考虑，决定选用ClickHouse来存储地球物理观测数据及日志等。ClickHouse是一个开源、免费的联机分析处理(OLAP)数据库，相对于传统的联机事务处理(OLTP)数据库，如Oracle和MySQL，具有读写性能高、按列存储、使用预计算加速聚合函数查询、自带数据压缩、具有向量化引擎、可以在多个服务器上分布式处理等优点(朱凯，2020；李亚臣，2021)。

对于数据完整性和事务完整性要求较高的数据(如台站、仪器、场地等基础信息)仍然存储在关系数据库，由于这部分数据量不大，使用开源MySQL数据库即可满足需求。通过实际部署与测试，4款时序数据库的比较见 表 1。

2.2 数据库结构 2.2.1 基本设计思路 2.2.1.1 设计原则

为有效支撑地球物理观测数据管理系统的数据管理、数据汇集、数据交换、数据服务、系统监控等业务的稳定性和高效性，并保证系统的健壮性、可靠性和可扩展性，数据库设计采用以下原则。

(1) 表命名一致性原则

对流数据处理中间件Pulsar中主题的命名、地球物理观测数据管理系统中基础数据中表的命名及用于OLAP的ClickHouse数据库参考原管理系统的命名规则，按统一规则命名来保证管理系统部署、运行以及扩展的可靠及稳定性。

(2) 表结构一致性原则

为更好地支持对原地震前兆台网数据管理系统的数据迁移，原系统中的字典表、日志类型等业务表采用同样的表结构设计。

(3) 多库分工配合使用原则

利用流行、高效的数据管理、分析、处理、存储方式，结合业务要求采用不同的数据库工具配合使用，充分利用各数据库的特色及优势。流数据的发布与订阅采用Pulsar中间件，基础数据的管理采用MySQL关系型数据库，大量地球物理观测数据的统计分析、绘图使用ClickHouse数据库。

2.2.1.2 建表原则

数据库表包括观测数据表、日志表和基础信息表三大类。观测数据表存储在ClickHouse数据库。ClickHouse的表分为两种：本地表和分布式表。本地表存储在本地磁盘上，对其操作只影响本节点上的数据。分布式表可以理解为集群所有分片上的本地表的合并视图，对分布式表的操作会根据分片规则映射到相应的分片节点上，一般来说读写数据操作的都是分布式表。

原始和预处理数据表以测点(可以看作与仪器对等)为基本单位，按照数据类型和采样率再进行分表。为保证数据迁移后的精度，时序数据用Decimal类型保存。以中国地震局地质研究所白浮台(代码03002)测点3气象三要素观测仪原始分钟采样数据为例，本地表名为dys_03002_3_01_local，分布式表名为dys_03002_3_01，其中“dys”代表原始数据，“01”代表分钟采样率。

考虑到Oracle中有少数的学科产品数据表未采用标准的产品表数据结构，ClickHouse中的产品数据表继续保持原Oracle的表结构，以利于数据迁移和校对。日志表包括观测日志表和仪器运行日志表。日志表在Oracle中按测项建表，ClickHouse也沿用Oracle的表结构，将不同台站相同测项的日志条目放在一个表中。

2.2.1.3 逻辑设计

参考现有中国地震前兆台网数据管理系统的数据库总体设计结构(周克昌等，2012)，本系统内的表分为观测数据表、日志表和数据字典表等。观测数据表用于存放各类与时间相关的观测数据，日志表用于存放观测日志和仪器运行日志等，数据字典表用于存放描述观测数据属性的相关信息，表数量较多，相互关联、依赖关系复杂，数据库结构及各类表的实体-关系图见 图 4。

2.2.1.4 物理表分库规则

系统中核心的数据库存储组件为MySQL和ClickHouse数据库。MySQL作为关系型数据库，主要存储需要管理或修改维护的数据；ClickHouse主要用于存储和分析数据量较大的仪器采集数据和日志数据，各类型数据的分库情况见 表 2。

2.2.2 物理结构设计 2.2.2.1 系统基础数据(MySQL)

系统基础数据表指地球物理观测数据管理系统中用户管理、系统菜单、权限和角色等相关基础表。

其中，系统验证码表用于用户登陆时系统生成的验证码信息，表结构设计见 表 3。

系统日志表用于记录用户的登陆、退出及重要系统操作的日志，可按用户要求进行埋点并记录，表结构设计见 表 4。

菜单管理表用于管理系统菜单信息，表结构设计见 表 5。

角色与菜单对应关系表用于管理系统菜单及对应角色之间关联信息，表结构设计见 表 6。

系统用户表用于管理系统用户信息，表结构设计见 表 7。

用户与角色对应关系表用于管理系统用户及角色配置信息，表结构设计见 表 8。

系统用户Token表用于管理系统用户登陆系统的token信息，表结构设计见 表 9。

2.2.2.2 数据到达表(ClickHouse)

为记录每天的观测数据是否到达，便于进行统计，设计的数据到达表结构见 表 10。

2.2.2.3 原始数据(ClickHouse)

原始数据表的命名规则为：“dys_台站代码_测点编码_采样率代码”，其中“dys”代表原始数据。为节约表空间，在表名中包含了台站代码、测点编码、采样率代码等业务特征，表中只存储业务采集的时序观测数据。原始数据表结构设计见 表 11。

2.2.2.4 预处理数据(ClickHouse)

预处理数据包括人工预处理后的仪器数据以及预处理日志信息。人工预处理数据表结构与原始数据表结构相同，表结构设计见 表 11，表名设计为“dyu_台站代码_测点编码_采样率代码”。

2.2.2.5 产品数据与日志类数据(ClickHouse)

产品数据表与日志类数据表从Oracle复制过来后表结构保持不变，详细设计可参考相关文献(周克昌等，2012)。

2.2.2.6 业务基础信息(MySQL)

基础信息表的结构参考原中国地震前兆台网数据管理系统的表结构设计，通过采集工具将数据同步到MySQL数据库中，主要包括的表有仪器信息表、台站表、台站测点表、台站测项分量表、断层表、山洞表、地电场地表、地磁场地表、井信息表、泉信息表等。

2.3 数据情况

目前，原中国地震前兆台网数据管理系统中的Oracle数据已全部迁移到本系统中，包括基础信息、观测数据、工作日志、观测日志、数据跟踪分析记录等。其中基础信息和工作日志存储在MySQL数据库，观测数据、产品数据、观测日志等存储在ClickHouse数据库。共迁移9516个台站、14089套仪器、71个测项的历史数据到ClickHouse，数据的起止时间为1982-2023年。

ClickHouse数据库里的观测数据共有2.4亿条，按时序数据格式存储后，总数据条数1421202409017条，其中秒钟值记录1307164176000条，分钟值113334482880条，小时值662422296条，日值数据41327841条，总数据量为18.2TB，其中观测数据18TB，产品数据187GB，日志数据37GB，日增观测数据2.8GB。

3 业务功能

地球物理观测数据管理系统的主要业务功能包括地球物理台网的数据汇集、存储、管理、处理与服务等，并对历史数据进行清查、清洗、迁移等。系统整体业务流程见 图 5。

(1) 数据采集上报。台站业务管理员负责台站的仪器、测点等基础信息维护，以及仪器数据的采集和上报配置。

(2) 预处理。台站业务用户负责对采集获得的原始数据进行预处理，产生产品数据。

(3) 数据编目。国家中心业务管理员负责对采集、汇集、加工后的原始数据、产品数据、基础数据进行数据资源目录的编制和发布。

(4) 数据使用。各学科业务用户依据数据目录对数据进行查询、绘图、订阅，以及与外部系统进行共享与交换。

3.1 基础数据管理

基础数据管理主要是对台站、仪器、测点、观测场地(地磁场地信息、地磁观测磁标变迁信息、地电观测场地、地电观测测项、洞体信息、洞体测项信息、观测井信息、观测泉信息、井泉测项信息和断层信息)的增、删、改、查。基础数据如台站或仪器等，对其添加、修改操作需要经过上级业务部门的审核才可以生效。基础数据审核的流程图见 图 6，审核过程中记录日志信息，相关人员可查看审核过程状态信息。

3.2 观测数据采集

台站业务管理员通过系统的数据接入功能，配置地球物理台网各类观测设备的采集作业。系统根据配置好的采集作业，按照定时方式、命令请求方式、接收Socket推送方式，对原始观测数据、仪器日志和事件数据进行采集，检验数据合法性并且入库。仪器数据采集的流程见 图 7。

3.3 Oracle数据同步

从原地震前兆数据管理系统中的Oracle数据库同步历史数据到本系统(需要转换格式并校验数据正确性)，历史数据一次性同步后，定时同步Oracle增量数据。针对Oracle数据库的历史和增量数据进行评估、校验和清洗。

3.3.1 Oracle历史数据同步流程

Oracle历史数据同步流程见 图 8。国家中心业务管理人员通过采集调度应用配置Oracle数据同步作业。系统提供脚本模板，可以针对测点(仪器)方便地选择模板、初始化采集作业。

业务管理人员按日期指定时间段(也可一次性)，从Oracle数据库同步历史数据(整体约18TB)到本系统(需要转换格式并校验数据正确性)。采集调度应用针对Oracle数据库的历史数据进行评估、校验和清洗。

3.3.2 Oracle增量数据同步流程

Oracle增量数据同步流程见 图 9。系统根据配置好的采集作业，按天定时从Oracle数据库同步整天增量数据到本系统(需要转换格式并校验数据正确性)。针对Oracle数据库的增量数据进行评估、校验和清洗。

3.4 数据目录管理

国家中心业务管理人员通过数据目录管理功能，进行数据目录注册，为用户提供数据的汇集管理，用户可根据数据类型、标签、业务元数据等条件从数据池中检索出数据构成一个数据集，并可为数据目录建立层次关系。

国家中心业务管理人员可以进行数据目录发布，发布后的数据目录正式为用户提供服务。发布后管理员可以根据使用情况，随时停用、启用、刷新数据目录。基础信息与观测数据可以按学科、仪器、是否参与评比等进行灵活配置，实现数据的发布，或抓取数据源变化后，实现快速发布。数据目录管理流程见 图 10。

4 结论与讨论

地球物理观测数据管理系统将数亿条的Oracle异构数据(包括原始数据、预处理数据、产品均值数据、观测日志等)迁移到ClickHouse数据库，并实现地震分析预报软件MapSIS与地球物理观测数据管理系统的对接。目前已将时序数据库ClickHouse向地震预报用户开放了数据访问权限。此外，地球物理观测数据管理系统已经完成与一体化监控平台的对接，向其推送每日的汇集率、有效率、连续率等指标，提升了台网监控的准确性。系统于2023年10月通过应急管理部信息中心开展的第三方软件测评。本系统的技术特点有：

(1) 采用时序数据库存储观测数据，通过数据压缩提升存储效率和传输效率。采用分布式架构提升系统的性能和高可用性，可通过横向扩展来增加系统规模。使用Pulsar消息中间件进行数据的传递，提升传输稳定性的同时，减少系统组件之间的耦合。

(2) 针对地球物理分钟采样和秒采样数据读取和绘图困难的现状，该系统使用B/S架构，充分利用高性能时序数据库和数据传输二次压缩，可以实现千万级数据点的秒级绘图。

(3) 将地球物理台网管理功能集成在软件中，实现业务管理与数据管理的联动，提升管理的精确性和效率。初步实现B/S架构下的数据预处理功能，包括去突跳、去台阶、线性拟合、多项式拟合、去趋势等。

地球物理观测数据从Oracle迁移到ClickHouse后，大数据量场景下时序数据读取速度提升约5到10倍，占用磁盘空间仅为Oracle的三分之一；ClickHouse支持常用的表连接策略，连接性能与Oracle相当，且支持与MySQL数据库的跨库连接(王军等，2023)。

ClickHouse、Pulsar等大数据组件使用数据分片、多副本等技术进一步提升了系统稳定性和健壮性，通过服务的容器化和横向扩展节点可以更为便捷地提升服务能力，大数据容灾备份的服务模式基本杜绝了数据丢失的可能。

分布式微服务的仪器数据采集功能使仪器数据采集和交换更加轻量可靠，具备实时数据传输能力的仪器可以借助消息中间件将数据高效、可靠地实时传输至省和国家中心，进一步提升地球物理数据传输的时效性，为应急会商等应用提供更及时的数据支撑。

与原“十五”地震前兆数据管理系统相比，基于大数据架构的地球物理观测数据管理系统使用分布式集群和时序数据库，显著提升了系统性能，并且易于通过扩充节点来进一步增强处理性能。分布式系统提高了软件的可靠性，在单节点故障的情况下系统仍然可以正常运行。然而分布式系统的实现和维护比较复杂，系统的建设和运维成本较高。此外，分布式系统中的数据一致性是一个挑战，需要采用合适的算法和协议来确保数据的一致性。

由于建设时间紧迫，地球物理观测数据管理系统尚有许多功能需要继续开发或完善，这些功能包括：

(1) 国家中心和省中心两级数据交换

在前期工作基础上，地球物理观测数据管理系统未来需要完成国家中心与省中心的数据交换。主要内容包括：交换清单的配置、基础数据和观测数据交换等；实现国家中心、省中心、中心站、一般台站的四级业务流转，主要是台站变更、仪器接入、仪器停测等业务管理需要由下而上逐级审批与管理。

(2) 数据采集功能强化

需要在前期的基础上对数据采集功能进行完善，完善的内容包括：全网仪器采集，对目前全部在网进行的地球物理仪器类型实现全面覆盖，确保具备所有仪器的数据接入能力；实时数据采集方面，需要对全网仪器进行验证测试，确认各学科仪器对实时数据的支持程度，实现部分仪器实时状态数据的应采尽采；新型重力仪器采集，实现超导重力仪数据采集适配和转发；全网仪器日志采集，实现仪器工作日志、访问日志等日志信息采集。

(3) 市、县站数据融合功能

目前，各省中心由地方投资建设的地球物理观测仪器数量众多。自2020年起中国地震台网中心逐步开始收集全国市、县站数据，取得显著的效果。市、县站数据的技术系统与“十五”技术系统完全相同，但却完全独立于“十五”系统，从数据的应用和系统的运维角度来说极其不方便，因此，有必要将市、县站数据与“十五”系统进行整合：开发新系统支持市、县仪器接入，具备数据清查结果，与“十五”系统进行核对，解决台站、测点编码的冲突问题。对接入的市、县站仪器的历史数据和增量数据进行采集、处理与入库。

(4) 地球物理产品平台对接

地球物理台网现有地下流体、形变、重力、地电4个学科的产品服务平台，已经在全国推广应用。这些平台的数据都来源于原管理系统的Oracle数据库。未来从地下流体产品平台开始，将学科的产品平台连接到地球物理观测数据管理系统，实现学科产品端的升级改造。