关于GreenPlum的一些整理

Greenplum数据库架构

  Greenplum数据库基本由PostgreSQL核心增强数据库实例组合并衔接成的数据库管理系统，即Greenplum数据在PostgreSQL基础上扩展开发，每个Greenplum数据库由1个master实例和2个或2个以上segment实例组成，客户端使用PostgreSQL规范与Master交互。以上的插图，展示Greenplum数据库实例由1个master和8 segement实例组成

        Master Host或Master实例就是GreenPlum数据服务端，服务端通过端口(默认端口5432)监听客户端连接。

        8个Segement部署在4个Segement Host，每个Segement Host是一台独立计算机含有操用系统、内存、CPU、存储、网络接口。与Master Host

类似，Segement Host也是独立计算机或虚拟机。
       每个Segement是数据库服务端分配并管理一部份数据存储，每个Segement在Segement Host采用独立端口监听。

       Master实例协调所有数据库实例、分布式请求Segement并且合并从Segement返回的结果。
Shared Nothing vs. Shared Disk

       GreenPlum数据库是Shared Nothing架构，因为每个Segement拥有自己的CPU、内存、硬盘来管理部份数据库。相反，基于共享磁盘的Shared Disk(或Shared Everything)架构的分布数据库管理系统拥有多个数据库服务实例管理单个数据库实例。Shared Nothing与Shared Disk架构有不同的优缺点。

    在磁盘共享系统中所有数据存储在本地数据库服务端，不需要通过网络发送数据到另一服务器执行连表查询；然而网络磁盘存储解决方案和软件

磁盘共享限制数据与数据库服务器数量添加到数据库集群。昂贵服务器和网络附属存储软件需要增加容量和保持可接受的查询响应时间。
    Shared Disk架构中, 每个CPU都有自己的内存, 但是所有CPU共享一组硬盘, 这些硬盘以SAN或者NAS的形式组织在一起。
    SD架构的缺点
       1. 连接CPU和硬盘驱动的连接会成为系统的瓶颈.
       2. 因为各个CPU都有自己的内存, 所以没有一个地方可以放置锁表(lock table)或者缓存池(buffer pool).

         为了设置锁, 只能在一个CPU上设置一个公共的锁管理器或者使用复杂的分布式锁协议. 当CPU数量增

         多 时, 上述两种两种方法的可扩展性都不是很好。
     Shared Nothing架构中, 每个CPU有自己的内存和硬盘. 数据按行被水平划分, 这样不同节点上存储的是不同行的数据. 每个节点只负责处理自己

硬盘上的数据. 每个节点有自己的锁表和缓存池, 这样就避免了复杂的分布式锁机制，SN的可扩展性非常好。

GreenPlum主要的功能和优势
SQL标准
通过SQL 2003 OLAP控制功能全面支持SQL-92和SQL-99。所有查询信息都并行地在整个系统上执行。

统一分析处理
可以在同一个并行数据流引擎上执行所有查询和分析（SQL、MapReduce、R等）操作，从而允许分析人员、开发人员和统计人员使用同一个基础构架进行数据分析。

可编程并行分析
为从事运算和统计工作的人员提供了更先进的并行分析功能，支持R、线性代数和机器学习功能。

数据库内压缩
采用了业内领先的压缩技术，提高性能的同时，显著地减少存储数据所需的空间。客户可以将所用空间减少3-10倍，并提高有效的I/O性能。

千万亿字节规模的数据加载操作
高性能的并行数据装载器可以在所有节点上同步执行操作，装载速度超过4.5TB/小时。

随地访问数据
不管数据的位置、格式或存储介质如何，都可以从数据库向外部数据源执行查询操作，并行向数据库返回数据。

动态扩展
帮助公司对数据仓库进行便捷的小规模或大规模扩展，同时避免高成本的设备或SMP服务器升级。

工作负载管理
允许管理人员创建基于角色的资源队列，以便划分资源和管理系统负载。

集中管理
提供集群级管理工具和资源，帮助管理人员像管理一台服务器一样管理整个Greenplum数据库平台。

性能监控
通过图形化的性能监控功能，用户可以确定当前运行的情况和历史查询信息，并跟踪系统使用情况和资源信息。

支持索引
Greenplum支持二叉搜索树、哈希、位图、GiST和GIN，从而能够实现多种索引功能，提供给数据架构师实施优化设计所必需的工具。

工业标准接口
支持标准数据库接口（SQL、ODBC、JDBC、DBI），并且可以与市场上先进的商务智能和抽取/转换/加载（ETL）工具互相操作。

关于GreenPlum的一些整理

这篇文章用来整理下gp的一些东西，不是概念搭建七七八八的东西，就是单纯的一些sql和使用。

1、gp是分布式的数据库，跟hadoop有点类似，也是有master和slave的架构关系

摘抄作者的话：Greenplum所有的并行任务都是在Segment数据节点上完成后，Master只负责生成和优化查询计划、派发任务、协调数据节点进行并行计算，Master上的资源消耗很少有超过20%情况发生，因为Segment才是计算和加载发生的场所（当然，在HA方面，Greenplum提供Standby Master机制进行保证）。

缺陷：他和hadoop一样不支持多并发，也就是说sql不多的时候，执行速度会很快，但是如果有多个sql一起运行，就会奇慢无比！

2、索引和压缩：

索引：GreenPlum是有索引的（但是实际上，我并没有多GP的索引有多少的测试），大概如下：

-1.如果是从超大结果集合中返回非常小的结果集（不超过5%），建议使用BTREE索引（非典型数据仓库操作）

-2.表记录的存储顺序最好与索引一致，可以进一步减少IO（好的index cluster）

-3.where条件中的列用or的方式进行join，可以考虑使用索引

-4.键值大量重复时，比较适合使用bitmap索引

压缩：其实压缩也是为了加快查询速度，概念如下：

-1.不需要对表进行更新和删除操作

-2.访问表的时候基本上是全表扫描，不需要建立索引

-3.不能经常对表添加字段或者修改字段类型

实际测试：

• 
  CREATE TABLE "数据库"."表" (
• 
  "字段1" varchar(20),
• 
  "字段2" int4,
• 
  "字段3" int8,
• 
  "字段4" numeric,
• 
  ....
• 
  )
