（轉）聊聊Greenplum的那些事

 

開卷有益——做者的話

 

有時候真的感嘆人生歲月匆匆，特別是當一個IT人沉浸於某個技術領域十來年後，驀然回首，總有說不出的萬千感慨。

 

筆者有幸從04年就開始從事大規模數據計算的相關工做，08年做爲Greenplum 早期員工加入Greenplum團隊（當時的工牌是「005」，哈哈），記得當時看了一眼Greenplum的架構（嗯，就是如今你們耳熟能詳的那個好多個X86框框的圖），就義無反顧地加入了，轉眼之間，已經到了第8個年頭。

 

在諸多項目中我親歷了Greenplum在國內的生根發芽到高速發展，再到如今擁有一百多個企業級用戶的過程。也見證了Greenplum從早期的2.1版本到當前的4.37版本，許多NB功能的不斷加強、系統穩定性的不斷大幅提升，在Greenplum的發展壯大中，IT行業也發生着巨大的變化，業界潮流沿着開放、開源的方向走向了大數據和雲計算時代。由此看出，Greenplum十來年的快速發展不是偶然發生的，這與其在技術路線上始終保持與整個IT行業的技術演進高度一致密不可分的。

 

 

多年曆練中接觸過大大小小几十個數據類項目，有些淺嘗輒止（最短的不到一週甚至還有遠程支持），有些週期以年來計（長期出差現場、生不如死），客觀來講， 每一個項目都有其獨一無二的的特色，只要有心，你總能在這個項目上學到些什麼或有所領悟。我以爲把這些整理一下，用隨筆的方式寫下來，除了本身備忘之外，也許會對你們更深刻地去了解GP帶來一些啓發，也或許在某個技術點上是你目前遇到的問題，如亂碼怎麼加載？異構數據庫如何遷移？集羣間如何高速複製數據？如何用C API擴展實現高效備份恢復等。但願個人這篇文章可以給你們帶來幫助，同時也但願你們多拍磚。

 

Greenplum的起源

 

Greenplum最先是在10多年前（大約在2002年）出現的，基本上和Hadoop是同一時期（Hadoop 約是2004年先後，早期的Nutch可追溯到2002年）。當時的背景是：

1

互聯網行業通過以前近10年的由慢到快的發展，累積了大量信息和數據，數據在爆發式增加，這些海量數據急需新的計算方式，須要一場計算方式的革命；

 2

傳統的主機計算模式在海量數據面前，除了造價昂貴外，在技術上也難於知足數據計算性能指標，傳統主機的Scale-up模式遇到了瓶頸，SMP（對稱多處理）架構難於擴展，而且在CPU計算和IO吞吐上不能知足海量數據的計算需求；

 3

分佈式存儲和分佈式計算理論剛剛被提出來，Google的兩篇著名論文發表後引發業界的關注，一篇是關於GFS分佈式文件系統，另一篇是關於MapReduce 並行計算框架的理論，分佈式計算模式在互聯網行業特別是收索引擎和分詞檢索等方面得到了巨大成功。

 

 

由此，業界認識到對於海量數據須要一種新的計算模式來支持，這種模式就是能夠支持Scale-out橫向擴展的分佈式並行數據計算技術。

 

當時，開放的X86服務器技術已經能很好的支持商用，藉助高速網絡（當時是千兆以太網）組建的X86集羣在總體上提供的計算能力已大幅高於傳統SMP主機，而且成本很低，橫向的擴展性還可帶來系統良好的成長性。
 

問題來了，在X86集羣上實現自動的並行計算，不管是後來的MapReduce計算框架仍是MPP（海量並行處理）計算框架，最終仍是須要軟件來實現，Greenplum正是在這一背景下產生的，藉助於分佈式計算思想，Greenplum實現了基於數據庫的分佈式數據存儲和並行計算（GoogleMapReduce實現的是基於文件的分佈式數據存儲和計算，咱們事後會比較這兩種方法的優劣性）。

 

 

