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

本文首发于 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