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