話說當年Greenplum（當時仍是一個Startup公司，創始人家門口有一棵青梅 ——greenplum，所以而得名）召集了十幾位業界大咖（聽說來自google、yahoo、ibm和TD），說幹就幹，花了1年多的時間完成最初的版本設計和開發，用軟件實現了在開放X86平臺上的分佈式並行計算，不依賴於任何專有硬件，達到的性能卻遠遠超過傳統高昂的專有系統。

 

你們都知道Greenplum的數據庫引擎層是基於著名的開源數據庫Postgresql的（下面會分析爲何採用Postgresql，而不是mysql等等），可是Postgresql是單實例數據庫，怎麼能在多個X86服務器上運行多個實例且實現並行計算呢？爲了這，Interconnnect大神器出現了。在那1年多的時間裏，大拿們很大一部分精力都在不斷的設計、優化、開發Interconnect這個核心軟件組件。最終實現了對同一個集羣中多個Postgresql實例的高效協同和並行計算，interconnect承載了並行查詢計劃生產和Dispatch分發（QD）、協調節點上QE執行器的並行工做、負責數據分佈、Pipeline計算、鏡像複製、健康探測等等諸多任務。

 

在Greenplum開源之前，聽說一些廠商也有開發MPP數據庫的打算，其中最難的部分就是在Interconnect上遇到了障礙，可見這項技術的關鍵性。

 

Greenplum爲何選擇Postgreeql作輪子

 

說到這，也許有同窗會問，爲何Greenplum 要基於Postgresql? 這個問題大體引伸出兩個問題：

 

一、爲何不從數據庫底層進行從新設計研發？

 

 道理比較簡單，所謂術業有專攻，就像製造跑車的不會親自生產車輪同樣，咱們只要專一在分佈式技術中最核心的並行處理技術上面，協調咱們下面的輪子跑的更快更穩纔是咱們的最終目標。而數據庫底層組件就像車輪同樣，通過幾十年磨礪，數據庫引擎技術已經很是成熟，大可沒必要去從新設計開發，並且把數據庫底層交給其它專業化組織來開發（對應到Postgresql就是社區），還可充分利用到社區的源源不斷的創新能力和資源，讓產品保持持續旺盛的生命力。

 

這也是咱們在用戶選型時，一般建議用戶考察一下底層的技術支撐是否是有好的組織和社區支持的緣由，若是缺少這方面的有力支持或獨自閉門造輪，那就有理由爲那個車的前途感到擔心，一個簡單判斷的標準就是看看底下那個輪子有多少人使用，有多少人爲它貢獻力量。

 

二、爲何是Postgresql而不是其它的？

 

我想你們可能主要想問爲何是Postgresql而不是Mysql（對不起，還有不少開源關係型數據庫，但相比這兩個主流開源庫，但和這兩個大牛比起來，實在不在一個起跑線上）。本文無心去從詳細技術點上PK這兩個數據庫孰優孰劣（網上不少比較），我相信它們的存在都有各自的特色，它們都有成熟的開源社區作支持，有各自的龐大的fans羣衆基礎。我的之見，Greenplum選擇Postgressql有如下考慮：

 

1）Postgresql號稱最早進的數據庫（官方主頁「The world’s most advanced open source database」）,且無論這是否是自我標榜，就從OLAP分析型方面來考察，如下幾點Postgresql確實勝出一籌：

1

PG有很是強大 SQL 支持能力和很是豐富的統計函數和統計語法支持，除對ANSI SQL徹底支持外，還支持好比分析函數（SQL2003 OLAP window函數），還能夠用多種語言來寫存儲過程，對於Madlib、R的支持也很好。這一點上MYSQL就差的很遠，不少分析功能都不支持，而Greenplum做爲MPP數據分析平臺，這些功能都是必不可少的。

 2

Mysql查詢優化器對於子查詢、複製查詢如多表關聯、外關聯的支持等較弱，特別是在關聯時對於三大join技術：hash join、merge join、nestloop join的支持方面，Mysql只支持最後一種nestloop join（聽說將來會支持hash join），而多個大表關聯分析時hash join是必備的利器，缺乏這些關鍵功能很是致命，將難於在OLAP領域充當大任。咱們最近對基於MYSQL的某內存分佈式數據庫作對比測試時，發現其優勢是OLTP很是快，TPS很是高（輕鬆搞定幾十萬），但一到複雜多表關聯性能就立馬降低，即便其具備內存計算的功能也無能爲力，就其因估計仍是受到mysql在這方面限制。

 

