Greenplum 的分佈式框架結構

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