数据海量数据库

与Greenplum结伴而行

文章来自：天善智能社区作者：phibert引言BigData，无论这个词被翻译成大数据、海量数据还是巨量资...

文章来自：天善智能社区作者：phibert

引言

BigData，无论这个词被翻译成大数据、海量数据还是巨量资料，它都当之无愧是近两年上镜率最高的一个词，这种曝光率使它和它的小伙伴们终于从幕后正式走向了舞台中央，真正站在了聚光灯下，人们开始在各种场合通过各种媒体和渠道切身的感受着它们的存在，它们红了，红的那么耀眼。

它们是谁？它们代表的不只是数据本身而是整个数据技术体系，是从数据定义到数据存储再到数据处理的各种数据技术的集合，在这个体系内涌现的技术和平台越多，技术应用者面对的选择就越多，在海量数据分析正在进入黄金时代的今天，在众多的海量数据处理技术和平台中选择谁来作为你的海量数据分析大片的女(男)一号和她(他)牵手向前呢？我选择Greenplum！如果你也和我一样想不断关注和了解她(他)，那么欢迎你加入我与Greenplum的结伴之旅。

注：本文将以连载方式对Greenplum的相关技术进行阐述，此博客(http://www.flybi.net/blog/philbert)为本人确定的文章唯一更新位置，转载请事先声明并注明出处，谢谢。

优良基因的继承与发展

如果现在随意打开一个搜索引擎,输入关键字：Greenplum，根据搜索到的结果有很大概率可以总结出一些关于Greenplum的背景信息：Greenplum是一款基于Share-nothing架构、擅长大规模并行处理、面向海量数据分析的关系型数据库；Greenplum最初于2003年出现于美国硅谷，2010年改姓EMC(估计再过不久又要改姓DELL了)，目前由Pivotal Software负责对其进行独立运营。下面我将尝试对这些信息进行扩展和解读。

Greenplum从诞生到现在也不过十几年的时间，其版本进入稳定期的时间还不足十年，现在产品正在经历又一个合并重组的时期，这位数据库家族的新成员无疑还很稚嫩，但就是这样一个稚嫩的孩子却让很多数据库使用者大开眼界，这个孩子的身上有什么魔力？在这样一个需要底蕴的时代里，这个孩子是否也有属于自己的巨大身影站在它的身后？PostgreSQL，显然寻找这个答案并不需要花费什么时间和精力，关于PostgreSQL的历史我无意多说，互联网上有足够多的信息供大家了解，需要重点聊聊的可能只是继续这个思路往下走自然而然遇的一个问题：

为什么是PostgreSQL，Greenplum开发团队为什么会选择PostgreSQL作为基础平台来开发产品？

对于这个问题的回答见仁见智，本人资质愚钝，能想到的关键理由只有两个(欢迎大牛们批评)：原因N0.1，开源！作为社区型开源项目，PostgreSQL可以让开发团队尽可能的摆脱厂商束缚，这一点对于可能涉及数据库内核修改的项目来说显得尤其重要；还有必须要提的一个方面就是源码部分，PostgreSQL源码的漂亮程度绝对是一流帅哥美女级别的，哪个人(开发者)会拒绝有帅哥美女相伴的日子呢？此话虽属玩笑，但本人确实认为PostgreSQL的源码足以成为业界典范。关于开源的话题这里只是一个开始，后面会找机会继续深入，因为就在2015年Greenplum也已经开始了自己的开源行动；原因N0.2，面向海量数据分析！简单来说开发Greenplum的目的是服务于海量数据分析这样的决策分析型应用目标的，相信很多人都听说过这样一句话：PostgreSQL是世界上最先进的开源数据库，但以我的保守风格还是习惯在'开源数据库'这个短语之前加上'OLAP'，同时在这个短语之后加上'之一'，PostgreSQL在多进程环境下展现的稳定性和针对分析型复杂查询的良好支持都足以给Greenplum提供足够的安全感和依靠。从这点上来说Greenplum绝对是PostgreSQL数据分析处理优良基因的继承者，说到这里如果有朋友还在纠结是否选择Greenplum应对事务处理型(OLTP)应用场景，那我就真的无话可说了。

接下来的话题显而易见：Greenplum从PostgreSQL继承到的基因图谱包括哪些内容？

SQL，任何数据库都必须支持的内容，这方面PostgreSQL针对数据分析型应用提供的统计型函数和语法为Greenplum在相关功能上的扩展和改进奠定了良好基础。
Hash Join，对大型数据表进行关联分析一直都是PostgreSQL的强项，尤其是Hash Join这项针对分析型复杂查询的必需品，PostgreSQL实现的很好，Greenplum没有任何理由埋没这种天赋。
语言包扩展，PostgreSQL支持Python，C，PLSQL等多种扩展语言来进行应用功能扩展，使用者可以根据应用需求的不同开发情况和目标来选择合适的最适合的方式来开发扩展功能，Greenplum会让这一传统得以延续。
应用包扩展， PostgreSQL对Postgis和Madlib的支持使得Greenplum能够与地图和图像处理完成无缝或窄缝衔接。

优良基因的继承只是的开始，Greenplum究竟要在PostgreSQL之上干什么？

Share-Nothing，数据库架构的一种，与之对应的是Share-Disk架构(其实还有Share-everything架构，主要用于单机，这里不作详细说明)，Share-Disk针对数据库多处理单元场景，各处理单元有自己独立的CPU和MEM的同时在Disk层面共享数据，传统的Oracle RAC是它的典型代表，Share-Nothing同样针对数据库多处理单元场景，各处理单元相互独立，不存在共享资源，处理单元间通过特定通讯协议进行通讯，Greenplum通过这种数据库架构来保证自身扩展性。

大规模并行处理，可能很多朋友更愿意用MPP这个缩写来称呼它，这种处理方式的选择是直接与数据库基础架构相关的，你很难想象在Share-everything架构下使用MPP进行数据处理，Share-Nothing架构各处理单元的松耦合关系保证了整体架构的良好扩展性，正是MPP体现在海量数据决策支持和数据挖掘处理方面优势的最佳搭档。而Greenplum正是通过对多个PostgreSQL实例的统一规划使其共同形成一个完整的数据库管理系统的方式来实现MPP的。

在Share-Nothing架构下实现MPP，必须要面对的问题是什么？处理单元间的信息交互！这里的交互信息既包括处理单元间的控制信息又包括处理单元间的数据信息，如何保证信息交互过程的及时准确将直接关系到Greenplum是否能将MPP的优势发挥到极致！这个问题的处理应该是Greenplum最引以为傲的成就(真的很想有时间好好玩玩这段源码)。

写到这里，如果你觉得Greenplum牛X的不行，那就是我应该给你泼点冷水的时候了，Greenplum的早期版本一直存在一些关键性BUG，直到4.2版本的发布才逐渐进入稳定期(如果你在使用低于4.2的版本请立刻马上更换)，后面文章中的主要内容都将以4.2版本为基础进行覆盖和扩展，Greenplum选择的PostgreSQL基础版本是8.2，这意味着什么不言而喻，凡是高于此版本(8.2)的PostgreSQL特性都将是理想中的美好，要么面对现实要么DIY(先把开源代码拿到)，如果你选择后者，在向你致敬的同时我还会加一句：Good Luck！