2）擴展性方面，Postgresql比mysql也要出色許多，Postgres天生就是爲擴展而生的，你能夠在PG中用Python、C、Perl、TCL、PLSQL等等語言來擴展功能，在後續章節中，我將展示這種擴展是如何的方便，另外，開發新的功能模塊、新的數據類型、新的索引類型等等很是方便，只要按照API接口開發，無需對PG從新編譯。PG中contrib目錄下的各個第三方模塊，在GP中的postgis空間數據庫、R、Madlib、pgcrypto各種加密算法、gptext全文檢索都是經過這種方式實現功能擴展的。
 

3）在諸如ACID事物處理、數據強一致性保證、數據類型支持、獨特的MVCC帶來高效數據更新能力等還有不少方面，Postgresql彷佛在這些OLAP功能上都比mysql更甚一籌。

 

4）最後，Postgresql許但是仿照BSD許可模式的，沒有被大公司控制，社區比較純潔，版本和路線控制很是好，基於Postgresql可以讓用戶擁有更多自主性。反觀Mysql的社區現狀和衆多分支（如MariaDB），確實夠亂的。

 

好吧，再也不過多列舉了，這些特色已經足夠了，聽說不少互聯網公司採用Mysql來作OLTP的同時，卻採用Postgresql來作內部的OLAP分析數據庫，甚至對新的OLTP系統也直接採用Postgresql。

   

相比之下，Greenplum更強悍，把Postgresql做爲實例（注：該實例非Oracle實例概念，這裏指的是一個分佈式子庫）架構在Interconnect下，在Interconnect的指揮協調下，數十個甚至數千個Sub Postgresql數據庫實例同時開展並行計算，並且，這些Postgresql之間採用share-nothing無共享架構，從而更將這種並行計算能力發揮到極致。

 

除此以外，MPP採用兩階段提交和全局事務管理機制來保證集羣上分佈式事務的一致性，Greenplum像Postgresql同樣知足關係型數據庫的包括ACID在內的全部特徵。

    

 

從上圖進而能夠看到，Greenplum的最小並行單元不是節點層級，而是在實例層級，安裝過Greenplum的同窗應該都看到每一個實例都有本身的postgresql目錄結構，都有各自的一套Postgresql數據庫守護進程（甚至能夠經過UT模式進行單個實例的訪問）。正由於如此，甚至一個運行在單節點上的GreenplumDB也是一個小型的並行計算架構，通常一個節點配置6~8個實例，至關於在一個節點上有6~8個Postgresql數據庫同時並行工做，優點在於能夠充分利用到每一個節點的全部CPU和IO 能力。

 

Greenplum單個節點上運行能力比其它數據庫也快不少，若是運行在多節點上，其提供性能幾乎是線性的增加，這樣一個集羣提供的性能可以很輕易的達到傳統數據庫的數百倍甚至數千倍，所管理數據存儲規模達到100TB~數PB，而你在硬件上的投入，僅僅是數臺通常的X86服務器和普通的萬兆交換機。

 

Greenplum採用Postgresl做爲底層引擎，良好的兼容了Postgresql的功能，Postgresql中的功能模塊和接口基本上99%均可以在Greenplum上使用，例如odbc、jdbc、oledb、perldbi、python psycopg2等，因此Greenplum與第三方工具、BI報表集成的時候很是容易；對於postgresql的contrib中的一些經常使用模塊Greenplum提供了編譯後的模塊開箱即用，如oraface、postgis、pgcrypt等，對於其它模塊，用戶能夠自行將contrib下的代碼與Greenplum的include頭文件編譯後，將動態so庫文件部署到全部節點就可進行測試使用了。有些模塊仍是很是好用的，例如oraface，基本上集成了Oracle經常使用的函數到Greenplum中，曾經在一次PoC測試中，用戶提供的22條Oracle SQL語句，不作任何改動就能運行在Greenplum上。

 

