作者：周雷皓 ，百度外賣大數(shù)據(jù)工程師。

來自：《程序員》3月技術板原創(chuàng)投稿。

摘要：本文介紹了大數(shù)據(jù)引擎Greenplum的架構和部分技術特點，從GPDB基本背景開始，在架構的層面上講解GPDB系統(tǒng)內部各個模塊的概貌，然后圍繞GPDB的自身特性，并行執(zhí)行和運維等技術細節(jié)，闡述了為什么選擇使用Greenplum作為下一代的查詢引擎解決方案。

Greenplum的MPP架構

Greenplum（以下簡稱GPDB）是一款開源數(shù)據(jù)倉庫。基于開源的PostgreSQL改造，主要用來處理大規(guī)模數(shù)據(jù)分析任務，相比Hadoop，Greenplum更適合做大數(shù)據(jù)的存儲、計算和分析引擎。

GPDB是典型的Master/Slave架構，在Greenplum集群中，存在一個Master節(jié)點和多個Segment節(jié)點，其中每個節(jié)點上可以運行多個數(shù)據(jù)庫。Greenplum采用shared nothing架構（MPP）。典型的Shared Nothing系統(tǒng)會集數(shù)據(jù)庫、內存Cache等存儲狀態(tài)的信息；而不在節(jié)點上保存狀態(tài)的信息。節(jié)點之間的信息交互都是通過節(jié)點互聯(lián)網(wǎng)絡實現(xiàn)。通過將數(shù)據(jù)分布到多個節(jié)點上來實現(xiàn)規(guī)模數(shù)據(jù)的存儲，通過并行查詢處理來提高查詢性能。每個節(jié)點僅查詢自己的數(shù)據(jù)。所得到的結果再經(jīng)過主節(jié)點處理得到最終結果。通過增加節(jié)點數(shù)目達到系統(tǒng)線性擴展。

　　圖1 GPDB的基本架構

如上圖1為GPDB的基本架構，客戶端通過網(wǎng)絡連接到gpdb，其中Master Host是GP的主節(jié)點（客戶端的接入點），Segment Host是子節(jié)點（連接并提交SQL語句的接口），主節(jié)點是不存儲用戶數(shù)據(jù)的，子節(jié)點存儲數(shù)據(jù)并負責SQL查詢，主節(jié)點負責相應客戶端請求并將請求的SQL語句進行轉換，轉換之后調度后臺的子節(jié)點進行查詢，并將查詢結果返回客戶端。

Greenplum Master

Master只存儲系統(tǒng)元數(shù)據(jù)，業(yè)務數(shù)據(jù)全部分布在Segments上。其作為整個數(shù)據(jù)庫系統(tǒng)的入口，負責建立與客戶端的連接，SQL的解析并形成執(zhí)行計劃，分發(fā)任務給Segment實例，并且收集Segment的執(zhí)行結果。正因為Master不負責計算，所以Master不會成為系統(tǒng)的瓶頸。

Master節(jié)點的高可用（圖2），類似于Hadoop的NameNode HA，如下圖，Standby Master通過synchronization process，保持與Primary Master的catalog和事務日志一致，當Primary Master出現(xiàn)故障時，Standby Master承擔Master的全部工作。

　　圖2 Master節(jié)點的高可用Segments

Greenplum中可以存在多個Segment，Segment主要負責業(yè)務數(shù)據(jù)的存儲和存?。▓D3），用戶查詢SQL的執(zhí)行，每個Segment存放一部分用戶數(shù)據(jù)，但是用戶不能直接訪問Segment，所有對Segment的訪問都必須經(jīng)過Master。進行數(shù)據(jù)訪問時，所有的Segment先并行處理與自己有關的數(shù)據(jù)，如果需要關聯(lián)處理其他Segment上的數(shù)據(jù)，Segment可以通過Interconnect進行數(shù)據(jù)的傳輸。Segment節(jié)點越多，數(shù)據(jù)就會打的越散，處理速度就越快。因此與Share All數(shù)據(jù)庫集群不同，通過增加Segment節(jié)點服務器的數(shù)量，Greenplum的性能會成線性增長。