• 
  WITH (APPENDONLY=true, COMPRESSLEVEL=1, ORIENTATION=column, COMPRESSTYPE=rle_type)
• 
  DISTRIBUTED randomly;
  

在我们的集群环境下，如下创建一张排名表，性能会比创建索引好很多（查询8s优化到1.5s），原因是因为服务器上磁盘IO经常跑满，但是cpu挺空闲的，所以把压力推到cpu让它去压缩和解压缩，缓解磁盘io的压力

3、分布键

个人觉得分布键是一个挺重要的东西，因为分布不均匀就会导致实现不了并行，从而影响查询的速度。

• 
  CREATE TABLE "数据库"."表" (
• 
  "字段1" varchar(50),
• 
  "字段2" varchar(500),
• 
  "字段3" varchar(500),
• 
  ....
• 
  "时间" timestamp(6) DEFAULT now()
• 
  )
• 
  distributed by(字段1,字段2)
• 
  ;
  

-1.distributed by(字段1, 字段2)

括号里面可以是一个字段，也可以是多个字段，一般来说都是通过用户id，设备mac，这种很随机的值来给定分布键。

如果在建表的时候不给定分布键，那么分布键就会是这张表的主键，或者是第一个字段。

也可以给定随机分布，把distributed by(字段1, 字段2)替换成DISTRIBUTED randomly

-2.修改分布键：alter table "数据库"."表名" set distributed randomly;

-3.查看分布情况：

select gp_segment_id,count(*) from "数据库"."表名" group by gp_segment_id;

-4.举个例子，如果你设置一个分布键叫做flag，然后这个字段只有两个值0和1，你有一个20台机器组成的GreenPlum，那这张表只会分布到两台机器上，在计算的时候，也只会动用这两台机器运算能力，其他18台在围观，所以分布键要合理分配！

4、层级关系

-1.数据库连接

-2.创建数据库

-3.创建模式（也叫schema）

-4.创建表

所以它多了一层叫做模式的东西，如下图：

5、关于sql

-1.窗口函数很好用！

row_number() over(partition by XXX order by XXX desc)

max() over(partition by XXX order by XXX)

avg() over(partition by XXX order by XXX)

....

-2.行列互转

• 
  --列转行（GP）
• 
  SELECT uid,String_agg(DISTINCT tag) as tag FROM (SELECT uid,tag FROM 数据库.表
• 
  WHERE create_time BETWEEN '20180601' AND '20180701') tagtb GROUP BY uid;
• 
  
• 
  --列转行（pg postgresql）
• 
  SELECT string_agg(name,',') from test;
• 
  
• 
  --行转列（pg postgresql）
• 
  SELECT regexp_split_to_table(name,',') from test;
• 
  
• 
  --行转列的去重(实际运用)
• 
  SELECT * FROM (SELECT
• 
  regexp_split_to_table(tag_name,',') as tag
• 
  FROM
• 
  表A )tb
• 
  WHERE
• 
  tag IS NOT NULL
• 
  GROUP BY
• 
  tag
• 
  ORDER BY
• 
  1 ASC;
• 
  
• 
  
  

使用的时候注意下，不同的sql行列互转的函数传参甚至名称可能不太一样，然后如果把列转成行最好要有个分隔符，方便后面的分词查询！

-3.update（b表计算出的某一个字段设置的想要更新字段的表中，通过uid来关联）

• 
  update 数据库.想要更新字段的表 tb set 想要更新的字段=b.另一张表的相同字段
• 
  from (SELECT uid,String_agg(DISTINCT tag) as tag
• 
  FROM (SELECT uid,tag FROM 数据库.另一张表 WHERE 条件) tagtb
• 
  GROUP BY uid) b
• 
  where  tb.uid=b.uid;
• 
  
• 
  
• 
  --1、更新表中前10条数据（更新为固定值）：
• 
  
• 
  update BranchAccount
• 
  set AccountNumber = '10010'
• 
  from (select top 10 *from BranchAccountorder by ID)as t1
• 
  where BranchAccount.ID = t1.ID
• 
  
• 
  
• 
  --2、用一个表的字段值更新另一个表的某字段值：
• 
  
• 
  update BranchAccount
• 
  set BranchAccount.AccountNumber = t1.AccountNumber
• 
  from TEMPBranchAccount as t1
• 
  where BranchAccount.ID = t1.ID
• 
  
• 
  
• 
  --3、更新表前10条数据（更新为另一个表的数据）：
• 
  
• 
  update BranchAccount
• 
  set BranchAccount.AccountNumber = t1.AccountNumber
• 
  from (select top 10 *from TEMPBranchAccount)as t1
• 
  where BranchAccount.ID = t1.ID
  

暂时写到这吧，感觉还没写完，如果以后想到什么再加进来吧，或者大家如果有什么想问的，可以给我留言！希望我能够帮上忙~

============================================================================

补充一：

记录几个关于日期的处理sql

• 
  --注：gmt_modified 这个字段是 default now()
• 
  --求当前5天的数据
• 
  select * from 库名.表明 WHERE gmt_modified >= (SELECT now() - interval '5 D')
• 
  
• 
  --第二段是这样的，表A和表C中对应天的数据计算结束之后，并且确定表B中没有计算当天的数据之后，就返回要计算的日期，主要想说的是可以通过这种方式给定日期的范围to_char((SELECT now() - interval '5 D'),'yyyyMMdd') ，date_id是int类型
• 
  
• 
  select *from (
• 
  select rc.date_id::VARCHAR as date_id,'${date_type}' as date_type from (
• 
  select date_id,status_flag from 表A where date_id>='${date_id}' and status_flag='Completed' ORDER BY date_id desc
• 
  limit 9999 ) rc
• 
  where not EXISTS (select date_id from 表B b where rc.date_id=b.date_id and rc.status_flag=b.status_flag)
• 
  and EXISTS (select date_id from 表C b where rc.date_id=b.date_id)
• 
  ) tb
• 
  where tb.date_id <=(to_char((SELECT now() - interval '5 D'),'yyyyMMdd'))
• 
  ORDER BY date_id;
• 
  
• 
  --第三段是求数据库中的最新日期的前几天