最後特別提示，Greenplum毫不僅僅只是簡單的等同於「Postgresql+interconnect並行調度+分佈式事務兩階段提交」，Greenplum還研發了很是多的高級數據分析管理功能和企業級管理模塊，這些功能都是Postgresql沒有提供的：

   

• 外部表並行數據加載

• 可更新數據壓縮表

• 行、列混合存儲

• 數據表多級分區

• Bitmap索引

• Hadoop外部表

• Gptext全文檢索

• 並行查詢計劃優化器和Orca優化器

• Primary/Mirror鏡像保護機制

• 資源隊列管理

• WEB/Brower監控

   

Greenplum的藝術，一切皆並行（Parallel Everything）

 

前面介紹了Greenplum的分佈式並行計算架構，其中每一個節點上全部Postgresql實例都是並行工做的，這種並行的Style貫穿了Greenplum功能設計的方方面面：外部表數據加載是並行的、查詢計劃執行是並行的、索引的創建和使用是並行的，統計信息收集是並行的、表關聯（包括其中的重分佈或廣播及關聯計算）是並行的，排序和分組聚合都是並行的，備份恢復也是並行的，甚而數據庫啓停和元數據檢查等維護工具也按照並行方式來設計，得益於這種無所不在的並行，Greenplum在數據加載和數據計算中表現出強悍的性能，某行業客戶深有體會:一樣2TB左右的數據，在Greenplum中不到一個小時就加載完成了，而在用戶傳統數據倉庫平臺上耗時半天以上。

 

在該用戶的生產環境中，1個數百億表和2個10多億條記錄表的全表關聯中（只有on關聯條件，不帶where過濾條件，其中一個10億條的表計算中須要重分佈），Greenplum僅耗時數分鐘就完成了，當其它傳統數據平臺還在爲千萬級或億級規模的表關聯性能發愁時，Greenplum已經一騎絕塵，在百億級規模以上表關聯中展現出上佳的表現。

 

Greenplum創建在Share-nothing無共享架構上，讓每一顆CPU和每一塊磁盤IO都運轉起來，無共享架構將這種並行處理髮揮到極致。相比一些其它傳統數據倉庫的Sharedisk架構，後者最大瓶頸就是在IO吞吐上，在大規模數據處理時，IO沒法及時feed數據給到CPU，CPU資源處於wait 空轉狀態，沒法充分利用系統資源，致使SQL效率低下：

 

一臺內置16塊SAS盤的X86服務器，每秒的IO數據掃描性能約在2000MB/s左右，能夠想象，20臺這樣的服務器構成的機羣IO性能是40GB/s，這樣超大的IO吞吐是傳統的 Storage難以達到的。

 

(MPP Share-nothing架構實現超大IO吞吐能力)

 

另外，Greenplum仍是創建在實例級別上的並行計算，可在一次SQL請求中利用到每一個節點上的多個CPU CORE的計算能力，對X86的CPU超線程有很好的支持，提供更好的請求響應速度。在PoC中接觸到其它一些國內外基於開放平臺的MPP軟件，大都是創建在節點級的並行，單個或少許的任務時沒法充分利用資源，致使系統加載和SQL執行性能不高。

 

記憶較深的一次PoC公開測試中，有廠商要求在測試中關閉CPU超線程，估計和這個緣由有關（由於沒有辦法利用到多個CPU core的計算能力，還不如關掉超線程以提升單core的能力），但即便是這樣，在那個測試中，測試性能也大幅低於Greenplum（那個測試中，各廠商基於客戶提供的徹底相同的硬件環境，Greenplum是惟一一家完成全部測試的，特別在混合負載測試中，Greenplum的80併發耗時3個多小時就成功完成了，其它廠商大都沒有完成此項測試，惟一完成的一家耗時40多小時）

 

前文提到，得益於Postgresql的良好擴展性（這裏是extension，不是scalability），Greenplum 能夠採用各類開發語言來擴展用戶自定義函數（UDF）（我我的是Python和C的fans，後續章節與你們分享）。這些自定義函數部署到Greenplum後可用充分享受到實例級別的並行性能優點，咱們強烈建議用戶將庫外的處理邏輯，部署到用MPP數據庫的UDF這種In-Database的方式來處理，你將得到意想不到的性能和方便性；例如咱們在某客戶實現的數據轉碼、數據脫敏等，只須要簡單的改寫原有代碼後部署到GP中，經過並行計算得到數十倍性能提升。

 

