关于greenplum:特性分析-GreenPlum-的并行查询优化策略详解

41次阅读

共计 3611 个字符,预计需要花费 10 分钟才能阅读完成。

本文首发于 2016-11-21 09:43:07

架构

GreenPlum 采纳 Share Nothing 的架构,良好的施展了便宜 PC 的作用。自此 I / O 不在是 DW(data warehouse) 的瓶颈,相同网络的压力会大很多。然而 GreenPlum 的查问优化策略可能防止尽量少的网络替换。对于首次接触 GreenPlum 的人来说,必定耳目一新。

查问优化器

GreenPlum 的 master 节点负责 SQL 解析和执行打算的生成,具体来说,查问优化器会将 SQL 解析成每个节点(segments)要执行的物理执行打算。

GreenPlum 采纳的是基于老本的优化策略:如果有多条执行门路,会评估执行代价,找出代价最小、最有效率的一条。

不像传统的查问优化器,GreenPlum 的查问优化器必须全局的思考整个集群,在每个候选的执行打算中思考到节点间挪动数据的开销。比方有 join,那么 join 是在各个节点别离进行的(每个节点只和本身数据做 join),所以它的查问很快。

查问打算包含了一些传统的操作,比方:扫描、Join、排序、聚合等等。

GreenPlum 中有三种数据的挪动操作:

  • Broadcast Motion (N:N):播送数据。每个节点向其余节点播送须要发送的数据。
  • Redistribute Motion (N:N):从新散布数据。利用 join 列数据的 hash 值不同,将筛选后的数据在其余 segment 从新散布。
  • Gather Motion (N:1):聚合汇总数据。每个节点将 join 后的数据发到一个单节点上,通常是发到主节点 master。

示例

示例 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;   
                                       QUERY PLAN                                          
----------------------------------------------------------------------------------------   
 Gather Motion 88:1  (slice2)  (cost=3.01..939.49 rows=2717 width=59)   
   ->  Hash Join  (cost=3.01..939.49 rows=2717 width=59)   
         Hash Cond: d.partner_id::text = j.partner_id::text   
         ->  Seq Scan on data d  (cost=0.00..260.74 rows=20374 width=50)   
         ->  Hash  (cost=1.91..1.91 rows=88 width=26)   
               ->  Broadcast Motion 88:88  (slice1)  (cost=0.00..1.91 rows=88 width=26)   
                     ->  Seq Scan on jd1 j  (cost=0.00..1.02 rows=1 width=26)   
                           Filter: gmt_modified > ('now'::text::date - 80)  

执行打算须要自下而上剖析:

  1. 在各个节点扫描本人的 jd1 表数据,依照条件过滤生成数据(记为 rs)。
  2. 各节点将本人生成的 rs 顺次发送到其余节点。(Broadcast Motion (N:N)
  3. 每个节点上的 data 表的数据,和各自节点上收到的 rs 进行 join,这样能保障本机数据只和本机数据做 join。
  4. 各节点将 join 后的后果发送给 master(Gather Motion (N:1))。

由下面的执行过程能够看出,GreenPlum 将 rs 给每个含有 data 表数据的节点都发了一份。

问:如果 rs 很大或者压根就没有过滤条件,会有什么问题?如何解决?

比方本例中的表 jd1 和表 data 的数据行数如下:

=> select count(*) from jd1;   
 count    
-------   
    20   
(1 row)  
=> select count(*) from data;   
 count     
--------   
 113367  

如果 rs 很大的话,播送数据时网络就会成为瓶颈。GreenPlum 的优化器很聪慧,它是将 小表 播送到各个 segment 上,极大的升高网络开销。从这个例子能看出统计信息对于生成好的查问打算是何等重要。

示例 2

上面看一个简单点的例子:

select
    c_custkey, c_name,
    sum(l_extendedprice * (1 - 1_discount)) as revenue,
    c_acctbal, n_name, c_address, c_phone, c_comment
from
    customer, orders, lineitem, nation
where
    c_custkey = o_custkey
and 1_orderkey = o_orderkey
and o_orderdate >= date '1994-08-01'
and o_orderdate < date '1994-08-0l'
                  + interval '3 month'
and l_returnflag = 'R' 
and c_nationkey = n_nationkey
group by
    c_custkey, c_name, c_acctbal,
    c_phone, n_name, c_address, c_comment
order by
    revenue desc

执行打算如下:

  1. 各个节点上同时扫描各自的 nation 表数据,将各 segment 上的 nation 数据向其余节点播送(Broadcast Motion (N:N))。
  2. 各个节点上同时扫描各自 customer 数据,和收到的 nation 数据 join 生成RS-CN
  3. 各个 segment 同时扫描本人 orders 表数据,过滤数据生成 RS-O
  4. 各个 segment 同时扫描本人 lineitem 表数据,过滤生成 RS-L
  5. 各个 segment 同时将各自 RS-ORS-L 进行 join,生成RS-OL。留神此过程不须要 Redistribute Motion (N:N) 从新散布数据,因为 orders 和 lineitem 的 distribute column 都是 orderkey,这就保障了各自须要 join 的对象都是在各自的机器上,所以 n 个节点就开始并行 join 了。
  6. 各个节点将本人在步骤 5 生成的 RS-OL 依照 cust-key 在所有节点间从新散布数据(Redistribute Motion (N:N),能够依照 hash 和 range 在节点间来从新散布数据,默认是 hash),这样每个节点都会有本人的 RS-OL
  7. 各个节点将本人在步骤 2 生成的 RS-CN 和本人节点上的 RS-OL 数据进行 join,又是本机只和本机的数据进行 join。
  8. 聚合,排序,发往主节点 master。

总结

Greenplum 如何解决和优化一张大表和小表的 join?

Greenplum 是抉择将小表播送数据,而不是将大表播送。

举例说明:

表 A 有 10 亿条数据(empno<pk>,deptno,ename),表 B 有 500 条数据(deptno<pk>,dname,loc

表 A 与表 B 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。

由该例可见统计信息非常重要,GreenPlum 通过统计信息来确定将哪张表进行(Broadcast Motion (N:N))。

另外,理论应用中还会呈现 列值歪斜 的状况,比方 A 没有依照主键来 hash 散布,而是人为指定依照 deptno 的 hash 在各个节点上散布数据。若 A 中 80% 的数据都是 sales(deptno=10)部门的,此时 10 个节点中,就会有一个节点上领有了 10 亿×80% 的数据,就算是将表 B 播送到其余节点 也杯水车薪,因为 计算的压力都集中在一台机器 了。所以,必须抉择适合的列进行 hash 散布


欢送关注我的微信公众号【数据库内核】:分享支流开源数据库和存储引擎相干技术。

题目 网址
GitHub https://dbkernel.github.io
知乎 https://www.zhihu.com/people/…
思否(SegmentFault) https://segmentfault.com/u/db…
掘金 https://juejin.im/user/5e9d3e…
开源中国(oschina) https://my.oschina.net/dbkernel
博客园(cnblogs) https://www.cnblogs.com/dbkernel

正文完
 0