【GreenPlum】GreenPlum服务来了！

今天的博文 向大家介绍下GreenPlum这个系统 ，因为GreenPlum太过于庞大，今天就先选择部分功能点来展开。

可能很多同学没听说过GreenPlum，没关系，PostgreSQL有没有听说过？呃，当我没说:(

这样，我们举个简单的例子：把PostgreSQL比作MySQL，把GreenPlum比作DDB（网易分布式数据库），这样应该有点feeling了吧？

事实上，确实如此，PostgreSQL是款伟大的数据库，而GreenPlum正建立在它的基础上，把许许多多的PostgreSQL节点组织在一起，实现了一个强大的分布式数据库。

1.系统结构

这是官方的highlevel_arch图，展示的是GreenPlum集群的结构：

集群包括两类角色：master和segment。

• master：中心节点，储存所有的元数据，包括database、schema、table等全局性的信息；SQL解析、优化、生成执行计划，把执行计划推送给右边的所有segment；监控segmemnt节点，管理它们主从切换；
• segment：计算和存储节点，可以理解为是一个独立的PostgreSQL数据库，执行master推送的执行计划，把执行结果返回给master，最终由master统一返回给应用。

外部应用（最左边的Client），和master进行SQL交互，但不会同segment直接交互！

2.容灾设计

这里，有同学可能会有高可用、高可靠方面的疑问，是的，GreenPlum已经有对应的保障机制：

• master：配置一个standby master温备节点，当主节点异常的时候，可以手工切换到standby master节点上；我们给它们配了一个VIP（virtual IP），通过keepalived实现了秒级的异常切换；
• segment：每个segment节点都有一个实时同步的备用节点，术语上主segment节点称为primary，备segment节点称为mirror节点，生产上我们选择了spread mirror模式（另外一种是group mirror，两机互备），可以提高容灾能力；segment的主从切换由master节点自动完成。

上面软件层的节点异常，发生主从切换后，异常节点都可以通过一定的运维操作进行恢复，甚至通过rebalance操作复原到发生异常前的状态，期间基本不影响正常业务。另外，硬件层的异常也是有可能发生的，比如硬盘坏掉、主机宕机等，这些都可以在软件层高可用功能的基础上进行恢复。

3.系统扩容

数据库在使用的过程中会随着数据量的增加而需要扩容，一般需要扩容的原因包括以下几方面：

• 历史数据量不断增加，磁盘剩余空间越来越少；
• 计算的数据量不断增加，计算性能跟不上，包括CPU或者磁盘IO限制；
• 网络传输量增加，网卡带宽限制；

GreenPlum数据库默认会采用Hash Distribution：

• 如果创建表时没有指定Distribution Key，则会选择Primary Key作为Distribution Key
• 如果Primary Key也不存在，就会选择表的第一列作为Distribution Key

和大多数的分布式系统一样，GreenPlum也支持垂直和水平两种扩容方式（对于表的数据partition分片方式，我们在这里就不介绍了，很容易和Distribution分布引起混淆）。BTW：在以前NCR系统中（redis），垂直扩容又被称为presharding模式。

垂直扩容

我们对前面“容灾设计”章节中的集群进行垂直扩容，可以看到总的segment节点数量没有发生变化，还是16个，但是新增加了4台物理机：Host7~Host10（上图浅蓝色），而这4台新机器上的segment节点，都是从原先左边的主机上迁移过来的，比如Host7上的primary2/mirror6来自于Host3，Host10上的primary8/mirror4来自于Host6等。

垂直扩容这种方式，是通过迁移和拷贝节点数据到新加的机器上，来达到扩容的目的，我们这里的例子中，迁移了整个系统一半的节点，拷贝了一半的数据。

水平扩容

这里我们假设同样增加了4台物理机，可以发现新增加的Host7~Host10上，每台新机器上的segment数量和原先左边的机器一样，都是4个。

水平扩容这种方式，会重分布整个集群的数据，需要重新计算整个集群中已有数据的分布键值，对集群的冲击较大，扩容的耗时随数据规模线性增加，通常较长，所以只能在业务空闲期才能操作。

4.资源管理

为什么要介绍下资源管理？因为作为共享型的服务，如果没有资源管理，一个业务的一个野蛮请求，就有可能把整个集群拖跨掉，影响其他正常用户，这个也是很多同学关心的话题。

GreenPlum在4.x之后的版本中，引入了资源队列的概念，通过把用户绑定到资源队列上，来限制用户活动的SQL个数，以及SQL的各种资源消耗的多少（大小）。

• 举个例子：我们创建了一个叫adhoc的资源队列，定义它的长度为4（即该队列只能并发4个SQL），它的内存资源为8GB（即该队列可以总共消耗8GB内存）。现在创建一个叫eyu的用户，把他绑定到这个资源队列上，当他向GreenPlum集群同时提交了7个SQL，但受制于资源队列，只能并发执行4个SQL，剩余3个得等待前面的执行完；同时，并发执行的4个SQL中，如果存在消耗大量内存资源的SQL，那么排在后面的SQL将不会并发执行，它们需要等待该SQL执行完，释放出内存才能继续执行。

通过这个例子，想必大家已经有了一个比较直观的感受了吧！

除此之外，资源队列还有一个任务优先级的属性，用来控制分配CPU的计算资源，高优先级资源队列里的SQL能分配得到更多的CPU，这个属性主要用来划分业务类型，这里不再展开讨论。

现在，我们上线的这个集群，因为用户还少，所以不会限制大家的资源，大家可以放心大胆的来体验：）

5.高级应用

大数据的同学，很多都是在Hadoop上玩，比如Hive、Druid、Impala等，今天，我们推出来的GreenPlum可以结合Hadoop一起玩！

GreenPlum通过外部表，可以非常方便地进行数据的导入导出，通过并行处理，性能非常高。这里解释下“外部表”：就是一张表的数据是指向数据库之外的数据文件的。在GreenPlum中，我们可以对一个外部表执行正常的DML操作，当读取数据的时候，就从数据文件中加载数据。

TEXT外部表

TEXT外部表支持多个文件格式，支持在segment上并发地高速从gpfdist导入数据，由于是直接从segment上导入，所以效率非常的高，这个在我们之前的基准测试报告里已经有提到。这个外部表，对于每天有大量数据导入任务的业务来讲，简直就是个大礼包！不再需要自己写导入工具了，甚至可以自己写shell脚本transform任意类型的数据！！还有，不要忘记也可以导出哦！！

HDFS外部表

GreenPlum可以直接读取HDFS文件，这样可以将GreenPlum和HDFS混合部署在一起，将GreenPlum作为一个计算节点，计算后的数据也可以直接写到HDFS中！（有没有感觉到什么？这就是酝酿中的Apache HAWQ）。

外部表，这部分其实在前面关于GreenPlum导数据的博文中已经有描述，大家可以看看那边。

GreenPlum MapReduce

哈哈，没错，GreenPlum也支持MapReduce！->_____-> 难道你还不心动？