Greenplum技术浅析

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慢一些，但是效率还是非常高的。

 

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很烂的结论，所以不要相信厂商的数据，不要相信什么可以解决一切问题的技术，那根本不存在。