1、GreenPlum这种share nothing的架构:

良好的发挥了廉价PC的作用。自此I/O不在是DW的瓶颈,相反网络的压力会大很多。但是greenplum的查询优化策略能够避免尽量少的网络交换。对于初次接触greenplum的人来说,肯定耳目一新。

2、greenplum的查询优化器

greenplum的查询优化器负责将SQL解析成每个节点(segments)所要走的物理执行计划。也是基于成本的优化策略:评估若干个执行计划,找出最有效率的一个。主节点master负责SQL解析和执行计划的生成。

不像传统的查询优化器,Greenplum的查询优化器必须全局的考虑整个集群,在每个候选的执行计划中考虑到节点间移动数据的开销。一旦执行计划确定,比如有join,那么join是在各个节点分别进行的(本机只和本机的数据join)。所以它的查询很快。

3、查询计划包括了一些传统的操作,比如:扫描、Join、排序、聚合等等。greenplum中有三种数据的移动操作:

A: Broadcast Motion (N:N) ,即广播数据,每个节点向其他节点广播需要发送的数据。

B: Redistribute Motion (N:N) ,重新分布数据,利用join的列值hash不同,将筛选后的数据在其他segment重新分布。

C: Gather Motion (N:1),聚合汇总数据,每个节点将join后的数据发到一个单节点上,通常是发到主节点master。

4、一个简单的例子:

Sql代码
  1. explain select d.*,j.customer_id from data d join jd1 j on d.partner_id=j.partner_id where j.gmt_modified> current_date -80;

  2. QUERY PLAN

  3. ----------------------------------------------------------------------------------------

  4. Gather Motion 88:1 (slice2) (cost=3.01..939.49 rows=2717 width=59)

  5. -> Hash Join (cost=3.01..939.49 rows=2717 width=59)

  6. Hash Cond: d.partner_id::text = j.partner_id::text

  7. -> Seq Scan on data d (cost=0.00..260.74 rows=20374 width=50)

  8. -> Hash (cost=1.91..1.91 rows=88 width=26)

  9. -> Broadcast Motion 88:88 (slice1) (cost=0.00..1.91 rows=88 width=26)

  10. -> Seq Scan on jd1 j (cost=0.00..1.02 rows=1 width=26)

  11. Filter: gmt_modified > ('now'::text::date - 80)

执行计划执行从下至上:

a, 在各个节点扫描自己的jd1表数据,按照条件过滤生成数据rs

b, 各节点将自己生成的rs依次发送到其他节点。(Broadcast Motion (N:N) ,即广播数据)

c, 每个节点上的data表的数据,和各自节点上收到的rs进行join。这样就保证本机上的数据只和本机的数据join。

d,各节点将join后的结果发送给master(Gather Motion (N:1))

由上面的执行过程可以看出, Greenplum 是将 rs 给每个含有 data 表数据的节点都发了一份的。

要是 RS 很大或者压根就没有过滤条件怎么办呢:

Sql代码
  1. => selectcount(*) from jd1;

  2. count

  3. -------

  4. 20

  5. (1 row)

Sql代码
  1. => selectcount(*) from data;

  2. count

  3. --------

  4. 113367

要是 rs 很大的话,广播数据 网络就会成为瓶颈。可以看出 greenplum 很聪明:

它是将小表广播到各个 segment 上。可以看出统计信息对于生成好的查询计划是何等重要。

5、下面看一个复杂点的例子:

执行计划:

A,各个节点上 同时扫描各自的nation表数据,将各segment上的nation数据向其他节点广播(Broadcast Motion (N:N) )

B, 各个节点上 同时扫描各自customer数据,和收到的nation数据join 生成RS-CN

C,各个segment同时扫描自己orders表数据,过滤数据生成RS-O

D, 各个segment同时扫描 自己lineitem表数据,过滤生成RS-L

E,各个segment同时将各自RS-O和RS-L进行join 生成RS-OL,注意此过程不需要Redistribute Motion (N:N) ,重新分布数据,因为orders和lineitem的distribute column都是orderkey。这就保证了各自需要join的对象都是在各自的机器上,所以n个节点就开始并行join了。

F, 各个节点将自己在步骤E生成的RS-OL按照cust-key在所有节点间重新分布数据(Redistribute Motion (N:N),可以按照hash和range在节点间来重新分布数据,默认是hash ),这样每个节点都会有自己的RS-OL

G, 各个节点将自己在步骤B生成的RS-CN和自己节点上的RS-OL数据进行join,又是本机只和本机的数据进行join

H, 聚合,排序,发往主节点master

6、总结:

Greenplum如何处理和优化一张大表和小表的join?

Greenplum是选择将小表广播数据,而不是将大表广播。

举例说明:表A 有10亿 (empno<pk>,deptno,ename),表B(deptno<pk>,dname,loc) 500条 join on deptno

有11个节点:1 master+10 segment

按照正常的主键列hash分布,每个segment节点上只会有1/10的A和1/10的表B。

此时greenplum会让所有节点给其他节点发送各自所拥有的小表(B)1/10的数据,这样就保证了10个节点上,每个节点都有一份完整的表B的数据。此时 每个节点上1/10的A 只要和自己节点上的B进行Join 就OK。所以Greenplum并行处理能力惊人的原因就在这里。

最终所有节点会将join的结果都发给主节点master,master负责和各种client(比如JDBC,GP client等等)的连接。可见统计信息十分重要,Greenplum通过统计信息来确定将哪张表进行(Broadcast Motion (N:N) ,即广播数据)。

