近兩年，國内的大資料市場逐漸成熟，有真實的大資料處理需求的企業數量呈現爆炸性的增長，從傳統的資料庫産品往mpp資料庫轉型的增長勢頭十分迅猛。greenplum作為mpp産品的領頭羊，具有較低的學習成本，得到了國内大量客戶的青睐。
目錄
gp實施之道
1、前期規劃的重要性
2、資料模型設計的重要性
日常運維最佳實踐
1、日常維護關注這些
2、重點說說系統表的維護
3、檢查工具
4、分析方法和處理技巧
第一篇 gp實施之道
國内的一位greenplum大拿（也是翻譯greenplum官方資料的第一人），曾經說過：學會用greenplum不難，但要用好greenplum就要下一番苦工。greenplum資料庫産品在中國一路走來，期間不乏負面聲音。除了競争對手的惡意中傷以外，所有問題的解決都是我們一點一滴經驗的積累，都是我們修煉之路上的寶貴财富。
1 前期規劃的重要性
我們在硬體配置方面曾吃過不少虧。早期不少案例都是去做實施時才感歎：“巧婦難為無米之炊”。總結出了好多寶貴的經驗。後來有人跟我說：為什麼沒有早點看到這篇文章！是以，早期做好架構規劃，做好選型是何等重要。
在硬體選型上，我們講究達到平衡。是要在性能、容量、成本等多個方面綜合考慮，取得平衡。不能一味追求容量而忽略了整體性能，忽略了日後維護和擴容的成本；也不能一味追求性能而忽略了成本，而讓采購部門望而卻步。
搭建greenplum叢集，首要考慮單個segment host上的執行個體個數，随着現在單台pc伺服器的處理能力不斷提升，規劃執行個體個數已經不能簡單的按照cpu核數來推算。單台伺服器的執行個體個數與資料庫的并發處理能力是成反比的。是以，規劃單台伺服器的執行個體個數需要綜合考慮伺服器配置、生産環境的運作負載壓力、跑批使用者和前段查詢使用者并發需求等各個方面。大多數場景下，4或6個為宜。
同樣，作為整體架構設計的重要組成部分，etl伺服器、監控管理，備份政策如何規劃，如何高效組網都得在前期考慮好。在我們的成功案例中，同一個企業級資料平台中greenplum叢集和hadoop叢集配合運作的案例越來越多。在中國移動的大資料架構規範中，雲化etl是一個重要的組成部分。雲化etl就是構架在hadoop叢集之上。greenplum提供了專用産品子產品gphdfs，greenplum通過gphdfs可以直接與hdfs上的資料進行互動，并且可以同時發揮greenplum和hadoop兩者并行處理的優勢。
2 資料模型設計的重要性
實施greenplum的項目，有的是從其他資料庫産品遷移過來的資料模型，有的是新設計的資料模型。無論是哪種情況，設計時請重點關注greenplum的特性，要充分發揮greenplum所長：
分布鍵：均勻為第一大原則，選取更有業務意義的字段，并非必須選擇原庫的主鍵（pk）。
壓縮表使用：大表都要采用壓縮存儲，既節省空間也節省io資源。長遠來看還可降低陣列卡和磁盤的故障率。
行存還是列存：列存儲有更高的壓縮率，合适于聚合運算，但不合适于寬表。一個資料庫中不應隻有一種存儲方式，每張表應依據實際情況設計存儲方式。
臨時表：對于程式中所使用到的臨時表和中間表，上述3點規則同樣适用。
分區：greenplum的分區原理與其他資料庫無異。表的子分區個數不宜過多，子分區粒度不易過細，子分區之間無需均勻。
索引：在greenplum中，可以使用索引但不能濫用。與oltp類型資料庫不同，greenplum在絕大部分關聯場景中不會用到索引。隻有部分小結果集的查詢場景中需要使用索引優化。
第二篇 日常運維最佳實踐
第一篇介紹了gp實施前重點應該關注前期規劃及模型設計，其實實施完運維更重要，切忌運而不維（隻讓其運作而不加以維護）！
想要一個資料庫長久健康的運作，離不開一個稱職的dba。
從其他資料庫的dba轉為greenplum的dba并不是一件很困難的事，成功轉成greenplum dba的工程師越來越多。
1 日常維護關注這些
現在企業客戶中搭建的greenplum叢集伺服器數量是越來越大，在電信行業和銀行業，搭建50台伺服器以上的greenplum叢集越來越多。而叢集伺服器數量越多也就代表故障發生率越高。作為greenplum的dba和運維人員，不單隻關注greenplum本身，還要關注叢集中各硬體的狀況，及時發現及時處理。硬碟狀态、陣列卡狀态、硬體告警、作業系統告警、空間使用率等都是應關注的重點。這些都可通過廠商提供的工具，編寫監控程式，snmp協定對接企業監控平台等手段提升日常巡檢和監控的效率。
針對greenplum，dba需要關注的重點：
（1）greenplum的狀态：standby master的同步狀态往往容易被忽略。通過監控平台或者腳本程式，能夠及時告警則最好。
（2）系統表：日常系統表維護（vacuum analyze），在系統投産時就應該配置好每天執行維護。
（3）統計資訊收集：統計資訊的準确性影響到運作效率，使用者表應該及時收集統計資訊。在應用程式中增加收集統計資訊的處理邏輯，通過腳本定時批量收集統計資訊，或者兩者相結合。針對分區表日常可按需收集子分區的統計資訊，可節省時間提升效率。
（4）表傾斜：表傾斜情況應該dba的關注點之一，但無需每天處理。
（5）表膨脹：基于postgresql的mvcc機制，表膨脹情況不能忽視。重點應該關注日常更新和删除操作的表。
（6）報錯資訊：在日志中錯誤資訊多種多樣，大部分不是dba需要關注的。應該重點關注panic、oom、internal error等關鍵資訊。
2 重點說說系統表的維護
greenplum與其他所有關系型資料庫一樣，擁有一套管理資料庫内部對象及關聯關系的中繼資料表，我們稱之為greenplum系統表。greenplum的産品核心是基于postgresql資料庫基礎上開發完成的，是以，greenplum系統表很多繼承于postgresql資料庫。
greenplum的系統表大緻可分為這幾類：
（1）資料庫内部對象的中繼資料，如：pg_database、pg_namespace、pg_class、pg_attribute、pg_type、pg_exttable等。
這類系統表既涵蓋了全局的對象定義，也涵蓋了每個資料庫内的各種對象定義。這類系統表的中繼資料不是分布式的存儲，而是每一個資料庫執行個體（不論是master執行個體還是segment執行個體）中都各有一份完整的中繼資料。但也有例外，如：gp_distribution_policy（分布鍵定義）表則隻在master上才有中繼資料。
對于這類系統表，各個執行個體之間中繼資料保持一緻十分重要。
（2）維護greenplum叢集狀态的中繼資料，如：gp_segment_configuration、gp_configuration_history、pg_stat_replication等。
這類系統表主要由master執行個體負責維護，就如segment執行個體狀态管理的兩張表gp_segment_configuration和gp_configuration_history的資料是由master的專用程序fts負責維護的。
（3）persistent table，如：gp_persistent_database_node、gp_persistent_filespace_node、gp_persistent_relation_node、gp_persistent_tablespace_node。
這類系統表同樣是存在于每一個資料庫執行個體中。在每個執行個體内，persistenttable與pg_class/pg_relation_node/pg_database等系統表有着嚴格的主外鍵關系。這類系統表也是primary執行個體與mirror執行個體之間實作同步的重要參考資料。
在greenplum叢集出現故障時，會有可能導緻系統表資料有問題。系統表出現問題會導緻很多種故障産生，如：某些資料庫對象不可用，執行個體恢複不成功，執行個體啟動不成功等。針對系統表相關的問題，我們應該結合各個執行個體的日志資訊，系統表的檢查結果一起定位問題，本文将介紹一些定位、分析及解決問題的方法和技巧。
3 檢查工具
greenplum提供了一個系統表檢查工具gpcheckcat。該工具在$gphome/bin/lib目錄下。該工具必須要在greenplum資料庫空閑的時候檢查才最準确。若在大量任務運作時，檢查結果将會受到幹擾，不利于定位問題。是以，在使用gpcheckcat前建議使用限制模式啟動資料庫，確定沒有其他應用任務幹擾。
4 分析方法和處理技巧
1、遇到臨時schema的問題，命名為pg_temp_xxxxx，可以直接删除。通過gpcheckcat檢查後，會自動生成對臨時schema的修複腳本。由于臨時schema的問題會幹擾檢查結果，是以，處理完後，需要再次用gpcheckcat檢查。
2、如遇個别表對象中繼資料不一緻的情況，通常隻會影響該對象的使用，不會影響到整個叢集。如果隻是個别執行個體中存在問題，可以通過utility模式連接配接到問題執行個體中處理。處理原則是盡量不要直接更改系統表的資料，而是采用資料庫的手段去解決，如：drop table/alter table等。
3、persistent table問題，這類問題往往比較棘手，影響也比較大。依據gpcheckcat的檢查結果，必須把persistent table以外的所有問題修複完之後，才可以着手處理persistent table的問題。
針對persistent table再展開講述幾種問題的處理技巧：
（1）報錯的segment執行個體日志中出現類似資訊
該錯誤可能會導緻執行個體啟動失敗，資料庫執行個體恢複失敗等情況。首先可在問題的執行個體（postgresql.conf）中設定參數gp_persistent_skip_free_list=true。讓出問題的執行個體先啟動起來。再進行gpcheckcat檢查。在gpcheckcat的結果中應該能找到類似的問題：
從上述檢查結果可以看出persistent table的部分資料和其他系統表對應關系不正确。處理方法就是要修複persistent table資料。
（2）報錯的執行個體日志中出現類似資訊
該問題可能會導緻執行個體啟動失敗。可在問題的執行個體（postgresql.conf）中設定參數gp_persistent_repair_global_sequence=true，便可修複相應問題，讓相應執行個體正常啟動。
（3）報錯的執行個體日志中出現類似資訊
該問題會出現在ao表中，表示個别執行個體上的資料檔案被損壞。問題可能會導緻程序panic，執行個體啟動失敗。首先可在問題的執行個體（postgresql.conf）中設定參數gp_crash_recovery_suppress_ao_eof=true。讓出問題的執行個體先啟動起來。再進行gpcheckcat檢查。确定問題所在并修複。而通常出問題的ao表已經損壞，建議rename或者删除。
（4）在gpcheckcat的檢查結果中如果出現如下資訊
檢查結果表明檔案系統中存在部分資料檔案在系統表中沒有對應的關系，也就是檔案系統中有多餘的資料檔案。這種情況不會影響greenplum叢集的正常運作，可以暫時忽略不處理。
修複persistent table表的問題，不可手工修改，隻能夠使用greenplum提供的修複工具gppersistentrebuild進行修複。工具提供了備份功能，在操作修複之前必須要執行備份操作。然後通過gppersistentrebuild，指定待修複的執行個體的contentid進行修複。
另外，如果primary執行個體與mirror執行個體之間是處于changetracking狀态。一旦primary執行個體進行了persistent table的修複操作，primary執行個體與mirror執行個體之間隻能執行全量恢複操作（gprecoverseg -f）。
上面所介紹的一些guc參數，都是在修複系統表過程中臨時增加的參數，待叢集恢複正常之後，請将所修改過的guc參數值恢複回原有預設狀态。
greenplum已經開源了，生态圈在迅速地壯大，greenplum的愛好者、擁護者人數也在不斷地壯大。在使用和探索greenplum的路途中，我們通過一點經驗介紹，希望讓大家少走彎路。在産品實施過程中的關鍵階段，還應該更多地尋求專業顧問的支援。
<b></b>
<b>本文來自雲栖社群合作夥伴"dbaplus"，原文釋出時間：2016-02-23</b>