AETA多分量地震监测系统的数据存储与安全系统

刘晨光，王新安，雍珊珊，徐伯星，张 丹，周康生

(1.北京大学深圳研究生院 集成微系统科学工程与应用重点实验室，广东 深圳 518055；2.武汉大学 计算机学院，湖北 武汉 430072)

0 引 言

地震是一种会给人类社会造成巨大经济损失的自然灾害。仅因地震导致的人员死亡数，就占全球各类自然灾害造成的死亡人数总数的54%[1]，堪称群灾之首。中国是世界上地震活动多发且受地震灾害最为严重的国家之一[2]。为解决地震监测预测的难题，北京大学深圳研究生院集成微系统实验室研制了AETA多分量地震监测系统，希望通过低成本、大区域、高密度的设备布设，建立完善的监测网络，捕捉比较一致的前兆异常信号，服务于地震预测。

AETA系统由地声传感探头[3-4]、电磁传感探头、数据处理终端[5]以及云端的应用服务器、数据存储中心及数据分析系统组成。目前该系统已在国内地震多发的川滇藏和京冀粤台等地区建立监测站点约200个 (见图1黑点标记)，云服务器将实时接收、处理海量监测数据并将其存储至数据库。由此带来的海量监测数据传输、存储和访问问题，将会给后台数据中心带来巨大压力。任何节点上的软硬件异常或人为失误，都可能导致实时数据入库失败或历史数据丢失，给整个AETA监测系统带来巨大的数据损失；在保证数据安全性的同时，数据中心还需要提供方便高效的数据访问接口，服务于后期的数据分析。因此，如何保证海量监测数据的完整性和安全性，是AETA多分量地震监测系统连续可靠运行的关键；一套高可用、高安全的监测数据存储方案，对AETA系统来说有着重大意义。

图1 多分量地震监测系统AETA站点分布

基于以上背景，文中介绍了当前AETA系统数据安全存储方案的设计和实现。该方案对系统中的原始数据和特征数据分别采用不同的存储和备份方式，涉及本地RAID存储、主从同步和分库分表等技术；同时数据访问中间件提供了统一的数据接口，向用户屏蔽了数据源内部结构和操作，提升了系统安全性。

1 AETA系统业务数据分析

1.1 系统数据流

在AETA多分量地震监测系统中，监测数据首先由传感探头采集，依次经数据处理终端和应用服务器处理，最终存入数据存储层。其数据流图如图2所示。

传感探头利用内部传感器和放大调理电路获取地震前兆信号，并通过TCP/IP协议将探头原始数据发送至数据采集终端。

探头原始数据在数据处理终端内首先进行窗口取样，每3 min数据取1 min数据存入Buffer；Buffer内数据又分为两路，一路经软件低通滤波后成为低频原始数据；另一路不进行滤波操作，直接成为全频原始数据。低频原始数据和全频数据都将通过HTTP协议发送至云端应用服务器。

图2 多分量地震监测系统AETA的数据流图

低频原始数据和全频原始数据，被应用服务器端校验接收后将再次分为两路，一路直接作为原始数据存入数据存储层，另一路经特定算法处理，提取出均值、振铃计数和峰值频率等特征值，并作为特征数据存入数据存储层。经上述分层处理后，传感器采集到的连续传感信号，将最终被划分为原始数据和特征数据，并计划存入数据存储层。原始数据和特征数据相关属性如表1所示。

特征数据均是经处理的十进制数值型特征值，数据量较小；原始数据是未经特征值提取处理的二进制采样数据，数据量较大，主要考虑原始数据的空间占用情况。原始数据单条记录占用60 K字节(除全频地声原始数据单条数据占用300 K字节)。所有信号分量均按照1条/3 min的频率采集入库。那么可以计算得到单台终端一天的原始数据将占用约230兆字节的空间。若考虑整个AETA地震监测网络，原始数据的空间占用将更加庞大。

表1 AETA系统中的信号类型

1.2 存储与安全的需求分析

AETA系统的数据存储层，承担着数据存储和安全访问的作用，是整个AETA系统中最重要的基础支撑。为保证该系统设计和实现的科学性和可靠性，需结合业务特点对数据存储层进行全方面的需求分析。

AETA系统数据存储与安全的需求点主要有：

(1)数据存储的可用性：按满足AETA系统中期1 000台设备、长期10 000台设备同时运行的目标，数据存储层需支持每日约230 GB，全年约84 TB规模数据的可控入库。所以数据存储服务的可用性成为关键。应首先保证服务高可用，不轻易宕机；其次大量终端的海量实时数据涌来时，数据存储层需保证对这些数据的可靠接收。

