詳解開源大資料引擎Greenplum的架構和技術特點

greenplum的mpp架構

greenplum（以下簡稱gpdb）是一款開源資料倉庫。基于開源的postgresql改造，主要用來處理大規模資料分析任務，相比hadoop，greenplum更适合做大資料的存儲、計算和分析引擎。

gpdb是典型的master/slave架構，在greenplum叢集中，存在一個master節點和多個segment節點，其中每個節點上可以運作多個資料庫。greenplum采用shared nothing架構（mpp）。典型的shared nothing系統會集資料庫、記憶體cache等存儲狀态的資訊；而不在節點上儲存狀态的資訊。節點之間的資訊互動都是通過節點網際網路絡實作。通過将資料分布到多個節點上來實作規模資料的存儲，通過并行查詢處理來提高查詢性能。每個節點僅查詢自己的資料。所得到的結果再經過主節點處理得到最終結果。通過增加節點數目達到系統線性擴充。

　　圖1 gpdb的基本架構

如上圖1為gpdb的基本架構，用戶端通過網絡連接配接到gpdb，其中master host是gp的主節點（用戶端的接入點），segment host是子節點（連接配接并送出sql語句的接口），主節點是不存儲使用者資料的，子節點存儲資料并負責sql查詢，主節點負責相應用戶端請求并将請求的sql語句進行轉換，轉換之後排程背景的子節點進行查詢，并将查詢結果傳回用戶端。

greenplum master

master隻存儲系統中繼資料，業務資料全部分布在segments上。其作為整個資料庫系統的入口，負責建立與用戶端的連接配接，sql的解析并形成執行計劃，分發任務給segment執行個體，并且收集segment的執行結果。正因為master不負責計算，是以master不會成為系統的瓶頸。

master節點的高可用（圖2），類似于hadoop的namenode ha，如下圖，standby master通過synchronization process，保持與primary master的catalog和事務日志一緻，當primary master出現故障時，standby master承擔master的全部工作。

　　圖2 master節點的高可用segments

greenplum中可以存在多個segment，segment主要負責業務資料的存儲和存取（圖3），使用者查詢sql的執行，每個segment存放一部分使用者資料，但是使用者不能直接通路segment，所有對segment的通路都必須經過master。進行資料通路時，所有的segment先并行處理與自己有關的資料，如果需要關聯處理其他segment上的資料，segment可以通過interconnect進行資料的傳輸。segment節點越多，資料就會打的越散，處理速度就越快。是以與share all資料庫叢集不同，通過增加segment節點伺服器的數量，greenplum的性能會成線性增長。

　　圖3 segment負責業務資料的存取

每個segment的資料備援存放在另一個segment上，資料實時同步，當primary segment失效時，mirror segment将自動提供服務，當primary segment恢複正常後，可以很友善的使用gprecoverseg -f工具來同步資料。

interconnect

interconnect是greenplum架構中的網絡層（圖4），是gpdb系統的主要元件，預設情況下，使用udp協定，但是greenplum會對資料包進行校驗，是以可靠性等同于tcp，但是性能上會更好。在使用tcp協定的情況下，segment的執行個體不能超過1000，但是使用udp則沒有這個限制。

　　圖4 greenplum網絡層interconnectgreenplum，新的解決方案

前面介紹了gpdb的基本架構，讓讀者對gpdb有了初步的了解，下面對gpdb的部分特性描述可以很好的了解為什麼選擇gpdb作為新的解決方案。

豐富的工具包，運維從此不是事兒

對比開源社群的其他項目在運維上的困難，gpdb提供了豐富的管理工具，圖形化的web監控頁面，幫助管理者更好的管理叢集，監控叢集本身以及所在伺服器的運作狀況。

最近的公有雲叢集遷移過程中，impala總查詢段達到100的時候，系統開始變得極不穩定，後來在外援的幫助下發現是系統核心本身的問題，在惡補系統核心參數的同時，發現gpdb的工具也變相的填充了我們的短闆，比如提供了gpcheck和gpcheckperf等指令，用以檢測gpdb運作所需要的系統配置是否合理以及對相關硬體做性能測試，如下，執行gpcheck指令後，檢測sysctl.conf中參數的設定是否符合要求，如果對參數的含義感興趣，可以自行百度學習。

　　（點選可檢視高清版）

