关于时序数据库:单日-5000-亿行-900G-数据接入TDengine-30-在中国地震台网中心的大型应用

2次阅读

共计 3126 个字符,预计需要花费 8 分钟才能阅读完成。

小 T 导读: 为满足地震预警数据存储、检索和解决的建设与集成需要,以及响应国家国产软件自主可控的号召,中国地震台网核心决定选用国产数据库 TDengine 来存储和解决地震波形数据。本文将针对 TDengine 3.0 在地震畛域的利用开展具体解说。

对于企业:
中国地震台网核心是作为中国地震局直属的公益一类事业单位,是我国防震减灾工作的业务枢纽和国际交流窗口,是地震监测预报预警、应急响应和信息化工作的国家级业务核心。

我的项目背景

近年,随着国家对防震减灾要求一直进步,我国先后施行了多个大型地震监测工程项目。随着地震台站密集建设,台站仪器采集汇入中国地震台网核心的地震波形数据也增长了一个数量级。

地震波形数据次要是指由国家地震台站、各省区域地震台网等地震观测网络系统中地震计采集并传回核心的数据,具备典型的时序数据特色,是发展地震监测预警、数据分析与开掘、地震异样研判等利用的根底资料。

为了满足地震预警数据存储、检索和解决的建设与集成需要,以及响应国家国产软件自主可控的号召,该我的项目选用国产数据库来存储和解决地震波形数据。

通过竞标,最终由 TDengine 承当该我的项目。

思考到运维部署老本性能等等各个方面,数据库须要做好如下方面:

  • 高效读写:承载每秒 500 万数据点的海量数据实时汇入,反对即席疾速查问。
  • 高数据压缩比:尽可能多的保留更多数据,同时缩小磁盘存储老本。
  • 时序剖析:基于工夫线的窗口化剖析函数或工具。
  • 弹性扩大:零碎可能反对程度扩大,随着业务规模逐年扩充,弹性扩容以反对更高的数据接入量。
  • 安全可靠:零碎可能保障多正本存储和高可用,保障在单点故障时不影响失常应用。
  • 冷热拆散:对于新采集的数据和历史数据有肯定归档能力,依照数据冷热水平拆散存储。
  • 能够对地震业余算法包集成:通过 UDF 形式,将地震业余信号处理算法集成至数据库中。

本文将以中国地震台网核心的我的项目作为主体开展(该我的项目用于全国范畴的地震数据监控剖析)。

业务架构

目前,该我的项目上应用的是 3.0.6.0 版本的 5 节点集群,单台服务器配置为:48CPU(s),192GB 内存,500GB SSD  + 1.2TB *6HDD 硬盘。

业务架构如下:

首先,每个地震仪个别会采集两个程度向,一个垂直向共三个通道(重量)的地触动数据,采样频率个别为 100HZ(10 毫秒采样一次)。数据包中的数据通过工具解析之后会先过渡写入 cencdb 这个 TDengine 库当中,写入 cencdb 的同时,TDengine 的订阅性能会取出该数据包,并再次进行解析,获取更多层次的数据写入 TDengine 集群当中。

站点的地位由其所属台网代码、台站代码和测点地位号码决定。地震仪每天不间断的继续采集地触动数据,并每隔 0.5 秒将数据打成 miniSEED 数据包传输,造成数据流。基于 TDengine“一个设施采集点一张表”的建模思路,每道数据流别离对应一张数据表和一张元数据表。

以后,该集群共有约 5.9 万张数据表,代表流入库中的 5.9 万道地震数据流。另外还有 5.9 万张元数据表(上图),存储 5.9 万道数据流中每个数据包的形容信息。

我的项目运行至今,TDengine 接入的原始数据包每天约 900GB,每秒大略接入超过 5 万个地震数据包,每天总数据量约 5000 亿条。

因为原始数据包已应用 STEM2 算法压缩,TDengine 压缩后的数据库文件与原数据包所占磁盘空间相当。对于惯例的 INT 类型数据,TDengine 压缩比可达到 5%-10% 之间,对于 VARCHAR 类型的数据,压缩比可达到 15-20%,极大水平地节约存储老本。