(2)数据存储的可靠性：数据存储进该层后，应保证存量数据可靠地保存在物理介质中，不易因人为操作或外来灾害而丢失数据。即使发生数据损失，也可以从备份中迅速恢复数据。该需求其实对数据备份和恢复机制的完善性提出了较高要求。

(3)数据访问的高效性：除了存数据，数据存储层的另一项重要职责是取数据。该层需保证向外取数据的接口便捷性和读取高效性。

(4)数据访问的安全性：向外提供数据访问时，数据存储层存在被不合法使用，造成数据泄露、更改或破坏的情况。目前对数据安全有较大威胁的攻击手段主要有SQL注入[6]、比特币勒索攻击等。

数据存储层设计时应考虑这些因素，设计适当机制以提升数据安全性。

2 数据存储方案设计

设计的数据存储方案如图3所示。应用服务器送来的特征数据和原始数据，首先在该数据存储层分开入库保存，然后通过备份和同步等机制，最后经数据接口向外提供数据访问服务。

图3 数据存储层架构

2.1 原始数据和特征数据的分开存储

经应用服务器处理后的原始数据和特征数据，因其数据特点和应用场景不同，在数据存储层中将被分别存储到硬盘的文件系统和关系型数据库MySQL。

原始数据是未经特征值提取处理的二进制采样数据，单台设备单天原始数据即达到230 M字节，空间占用较大；此外原始数据一般适用于细粒度的信号时域和频域分析，系统中使用频率较低。因此原始数据并不适合存储于传统的关系型数据库中，否则随数据量增大数据库将出现较大的读写瓶颈。

为解决海量原始数据的存储问题，参考了国家地震台网和美国地震学联合研究协会IRIS的处理办法[7]，不采用数据库，而采用了文件系统存储原始数据的方法。本设计将原始数据存储在Linux系统的文件系统(目录树)中，存储路径类似于/Date/StationID/DataChannel/TimeStamp.data，最底层DataChannel目录下将存储该终端某一分量一天内的全部480条数据记录(3分钟一条记录)，每个文件的文件名含该记录的准确时间戳。

特征数据是原始数据经算法处理后得到的数值型数据，分为均值、振铃计数和峰值频率等细分项目，可以有效体现前兆信号的时域或频域特征。特征数据的数据量很小，频繁用于波形绘制和数据分析，适合存储在MySQL数据库中。在MySQL建立四张特征数据表，分别用来存储低频电磁、全频电磁、低频地声、全频地声四大类特征数据，每张特征数据表中建立时间戳(Time)和站点号(StationID)的联合主键。

这种分离存储的好处是，既可以支撑特征数据的快速频繁访问，也可以保证原始数据的可控存取；同时也避免了大量原始数据存入数据库，给MySQL带来存储和访问上的隐患。

2.2 原始数据的RAID备份

任何一种物理存储介质都无法保证数据的绝对可靠，现实生活中种种因素如自然灾害、系统异常、人工操作失误或黑客入侵，都可能导致数据损失的发生。因此数据备份是保证数据可靠性的关键性机制。针对云端文件系统中存储的原始数据，设计了本地RAID配合热备盘的数据备份方案。

RAID的全称是redundant arrays of inexpensive disks，即容错廉价磁盘阵列，简称磁盘阵列，是由UCLA研究人员[8]于1988年提出的。其原理是将多块独立的物理硬盘通过阵列控制器，整合成虚拟的单台大容量硬盘，以提高硬盘的传输速率和容错能力。按照数据分布和冗余方式，可以将RAID大致划分为RAID0、RAID1、RAID3、RAID5、RAID10等不同等级，不同等级的RAID存储具有不同的存储特性和应用场景[9]。这里采用了兼具经济实用性和数据安全性的RAID5备份原始数据。

将N块(N≥3)容量为X的磁盘放入磁盘阵列柜，即可组建总容量为(N-1)*X的RAID5磁盘阵列；将磁盘阵列挂载至本地CentOS 6.5系统中，即可在操作系统中访问该RAID文件系统。本地备份环境搭建完成，如何自动获取云端原始数据并备份至磁盘阵列，是一个亟待解决的问题。设计了一套基于HTTP协议的C/S架构的原始数据备份工具。

原始数据备份工具是使用Java语言在MyEclipse平台开发的，由Server端和Client端组成。Client端在Linux系统中每日定时启动，通过HTTP协议向Server端发送近期原始数据的备份请求，Server端监听到备份请求后，将相应的数据通过HTTP协议返回Client端。Client端获得返回数据后，将文件存储至本地磁盘阵列，并将文件路径存入本地数据库作为文件索引。至此，该系统便完成了原始数据定期下载至RAID5的工作。

