972      阿裏雲  技術社區[雲棲]

Greenplum在企業生產中的最佳實踐（上）

本文章轉自Pivotal公眾號，在此感謝任振中和Pivotal公司的分享，希望對更多的朋友有幫助～

一、GP搭建過程當中硬件的選擇和部署建議

GP是一個分布式X86架構，是把多台X86服務器組合成一起做一個大的集群。相比傳統單機版的Oracle和MySQL，它的特點是使用比較多的服務器做海量數據處理。

一般在企業客戶中，把X86服務器采集過來後會做上機安裝，如果企業使用的集群規模比較大，比如國內客戶最大的有將近128個節點，數據量有1PB。在部署的時候，X86的服務器會非常多，有超過100台的服務器。為了保證它整個集群的高可用、性能，在部署的時候一般是需要跨多個機櫃。

1.服務器部署

（雙機櫃為一組的部署方式）

對於X86服務器上架之後，接下來就要把X86服務器組網。對於目前市麵上看到的2U的服務器，在一個機架裏一般都會部署兩個萬兆交換機。對於單台服務器來說，一塊網卡網口出來都會接入相應的交換機裏麵，那麼在主機X86服務器上一般會使用moved4，也就是雙active的方式做綁定。當任意的網絡故障，就是網口出現故障或者交換機出現故障的時候，都不會對集群的可用性造成影響。

另外，當集群規模比較大的時候，在接入組交換機端口可能是有限的，會把接入層的交換機接入到匯聚層，在匯聚層交換機接入的方式和底下的接入方式是比較像的。在接入層交換機上會分出兩個口，分別接入到上層的匯聚層交換機，匯聚層交換機之間也會采用跨設備鏈路聚合這種方式做綁定。這樣就保證了性能和可靠性。

在企業客戶現有的案例中，目前可以看到的交換機基本上都是支持雙active的綁定方式，一般要在交換機上簡單的把端口做一下設置就可以達到這種模式。

（單個機櫃的部署方式）

對於底下的數據節點，就GP數據庫來說，一般會做海量數據的處理和分析，因此數據節點往往需要承擔大量的數據存儲和計算。建議對於計算節點一般采用2U的服務器，可以采用24塊600GB或者900GB的SAS 10K或者15K轉的盤，根據企業中自己的實際數據去選用磁盤類型。

目前在國內客戶用900G的SAS盤居多一些，在一些電信行業，數據量往往比較大，也有一些客戶采用單塊2T的硬盤。一個機櫃裏麵也會放兩台萬兆交換機，用於內部的數據互聯，同時也會加一台千兆交換機，用於對於服務器進行管理。

在劃分網絡的時候，千兆和萬兆的交換機一般都會劃分成不同的網段。對於萬兆交換機的接入，一般采用雙active這種方式，隻給分配一個IP段就可以。

2.GP軟件部署

舉個例子，假如有兩個機櫃，每個機櫃上麵有六台X86服務器，在存放的時候，假如在第一台服務器上部署了四個primary實例，會把對應的mirror節點放在相鄰的服務器上。第二台primary備份實例就會放在第三台節點。那它就是采用這種輪訓打散的方式來做GP的高可用。當任意一台機器掛掉之後，都不會對GP的可用性產生很大的影響。但是帶來的問題是，GP在正常情況下，隻有primary對外提供服務，假如說這個機器掛掉之後，那它對應的mirror就全部切到另外一台服務器上。這樣對於MPP數據庫，相當於有一台機器要承擔比平時多兩倍的計算工作量。

由於MPP這樣的短板效應，尤其是在壓力比較大的時候，就會發現整個集群因為掛了一個節點，就會對整個集群性能下降40%到50%的影響，因為它受最慢的節點影響。其他節點都已經計算完了，但這個節點沒有計算完，它就受這個節點的影響。

另外還有一種方式，這個機器上有四個primary實例，可以把每一個primary實例打散在接下來的四個節點上，相當於每一個機器上隻放第一台機器的一個備份數據。這樣的好處在於，當這台機器掛了之後，相當於有四台機器分開承擔原來一台機器的工作點。整個集群的性能最多情況下相比原來，可能就下降了25%。但是對它來說，采用這種方式，在掛了一個節點之後，如果這四個機器裏麵再有任意一個節點掛掉，那整個集群就不可用了。就是在GP裏麵如果是主備數據同時掛掉，那整個集群就會報錯，我們發的所有SQL都會異常退出。

