存档

文章标签 ‘Greenplum’

说起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)。

数据在进入数据库时,首先要做数据分布的工作,即把一个表的数据尽可能均匀的分布到每个segment上,我们需要为每个表指定一个distribute列,然后根据hash来做数据分布。这样做的目的就是要充分利用每个节点的IO能力,我们知道现在PC机的IO能力相当可观,象DWA这种专门设计的数据节点,Sun Fire X4500 Server,在一个box内集成了48块SATA盘,号称“Scan 1 Terabyte of data in 60 seconds”。其实没必要买DWA,国内厂商都有那种磁盘密集型的PC,价格便宜量又足,我们一直用它。

很多人在看到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慢一些,但是效率还是非常高的。
Bride Wars download Somewhere in Time divx
Greenplum真正发挥了并行无处不在的优势,在一个主机上同时启动多个PgSQL数据库,这样硬件上的多核CPU就可以充分发挥优势。有人问我:Greenplum能并行处理多个任务吗?回答是:不可能。因为Greenplun已经将机器的IO和处理能力全部发挥出来了,再没有可能同时处理多个任务。
Greenplum还有一个有意思的特性就是在数据装载时,不是我们一般想象的存在一个中心的数据分发节点,而是所有节点同时读取数据,然后根据hash算法,将属于自己的数据留下,将其他的节点的数据通过网络直接传送给他,所以数据装载的速度非常快。
Greenplum HA架构

现在来看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很烂的结论,所以不要相信厂商的数据,不要相信什么可以解决一切问题的技术,那根本不存在。
”不要迷恋哥,哥只是传说。“
–EOF–

7 24th, 2009 | Filed under 大话技术