　　圖3 Segment負責業(yè)務數(shù)據(jù)的存取

每個Segment的數(shù)據(jù)冗余存放在另一個Segment上，數(shù)據(jù)實時同步，當Primary Segment失效時，Mirror Segment將自動提供服務，當Primary Segment恢復正常后，可以很方便的使用gprecoverseg -F工具來同步數(shù)據(jù)。

Interconnect

Interconnect是Greenplum架構中的網(wǎng)絡層（圖4），是GPDB系統(tǒng)的主要組件，默認情況下，使用UDP協(xié)議，但是Greenplum會對數(shù)據(jù)包進行校驗，因此可靠性等同于TCP，但是性能上會更好。在使用TCP協(xié)議的情況下，Segment的實例不能超過1000，但是使用UDP則沒有這個限制。

　　圖4 Greenplum網(wǎng)絡層InterconnectGreenplum，新的解決方案

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

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

對比開源社區(qū)的其他項目在運維上的困難，GPDB提供了豐富的管理工具，圖形化的web監(jiān)控頁面，幫助管理員更好的管理集群，監(jiān)控集群本身以及所在服務器的運行狀況。

最近的公有云集群遷移過程中，impala總查詢段達到100的時候，系統(tǒng)開始變得極不穩(wěn)定，后來在外援的幫助下發(fā)現(xiàn)是系統(tǒng)內核本身的問題，在惡補系統(tǒng)內核參數(shù)的同時，發(fā)現(xiàn)GPDB的工具也變相的填充了我們的短板，比如提供了gpcheck和gpcheckperf等命令，用以檢測GPDB運行所需要的系統(tǒng)配置是否合理以及對相關硬件做性能測試，如下，執(zhí)行gpcheck命令后，檢測sysctl.conf中參數(shù)的設置是否符合要求，如果對參數(shù)的含義感興趣，可以自行百度學習。

　　（點擊可查看高清版）

另外，在安裝過程中，用其提供的gpssh-exkeys命令打通所有機器免密登錄后，可以很方便的使用gpassh命令對所有的機器批量操作，如下圖演示了在master主機上執(zhí)行gpssh命令后，在集群的五臺機器上批量執(zhí)行pwd命令。

　?。c擊可查看高清版）

諸如上述的工具GPDB還提供了很多，比如恢復segment節(jié)點的gprecoverseg命令，比如切換主備節(jié)點的gpactivatestandby命令，等等。這類工具的提供讓集群的維護變得很簡單，當然我們也可以基于強大的工具包開發(fā)自己的管理后臺，讓集群的維護更加的傻瓜化。

查詢計劃和并行執(zhí)行，SQL優(yōu)化利器

查詢計劃包括了一些傳統(tǒng)的操作，比如：掃表、關聯(lián)、聚合、排序等。另外，GPDB有一個特定的操作：移動（motion）。移動操作涉及到查詢處理期間在Segment之間移動數(shù)據(jù)。

下面的SQL是TPCH中Query 1的簡化版，用來簡單描述查詢計劃。

　　（點擊可查看高清版）

執(zhí)行計劃執(zhí)行從下至上，可以看到每個計劃節(jié)點操作的額外信息。

Segment節(jié)點掃描各自所存儲的customer表數(shù)據(jù)，按照過濾條件生成結果數(shù)據(jù)，并將自己生成的結果數(shù)據(jù)依次發(fā)送到其他Segment。

每個Segment上，orders表的數(shù)據(jù)和收到的rs做join，并把結果數(shù)據(jù)返回給master