• 
  select count(1),gmt_modified,next_gmt_modified from (
• 
  select to_char(freshtime,'yyyyMMdd') as gmt_modified,(to_char(((select max(freshtime) from 表A) - interval '3 D'),'yyyyMMdd')) as next_gmt_modified from 表A
• 
  where freshtime is not null
• 
  ) tb
• 
  where gmt_modified >= next_gmt_modified
• 
  GROUP BY gmt_modified,next_gmt_modified ORDER BY 2 desc;
• 
  
• 
  --但是第三段有个缺点，缺点是gmt_modified更新时间一般来说不会做索引什么的，如果要求这个字段的最大值，很有可能查询速度奇慢无比，因此就需要用到其他方式来解决这个问题
• 
  --例如，如果该表有自增的主键id，那么我只要拿到id最大的那条数据的更新时间，就是最新的时间，而且实际运行，第三段sql在数据多的情况下，需要查询半小时。。。但是如下sql只需要不到1秒钟！！
• 
  select * from 表A where
• 
  freshtime >=
• 
  (
• 
  select next_gmt_modified::TIMESTAMP from (
• 
  select to_char(freshtime,'yyyyMMdd'),to_char((freshtime - interval '3 D'),'yyyyMMdd') as next_gmt_modified from 表A where 主键 in (select max(主键)from 表A )
• 
  ) tb )
  

补充二：

pg上的相关的元数据sql

• 
  --查询表占用空间大小
• 
  select pg_size_pretty(pg_relation_size('表名'));
• 
  
• 
  --查询某张表，在某个schema上是否存在
• 
  select * from pg_class where relname='表名'::name and relkind='r' ) a INNER JOIN
• 
  pg_namespace b on a.relnamespace = b.oid
• 
  WHERE nspname = 'schema名'
• 
  
• 
  --杀掉某个sql
• 
  select pg_terminate_backend(传入sqlid);
• 
  
• 
  --查询当前正在执行的sql情况（可做成视图）
• 
  SELECT (( 'select pg_cancel_backend(' :: TEXT || pg_stat_activity.procpid ) || ');' :: TEXT
• 
  ),
• 
  ( now() - pg_stat_activity.query_start ) AS cost_time,
• 
  pg_stat_activity.datid,
• 
  pg_stat_activity.datname,
• 
  pg_stat_activity.procpid,
• 
  pg_stat_activity.sess_id,
• 
  pg_stat_activity.usesysid,
• 
  pg_stat_activity.usename,
• 
  pg_stat_activity.current_query,
• 
  pg_stat_activity.waiting,
• 
  pg_stat_activity.query_start,
• 
  pg_stat_activity.backend_start,
• 
  pg_stat_activity.client_addr,
• 
  pg_stat_activity.client_port,
• 
  pg_stat_activity.application_name,
• 
  pg_stat_activity.xact_start,
• 
  pg_stat_activity.waiting_reason,
• 
  pg_stat_activity.rsgid,
• 
  pg_stat_activity.rsgname,
• 
  pg_stat_activity.rsgqueueduration
• 
  FROM
• 
  pg_stat_activity
• 
  WHERE
• 
  (
• 
  pg_stat_activity.current_query <> ALL ( ARRAY [ '<IDLE>' :: TEXT, '<insufficient privilege>' :: TEXT ] ))
• 
  ORDER BY
• 
  ( now() - pg_stat_activity.query_start ) DESC
  

如果想在数据仓库中快速查询结果，可以使用greenplum。

Greenplum数据库也简称GPDB。它拥有丰富的特性：

第一，完善的标准支持：GPDB完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展；从应用编程接口上讲，它支持ODBC和JDBC。完善的标准支持使得系统开发、维护和管理都大为方便。而现在的 NoSQL，NewSQL和Hadoop 对 SQL 的支持都不完善，不同的系统需要单独开发和管理，且移植性不好。

第二，支持分布式事务，支持ACID。保证数据的强一致性。

第三，做为分布式数据库，拥有良好的线性扩展能力。在国内外用户生产环境中，具有上百个物理节点的GPDB集群都有很多案例。

第四，GPDB是企业级数据库产品，全球有上千个集群在不同客户的生产环境运行。这些集群为全球很多大的金融、政府、物流、零售等公司的关键业务提供服务。

第五，GPDB是Greenplum（现在的Pivotal）公司十多年研发投入的结果。GPDB基于PostgreSQL 8.2，PostgreSQL 8.2有大约80万行源代码，而GPDB现在有130万行源码。相比PostgreSQL 8.2，增加了约50万行的源代码。

第六，Greenplum有很多合作伙伴，GPDB有完善的生态系统，可以与很多企业级产品集成，譬如SAS，cognos，Informatic，Tableau等；也可以很多种开源软件集成，譬如Pentaho,Talend 等。

greenplum起源

Greenplum最早是在10多年前（大约在2002年）出现的，基本上和Hadoop是同一时期（Hadoop 约是2004年前后，早期的Nutch可追溯到2002年）。当时的背景是：

• 互联网行业经过之前近10年的由慢到快的发展，累积了大量信息和数据，数据在爆发式增长，这些海量数据急需新的计算方式，需要一场计算方式的革命；
• 传统的主机计算模式在海量数据面前，除了造价昂贵外，在技术上也难于满足数据计算性能指标，传统主机的Scale-up模式遇到了瓶颈，SMP（对称多处理）架构难于扩展，并且在CPU计算和IO吞吐上不能满足海量数据的计算需求；
• 分布式存储和分布式计算理论刚刚被提出来，Google的两篇著名论文发表后引起业界的关注，一篇是关于GFS分布式文件系统，另外一篇是关于MapReduce 并行计算框架的理论，分布式计算模式在互联网行业特别是收索引擎和分词检索等方面获得了巨大成功。
  

下图就是GFS的架构

总体架构

greenplum的总体架构如下：

数据库由Master Severs和Segment Severs通过Interconnect互联组成。

Master主机负责：建立与客户端的连接和管理；SQL的解析并形成执行计划；执行计划向Segment的分发收集Segment的执行结果；Master不存储业务数据，只存储数据字典。  

Segment主机负责：业务数据的存储和存取；用户查询SQL的执行。

  greenplum使用mpp架构。

基本体系架构

master节点，可以做成高可用的架构

