詳解開源大數(shù)據(jù)引擎Greenplum的架構和技術特點

責任編輯:editor004

作者:周雷皓

2017-03-13 11:04:17

摘自:《程序員》

GPDB是典型的Master Slave架構,在Greenplum集群中,存在一個Master節(jié)點和多個Segment節(jié)點,其中每個節(jié)點上可以運行多個數(shù)據(jù)庫。

作者:周雷皓 ,百度外賣大數(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

鏈接已復制,快去分享吧

企業(yè)網(wǎng)版權所有?2010-2024 京ICP備09108050號-6京公網(wǎng)安備 11010502049343號