Greenplum介绍

一、Greenplum的发展历史

Greenplum的发展可以分为下面6个阶段:


图 1 Greenplum时间线

Postgres关系型数据库。Postgres是UC Berkeley开发的关系型数据库,现已更名为PostgreSQL。PostgerSQL官网介绍自己是最先进的数据库,有强大的SQL支持能力,扩展性好,并且支持空间扩展。通过空间数据引擎PostGIS的支持可以存储和操作空间数据。

SQL queries on Big Data。Greenplum初步成型,由于数据越存越多,如何在大量数据中继续使用SQL来进行查询成了一个需要解决的问题。Greenplum开发者在X86架构和Postgres数据库的基础上,结合Postgres社区和应用生态使用MPP架构将Postgres实例组织起来,并通过MPP后端来实现存储和查询。

Pivotal商业公司。Emc2公司将Greenplum与分布式缓存GemFile一起结合形成了一款专注于OLAP系统的数据引擎产品,并以这个产品为核心组建了新的公司Pivotal。

收购MoreVRP。最初的Greenplum希望对每一次query操作都能做到尽可能的快,这样使得所有的资源都被一次query占用。然而当并发多的时候,会造成query效果变差。因此Greenplum最初将query按类型划分到了不同的队列,然后按优先级给队列分配资源,进而解决了这个问题。但是因为query是在不断变动的,这时候这种策略也需要不断调整,因此Pivotal收购了一家专注于动态配置数据库的公司MoreVRP。

发布HAWQ。由于市场上越来越多的客户将数据存放在HDFS上,基于Hadoop的Hive和Impala带给了Greenplum也受到了很大的冲击。Pivotal因此推出了一个处理HDFS上数据的解决方案HAWQ,但是HAWQ在HDFS上使用的是Greenplum专利格式来存储数据,其他的软件不能对这个格式进行操作,并不方便。

开源Greenplum。2015年,Pivotal公司拥抱了开源社区,将Greenplum开源。

二、Greenplum的几个关键词

1、shared-nothing

  Shared Everthting:一般是针对单个主机,完全透明共享CPU/MEMORY/IO,并行处理能力差,典型的代表SQLServer。 shared-everything架构优点很明显,但是网络,硬盘很容易就会成为系统瓶颈。

  Shared Disk:各个处理单元使用自己的私有 CPU和Memory,共享磁盘系统。典型的代表Oracle Rac, 它是数据共享,可通过增加节点来提高并行处理的能力,扩展能力较好。其类似于SMP(对称多处理)模式,但是当存储器接口达到饱和的时候,增加节点并不能获得更高的性能 。

    Shared Nothing:各个处理单元都有自己私有的CPU/内存/硬盘等,不存在共享资源,各处理单元之间通过协议通信,并行处理和扩展能力更好。各节点相互独立,各自处理自己的数据,处理后的结果可能向上层汇总或在节点间流转。Share-Nothing架构在扩展性和成本上都具有明显优势。

1

2

3

2、MPP

  大规模并行处理系统是由许多松耦合处理单元组成的,借助MPP这种高性能的系统架构,Greenplum可以将TB级的数据仓库负载分解,并使用所有的系统资源并行处理单个查询。

1

3、MVCC

  与事务型数据库系统通过锁机制来控制并发访问的机制不同, GPDB使用多版本控制(Multiversion Concurrency Control/MVCC)保证数据一致性。 这意味着在查询数据库时,每个事务看到的只是数据的快照,其确保当前的事务不会看到其他事务在相同记录上的修改。据此为数据库的每个事务提供事务隔离。

    MVCC以避免给数据库事务显式锁定的方式,最大化减少锁争用以确保多用户环境下的性能。在并发控制方面,使用MVCC而不是使用锁机制的最大优势是, MVCC对查询(读)的锁与写的锁不存在冲突,并且读与写之间从不互相阻塞。

1

2

3

三、Greenplum架构

Greenplum主要由Master节点、Segment节点、interconnect三大部分组成。Greenplum master是Greenplum数据库系统的入口,接受客户端连接及提交的SQL语句,将工作负载分发给其它数据库实例(segment实例),由它们存储和处理数据。Greenplum interconnect负责不同PostgreSQL实例之间的通信。Greenplum segment是独立的PostgreSQL数据库,每个segment存储一部分数据。大部分查询处理都由segment完成。

