分布式数据库Greenplum在地震前兆数据存储中的应用*

陈晓琳，李盛乐，刘 坚，刘珠妹

(中国地震局地震研究所 地震大地测量重点实验室，湖北 武汉 430071)

0 引言

地震前兆观测数据作为基础数据，在地震研究中具有广泛应用。为使地震研究人员更方便、广泛地获得全国范围内的地震前兆观测数据，中国地震台网中心联合中国地震局地震研究所开发了地震数据对内共享服务平台(谢有顺等，2017)。该平台汇集了800多个前兆观测台站、2 900多套前兆仪器的实时产出数据，学科预处理、专业处理的产品数据共计973 GB；主要采用B/S架构，用户直接通过浏览器访问位于服务器端的Oracle前兆共享数据库。在平台测试运行阶段，由于用户查询、下载数据量较大，Oracle数据库的查询、读取速度极大地制约了共享平台的访问性能。因此，为了解决该问题，需要研究地震前兆数据在大数据平台下的存储方案(刘坚等，2015)。在大数据环境下发展起来的新型分布式数据库Greenplum具有专为大规模查询、下载设计的并行处理架构(Bani，Girsang，2018)；并且拥有良好的线性扩展能力，能方便地增加系统的存储容量和处理能力，这些优势都较好地契合了前兆数据共享服务的存储需求。

由于Greenplum数据库的良好性能，在国内外大型企业中得到了广泛的关注。纽约证券交易所(NYSE)采用Greenplum数据库支持其海量数据的高速查询(Kauretal，2012)；国内最早开始使用Greenplum数据库的是阿里巴巴(中国)网络技术有限公司，其在2008年引入该技术，将原有的Oracle数据库迁移到Greenplum数据库上作为数据中心，进行产品关联分析(何勇，陈晓峰，2014)；银行等金融机构采用了Greenplum数据库分布式架构技术来支持其大批量数据的查询需求(张文升，2017)；移动通信运营商将Greenplum数据库作为数据仓库，利用分布式算法挖掘出隐藏在数据中的关联关系，从而帮助运营商对客户进行精准营销(余彪，2015)。但值得注意的是，以上应用均是定位于OLAP(联机分析处理，On-Line Analytical Processing)场景，这是由于Greenplum数据库的并行处理架构，更适合作为数据仓库使用。Greenplum数据库不能替代前兆业务的所有场景。传统Oracle数据库适合前兆业务前端OLTP(联机事务处理过程，On-Line Transaction Processing)场景，比如高频次的数据采集与交换的增删改操作；而Greenplum数据库中基于数据仓库的信息处理过程，更适合作为数据共享查询、下载服务的后端数据库。

本文根据前兆数据共享需求，制定了前兆数据在Greenplum数据库下的存储策略。基于地震行业网搭建了Greenplum分布式数据库环境，并从前兆数据读取性能、数据库可扩展性能、前兆应用软件兼容性等方面对Greenplum数据库与Oracle数据库进行了对比测试。

1 Greenplum数据库原理

目前，大数据存储或计算是热点问题，涌现了许多的大数据存储技术。而Greenplum数据库作为关系型数据库，更容易和目前使用的Oracle数据库进行对接、转换。另外Greenplum数据库完全支持SQL标准，支持ODBC和JDBC，从应用编程接口上讲，更利于原有的地震数据分析应用软件迁移到大数据平台。

1.1 分布式并行架构

Greenplum数据库采用了大规模并行处理架构(Massively Parallel Processing，以下简称MPP)，MPP是由2个或多个处理器构成的系统。每个处理器都有自己的内存、操作系统和磁盘，它们并行执行用户操作(陈达伦等，2016)。主节点Master是Greenplum数据库系统的入口点(图1)，是与客户端连接并提交SQL语句的数据库实例。

图1 Greenplum数据库集群架构