master node高可用，类似于hadoop的namenode和second namenode，实现主备的高可用。

segments节点

并行管理

对于数据的装载和性能监控。

并行备份和恢复。

数据访问流程，数据分布到不同颜色的节点上

查询流程分为查询创建和查询分发，计算后将结果返回。

对于存储，将存储的内容分布到各个结点上。

对于数据的分布，分为hash分布和随机分布两种。

均匀分布的情况：

总结

GPDB从开始设计的时候就被定义成数据仓库，如果是olap的应用，可以尝试使用GPDB。

聊聊Greenplum的那些事

https://dbaplus.cn/news-21-341-1.html

有时候真的感叹人生岁月匆匆，特别是当一个IT人沉浸于某个技术领域十来年后，蓦然回首，总有说不出的万千感慨。

笔者有幸从04年就开始从事大规模数据计算的相关工作，08年作为Greenplum 早期员工加入Greenplum团队（当时的工牌是“005”，哈哈），记得当时看了一眼Greenplum的架构（嗯，就是现在大家耳熟能详的那个好多个X86框框的图），就义无反顾地加入了，转眼之间，已经到了第8个年头。

在诸多项目中我亲历了Greenplum在国内的生根发芽到高速发展，再到现在拥有一百多个企业级用户的过程。也见证了Greenplum从早期的2.1版本到当前的4.37版本，许多NB功能的不断增强、系统稳定性的不断大幅提高，在Greenplum的发展壮大中，IT行业也发生着巨大的变化，业界潮流沿着开放、开源的方向走向了大数据和云计算时代。由此看出，Greenplum十来年的快速发展不是偶然发生的，这与其在技术路线上始终保持与整个IT行业的技术演进高度一致密不可分的。

多年历练中接触过大大小小几十个数据类项目，有些浅尝辄止（最短的不到一周甚至还有远程支持），有些周期以年来计（长期出差现场、生不如死），客观来说， 每个项目都有其独一无二的的特点，只要有心，你总能在这个项目上学到些什么或有所领悟。我觉得把这些整理一下，用随笔的方式写下来，除了自己备忘以外，也许会对大家更深入地去了解GP带来一些启发，也或许在某个技术点上是你目前遇到的问题，如乱码怎么加载？异构数据库如何迁移？集群间如何高速复制数据？如何用C API扩展实现高效备份恢复等。希望我的这篇文章能够给大家带来帮助，同时也希望大家多拍砖。

Greenplum的起源

Greenplum最早是在10多年前（大约在2002年）出现的，基本上和Hadoop是同一时期（Hadoop 约是2004年前后，早期的Nutch可追溯到2002年）。当时的背景是：

1

互联网行业经过之前近10年的由慢到快的发展，累积了大量信息和数据，数据在爆发式增长，这些海量数据急需新的计算方式，需要一场计算方式的革命；

2

传统的主机计算模式在海量数据面前，除了造价昂贵外，在技术上也难于满足数据计算性能指标，传统主机的Scale-up模式遇到了瓶颈，SMP（对称多处理）架构难于扩展，并且在CPU计算和IO吞吐上不能满足海量数据的计算需求；

3

分布式存储和分布式计算理论刚刚被提出来，Google的两篇著名论文发表后引起业界的关注，一篇是关于GFS分布式文件系统，另外一篇是关于MapReduce 并行计算框架的理论，分布式计算模式在互联网行业特别是收索引擎和分词检索等方面获得了巨大成功。

由此，业界认识到对于海量数据需要一种新的计算模式来支持，这种模式就是可以支持Scale-out横向扩展的分布式并行数据计算技术。

当时，开放的X86服务器技术已经能很好的支持商用，借助高速网络（当时是千兆以太网）组建的X86集群在整体上提供的计算能力已大幅高于传统SMP主机，并且成本很低，横向的扩展性还可带来系统良好的成长性。

问题来了，在X86集群上实现自动的并行计算，无论是后来的MapReduce计算框架还是MPP（海量并行处理）计算框架，最终还是需要软件来实现，Greenplum正是在这一背景下产生的，借助于分布式计算思想，Greenplum实现了基于数据库的分布式数据存储和并行计算（GoogleMapReduce实现的是基于文件的分布式数据存储和计算，我们过后会比较这两种方法的优劣性）。

话说当年Greenplum（当时还是一个Startup公司，创始人家门口有一棵青梅 ——greenplum，因此而得名）召集了十几位业界大咖（据说来自google、yahoo、ibm和TD），说干就干，花了1年多的时间完成最初的版本设计和开发，用软件实现了在开放X86平台上的分布式并行计算，不依赖于任何专有硬件，达到的性能却远远超过传统高昂的专有系统。

大家都知道Greenplum的数据库引擎层是基于著名的开源数据库Postgresql的（下面会分析为什么采用Postgresql，而不是mysql等等），但是Postgresql是单实例数据库，怎么能在多个X86服务器上运行多个实例且实现并行计算呢？为了这，Interconnnect大神器出现了。在那1年多的时间里，大拿们很大一部分精力都在不断的设计、优化、开发Interconnect这个核心软件组件。最终实现了对同一个集群中多个Postgresql实例的高效协同和并行计算，interconnect承载了并行查询计划生产和Dispatch分发（QD）、协调节点上QE执行器的并行工作、负责数据分布、Pipeline计算、镜像复制、健康探测等等诸多任务。

在Greenplum开源以前，据说一些厂商也有开发MPP数据库的打算，其中最难的部分就是在Interconnect上遇到了障碍，可见这项技术的关键性。

Greenplum为什么选择Postgreeql做轮子

说到这，也许有同学会问，为什么Greenplum 要基于Postgresql? 这个问题大致引申出两个问题：

1、为什么不从数据库底层进行重新设计研发？

道理比较简单，所谓术业有专攻，就像制造跑车的不会亲自生产车轮一样，我们只要专注在分布式技术中最核心的并行处理技术上面，协调我们下面的轮子跑的更快更稳才是我们的最终目标。而数据库底层组件就像车轮一样，经过几十年磨砺，数据库引擎技术已经非常成熟，大可不必去重新设计开发，而且把数据库底层交给其它专业化组织来开发（对应到Postgresql就是社区），还可充分利用到社区的源源不断的创新能力和资源，让产品保持持续旺盛的生命力。