在集群日常负载上,单台数据库服务端 CPU 使用率 40%~50%,内存占用 14%~20%,运行安稳。

具体利用

在地震监测畛域,以下这些是比拟常见的需要:

1. 通过应用 SQL 查问“XJ_BKO_00_H_H_Z”表,就能够失去该地震仪器垂直重量的振幅数据。

2. 对地震数据包内的数据工夫,与理论入库工夫做差,能够统计到数据包入库的时延。因而,咱们对元数据表执行如下 SQL,就能失去超过 5 秒时延的异样数据用作进一步剖析。

3. 在地震数据中,地震波流传门路上会呈现多个不同的震相。地震学家能够对这些震相的达到工夫和振幅特色,对地震事件进行精确定位、震源机制剖析等工作。其中在地震信号中精确地辨认和捕获特定震相的行为,便是震相拾取。

咱们通过 TDengine 的 UDF(自定义函数)性能,把曾经训练好的 GPD 模型间接同 TDengine 的流计算 /SQL 联合起来,实现了震相拾取的实时计算。

建流语句:create stream gpd_stream trigger at_once into gpd_stream_stb as select ts, gpd(calc_ts, tbname,‘detail’) from detail.pick partition by tbname;

4. 同样是通过流计算,实现了实时计算上万个台站的每秒最大峰值,对流计算生成的表进行查问。

建流语句:create stream xxxxxxx into max_val_per_seconds_test subtable(concat(‘max_test_val_per_seconds-‘,tbname)) as select ts,max(data) as max_data from data where channel_3th=’Z’partition by tbname interval(1s) sliding(1s);

可视化

在地震监控畛域的可视化中,最重要的就是展现信息的完整性、实时性、可交互性,灵活性。
TDengine 高效的查问能力以及简略易用的 SQL 语句能够很不便的实现上述工作。 通过网页展现工具调用 TDengine 的 SQL,咱们实现了展现地震事件的主看板: 看板中的地图能够展现台站的每秒峰值记录,点击近期地震事件便能够进行一段时间(例如该地震产生时刻前 1min 和后 2min)内的地震数据回放。

另外, 因为 TDengine 能够和 Grafana 无缝对接,通过执行 SQL 即可实现数据可视化工作。 该我的项目应用 Grafana 实现了另一部分数据的监控。

该场景是按台网分组,统计最近 5 分钟内的台站可用率。

该场景是通过 SQL 查问某站台一段时间内的地震波原始数据,在 Grafana 中绘制出该时间段内该台站的地震波形图。

整体成果

此前,该我的项目通过程序进行基于 miniseed 文件的解决:简略来说是对 miniseed 数据依照日期、台站等维度进行分片,通过调用 python/C 程序加载 miniseed 文件做剖析解决。切换到 TDengine 之后,有很多变动:

  1. 不须要再保护繁多的 miniseed 文件,而是将他们解析成工夫序列数据,在 TDengine 中分表存储,节俭了使用者每次应用数据时解包的工夫。
  2. 通过简略的 SQL 实现了疾速的实时查问 / 展现 / 剖析,升高了数据展现和查问的应用难度。
  3. 零碎整体分布式扩大能力晋升,通过减少节点的操作便能够应答将来可能疾速减少的台站和数据。
  4. TDengine 时序数据库系统反对插件式业务函数集成,将成熟业务函数甚至机器学习训练模型以 UDF 形式内置到时序库零碎中,进行流式解决,不便翻新、扩大业务。

这些便是 TDengine 3.0 在地震畛域的利用,在气象、环境、交通等等很多其余畛域都会有相似的场景和需要。在人类社会的智能化倒退正处于一直演进迭代的过程中,TDengine 将会表演更多重要的角色。

注:文中所提及的 GPD 模型出自:https://github.com/interseismic/generalized-phase-detection

正文完
 0