詳解開源大資料引擎Greenplum的架構和技術特點
本文介紹了大資料引擎Greenplum的架構和部分技術特點。從GPDB基本背景開始，在架構的層面上講解GPDB系統內部各個模組的概貌，然後圍繞GPDB的自身特性、並行執行和運維等技術細節，闡述了為什麼選擇Greenplum作為下一代的查詢引擎解決方案。
Greenplum的MPP架構
Greenplum（以下簡稱GPDB）是一款開源資料倉庫，基於開源的PostgreSQL改造而來，主要用來處理大規模資料分析任務。相比Hadoop，Greenplum更適合做大資料的儲存、計算和分析引擎。
GPDB是典型的Master/Slave架構，在Greenplum叢集中，存在一個Master節點和多個Segment節點，每個節點上可以執行多個數據庫。Greenplum採用shared nothing架構（MPP），典型的Shared Nothing系統彙集了資料庫、記憶體Cache等儲存狀態的資訊，不在節點上儲存狀態的資訊。節點之間的資訊互動都是通過節點網際網路絡實現的。通過將資料分佈到多個節點上來實現規模資料的儲存，再通過並行查詢處理來提高查詢效能。每個節點僅查詢自己的資料，所得到的結果再經過主節點處理得到最終結果。通過增加節點數目達到系統線性擴充套件。
圖1為GPDB的基本架構，客戶端通過網路連線到gpdb，其中Master Host是GP的主節點（客戶端的接入點），Segment Host是子節點（連線並提交SQL語句的介面），主節點不儲存使用者資料，子節點儲存資料並負責SQL查詢，主節點負責相應客戶端請求並將請求的SQL語句進行轉換，轉換之後排程後臺的子節點進行查詢，並將查詢結果返回客戶端。
Greenplum Master
Master只儲存系統元資料，業務資料全部分佈在Segments上。其作為整個資料庫系統的入口，負責建立與客戶端的連線，SQL的解析並形成執行計劃，分發任務給Segment例項，並且收集Segment的執行結果。正因為Master不負責計算，所以Master不會成為系統的瓶頸。
Master節點的高可用類似Hadoop的NameNode HA，如圖2，Standby Master通過synchronization process，保持與Primary Master的catalog和事務日誌一致，當Primary Master出現故障時，Standby Master承擔Master的全部工作。
Segments
Greenplum中可以存在多個Segment，Segment主要負責業務資料的儲存和存取（圖3），使用者查詢SQL的執行時，每個Segment會存放一部分使用者資料，但是使用者不能直接訪問Segment，所有對Segment的訪問都必須經過Master。進行資料訪問時，所有的Segment先並行處理與自己有關的資料，如果需要關聯處理其他Segment上的資料，Segment可以通過Interconnect進行資料的傳輸。Segment節點越多，資料就會打的越散，處理速度就越快。因此與Share All資料庫叢集不同，通過增加Segment節點伺服器的數量，Greenplum的效能會成線性增長。
每個Segment的資料冗餘存放在另一個Segment上，資料實時同步，當Primary Segment失效時，Mirror Segment將自動提供服務。當Primary Segment恢復正常後，可以很方便地使用gprecoverseg -F工具來同步資料。
Interconnect
Interconnect是Greenplum架構中的網路層（圖4），也是GPDB系統的主要元件，它預設使用UDP協議，但是Greenplum會對資料包進行校驗，因此可靠性等同於TCP，但是效能上會更好。在使用TCP協議的情況下，Segment的例項不能超過1000，但是使用UDP則沒有這個限制。
Greenplum，新的解決方案
前面介紹了GPDB的基本架構，讓讀者對GPDB有了初步瞭解。下面對GPDB的部分特性進行了描述，可以很好地理解為什麼選擇GPDB作為新的解決方案。
豐富的工具包，運維從此不是事兒
對比開源社群中其他專案在運維上面臨的困難，GPDB提供了豐富的管理工具和圖形化的web監控頁面，幫助管理員更好地管理叢集，監控叢集本身以及所在伺服器的執行狀況。
最近的公有云叢集遷移過程中，impala總查詢段達到100的時候，系統開始變得極不穩定，後來在外援的幫助下發現是系統核心本身的問題，在惡補系統核心引數的同時，發現GPDB的工具也變相填充了我們的短板，比如提供了gpcheck和gpcheckperf等命令，用於檢測GPDB執行所需的系統配置是否合理以及對相關硬體做效能測試。如下，執行gpcheck命令後，檢測sysctl.conf中引數的設定是否符合要求，如果對引數的含義感興趣，可以自行搜尋學習。
1. [[email protected]do-hadoop280 greenplum]$ gpcheck --host mdw
2. variable not detected in /etc/sysctl.conf: 'net.ipv4.tcp_max_syn_backlog'
3. variable not detected in /etc/sysctl.conf: 'kernel.sem'
4. variable not detected in /etc/sysctl.conf: 'net.ipv4.conf.all.arp_filter'
5. /etc/sysctl.conf value for key 'kernel.shmall' has value '4294967296' and expects '4000000000'
6. variable not detected in /etc/sysctl.conf: 'net.core.netdev_max_backlog'
7. /etc/sysctl.conf value for key 'kernel.sysrq' has value '0' and expects '1'
8. variable not detected in /etc/sysctl.conf: 'kernel.shmmni'
9. variable not detected in /etc/sysctl.conf: 'kernel.msgmni'
10. /etc/sysctl.conf value for key 'net.ipv4.ip_local_port_range' has value '10000 65535' and expects '1025 65535'
11. variable not detected in /etc/sysctl.conf: 'net.ipv4.tcp_tw_recycle'
12. hard nproc not found in /etc/security/limits.conf
13. soft nproc not found in /etc/security/limits.conf另外在安裝過程中，用其提供的gpssh-exkeys命令打通所有機器免密登入後，可以很方便地使用gpassh命令對所有的機器批量操作，如下演示了在master主機上執行gpssh命令後，在叢集的五臺機器上批量執行pwd命令。
1. [[email protected] greenplum]$ gpssh -f hostlist
2. => pwd
3. [sdw3] /home/gpadmin
4. [sdw4] /home/gpadmin
5. [sdw5] /home/gpadmin
6. [ mdw] /home/gpadmin
7. [sdw2] /home/gpadmin
8. [sdw1] /home/gpadmin
9. => 諸如上述的工具GPDB還提供了很多，比如恢復segment節點的gprecoverseg命令，比如切換主備節點的gpactivatestandby命令等。這類工具讓叢集的維護變得很簡單，當然我們也可以基於強大的工具包開發自己的管理後臺，讓叢集的維護更加傻瓜化。
查詢計劃和並行執行，SQL優化利器
查詢計劃包括了一些傳統的操作，比如掃表、關聯、聚合、排序等。另外，GPDB有一個特定的操作：移動（motion）。移動操作涉及到查詢處理期間在Segment之間移動的資料。
下面的SQL是TPCH中Query 1的簡化版，用來簡單描述查詢計劃。
1. explain select
2. o_orderdate,
3. o_shippriority
4. from
5. customer,
6. orders
7. where
8. c_mktsegment = 'MACHINERY'
9. and c_custkey = o_custkey
10. and o_orderdate < date '1995-03-20'
11. LIMIT 10;
12.
13. QUERY PLAN
14. ----------------------------------------------------------------------------------------------------------
15. Limit (cost=98132.28..98134.63 rows=10 width=8)
16. -> Gather Motion 10:1 (slice2; segments: 10) (cost=98132.28..98134.63 rows=10 width=8)
17. -> Limit (cost=98132.28..98134.43 rows=1 width=8)
18. -> Hash Join (cost=98132.28..408214.09 rows=144469 width=8)
19. Hash Cond: orders.o_custkey = customer.c_custkey
20. -> Append-only Columnar Scan on orders (cost=0.00..241730.00 rows=711519 width=16)
21. Filter: o_orderdate < '1995-03-20'::date
22. -> Hash (cost=60061.92..60061.92 rows=304563 width=8)
23. -> Broadcast Motion 10:10 (slice1; segments: 10) (cost=0.00..60061.92 rows=304563 width=8)
24. -> Append-only Columnar Scan on customer (cost=0.00..26560.00 rows=30457 width=8)
25. Filter: c_mktsegment = 'MACHINERY'::bpchar
26. Settings: enable_nestloop=off
27. Optimizer status: legacy query optimizer執行計劃從下至上執行，可以看到每個計劃節點操作的額外資訊。
Segment節點掃描各自所儲存的customer表資料，按照過濾條件生成結果資料，並將自己生成的結果資料依次傳送到其他Segment；每個Segment上，orders表的資料和收到的rs做join，並把結果資料返回給master。
上面的執行過程可以看出，GPDB將結果資料給每個含有orders表資料的節點都發了一份。為了最大限度地實現並行化處理，GPDB會將查詢計劃分成多個處理步驟。在查詢執行期間，分發到Segment上的各部分會並行地執行一系列處理工作，並且只處理屬於自己部分的工作。重要的是，可以在同一個主機上啟動多個postgresql資料庫進行更多表的關聯以及更復雜的查詢操作，單臺機器的效能得到更加充分的發揮。
如何檢視執行計劃？
如果一個查詢表現出很差的效能，可以通過檢視執行計劃找到可能的問題點。
• 計劃中是否有一個操作花費時間超長？
• 規劃期的評估是否接近實際情況？
• 選擇性強的條件是否較早出現？
• 規劃期是否選擇了最佳的關聯順序？
• 規劃其是否選擇性的掃描分割槽表？
• 規劃其是否合適的選擇了Hash聚合與Hash關聯操作？
高效的資料匯入，批量不再是瓶頸
前面提到，Greenplum的Master節點只負責客戶端互動和其他一些必要的控制，而不承擔任何的計算任務。在載入資料的時候，會先進行資料分佈的處理工作，為每個表指定一個分發列，接下來所有的節點同時讀取資料，根據選定的Hash演算法，將當前節點資料留下，其他資料通過interconnect傳輸到其他節點上去，保證了高效能的資料匯入。通過結合外部表和gpfdist服務，GPDB可以做到每小時匯入2TB資料，在不改變ETL流程的情況下，可以從impala快速匯入計算好的資料為消費提供服務。
使用gpfdist的優勢在於其可以確保再度去外部表的檔案時，GPDB系統的所有Segment可以完全被利用起來，但是需要確保所有Segment主機可以具有訪問gpfdist的網路。
其他
GPDB支援LDAP認證，這一特性的支援，讓我們可以把目前Impala的角色許可權控制無縫遷移到GPDB；
GPDB基於Postgresql 8.2開發，通過psql命令列工具可以訪問GPDB資料庫的所有功能，另外支援JDBC、ODBC等訪問方式，產品介面層只需要進行少量的適配即可使用GPDB提供服務；
GPDB支援基於資源佇列的管理，可以為不同型別工作負載建立資源獨立的佇列，並且有效地控制使用者的查詢以避免系統超負荷執行。比如，可以為VIP使用者、ETL生產、任性和adhoc等建立不同的資源佇列。同時支援優先順序的設定，在併發爭用資源時，高優先順序佇列的語句將可以獲得比低優先順序資源佇列語句更多的資源。
最近在對GPDB做調研和測試，過程中用TPCH做效能的測試。通過和網路上其他服務的對比發現在5個節點的情況下已經有了很高的查詢速度，但是由於測試環境伺服器問題，具體的效能資料還要在接下來的新環境中得出，不過GPDB基於postgresql開發，天生支援豐富的統計函式，支援橫向的線性擴充套件，內部容錯機制，有很多功能強大的運維管理命令和程式碼。相比impala而言，顯然在SQL的支援、實時性和穩定性上更勝一籌。
本文只是對Greenplum的初窺，接下來更深入的剖析以及在工作中的實踐經驗分享也請關注DA的wiki。更多關於Greenplum基本的語法和特性，也可以參考PostgreSQL的官方文件。
SDCC 2017•上海站將於2017年3月17-19日登陸申城，三大技術峰會和24位嘉賓，匯聚國內知名的網際網路公司CTO、架構師、技術總監，暢談運維、資料庫和架構的熱門話題和技術熱點，遇見精益運維發起人&優維科技CEO王津銀、MongoDB大中華區首席架構師唐建法等大牛，五人團購報名立減1500元，詳情點選註冊參會。
