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,deptno,ename），表b(deptno,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分布，也很關鍵。
大資料執行環境的執行
1.azkaban 啟動 bin azkaban solo start.sh或絕對路徑方式執行azkaban solo start.sh指令碼 關閉 bin azkaban solo shutdown.sh 2.kafka 注意配置server.properties,此配置檔案用來配置kafka伺服...
編譯執行和解析執行的區別以及執行的速度比較？
解釋執行 由直譯器根據輸入的資料當場執行而不生成任何的目標程式.解釋執行，它解釋一句就執行一句，不形成目標程式，輸入一條命令語句，解釋程式就立即將此語句解釋成一條或幾條指令並提交硬體立即執行且將執行結果反映到終端，就能立即得到計算結果。但解釋程式執行速度很慢，例如源程式中出現迴圈，則解釋程式也重複地...
執行緒的執行
就需要使用執行緒池來進行管理。執行緒池的好處 降低重複建立執行緒的開銷 任務 runnable 基本的任務介面，run 方法沒有返回值，不能丟擲異常。callable runnable的公升級版，call 方法既有返回值，又丟擲異常。任務的執行 executor 可以執行 execute runna...