說起Greenplum這個產品，最早是SUN來推他們的數據倉庫產品DWA時接觸到的，對這個由PgSQL堆疊出來的數據庫產品還不是很了解，當時的焦點還在DWA本身的硬件上，當然不可否認，DWA還是有一些特點的。
后來，我們發現普通的PC+SAS磁盤具備非常好的吞吐能力，完全不遜於某些昂貴的存儲設備。這樣我們就嘗試用PC+Greenplum搭建了一個 環境，效果完全超出了我們的預期，吞吐量完全超過了我們的大型存儲。從那時開始，我們不再迷信那些昂貴的主機和存儲，開始嘗試一些新的東西，比如用 PC+SAS/SATA來堆疊廉價存儲，用Greenplum來搭建數據倉庫計算環境，搜索的hadoop集群，PC+SSD搭建OLTP數據庫，用 Intel Nehalem來替代小型機等等。
昨天，去參加了數據倉庫部門關於Greenplum的一個技術分享，期間大量列舉了一些性能數據的對比，尤其是和當前的一套Oracle RAC的對比。結果不言而喻，在數據倉庫的應用上，尤其是大數據量的處理，性能相差懸殊。這時問題就來了，很多人感覺這個產品太神奇了，可以解決數據倉庫 的一切問題，好像它就是上帝賜予我們的禮物。最后好多人都在問：Oracle太爛了，用這么好的設備，性能還這么差，我們干嘛還要用？嗚呼哀 哉，Greenplum是好，但並不“神奇”，我們不要被這些”神奇“的數據擋住了視線。
對於Greenplum，我其實也處於一知半解的狀態，給大家講原理未免有些力不從心，這里只簡單給大家分析一下Greenplum為什么會快？他用了什么”神奇“的技術？
如何提升數據倉庫的處理能力，有以下兩個主要因素：第一，吞吐能力，就是所謂的IO；第二，並行計算能力。
我們都知道Oracle RAC是shared everything架構，而Greenplum是shared nothing架構。整個集群由很多個segment host(數據節點)+master host(控制節點)組成，其中每個segment host上運行了很多個PgSQL數據庫(segment)。
數據在進入數據庫時，首先要做數據分布的工作，即把一個表的數據盡可能均勻的分布到每個segment上，我們需要為每個表指定一個 distribute列，然后根據hash來做數據分布。這樣做的目的就是要充分利用每個節點的IO能力，我們知道現在PC機的IO能力相當可觀，象 DWA這種專門設計的數據節點，Sun Fire X4500 Server，在一個box內集成了48塊SATA盤，號稱“Scan 1 Terabyte of data in 60 seconds”。其實沒必要買DWA，國內廠商都有那種磁盤密集型的PC，價格便宜量又足，我們一直用它。
很多人在看到Greenplum架構的時候，第一個問題就是master機器承擔了什么功能？它會不會成為系統的瓶頸？這也是Greenplum系 統的一個重要特點，master只承擔非常少量的控制功能，以及和客戶端的交互，完全不承擔任何計算。如果存在一個中心節點的話，那意味着這個系統根本沒 有辦法線性擴展，因為master一定會成為系統的瓶頸。而Greenplum不存在這個問題，節點間的數據交互，不需要經過master，而是直接在節 點間就完成了。
現在，如果我們要查詢某個表的數據，只要把工作分配給每個節點就行了，IO不再是問題，接下來要解決並行計算的問題，核心問題是多表做join。因 為表是通過DT列做分布的，所以每個節點通過DT列就知道數據在某個節點上，假設兩個表用DT列做join，因為相同的數據都在相同的節點上，所以只需要 對應節點計算，然后合並結果就可以了。如果是非DT列做join，因為節點間不知道數據的分布，所以就會做一個數據重分布的過程 (redistribute)。我們看下面的例子，三個表都是用id列作為DT列，首先用id做join，因為設計到非DT列的join，這時 Greenplum會作redistribute的工作，作用就是重新按照hash做數據分布，這樣做的目的就是要讓節點知道數據在哪個節點上，以便完成 join的動作。我們看到后面的group by也做了redistribute，因為group by的也是非DT列，而hash aggregate動作也需要節點間交互數據，節點間也必須知道數據的分布。如果有redistribute動作，效率會高嗎？因為 redistribute僅僅只針對需要的數據，而且全部在節點cache中完成，肯定要比DT列做join慢一些，但是效率還是非常高的。
Greenplum真正發揮了並行無處不在的優勢，在一個主機上同時啟動多個PgSQL數據庫，這樣硬件上的多核CPU就可以充分發揮優勢。有人問 我：Greenplum能並行處理多個任務嗎？回答是：不可能。因為Greenplun已經將機器的IO和處理能力全部發揮出來了，再沒有可能同時處理多 個任務。
Greenplum還有一個有意思的特性就是在數據裝載時，不是我們一般想象的存在一個中心的數據分發節點，而是所有節點同時讀取數據，然后根據hash算法，將屬於自己的數據留下，將其他的節點的數據通過網絡直接傳送給他，所以數據裝載的速度非常快。
Greenplum HA架構
現在來看Greenplum並不神奇，其實Oracle RAC也是數據倉庫非常好的解決方案，類似的技術Oracle全部都有。我們可以這樣來做一個假設，如果針對某個固定的SQL，我可以同樣用Oracle RAC來做Greenplum做的事情，根據SQL，我們可以把表做 Hash+Range分區(事實上Greenplum也是hash+range分區，用hash將數據分布到不同的數據庫上，然后再用range將每個數 據庫上的表做分區)，再利用RAC的並行處理能力。Oracle也有partition-wise join這種類似功能，但是沒有數據redistribute的操作。Oracle最大的問題還是在於shared everything的架構，導致IO的處理能力有限，我們的大型存儲吞吐量也就1.4GB/S，而且擴展能力也有限。以前曾經介紹過的Oracle database machine，就是Oracle專門為數據倉庫的提供的解決方案。
其實並存在什么神奇的技術，Greenplum之所以神奇是因為我們的場景發揮了他的特點，其實我們也可以設計一個場景來得到Greenplum很爛的結論，所以不要相信廠商的數據，不要相信什么可以解決一切問題的技術，那根本不存在。
”不要迷戀哥，哥只是傳說。“