greenplum db 号稱是世界上第一個開源的大規模并行資料倉庫，最初是基于 postgresql，現在已經添加了大量資料庫方面的創新。greenplum 提供 pd 級别資料量的強大和快速分析能力，特别是面向大資料方面的分析能力，支援大資料的超高性能分析查詢。在本次分享中，曾文旌從gpdb架構入手，輔助以sql和優化器的案例以及對gpdb的硬體和性能的分析，對gpdb實作進行了詳細解析。分享最後，他還對比了gpdb的優勢和局限性，并對gpdb的未來發展進行了展望。
以下是現場分享觀點整理。
名詞簡介<b></b>
在分享開始之前，首先解釋一下整個内容中最關鍵的幾個名詞：
mpp（massive parallel processing）為大規模并行處理系統，一般是指多個sql資料庫節點搭建而成的資料庫倉庫；在執行sql查詢的時候，任務可分解到多個資料庫查詢，然後将結果傳回給使用者。
mr（mapreduce）是一種程式設計模型，結合了大規模處理并行運算程式設計的思想，可粗略地分成兩部分，map和reduce，任何一個複雜的任務都可以拆成map和reduce的串行組合，主要思想從函數式的程式設計語言所借鑒過來。
sn（shared nothing）為存儲的架構，用于存放資料，由多個完全獨立的處理節點構成，每個處理節點有自己獨立的處理smp的架構，他們存儲的資料沒有共享的部分，獨立的磁盤存放資料，多個smp資料節點之間通過高速網絡連接配接，協同起來完成一個複雜的任務。
data distribution 即資料分發。sn架構上，mpp完成并行任務，它們之間需要做資料的溝通，gpdb的溝通相對複雜，每個資料節點之間可以互相溝通，有的資料庫産品可能隻允許master和資料交流，master和其他資料節點不能互相分發資料。
mpp的完整定義如上所示，它的重點首先是本地存儲資料，其次是通過網絡交換資料，最後是每個資料都是資料節點的一部分，它們之間沒有共享。
gpdb架構特點<b></b>
上圖顯示的gpdb架構圖，架構中最主要的中心節點是master host，它可以和使用者的用戶端直接互動；其他的資料連接配接的是segment host，并且segment中存放了一部分的資料；master和segment之間通過高速網絡交換。
<b>mpp vs mr</b><b></b>
上圖是mr的相關定義資訊。顯然，hadoop主要分為兩部分，一是存儲部分，即分布式存儲，比如熟悉的hdfs；二是大資料的計算架構，通常為mapreduce。
apache hadoop是谷歌思想的一種流行的實作。整個hadoop實作的過程中，它是作為一種開源的架構，設計思路是使用低成本的硬體和自己軟體中的容錯功能，容錯功能由hdfs來完成。有了hdfs，apache hadoop很容易上一定的規模，hdfs是hadoop做到很大叢集的最主要的原因。
詞頻統計是mapreduce的設計思路常用的簡單案例，将文本中單詞出現的次數做一個統計，其過程也展現了hadoop的處理思想。第一步map将資料從hdfs中讀出來，将句子拆成單詞形式，這是一個key-value的過程，key就是單詞本身，value是詞頻，一般取1，其結果再存放到本地hdfs中，即入庫的過程；第二步是reduce的過程，從hdfs中拉取資料，然後計算詞頻，将相同的key值放到一個reducer中，再将key累加起來，最後得到的結果再存回hdfs。如果再做一些更複雜的操作，就重新疊代幾次，這個統稱為mapreduce思想。
這個思想的開源版本未被抛棄的優勢在于：它完整地實作了google思想，同時具有良好的容錯，适合大資料存儲和計算，并且具有廉價的可用方案（軟體硬體）。但其也有很多思想是過時的，例如它隻是比較簡單的開源實作，隻适合離線計算，同時模型抽象困難、程式設計困難。此外它還具有一個緻命的弱點，即中間結果入庫整體效率低、性能差。
雖然實作方式已經過時了，但它仍未被抛棄，而且性能還會改進。
上圖顯示的是mr的典型的發展方向：首先，十年前主要是mapreduce，它的程式設計方式不太好學習；于是就有了hive，即上面是它自己的語句，底層轉換成了mapreduce的方式；再後來，由于每次入庫都比較慢，則将這種方式放在記憶體裡面做，即memory的實作方式。
在關系型資料庫裡，詞頻統計也很簡單，一個sql語句就可以做到。sql語句在gpdb是相容sql語句的，如上圖的語句中：通過一個函數從some_table表把some_column字段拆成了一列多行的形式，将其抽象成一個臨時表，再對臨時表進行group by，針對每個group進行一次count，最後将結果計算出來。
上圖是gpdb中的query plan，通過檢視sql語句的執行計劃了解執行過程以及使用的算法。上圖是一個16節點的gpdb，在segment中被拆成了兩部分，首先是底層的順序掃描，讀到之後用函數拆分，然後将拆分的結果作為一次哈希聚集，并通過網絡的分布節點，發送到各個segment。發送方式是哈希方式，定義一個哈希分布，把需要的資料留下，把不需要的分發到需要它的segment中。另外一個segment的作用是收到這個資料，再做一個哈希聚集，最終把這個資料再發送給master節點，它的分發程度和segment一樣。是以我們看到：中間的網絡分發是segment實作的一個點，它能做到hadoop相同的功能，但前提是把非結構型資料轉換成結構型資料存放到關系型資料庫的表裡，這樣性能才可以得到保證。
gpdb同類産品<b> </b><b></b>
相關的mpp産品，總結如下表，在這裡不一一詳述。
gpdb關鍵特性解析<b></b>
接下來解析gpdb的關鍵特性：
分區表是關系型資料庫，gpdb做到了完整的分區表，不同類型的表都可以組成一張分區表，比如說堆表、列存儲的表。另一個差別是shared nothing hush分布。
傳統的資料庫支援複雜的sql語句，完成複雜的任務，并可以通過一個sql語句表達出來，整個語句的執行計算也好，資料讀取也好，都被完全下發到了資料節點上。
關系資料庫的代價模型，這也是它能做複雜sql的關鍵性的原因。根據不同表的規模選取sql語句，節點間的資料可以做互相的分發，根據該特性可以進行網絡方面的優化。
傳統堆表，相當于一行資料是元存儲方式，多列組合成一條，存儲在資料庫上面，支援列存儲，支援壓縮資料的存儲。
gpdb可以像通常的關系型資料庫那樣支援事務，可以做并發，但是有一定的限度。sql語句的select并發沒有問題。對于高速資料裝載，gpdb可以讓每一個segment同時往自己的節點上裝載資料，這和傳統的方式相比，性能有很大的差別，裝載性能很好，有時候甚至可以把網絡的帶寬占滿。
企業的高可用性。，支援一個高可用的部署，以鏡像節點的方式，持續地提供服務。還有高速網絡通信，因為不可能為每一個業務都定制表的分發方式，在tcp的基礎上又增加的udp的連接配接協定，顯著地提高網絡的傳輸效率。
足夠穩定，功能相對完善。支援資料壓縮，能夠提供壓縮算法的選擇。開源版本支援開源的一些壓縮方式，gpdb還有一個收費的壓縮方式，需要的話可以購買。
上圖是查詢的執行方式。master上不存儲使用者資料，但是會存放表定義，有時候可通過copy的方式往master上加載資料，然後maser再向每個segment上分發資料。master支援stand by節點，stand by不能讀，隻是一個備份，在master節點出問題的時候，讓stand by連接配接，繼續做任務，然後再将master搭起來，實作高可用。
查詢執行的任務拆分是一個簡單的兩個表的作用語句，它在segment中被分為了兩個部分來執行，分片1掃到資料之後通過網絡重分布motion節點到另外一個節點，然後它發送給本segment的另外一個節點；根據motion的定義，另一個分片掃描另外一部分表，把收到的資料作一些函數的調用，最後的資料會發送給gather motion節點。每個segment的執行方式完全一樣，最後的gather motion實際上是一個master節點，它會收所有的segment資料。
接下來說任務執行，在這裡出現了gang的概念。master分發任務稱為qd process，即查詢分發，首先進行segment查詢，多個步驟，即多個gang的方式來執行，下層會将資料往上層上傳，最終彙總到qd上。
我們以兩個表為例，說明一下sql語句的執行過程。表a和表b都是以id列作為分發，這裡面做了一個粗暴的估計，以表裡的行數出現。網絡部分的cost和網絡傳輸的資料量正相關。另一部分是用于網絡通信的motion節點，它有兩種類型：一是redistribute motion哈希重分布，二是broadcast motion廣播。
第一個優化器例子： a表和b表都各自有10000行，連接配接之後，可以看到整個的執行計劃沒有motion節點，是以不需要做網絡重分布 。
若表的規模不變化，左邊的是表a的分布列，id2不是分布列。b表會按照id2計算重分布，然後在所有的節點上做一個重分布，重分布b表時代價簡單了解為10000；方法二是把a/b表廣播出去，它們的代價是10000*16。很顯然，重分布b表的代價最小，執行計劃也是這麼選擇的，即優化器自動選擇了最優的執行方式。
當a表的規模變為100，b表還是10000，表的連接配接方式不變。顯然，廣播a表的時候代價最小，重分布b代價為10000，全廣播b代價為10000*16，優化器也自動選擇了最優的方式。
如果資料規模不變，改變連接配接方式，連接配接的兩個列都不是資料的分布列，很容易看出全廣播a表代價最小。
最後一個例子，不連接配接資料的分布列，表的大小都是10000行。定義一個id2作為重分布列，a表b表都重分布一次，對比全廣播a，全廣播b代價小很多，是以在這個資料規模下選擇重分布ab執行方式。
如圖，可将優化器作如上總結：sql比較友好，學習成本低，支援範圍比較多。基于統計資訊的代價模型有核心的優勢，sql語句越複雜，優勢越明顯。
除此之外，還有一個高可用的部署方式，master的一個備份叫slave，它們之間通過流複制同步，master若出現問題，slave可以被激活，然後成為新的master。master和slave之間是流複制同步，半同步；segment之間是基于檔案的快的同步，概念上是一個primary和mirror。segment若出現問題，有一個機制來保證繼續往下提供服務，若網絡閃斷，primary會積攢一些資料，等網絡好的時候再同步到mirror上。
上圖為高速資料裝載，gpdb可以支援分布式資料裝載。首先部署多個存放資料的節點，資料用web表的形式通過master請求；master請求之後，所有的segment通過gpfd的資料分發服務，gpfd收到資料的請求，然後給所有segment發資料，對等随機地發送，也可以部署多個gpfd，将資料平均地配置設定到每一個中， segment解析資料，和重分布有點類似，留下自己的那部分資料，存到本地segment中，定向發送不屬于自己的資料。segment是定向發送，gpfd發給segment是随機發送。是以說如果整個網絡足夠好，裝載速度會非常快，可以裝載全量資料，也可以批量裝載。
gpdb硬體和性能<b></b>
segment是存儲和計算資料的節點，segment越多，并行程度越高。建議為每個segment至少配置設定一個實體核cpu，8g記憶體，網絡至少千兆以上，因為剛剛列舉的很多特性有網絡要求；硬碟一般為raid 5。mirror狀态不會消耗很多cpu，但是會消耗對等的網絡。
标準的tpch測試用的比較多，很容易找到開源項目，最大測1t左右的資料；pc server和hadoop比，性能好很多；sql越複雜，gpdb性能越好，好的可能到幾十倍。除了排序需要将資料緩存到磁盤，大部分的資料在記憶體裡，通過網絡做高速的分發，網絡的分發經過優化，是以性能非常好。資料在記憶體是流式的執行方式，正常情況，一個資料被掃描到一個節點，處理完之後立馬發送到上層節點，然後再往上發。
gpdb優勢和局限性
gpdb的優勢在于它可以做網絡資料同步，能夠控制整個sql語句的隊列，控制記憶體的消耗；還可以用它來做資源的限制，根據自己硬體的需要控制資源；此外，每個子產品經過多年的打磨，優化很好。
gpdb的局限性，有如下幾種：
擴充性，它不像hadoop和hdfs可以擴充到上千台，有理論瓶頸。從使用來說，比如說擴容，擴容之後所有的整個資料都需要重分布，存儲方式限制了其繼續往上擴充，運維的成本有可能會越來越高，當然，幾十台的情況下還是遊刃有餘的。
增量入庫， gp提供了一個其他的方式，來做到類似的功能。把增量成批地導出到文本，然後再成批地導入到gpdb裡面去，最後再用合并的方式合并到原有的資料庫，變相做到增量入庫。
容錯，上面提到通過備份的方式容錯，這個有一定的局限性。
改進空間，比如，它支援的存儲方式有列存儲，列存儲就是一列一個檔案，用了分區表再用列存儲，磁盤上的檔案就會非常多，如果說再來一個并發的查詢，由于pg是多程序的方式，在檔案os上同時打開，打開的個數就會特别多。
gpdb的發展<b></b>
gpdb未來發展有幾個方面：
新一代優化器，也是開源部分，在一些情況下，會比原有的gpdb優化器更好，尤其是在算多個分區表互相作用的情況下。
cpu的消耗會明顯減少，整個cpu運作的效率會提高，網上釋出了測試的版本，從結果來看，性能不錯。
其他資料庫沒有udp通信的優化，是以gpdb發展的較好。
内部發展方向，用hdfs提高容錯性，資料和計算分離。每個hdfs節點都會挂segment節點的程序，當需要的時候，啟動segment計算；不需要的時候不會存在。
總結<b></b>
最後簡單地總結一下： gpdb的開源，在tp級别遊刃有餘，解決方案非常好，應用性較好，比hadoop有着明顯的優勢；但是以後hadoop也會朝着相同的方向發展。另一方面，mr和mpp的關系是互相學習，能夠融合互相的優點。相當于mr把一些計算優化，使性能更好；mpp也會學習hadoop把資料放在hdfs上，就這樣實作互相融合，它們之間的一些界限作為并行計算來說越來越模糊，未來也會有很多開源或者商業的産品，在這上面誕生。