这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单判断的标准就是看看底下那个轮子有多少人使用，有多少人为它贡献力量。

2、为什么是Postgresql而不是其它的？

我想大家可能主要想问为什么是Postgresql而不是Mysql（对不起，还有很多开源关系型数据库，但相比这两个主流开源库，但和这两个大牛比起来，实在不在一个起跑线上）。本文无意去从详细技术点上PK这两个数据库孰优孰劣（网上很多比较），我相信它们的存在都有各自的特点，它们都有成熟的开源社区做支持，有各自的庞大的fans群众基础。个人之见，Greenplum选择Postgressql有以下考虑：

1）Postgresql号称最先进的数据库（官方主页“The world’s most advanced open source database”）,且不管这是不是自我标榜，就从OLAP分析型方面来考察，以下几点Postgresql确实胜出一筹：

1

PG有非常强大 SQL 支持能力和非常丰富的统计函数和统计语法支持，除对ANSI SQL完全支持外，还支持比如分析函数（SQL2003 OLAP window函数），还可以用多种语言来写存储过程，对于Madlib、R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持，而Greenplum作为MPP数据分析平台，这些功能都是必不可少的。

2

Mysql查询优化器对于子查询、复制查询如多表关联、外关联的支持等较弱，特别是在关联时对于三大join技术：hash join、merge join、nestloop join的支持方面，Mysql只支持最后一种nestloop join（据说未来会支持hash join），而多个大表关联分析时hash join是必备的利器，缺少这些关键功能非常致命，将难于在OLAP领域充当大任。我们最近对基于MYSQL的某内存分布式数据库做对比测试时，发现其优点是OLTP非常快，TPS非常高（轻松搞定几十万），但一到复杂多表关联性能就立马下降，即使其具有内存计算的功能也无能为力，就其因估计还是受到mysql在这方面限制。

2）扩展性方面，Postgresql比mysql也要出色许多，Postgres天生就是为扩展而生的，你可以在PG中用Python、C、Perl、TCL、PLSQL等等语言来扩展功能，在后续章节中，我将展现这种扩展是如何的方便，另外，开发新的功能模块、新的数据类型、新的索引类型等等非常方便，只要按照API接口开发，无需对PG重新编译。PG中contrib目录下的各个第三方模块，在GP中的postgis空间数据库、R、Madlib、pgcrypto各类加密算法、gptext全文检索都是通过这种方式实现功能扩展的。

3）在诸如ACID事物处理、数据强一致性保证、数据类型支持、独特的MVCC带来高效数据更新能力等还有很多方面，Postgresql似乎在这些OLAP功能上都比mysql更甚一筹。

4）最后，Postgresql许可是仿照BSD许可模式的，没有被大公司控制，社区比较纯洁，版本和路线控制非常好，基于Postgresql可让用户拥有更多自主性。反观Mysql的社区现状和众多分支（如MariaDB），确实够乱的。

好吧，不再过多列举了，这些特点已经足够了，据说很多互联网公司采用Mysql来做OLTP的同时，却采用Postgresql来做内部的OLAP分析数据库，甚至对新的OLTP系统也直接采用Postgresql。

   

相比之下，Greenplum更强悍，把Postgresql作为实例（注：该实例非Oracle实例概念，这里指的是一个分布式子库）架构在Interconnect下，在Interconnect的指挥协调下，数十个甚至数千个Sub Postgresql数据库实例同时开展并行计算，而且，这些Postgresql之间采用share-nothing无共享架构，从而更将这种并行计算能力发挥到极致。

除此之外，MPP采用两阶段提交和全局事务管理机制来保证集群上分布式事务的一致性，Greenplum像Postgresql一样满足关系型数据库的包括ACID在内的所有特征。

从上图进而可以看到，Greenplum的最小并行单元不是节点层级，而是在实例层级，安装过Greenplum的同学应该都看到每个实例都有自己的postgresql目录结构，都有各自的一套Postgresql数据库守护进程（甚至可以通过UT模式进行单个实例的访问）。正因为如此，甚至一个运行在单节点上的GreenplumDB也是一个小型的并行计算架构，一般一个节点配置6~8个实例，相当于在一个节点上有6~8个Postgresql数据库同时并行工作，优势在于可以充分利用到每个节点的所有CPU和IO 能力。

Greenplum单个节点上运行能力比其它数据库也快很多，如果运行在多节点上，其提供性能几乎是线性的增长，这样一个集群提供的性能能够很轻易的达到传统数据库的数百倍甚至数千倍，所管理数据存储规模达到100TB~数PB，而你在硬件上的投入，仅仅是数台一般的X86服务器和普通的万兆交换机。

Greenplum采用Postgresl作为底层引擎，良好的兼容了Postgresql的功能，Postgresql中的功能模块和接口基本上99%都可以在Greenplum上使用，例如odbc、jdbc、oledb、perldbi、python psycopg2等，所以Greenplum与第三方工具、BI报表集成的时候非常容易；对于postgresql的contrib中的一些常用模块Greenplum提供了编译后的模块开箱即用，如oraface、postgis、pgcrypt等，对于其它模块，用户可以自行将contrib下的代码与Greenplum的include头文件编译后，将动态so库文件部署到所有节点就可进行测试使用了。有些模块还是非常好用的，例如oraface，基本上集成了Oracle常用的函数到Greenplum中，曾经在一次PoC测试中，用户提供的22条Oracle SQL语句，不做任何改动就能运行在Greenplum上。

最后特别提示，Greenplum绝不仅仅只是简单的等同于“Postgresql+interconnect并行调度+分布式事务两阶段提交”，Greenplum还研发了非常多的高级数据分析管理功能和企业级管理模块，这些功能都是Postgresql没有提供的：

   

• 外部表并行数据加载
• 可更新数据压缩表
• 行、列混合存储
• 数据表多级分区
• Bitmap索引
• Hadoop外部表
• Gptext全文检索
• 并行查询计划优化器和Orca优化器
• Primary/Mirror镜像保护机制
• 资源队列管理
• WEB/Brower监控
  
  

   

Greenplum的艺术，一切皆并行（Parallel Everything）

