Green Plum（简称GP）数据库是一种MPP架构的分布式数据库，为新一代数据分析所需的大规模数据和复杂查询功能所设计，在各行业中得到了广泛应用。在我行新一代架构P9平台数据仓库中，GP数据库有十分重要的地位。针对GP数据库在非功能测试当中遇到的问题，研究开发一种针对GP数据库的状态检查及性能监控工具具有十分重要的意义。
论文首先总结了导师制一年来的学习工作情况，阐述了自己经过各方面学习与完成测试任务后的心得体会。
第二章首先介绍了P9平台架构，简要介绍了P9平台中各个数据区的情况。其次介绍了GP数据库的架构与重要特点，这些特点使得GP数据库越来越广泛地应用在P9及其他平台中。
第三章是本文的重点，着重介绍了GP数据库的检查与监控方法。本章分操作系统与数据库两种级别来对GP数据库进行检查与监控。主要对针对GP数据库的操作系统命令与GP中的相关查询语句进行介绍与详细分析，为后文工具的实现提供理论依据。
第四章根据第三章所分析的相关命令语句，自行设计工具框架，实现了一种基于GP数据库的状态检查与性能监控工具，同时该工具可动态添加相关操作命令并可增加相关分析功能。
最后，本文对导师制阶段的学习工作与导师制结业工作进行总结和展望。
关键词：GreenPlum数据库 状态检查 性能监控
目 录
1 绪论 2
1.1 研究背景 2
1.2 研究意义 2
1.3 研究内容 3
1.4 导师制工作学习情况 4
1.5 论文结构 5
2 P9平台及GP数据库介绍 6
2.1 P9平台架构介绍 6
2.2 GP数据库介绍 8
2.2.1 GP数据库架构 8
2.2.2 GP数据库分析 9
2.2.3 GP的重要特点 10
3 GP数据库检查及监控方法 15
3.1 操作系统级别检查与监控方法 15
3.2 数据库级别检查与监控方法 17
3.3 结果简要分析 23
4 集成工具的设计与实现 25
4.1 集成工具框架及实现 25
4.1.1 集成工具框架 25
4.1.2 集成工具各模块的实现方法 25
4.1.3 集成工具的可扩展性 26
4.2 集成工具的使用方法 26
5 总结与展望 30
5.1 总结 30
5.2 展望 31
1绪论
1.1研究背景
当今大数据时代下，GreenPlum（简称GP）作为一种分析型数据库软件专门为新一代数据分析所需的大规模数据和复杂查询功能所设计，在各行业中得到了广泛应用。它源于PostgreSQL（开源关系数据库），因此与Oracle, DB2相似，可以通过标准的SQL对GP中的数据进行访问存取；同时，通过采用MPP（大规模并行处理）架构，GP提供大规模的并行处理能力，支持新一代企业级数据仓库和大规模数据处理，帮助客户查询、分析或整合企业数据。
GreenPlum数据库有以下3点优势：（1）用更低整体成本拥有数据仓库或集市。它的硬件采用X86开放架构，不依赖任何封闭式专有硬件，不需要过多的人工调整和优化，同时可以通过增加节点来实现低成本线性扩展。（2）使用面向OLAP数据仓库应用业界新技术。行/列存储方式适合于OLAP应用，大数据量频繁访问，性能提升40%以上。并行数据加载比串行加载速度提高40-50倍以上，减少ETL窗口时间。分布式并行计算可以大幅提高计算性能20倍以上，减少复杂计算分析的响应时间。（3）支持高可用性在线扩容。在线扩容期间，系统不需要宕机，所有用户访问和数据计算不受影响。在线扩容后，计算性能和数据容量呈线性增长。基于通用X86的低成本扩展，支持多代/隔代产品共存。
在新一代核心系统架构中，数据集成层P9是我行的数据仓库，P1到P8产生的数据都会输送到P9平台，P12在线交易数据服务平台从数据集成层实时获取数据满足在线交易，P10管理分析平台获取数据后完成报表、数据挖掘类等应用。所以在新一代核心系统架构中，P9平台具有十分重要的地位。P9平台中主要使用的数据库之一即为GP数据库，其中贴源数据区、公共访问区、实验数据区使用GP数据库，使用TeraData（TD）数据库的数据区主要有基础主题区、公共计算区、应用计算区，历史数据区使用Hadoop进行存储。
1.2研究意义
由于GP数据库适合批处理，TD数据库较适合大并发实时性高的操作，并且TD数据库成本较GP数据库成本高，所以未来P9平台中的TD数据库将会逐渐被GP数据库所取代。且GP数据库将会尝试应用在P9之外的平台上，比如管理分析类交易当中，应用将会越来越广泛。
目前在非功能测试实践中，针对GP数据库主要有以下四个问题：
（1） 相对于Oracle数据库，GP数据库的相关资料和研究稀少，搜集查阅不便，多数测试人员对GP数据库了解较少。
（2） GP数据库作为一个分布式数据库，一个集群的机器数量多达几十台至上百台，测试时需要监控的机器数量多；测试时需要配置和关注的参数多，包括系统参数、配置参数、连接参数、查询调优参数、统计信息收集参数、错误报告和日志参数、锁管理参数等；此外，监控点较ORACLE数据库更多，除sql语句执行时间、空间信息等之外，还需要关注网络性能、数据分布情况等；通过运行命令的方式在数目庞大的机器上进行大量信息的查询、配置、监控费时费力，降低测试工作效率，并且无法保证准确性。
（3） 针对效率差的作业，测试人员无法通过简单分析确定瓶颈点。
（4） 已有的GP性能监控工具比如Greenplum Performance Monitor Console可以进行图形化的展示，但需要安装greenplum-perfmon-web。在Greenplum 4.3最新的安装文件中并没有自带greenplum-perfmon-web的更新安装包。并且只能对cpu、内存、磁盘、网络、查询数量、查询时间等进行简单统计，针对在非功能测试当中起重要影响的相关参数无法进行监控与配置，对数据库的总体运行状态，表数据分布情况，空间信息，查询语句的执行计划等详细无法进行检查与监控。
针对以上在非功能测试当中遇到的问题，为保证测试质量，提高测试效率，需要对GP数据库进行非功能相关研究。同时由于针对GP数据库的研究相对于Oracle等数据库来说十分缺少，所以研究GP数据库，GP数据库的性能及其性能监控具有重要的意义。不仅能够加深对GP数据库的了解，还能够帮助非功能测试工作的顺利进行。
1.3研究内容
本文首先对GP数据库的架构和重要特点进行介绍，然后实现基于GP数据库的集参数配置监控、性能监控、对查询语句进行分析于一体的集成工具。该工具主要能够实现以下几项功能：
（1） 分操作系统与数据库两个级别来获取GP数据库的基本状态，包括运行状态，网络磁盘状态，数据库参数信息等静态信息。
（2） 获取GP数据库网络、磁盘、内存性能，表数据分布情况，资源队列以及参数，sql语句执行时间、执行计划等信息并对其进行简要分析。
后续还能在此基础上扩展相关功能，比如根据查询、性能等方面出现的问题，给出需要进行优化的参数，进行参数的自动调优。构建相应的规则库，直接找出执行效率差的sql语句，提高非功能测试的效率。对查询语句的执行计划进行分析，找出不合适的地方给出修改建议等。使该工具能够更好地辅助非功能测试。
在工作接近一年之际，回顾总结一年来在厦门开发中心轮岗学习工作和在2.2期非功能测试实施任务中学习到的非功能测试理论与非功能测试实施技能，不仅掌握了知识，而且学到了技能。结合在厦门开发中心轮岗中学习到我行企业级数据仓库P9平台的知识与数据线小组GP非功能测试任务，开发了一个基于GP数据库的状态检查、性能监控于一体的工具，论文主要分为以下三个部分：
（1）介绍P9平台架构，GP数据库的架构、重要特点等基本知识。
（2）着重描述了工具的实现方法与策略，分操作系统与数据库两个级别对GP数据进行检查与监控。包括对GP数据库总体状态进行检查的方法，对常用的GP数据库参数进行配置与监控的方法，对网络、表数据分布情况以及sql语句执行时间、空间信息、资源等信息进行监控的方法，获取查询语句执行计划方法等。
（3）开发了一个基于GP数据库的集总体状态检查，参数查询配置、性能监控、对查询语句进行分析于一体的集成工具。
1.4导师制工作学习情况
入职后经过总行中心的培训，迅速了解建行业务与我行新一代系统架构。通过企业级信息应用这个具体的非功能测试任务，对非功能测试的流程，方法有了详细的了解，学会在loadrunner中进行测试实施。
为了更好的进行非功能测试，先后在厦门开发中心企业级数据仓库项目与测试环境处进行轮岗。在企业级数据仓库项目，主要学习了P9架构，GreenPlum与TeraData两种分布式数据库，perl语言以及使用perl语言进行仓库各个区或者数据库之间的数据加载、卸载以及复制。主要产出物为数据仓库项目数据加载、卸载、全量复制、增量复制使用手册。通过开发轮岗，对开发过程中常见的困难以及由此对非功能测试所造成的影响有了深入地理解。
在测试环境处学习oracle、weblogic的基本知识以及安装，对非功能测试当中常用挂nas，扩表空间等基本操作进行实践，以及一些疑难问题的解决方法。这些解决方法之后确实用在了实际的非功能测试当中，提高了效率。
轮岗结束我便全身心地投入到了对公信贷流程项目的非功能测试工作当中。首先在老系统上进行脚本录制，参数化，规范化等实践。之后便近乎独立完成保理组件的组件组装测试。进行测试遇到了许多问题和困难，在同事的帮助与指导下，在不断碰壁和解决问题的过程中我掌握了许多测试方法和测试技巧。首先，在测试之前要深入理解业务本身逻辑，在测试过程中要特别注意各种日志级别、参数等细节问题，另外要对版本与数据质量加以控制，沟通要及时，职责要明确，最后在测试完成撰写报告时要力求严谨等等。上述积累的经验不但在随之而来的应用组装测试中发挥了作用，更为今后的非功能测试打下了坚实的基础。
组件组装结束后便投入到了应用组装测试中。相比组件组装测试，接触了非功能测试流程当中的几乎全部环节，首先是交易场景调研，测试环境检验，参数检查等工作，然后是在同事指导下从完全不懂到写出一份完整的测试方案与案例并进行非功能性能档案的录入，接下来便是绿灯测试，测试脚本与数据的准备，非功能测试实施，测试报告的编写等。
此外，我还参加了操作系统，GP &Hadoop，SAS&Cognos三个技术研究小组，积极参加处室组织的各项业务与技术培训。
通过一年的工作学习，对非功能测试有了全面的认识与理解。首先，非功能测试是一项需要十分细致的工作，任何有一个地方稍有差错即会功亏一篑。所以，只能在工作当中不断总结，不断学习，考虑周全，不忽略每一个可能出错的点。其次，非功能测试是一项对测试人员能力要求全面的工作，除了测试方法，还需要人员掌握操作系统，数据库，中间件等各项领域的知识。只有在工作当中不断地学习与积累才能做好非功能测试工作。
1.5论文结构
本论文共分为五章。
第一章，绪论。介绍论文的研究背景、研究意义、研究内容以及论文的组织结构。此外还对导师制一年的工作学习情况进行总结。
第二章，结合在厦门开发中心的轮岗学习工作，介绍我行新一代核心系统架构中P9平台，介绍P9平台中常用数据库GP数据库的架构、重要特点等。
第三章，结合非功能测试，分操作系统与数据库两个层面，着重阐述了常用的对GP数据库总体状态进行检查的方法，对常用的GP数据库参数进行配置与监控的方法，对网络、表数据分布情况以及sql语句执行时间、空间信息、资源等信息进行监控的方法，获取查询语句执行计划并进行分析的方法。
第四章，开发了一个基于GP数据库的集总体状态检查，参数查询、性能监控、对查询语句进行分析于一体的集成工具。同时该工具可动态添加相关操作命令并可增加相关分析功能。该集成工具具有良好的可扩展性。
第五章，总结与展望。本章对非功能测试以及本文研究内容进行总结与展望。
2P9平台及GP数据库介绍
在新一代核心系统架构中，数据集成层P9是我行的数据仓库，P1到P8产生的数据都会输送到P9平台，主要的交易系统数据由P6、P7、P8产生，以文件推送的方式，通过统一的信息交换组件将数据落地到P9的数据缓存层。对于非结构化数据除了批量导入的档案及影像文件数据外，还有通过API/WebService的方式进行逐笔导入。P12在线交易数据服务平台从数据集成层实时获取数据满足在线交易，P10管理分析平台获取数据后完成报表、数据挖掘类等应用。
2.1P9平台架构介绍
目前P9平台数据区的架构及其与P10，P12的关系如下图2-1所示。其中使用GreenPlum（GP）数据库的数据区主要有贴源数据区、公共访问区、实验数据区，使用TeraData（TD）数据库的数据区主要有基础主题区、公共计算区、应用计算区，历史数据区使用Hadoop进行存储。
图2-1 P9平台及与其它平台关系
从图中可以看出P9平台主要使用具有大规模并行处理（MPP）能力的数据库，包括GP和TD，以支持各数据区进行大规模的数据处理。GP与TD数据库的主要区别在于：GP数据库是有master节点的中心架构方式，TD数据库是无master节点的扁平架构方式。GP数据库适合批处理，不适合大并发实时性高的操作，而TD数据库较适合大并发实时性高的操作。
数据缓存区可以接收结构化和半结构化的数据，以文本文件的形式存储。数据缓存层的数据经过转码、标准化、技术清洗、简单加工过后，向贴源数据区，HDS历史数据区供数。
DW数据仓库包括以下5个数据分区。贴源数据区以数据拉链方式记录属性变化情况，提供半结构化数据转换为结构化数据、半结构化数据分析等功能。基础主题区完成企业级的基础数据整合计算，包括按基础主题模型重新组织数据、合并不同组件数据到同一实体中、将原有属性转换成一致性维度成员等加工。公共计算区与应用计算区通过数据认责进行区分，公共计算区完成公共指标和衍生数据的计算加工，应用计算区完成特定应用指标和衍生数据的加工处理。公共访问区涵盖基础数据、衍生数据等全部数据；支持非固定、低并发的用户对全部数据的访问；支持SAS，支持少数用户对全部数据的分析和挖掘。
实验数据区数据通常按月更新，使用样本数据，支持模型训练、压力测试。模型训练结果是模型及参数，由应用计算区负责对模型训练的结果进行加工。实验数据区目前所支持的应用有个金、财私、信用卡、电子银行、小企业、反洗钱、反欺诈、营运稽核。
P10应用访问区支持固定应用，如网点人员使用的固定格式报表，其特点是高并发、用户量多。支持大数据访问，半结构化数据转换成结构化数据后的分析和访问，其应用特点是低并发、数据量较大。此外，还有按分行设置专用的分行应用访问区。因为应用访问区不进行计算，不用进行大规模的并行处理，所以用oracle数据库作为P10应用访问区的数据库。
历史数据区分为数据归档区和原始数据访问区，存储架构为Hadoop。数据归档区进行组件、系统数据的归档和数据仓库归档，不进行计算。原始数据访问区根据数据查询的场景，将原始数据进行重组，提供对归档历史数据的访问。
GP数据库与TD数据库均为MPP架构类型的数据库，在三期中将把TD数据库替换为GP数据库。最终的数据架构如下图2-2所示。
图2-2 P9平台架构图
2.2GP数据库介绍
2.2.1GP数据库架构
GP的高性能得益于其良好的架构设计。GP的架构采用了MPP架构，本质上是一个关系型数据库集群的结构，分为三个部分：管理节点（Master节点）、计算节点（Segment节点）以及两者之间的高效互联技术GNET。对于GP来说，一个数据库实例实际上由多个独立的PostgreSQL实例组成，其中Master节点和Segment节点都是独立的PostgreSQL实例，它们分布在不同的物理主机上，协同工作，呈现给用户一个数据库DB的效果。下图2-3为GP的架构图：
图2-3 GP并行架构图
管理节点（Master节点）为GP数据库的访问入口，它主要负责与客户端应用的连接，生成并拆分出一个个执行计划，而后把执行计划分配给Segment节点处理，在Segment之间分配工作负载、整合Segment处理结果并向应用返回最终处理结果。
计算节点（Segment节点）负责存储用户的业务数据，并根据得到的执行计划，处理业务数据。当进行数据访问时，所有Segment节点并行处理与自己有关的数据，实现数据的并行处理。若需要其他节点数据，则可以通过互联技术GNET进行彼此的数据交互。
Master节点不存储任何用户数据，不负责运算，不会成为系统性能的瓶颈，用户仅能通过Master节点来访问整个系统；Segment节点负责真正的数据存储以及查询处理工作，Segment节点之间通过网络互连进行交互，不经过Master节点。
总的来说，GP的操作由Master接收、处理、优化、创建一个并行或定向的查询计划，分发到相关的实例去执行。大部分操作如扫表、关联、聚合、排序在实例上被并行执行，单行的insert，update，delete、select操作被定向到包含该DK列的实例。
2.2.2GP数据库分析
GP的集群与常见关系型数据库集群（如oracle RAC）不同，RAC采用shared everything架构来做集群，数据存储共享，节点间的内存可以相互访问；而GP采用的MPP架构是一种Shared Nothing架构，主机，操作系统，内存，存储都是自我控制的，不存在共享。
共享型的架构系统包括多个服务器，这些服务器与共享的存储设备相连。这种体系需要通过一个数据管道Interconnect将所有I/O信息过滤到共享磁盘子系统。从结构上来说，这种架构由于共享内存，因此节点间通信效率较高，适用于节点间通信比较频繁的OLTP联机查询类交易，在运行大量的小规模交易查询数据时效果较好。但由于共享造成占用资源较多，对于较大规模的事务处理性能较差。
图2-4 有共享与无共享架构对比
而在MPP系统中，每个节点都可以运行自己的操作系统、数据库等，不共享内存，节点之间的信息交互通过节点互联网络实现，如图3所示。这种架构由于不共享资源，各个节点服务器自身拥有的资源较多，因此MPP系统在处理大规模数据，比如决策支持和数据挖掘方面可以发挥资源优势，达到高效率的处理性能。同时，不共享结构也使得GP具备更好的扩展性，通过增加Segment节点服务器的数量，GP的性能会成线性增长。
