数据仓库选择Greenplum还是SQL-on-Hadoop

Greenplum和Hadoop都是为了解决大数据并行计算而出现的技术，二者的相似点在于：

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

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

Greenplum按照关系数据库行列表方式存储数据（有模式）；Hadoop按照文件切块方式分布式存储（无模式）数据。
两者采用的数据分布机制不同，Greenplum采用Hash分布，计算节点和存储紧密耦合，数据分布在记录级的更小粒度，一般在1KB以下；Hadoop FS按照文件切块后随机分配，节点和数据无耦合，数据分布粒度在文件块级，默认为64MB。
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_timefrom relationwhere userid = 717600270and relation_type in (1, 2) order by update_time desclimit 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.targetwhere dynamic_status = 0and dynamic_type in (1, 6, 8, 11, 13) order by id desclimit 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数据库有较大差距，笔者在使用过程中对此深有体会：

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。
由于HDFS本身只能追加数据的特性（Append-only），SQL-on-Hadoop大多不支持行级数据更新（update）和删除（delete）功能。而像Hive虽然通过配置可以支持事务和行级更新，但实现极为别扭，性能更是无法接受，基本不具实用价值。
SQL-on-Hadoop不擅长于交互式即席查询，多通过预关联的方式来规避这个问题。另外，在并发处理方面能力较弱，高并发大查询场景下，需要控制计算请求的并发度，避免资源过载导致的稳定性和性能下降等问题。笔者就曾多次遇到几个并发Spark SQL任务占用大量内存，最终出现OOM错误的情况。

反观专为大数据存储、计算、挖掘而设计的Greenplum，它所拥有的丰富特性使其成为构建数据仓库等分析型应用的理想选择：

完善的标准支持。Greenplum完全支持ANSI SQL 2008标准和SQL OLAP 2003 扩展。例如，支持内连接、外连接、全连接、笛卡尔连接、相关子查询等所有表连接方式，支持并集、交集、差集等集合操作，并支持递归函数调用。作为一个数据库系统，提供这些功能很好理解。
除了包含诸多字符串、数字、日期时间、类型转换等常规标量函数以外，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)等。
得益于PostgreSQL良好的扩展性（这里是extension，不是scalability），Greenplum 可以采用各种开发语言来开发用户自定义函数（UDF）。自定义函数部署到Greenplum后，能充分享受到实例级别的并行性能优势。建议把库外的处理逻辑部署为用MPP数据库的UDF这种库内方式来处理，这将获得意想不到的性能和方便。
支持分布式事务，支持ACID，保证数据的强一致性。
Greenplum支持用“Hadoop外部表”方式来访问、加载HDFS的数据。虽然Greenplum的Hadoop外部表性能大幅低于MPP内部表，但比Hadoop自身的Hive要快很多。Greenplum还提供了gpfdist文件服务器，可并行读写本地文件系统中的文件，最大化数据装载性能。
Greenplum有完善的生态系统，可以与很多企业级产品集成，如SAS、Cognos、Informatic、Tableau等；也可以与很多种开源软件集成，如Pentaho、Talend等。

本文节选自《Greenplum构建实时数据仓库实践》，内容发布获得作者和出版社授权。