上面的執(zhí)行過程可以看出，GPDB是將結果數(shù)據(jù)給每個含有orders表數(shù)據(jù)的節(jié)點都發(fā)了一份。為了最大限度的實現(xiàn)并行化處理，GPDB會將查詢計劃分成多個處理步驟。在查詢執(zhí)行期間，分發(fā)到Segment上的各部分會并行的執(zhí)行一系列的處理工作，并且只處理屬于自己部分的工作。重要的是，可以在同一個主機上啟動多個postgresql數(shù)據(jù)庫進行更多表的關聯(lián)以及更復雜的查詢操作，單臺機器的性能得到更加充分的發(fā)揮。

如何查看執(zhí)行計劃？

如果一個查詢表現(xiàn)出很差的性能，可以通過查看執(zhí)行計劃找到可能的問題點。

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

規(guī)劃期的評估是否接近實際情況？

選擇性強的條件是否較早出現(xiàn)？

規(guī)劃期是否選擇了最佳的關聯(lián)順序？

規(guī)劃其是否選擇性的掃描分區(qū)表？

規(guī)劃其是否合適的選擇了Hash聚合與Hash關聯(lián)操作？

高效的數(shù)據(jù)導入，批量不再是瓶頸

前面提到，Greenplum的Master節(jié)點只負責客戶端交互和其他一些必要的控制，而不承擔任何的計算任務。在加載數(shù)據(jù)的時候，會先進行數(shù)據(jù)分布的處理工作，為每個表指定一個分發(fā)列，接下來，所有的節(jié)點同時讀取數(shù)據(jù)，根據(jù)選定的Hash算法，將當前節(jié)點數(shù)據(jù)留下，其他數(shù)據(jù)通過interconnect傳輸?shù)狡渌?jié)點上去，保證了高性能的數(shù)據(jù)導入。通過結合外部表和gpfdist服務，GPDB可以做到每小時導入2TB數(shù)據(jù)，在不改變ETL流程的情況下，可以從impala快速的導入計算好的數(shù)據(jù)為消費提供服務。

使用gpfdist的優(yōu)勢在于其可以確保再度去外部表的文件時，GPDB系統(tǒng)的所有Segment可以完全被利用起來，但是需要確保所有Segment主機可以具有訪問gpfdist的網(wǎng)絡。

其他

GPDB支持LDAP認證，這一特性的支持，讓我們可以把目前Impala的角色權限控制無縫的遷移到GPDB。

GPDB基于Postgresql 8.2開發(fā)，通過psql命令行工具可以訪問GPDB數(shù)據(jù)庫的所有功能，另外支持JDBC、ODBC等訪問方式，產品接口層只需要進行少量的適配即可使用GPDB提供服務。

GPDB支持基于資源隊列的管理，可以為不同類型工作負載創(chuàng)建資源獨立的隊列，并且有效的控制用戶的查詢以避免系統(tǒng)超負荷運行。比如，可以為VIP用戶，ETL生產，任性和adhoc等創(chuàng)建不同的資源隊列。同時，支持優(yōu)先級的設置，在并發(fā)爭用資源時，高優(yōu)先級隊列的語句將可以獲得比低優(yōu)先級資源隊列語句更多的資源。

最近在對GPDB做調研和測試，過程中用TPCH做性能的測試，通過和網(wǎng)絡上其他服務的對比發(fā)現(xiàn)在5個節(jié)點的情況下已經(jīng)有了很高的查詢速度，但是由于測試環(huán)境服務器問題，具體的性能數(shù)據(jù)還要在接下來的新環(huán)境中得出，不過GPDB基于postgresql開發(fā)，天生支持豐富的統(tǒng)計函數(shù)，支持橫向的線性擴展，內部容錯機制，有很多功能強大的運維管理命令和代碼，相比impala而言，顯然在SQL的支持、實時性和穩(wěn)定性上更勝一籌。

本文只是對Greenplum的初窺，接下來更深入的剖析以及在工作中的實踐經(jīng)驗分享也請關注DA的wiki。更多的關于Greenplum基本的語法和特性，也可以參考PostgreSQL的官方文檔。

本文參考：Pivotal Greenplum Database 4.3.9.1 Documentation