另外，GPTEXT（lucent全文檢索）、Apache Madlib（開源挖掘算法）、SAS algorithm、R都是經過UDF方式實如今Greenplum集羣中分佈式部署，從而得到庫內計算的並行能力。這裏能夠分享的是，SAS曾經作過測試，對1億條記錄作邏輯迴歸，採用一臺小型機耗時約4個多小時，經過部署到Greenplum集羣中，耗時不到2分鐘就所有完成了。以GPEXT爲例，下圖展示了Solr全文檢索在Greenplum中的並行化風格。

 

 

最後，也許有同窗會有問題，Greenplum採用Master-slave架構，Master是否會成爲瓶頸？徹底不用擔憂，Greenplum全部的並行任務都是在Segment數據節點上完成後，Master只負責生成和優化查詢計劃、派發任務、協調數據節點進行並行計算。

 

按照咱們在用戶現場觀察到的，Master上的資源消耗不多有超過20%狀況發生，由於Segment纔是計算和加載發生的場所（固然，在HA方面，Greenplum提供Standby Master機制進行保證）。

 

再進一步看，Master-Slave架構在業界的大數據分佈式計算和雲計算體系中被普遍應用，你們能夠看到，如今主流分佈式系統都是採用Master-Slave架構，包括：Hadoop FS、Hbase、MapReduce、Storm、Mesos……無一例外都是Master-Slave架構。相反，採用Multiple Active Master 的軟件系統，須要消耗更多資源和機制來保證元數據一致性和全局事務一致性，特別是在節點規模較多時，將致使性能降低，嚴重時可能致使多Master之間的腦裂引起嚴重系統故障。

 

Greenplum不能作什麼？

 

Greenplum最大的特色總結就一句話：基於低成本的開放平臺基礎上提供強大的並行數據計算性能和海量數據管理能力。這個能力主要指的是並行計算能力，是對大任務、複雜任務的快速高效計算，但若是你期望MPP並行數據庫可以像OLTP數據庫同樣，在極短的時間處理大量的併發小任務，這個並不是MPP數據庫所長。請牢記，並行和併發是兩個徹底不一樣的概念，MPP數據庫是爲了解決大問題而設計的並行計算技術，而不是大量的小問題的高併發請求。

 

再通俗點說，Greenplum主要定位在OLAP領域，利用Greenplum MPP數據庫作大數據計算或分析平臺很是適合，例如:數據倉庫系統、ODS系統、ACRM系統、歷史數據管理系統、電信流量分析系統、移動信令分析系統、SANDBOX自助分析沙箱、數據集市等等。

 

而MPP數據庫都不擅長作OLTP交易系統，所謂交易系統，就是高頻的交易型小規模數據插入、修改、刪除，每次事務處理的數據量不大，但每秒鐘都會發生幾十次甚至幾百次以上交易型事務 ，這類系統的衡量指標是TPS，適用的系統是OLTP數據庫或相似Gemfire的內存數據庫。

 

Greenplum MPP 與 Hadoop

 

MPP和Hadoop都是爲了解決大規模數據的並行計算而出現的技術，兩種技術的類似點在於：

   

• 分佈式存儲數據在多個節點服務器上

•  採用分佈式並行計算框架

• 支持橫向擴展來提升總體的計算能力和存儲容量

• 都支持X86開放集羣架構

 

但兩種技術在數據存儲和計算方法上，也存在不少顯而易見的差別：

   

• MPP按照關係數據庫行列表方式存儲數據（有模式），Hadoop按照文件切片方式分佈式存儲（無模式）

• 二者採用的數據分佈機制不一樣，MPP採用Hash分佈，計算節點和存儲緊密耦合，數據分佈粒度在記錄級的更小粒度（通常在1k如下）；Hadoop FS按照文件切塊後隨機分配，節點和數據無耦合，數據分佈粒度在文件塊級（缺省64MB）。