Master节点不存放任何用户数据,只是对客户端进行访问控制和存储表分布逻辑的元数据


Segment节点负责数据的存储,可以对分布键进行优化以充分利用Segment节点的io性能来扩展整集群的io性能

存储方式可以根据数据热度或者访问模式的不同而使用不同的存储方式。一张表的不同数据可以使用不同的物理存储方式:行存储、列存储、外部表

3.1 大规模数据存储

(1)Greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。数据库的瓶颈经常发生在I/O方面,数据库的诸多性能问题最终总能归罪到I/O身上,久而久之,IO瓶颈成为了数据库性能的永恒的话题。

(2)Greenplum采用分而治之的办法,将数据规律的分布到节点上,充分利用Segment主机的IO能力,以此让系统达到最大的IO能力(主要是带宽)。

(3)在Greenplum中每个表都是分布在所有节点上的。Master节点首先通过对表的某个或多个列进行hash运算,然后根据hash结果将表的数据分布到Segment节点中。整个过程中Master节点不存放任何用户数据,只是对客户端进行访问控制和存储表分布逻辑的元数据。

图 2 Greenplum存储结构

Greenplum提供称为“多态存储”的灵活存储方式。多态存储可以根据数据热度或者访问模式的不同而使用不同的存储方式。一张表的不同数据可以使用不同的物理存储方式。支持的存储方式包含:

行存储:行存储是传统数据库常用的存储方式,特点是访问比较快,多列更新比较容易。

列存储:列存储按列保存,不同列的数据存储在不同的地方(通常是不同文件中)。适合一次只访问宽表中某几个字段的情况。列存储的另外一个优势是压缩比高。

外部表:数据保存在其他系统中例如HDFS,数据库只保留元数据信息。

3.2 并行查询计划和执行

下图为一个简单SQL语句,从两张表中找到2008年的销售数据。图中右边是这个SQL的查询计划。从生成的查询计划树中看到有三种不同的颜色,颜色相同表示做同一件事情,我们称之为分片/切片(Slice)。最下层的橙色切片中有一个重分发节点,这个节点将本节点的数据重新分发到其他节点上。中间绿色切片表示分布式数据关联(HashJoin)。最上面切片负责将各个数据节点收到的数据进行汇总。


然后看看这个查询计划的执行。主节点(Master)上的调度器(QD)会下发查询任务到每个数据节点,数据节点收到任务后(查询计划树),创建工作进程(QE)执行任务。如果需要跨节点数据交换(例如上面的HashJoin),则数据节点上会创建多个工作进程协调执行任务。不同节点上执行同一任务(查询计划中的切片)的进程组成一个团伙(Gang)。数据从下往上流动,最终Master返回给客户端。


3.3 并行数据加载

(1)并行加载技术充分利用分布式计算和分布式存储的优势,保证发挥出每一块Disk的I/O资源

(2)并行加载比串行加载,速度提高40-50倍以上,减少ETL窗口时间

(3)增加Segment和ETL Server,并行加载速度呈线性增长


四、应用生态


图3 Greenplum应用生态

在标准的X86平台上,Greenplum与其它异构数据库、BI工具、挖掘预测工具、ETL工具和J2EE/.NET应用程序均有良好的连通性。

利用Greenplum外部表技术,映射Hadoop集群中的HDFS、HIVE、HBASE 等多种格式数据,使用ANSI SQL访问,数据无需中间落地

Greenplum对亚马逊S3的全面读写支持

Pivotal又刚刚宣布了Greenplum数据库对微软Azure云平台的支持,用户可以在微软Azure云平台上方便地使用到Greenplum

五、Greenplum特点

借助MPP,Greenplum在大型数据集上执行复杂SQL分析的速度比很多解决方案都要快。Greenplum也带来了其它开源方案中没有的数据管理质量特性、升级和扩展能力。同时,Greenplum也降低了大规模实时数据分析的门槛,相比于 Map-Reduce,SQL语法简单,功能强大,易上手,使用和开发成本低,易于对接其他第三方数据分析工具。

标准SQL接口,比MapReduce接入更方便

完整的分布式事务能力,确保强数据一致性

近乎线性的在线扩展能力

高并发数据加载技术

高灵活的行、列以及混合存储及压缩技术

高可用技术方案

支持多方式的授权管理及审计,表级别粒度

丰富的生态系统,便捷对接hadoop等

