(轉)
近兩年，國內的大數據市場逐漸成熟，有真實的大數據處理需求的企業數量呈現爆炸性的增長，從傳統的數據庫產品往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的路途中，我們通過一點經驗介紹，希望讓大家少走彎路。在產品實施過程中的關鍵階段，還應該更多地尋求專業顧問的支持。