• MPP採用SQL並行查詢計劃，Hadoop採用Mapreduce框架

   

基於以上不一樣，體如今效率、功能等特性方面也大不相同：

 

1.計算效率比較：

 

先說說Mapreduce技術，Mapreduce相比而言是一種較爲蠻力計算方式（業內曾經甚至有聲音質疑MapReduce是反潮流的），數據處理過程分紅Map-〉Shuffle-〉Reduce的過程，相比MPP 數據庫並行計算而言，Mapreduce的數據在計算前未經整理和組織（只是作了簡單數據分塊，數據無模式），而MPP預先會把數據有效的組織（有模式），例如：行列表關係、Hash分佈、索引、分區、列存儲等、統計信息收集等，這就決定了在計算過程當中效率大爲不一樣：

1

MAP效率對比：

 

• Hadoop的MAP階段須要對數據的再解析，而MPP數據庫直接取行列表，效率高

• Hadoop按照64MB分拆文件，並且數據不能保證在全部節點均勻分佈，所以MAP過程的並行化程度低；MPP數據庫按照數據記錄拆分和Hash分佈，粒度更細，數據分佈在全部節點中很是均勻，並行化程度很高

•  Hadoop HDFS沒有靈活的索引、分區、列存儲等技術支持，而MPP一般利用這些技術大幅提升數據的檢索效率；

 2

Shuffle效率對比：（Hadoop  Shuffle 對比MPP計算中的重分佈）

 

• 因爲Hadoop數據與節點的無關性，所以Shuffle是基本避免不了的；而MPP數據庫對於相同Hash分佈數據不須要重分佈，節省大量網絡和CPU消耗；

• Mapreduce沒有統計信息，不能作基於cost-base的優化；MPP數據庫利用統計信息能夠很好的進行並行計算優化，例如，對於不一樣分佈的數據，能夠在計算中基於Cost動態的決定最優執行路徑，如採用重分佈仍是小表廣播

 3

Reduce效率對比：（對比於MPP數據庫的SQL執行器-executor）

 

• Mapreduce缺少靈活的Join技術支持，MPP數據庫能夠基於COST來自動選擇Hash join、Merger join和Nestloop join，甚至能夠在Hash join經過COST選擇小表作Hash，在Nestloop Join中選擇index提升join性能等等；

• MPP數據庫對於Aggregation（聚合）提供Multiple-agg、Group-agg、sort-agg等多種技術來提供計算性能，Mapreuce須要開發人員本身實現；

 4

另外，Mapreduce在整個MAP->Shuffle->Reduce過程當中經過文件來交換數據，效率很低，MapReduce要求每一個步驟間的數據都要序列化到磁盤，這意味着MapReduce做業的I/O成本很高，致使交互分析和迭代算法開銷很大，MPP數據庫採用Pipline方式在內存數據流中處理數據，效率比文件方式高不少；

 

總結以上幾點，MPP數據庫在計算並行度、計算算法上比Hadoop更加SMART，效率更高；在客戶現場的測試對比中，Mapreduce對於單表的計算尚可，但對於複雜查詢，如多表關聯等，性能不好，性能甚至只有MPP數據庫的幾十分之一甚至幾百分之一，下圖是基於MapReduce的Hive和Greenplum MPP在TPCH 22個SQL測試性能比較：（相同硬件環境下）

 

 

還有，某國內知名電商在其數據分析平臺作過驗證，一樣硬件條件下，MPP數據庫比Hadoop性能快12倍以上。

 

2.功能上的對比

 

MPP數據庫採用SQL做爲主要交互式語言，SQL語言簡單易學，具備很強數據操縱能力和過程語言的流程控制能力，SQL語言是專門爲統計和數據分析開發的語言，各類功能和函數琳琅滿目，SQL語言不只適合開發人員，也適用於分析業務人員，大幅簡化了數據的操做和交互過程。

 