目前在一些大的銀行裏麵，尤其是當集群規模比較多的時候，一般都是采用group+spread的方式。但是在一些隻有十幾個節點的客戶裏麵，一般還是采用group的方式去做實例的規劃。

3.GP硬件選擇

剛剛講過，在X86服務器裏，一般企業客戶都會采用SAS盤或者SATA盤去做，因為容量會比較大。GP主要的場景是做海量數據的分析。一些電信客戶裏麵也會涉及到一些明細數據的查詢，比如說在某省的移動客戶，會涉及到用戶的一些詳單的查詢。因為在底層硬件上選用了SATA盤，即使用了24塊，它的IOPS還是比較低的，一般SATA盤的IOPS隻有100到200左右，當並發的分析，比如跑報表的分析應用和小的並發的查詢過來之後，就會發現對於用戶詳單查詢會有很大的影響。當時它做了很多的調優工作，包括底層用了GP的資源隊列，甚至還用了操作係統的Cgroup，對IO做了限製。但是效果都不太理想。因為Cgroup也是通用采樣的方式，在一個周期裏麵會控製IO使用。但是對於一些大的查詢，如果把IO占滿之後，還是會對整個集群使用造成比較大的影響。

硬件選擇--磁盤

底下這兩個就是SSD和SATA盤，在IOPS尤其是在小的IO上麵，SSD比SATA盤有非常大的優勢，一般情況下來看對於SSD的設備，它的IOPS往往是SATA盤的幾十倍甚至到一百倍，但是對於這樣一個大的IO查詢，比如像海量數據掃描來說，相比傳統的SATA盤並沒有非常大的提高。對這個數據來說SSD性能比較差，也是屬於比較老的SSD設備。

目前在企業裏看到的一般的SSD的吞吐能到600MB/s到900MB/s的速度，但是IOPS基本上在30萬左右。如果企業裏麵確實有對於小IO的高並發的查詢類的場景，建議在X86服務器裏采用SSD和SATA混搭的方式，然後在GP層麵真正在底層硬件上隔離物理資源。

有的客戶，比如某電信用戶，已經采購了這樣的設備，就想看看能不能在數倉係統裏把GP接入進來，當時遇到的情況是，因為GP在底層是使用的TCP/IP通信協議，所以即使有高速網絡互聯設備，要去接入的話，還需要用一層IPOIP的一些協議去做轉換。一方麵是會帶來一些性能的損耗，另外一方麵當時的測試也不是特別穩定，因為網卡驅動的問題，導致服務器經常宕機。所以說在GP裏麵一般都是根據具體的業務場景，主要的場景就是這種海量數據的大的順序IO的讀寫操作，一般是建議采用24塊盤的SAS盤或者SATA盤，做底層的存儲。對於有這種海量的小的並發查詢的時候，也可以采用SSD。

4.RAID的劃分與性能比較

在容量上來說，舉個例子，下圖是某銀行客戶當時做了非常詳細的RAID組的測試，這是在十塊SAS盤做了大的RAID5，另外一個是做了RAID10。RAID5和RAID10相比最大的優勢，一個是在容量方麵，因為RAID5假如有10塊900GB的盤，那隻需要丟掉一塊盤的容量，還有9T的空間。對於RAID10來說，基本上是需要丟掉一半的存儲空間。在具體的性能上來看具體的數據，在讀寫性能上正常情況下十塊盤讀寫數據RAID5都要好於RAID10。

RAID5 VS RAID10 順序IO測試對比

但是在真實的業務場景當中就會發現磁盤IO往往不會一直持續100%，繁忙程度不會到100%的程度，所以說根據在企業裏具體的觀察，跑真正的SQL查詢的時候，RAID5和RAID10並沒有非常大的明顯的差異。

在空間使用率上來說，在底下的磁盤空間，使用率占到70%之後再通過GP check做磁盤性能的檢測，就會發現它的性能大概下降了有20%左右，包括讀寫性能。這是因為在空間使用非常多之後，可能磁盤外側空間已經使用完，另外一方麵，在文件分配上麵也會有一些性能的損耗，所以說當你空間使用超過70%之後，對於數倉類的應用也會造成一些影響。所以建議企業客戶服務器磁盤空間不要超過70%，一方麵是從性能考慮，另外一方麵在查詢的時候，還會有一些中間的結果也會用一些臨時的空間。

