海量數據處理利器greenplum——初識

本文轉自https://www.cnblogs.com/skyme/p/5779885.htmlhtml

簡介及適用場景

若是想在數據倉庫中快速查詢結果,可使用greenplum。node

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萬行的源代碼。oop

第六,Greenplum有不少合做夥伴,GPDB有完善的生態系統,能夠與不少企業級產品集成,譬如SAS,Cognos,Informatic,Tableau等;也能夠不少種開源軟件集成,譬如Pentaho,Talend 等。性能

greenplum起源

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

  • 互聯網行業通過以前近10年的由慢到快的發展,累積了大量信息和數據,數據在爆發式增加,這些海量數據急需新的計算方式,須要一場計算方式的革命;
  • 傳統的主機計算模式在海量數據面前,除了造價昂貴外,在技術上也難於知足數據計算性能指標,傳統主機的Scale-up模式遇到了瓶頸,SMP(對稱多處理)架構難於擴展,而且在CPU計算和IO吞吐上不能知足海量數據的計算需求;
  • 分佈式存儲和分佈式計算理論剛剛被提出來,Google的兩篇著名論文發表後引發業界的關注,一篇是關於GFS分佈式文件系統,另一篇是關於MapReduce 並行計算框架的理論,分佈式計算模式在互聯網行業特別是收索引擎和分詞檢索等方面得到了巨大成功。

下圖就是GFS的架構

image

整體架構

greenplum的整體架構以下:

image

  數據庫由Master Severs和Segment Severs經過Interconnect互聯組成。

Master主機負責:創建與客戶端的鏈接和管理;SQL的解析並造成執行計劃;執行計劃向Segment的分發收集Segment的執行結果;Master不存儲業務數據,只存儲數據字典。  

Segment主機負責:業務數據的存儲和存取;用戶查詢SQL的執行。 

  greenplum使用mpp架構。

image

    基本體系架構

image

master節點,能夠作成高可用的架構

image

master node高可用,相似於hadoop的namenode和second namenode,實現主備的高可用。

image

segments節點

image

並行管理

對於數據的裝載和性能監控。

image

並行備份和恢復。

image

數據訪問流程,數據分佈到不一樣顏色的節點上

image

查詢流程分爲查詢建立和查詢分發,計算後將結果返回。

image

對於存儲,將存儲的內容分佈到各個結點上。

image

對於數據的分佈,分爲hash分佈和隨機分佈兩種。

image

均勻分佈的狀況:

image

總結

GPDB從開始設計的時候就被定義成數據倉庫,若是是olap的應用,能夠嘗試使用GPDB。

相關文章
相關標籤/搜索