还有一种,对于列值倾斜的情况, 比如A 没有按照主键来hash分布,而是人为指定按照deptno的hash在各个节点上分布数据,若A中80%的数据 都是sales (deptno=10)部门的。此时10个节点中,就会有一个节点上拥有了10亿×80%的数据,就算是将B表广播到其他节点了 也无济于事,因为计算的压力都集中在一台机器了。所以选择合适的列进行hash分布,也很关键。

转载于:https://blog.51cto.com/jackwxh/1311341

GreenPlum的并行查询优化策略相关推荐

  1. Greenplum数据库数据分片策略Hash分布——GUC gp_use_legacy_hashops

    GUC系统参数gp_use_legacy_hashops可以控制建立列分布表时使用传统的哈希算法还是新的哈希算法.新的哈希算法如Greenplum数据库Hash分布--计算哈希值和映射segment文 ...

  2. 大规模分布式存储系统 - 读书笔记

    文章目录 大规模分布式存储系统(原理解析与架构实战OceanBase) 第1章 概述 1.1 分布式存储概述 1.2 分布式存储分类 第一篇 基础篇 第2章 单机存储系统 2.1 硬件基础 2.1.1 ...

  3. Greenplum 实时数据仓库实践(9)——Greenplum监控与运维

    目录 9.1 权限与角色管理 9.1.1 Greenplum中的角色与权限 9.1.2 管理角色及其成员 9.1.3 管理对象权限 9.1.4 口令加密 9.2 数据导入导出 9.2.1 file协议 ...

  4. 2017云栖大会门票转让_「揭秘GP」云栖大会 | Greenplum 6.0 内核优化解读和7.0展望...

    9月25日,云栖大会在杭州阿里巴巴云栖小镇正式拉开序幕,三天会议期间,共吸引了200多位世界级科学家.400多家科技合作伙伴参与,科技展区面积超过3万平方米,共发布了1000多项顶尖技术. 云栖大会现 ...

  5. 【02】查询优化的技术范围

    为什么80%的码农都做不了架构师?>>>    0.技术类型 (1)逻辑查询优化技术 A.语法级 基于语法进行优化 B.代数级 使用形式逻辑进行优化,运用关系代数的优化 C.语义级 ...

  6. 【青梅快讯】Greenplum 最新版本6.20.3已正式发布

    引言 自Greenplum 6.0正式版发布以来,一直保持每月一个小版本的迭代速率,持续为用户提供新功能和修复补丁,目前的最新版 6.20.3 已于2022年4月8日发布.此外,Greenplum众多 ...

  7. MySQL基础(二十八)索引优化与查询优化

    都有哪些维度可以进行数据库调优?简言之: 索引失效.没有充分利用到索引--索引建立 关联查询太多JOIN (设计缺陷或不得已的需求)--SQL优化 服务器调优及各个参数设置(缓冲.线程数等)---调整 ...

  8. Greenplum简介

    Greenplum: http://greenplum.org/ 原来是个商业产品,后来开源. 从Slogan看: 是个数据库 着眼于数据仓库 主要在于大规模并行 基于强大的PostgreSQL,Po ...

  9. Greenplum 6.0 版本官方最强解读

    Pivotal Greenplum 6.0 已于2019年9月4日正式发布,可从Pivotal Network中下载. 十六年来,Greenplum始终致力于帮助企业更加高效地分析数据,使企业增加了收 ...

最新文章

  1. C语言应用于LR中-如何得到数组长度
  2. jQuery 表格实现
  3. 新鲜出炉的canvas~
  4. sqlite3_get_table()
  5. After Effect弹性表达式的用法
  6. 零管理费的基金你见过吗?基金行业价格战预演
  7. [Klipper从入门到放弃]香橙派zero2设置2.4g无线热点
  8. java list移除所有元素_Java - List集合中如何删除多个元素? remove( )方法 ?
  9. 飞桨框架v2.3 API最新升级!对科学计算、概率分布和稀疏Tensor等提供更全面支持!...
  10. 重磅 ! CVPR2020最新计算机视觉论文代码分类打包下载
  11. 腾讯再次投资国外著名游戏开发商 入股Epic布局长远
  12. 黑马程序员————交通灯管理系统
  13. tan0.75等于多少度用计算机怎么算,75度的正弦值是多少?怎么计算?
  14. LOL无限火力是哪个服务器先上线,LOL无限火力2019什么时间上线 2019LOL无限火力新玩法了解一下...
  15. 五十四、HBase的协处理器
  16. Linux 系统安全加固篇之安全加固脚本
  17. MIPI CSI-2调试总结
  18. sql 数据库显示 正在恢复
  19. flexslider图片轮播
  20. cloudreve重置管理密码

热门文章

  1. php-5.6.26源代码 - opcode执行
  2. Function types cannot have argument labels 错误解决方案
  3. html5中在canvas上绘图
  4. PHP和MySQL入门(8)
  5. 好用的把PDF等转换为SWF的工具
  6. sql语句跨服务器跨数据库执行
  7. 微软Expression Blend功能介绍
  8. 2018-10-19 Chrome插件实现GitHub代码离线翻译v0.0.4
  9. python编程:从入门到实践--项目1-外星人入侵_学习笔记_源码
  10. Java forEach中 Lambda Expr中的 final变量要求