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代碼

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)

執行計劃執行從下至上：

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代碼

=> selectcount(*) from jd1;

count

-------

20

(1 row)

Sql代碼

=> selectcount(*) from data;

count

--------

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的并行查询优化策略的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。