电话咨询

0571-89852485

工作日 9:30-18:00

在线咨询

架构师咨询

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

2018-07-10     作者:何李夫
本篇文章仅限本站分享,如需转载,请联系网易获取授权。
欢迎技术交流和讨论:bigdata@service.netease.com

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会优化选择这个慢的方案,这就同他优化器的具体实现有关了。

附件:

attachment.zip

看这里:

【大数据之数据仓库】选型流水记

立即下载

猛犸技术白皮书

提交以下信息,即可立即下载猛犸技术白皮书

格式不正确
格式不正确
格式不正确
请输入正确的验证码
请选择职位