主节点Master将工作负载分发给其它数据库实例(Segment Instance)进行存储和处理数据。Interconnect(网络层)支持在不同的Segment实例(独立的PostgreSQL数据库)之间进行通信，并允许系统作为一个逻辑数据库运行。由于Greenplum数据库使用这种高性能的系统架构来分担数据仓库的负载，并可以并行使用系统的所有资源来处理用户任务。因此，Greenplum数据库在大数据量的查询、下载时表现出了优越的性能。

Greenplum数据库是基于PostgreSQL的数据库集群(Waas，2009)，它们共同工作以呈现单个数据库映像。大多数情况下，在SQL语句、特性、配置选项和最终用户功能方面，Greenplum数据库与PostgreSQL数据库非常相似，数据库用户与Greenplum数据库交互，就像与普通的PostgreSQL数据库交互一样。但是Greenplum数据库对PostgreSQL数据库的内部结构进行了修改或补充，以支持它的并行结构。例如，系统目录、优化器、查询器和事务管理器组件已经被修改和增强，以便能够让所有分布式PostgreSQL数据库同时并发执行。

1.2 数据分布与同步

由于Greenplum数据库的分布式架构，因此所有的表都会被切片成若干数据片存储在Segment上。分区策略可以为随机分布和Hash分布。随机分布中数据被随机分散到每个Segment，虽然这种分布方式可以保证数据被均匀分布到每个Segment，但是在进行表的关联操作时，需要根据关联键重分布数据，所以随机分布性能较差。Hash分布可以指定表的一列或者多列组合作为Hash Key来进行数据分布。Greenplum数据库会根据指定的Hash Key列来计算每一行数据对应的Hash值，并映射至相应的Segment实例。对于Greenplum数据库，如果用户创建表时未指定数据分布方式，则默认为Hash分布，并且将主键作为Hash Key，如果没有设置主键则选择第一列作为Hash Key。

为了避免单点故障，Greenplum数据库对主节点和各数据节点均采用备份策略。当主节点Master发生故障时，激活主节点备份Standby主机接管Master事务，它们之间通过流复制技术实现同步复制。如图1所示，主数据节点(Primary)和它的镜像(Mirror)是分配在不同的主机上，以防止某一数据节点故障导致数据库的访问异常。主节点和其数据镜像之间通过文件操作级来实现数据的同步(GISEarth，2016)。

2 前兆数据建库关键技术

2.1 集群环境搭建

在行业网内搭建Greenplum分布式数据库环境，初始化搭建时由1个主节点(Master)和3个数据节点(Segment Host)组成，节点间使用千兆网络连接，节点配置见表1。

表1 Greenplum数据库集群服务器参数

高可用性设计：主节点(Master)负责解析、分发SQL语句，收集、汇总查询数据等工作。因此必须保证主节点的高可用性，这里同时将Segment Host3机器设置为主节点的备份节点(Master Standby)。每个数据节点都配备镜像数据，当主数据节点发生故障时，Mirror节点会自动切换为Primary，不会对前台应用产生影响。

在线扩展：各类前兆观测台站800多个，前兆仪器2 900多套，各测项采样率逐渐提高，秒采样逐渐成为趋势。秒采样的数据量比分采样的数据量提高了60倍，并且后期设计要接入气象观测数据。当数据量日益增大，现有集群不能满足需求时，可以通过增加集群数量对Greenplum数据库进行线性扩展。扩展过程中，业务可以继续运行，不需要宕机。

2.2 存储分布策略

对于Greenplum数据库，影响SQL查询性能的最重要因素是数据分布是否均匀。如果数据在Segment分布不均匀，会导致短板效应，因此设计合适的存储分布策略至关重要。一般情况下，如果数据经常被高并发的键值或离散查询，将查询条件的列作为分布列，这样不需要连接到所有的Segment去查，可以大大提高并发能力。因此根据前兆数据共享需求，制定了如下存储规则：指定表的主键(台站编码、测点编码、测项编码、开始时间)作为分布键。