前面介绍了Greenplum的分布式并行计算架构，其中每个节点上所有Postgresql实例都是并行工作的，这种并行的Style贯穿了Greenplum功能设计的方方面面：外部表数据加载是并行的、查询计划执行是并行的、索引的建立和使用是并行的，统计信息收集是并行的、表关联（包括其中的重分布或广播及关联计算）是并行的，排序和分组聚合都是并行的，备份恢复也是并行的，甚而数据库启停和元数据检查等维护工具也按照并行方式来设计，得益于这种无所不在的并行，Greenplum在数据加载和数据计算中表现出强悍的性能，某行业客户深有体会:同样2TB左右的数据，在Greenplum中不到一个小时就加载完成了，而在用户传统数据仓库平台上耗时半天以上。

在该用户的生产环境中，1个数百亿表和2个10多亿条记录表的全表关联中（只有on关联条件，不带where过滤条件，其中一个10亿条的表计算中需要重分布），Greenplum仅耗时数分钟就完成了，当其它传统数据平台还在为千万级或亿级规模的表关联性能发愁时，Greenplum已经一骑绝尘，在百亿级规模以上表关联中展示出上佳的表现。

Greenplum建立在Share-nothing无共享架构上，让每一颗CPU和每一块磁盘IO都运转起来，无共享架构将这种并行处理发挥到极致。相比一些其它传统数据仓库的Sharedisk架构，后者最大瓶颈就是在IO吞吐上，在大规模数据处理时，IO无法及时feed数据给到CPU，CPU资源处于wait 空转状态，无法充分利用系统资源，导致SQL效率低下：

一台内置16块SAS盘的X86服务器，每秒的IO数据扫描性能约在2000MB/s左右，可以想象，20台这样的服务器构成的机群IO性能是40GB/s，这样超大的IO吞吐是传统的 Storage难以达到的。

(MPP Share-nothing架构实现超大IO吞吐能力)

另外，Greenplum还是建立在实例级别上的并行计算，可在一次SQL请求中利用到每个节点上的多个CPU CORE的计算能力，对X86的CPU超线程有很好的支持，提供更好的请求响应速度。在PoC中接触到其它一些国内外基于开放平台的MPP软件，大都是建立在节点级的并行，单个或少量的任务时无法充分利用资源，导致系统加载和SQL执行性能不高。

记忆较深的一次PoC公开测试中，有厂商要求在测试中关闭CPU超线程，估计和这个原因有关（因为没有办法利用到多个CPU core的计算能力，还不如关掉超线程以提高单core的能力），但即使是这样，在那个测试中，测试性能也大幅低于Greenplum（那个测试中，各厂商基于客户提供的完全相同的硬件环境，Greenplum是唯一一家完成所有测试的，特别在混合负载测试中，Greenplum的80并发耗时3个多小时就成功完成了，其它厂商大都没有完成此项测试，唯一完成的一家耗时40多小时）

前文提到，得益于Postgresql的良好扩展性（这里是extension，不是scalability），Greenplum 可以采用各种开发语言来扩展用户自定义函数（UDF）（我个人是Python和C的fans，后续章节与大家分享）。这些自定义函数部署到Greenplum后可用充分享受到实例级别的并行性能优势，我们强烈建议用户将库外的处理逻辑，部署到用MPP数据库的UDF这种In-Database的方式来处理，你将获得意想不到的性能和方便性；例如我们在某客户实现的数据转码、数据脱敏等，只需要简单的改写原有代码后部署到GP中，通过并行计算获得数十倍性能提高。

另外，GPTEXT（lucent全文检索）、Apache Madlib（开源挖掘算法）、SAS algorithm、R都是通过UDF方式实现在Greenplum集群中分布式部署，从而获得库内计算的并行能力。这里可以分享的是，SAS曾经做过测试，对1亿条记录做逻辑回归，采用一台小型机耗时约4个多小时，通过部署到Greenplum集群中，耗时不到2分钟就全部完成了。以GPEXT为例，下图展现了Solr全文检索在Greenplum中的并行化风格。

最后，也许有同学会有问题，Greenplum采用Master-slave架构，Master是否会成为瓶颈？完全不用担心，Greenplum所有的并行任务都是在Segment数据节点上完成后，Master只负责生成和优化查询计划、派发任务、协调数据节点进行并行计算。

按照我们在用户现场观察到的，Master上的资源消耗很少有超过20%情况发生，因为Segment才是计算和加载发生的场所（当然，在HA方面，Greenplum提供Standby Master机制进行保证）。

再进一步看，Master-Slave架构在业界的大数据分布式计算和云计算体系中被广泛应用，大家可以看到，现在主流分布式系统都是采用Master-Slave架构，包括：Hadoop FS、Hbase、MapReduce、Storm、Mesos……无一例外都是Master-Slave架构。相反，采用Multiple Active Master 的软件系统，需要消耗更多资源和机制来保证元数据一致性和全局事务一致性，特别是在节点规模较多时，将导致性能下降，严重时可能导致多Master之间的脑裂引发严重系统故障。

Greenplum不能做什么？

Greenplum最大的特点总结就一句话：基于低成本的开放平台基础上提供强大的并行数据计算性能和海量数据管理能力。这个能力主要指的是并行计算能力，是对大任务、复杂任务的快速高效计算，但如果你指望MPP并行数据库能够像OLTP数据库一样，在极短的时间处理大量的并发小任务，这个并非MPP数据库所长。请牢记，并行和并发是两个完全不同的概念，MPP数据库是为了解决大问题而设计的并行计算技术，而不是大量的小问题的高并发请求。

再通俗点说，Greenplum主要定位在OLAP领域，利用Greenplum MPP数据库做大数据计算或分析平台非常适合，例如:数据仓库系统、ODS系统、ACRM系统、历史数据管理系统、电信流量分析系统、移动信令分析系统、SANDBOX自助分析沙箱、数据集市等等。

而MPP数据库都不擅长做OLTP交易系统，所谓交易系统，就是高频的交易型小规模数据插入、修改、删除，每次事务处理的数据量不大，但每秒钟都会发生几十次甚至几百次以上交易型事务 ，这类系统的衡量指标是TPS，适用的系统是OLTP数据库或类似Gemfire的内存数据库。

