Greenplum 的分布式框架結構
1.基本架構
Greenplum（以下簡稱 GPDB）是一款典型的 Shared-Nothing 分布式數據庫系統。GPDB 擁有一個中控節點（ Master ）統籌整個系統，並在整個分布式框架下運行多個數據庫實例（ Segment ）。Master 是 GPDB 系統的訪問入口，其負責處理客戶端的連接及 SQL 命令、協調系統中的其他 Segment 工作，Segment 負責管理和處理用戶數據。而每個 Segment 實際上是由多個獨立的 PostgreSQL 實例組成，它們分布在不同的物理主機上，協同工作。
主節點與子節點
GPDB中，數據通過復雜的HASH 算法或隨機拆分成無重疊的記錄集合，分布到所有 Segment 上。僅 Master 完成與用戶和客戶端程序的直接交互。因此但對於用戶來說，使用 GPDB 系統如同使用一個單機數據庫。
Master上存儲全局系統表（Global System Catalog ），但不存儲任何用戶數據，用戶數據只存儲在 Segment 上。Master 負責客戶端認證、處理 SQL 命令入口、在Segment 之間分配工作負、整合 Segment 處理結果、將最終結果呈現給客戶端程序。
用戶 Table 和相應的 Index 都分布在 GPDB 中各 Segment 上，每個 Segment 只存儲其中屬於本節點的那部分數據。用戶不能夠直接跳過 Master 訪問 Segment，而只能通過 Master 來訪問整個系統。在 GPDB 推薦的硬件配置環境下，每個有效的 CPU 核對應一個 Segment ，比如一台物理主機配備了2個雙核的 CPU，那么每個主機配置4個主實例（ Segment Primary ）。
網絡鏈接
網絡層組件（ Interconnect ）是 GPDB的重要組件。在用戶執行查詢時，每個 Segment 都需要執行相應的處理，因此物理主機間需要進行控制信息和數據的高效傳遞。網絡層的作用就是實現物理主機之間的通信、數據傳遞，以及備份。在默認情況下，網絡層使用 UDP 協議。GPDB 自己會為 UDP 協議做數據包校驗，其可靠性與 TCP 協議一致，但其性能和擴展性遠好於TCP協議。
2.查詢執行機制
系統啟動后，用戶通過客戶端程序（例如 psql ）連接到的 Master 主機並提交查詢語句。GP 會創建多個 DB 進程來處理查詢。在 Master 上的稱為執行分發器（ Query Dispatcher/QD ）。QD 負責創建、分發查詢計划，匯總呈現最終結果。在 Segment 上，處理進程被稱為查詢執行器（ Query executor/QE ）。QE負責完成自身部分的處理工作以及與其他處理進程之間交換中間結果。
查詢計划生成與派發
查詢被 Master 接收處理（ QD身份）。QD 將查詢語句依據所定義的詞法和語法規則創建原始查詢語法樹。接着在查詢分析階段，QD 將原始語法樹轉換為查詢樹。然后進入查詢改寫階段，QD 將查詢樹依據系統中預先定義的規則對查詢樹進行轉換。QD 最終調用優化器接受改寫后的查詢樹，並依據該查詢樹完成查詢邏輯優化和物理優化。GPDB 是基於成本的優化策略：評估若干個執行計划，找出最有效率的一個。但查詢優化器必須全局的考慮整個集群，在每個候選的執行計划中考慮到節點間移動數據的開銷。至此 QD 創建一個並行的或者定向的查詢計划（根據查詢語句決定）。之后Master將查詢計划分發到相關的 Segment 去執行，每個 Segment 只負責處理自己本地的那部分數據操作。大部分的操作—比如掃表、關聯、聚合、排序都是同時在 Segment 上並行被執行。每個具體部分都獨立於其他 Segment 執行（一旦執行計划確定，比如有 join，派發后 join 是在各個節點分別進行的，本機只和本機的數據 join ）。
查詢執行
由於 GPDB 采用 Shared-Nothing 架構，為了最大限度的實現並行化處理，當節點間需要移動數據時，查詢計划將被分割，最終一個查詢會分為多個切片（ slice ），每個切片都涉及不同處理工作。即：先執行一步分操作，然后執行數據移動，再執行下一步分操作。在查詢執行期間，每個 Segment 會根據查詢計划上 slice 的划分，創建多個 postgres 工作進程，並行的執行查詢。每個 slice 對應的進程只處理屬於自己部分的工作，且這些處理工作僅在本 Segment 上執行。slice 之間為樹形結構，其整體構成整個查詢計划。不同 Segment 之間對應的查詢計划上的同一個 slice 處理工作稱為一個簇（ gang ）。在當前 gang 上的工作完成后，數據將向上傳遞，直到查詢計划完成。Segment之間的通信涉及到 GPDB 的網絡層組件（ Interconnect ）。
QE 為每個 slice 開啟獨立進程，在該進程內執行多個操作。每一步代表着特定的 DB 操作，比如：掃表、關聯、聚合、排序等。Segment 上單個 slice 對應進程的執行算子從上向下調用，數據從下向上傳遞。
與典型的 DB 操作不同的是，GPDB 有一個特有的算子：移動（ motion ）。移動操作涉及到查詢處理期間在 Segment 之間移動數據。motion 分為廣播（ broadcast ）和重分布（ redistribute motion ）兩種。正是 motion 算子將查詢計划分割為一個個 slice ，上一層 slice 對應的進程會讀取下一層各個 slice 進程廣播或重分布的數據，然后進行計算。
Greenplum 同 PostgreSQL 一樣，采用元組流水方式獲取和處理數據。我們按需取出單條元組，在處理本條元組后，系統將會取出下一條滿足條件的元組，直到取出所有滿足條件的元組為止。slice 間的 motion 操作同樣以元組為單位收發數據，並通過下層 slice 緩沖構成生產消費模型，但不會阻斷整個查詢的流水。最終，各 Segment 的查詢結果同樣通過 motion 傳給 Master，Master 完成最終處理后返回查詢結果。
3.容錯機制
節點鏡像與故障容錯
GPDB 支持為 Segment 配置鏡像節點，單個Primary Segment 與對應的 Mirror Segment 配置在不同的物理主機上。同一物理主機可同時混合裝載多個對應不同實例的 Primary Segment 和 Mirror Segment 。Primary Segment 與對應 Mirror Segment 之間的數據基於文件級別同步備份。Mirror Segment 不直接參與數據庫事務和控制操作。
當 Primary Segment 不可訪問時，系統會自動切換到其對應的 Mirror Segment 上，此時，Mirror Segment 取代 Primary Segment 的作用。只要剩余的可用 Segment 能夠保證數據完整性，在個別 Segment 或者物理主機宕機時，GPDB系統仍可能通過 Primary/Mirror 身份切換，來保持系統整體的可用狀態。
其具體切換過程是，每當 Master 發現無法連接到某 Primary Segment 時（ FTS系統），會在 GPDB 的系統日志表中標記失敗狀態，並激活/喚醒對應的 Mirror Segment 取代原有的 Primary Segment 繼續完成后續工作。失敗的 Primary Segment 可以等恢復工作能力后，在系統處於運行狀態時切換回來。
擴展閱讀
Greenplum Database Administrator Guide
Greenplum 源碼安裝教程
轉載請注明 作者 Arthur_Qin(禾眾) 及文章地址 http://www.cnblogs.com/arthurqin/p/6243277.html