另外，在安裝過程中，用其提供的gpssh-exkeys指令打通所有機器免密登入後，可以很友善的使用gpassh指令對所有的機器批量操作，如下圖示範了在master主機上執行gpssh指令後，在叢集的五台機器上批量執行pwd指令。

諸如上述的工具gpdb還提供了很多，比如恢複segment節點的gprecoverseg指令，比如切換主備節點的gpactivatestandby指令，等等。這類工具的提供讓叢集的維護變得很簡單，當然我們也可以基于強大的工具包開發自己的管理背景，讓叢集的維護更加的傻瓜化。

查詢計劃和并行執行，sql優化利器

查詢計劃包括了一些傳統的操作，比如：掃表、關聯、聚合、排序等。另外，gpdb有一個特定的操作：移動（motion）。移動操作涉及到查詢處理期間在segment之間移動資料。

下面的sql是tpch中query 1的簡化版，用來簡單描述查詢計劃。

執行計劃執行從下至上，可以看到每個計劃節點操作的額外資訊。

segment節點掃描各自所存儲的customer表資料，按照過濾條件生成結果資料，并将自己生成的結果資料依次發送到其他segment。

每個segment上，orders表的資料和收到的rs做join，并把結果資料傳回給master

上面的執行過程可以看出，gpdb是将結果資料給每個含有orders表資料的節點都發了一份。為了最大限度的實作并行化處理，gpdb會将查詢計劃分成多個處理步驟。在查詢執行期間，分發到segment上的各部分會并行的執行一系列的處理工作，并且隻處理屬于自己部分的工作。重要的是，可以在同一個主機上啟動多個postgresql資料庫進行更多表的關聯以及更複雜的查詢操作，單台機器的性能得到更加充分的發揮。

如何檢視執行計劃？

如果一個查詢表現出很差的性能，可以通過檢視執行計劃找到可能的問題點。

計劃中是否有一個操作花費時間超長？

規劃期的評估是否接近實際情況？

選擇性強的條件是否較早出現？

規劃期是否選擇了最佳的關聯順序？

規劃其是否選擇性的掃描分區表？

規劃其是否合适的選擇了hash聚合與hash關聯操作？

高效的資料導入，批量不再是瓶頸

前面提到，greenplum的master節點隻負責用戶端互動和其他一些必要的控制，而不承擔任何的計算任務。在加載資料的時候，會先進行資料分布的處理工作，為每個表指定一個分發列，接下來，所有的節點同時讀取資料，根據標明的hash算法，将目前節點資料留下，其他資料通過interconnect傳輸到其他節點上去，保證了高性能的資料導入。通過結合外部表和gpfdist服務，gpdb可以做到每小時導入2tb資料，在不改變etl流程的情況下，可以從impala快速的導入計算好的資料為消費提供服務。

使用gpfdist的優勢在于其可以確定再度去外部表的檔案時，gpdb系統的所有segment可以完全被利用起來，但是需要確定所有segment主機可以具有通路gpfdist的網絡。

其他

gpdb支援ldap認證，這一特性的支援，讓我們可以把目前impala的角色權限控制無縫的遷移到gpdb。

gpdb基于postgresql 8.2開發，通過psql指令行工具可以通路gpdb資料庫的所有功能，另外支援jdbc、odbc等通路方式，産品接口層隻需要進行少量的适配即可使用gpdb提供服務。

gpdb支援基于資源隊列的管理，可以為不同類型工作負載建立資源獨立的隊列，并且有效的控制使用者的查詢以避免系統超負荷運作。比如，可以為vip使用者，etl生産，任性和adhoc等建立不同的資源隊列。同時，支援優先級的設定，在并發争用資源時，高優先級隊列的語句将可以獲得比低優先級資源隊列語句更多的資源。

最近在對gpdb做調研和測試，過程中用tpch做性能的測試，通過和網絡上其他服務的對比發現在5個節點的情況下已經有了很高的查詢速度，但是由于測試環境伺服器問題，具體的性能資料還要在接下來的新環境中得出，不過gpdb基于postgresql開發，天生支援豐富的統計函數，支援橫向的線性擴充，内部容錯機制，有很多功能強大的運維管理指令和代碼，相比impala而言，顯然在sql的支援、實時性和穩定性上更勝一籌。

本文隻是對greenplum的初窺，接下來更深入的剖析以及在工作中的實踐經驗分享也請關注da的wiki。更多的關于greenplum基本的文法和特性，也可以參考postgresql的官方文檔。

本文轉自d1net（轉載）