Greenplum 和Hadoop 都是为了解决大数据并行计算而出现的技术，二者的相似点在于：
l 分布式存储数据在多个节点上。
l 采用分布式并行计算框架。
l 支持向外扩展来提高整体的计算能力和存储容量。
l 支持X86 开放集群架构。
但两种技术在数据存储和计算方法上，也存在很多显而易见的差异：
l Greenplum 按照关系数据库行列表方式存储数据（有模式）；Hadoop 按照文件切块方式分布式存储（无模式）数据。
l 两者采用的数据分布机制不同，Greenplum 采用Hash 分布，计算节点和存储紧密耦合，数据分布在记录级的更小粒度，一般在1KB 以下；Hadoop FS 按照文件切块后随机分配，节点和数据无耦合，数据分布粒度在文件块级，默认为64MB 。
l Greenplum 采用SQL 并行查询计划；Hadoop 采用MapReduce 框架。
基于以上不同，体现在效率、功能特性等方面也大不相同。Greenplum 数据库在计算并行度、计算算法上比Hadoop 更加优雅，效率更高。图3-11 由Pivotal 提供，显示相同硬件环境下，基于MapReduce 的Hive 和Greenplum 在TPC-H （商业智能测试）22 个SQL 测试中的性能比较，可以看到两者的执行速度相去甚远。
图3-11 Hive 和Greenplum 在TPCH 中的性能比较
为了取得第一手数据，笔者做了以下两个简单的Greenplum 与MySQL 查询性能对比测试，以便有一个最初的直观体验。也许你会觉得拿分布式集群数据库与单机集中式数据库作比较有失公允，没错！笔者想说明的是：这两个查询都是线上实际在MySQL 上运行的慢查询，而考虑Greenplum 就是为了解决大数据量在MySQL 上查不动的问题。而且这也并不是严格的对等测试，Greenplum 只是由三台测试机组成的集群，而MySQL 使用的是线上高配服务器。
-- 查询1： select userid, target, relation_type, update_time from relation where userid = 717600270 and relation_type in (1, 2) order by update_time desc limit 30; -- 查询2： select a.* from moments_dynamic a -- force index (idx_user_all) join (select target from relation r where r.userid = 918046590 and (r.relation_type = 1 or r.relation_type = 2) union all select 918046590) b on a.userid=b.target where dynamic_status = 0 and dynamic_type in (1, 6, 8, 11, 13) order by id desc limit 80;
moments_dynamic 表有79309341 行，relation 表有499194521 行。查询1 ，Greenplum 用时44 ms ，MySQL 用时9210 ms ；查询2 ，Greenplum 用时75ms ，MySQL 用时170 ms(force index (idx_user_all)) 。
在功能上Greenplum 数据库采用SQL 作为主要交互式语言。SQL 语言简单易学，具有很强的数据操纵能力和过程语言的流程控制能力，是专门为统计和数据分析开发的语言，丰富的功能和函数极大简化了数据操作和交互过程。
而对于MapReduce 编程明显是困难的，在原生的MapReduce 开发框架基础上进行开发，需要技术人员谙熟Java 开发和并行原理，而这即便是技术人员也难以学习和操控。为了解决易用性问题，近年来SQL-on-Hadoop 技术大量涌现出来，成为当前Hadoop 开发使用的一个技术热点。其中，Hive 支持MapReduce 、Spark 、Tez 三种计算框架；Spark SQL 采用内存中的MapReduce ；Impala 、HAWQ 则借鉴MPP 计算思想来做查询优化和内存数据管道计算，以此来提高性能。
虽然SQL-on-Hadoop 比原始的MapReduce 在易用性上有所提高，但在SQL 成熟度和复杂分析上目前还与Greenplum 数据库有较大差距，笔者在使用过程中对此深有体会：
l SQL-on-Hadoop 系统中，除了HAWQ （HAWQ 从代码级别上可以简单理解成是数据存储在HDFS 上的Greenplum 数据库）外，其余系统对SQL 的支持都非常有限，特别是分析型复杂SQL ，如SQL 2003 OLAP WINDOW 函数，几乎都不支持，更不用说存储过程等数据库常规功能。以Impala 为例，不支持Date 数据类型，不支持XML 和JSON 相关函数，不支持covar_pop 、covar_samp 、corr 、percentile 、percentile_approx 、histogram_numeric 、collect_set 等聚合函数，不支持rollup 、cube 、grouping set 等操作，不支持数据抽样（Sampling ）等数据分析中的常用操作。在TPC-DS 测试中，Spark SQL 、Impala 、Hive 等只支持其中1/3 左右的SQL 测试。TPC-DS 是专门用于评测决策支持系统（大数据或数据仓库）的标准SQL 测试集，包含99 个SQL 。
l 由于HDFS 本身只能追加数据的特性（Append-only ），SQL-on-Hadoop 大多不支持行级数据更新（update ）和删除（delete ）功能。而像Hive 虽然通过配置可以支持事务和行级更新，但实现极为别扭，性能更是无法接受，基本不具实用价值。
l SQL-on-Hadoop 不擅长于交互式即席查询，多通过预关联的方式来规避这个问题。另外，在并发处理方面能力较弱，高并发大查询场景下，需要控制计算请求的并发度，避免资源过载导致的稳定性和性能下降等问题。笔者就曾多次遇到几个并发Spark SQL 任务占用大量内存，最终出现OOM 错误的情况。
反观专为大数据存储、计算、挖掘而设计的Greenplum ，它所拥有的丰富特性使其成为构建数据仓库等分析型应用的理想选择：
l 完善的标准支持。Greenplum 完全支持ANSI SQL 2008 标准和SQL OLAP 2003 扩展。例如，支持内连接、外连接、全连接、笛卡尔连接、相关子查询等所有表连接方式，支持并集、交集、差集等集合操作，并支持递归函数调用。作为一个数据库系统，提供这些功能很好理解。
l 除了包含诸多字符串、数字、日期时间、类型转换等常规标量函数以外，Greenplum 还包含丰富的窗口函数和高+级聚合函数，这些函数经常被用于分析型数据查询。窗口函数包括cume_dist 、dense_rank 、first_value 、lag 、last_valueexpr 、lead 、ntile 、percent_rank 、rank 、row_number 等。高+级聚合函数包括median 、percentile_cont (expr) within group (order by expr [desc/asc]) 、percentile_disc (expr) within group (order by expr [desc/asc]) 、sum(array[]) 、pivot_sum (label[], label, expr) 等。
l 得益于PostgreSQL 良好的扩展性（这里是extension ，不是scalability ），Greenplum 可以采用各种开发语言来开发用户自定义函数（UDF ）。自定义函数部署到Greenplum 后，能充分享受到实例级别的并行性能优势。建议把库外的处理逻辑部署为用MPP 数据库的UDF 这种库内方式来处理，这将获得意想不到的性能和方便。
l 支持分布式事务，支持ACID ，保证数据的强一致性。
l Greenplum 支持用“Hadoop 外部表”方式来访问、加载HDFS 的数据。虽然Greenplum 的Hadoop 外部表性能大幅低于MPP 内部表，但比Hadoop 自身的Hive 要快很多。Greenplum 还提供了gpfdist 文件服务器，可并行读写本地文件系统中的文件，最大化数据装载性能。
l Greenplum 有完善的生态系统，可以与很多企业级产品集成，如SAS 、Cognos 、Informatic 、Tableau 等；也可以与很多种开源软件集成，如Pentaho 、Talend 等。
本文节选自《 Greenplum 构建实时数据仓库实践》，内容发布获得作者和出版社授权。
