【大数据之数据仓库】GreenPlum PK DeepGreen(TPCH)

阿凡达2018-07-10 12:49
1.背景
一张UML类图可以简单的说明GreenPlum和DeepGreen之间的关系:


GreenPlum:
DeepGreen:
DeepGreen官方宣传的优势:

事实是否如此呢?
2.测试
10GB数据集下的测试结果如下:
DeepGreen比GreenPlum快,基本符合预期,至于快多少倍,我们暂不关心,毕竟10GB的容量对于数据仓库来讲太小了。
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会优化选择这个慢的方案,这就同他优化器的具体实现有关了。
附件:
看这里:

本文来自网易实践者社区,经作者何李夫授权发布。