EMC Greenplum 技术浅析
2012-04-22 16:05
183 查看
说起Greenplum这个产品,最早是SUN来推他们的数据仓库产品DWA时接触到的,对这个由PgSQL堆叠出来的数据库产品还不是很了解,当时的焦点还在DWA本身的硬件上,当然不可否认,DWA还是有一些特点的。
后来,我们发现普通的PC+SAS磁盘具备非常好的吞吐能力,完全不逊于某些昂贵的存储设备。这样我们就尝试用PC+Greenplum搭建了一个环境,效果完全超出了我们的预期,吞吐量完全超过了我们的大型存储。从那时开始,我们不再迷信那些昂贵的主机和存储,开始尝试一些新的东西,比如用PC+SAS/SATA来堆叠廉价存储,用Greenplum来搭建数据仓库计算环境,搜索的hadoop集群,PC+SSD搭建OLTP数据库,用Intel
Nehalem来替代小型机等等。
昨天,去参加了数据仓库部门关于Greenplum的一个技术分享,期间大量列举了一些性能数据的对比,尤其是和当前的一套Oracle
RAC的对比。结果不言而喻,在数据仓库的应用上,尤其是大数据量的处理,性能相差悬殊。这时问题就来了,很多人感觉这个产品太神奇了,可以解决数据仓库的一切问题,好像它就是上帝赐予我们的礼物。最后好多人都在问:Oracle太烂了,用这么好的设备,性能还这么差,我们干嘛还要用?呜呼哀哉,Greenplum是好,但并不“神奇”,我们不要被这些”神奇“的数据挡住了视线。
对于Greenplum,我其实也处于一知半解的状态,给大家讲原理未免有些力不从心,这里只简单给大家分析一下Greenplum为什么会快?他用了什么”神奇“的技术?
如何提升数据仓库的处理能力,有以下两个主要因素:第一,吞吐能力,就是所谓的IO;第二,并行计算能力。
我们都知道Oracle RAC是shared
everything架构,而Greenplum是shared nothing架构。整个集群由很多个segment
host(数据节点)+master host(控制节点)组成,其中每个segment
host上运行了很多个PgSQL数据库(segment)。
![](http://home.dwway.com/data/attachment/album/201202/07/22220335nlnynye5deinnl.jpg)
数据在进入数据库时,首先要做数据分布的工作,即把一个表的数据尽可能均匀的分布到每个segment上,我们需要为每个表指定一个distribute列,然后根据hash来做数据分布。这样做的目的就是要充分利用每个节点的IO能力,我们知道现在PC机的IO能力相当可观,象DWA这种专门设计的数据节点,Sun
Fire X4500 Server,在一个box内集成了48块SATA盘,号称“Scan
1 Terabyte of data in 60 seconds”。其实没必要买DWA,国内厂商都有那种磁盘密集型的PC,价格便宜量又足,我们一直用它。
![](http://home.dwway.com/static/image/common/emp.gif)
![](http://home.dwway.com/data/attachment/album/201202/07/222205wc1273p1f3ey2y2b.jpg)
很多人在看到Greenplum架构的时候,第一个问题就是master机器承担了什么功能?它会不会成为系统的瓶颈?这也是Greenplum系统的一个重要特点,master只承担非常少量的控制功能,以及和客户端的交互,完全不承担任何计算。如果存在一个中心节点的话,那意味着这个系统根本没有办法线性扩展,因为master一定会成为系统的瓶颈。而Greenplum不存在这个问题,节点间的数据交互,不需要经过master,而是直接在节点间就完成了。
现在,如果我们要查询某个表的数据,只要把工作分配给每个节点就行了,IO不再是问题,接下来要解决并行计算的问题,核心问题是多表做join。因为表是通过DT列做分布的,所以每个节点通过DT列就知道数据在某个节点上,假设两个表用DT列做join,因为相同的数据都在相同的节点上,所以只需要对应节点计算,然后合并结果就可以了。如果是非DT列做join,因为节点间不知道数据的分布,所以就会做一个数据重分布的过程(redistribute)。我们看下面的例子,三个表都是用id列作为DT列,首先用id做join,因为设计到非DT列的join,这时Greenplum会作redistribute的工作,作用就是重新按照hash做数据分布,这样做的目的就是要让节点知道数据在哪个节点上,以便完成join的动作。我们看到后面的group
by也做了redistribute,因为group by的也是非DT列,而hash
aggregate动作也需要节点间交互数据,节点间也必须知道数据的分布。如果有redistribute动作,效率会高吗?因为redistribute仅仅只针对需要的数据,而且全部在节点cache中完成,肯定要比DT列做join慢一些,但是效率还是非常高的。
![](http://home.dwway.com/data/attachment/album/201202/07/222815jfzcac6jy8jdzmyn.jpg)
Greenplum真正发挥了并行无处不在的优势,在一个主机上同时启动多个PgSQL数据库,这样硬件上的多核CPU就可以充分发挥优势。有人问我:Greenplum能并行处理多个任务吗?回答是:不可能。因为Greenplun已经将机器的IO和处理能力全部发挥出来了,再没有可能同时处理多个任务。
Greenplum还有一个有意思的特性就是在数据装载时,不是我们一般想象的存在一个中心的数据分发节点,而是所有节点同时读取数据,然后根据hash算法,将属于自己的数据留下,将其他的节点的数据通过网络直接传送给他,所以数据装载的速度非常快。
Greenplum HA架构
![](http://home.dwway.com/data/attachment/album/201202/07/22220657slzvbm4mippig2.jpg)
现在来看Greenplum并不神奇,其实Oracle
RAC也是数据仓库非常好的解决方案,类似的技术Oracle全部都有。我们可以这样来做一个假设,如果针对某个固定的SQL,我可以同样用Oracle
RAC来做Greenplum做的事情,根据SQL,我们可以把表做
Hash+Range分区(事实上Greenplum也是hash+range分区,用hash将数据分布到不同的数据库上,然后再用range将每个数据库上的表做分区),再利用RAC的并行处理能力。Oracle也有partition-wise
join这种类似功能,但是没有数据redistribute的操作。Oracle最大的问题还是在于shared
everything的架构,导致IO的处理能力有限,我们的大型存储吞吐量也就1.4GB/S,而且扩展能力也有限。以前曾经介绍过的Oracle
database machine,就是Oracle专门为数据仓库的提供的解决方案。
其实并存在什么神奇的技术,Greenplum之所以神奇是因为我们的场景发挥了他的特点,其实我们也可以设计一个场景来得到Greenplum很烂的结论,所以不要相信厂商的数据,不要相信什么可以解决一切问题的技术,那根本不存在。
”不要迷恋哥,哥只是传说。“
后来,我们发现普通的PC+SAS磁盘具备非常好的吞吐能力,完全不逊于某些昂贵的存储设备。这样我们就尝试用PC+Greenplum搭建了一个环境,效果完全超出了我们的预期,吞吐量完全超过了我们的大型存储。从那时开始,我们不再迷信那些昂贵的主机和存储,开始尝试一些新的东西,比如用PC+SAS/SATA来堆叠廉价存储,用Greenplum来搭建数据仓库计算环境,搜索的hadoop集群,PC+SSD搭建OLTP数据库,用Intel
Nehalem来替代小型机等等。
昨天,去参加了数据仓库部门关于Greenplum的一个技术分享,期间大量列举了一些性能数据的对比,尤其是和当前的一套Oracle
RAC的对比。结果不言而喻,在数据仓库的应用上,尤其是大数据量的处理,性能相差悬殊。这时问题就来了,很多人感觉这个产品太神奇了,可以解决数据仓库的一切问题,好像它就是上帝赐予我们的礼物。最后好多人都在问:Oracle太烂了,用这么好的设备,性能还这么差,我们干嘛还要用?呜呼哀哉,Greenplum是好,但并不“神奇”,我们不要被这些”神奇“的数据挡住了视线。
对于Greenplum,我其实也处于一知半解的状态,给大家讲原理未免有些力不从心,这里只简单给大家分析一下Greenplum为什么会快?他用了什么”神奇“的技术?
如何提升数据仓库的处理能力,有以下两个主要因素:第一,吞吐能力,就是所谓的IO;第二,并行计算能力。
我们都知道Oracle RAC是shared
everything架构,而Greenplum是shared nothing架构。整个集群由很多个segment
host(数据节点)+master host(控制节点)组成,其中每个segment
host上运行了很多个PgSQL数据库(segment)。
![](http://home.dwway.com/data/attachment/album/201202/07/22220335nlnynye5deinnl.jpg)
数据在进入数据库时,首先要做数据分布的工作,即把一个表的数据尽可能均匀的分布到每个segment上,我们需要为每个表指定一个distribute列,然后根据hash来做数据分布。这样做的目的就是要充分利用每个节点的IO能力,我们知道现在PC机的IO能力相当可观,象DWA这种专门设计的数据节点,Sun
Fire X4500 Server,在一个box内集成了48块SATA盘,号称“Scan
1 Terabyte of data in 60 seconds”。其实没必要买DWA,国内厂商都有那种磁盘密集型的PC,价格便宜量又足,我们一直用它。
![](http://home.dwway.com/static/image/common/emp.gif)
![](http://home.dwway.com/data/attachment/album/201202/07/222205wc1273p1f3ey2y2b.jpg)
很多人在看到Greenplum架构的时候,第一个问题就是master机器承担了什么功能?它会不会成为系统的瓶颈?这也是Greenplum系统的一个重要特点,master只承担非常少量的控制功能,以及和客户端的交互,完全不承担任何计算。如果存在一个中心节点的话,那意味着这个系统根本没有办法线性扩展,因为master一定会成为系统的瓶颈。而Greenplum不存在这个问题,节点间的数据交互,不需要经过master,而是直接在节点间就完成了。
现在,如果我们要查询某个表的数据,只要把工作分配给每个节点就行了,IO不再是问题,接下来要解决并行计算的问题,核心问题是多表做join。因为表是通过DT列做分布的,所以每个节点通过DT列就知道数据在某个节点上,假设两个表用DT列做join,因为相同的数据都在相同的节点上,所以只需要对应节点计算,然后合并结果就可以了。如果是非DT列做join,因为节点间不知道数据的分布,所以就会做一个数据重分布的过程(redistribute)。我们看下面的例子,三个表都是用id列作为DT列,首先用id做join,因为设计到非DT列的join,这时Greenplum会作redistribute的工作,作用就是重新按照hash做数据分布,这样做的目的就是要让节点知道数据在哪个节点上,以便完成join的动作。我们看到后面的group
by也做了redistribute,因为group by的也是非DT列,而hash
aggregate动作也需要节点间交互数据,节点间也必须知道数据的分布。如果有redistribute动作,效率会高吗?因为redistribute仅仅只针对需要的数据,而且全部在节点cache中完成,肯定要比DT列做join慢一些,但是效率还是非常高的。
![](http://home.dwway.com/data/attachment/album/201202/07/222815jfzcac6jy8jdzmyn.jpg)
Greenplum真正发挥了并行无处不在的优势,在一个主机上同时启动多个PgSQL数据库,这样硬件上的多核CPU就可以充分发挥优势。有人问我:Greenplum能并行处理多个任务吗?回答是:不可能。因为Greenplun已经将机器的IO和处理能力全部发挥出来了,再没有可能同时处理多个任务。
Greenplum还有一个有意思的特性就是在数据装载时,不是我们一般想象的存在一个中心的数据分发节点,而是所有节点同时读取数据,然后根据hash算法,将属于自己的数据留下,将其他的节点的数据通过网络直接传送给他,所以数据装载的速度非常快。
Greenplum HA架构
![](http://home.dwway.com/data/attachment/album/201202/07/22220657slzvbm4mippig2.jpg)
现在来看Greenplum并不神奇,其实Oracle
RAC也是数据仓库非常好的解决方案,类似的技术Oracle全部都有。我们可以这样来做一个假设,如果针对某个固定的SQL,我可以同样用Oracle
RAC来做Greenplum做的事情,根据SQL,我们可以把表做
Hash+Range分区(事实上Greenplum也是hash+range分区,用hash将数据分布到不同的数据库上,然后再用range将每个数据库上的表做分区),再利用RAC的并行处理能力。Oracle也有partition-wise
join这种类似功能,但是没有数据redistribute的操作。Oracle最大的问题还是在于shared
everything的架构,导致IO的处理能力有限,我们的大型存储吞吐量也就1.4GB/S,而且扩展能力也有限。以前曾经介绍过的Oracle
database machine,就是Oracle专门为数据仓库的提供的解决方案。
其实并存在什么神奇的技术,Greenplum之所以神奇是因为我们的场景发挥了他的特点,其实我们也可以设计一个场景来得到Greenplum很烂的结论,所以不要相信厂商的数据,不要相信什么可以解决一切问题的技术,那根本不存在。
”不要迷恋哥,哥只是传说。“
相关文章推荐
- 转载:Greenplum技术浅析
- Greenplum技术浅析--vs oracle RAC
- EMC的Vplex技术用于提升云存储服务质量
- 数据库连接池技术浅析
- 硬件虚拟化技术浅析
- AAA 分布式网站架构后续:zookeeper技术浅析
- VC++服务器端开发方向必须要学的几门技术浅析
- 浅析Android自动化测试基础技术(一)
- 浅析木马服务端的生成技术
- STUN和TURN技术浅析
- 浅析ADO.NET数据库编程技术
- 用sharding技术来扩展你的数据库(一)sharding 介绍_EMC中国研究院_新浪轻博客_Qing|轻松分享你的兴趣
- 关于公交系统中运用NFC-TSM技术进行移动支付的解决案例浅析
- 阿里云大数据三次技术突围:Greenplum、Hadoop和飞天
- Hadoop MapReduce核心技术浅析-----RPC框架解析
- 区块链技术浅析之二:区块链的技术源流
- 浅析C++ Compile-time Assertion技术
- 分布式网站架构后续:zookeeper技术浅析
- 透明加密技术浅析
- 浅析无线网络数据窥探技术