转：聊聊Greenplum的那些事

笔者有幸从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? 这个问题大体引伸出两个问题：

 

一、为何不从数据库底层进行从新设计研发？

 

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

 

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

 

二、为何是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数据库在新的时代将保持旺盛的生命力，继续高速发展。