greenplum SQL 的执行过程

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

 

总结：

   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分布，也很关键。