開卷有益——作者的話
有時候真的感嘆人生歲月匆匆，特別是當一個IT人沉浸于某個技術(shù)領(lǐng)域十來年后，驀然回首，總有說不出的萬千感慨。
筆者有幸從04年就開始從事大規(guī)模數(shù)據(jù)計算的相關(guān)工作，08年作為Greenplum 早期員工加入Greenplum團隊（當時的工牌是“005”，哈哈），記得當時看了一眼Greenplum的架構(gòu)（嗯，就是現(xiàn)在大家耳熟能詳?shù)哪莻€好多個X86框框的圖），就義無反顧地加入了，轉(zhuǎn)眼之間，已經(jīng)到了第8個年頭。
在諸多項目中我親歷了Greenplum在國內(nèi)的生根發(fā)芽到高速發(fā)展，再到現(xiàn)在擁有一百多個企業(yè)級用戶的過程。也見證了Greenplum從早期的2.1版本到當前的4.37版本，許多NB功能的不斷增強、系統(tǒng)穩(wěn)定性的不斷大幅提高，在Greenplum的發(fā)展壯大中，IT行業(yè)也發(fā)生著巨大的變化，業(yè)界潮流沿著開放、開源的方向走向了大數(shù)據(jù)和云計算時代。由此看出，Greenplum十來年的快速發(fā)展不是偶然發(fā)生的，這與其在技術(shù)路線上始終保持與整個IT行業(yè)的技術(shù)演進高度一致密不可分的。
多年歷練中接觸過大大小小幾十個數(shù)據(jù)類項目，有些淺嘗輒止（最短的不到一周甚至還有遠程支持），有些周期以年來計（長期出差現(xiàn)場、生不如死），客觀來說， 每個項目都有其獨一無二的的特點，只要有心，你總能在這個項目上學(xué)到些什么或有所領(lǐng)悟。我覺得把這些整理一下，用隨筆的方式寫下來，除了自己備忘以外，也許會對大家更深入地去了解GP帶來一些啟發(fā)，也或許在某個技術(shù)點上是你目前遇到的問題，如亂碼怎么加載？異構(gòu)數(shù)據(jù)庫如何遷移？集群間如何高速復(fù)制數(shù)據(jù)？如何用C API擴展實現(xiàn)高效備份恢復(fù)等。希望我的這篇文章能夠給大家?guī)韼椭?，同時也希望大家多拍磚。
Greenplum的起源
Greenplum最早是在10多年前（大約在2002年）出現(xiàn)的，基本上和Hadoop是同一時期（Hadoop 約是2004年前后，早期的Nutch可追溯到2002年）。當時的背景是：
互聯(lián)網(wǎng)行業(yè)經(jīng)過之前近10年的由慢到快的發(fā)展，累積了大量信息和數(shù)據(jù)，數(shù)據(jù)在爆發(fā)式增長，這些海量數(shù)據(jù)急需新的計算方式，需要一場計算方式的革命；
傳統(tǒng)的主機計算模式在海量數(shù)據(jù)面前，除了造價昂貴外，在技術(shù)上也難于滿足數(shù)據(jù)計算性能指標，傳統(tǒng)主機的Scale-up模式遇到了瓶頸，SMP（對稱多處理）架構(gòu)難于擴展，并且在CPU計算和IO吞吐上不能滿足海量數(shù)據(jù)的計算需求；
分布式存儲和分布式計算理論剛剛被提出來，Google的兩篇著名論文發(fā)表后引起業(yè)界的關(guān)注，一篇是關(guān)于GFS分布式文件系統(tǒng)，另外一篇是關(guān)于MapReduce 并行計算框架的理論，分布式計算模式在互聯(lián)網(wǎng)行業(yè)特別是收索引擎和分詞檢索等方面獲得了巨大成功。
由此，業(yè)界認識到對于海量數(shù)據(jù)需要一種新的計算模式來支持，這種模式就是可以支持Scale-out橫向擴展的分布式并行數(shù)據(jù)計算技術(shù)。
當時，開放的X86服務(wù)器技術(shù)已經(jīng)能很好的支持商用，借助高速網(wǎng)絡(luò)（當時是千兆以太網(wǎng)）組建的X86集群在整體上提供的計算能力已大幅高于傳統(tǒng)SMP主機，并且成本很低，橫向的擴展性還可帶來系統(tǒng)良好的成長性。
問題來了，在X86集群上實現(xiàn)自動的并行計算，無論是后來的MapReduce計算框架還是MPP（海量并行處理）計算框架，最終還是需要軟件來實現(xiàn)，Greenplum正是在這一背景下產(chǎn)生的，借助于分布式計算思想，Greenplum實現(xiàn)了基于數(shù)據(jù)庫的分布式數(shù)據(jù)存儲和并行計算（GoogleMapReduce實現(xiàn)的是基于文件的分布式數(shù)據(jù)存儲和計算，我們過后會比較這兩種方法的優(yōu)劣性）。
話說當年Greenplum（當時還是一個Startup公司，創(chuàng)始人家門口有一棵青梅 ——greenplum，因此而得名）召集了十幾位業(yè)界大咖（據(jù)說來自google、yahoo、ibm和TD），說干就干，花了1年多的時間完成最初的版本設(shè)計和開發(fā)，用軟件實現(xiàn)了在開放X86平臺上的分布式并行計算，不依賴于任何專有硬件，達到的性能卻遠遠超過傳統(tǒng)高昂的專有系統(tǒng)。
大家都知道Greenplum的數(shù)據(jù)庫引擎層是基于著名的開源數(shù)據(jù)庫Postgresql的（下面會分析為什么采用Postgresql，而不是mysql等等），但是Postgresql是單實例數(shù)據(jù)庫，怎么能在多個X86服務(wù)器上運行多個實例且實現(xiàn)并行計算呢？為了這，Interconnnect大神器出現(xiàn)了。在那1年多的時間里，大拿們很大一部分精力都在不斷的設(shè)計、優(yōu)化、開發(fā)Interconnect這個核心軟件組件。最終實現(xiàn)了對同一個集群中多個Postgresql實例的高效協(xié)同和并行計算，interconnect承載了并行查詢計劃生產(chǎn)和Dispatch分發(fā)（QD）、協(xié)調(diào)節(jié)點上QE執(zhí)行器的并行工作、負責(zé)數(shù)據(jù)分布、Pipeline計算、鏡像復(fù)制、健康探測等等諸多任務(wù)。
在Greenplum開源以前，據(jù)說一些廠商也有開發(fā)MPP數(shù)據(jù)庫的打算，其中最難的部分就是在Interconnect上遇到了障礙，可見這項技術(shù)的關(guān)鍵性。
Greenplum為什么選擇Postgreeql做輪子
說到這，也許有同學(xué)會問，為什么Greenplum 要基于Postgresql? 這個問題大致引申出兩個問題：
1、為什么不從數(shù)據(jù)庫底層進行重新設(shè)計研發(fā)？
道理比較簡單，所謂術(shù)業(yè)有專攻，就像制造跑車的不會親自生產(chǎn)車輪一樣，我們只要專注在分布式技術(shù)中最核心的并行處理技術(shù)上面，協(xié)調(diào)我們下面的輪子跑的更快更穩(wěn)才是我們的最終目標。而數(shù)據(jù)庫底層組件就像車輪一樣，經(jīng)過幾十年磨礪，數(shù)據(jù)庫引擎技術(shù)已經(jīng)非常成熟，大可不必去重新設(shè)計開發(fā)，而且把數(shù)據(jù)庫底層交給其它專業(yè)化組織來開發(fā)（對應(yīng)到Postgresql就是社區(qū)），還可充分利用到社區(qū)的源源不斷的創(chuàng)新能力和資源，讓產(chǎn)品保持持續(xù)旺盛的生命力。
這也是我們在用戶選型時，通常建議用戶考察一下底層的技術(shù)支撐是不是有好的組織和社區(qū)支持的原因，如果缺乏這方面的有力支持或獨自閉門造輪，那就有理由為那個車的前途感到擔(dān)憂，一個簡單判斷的標準就是看看底下那個輪子有多少人使用，有多少人為它貢獻力量。
2、為什么是Postgresql而不是其它的？
我想大家可能主要想問為什么是Postgresql而不是Mysql（對不起，還有很多開源關(guān)系型數(shù)據(jù)庫，但相比這兩個主流開源庫，但和這兩個大牛比起來，實在不在一個起跑線上）。本文無意去從詳細技術(shù)點上PK這兩個數(shù)據(jù)庫孰優(yōu)孰劣（網(wǎng)上很多比較），我相信它們的存在都有各自的特點，它們都有成熟的開源社區(qū)做支持，有各自的龐大的fans群眾基礎(chǔ)。個人之見，Greenplum選擇Postgressql有以下考慮：
1）Postgresql號稱最先進的數(shù)據(jù)庫（官方主頁“The world’s most advanced open source database”）,且不管這是不是自我標榜，就從OLAP分析型方面來考察，以下幾點Postgresql確實勝出一籌：
PG有非常強大 SQL 支持能力和非常豐富的統(tǒng)計函數(shù)和統(tǒng)計語法支持，除對ANSI SQL完全支持外，還支持比如分析函數(shù)（SQL2003 OLAP window函數(shù)），還可以用多種語言來寫存儲過程，對于Madlib、R的支持也很好。這一點上MYSQL就差的很遠，很多分析功能都不支持，而Greenplum作為MPP數(shù)據(jù)分析平臺，這些功能都是必不可少的。
Mysql查詢優(yōu)化器對于子查詢、復(fù)制查詢?nèi)缍啾黻P(guān)聯(lián)、外關(guān)聯(lián)的支持等較弱，特別是在關(guān)聯(lián)時對于三大join技術(shù)：hash join、merge join、nestloop join的支持方面，Mysql只支持最后一種nestloop join（據(jù)說未來會支持hash join），而多個大表關(guān)聯(lián)分析時hash join是必備的利器，缺少這些關(guān)鍵功能非常致命，將難于在OLAP領(lǐng)域充當大任。我們最近對基于MYSQL的某內(nèi)存分布式數(shù)據(jù)庫做對比測試時，發(fā)現(xiàn)其優(yōu)點是OLTP非?？?，TPS非常高（輕松搞定幾十萬），但一到復(fù)雜多表關(guān)聯(lián)性能就立馬下降，即使其具有內(nèi)存計算的功能也無能為力，就其因估計還是受到mysql在這方面限制。
2）擴展性方面，Postgresql比mysql也要出色許多，Postgres天生就是為擴展而生的，你可以在PG中用Python、C、Perl、TCL、PLSQL等等語言來擴展功能，在后續(xù)章節(jié)中，我將展現(xiàn)這種擴展是如何的方便，另外，開發(fā)新的功能模塊、新的數(shù)據(jù)類型、新的索引類型等等非常方便，只要按照API接口開發(fā)，無需對PG重新編譯。PG中contrib目錄下的各個第三方模塊，在GP中的postgis空間數(shù)據(jù)庫、R、Madlib、pgcrypto各類加密算法、gptext全文檢索都是通過這種方式實現(xiàn)功能擴展的。
3）在諸如ACID事物處理、數(shù)據(jù)強一致性保證、數(shù)據(jù)類型支持、獨特的MVCC帶來高效數(shù)據(jù)更新能力等還有很多方面，Postgresql似乎在這些OLAP功能上都比mysql更甚一籌。
4）最后，Postgresql許可是仿照BSD許可模式的，沒有被大公司控制，社區(qū)比較純潔，版本和路線控制非常好，基于Postgresql可讓用戶擁有更多自主性。反觀Mysql的社區(qū)現(xiàn)狀和眾多分支（如MariaDB），確實夠亂的。
好吧，不再過多列舉了，這些特點已經(jīng)足夠了，據(jù)說很多互聯(lián)網(wǎng)公司采用Mysql來做OLTP的同時，卻采用Postgresql來做內(nèi)部的OLAP分析數(shù)據(jù)庫，甚至對新的OLTP系統(tǒng)也直接采用Postgresql。
相比之下，Greenplum更強悍，把Postgresql作為實例（注：該實例非Oracle實例概念，這里指的是一個分布式子庫）架構(gòu)在Interconnect下，在Interconnect的指揮協(xié)調(diào)下，數(shù)十個甚至數(shù)千個Sub Postgresql數(shù)據(jù)庫實例同時開展并行計算，而且，這些Postgresql之間采用share-nothing無共享架構(gòu)，從而更將這種并行計算能力發(fā)揮到極致。
除此之外，MPP采用兩階段提交和全局事務(wù)管理機制來保證集群上分布式事務(wù)的一致性，Greenplum像Postgresql一樣滿足關(guān)系型數(shù)據(jù)庫的包括ACID在內(nèi)的所有特征。
從上圖進而可以看到，Greenplum的最小并行單元不是節(jié)點層級，而是在實例層級，安裝過Greenplum的同學(xué)應(yīng)該都看到每個實例都有自己的postgresql目錄結(jié)構(gòu)，都有各自的一套Postgresql數(shù)據(jù)庫守護進程（甚至可以通過UT模式進行單個實例的訪問）。正因為如此，甚至一個運行在單節(jié)點上的GreenplumDB也是一個小型的并行計算架構(gòu)，一般一個節(jié)點配置6~8個實例，相當于在一個節(jié)點上有6~8個Postgresql數(shù)據(jù)庫同時并行工作，優(yōu)勢在于可以充分利用到每個節(jié)點的所有CPU和IO 能力。
Greenplum單個節(jié)點上運行能力比其它數(shù)據(jù)庫也快很多，如果運行在多節(jié)點上，其提供性能幾乎是線性的增長，這樣一個集群提供的性能能夠很輕易的達到傳統(tǒng)數(shù)據(jù)庫的數(shù)百倍甚至數(shù)千倍，所管理數(shù)據(jù)存儲規(guī)模達到100TB~數(shù)PB，而你在硬件上的投入，僅僅是數(shù)臺一般的X86服務(wù)器和普通的萬兆交換機。
Greenplum采用Postgresl作為底層引擎，良好的兼容了Postgresql的功能，Postgresql中的功能模塊和接口基本上99%都可以在Greenplum上使用，例如odbc、jdbc、oledb、perldbi、python psycopg2等，所以Greenplum與第三方工具、BI報表集成的時候非常容易；對于postgresql的contrib中的一些常用模塊Greenplum提供了編譯后的模塊開箱即用，如oraface、postgis、pgcrypt等，對于其它模塊，用戶可以自行將contrib下的代碼與Greenplum的include頭文件編譯后，將動態(tài)so庫文件部署到所有節(jié)點就可進行測試使用了。有些模塊還是非常好用的，例如oraface，基本上集成了Oracle常用的函數(shù)到Greenplum中，曾經(jīng)在一次PoC測試中，用戶提供的22條Oracle SQL語句，不做任何改動就能運行在Greenplum上。
最后特別提示，Greenplum絕不僅僅只是簡單的等同于“Postgresql+interconnect并行調(diào)度+分布式事務(wù)兩階段提交”，Greenplum還研發(fā)了非常多的高級數(shù)據(jù)分析管理功能和企業(yè)級管理模塊，這些功能都是Postgresql沒有提供的：
外部表并行數(shù)據(jù)加載
可更新數(shù)據(jù)壓縮表
行、列混合存儲
數(shù)據(jù)表多級分區(qū)
Bitmap索引
Hadoop外部表
Gptext全文檢索
并行查詢計劃優(yōu)化器和Orca優(yōu)化器
Primary/Mirror鏡像保護機制
資源隊列管理
WEB/Brower監(jiān)控
Greenplum的藝術(shù)，一切皆并行（Parallel Everything）
前面介紹了Greenplum的分布式并行計算架構(gòu)，其中每個節(jié)點上所有Postgresql實例都是并行工作的，這種并行的Style貫穿了Greenplum功能設(shè)計的方方面面：外部表數(shù)據(jù)加載是并行的、查詢計劃執(zhí)行是并行的、索引的建立和使用是并行的，統(tǒng)計信息收集是并行的、表關(guān)聯(lián)（包括其中的重分布或廣播及關(guān)聯(lián)計算）是并行的，排序和分組聚合都是并行的，備份恢復(fù)也是并行的，甚而數(shù)據(jù)庫啟停和元數(shù)據(jù)檢查等維護工具也按照并行方式來設(shè)計，得益于這種無所不在的并行，Greenplum在數(shù)據(jù)加載和數(shù)據(jù)計算中表現(xiàn)出強悍的性能，某行業(yè)客戶深有體會:同樣2TB左右的數(shù)據(jù)，在Greenplum中不到一個小時就加載完成了，而在用戶傳統(tǒng)數(shù)據(jù)倉庫平臺上耗時半天以上。
在該用戶的生產(chǎn)環(huán)境中，1個數(shù)百億表和2個10多億條記錄表的全表關(guān)聯(lián)中（只有on關(guān)聯(lián)條件，不帶where過濾條件，其中一個10億條的表計算中需要重分布），Greenplum僅耗時數(shù)分鐘就完成了，當其它傳統(tǒng)數(shù)據(jù)平臺還在為千萬級或億級規(guī)模的表關(guān)聯(lián)性能發(fā)愁時，Greenplum已經(jīng)一騎絕塵，在百億級規(guī)模以上表關(guān)聯(lián)中展示出上佳的表現(xiàn)。
Greenplum建立在Share-nothing無共享架構(gòu)上，讓每一顆CPU和每一塊磁盤IO都運轉(zhuǎn)起來，無共享架構(gòu)將這種并行處理發(fā)揮到極致。相比一些其它傳統(tǒng)數(shù)據(jù)倉庫的Sharedisk架構(gòu)，后者最大瓶頸就是在IO吞吐上，在大規(guī)模數(shù)據(jù)處理時，IO無法及時feed數(shù)據(jù)給到CPU，CPU資源處于wait 空轉(zhuǎn)狀態(tài)，無法充分利用系統(tǒng)資源，導(dǎo)致SQL效率低下：
一臺內(nèi)置16塊SAS盤的X86服務(wù)器，每秒的IO數(shù)據(jù)掃描性能約在2000MB/s左右，可以想象，20臺這樣的服務(wù)器構(gòu)成的機群IO性能是40GB/s，這樣超大的IO吞吐是傳統(tǒng)的 Storage難以達到的。
另外，Greenplum還是建立在實例級別上的并行計算，可在一次SQL請求中利用到每個節(jié)點上的多個CPU CORE的計算能力，對X86的CPU超線程有很好的支持，提供更好的請求響應(yīng)速度。在PoC中接觸到其它一些國內(nèi)外基于開放平臺的MPP軟件，大都是建立在節(jié)點級的并行，單個或少量的任務(wù)時無法充分利用資源，導(dǎo)致系統(tǒng)加載和SQL執(zhí)行性能不高。
記憶較深的一次PoC公開測試中，有廠商要求在測試中關(guān)閉CPU超線程，估計和這個原因有關(guān)（因為沒有辦法利用到多個CPU core的計算能力，還不如關(guān)掉超線程以提高單core的能力），但即使是這樣，在那個測試中，測試性能也大幅低于Greenplum（那個測試中，各廠商基于客戶提供的完全相同的硬件環(huán)境，Greenplum是唯一一家完成所有測試的，特別在混合負載測試中，Greenplum的80并發(fā)耗時3個多小時就成功完成了，其它廠商大都沒有完成此項測試，唯一完成的一家耗時40多小時）
前文提到，得益于Postgresql的良好擴展性（這里是extension，不是scalability），Greenplum 可以采用各種開發(fā)語言來擴展用戶自定義函數(shù)（UDF）（我個人是Python和C的fans，后續(xù)章節(jié)與大家分享）。這些自定義函數(shù)部署到Greenplum后可用充分享受到實例級別的并行性能優(yōu)勢，我們強烈建議用戶將庫外的處理邏輯，部署到用MPP數(shù)據(jù)庫的UDF這種In-Database的方式來處理，你將獲得意想不到的性能和方便性；例如我們在某客戶實現(xiàn)的數(shù)據(jù)轉(zhuǎn)碼、數(shù)據(jù)脫敏等，只需要簡單的改寫原有代碼后部署到GP中，通過并行計算獲得數(shù)十倍性能提高。
另外，GPTEXT（lucent全文檢索）、Apache Madlib（開源挖掘算法）、SAS algorithm、R都是通過UDF方式實現(xiàn)在Greenplum集群中分布式部署，從而獲得庫內(nèi)計算的并行能力。這里可以分享的是，SAS曾經(jīng)做過測試，對1億條記錄做邏輯回歸，采用一臺小型機耗時約4個多小時，通過部署到Greenplum集群中，耗時不到2分鐘就全部完成了。以GPEXT為例，下圖展現(xiàn)了Solr全文檢索在Greenplum中的并行化風(fēng)格。
最后，也許有同學(xué)會有問題，Greenplum采用Master-slave架構(gòu)，Master是否會成為瓶頸？完全不用擔(dān)心，Greenplum所有的并行任務(wù)都是在Segment數(shù)據(jù)節(jié)點上完成后，Master只負責(zé)生成和優(yōu)化查詢計劃、派發(fā)任務(wù)、協(xié)調(diào)數(shù)據(jù)節(jié)點進行并行計算。
按照我們在用戶現(xiàn)場觀察到的，Master上的資源消耗很少有超過20%情況發(fā)生，因為Segment才是計算和加載發(fā)生的場所（當然，在HA方面，Greenplum提供Standby Master機制進行保證）。
再進一步看，Master-Slave架構(gòu)在業(yè)界的大數(shù)據(jù)分布式計算和云計算體系中被廣泛應(yīng)用，大家可以看到，現(xiàn)在主流分布式系統(tǒng)都是采用Master-Slave架構(gòu)，包括：Hadoop FS、Hbase、MapReduce、Storm、Mesos……無一例外都是Master-Slave架構(gòu)。相反，采用Multiple Active Master 的軟件系統(tǒng)，需要消耗更多資源和機制來保證元數(shù)據(jù)一致性和全局事務(wù)一致性，特別是在節(jié)點規(guī)模較多時，將導(dǎo)致性能下降，嚴重時可能導(dǎo)致多Master之間的腦裂引發(fā)嚴重系統(tǒng)故障。
Greenplum不能做什么？
Greenplum最大的特點總結(jié)就一句話：基于低成本的開放平臺基礎(chǔ)上提供強大的并行數(shù)據(jù)計算性能和海量數(shù)據(jù)管理能力。這個能力主要指的是并行計算能力，是對大任務(wù)、復(fù)雜任務(wù)的快速高效計算，但如果你指望MPP并行數(shù)據(jù)庫能夠像OLTP數(shù)據(jù)庫一樣，在極短的時間處理大量的并發(fā)小任務(wù)，這個并非MPP數(shù)據(jù)庫所長。請牢記，并行和并發(fā)是兩個完全不同的概念，MPP數(shù)據(jù)庫是為了解決大問題而設(shè)計的并行計算技術(shù)，而不是大量的小問題的高并發(fā)請求。
再通俗點說，Greenplum主要定位在OLAP領(lǐng)域，利用Greenplum MPP數(shù)據(jù)庫做大數(shù)據(jù)計算或分析平臺非常適合，例如:數(shù)據(jù)倉庫系統(tǒng)、ODS系統(tǒng)、ACRM系統(tǒng)、歷史數(shù)據(jù)管理系統(tǒng)、電信流量分析系統(tǒng)、移動信令分析系統(tǒng)、SANDBOX自助分析沙箱、數(shù)據(jù)集市等等。
而MPP數(shù)據(jù)庫都不擅長做OLTP交易系統(tǒng)，所謂交易系統(tǒng)，就是高頻的交易型小規(guī)模數(shù)據(jù)插入、修改、刪除，每次事務(wù)處理的數(shù)據(jù)量不大，但每秒鐘都會發(fā)生幾十次甚至幾百次以上交易型事務(wù) ，這類系統(tǒng)的衡量指標是TPS，適用的系統(tǒng)是OLTP數(shù)據(jù)庫或類似Gemfire的內(nèi)存數(shù)據(jù)庫。
Greenplum MPP 與 Hadoop
MPP和Hadoop都是為了解決大規(guī)模數(shù)據(jù)的并行計算而出現(xiàn)的技術(shù)，兩種技術(shù)的相似點在于：
分布式存儲數(shù)據(jù)在多個節(jié)點服務(wù)器上
采用分布式并行計算框架
支持橫向擴展來提高整體的計算能力和存儲容量
都支持X86開放集群架構(gòu)
但兩種技術(shù)在數(shù)據(jù)存儲和計算方法上，也存在很多顯而易見的差異：
MPP按照關(guān)系數(shù)據(jù)庫行列表方式存儲數(shù)據(jù)（有模式），Hadoop按照文件切片方式分布式存儲（無模式）
兩者采用的數(shù)據(jù)分布機制不同，MPP采用Hash分布，計算節(jié)點和存儲緊密耦合，數(shù)據(jù)分布粒度在記錄級的更小粒度（一般在1k以下）；Hadoop FS按照文件切塊后隨機分配，節(jié)點和數(shù)據(jù)無耦合，數(shù)據(jù)分布粒度在文件塊級（缺省64MB）。
MPP采用SQL并行查詢計劃，Hadoop采用Mapreduce框架
基于以上不同，體現(xiàn)在效率、功能等特性方面也大不相同：
1.計算效率比較：
先說說Mapreduce技術(shù)，Mapreduce相比而言是一種較為蠻力計算方式（業(yè)內(nèi)曾經(jīng)甚至有聲音質(zhì)疑MapReduce是反潮流的），數(shù)據(jù)處理過程分成Map-〉Shuffle-〉Reduce的過程，相比MPP 數(shù)據(jù)庫并行計算而言，Mapreduce的數(shù)據(jù)在計算前未經(jīng)整理和組織（只是做了簡單數(shù)據(jù)分塊，數(shù)據(jù)無模式），而MPP預(yù)先會把數(shù)據(jù)有效的組織（有模式），例如：行列表關(guān)系、Hash分布、索引、分區(qū)、列存儲等、統(tǒng)計信息收集等，這就決定了在計算過程中效率大為不同：
MAP效率對比：
Hadoop的MAP階段需要對數(shù)據(jù)的再解析，而MPP數(shù)據(jù)庫直接取行列表，效率高
Hadoop按照64MB分拆文件，而且數(shù)據(jù)不能保證在所有節(jié)點均勻分布，因此MAP過程的并行化程度低；MPP數(shù)據(jù)庫按照數(shù)據(jù)記錄拆分和Hash分布，粒度更細，數(shù)據(jù)分布在所有節(jié)點中非常均勻，并行化程度很高
Hadoop HDFS沒有靈活的索引、分區(qū)、列存儲等技術(shù)支持，而MPP通常利用這些技術(shù)大幅提高數(shù)據(jù)的檢索效率；
Shuffle效率對比：（Hadoop Shuffle 對比MPP計算中的重分布）
由于Hadoop數(shù)據(jù)與節(jié)點的無關(guān)性，因此Shuffle是基本避免不了的；而MPP數(shù)據(jù)庫對于相同Hash分布數(shù)據(jù)不需要重分布，節(jié)省大量網(wǎng)絡(luò)和CPU消耗；
Mapreduce沒有統(tǒng)計信息，不能做基于cost-base的優(yōu)化；MPP數(shù)據(jù)庫利用統(tǒng)計信息可以很好的進行并行計算優(yōu)化，例如，對于不同分布的數(shù)據(jù)，可以在計算中基于Cost動態(tài)的決定最優(yōu)執(zhí)行路徑，如采用重分布還是小表廣播
Reduce效率對比：（對比于MPP數(shù)據(jù)庫的SQL執(zhí)行器-executor）
Mapreduce缺乏靈活的Join技術(shù)支持，MPP數(shù)據(jù)庫可以基于COST來自動選擇Hash join、Merger join和Nestloop join，甚至可以在Hash join通過COST選擇小表做Hash，在Nestloop Join中選擇index提高join性能等等；
MPP數(shù)據(jù)庫對于Aggregation（聚合）提供Multiple-agg、Group-agg、sort-agg等多種技術(shù)來提供計算性能，Mapreuce需要開發(fā)人員自己實現(xiàn)；
另外，Mapreduce在整個MAP->Shuffle->Reduce過程中通過文件來交換數(shù)據(jù)，效率很低，MapReduce要求每個步驟間的數(shù)據(jù)都要序列化到磁盤，這意味著MapReduce作業(yè)的I/O成本很高，導(dǎo)致交互分析和迭代算法開銷很大，MPP數(shù)據(jù)庫采用Pipline方式在內(nèi)存數(shù)據(jù)流中處理數(shù)據(jù)，效率比文件方式高很多；
總結(jié)以上幾點，MPP數(shù)據(jù)庫在計算并行度、計算算法上比Hadoop更加SMART，效率更高；在客戶現(xiàn)場的測試對比中，Mapreduce對于單表的計算尚可，但對于復(fù)雜查詢，如多表關(guān)聯(lián)等，性能很差，性能甚至只有MPP數(shù)據(jù)庫的幾十分之一甚至幾百分之一，下圖是基于MapReduce的Hive和Greenplum MPP在TPCH 22個SQL測試性能比較：（相同硬件環(huán)境下）
還有，某國內(nèi)知名電商在其數(shù)據(jù)分析平臺做過驗證，同樣硬件條件下，MPP數(shù)據(jù)庫比Hadoop性能快12倍以上。
2.功能上的對比
MPP數(shù)據(jù)庫采用SQL作為主要交互式語言，SQL語言簡單易學(xué)，具有很強數(shù)據(jù)操縱能力和過程語言的流程控制能力，SQL語言是專門為統(tǒng)計和數(shù)據(jù)分析開發(fā)的語言，各種功能和函數(shù)琳瑯滿目，SQL語言不僅適合開發(fā)人員，也適用于分析業(yè)務(wù)人員，大幅簡化了數(shù)據(jù)的操作和交互過程。
而對MapReduce編程明顯是困難的，在原生的Mapreduce開發(fā)框架基礎(chǔ)上的開發(fā)，需要技術(shù)人員諳熟于JAVA開發(fā)和并行原理，不僅業(yè)務(wù)分析人員無法使用，甚至技術(shù)人員也難以學(xué)習(xí)和操控。為了解決易用性的問題，近年來SQL-0N-HADOOP技術(shù)大量涌現(xiàn)出來，幾乎成為當前Hadoop開發(fā)使用的一個技術(shù)熱點趨勢。
這些技術(shù)包括：Hive、Pivotal HAWQ、SPARK SQL、Impala、Prest、Drill、Tajo等等很多，這些技術(shù)有些是在Mapreduce上做了優(yōu)化，例如Spark采用內(nèi)存中的Mapreduce技術(shù)，號稱性能比基于文件的的Mapreduce提高10倍；有的則采用C/C++語言替代Java語言重構(gòu)Hadoop和Mapreuce（如MapR公司及國內(nèi)某知名電商的大數(shù)據(jù)平臺）；而有些則直接繞開了Mapreduce另起爐灶，如Impala、hawq采用借鑒MPP計算思想來做查詢優(yōu)化和內(nèi)存數(shù)據(jù)Pipeline計算，以此來提高性能。
雖然SQL-On-Hadoop比原始的Mapreduce雖然在易用上有所提高，但在SQL成熟度和關(guān)系分析上目前還與MPP數(shù)據(jù)庫有較大差距：
上述系統(tǒng)，除了HAWQ外，對SQL的支持都非常有限，特別是分析型復(fù)雜SQL，如SQL 2003 OLAP WINDOW函數(shù)，幾乎都不支持，以TPC-DS測試（用于評測決策支持系統(tǒng)（大數(shù)據(jù)或數(shù)據(jù)倉庫）的標準SQL測試集,99個SQL）為例，包括SPARK、Impala、Hive只支持其中1/3左右；
由于HADOOP 本身Append-only特性，SQL-On-Hadoop大多不支持數(shù)據(jù)局部更新和刪除功能(update/delete)；而有些，例如Spark計算時，需要預(yù)先將數(shù)據(jù)裝載到DataFrames模型中；
基本上都缺少索引和存儲過程等等特征
除HAWQ外，大多對于ODBC/JDBC/DBI/OLEDB/.NET接口的支持有限，與主流第三方BI報表工具兼容性不如MPP數(shù)據(jù)庫
SQL-ON-HADOOP不擅長于交互式（interactive）的Ad-hoc查詢，多通過預(yù)關(guān)聯(lián)的方式來規(guī)避這個問題；另外，在并發(fā)處理方面能力較弱，高并發(fā)場景下，需要控制計算請求的并發(fā)度，避免資源過載導(dǎo)致的穩(wěn)定性問題和性能下降問題；
3.架構(gòu)靈活性對比：
前文提到，為保證數(shù)據(jù)的高性能計算，MPP數(shù)據(jù)庫節(jié)點和數(shù)據(jù)之間是緊耦合的，相反，Hadoop的節(jié)點和數(shù)據(jù)是沒有耦合關(guān)系的。這就決定了Hadoop的架構(gòu)更加靈活-存儲節(jié)點和計算節(jié)點的無關(guān)性，這體現(xiàn)在以下2個方面：
擴展性方面
Hadoop架構(gòu)支持單獨增加數(shù)據(jù)節(jié)點或計算節(jié)點，依托于Hadoop的SQL-ON-HADOOP系統(tǒng)，例如HAWQ、SPARK均可單獨增加計算層的節(jié)點或數(shù)據(jù)層的HDFS存儲節(jié)點，HDFS數(shù)據(jù)存儲對計算層來說是透明的；
MPP數(shù)據(jù)庫擴展時，一般情況下是計算節(jié)點和數(shù)據(jù)節(jié)點一起增加的，在增加節(jié)點后，需要對數(shù)據(jù)做重分布才能保證數(shù)據(jù)與節(jié)點的緊耦合（重新hash數(shù)據(jù)），進而保證系統(tǒng)的性能；Hadoop在增加存儲層節(jié)點后，雖然也需要Rebalance數(shù)據(jù)，但相較MPP而言，不是那么緊迫。
節(jié)點退服方面
Hadoop節(jié)點宕機退服，對系統(tǒng)的影響較小，并且系統(tǒng)會自動將數(shù)據(jù)在其它節(jié)點擴充到3份；MPP數(shù)據(jù)庫節(jié)點宕機時，系統(tǒng)的性能損耗大于Hadoop節(jié)點。
Pivotal將GPDB 的MPP技術(shù)與Hadoop分布式存儲技術(shù)結(jié)合，推出了HAWQ高級數(shù)據(jù)分析軟件系統(tǒng)，實現(xiàn)了Hadoop上的SQL-on-HADOOP，與其它的SQL-on-HADOOP系統(tǒng)不同，HAWQ支持完全的SQL語法 和SQL 2003 OLAP 語法及Cost-Base的算法優(yōu)化，讓用戶就像使用關(guān)系型數(shù)據(jù)庫一樣使用Hadoop。底層存儲采用HDFS，HAWQ實現(xiàn)了計算節(jié)點和HDFS數(shù)據(jù)節(jié)點的解耦，采用MR2.0的YARN來進行資源調(diào)度，同時具有Hadoop的靈活伸縮的架構(gòu)特性和MPP的高效能計算能力.
當然，有得也有所失，HAWQ的架構(gòu)比Greenplum MPP數(shù)據(jù)庫靈活，在獲得架構(gòu)優(yōu)越性的同時，其性能比Greenplum MPP數(shù)據(jù)庫要低一倍左右，但得益于MPP算法的紅利，HAWQ性能仍大幅高于其它的基于MapReduce的SQL-on-HADOOP系統(tǒng)。
4.選擇MPP還是Hadoop
總結(jié)一下，Hadoop MapReduce和SQL-on-HADOOP技術(shù)目前都還不夠成熟，性能和功能上都有很多待提升的空間，相比之下，MPP數(shù)據(jù)在數(shù)據(jù)處理上更加SMART，要填平或縮小與MPP數(shù)據(jù)庫之間的性能和功能上的GAP，Hadoop還有很長的一段路要走。
就目前來看，個人認為這兩個系統(tǒng)都有其適用的場景，簡單來說，如果你的數(shù)據(jù)需要頻繁的被計算和統(tǒng)計、并且你希望具有更好的SQL交互式支持和更快計算性能及復(fù)雜SQL語法的支持，那么你應(yīng)該選擇MPP數(shù)據(jù)庫，SQL-on-Hadoop技術(shù)還沒有Ready。特別如數(shù)據(jù)倉庫、集市、ODS、交互式分析數(shù)據(jù)平臺等系統(tǒng)，MPP數(shù)據(jù)庫有明顯的優(yōu)勢。
而如果你的數(shù)據(jù)加載后只會被用于讀取少數(shù)次的任務(wù)和用于少數(shù)次的訪問，而且主要用于Batch（不需要交互式），對計算性能不是很敏感，那Hadoop也是不錯的選擇，因為Hadoop不需要你花費較多的精力來模式化你的數(shù)據(jù)，節(jié)省數(shù)據(jù)模型設(shè)計和數(shù)據(jù)加載設(shè)計方面的投入。這些系統(tǒng)包括：歷史數(shù)據(jù)系統(tǒng)、ETL臨時數(shù)據(jù)區(qū)、數(shù)據(jù)交換平臺等等。
總之，Bear in mind，千萬不要為了大數(shù)據(jù)而大數(shù)據(jù)（就好像不要為了創(chuàng)新而創(chuàng)新一個道理），否則，你項目最后的產(chǎn)出與你的最初設(shè)想可能將差之千里，行業(yè)內(nèi)不乏失敗案例。
最后，提一下，Greenplum MPP數(shù)據(jù)庫支持用“Hadoop外部表”方式來訪問、加載Hadoop FS的數(shù)據(jù)，雖然Greenplum的Hadoop外部表性能大幅低于MPP內(nèi)部表，但比Hadoop 自身的HIVE要高很多（在某金融客戶的測試結(jié)果，比HIVE高8倍左右），因此可以考慮在項目中同時部署MPP數(shù)據(jù)庫和Hadoop，MPP用于交互式高性能分析，Hadoop用于數(shù)據(jù)Staging、MPP的數(shù)據(jù)備份或一些ETL batch的數(shù)據(jù)清洗任務(wù)，兩者相輔相成，在各自最擅長的場景中發(fā)揮其特性和優(yōu)勢。
5.未來GP發(fā)展之路
過去十年，IT技術(shù)潮起潮落發(fā)生著時刻不停的變化，而在這變化中的不變就是走向開放和開源的道路，即將到來的偉大變革是云計算時代的到來，任何IT技術(shù)，從硬件到軟件到服務(wù)，都逃不過要接受云計算的洗禮，不能趕上時代潮流的技術(shù)和公司都將被無情的淘汰。大數(shù)據(jù)也要擁抱云計算，大數(shù)據(jù)將作為一種數(shù)據(jù)服務(wù)來提供（DaaS-Data as A Service），依靠云提供共享的、彈性、按需分配的大數(shù)據(jù)計算和存儲的服務(wù)。
Greenplum MPP數(shù)據(jù)庫從已一開始就是開放的技術(shù)，并且在2015年年底已經(jīng)開源和成立社區(qū)（在開源第一天就有上千個Download），可以說，Greenplum已經(jīng)不僅僅只是Pivotal公司一家的產(chǎn)品，我們相信越來越多組織和個人會成為Greenplum的Contributor貢獻者，隨著社區(qū)的發(fā)展將推動Greenplum MPP數(shù)據(jù)庫走向新的高速發(fā)展旅程。（分享一下開源的直接好處，最近我們某用戶的一個特殊需求，加載數(shù)據(jù)中有回車等特殊字符，我們下載了GP外部表gpfdist源代碼，不到一天就輕松搞定問題）
Greenplum也正在積極的擁抱云計算，Cloud Foundry的PaaS云平臺正在技術(shù)考慮把Greenplum MPP做為DaaS服務(wù)來提供，對于Mesos或其它云計算技術(shù)的愛好者，也可以考慮采用容器鏡像技術(shù)+集群資源框架管理技術(shù)來部署Greenplum,從而可以實現(xiàn)在公共計算資源集群上的MPP敏捷部署和資源共享與分配。
總之，相信沿著開放、開源、云計算的路線繼續(xù)前行，Greenplum MPP數(shù)據(jù)庫在新的時代將保持旺盛的生命力，繼續(xù)高速發(fā)展。
本文來源pivotal_china官方微信，經(jīng)作者同意由DBA+社群編輯整理。
作者簡介 李巍
資深Greenplum 數(shù)據(jù)庫專家， 擁有超過10年從事分布式計算和大數(shù)據(jù)計算的經(jīng)歷，對大規(guī)模數(shù)據(jù)計算有著豐富的實戰(zhàn)經(jīng)驗。
曾在包括大型電商、國有大銀行、電信行業(yè)在內(nèi)的數(shù)十個項目中擔(dān)任架構(gòu)師或技術(shù)專家，在很多關(guān)鍵性問題的解決上做出過多項貢獻。
長期關(guān)注開源技術(shù)，對開源數(shù)據(jù)庫及Python、C、Perl語言極其熟練，信念“實踐出真知”的真理。
