1.背景
一张UML类图可以简单的说明GreenPlum和DeepGreen之间的关系：
GreenPlum：
DeepGreen：
DeepGreen官方宣传的优势：
事实是否如此呢？
2.测试
在10GB数据集下的测试结果如下：
DeepGreen比GreenPlum快，基本符合预期，至于快多少倍，我们暂不关心，毕竟10GB的容量对于数据仓库来讲太小了。
在
1TB数据集下的测试结果如下：
1TB数据集下的测试结果如下：
大部分sql都是DeepGreen比GreenPlum快，但是3、5、17都是GreenPlum快，
不符合预期！
不符合预期！
3.分析
我在附件中贴上了第1和第3两个sql的explain以及DDL，大家感兴趣的话可以对比下，能发现一些有趣的东西：）
我们关心的是为什么DeepGreen会比GreenPlum慢！？我们以第3个sql来进行分析。
照着explain文件逐行分析比对数据总结成如下两个执行计划图，左边是GreenPlum的执行计划，右边是DeepGreen的执行计划：
整个执行计划扫描3张表，原始记录：lineitem表有5,999,989,709条记录，orders表有1,500,000,000条记录，customer表150,000,000条记录。
明显的，两个执行计划不一样，图中的数字是从explain文件中抽取出来的，表示的是每个节点执行完后的有效数据记录数量；每个执行计划的耗时主要集中在图中蓝色节点部分。
善于观察的同事应该已经看到右侧执行计划中的红色框框部分了:)
在custkey关联这个阶段：
左侧各节点的计算量：(149,630,385/72) x 29,998,152 = 2,078,199 x 29,998,152
右侧各节点的计算量：144,147,772 x (3,266,814,571/72) = 144,147,772 x 45,372,424
两个执行计划的关联计算任务不在一个量级，耗时也显而易见了，这就是为什么DeepGreen比GreenPlum执行慢的原因！而为什么DeepGreen会优化选择这个慢的方案，这就同他优化器的具体实现有关了。
附件：
看这里：
本文来自网易云社区，经作者何李夫授权发布。
原文地址：【大数据之数据仓库】GreenPlum PK DeepGreen（TPCH）
更多网易研发、产品、运营经验分享请访问网易云社区。