二、在企業性能上來說

（1）RAID卡cache對性能的影響

對於做RAID之後，尤其是對企業的性能還是有非常大的影響的，因為RAID卡本身在數據寫入的時候，會先寫入到RAID卡的cache裏麵，後麵就是通過RAID卡硬件再把它刷到真正的底下的磁盤裏麵。如果沒有RAID卡cache的話，對不管是RAID5還是RAID10，對寫的性能都會造成比較大的影響。

比如一個客戶它的數據規模比較小，從兩個節點擴到四個節點，完成擴容之後發現機器數增加了，並且每個機器上的數據量減少了，但是性能還沒有之前兩個節點跑得好。原因在於他們新采購的機器沒有RAID卡cache，導致新的機器IO性能下降非常嚴重。因為這個就是MPP短板效應造成了整個集群的性能比較大的下降。

（2）異常情況下對性能的影響

對於RAID5和RAID10來說在壞掉一塊盤的情況下，由於在讀的時候，RAID5需要通過其他盤去重新構建數據，所以當壞掉一塊盤之後，RAID5比RAID10性能會下降非常多。對寫的性能也會有一些下降，但沒有讀的性能下降得厲害。

另外，比如壞了一塊盤，又拿了一塊新盤頂上去之後，在review的過程當中，對RAID5讀和寫的性能也會有一些比較大的影響。現在一般的RAID卡做得比較智能，前台有正常的IO操作，後台就會把review的操作暫停掉，等正常的IO下來之後，後台再做。但是對於RAID5和RAID10，以具體的測試情況，大的順序IO來說，RAID5的讀寫性能還是要好於RAID10，但在異常情況下，它的性能會掉得比較厲害。所以具體到企業客戶，還是根據這樣的場景去選擇RAID5和RAID10。

如果對性能包括容錯性要求比較高，不管在任何情況下都要對性能不會造成非常大的影響，這時候一般建議還是用RAID10；如果沒有這樣嚴格的要求，往往是從成本和容量、性能來考慮的話，在GP這邊還是推薦使用RAID5。目前國內客戶中，采用RAID5是最多的方式。

（3）從不同故障場景下比較性能影響

剛剛對於底層磁盤RAID5和RAID10的性能進行了比較，對於GP來說，具體可以看一下在不同的故障場景下，對性能到底有多大的影響。

RAID5 VS RAID10 故障場景下對GP性能的影響

這是在X86服務器上裝了四個實例。

第一

對於在cache失效的情況下，對於RAID10來說，它的性能大概隻有3%、4%的性能下降。但是對於一塊硬盤壞掉之後，因為它對讀的性能會有一些影響。當RAID10有一塊硬盤壞掉的話，它的性能大概下降了20%左右。對於RAID5來說，一塊盤壞掉之後，有這樣大量的IO讀寫的話，整個集群的性能將近下降了一倍還要多一點。

第二

在36個節點上有60萬張表，做的測試是分別模擬，先把mirror的事例給停掉，測了一下它的性能，隻是把mirror停掉的話，對性能影響基本上沒有太大的影響。但當一個節點掛掉之後，如果采用group這種方式，因為它的壓力完全會有另外一台機器去承擔。當這個集群本身的負載非常高的時候，就會看到整個集群的性能可能就要下降一半還要多一點。

第三

很多客戶認為在硬件異常的過程當中發現底下的數據節點不同步，要執行GPrecoverseg的話，還要跑作業。因為在做recoverseg時，底下的節點已經有一些問題了，那它在做同步時，本身也會有一些大的IO和資源的消耗，所以它對集群的性能會下降得比較多。因此在真實的生產環境裏麵，比如說節點掛掉之後，一般會建議客戶在有空閑的時間窗口，比如大的批量跑完之後，再去趕緊把GPrecoverseg做一下同步。因為GP底層是做的增量塊的複製，同步的速度還是比較快的。

第四

