greenplum是基於postgre的數據庫，最大的特徵就是分佈式，多節點（segment）。保存的數據會根據分佈鍵存儲到不同的節點上，用於查詢或者關聯。如果分佈鍵選擇得當，數據散列均勻，各個節點的數據量就會保持平衡，量級基本一致。如果選擇不當就是導致數據傾斜，某一個節點數據量特別大。直接影響就是木桶效應，其他節點不工作，一個節點處理所有的數據，再提交給master，效率低下。理想狀態下關聯表分佈鍵相同，在同一節點進行關聯提交MASTER。
Greenplum分佈鍵方式：
| Hash分佈：選擇一個或多個列作爲分佈鍵，計算 hash 值，並通過 hash 值路由到特定的Segment節點上。如果不指定分佈鍵，默認將第一個字段作爲分佈鍵。 |
| 隨機分佈：數據隨機分散在每一個節點中，可以保證數據平均分佈，但是在執行 SQL 的過程中，關聯等操作都需要將數據重分佈，性能較差。 |
分佈鍵的創建：
- DISTRIBUTED BY（字段1，字段2）指定字段作爲分佈鍵
- 變更分佈鍵（ALTER TABLE 表明 set distributed by(字段1,字段2)），執行後會重新分佈節點上的數據。
- 建表時不指定DISTRIBUTED BY 第一個字段就是分佈鍵。
分佈鍵的選擇：
-
經常需要 JOIN 的列
當關聯鍵和分佈鍵均一致時，可以在 Segment 中完成 JOIN，不需要重分佈或者廣播表（左連接 不能將左表廣播，右連接 不能將右表廣播，全連接時，兩表不允許廣播 ）。
當關聯鍵和分佈鍵不一致時，則需要重分佈不一致的表或者廣播表，帶來額外的開銷。
例：左分佈鍵 關聯 右非分佈鍵
無分佈鍵進行關聯：
選擇分佈鍵關聯代價會減少。
-
分佈均勻的列或者多列
選擇的分佈列值單一，則可能導致數據傾斜，更有可能全部傾斜到一個節點上。master會等待所有的segment提交數據後返回結果，小的節點立即提交，但是大的節點會浪費很多時間。所以一次SQL執行的時間無形中被延長了。
若表中沒有分佈太均勻的字段 就多個字段進行組合分佈。
查詢數據傾斜狀態: select gp_segment_id,count(*) from ods_events GROUP BY gp_segment_id;
-
高併發查詢的條件列
如果數據經常被高併發的鍵值或離散查詢，可以將查詢條件的列作爲分佈列，這樣不需要連接到所有的 Segment 去查，可以大大提高併發能力。
-
不要輕易使用隨機分佈
隨機分佈，單表使用還好，如果多表管理，就是上圖（無分佈鍵進行關聯）的效果了。多節點重分佈。。。效率低下
-
不會被修改的字段
程序中也應注意，分佈鍵不能出現在update語句中，半自動修改數據的時候要避開分佈鍵，不要出現在被修改的字段中。