而對MapReduce編程明顯是困難的，在原生的Mapreduce開發框架基礎上的開發，須要技術人員諳熟於JAVA開發和並行原理，不只業務分析人員沒法使用，甚至技術人員也難以學習和操控。爲了解決易用性的問題，近年來SQL-0N-HADOOP技術大量涌現出來，幾乎成爲當前Hadoop開發使用的一個技術熱點趨勢。

 

這些技術包括：Hive、Pivotal HAWQ、SPARK SQL、Impala、Prest、Drill、Tajo等等不少，這些技術有些是在Mapreduce上作了優化，例如Spark採用內存中的Mapreduce技術，號稱性能比基於文件的的Mapreduce提升10倍；有的則採用C/C++語言替代Java語言重構Hadoop和Mapreuce（如MapR公司及國內某知名電商的大數據平臺）；而有些則直接繞開了Mapreduce另起爐竈，如Impala、hawq採用借鑑MPP計算思想來作查詢優化和內存數據Pipeline計算，以此來提升性能。

 

雖然SQL-On-Hadoop比原始的Mapreduce雖然在易用上有所提升，但在SQL成熟度和關係分析上目前還與MPP數據庫有較大差距：

   

• 上述系統，除了HAWQ外，對SQL的支持都很是有限，特別是分析型複雜SQL，如SQL 2003 OLAP WINDOW函數，幾乎都不支持，以TPC-DS測試（用於評測決策支持系統（大數據或數據倉庫）的標準SQL測試集,99個SQL）爲例，包括SPARK、Impala、Hive只支持其中1/3左右；

 

• 因爲HADOOP 自己Append-only特性，SQL-On-Hadoop大多不支持數據局部更新和刪除功能(update/delete)；而有些，例如Spark計算時，須要預先將數據裝載到DataFrames模型中；

 

• 基本上都缺乏索引和存儲過程等等特徵

 

• 除HAWQ外，大多對於ODBC/JDBC/DBI/OLEDB/.NET接口的支持有限，與主流第三方BI報表工具兼容性不如MPP數據庫

 

•  SQL-ON-HADOOP不擅長於交互式（interactive）的Ad-hoc查詢，多經過預關聯的方式來規避這個問題；另外，在併發處理方面能力較弱，高併發場景下，須要控制計算請求的併發度，避免資源過載致使的穩定性問題和性能降低問題；

 

3.架構靈活性對比：

 

前文提到，爲保證數據的高性能計算，MPP數據庫節點和數據之間是緊耦合的，相反，Hadoop的節點和數據是沒有耦合關係的。這就決定了Hadoop的架構更加靈活-存儲節點和計算節點的無關性，這體如今如下2個方面：

1

擴展性方面

 

• Hadoop架構支持單獨增長數據節點或計算節點，依託於Hadoop的SQL-ON-HADOOP系統，例如HAWQ、SPARK都可單獨增長計算層的節點或數據層的HDFS存儲節點，HDFS數據存儲對計算層來講是透明的；

• MPP數據庫擴展時，通常狀況下是計算節點和數據節點一塊兒增長的，在增長節點後，須要對數據作重分佈才能保證數據與節點的緊耦合（從新hash數據），進而保證系統的性能；Hadoop在增長存儲層節點後，雖然也須要Rebalance數據，但相較MPP而言，不是那麼緊迫。

 2

節點退服方面

 

•  Hadoop節點宕機退服，對系統的影響較小，而且系統會自動將數據在其它節點擴充到3份；MPP數據庫節點宕機時，系統的性能損耗大於Hadoop節點。

 

Pivotal將GPDB 的MPP技術與Hadoop分佈式存儲技術結合，推出了HAWQ高級數據分析軟件系統，實現了Hadoop上的SQL-on-HADOOP，與其它的SQL-on-HADOOP系統不一樣，HAWQ支持徹底的SQL語法 和SQL 2003 OLAP 語法及Cost-Base的算法優化，讓用戶就像使用關係型數據庫同樣使用Hadoop。底層存儲採用HDFS，HAWQ實現了計算節點和HDFS數據節點的解耦，採用MR2.0的YARN來進行資源調度，同時具備Hadoop的靈活伸縮的架構特性和MPP的高效能計算能力.

 