當有一個節點宕機之後，在跑的性能。整個建議是，在真實的業務場景中，RAID5在跑數倉類的場景裏麵，真實的業務IO不會一直持續100%，所以RAID5和RAID10對真實的業務影響並不是特別大。但是當硬件壞掉之後，RAID5的性能下降比較多，會對集群有比較大的影響。另外，係統空間使用盡量不要超過70%，超過70%之後也會有一些影響。

三、GP高可用原理

Greenplum數據同步原理

元數據和底下數據節點的安全性

對於GP元數據的同步，是采用了Postgres原生的流複製的方式，是強同步的方式，就是元數據這種變更的時候，一定是它這邊真正刷盤成功之後，才會認為寫入的動作成功。所以在元數據這塊，是能保證絕對的可靠性，假如master掛掉之後，那這個standby進程會讀Postgres進程，做回訪，應用到standby數據。當異常情況的時候，集群會重新拉起來的時候，也會用xlog做恢複，這樣就保證了元數據的安全和可靠。

對於底下節點來說，GP是采用自己的一套塊數據的複製方式，怎麼來理解呢？當有數據插入或者變更的時候，當這個數據要真正刷盤之前，在寫入磁盤之前，它會截獲到數據的變化，然後會把這個變化同樣是通過這個進程發到對應的mirror節點，mirror節點後台會有相應的consumer的進程，包括heap表，來做相應的寫盤動作。對於整個來說，隻有mirror節點，把這個數據寫成功之後，才會返回給primary節點，告訴它數據已經寫成功了，就是真正後台會有一個刷盤的動作。

在GP整個的數據庫裏麵，不管是從master節點還是底下的數據計算節點，是能保證數據的強一致性的。在任何情況下，比如機器突然掉電的情況下，不會出現切到mirror之後發現已經提交的事物丟失的情況。後麵具體講一下它後台的進程。

Greenplum主節點同步原理

這個就是說對於master和standby節點，當一個事物在提、把WAL刷盤的時候，它就會先把數據同步到standby節點，standby節點會寫到本地盤上，然後再返回，告訴它表示已經寫成功了，最後會傳達到客戶端請求已經成功，整個在元數據這塊是通過WAL的流複製保證數據的安全可靠。

對於底下的計算節點，同樣是當有大的數據插入或者更新來說，有一個WAL replication的進程，當這個數據要寫盤的過程當中，會根據AO表還是heap表，會從不同的buffer裏麵會納入到塊的變化。比如說要刷盤的時候，這個replication的進程會通過新的進程把數據通過TCP/IP這個協議發到mirror節點，mirror節點拿到這個數據之後，也會先把它放到它的內存裏麵，然後有相應的consumer進程把它寫到對應的底下的文件係統上，之後會有一個act進程，告訴primary節點，說數據已經寫入成功了，通過這樣的一個完整的鏈路，告訴primary節點，說這個時候也可以把事物提交，完成整個的動作。

Greenplum數據節點同步原理

它就是通過這種方式，類似管道的方式，在數據真正寫盤之前，在primary節點寫盤之前，就是通過這種強一致的刷盤的動作，不管是AO表還是heap表，都會通過強製的刷盤動作，保證數據的絕對安全、可靠，就是任何情況下機器斷電等等情況下都不會造成數據的丟失。這也是為什麼GP在金融客戶有非常非常多的應用案例的原因，就是它不管是從原數據還是底下的數據節點，都能保證數據的絕對的安全可靠。

底層的同步進程

它其實有三個最重要的進程：

1.一個是consumer進程

mirror consumer process主要負責xlog的寫入和控製文件，因為在寫入之後，比如做檢查點之後，會更新相應的控製文件。它主要是負責xlog的寫入。

2.一個是write process

負責heap表的寫入，對於heap表的寫入是通過xlog日誌，就是通過xlogdump提供的工具，當數據寫入之後，比如在heap表裏插入之後，會解析它後台到底是做了什麼樣的動作。解析後可以看到當有heap表插入時，會馬上在對應的mirror把WAL日誌寫到相應的磁盤上。對於底下來說，去跟蹤剛剛提到的heap表的consumer進程，真正的數據文件的寫入，在write的時候，底下並沒有看到有think的動作。因為write的時候，它隻是把數據從buffer裏寫到文件係統cache裏麵，並沒有確定數據一定是刷到磁盤上的。

