615
Greenplum在企業生產中的最佳實踐（下）
今天，我們將分享國內客戶在使用GP時遇到的問題及相關建議。同時，架構師就大家經常遇到的技術問題進行了細致的說明，相信對您有所啟迪！
第一個案例——底層數據文件報錯處理
在一個金融客戶的案例中發現RAID卡故障導致底層的數據文件損壞了。這是什麼意思呢？假如通過操作係統的命令找到這個文件，去cat這個文件或者去做這樣的一些操作的時候，是正常的，是沒有任何問題的。但是通過GP去查這個表的時候，就會報錯，說底下的數據文件有問題。這是因為這個數據塊有它自己的特殊的組織方式，會有一些校驗。當時認為既然這是因為有硬件問題導致的數據文件的損壞，那就強製地把這個primary切到mirror節點。切到mirror節點之後，查這個表同樣的報錯，這就比較奇怪。因為出故障的隻是primary節點，但切到mirror之後，同樣發現了問題。
後來分析到，是因為這個客戶數據量非常大，他在裏麵使用了heap表，heap表是原生的數據存儲方式。在GP裏麵，目前它對於heap表在讀寫或者同步的時候是沒有做校驗的。就是在一些極端異常的情況下，比如說底層的數據文件，比如RAID卡bug等等，數據寫到一半，導致塊損壞的情況下。假如去更新這個塊，塊上損壞了某一行記錄而更新的數據就是另外一行，那在更新完成之後，通過塊複製的方式，它就會把這個壞塊複製到對應的mirror節點上去。這個時候，因為它沒有這種文件校驗機製，所以切到mirror之後，對於heap表來說也是報錯，就是用之前的primary的壞塊把原來的數據庫給覆蓋掉了。所以這樣的話會導致數據的損壞。
另外，在GP即將發布的5.0的版本，也會對heap表做一些底層的改進。在這種極端異常的情況下，對於heap表，也不會說因為硬件的故障在寫入的時候，導致主備節點的數據同步，導致主備數據都損壞的情況。
第二個案例——網卡的自動降級
某一個地市銀行客戶，在集群空負載的情況下，因為磁盤損壞了，要換磁盤，把服務器停掉，把磁盤換上去之後，重啟集群，做同步。因為是空負載，這個階段沒有任何的數據寫入和數據變更，應該是很快可以完成的，但這個主備的數據同步花了將近兩個小時。
剛才提到對於數據文件在底下GP同步的時候，會通過實時的同步給同步過去，但是它底下還有一些xlog日誌文件等等，對這樣的一些日誌每次做同步的時候，都會用primary全部覆蓋到mirror節點。這是因為這個客戶同樣是使用了大量的heap表，導致xlog非常龐大，在這個節點起來之後，由於網絡配置的是千兆網絡，自動的把千兆網絡降成百兆了，兩台機器同步的帶寬大概隻有10MB/s的帶寬， xlog又非常大，所以導致主備同步花了非常長的時間。同步完成之後，後麵要跑業務，因為本身帶寬已經下降了將近10倍左右，所以對整個業務造成了非常大的影響。
第三個案例——恢複硬件故障的性能
某省移動客戶出現了一種情況，它底下的硬盤雖然有了一些壞塊，但它在寫入時，在RAID卡控製器層麵並沒有真正把磁盤標記出來，直接把壞的部分offline掉，然後再做rebuild。因為它磁盤本身會有一些容錯機製，它會不斷地嚐試去讀取數據。雖然硬盤有一些壞塊，但是硬件層麵並沒有徹底的把它隔離。硬盤處於將壞不壞之間，對整個集群的性能造成了非常大的影響 。
對於GP來說，企業客戶遇到80%、90%的問題往往都是硬件故障或者操作不當，使用表設計不當造成的影響。所以在整個集群規劃部署，包括使用的過程當中，一般還是要盡量遵循最佳的實踐，包括在搭建的時候，磁盤的選擇、RAID的做法以及底下的primary的放置，還有定期做一些備份的動作，對於這種異常情況，我們就可以通過剛剛提到的GP自帶的一些工具，還有Linux的一些命令去定位一些比較難定位的問題。
-- Q&A --
1.Greenplum使用外部存儲的多嗎？
GP一般建議還是使用本地的X86自帶的SAS盤做數據的存放，我們在一些金融客戶裏麵也有比如他用SAN存儲做的GP數據的存放，但是它之間的網絡帶寬一般都會用光纖網絡去接入到GP的X86服務器，也有這種案例。但是真實生產裏麵用的比較少，因為SAN存儲，首先是成本比較高。另外，它對整個網絡拓撲也會要求比較高一些。另外，當性能不太好的時候，擴容也會帶來一些問題。因為GP本身從嚴格意義來講，就和我們這種Hadoop方式不太一樣，還是一種比較集約型的管理方式，數據打散在本地的X86服務器，這樣在後續計算的時候，能用到很多之前已經預設好的優化的方式，來提升性能。
你用外部存儲的話，相當於它很多的優化的方案，實際內部做的優化已經用不到了。但是對於一些目前包括阿裏雲等雲上的客戶，因為外部的存儲越來越多，我們現在在雲上也有一些基於GP的使用案例。
2.對於Greenplum這種master節點有standby的架構，如何保證它的高可用？
對於GP來說，當master節點掛掉之後，切換動作雖然非常快，但是還是需要人工去做這樣的觸發的動作。我們在真實的企業裏麵，建議切換master的時候，一般情況下還是要看一下，你要確定一下元數據有沒有同步。另外，要看一下是什麼故障導致的，要簡單的分析一下。另外，你做成這種全自動的方式是很容易的，自動化腳本切換是很容易的，但是前麵還是有一些判斷的動作，我們也有客戶把這個判斷和切換的邏輯封裝在一起，做成自動化腳本的 。
3.GP有沒有比較自動化的日誌分析功能？
因為GP主要還是做一個結構化的數據處理，目前我們有一個GP text組件，是可以直接部署在GP上麵，底層是做非結構化的數據的處理，如果有這種日誌分析的話，可以嚐試一下GP text組件。
4.GP如何管理非結構化數據？
對GP來說，主要還是處理結構化數據，因為GP在底層存儲，還是通過表這種方式，雖然現在已經支持了一些XML等半結構化的數據，但是在真實的企業裏麵做分析的時候，比如做一些圖像的處理，完全的非結構化數據處理的話，我們往往還是需要通過轉換，比如把二進製的數據轉化成結構化數據存儲到GP裏麵，然後通過並行的方式做分析。因為導出的話，還是需要非結構化數據。所以要再把它轉化成非結構化數據，因為GP裏麵支持非常多的函數，包括C等語言，我們都可以靈活的去自定義這樣的一些函數，去做一些非結構化的數據的處理。但是總的來說，它在處理非結構化數據的話，還是要做一些轉化，轉化成結構化數據再做處理。
5.另外一個問題，剛剛提到某一個客戶那邊在機器重啟之後，帶寬自動降級的情況。
說實話，我們當時沒有仔細排查這個原因，因為帶寬一般是在交換機和主機層麵有一個協商，協商一個帶寬。我們當時沒有具體排查原因，最後我們在操作係統層麵把帶寬強製成千兆了。一般我們在企業部署的話，比如在交換機、主機，禁止帶寬協商，讓它強製成我們標準化最大的帶寬，避免這種問題。
6.使用本地盤做RAID，是基於成本考慮還是其他原因？
我們這邊RAID一個是成本，一個是從性能上說，因為目前X86服務器配24塊盤已經是市麵上比較常見的了，單台X86服務器有機是在順序IO上，整個順序的吞吐並不比SSD或者SAN存儲差很多，就是說機器多了之後，並不會有很大的差異。對於標準化的X86服務器來說，我們一般還是建議用本地盤做RAID，它不同於Hadoop這種方式，因為Hadoop目前能夠在塊級別設備份的副本數。對GP來說，在軟件層麵是支持一副本，底層還需要通過RAID這種方式在硬件層麵也做一份高可用，實際上來說，它的數據可靠性相比於Hadoop 3副本來說還是高的。
7.GP單節點的數據量有建議上限嗎？一般不超過多少？
單節點的數據量是沒有上限的，因為我們GP一般建議底下的文件係統是使用XfS文件係統，而XfS文件係統對單個文件就受限於本身文件係統的限製，因為XfSP本身對單個文件的支持是非常大的，並且支持的數目也是非常多的。所以說對單節點的數據量是沒有限製的，受限於文件係統本身，還有本身這個盤的大小的影響。
我們的建議是，在空間使用，就是在真實生產上布的話，不要超過70%，超過70%當然也可以正常去跑，但是當空間再多的時候，比如說大的文件內存不夠，這時候可能會對機器的性能或者軟件正常運行造成一些影響。所以一般的情況是，單節點的數據量是受限於本身的硬件。
8.GP在哪個數量級別以上會有明顯性能下降？
GP在底下的數據容量上，不管是TB、PB、ZB，在數據容量上是看不出來的，因為說到底就是用底層的物理資源，比如IO、吞吐、CPU、內存去做相應的計算，但是對於GP這樣一種MP的架構來說，一般情況下對大的查詢來說，會發到所有的節點去執行。對於集群的規模，還會有一些影響。
GP建議我們在實驗室環境下，MPP這種架構節點數盡量還是不要超過一千個節點，因為一千個節點之後，在網絡的交互和通信方麵都會有一些影響。雖然GP內部已經有UDPFC協議，已經對協議層做了一些改進，但是當集群規模非常大了之後，對於這種短的查詢、小查詢，數據量不是特別多的查詢，還會有一些影響。對於底層數據量的話，是沒有明顯影響的。
我們國內客戶超過PB級別，就是壓縮之後整個數據量已經超過PB級別，壓縮之前GP一般在銀行的壓縮級別可能是3到5左右，在電信那邊可能也有3左右。真實的數據量可能已經到3、4PB左右了。
9.GP與HAWQ應用場景有什麼不同？
現在來說，HAWQ也是我們公司的另外一個基於Hadoop的原生的SQL引擎。簡單來說，目前HAWQ能做的事情GP都可以做，但是HAWQ不能做的事情GP也能做。因為它底基層是基於HDFS，上麵包括表的update、索引目前還不支持，在GP裏麵如果有索引查詢，還有一些數據更新的場景的話，對於GP來說還是比較合適的。
HAWQ一個典型的應用場景就是，如果你已經有了一個Hadoop集群，上麵也存了很多數據，想用它做一些原生的分析的話，我們用HAWQ還是比較方便的。因為HAWQ和GP架構不太一樣，就是我們2.0做的最大的變化，它在底層起計算實例的話，對GP來說，比如一個大的SQL放下來，所有的postgre實例都會起來做相應的計算。但對HAWQ來說，它會根據你底下真正的數據塊的規模和分布情況，就是它能比較靈活的來起相應的計算的節點去做計算。所以說對於這種雲計算和Hadoop這樣的故障率比較高的場景來說，使用HAWQ是比較合適的。
GP對HAWQ也真實測試過，比如都采用相同的分布件，對這種大的查詢來說，因為HAWQ底層是基於HDFS，所以性能可能要比GP有將近20%的性能損耗。但是相比其他的Hadoop上的引擎，HAWQ是GP做了十幾年的並行引擎，直接放在上麵也做了很多優化，它的性能還是非常強的，並且在SQL支持層麵應該是目前最好的。
10.HAWQ會替代GP嗎?
我個人感覺未來的雲化的數據，包括存儲與計算分離，是一個方向。但是目前很多SQL Hadoop引擎打著要替換MPP的宣傳標語去做這樣的一些事情，但是目前來說，我剛剛提到的，比如在功能性上，包括在性能上的一些限製，目前來說它還是沒有辦法去替代的。未來如果是在雲上的話，我們選擇HAWQ也是一個非常不錯的方案。
11.Greenplum與Hadoop有什麼區別？應用場景各有所長嗎？
這個就是剛剛提到的，GP的這種MPP架構之前的數據存放相當於已經對數據做了一些預設置，比如數據怎麼分布、數據模型等等方麵已經幫你提前做了一些規劃，所以它之後再做一些查詢的時候，能用到之前的這些設計，所以在性能上比傳統的Hadoop上跑SQL的引擎，性能上會有非常大的明顯的性能的提升。這個隻是SQL類的。
但是對於一些非結構化的數據，剛剛也提到，因為Hadoop底層就是一個分布式的文件係統，你如果有一些非結構化的數據，使用Hadoop還是非常適合的。
另外，Hadoop是可以到非常大的規模，就是Hadoop可以到五千個節點，以阿裏舉例，飛天已經到五千個規模。這樣從原理上來說，Hadoop比如在做一些請求的做，可以采用HAWQ類似的架構，你雖然五千個節點，但是我在跑SQL的時候，我可以根據具體的情況，可以在裏麵隻用三四個節點做計算。真正的數據交互並不是說我一個SQL下去，五千個節點都要做這樣的數據交互。所以說對於MPP和Hadoop來說，這個集群規模本身的設計，MPP包括GP的規模，應該還是達不到Hadoop這樣的規模。但是從它的執行效率，包括在數據倉庫裏麵的一些使用場景做一些分析計算來說，GP比Hadoop還是有非常強的、明顯的優勢。
12.SAN網的速度應該沒問題吧？
這個就看你具體的網絡部署。我們當時在最開始平安銀行有一套GP集群，就是基於SAN網絡，也跑了很長的時間，這是完全沒有問題的。還要看你底下SAN采用什麼存儲，你接入GP的時候的網絡，還受限於硬件的拓撲。但是你使用SAN的話，本身GP做的一些優化實際上是用不到的。
13.一般X86服務器最多插多少塊盤？
目前我們市麵上看到的比較多的是24塊盤，就是數據盤是24塊盤。前麵前置的可能會有兩塊SSD的做RAID1，放操作係統。這是市麵上我們見的比較多的24塊盤2U的機器。如果采用4U的機器的話，盤數還會更多。
但現在本身RAID卡的接口帶寬有些限製，盤多的話可能會達到RAID卡的性能的瓶頸。假如24塊盤，底下都是用SSD，在這種情況下有可能達到RAID卡的性能瓶頸，導致IO上不去。即使磁盤性能很強，對於MPP這種架構經常會有數據跨網絡之間的交互，即使IO能力很強，但網絡比如隻有一萬兆的帶寬，也會受限於網絡的帶寬。所以說在整個集群搭建和服務器選型的時候，我們往往會是一個綜合的考慮，就是IO和網絡之間達到一個均衡的狀態。
14.如果在私有雲上部署GP性能較物理機會明顯下降嗎？
還是要提到受限於本身這個雲上的磁盤，還有這之間的網絡，包括硬件設備的影響。我們在真實的企業客戶裏麵，比如我們在國泰航空裏麵，他們做了一層虛擬化去做相應的GP的部署，就是生產環境上也是采用私有雲做了部署。
當時我們具體測試下來的結果就是，在IO層麵會有一些性能損耗，但是對整個集群的使用影響也不大，大概下降了10%到20%。
15.GP搭建大數據集成平台的時候要注意什麼？
第一，硬件選型要均衡，不能有明顯的性能短板。
第二，數據容量和未來業務的發展要提前規劃好。因為存儲層麵、容量層麵是最容易規劃的，這個定了之後，可以選擇你采用胖機器還是瘦機器。胖機器就是比如單台機器配置非常高，比如可以有1TB的內存，24塊1.8T或者2TB的盤。
對於GP來說，一般情況下如果能用小的規模，就是可以用小的胖機器能滿足你業務要求的話，還是盡量選擇胖機器，因為胖機器本身規模大了之後，硬件出故障的概率還是比較高的。所以說對於選型的時候，大數據平台搭建的時候，我們主要還是從業務和未來性能和空間的規劃來考量具體怎麼去選硬件、怎麼去做部署。
16.GP什麼時候用heap表，什麼時候用AO表？
目前對GP來說我們的建議是，一個總的原則是，能用AO表的就盡量用AO表，不能用AO表的時候你再用heap表。因為之前對GP來說，在4.2之前的版本，appendonly表因為本身做壓縮、做一些東西的時候，是不能做update、delate，目前GP AO表已經能做了。因為AO表我們剛剛也提到，在底層的數據校驗，包括在寫AO表的時候，寫的WAL日誌都非常少，你寫heap表的話，除了寫本身的數據文件還要寫大量的日誌文件，並且heap表不能壓縮。
一個總的原則，能用AO表的就盡量用AO表。那heap表什麼時候用呢？因為在heap表上可以建主鍵索引，現在目前AO表還不支持，如果有主鍵這種約束的情況下，我們還可以使用heap表。
最後更新：2017-08-13 22:40:05