固然，有得也有所失，HAWQ的架構比Greenplum MPP數據庫靈活，在得到架構優越性的同時，其性能比Greenplum MPP數據庫要低一倍左右，但得益於MPP算法的紅利，HAWQ性能仍大幅高於其它的基於MapReduce的SQL-on-HADOOP系統。

 

4.選擇MPP仍是Hadoop

 

總結一下，Hadoop MapReduce和SQL-on-HADOOP技術目前都還不夠成熟，性能和功能上都有不少待提高的空間，相比之下，MPP數據在數據處理上更加SMART，要填平或縮小與MPP數據庫之間的性能和功能上的GAP，Hadoop還有很長的一段路要走。

 

就目前來看，我的認爲這兩個系統都有其適用的場景，簡單來講，若是你的數據須要頻繁的被計算和統計、而且你但願具備更好的SQL交互式支持和更快計算性能及複雜SQL語法的支持，那麼你應該選擇MPP數據庫，SQL-on-Hadoop技術尚未Ready。特別如數據倉庫、集市、ODS、交互式分析數據平臺等系統，MPP數據庫有明顯的優點。

 

而若是你的數據加載後只會被用於讀取少數次的任務和用於少數次的訪問，並且主要用於Batch（不須要交互式），對計算性能不是很敏感，那Hadoop也是不錯的選擇，由於Hadoop不須要你花費較多的精力來模式化你的數據，節省數據模型設計和數據加載設計方面的投入。這些系統包括：歷史數據系統、ETL臨時數據區、數據交換平臺等等。

 

總之，Bear in mind，千萬不要爲了大數據而大數據（就好像不要爲了創新而創新一個道理），不然，你項目最後的產出與你的最初設想可能將差之千里，行業內不乏失敗案例。

 

最後，提一下，Greenplum MPP數據庫支持用「Hadoop外部表」方式來訪問、加載Hadoop FS的數據，雖然Greenplum的Hadoop外部表性能大幅低於MPP內部表，但比Hadoop 自身的HIVE要高不少（在某金融客戶的測試結果，比HIVE高8倍左右），所以能夠考慮在項目中同時部署MPP數據庫和Hadoop，MPP用於交互式高性能分析，Hadoop用於數據Staging、MPP的數據備份或一些ETL batch的數據清洗任務，二者相輔相成，在各自最擅長的場景中發揮其特性和優點。

 

 

5.將來GP發展之路

 

過去十年，IT技術潮起潮落髮生着時刻不停的變化，而在這變化中的不變就是走向開放和開源的道路，即將到來的偉大變革是雲計算時代的到來，任何IT技術，從硬件到軟件到服務，都逃不過要接受雲計算的洗禮，不能遇上時代潮流的技術和公司都將被無情的淘汰。大數據也要擁抱雲計算，大數據將做爲一種數據服務來提供（DaaS-Data as A Service），依靠雲提供共享的、彈性、按需分配的大數據計算和存儲的服務。

 

Greenplum MPP數據庫從已一開始就是開放的技術，而且在2015年年末已經開源和成立社區（在開源第一天就有上千個Download），能夠說，Greenplum已經不只僅只是Pivotal公司一家的產品，咱們相信愈來愈多組織和我的會成爲Greenplum的Contributor貢獻者，隨着社區的發展將推進Greenplum MPP數據庫走向新的高速發展旅程。（分享一下開源的直接好處，最近咱們某用戶的一個特殊需求，加載數據中有回車等特殊字符，咱們下載了GP外部表gpfdist源代碼，不到一天就輕鬆搞定問題）

 

Greenplum也正在積極的擁抱雲計算，Cloud Foundry的PaaS雲平臺正在技術考慮把Greenplum MPP作爲DaaS服務來提供，對於Mesos或其它雲計算技術的愛好者，也能夠考慮採用容器鏡像技術+集羣資源框架管理技術來部署Greenplum,從而能夠實如今公共計算資源集羣上的MPP敏捷部署和資源共享與分配。

總之，相信沿着開放、開源、雲計算的路線繼續前行，Greenplum MPP數據庫在新的時代將保持旺盛的生命力，繼續高速發展。

 

轉自https://dbaplus.cn/news-21-341-1.html