在Greenplum数据库中除了将数据分布到各Segment外，还要对各Segment上的数据进行分区，分布和分区共同决定数据的查询效率。分区是从逻辑上对同一个Segment上的表数据进行划分，这样可以优化查询性能，不会影响数据在各个Segment上的分布情况。目前Greenplum数据库支持LIST和RANGE两种分区类型。分区的目的是尽可能地缩小QUERY需要扫描的数据量，因此必须和查询条件相关联。鉴于此，本文以时间作为分区键，选择RANGE分区类型。

2.3 字段类型设计

Greenplum数据库的数据类型十分丰富，基本与Oracle数据库的一样，仅在少数数据类型上有区别(Rajputetal，2013)。在建设前兆Greenplum数据库时，参照“十五”前兆数据库(周克昌等，2010)中的常用数据类型选择了对应的数据类型，见表2。

表2 Greenplum数据库字段类型

3 性能测试与结果分析

为了更好地进行前兆共享数据库的选型，本文从数据查询、集群扩展等方面对Greenplum数据库进行了测试实验，并给出了测试结果。

3.1 数据读取性能测试

以QZ_312_DYS_02(地磁变化记录秒数据)表为例，对部署于相同网段的Oracle和Greenplum数据库进行数据读取速度测试。测试程序采用Java编写，利用JDBC驱动远程连接数据库。分别进行了小数据量和大数据量的查询测试，查询结果见表3。

表3 查询测试结果

从表3测试结果来看，对于小数据量的查询处理，Oracle和Greenplum数据库均可以在较短的时间内完成处理，用户等待时间差距不明显；而对于大批量数据的查询处理，Oracle数据库等待时间较长，Greenplum数据库则在很短的时间即可完成查询任务。显然，对于大批量数据的查询处理，Greenplum数据库明显优于Oracle数据库。这是由于Greenplum数据库将查询任务分布至各个数据节点进行并行处理，充分利用了各数据节点的CPU和IO能力，使数据分析处理能力得到提升。

3.2 可扩展性能测试

Greenplum数据库的重要特性是能在数据规模增大时便捷地进行线性扩展，通过增加节点数量高效提升数据库的性能。为此，本文在基础集群为4节点的基础上，逐步将集群增加至6，8节点，对数据库的扩展性进行了测试，结果见表4。

表4 不同节点集群上查询测试结果

测试结果显示，随着节点数的增加，Greenplum数据库的查询效率也随之提升。这种良好的横向扩展性可以支持数据库良好的成长，以应对不断增长的前兆观测数据。

3.3 应用兼容性测试

现有的前兆各学科各种数据处理软件基于Oracle数据库运行多年(王建军等，2019)，其主要数据库操作部分均为查询读取，较好地匹配了Greenplum数据库的数据读取优势。如果能将其后台数据库迁移至Greenplum数据库，将会极大地提升数据处理效率。而且本文所采用的Greenplum数据库完全支持SQL标准，支持ODBC和JDBC。因此只需修改这些软件的数据库接口部分的代码，便可以将底层数据库经由Oracle转换为Greenplum。以前兆数据处理中的周期分析和前兆数据共享网站为例，分别测试Greenplum数据库对SQL标准及ODBC和JDBC的支持。

表5 Greenplum数据库的ODBC及JDBC访问测试

4 结论

本文提出将分布式数据库Greenplum用于前兆数据共享服务，以满足大批量前兆数据的快速读取需求。通过在地震行业网内搭建分布式集群服务器，部署了基于Greenplum的前兆共享数据库。性能测试实验表明，与传统Oracle数据库相比，基于Greenplum的前兆共享数据库在大批量的数据查询处理上，具有显著的优势，并且Greenplum数据库架构具有良好的可扩展性，随着节点数的增加，查询效率能得到进一步提升。Greenplum数据库作为大数据环境下发展起来的数据库，增加了可编程并行分析挖掘功能，并提供广泛的语言支持，使得现有的前兆分析应用程序移植起来极为方便。因此，利用Greenplum数据库开展前兆数据库分析挖掘是下一步的研究方向。

测试环境搭建过程中，得到南京云创存储科技有限公司地震研发组成员马鸣、陈旭等的大力支持和热心帮助，在此表示感谢！