Greenplum MPP 与 Hadoop

MPP和Hadoop都是为了解决大规模数据的并行计算而出现的技术，两种技术的相似点在于：

   

• 分布式存储数据在多个节点服务器上
• 采用分布式并行计算框架
• 支持横向扩展来提高整体的计算能力和存储容量
• 都支持X86开放集群架构
  
  

但两种技术在数据存储和计算方法上，也存在很多显而易见的差异：

   

• MPP按照关系数据库行列表方式存储数据（有模式），Hadoop按照文件切片方式分布式存储（无模式）
• 两者采用的数据分布机制不同，MPP采用Hash分布，计算节点和存储紧密耦合，数据分布粒度在记录级的更小粒度（一般在1k以下）；Hadoop FS按照文件切块后随机分配，节点和数据无耦合，数据分布粒度在文件块级（缺省64MB）。
• MPP采用SQL并行查询计划，Hadoop采用Mapreduce框架
  
  

   

基于以上不同，体现在效率、功能等特性方面也大不相同：

1.计算效率比较：

先说说Mapreduce技术，Mapreduce相比而言是一种较为蛮力计算方式（业内曾经甚至有声音质疑MapReduce是反潮流的），数据处理过程分成Map-〉Shuffle-〉Reduce的过程，相比MPP 数据库并行计算而言，Mapreduce的数据在计算前未经整理和组织（只是做了简单数据分块，数据无模式），而MPP预先会把数据有效的组织（有模式），例如：行列表关系、Hash分布、索引、分区、列存储等、统计信息收集等，这就决定了在计算过程中效率大为不同：

1

MAP效率对比：

• Hadoop的MAP阶段需要对数据的再解析，而MPP数据库直接取行列表，效率高
• Hadoop按照64MB分拆文件，而且数据不能保证在所有节点均匀分布，因此MAP过程的并行化程度低；MPP数据库按照数据记录拆分和Hash分布，粒度更细，数据分布在所有节点中非常均匀，并行化程度很高
• Hadoop HDFS没有灵活的索引、分区、列存储等技术支持，而MPP通常利用这些技术大幅提高数据的检索效率；
  
  

2

Shuffle效率对比：（Hadoop  Shuffle 对比MPP计算中的重分布）

• 由于Hadoop数据与节点的无关性，因此Shuffle是基本避免不了的；而MPP数据库对于相同Hash分布数据不需要重分布，节省大量网络和CPU消耗；
• Mapreduce没有统计信息，不能做基于cost-base的优化；MPP数据库利用统计信息可以很好的进行并行计算优化，例如，对于不同分布的数据，可以在计算中基于Cost动态的决定最优执行路径，如采用重分布还是小表广播
  
  

3

Reduce效率对比：（对比于MPP数据库的SQL执行器-executor）

• Mapreduce缺乏灵活的Join技术支持，MPP数据库可以基于COST来自动选择Hash join、Merger join和Nestloop join，甚至可以在Hash join通过COST选择小表做Hash，在Nestloop Join中选择index提高join性能等等；
• MPP数据库对于Aggregation（聚合）提供Multiple-agg、Group-agg、sort-agg等多种技术来提供计算性能，Mapreuce需要开发人员自己实现；
  
  

4

另外，Mapreduce在整个MAP->Shuffle->Reduce过程中通过文件来交换数据，效率很低，MapReduce要求每个步骤间的数据都要序列化到磁盘，这意味着MapReduce作业的I/O成本很高，导致交互分析和迭代算法开销很大，MPP数据库采用Pipline方式在内存数据流中处理数据，效率比文件方式高很多；

总结以上几点，MPP数据库在计算并行度、计算算法上比Hadoop更加SMART，效率更高；在客户现场的测试对比中，Mapreduce对于单表的计算尚可，但对于复杂查询，如多表关联等，性能很差，性能甚至只有MPP数据库的几十分之一甚至几百分之一，下图是基于MapReduce的Hive和Greenplum MPP在TPCH 22个SQL测试性能比较：（相同硬件环境下）

还有，某国内知名电商在其数据分析平台做过验证，同样硬件条件下，MPP数据库比Hadoop性能快12倍以上。

2.功能上的对比

MPP数据库采用SQL作为主要交互式语言，SQL语言简单易学，具有很强数据操纵能力和过程语言的流程控制能力，SQL语言是专门为统计和数据分析开发的语言，各种功能和函数琳琅满目，SQL语言不仅适合开发人员，也适用于分析业务人员，大幅简化了数据的操作和交互过程。

而对MapReduce编程明显是困难的，在原生的Mapreduce开发框架基础上的开发，需要技术人员谙熟于JAVA开发和并行原理，不仅业务分析人员无法使用，甚至技术人员也难以学习和操控。为了解决易用性的问题，近年来SQL-0N-HADOOP技术大量涌现出来，几乎成为当前Hadoop开发使用的一个技术热点趋势。

这些技术包括：Hive、Pivotal HAWQ、Spark SQL、Impala、Prest、Drill、Tajo等等很多，这些技术有些是在Mapreduce上做了优化，例如Spark采用内存中的Mapreduce技术，号称性能比基于文件的的Mapreduce提高10倍；有的则采用C/C++语言替代Java语言重构Hadoop和Mapreuce（如MapR公司及国内某知名电商的大数据平台）；而有些则直接绕开了Mapreduce另起炉灶，如Impala、hawq采用借鉴MPP计算思想来做查询优化和内存数据Pipeline计算，以此来提高性能。

虽然SQL-On-Hadoop比原始的Mapreduce虽然在易用上有所提高，但在SQL成熟度和关系分析上目前还与MPP数据库有较大差距：

   

• 上述系统，除了HAWQ外，对SQL的支持都非常有限，特别是分析型复杂SQL，如SQL 2003 OLAP WINDOW函数，几乎都不支持，以TPC-DS测试（用于评测决策支持系统（大数据或数据仓库）的标准SQL测试集,99个SQL）为例，包括SPARK、Impala、Hive只支持其中1/3左右；
  
  

• 由于HADOOP 本身Append-only特性，SQL-On-Hadoop大多不支持数据局部更新和删除功能(update/delete)；而有些，例如Spark计算时，需要预先将数据装载到DataFrames模型中；
  
  

