簡介及適用場景
如果想在資料倉儲中快速查詢結果，可以使用greenplum。
Greenplum資料庫也簡稱GPDB。它擁有豐富的特性：
第一，完善的標準支援：GPDB完全支援ANSI SQL 2008標準和SQL OLAP 2003 擴充套件；從應用程式設計介面上講，它支援ODBC和JDBC。完善的標準支援使得系統開發、維護和管理都大為方便。而現在的 NoSQL，NewSQL和Hadoop 對 SQL 的支援都不完善，不同的系統需要單獨開發和管理，且移植性不好。
第二，支援分散式事務，支援ACID。保證資料的強一致性。
第三，做為分散式資料庫，擁有良好的線性擴充套件能力。在國內外使用者生產環境中，具有上百個物理節點的GPDB叢集都有很多案例。
第四，GPDB是企業級資料庫產品，全球有上千個叢集在不同客戶的生產環境執行。這些叢集為全球很多大的金融、政府、物流、零售等公司的關鍵業務提供服務。
第五，GPDB是Greenplum（現在的Pivotal）公司十多年研發投入的結果。GPDB基於PostgreSQL 8.2，PostgreSQL 8.2有大約80萬行原始碼，而GPDB現在有130萬行原始碼。相比PostgreSQL 8.2，增加了約50萬行的原始碼。
第六，Greenplum有很多合作伙伴，GPDB有完善的生態系統，可以與很多企業級產品整合，譬如SAS，Cognos，Informatic，Tableau等；也可以很多種開源軟體整合，譬如Pentaho,Talend 等。
greenplum起源
Greenplum最早是在10多年前（大約在2002年）出現的，基本上和Hadoop是同一時期（Hadoop 約是2004年前後，早期的Nutch可追溯到2002年）。當時的背景是：
- 網際網路行業經過之前近10年的由慢到快的發展，累積了大量資訊和資料，資料在爆發式增長，這些海量資料急需新的計算方式，需要一場計算方式的革命；
- 傳統的主機計算模式在海量資料面前，除了造價昂貴外，在技術上也難於滿足資料計算效能指標，傳統主機的Scale-up模式遇到了瓶頸，SMP（對稱多處理）架構難於擴充套件，並且在CPU計算和IO吞吐上不能滿足海量資料的計算需求；
- 分散式儲存和分散式計算理論剛剛被提出來，Google的兩篇著名論文發表後引起業界的關注，一篇是關於GFS分散式檔案系統，另外一篇是關於MapReduce 平行計算框架的理論，分散式計算模式在網際網路行業特別是收索引擎和分詞檢索等方面獲得了巨大成功。
下圖就是GFS的架構
總體架構
greenplum的總體架構如下：
資料庫由Master Severs和Segment Severs通過Interconnect互聯組成。
Master主機負責：建立與客戶端的連線和管理；SQL的解析並形成執行計劃；執行計劃向Segment的分發收集Segment的執行結果；Master不儲存業務資料，只儲存資料字典。
Segment主機負責：業務資料的儲存和存取；使用者查詢SQL的執行。
greenplum使用mpp架構。
基本體系架構
master節點，可以做成高可用的架構
master node高可用，類似於hadoop的namenode和second namenode，實現主備的高可用。
segments節點
並行管理
對於資料的裝載和效能監控。
並行備份和恢復。
資料訪問流程，資料分佈到不同顏色的節點上
查詢流程分為查詢建立和查詢分發，計算後將結果返回。
對於儲存，將儲存的內容分佈到各個結點上。
對於資料的分佈，分為hash分佈和隨機分佈兩種。
均勻分佈的情況：
總結
GPDB從開始設計的時候就被定義成資料倉儲，如果是olap的應用，可以嘗試使用GPDB。