對於heap表的寫入，隻是保證了xlog在mirror節點的寫入，但是對於真正的數據文件並不是一個強同步的過程。但是在做checkpoint時會發現heap表也會刷到這個磁盤上，但是通過這種方式已經能保證對於heap表的寫的操作一定是一致的，因為對於heap表的xlog已經寫到磁盤上，那就是掛掉之後，大不了再用xlog做一下恢複就可以了。這樣的話，對於heap表寫入操作完成之後，數據在mirror上絕對是不會丟掉的。

3.還有一個是appendonly process

負責AO表的寫入動作。AO表的插入跟heap表有不一樣的地方。因為在GP裏麵，AO是用了自己另外一套機製去實現的，所以它可以做壓縮等等。但是它裏麵對於appendonly表另外還有一些heap表作為輔助的數據字典，比如pg-fastsequence和aoseg，就是它上麵的一些索引和原數據的記錄信息。對於AO表的這些輔助的一些數據結構，在GP裏麵也是采用heap的存儲方式。

當在AO表裏麵去插入的時候，去跟蹤一下剛剛提到的xlog的寫入進程會發現它也會寫xlog日誌，但是它寫入的是AO表，就是appendonly表對應的heap的數據字典的一些信息，真正的數據是通過mirror consumer appendonly process去寫到磁盤上的。就是對於AO表的寫入，比heap表要稍微複雜一點，就是它在寫入的過程當中，同步是要包括一些xlog的一些寫入，同時也包括一些本身的數據寫入。

對於AO表來寫入的話，把AO表插入的時候不用做commit去跟一下進程，它在寫入的時候，把數據文件寫到文件係統cache之上，會馬上調一個fsync，這樣的話對於AO表的數據是會馬上寫到底下的磁盤上的。所以對於AO表來說，它也是通過自己內部的機製，保證了數據在寫入的過程當中是強同步的刷盤動作，保證了數據的可靠。

另外，對於剛剛提到的寫xlog的consumer進程，不管是對heap表還是AO表寫入，都會有相應的寫入，寫入之後緊接著會有一個fsync的動作。對於AO表的話，也是寫入之後馬上就會有一個fsync的動作。所以說對於GP來說，對於底層的數據存儲，不管是heap表還是AO表，通過xlog日誌和本身的appendonly表的寫入機製，保證了兩邊數據的絕對安全可靠。

四、企業客戶遇到各樣問題應如何分析

對於GP來說，一般遇到的問題歸納起來主要可以分為兩類。一類就是性能的下降，還有一類是異常情況。比如說在做一些操作報錯的情況。一般情況下在做問題定位分析，相比傳統的Oracle、MySQL的單機的數據庫來說，因為它的集群規模比較大，往往涉及到幾十甚至上百台規模，定位起來可能還是需要一些技巧。比如這個集群突然慢了，原來跑十幾分鍾的SQL，現在跑一個小時都還沒有結束。那這個時候怎麼去定位分析這個問題呢？

第一步就是首先要確認這個慢到底是慢在什麼地方，在檢查的時候，因為有的節點執行快的話，最後的進程的狀態是不一樣的。通過outSQL的視圖查看一下，看這個SQL還有哪個節點沒有執行結束，或者通過GPssh也可以跳到所有的節點上，去看一下它的負載，看一下它的連接狀態。就先定位到哪個也點慢了，影響到機器。

接下來可以看一下這個圖上的工具，基本上是自帶的一些工具，比如說通過vmstat看內存，通過top看進程，通過iostat看IO的，就是通過Linux係統的一些命令，再具體的去分析，這個進程hang是因為什麼，是不是底下硬件損壞導致性能下降，還是其他的一些情況導致的。

另外，比如跑了一段時間，發現跑所有的SQL都會有這樣的性能下降，在集群跑了一段時間之後，可以用GP自帶的一些工具，比如說GPcheckperf、GPcheckcat等工具檢查一下整個集群之間的性能，包括網絡、磁盤、IO等等，去定位是不是有硬件性能的下降。

最後更新：2017-08-13 22:52:17

  上一篇：  全文檢索 (不包含、不等於) 索引優化 - 阿裏雲RDS PostgreSQL最佳實踐

  下一篇：  每天萬億+級 實時分析、數據規整 - 阿裏雲HybridDB for PostgreSQL最佳實踐