---------------------

作者:Du_咳咳

来源:CSDN

原文:https://blog.csdn.net/dcpkeke/article/details/79003170

版权声明:本文为博主原创文章,转载请附上博文链接!

©著作权归作者所有,转载或内容合作请联系作者
  • 序言:七十年代末,一起剥皮案震惊了整个滨河市,随后出现的几起案子,更是在滨河造成了极大的恐慌,老刑警刘岩,带你破解...
    沈念sama阅读 159,015评论 4 362
  • 序言:滨河连续发生了三起死亡事件,死亡现场离奇诡异,居然都是意外死亡,警方通过查阅死者的电脑和手机,发现死者居然都...
    沈念sama阅读 67,262评论 1 292
  • 文/潘晓璐 我一进店门,熙熙楼的掌柜王于贵愁眉苦脸地迎上来,“玉大人,你说我怎么就摊上这事。” “怎么了?”我有些...
    开封第一讲书人阅读 108,727评论 0 243
  • 文/不坏的土叔 我叫张陵,是天一观的道长。 经常有香客问我,道长,这世上最难降的妖魔是什么? 我笑而不...
    开封第一讲书人阅读 43,986评论 0 205
  • 正文 为了忘掉前任,我火速办了婚礼,结果婚礼上,老公的妹妹穿的比我还像新娘。我一直安慰自己,他们只是感情好,可当我...
    茶点故事阅读 52,363评论 3 287
  • 文/花漫 我一把揭开白布。 她就那样静静地躺着,像睡着了一般。 火红的嫁衣衬着肌肤如雪。 梳的纹丝不乱的头发上,一...
    开封第一讲书人阅读 40,610评论 1 219
  • 那天,我揣着相机与录音,去河边找鬼。 笑死,一个胖子当着我的面吹牛,可吹牛的内容都是我干的。 我是一名探鬼主播,决...
    沈念sama阅读 31,871评论 2 312
  • 文/苍兰香墨 我猛地睁开眼,长吁一口气:“原来是场噩梦啊……” “哼!你这毒妇竟也来了?” 一声冷哼从身侧响起,我...
    开封第一讲书人阅读 30,582评论 0 198
  • 序言:老挝万荣一对情侣失踪,失踪者是张志新(化名)和其女友刘颖,没想到半个月后,有当地人在树林里发现了一具尸体,经...
    沈念sama阅读 34,297评论 1 242
  • 正文 独居荒郊野岭守林人离奇死亡,尸身上长有42处带血的脓包…… 初始之章·张勋 以下内容为张勋视角 年9月15日...
    茶点故事阅读 30,551评论 2 246
  • 正文 我和宋清朗相恋三年,在试婚纱的时候发现自己被绿了。 大学时的朋友给我发了我未婚夫和他白月光在一起吃饭的照片。...
    茶点故事阅读 32,053评论 1 260
  • 序言:一个原本活蹦乱跳的男人离奇死亡,死状恐怖,灵堂内的尸体忽然破棺而出,到底是诈尸还是另有隐情,我是刑警宁泽,带...
    沈念sama阅读 28,385评论 2 253
  • 正文 年R本政府宣布,位于F岛的核电站,受9级特大地震影响,放射性物质发生泄漏。R本人自食恶果不足惜,却给世界环境...
    茶点故事阅读 33,035评论 3 236
  • 文/蒙蒙 一、第九天 我趴在偏房一处隐蔽的房顶上张望。 院中可真热闹,春花似锦、人声如沸。这庄子的主人今日做“春日...
    开封第一讲书人阅读 26,079评论 0 8
  • 文/苍兰香墨 我抬头看了看天上的太阳。三九已至,却和暖如春,着一层夹袄步出监牢的瞬间,已是汗流浃背。 一阵脚步声响...
    开封第一讲书人阅读 26,841评论 0 195
  • 我被黑心中介骗来泰国打工, 没想到刚下飞机就差点儿被人妖公主榨干…… 1. 我叫王不留,地道东北人。 一个月前我还...
    沈念sama阅读 35,648评论 2 274
  • 正文 我出身青楼,却偏偏与公主长得像,于是被迫代替她去往敌国和亲。 传闻我的和亲对象是个残疾皇子,可洞房花烛夜当晚...
    茶点故事阅读 35,550评论 2 270

推荐阅读更多精彩内容