2.3 特征数据的复制与备份

MySQL中存储的特征数据，是前兆信号分析中频繁使用的数据，需要对这一部分结构化数据设计合理的备份方案。

首先MySQL中提供了内建的复制机制，可以实现从数据库Slave与主数据库Master的近实时数据同步。MySQL复制的基本原理是：Master将数据更改记录到二进制日志中，Slave不断追踪该二进制日志的DDL和DML事件，并将这些事件重做至Slave中，这样就实现了主库和从库数据的持续同步[10]。

该系统采用了一主一备的拓扑结构来实现MySQL复制，主库仅提供地震数据的实时入库功能，从库通过同步机制获取主库数据，并对外提供准实时的特征数据访问服务。该设计的好处在于，主库宕机后可快速切换至从库恢复服务，降低单点风险；还可将读操作全部指向从库，主库仅负责数据插入，即读写分离，可大大降低Master的访问压力；此外复制也可以作为一种数据库备份方式，一定程度上提升数据安全性。但是MYSQL复制不能代替备份，它对数据库误操作也无能为力，误操作也会同步至从库无法挽回。所以额外的数据库备份机制也是必需的。

MySQL数据库备份，按备份原理可分为逻辑备份和物理备份；按照备份策略可以分为全量备份、差异备份和增量备份[11]。该系统采用了长周期全量备份与短周期增量备份结合的策略，基于开源备份工具Percona XtraBackup每周进行两次全量的物理热备，并使用二进制日志binlog功能来进行增量备份。这种策略既保证了数据的安全性和高可恢复性，也避免了海量数据的备份对数据层正常业务的影响。

2.4 其他安全机制

除上述机制外，AETA地震监测系统的以下设计也对数据安全有重要意义。

(1)数据存储层的分区域水平分割：研究地震前兆信号时的一个重要因素是站点地理位置。按照地理位置的远近，将系统内台站划分成西南区域、华南区域或华北区域等不同片区，同一片区的台站数据统一存储至同一数据服务器，即将数据存储层分区域进行水平分割。这样设计的好处是，采用了一种类似分布式的架构存储地震监测数据，避免了单台数据库主机的读写压力，也提升了数据的灾备能力。

(2)应用层主机与存储层主机的分离：应用层主机提供数据接收处理服务，存储层主机提供关系型数据库等存储服务。将两层服务分别部署在不同主机上，保证了数据接收处理模块和数据存储模块的解耦，提升了系统架构的灵活性和安全性。

(3)基于云计算的基础设施：AETA多分量地震监测系统的线上服务均基于阿里云服务搭建，主要包括弹性计算服务ECS和关系型数据库服务RDS，具备弹性，高可靠，高可用的特点。此外，阿里云服务在态势感知、紧急预警、访问控制、防DDos攻击等安全运维领域有独特优势，提升了系统的数据安全性。

3 数据安全访问中间件设计

3.1 中间件的模块设计

AETA数据安全访问中间件主要涉及3个模块，数据访问平台、数据接口层和数据安全存储层，如图4所示。其中数据安全存储层即上一节所述的数据安全存储方案，所以这里将重点介绍数据访问平台和数据接口层。

数据访问平台是向用户提供的地震数据查看工具，包括WEB端网页和桌面客户端软件。WEB端网页可向外提供简单的特征和原始数据波形查看功能，也支持AETA系统的在线运维监控和管理功能；桌面客户端软件可提供更丰富的数据访问和展示功能，如数据波形查看、数据下载、异常标注、地震事件查看和地图服务等。

无论是WEB平台还是桌面客户端，都可划分为展示层和后台服务层两层。展示层向用户提供最直观的页面显示和操作界面，可按月周日等不同时间跨度绘制某一台站的数据波形，满足最基本的数据分析需求；后台服务层是数据访问平台的后端服务模块，负责从数据接口层获取配置信息和地震数据，并响应展示层的数据请求。后台服务层主要包括地址解析和配置信息缓存等模块。

图4 数据访问中间件的逻辑框图

数据接口层是数据访问平台和数据安全存储层的中间代理，避免了客户端与数据源的直接异地相连，向用户屏蔽了数据源的结构和操作。数据接口层由配置信息服务和地震数据服务两部分组成。

配置信息服务提供用户验证、权限查询和地震事件查询等接口，保证了数据访问平台的基础功能；更重要的是，配置信息服务还对外提供了地址解析接口，可以向数据访问平台提供待查询站点的数据服务接口，数据访问平台再访问该接口即可获取指定台站的地震数据，完成波形绘制工作。配置信息服务的底层是数据安全存储层的一系列配置表，主要存储了用户权限、地震事件、站点信息和站点对应数据接口等信息。