• 基本上都缺少索引和存储过程等等特征
  
  

• 除HAWQ外，大多对于ODBC/JDBC/DBI/OLEDB/.NET接口的支持有限，与主流第三方BI报表工具兼容性不如MPP数据库
  
  

• SQL-ON-HADOOP不擅长于交互式（interactive）的Ad-hoc查询，多通过预关联的方式来规避这个问题；另外，在并发处理方面能力较弱，高并发场景下，需要控制计算请求的并发度，避免资源过载导致的稳定性问题和性能下降问题；
  
  

3.架构灵活性对比：

前文提到，为保证数据的高性能计算，MPP数据库节点和数据之间是紧耦合的，相反，Hadoop的节点和数据是没有耦合关系的。这就决定了Hadoop的架构更加灵活-存储节点和计算节点的无关性，这体现在以下2个方面：

1

扩展性方面

• Hadoop架构支持单独增加数据节点或计算节点，依托于Hadoop的SQL-ON-HADOOP系统，例如HAWQ、SPARK均可单独增加计算层的节点或数据层的HDFS存储节点，HDFS数据存储对计算层来说是透明的；
• MPP数据库扩展时，一般情况下是计算节点和数据节点一起增加的，在增加节点后，需要对数据做重分布才能保证数据与节点的紧耦合（重新hash数据），进而保证系统的性能；Hadoop在增加存储层节点后，虽然也需要Rebalance数据，但相较MPP而言，不是那么紧迫。
  
  

2

节点退服方面

• Hadoop节点宕机退服，对系统的影响较小，并且系统会自动将数据在其它节点扩充到3份；MPP数据库节点宕机时，系统的性能损耗大于Hadoop节点。
  
  

Pivotal将GPDB 的MPP技术与Hadoop分布式存储技术结合，推出了HAWQ高级数据分析软件系统，实现了Hadoop上的SQL-on-HADOOP，与其它的SQL-on-HADOOP系统不同，HAWQ支持完全的SQL语法 和SQL 2003 OLAP 语法及Cost-Base的算法优化，让用户就像使用关系型数据库一样使用Hadoop。底层存储采用HDFS，HAWQ实现了计算节点和HDFS数据节点的解耦，采用MR2.0的YARN来进行资源调度，同时具有Hadoop的灵活伸缩的架构特性和MPP的高效能计算能力.

当然，有得也有所失，HAWQ的架构比Greenplum MPP数据库灵活，在获得架构优越性的同时，其性能比Greenplum MPP数据库要低一倍左右，但得益于MPP算法的红利，HAWQ性能仍大幅高于其它的基于MapReduce的SQL-on-HADOOP系统。

4.选择MPP还是Hadoop

总结一下，Hadoop MapReduce和SQL-on-HADOOP技术目前都还不够成熟，性能和功能上都有很多待提升的空间，相比之下，MPP数据在数据处理上更加SMART，要填平或缩小与MPP数据库之间的性能和功能上的GAP，Hadoop还有很长的一段路要走。

就目前来看，个人认为这两个系统都有其适用的场景，简单来说，如果你的数据需要频繁的被计算和统计、并且你希望具有更好的SQL交互式支持和更快计算性能及复杂SQL语法的支持，那么你应该选择MPP数据库，SQL-on-Hadoop技术还没有Ready。特别如数据仓库、集市、ODS、交互式分析数据平台等系统，MPP数据库有明显的优势。

而如果你的数据加载后只会被用于读取少数次的任务和用于少数次的访问，而且主要用于Batch（不需要交互式），对计算性能不是很敏感，那Hadoop也是不错的选择，因为Hadoop不需要你花费较多的精力来模式化你的数据，节省数据模型设计和数据加载设计方面的投入。这些系统包括：历史数据系统、ETL临时数据区、数据交换平台等等。

总之，Bear in mind，千万不要为了大数据而大数据（就好像不要为了创新而创新一个道理），否则，你项目最后的产出与你的最初设想可能将差之千里，行业内不乏失败案例。

最后，提一下，Greenplum MPP数据库支持用“Hadoop外部表”方式来访问、加载Hadoop FS的数据，虽然Greenplum的Hadoop外部表性能大幅低于MPP内部表，但比Hadoop 自身的HIVE要高很多（在某金融客户的测试结果，比HIVE高8倍左右），因此可以考虑在项目中同时部署MPP数据库和Hadoop，MPP用于交互式高性能分析，Hadoop用于数据Staging、MPP的数据备份或一些ETL batch的数据清洗任务，两者相辅相成，在各自最擅长的场景中发挥其特性和优势。

5.未来GP发展之路

过去十年，IT技术潮起潮落发生着时刻不停的变化，而在这变化中的不变就是走向开放和开源的道路，即将到来的伟大变革是云计算时代的到来，任何IT技术，从硬件到软件到服务，都逃不过要接受云计算的洗礼，不能赶上时代潮流的技术和公司都将被无情的淘汰。大数据也要拥抱云计算，大数据将作为一种数据服务来提供（DaaS-Data as A Service），依靠云提供共享的、弹性、按需分配的大数据计算和存储的服务。

Greenplum MPP数据库从已一开始就是开放的技术，并且在2015年年底已经开源和成立社区（在开源第一天就有上千个Download），可以说，Greenplum已经不仅仅只是Pivotal公司一家的产品，我们相信越来越多组织和个人会成为Greenplum的Contributor贡献者，随着社区的发展将推动Greenplum MPP数据库走向新的高速发展旅程。（分享一下开源的直接好处，最近我们某用户的一个特殊需求，加载数据中有回车等特殊字符，我们下载了GP外部表gpfdist源代码，不到一天就轻松搞定问题）

Greenplum也正在积极的拥抱云计算，Cloud Foundry的PaaS云平台正在技术考虑把Greenplum MPP做为DaaS服务来提供，对于Mesos或其它云计算技术的爱好者，也可以考虑采用容器镜像技术+集群资源框架管理技术来部署Greenplum,从而可以实现在公共计算资源集群上的MPP敏捷部署和资源共享与分配。

总之，相信沿着开放、开源、云计算的路线继续前行，Greenplum MPP数据库在新的时代将保持旺盛的生命力，继续高速发展。