地震监测数据服务是数据安全存储层的对外数据接口，向用户提供统一的数据访问接口。该服务负责响应数据访问平台的数据请求，向后台数据安全存储层查取特征数据或原始数据，并将其返回给接口调用者。按区域不同该服务划分为不同接口，如华北数据接口、西南数据接口和华南数据接口等，分别对应于后台的数据安全存储层的分区域存储方案。

3.2 中间件的运行流程

在上一节模块设计的基础上，本节将讨论中间件处理数据查询请求的详细流程和原理。一个数据请求的全周期处理流程大致包括5个步骤，如图4所示。

(0)用户登录：用户使用本人账号和密码登录系统。登录认证通过后，数据访问平台将收到配置信息服务的地址解析信息，该信息将被缓存在用户端应用中(客户端或WEB端应用中)。

(1)本地地址解析：用户选定某一台站请求地震数据，用户端应用将在缓存中检索该台站数据服务接口，若命中则直接跳至第4步进行数据请求。若未命中(如缓存过期，未与台站数据进行及时同步)，则跳至第2步。

(2)发送地址解析请求：缓存未命中时，数据访问平台将向配置信息服务的地址解析接口请求准确的数据服务接口信息。

(3)获取数据接口信息：地址解析接口从数据安全存储层拉取最新数据，将数据服务接口信息在POST响应中以HTTP的访问URL字符串形式返回给用户端应用。

(4)发送地震数据查询请求：数据访问平台已获取到准确的数据接口信息，将向该接口发送POST请求查询某一台站某一时间范围内的地震数据。

(5)地震数据的返回和展示：地震数据接口从数据安全存储层获取指定数据后，向数据访问平台返回该数据。地震数据经前端渲染绘制成波形图，在用户展示层向用户显示出来。

以上步骤中，数据访问平台与配置信息服务和地震信息服务之间的交互，均基于事先定义好的交互协议。该交互协议定义，数据接口层作为WEB服务器监听HTTP请求，而用户端应用以POST请求形式，携带特定字段对该WEB服务器进行访问，以实现用户登录、地址解析或数据查询等任务。数据接口层处理好用户端请求后，也会以POST方式向用户端返回响应数据。

3.3 中间件的实现和上线

经前述框架设计后，中间件可进入方案实现阶段。这里将分数据展示端和服务端对其具体实现进行简要介绍。

数据展示端分为WEB端网页和桌面客户端。其中WEB端网页是基于B/S架构，使用Java语言在MyEclipse平台开发完成的，应用运行在Tomcat容器中，可对外提供简单的数据波形查看功能。桌面客户端软件是基于C/S架构，使用C++语言在QT平台开发完成的。该软件基于QT的信号与槽机制[12]提供了直观的桌面GUI，拥有更丰富的数据访问和展示功能。

服务端产品包括配置信息服务aeta_middleware_AR和地震数据服务aeta_middleware_DS。这两大服务均基于Spring框架的依赖注入机制，服务内所有对象均以bean的形式自动扫描并装配给相关应用。无论是前端的HTTP请求对象还是后端的数据库返回数据，均在Spring容器的管理下有机协调和运行，各层对象的调用完全面向接口，这样就实现了系统的松耦合和非侵入特性[13]。

客户端和服务端应用开发完成后，在AETA系统内进行上线部署。服务端aeta_middleware_AR和WEB网页可部署在同一Linux主机内，便于WEB应用在同一主机内获取快速的配置信息服务响应。用户端在浏览器中验证账号密码后，进入该应用的波形展示页面，在左侧导航栏中点选台站即可查看该台站的各数据分量波形。

数据服务aeta_middleware_DS在每一个分区域数据服务器中均有部署，每个aeta_middleware_DS均服务于后台某一分区域数据源，为该数据源提供统一的对外数据访问接口。在本地Windows系统内安装客户端，经验证通过用户同样可进入数据波形查看界面。用户点选某一台站时请求波形时，客户端和WEB端均完全按照图4流程，通过中间件获取波形数据并在前台展示。

4 结束语

文中设计并实现了一套应用于AETA系统的数据存储与安全访问解决方案，已经应用于当前AETA系统约200个站点，总计约5 TB规模数据量的业务系统内，稳定运行6个月，数据备份有序进行，未出现数据存储与安全事故。另外该系统在设计上考虑了更大规模数据量的情况，应对日后系统规模扩大具备良好的扩展性。数据按区域分布存储在不同数据服务器，完善的备份和恢复机制保证了数据安全性。同时中间件的存在，使得数据的分布式高效访问成为可能，数据的访问安全性也得到有效提升。