Pivotal践行见远技术篇之(14) -跟您聊聊Greenplum的那些事儿 (上)

大梦

http://mp.weixin.qq.com/s?__biz= ... 0&ADPUBNO=26567


开卷有言——作者的话


有时候真的感叹人生岁月匆匆，特别是当一个IT人沉浸于某个技术领域十来年后，蓦然回首，总有说不出的万千感慨。


笔者有幸从04年就开始从事大规模数据计算的相关工作，08年作为Greenplum 早期员工加入Greenplum团队（当时的工牌是“005”，哈哈），记得当时看了一眼Greenplum的架构（嗯，就是现在大家耳熟能详的那个好多个X86框框的图），就义无反顾地加入了，转眼之间，已经到了第8个年头。


在诸多项目中我亲历了Greenplum在国内的生根发芽到高速发展，再到现在拥有一百多个企业级用户的过程。也见证了Greenplum从早期的2.1版本到当前的4.37版本，许多NB功能的不断增强、系统稳定性的不断大幅提高，在Greenplum的发展壮大中，IT行业也发生着巨大的变化，业界潮流也沿着开放、开源的方向走向了大数据和云计算时代，由此可以看出，Greenplum十来年的快速发展不是偶然发生的，与其在技术路线上始终保持与整个IT行业的技术演进高度一致密不可分。





多年历练中接触过大大小小几十个数据类项目，有些浅尝辄止（最短的不到一周甚至还有远程支持），有些周期以年来计（长期出差现场、生不如死），客观来说， 每个项目都有其独一无二的的特点，只要有心，你总能在这个项目上学到些什么或有所领悟。我觉得把这些整理一下，用随笔的方式写下来，除了自己备忘以外，也许会对大家更深入地去了解GP带来一些启发，也或许在某个技术点上是你目前遇到的问题，如乱码怎么加载？异构数据库如何迁移？集群间如何高速复制数据？如何用C API扩展实现高效备份恢复等。希望我的这篇文章能够给大家带来帮助，同时也希望大家多拍砖。


  Grenplum的起源


Greenplum最早是在10多年前（大约在2002年）出现的，基本上和Hadoop是同一时期（Hadoop 约是2004年前后，早期的Nutch可追溯到2002年）。当时的背景是：


互联网行业经过之前近10年的由慢到快的发展，累积了大量信息和数据，数据在爆发式增长，这些海量数据急需新的计算方式，需要一场计算方式的革命；

传统的主机计算模式在海量数据面前，除了造价昂贵外，在技术上也难于满足数据计算性能指标，传统主机的Scale-up模式遇到了瓶颈，SMP（对称多处理）架构难于扩展，并且在CPU计算和IO吞吐上不能满足海量数据的计算需求；

分布式存储和分布式计算理论刚刚被提出来，Google的两篇著名论文发表后引起业界的关注，一篇是关于GFS分布式文件系统，另外一篇是关于MapReduce 并行计算框架的理论，分布式计算模式在互联网行业特别是收索引擎和分词检索等方面获得了巨大成功；




由此，业界认识到对于海量数据需要一种新的计算模式来支持，这种模式就是可以支持Scale-out横向扩展的分布式并行数据计算技术。


当时，开放的X86服务器技术已经能很好的支持商用，借助高速网络（当时是千兆以太网）组建的X86集群在整体上提供的计算能力已大幅高于传统SMP主机，并且成本很低，横向的扩展性还可带来系统良好的成长性。


问题来了，在X86集群上实现自动的并行计算，无论是后来的MapReduce计算框架还是MPP（海量并行处理）计算框架，最终还是需要软件来实现，Greenplum正是在这一背景下产生的，借助于分布式计算思想，Greenplum实现了基于数据库的分布式数据存储和并行计算（GoogleMapReduce实现的是基于文件的分布式数据存储和计算，我们过后会比较这两种方法的优劣性）。



                          (Greenplum集群架构)


话说当年Greenplum（当时还是一个Startup公司，创始人家门口有一棵青梅 ——greenplum，因此而得名）召集了十几位业界大咖（据说来自google、yahoo、ibm和TD），说干就干，花了1年多的时间完成最初的版本设计和开发，用软件实现了在开放X86平台上的分布式并行计算，不依赖于任何专有硬件，达到的性能却远远超过传统高昂的专有系统。


大家都知道Greenplum的数据库引擎层是基于著名的开源数据库Postgresql的（下面会分析为什么采用Postgresql，而不是mysql等等），但是Postgresql是单实例数据库，怎么能在多个X86服务器上运行多个实例且实现并行计算呢？为了这，Interconnnect大神器出现了。在那1年多的时间里，大拿们很大一部分精力都在不断的设计、优化、开发Interconnect这个核心软件组件。最终实现了对同一个集群中多个Postgresql实例的高效协同和并行计算，interconnect承载了并行查询计划生产和Dispatch分发（QD）、协调节点上QE执行器的并行工作、负责数据分布、Pipeline计算、镜像复制、健康探测等等诸多任务。


在Greenplum开源以前，据说一些厂商也有开发MPP数据库的打算，其中最难的部分就是在Interconnect上遇到了障碍，可见这项技术的关键性。


  Grenplum为什么选择Postgreeql做轮子

说到这，也许有同学会问，为什么Greenplum 要基于Postgresql?

这个问题大致引申出两个问题：


1、为什么不从数据库底层进行重新设计研发？


这个问题道理比较简单，所谓术业有专攻，就像制造跑车的不会亲自生产车轮一样，我们只要专注在分布式技术中最核心的并行处理技术上面，协调我们下面的轮子跑的更快更稳才是我们的最终目标。而数据库底层组件就像车轮一样，经过几十年磨砺，数据库引擎技术已经非常成熟，大可不必去重新设计开发，而且把数据库底层交给其它专业化组织来开发（对应到Postgresql就是社区），还可充分利用到社区的源源不断的创新能力和资源，让产品保持持续旺盛的生命力。


这也是我们在用户选型时，通常建议用户考察一下底层的技术支撑是不是有好的组织和社区支持的原因，如果缺乏这方面的有力支持或独自闭门造轮，那就有理由为那个车的前途感到担忧，一个简单判断的标准就是看看底下那个轮子有多少人使用，有多少人为它贡献力量。

            

2、为什么是Postgresql而不是其它的？


我想大家可能主要想问为什么是Postgresql而不是Mysql（对不起，还有很多开源关系型数据库，但相比这两个主流开源库，但和这两个大牛比起来，实在不在一个起跑线上）。本文无意去从详细技术点上PK这两个数据库孰优孰劣（网上很多比较），我相信它们的存在都有各自的特点，它们都有成熟的开源社区做支持，有各自的庞大的fans群众基础。个人之见，Greenplum选择Postgressql有以下考虑：


➤  Postgresql号称最先进的数据库（官方主页“The world’s most advanced open source database”）,且不管这是不是自我标榜，就从OLAP分析型方面来考察，以下几点Postgresql确实胜出一筹：


PG有非常强大 SQL 支持能力和非常丰富的统计函数和统计语法支持，除对ANSI SQL完全支持外，还支持比如分析函数（SQL2003 OLAP window函数），还可以用多种语言来写存储过程，对于Madlib、R的支持也很好。这一点上MYSQL就差的很远，很多分析功能都不支持，而Greenplum作为MPP数据分析平台，这些功能都是必不可少的。

Mysql查询优化器对于子查询、复制查询如多表关联、外关联的支持等较弱，特别是在关联时对于三大join技术：hash join、merge join、nestloop join的支持方面，Mysql只支持最后一种nestloop join（据说未来会支持hash join），而多个大表关联分析时hash join是必备的利器，缺少这些关键功能非常致命，将难于在OLAP领域充当大任。我们最近对基于MYSQL的某内存分布式数据库做对比测试时，发现其优点是OLTP非常快，TPS非常高（轻松搞定几十万），但一到复杂多表关联性能就立马下降，即使其具有内存计算的功能也无能为力，就其因估计还是受到mysql在这方面限制。

➤  扩展性方面，Postgresql比mysql也要出色许多，Postgres天生就是为扩展而生的，你可以在PG中用Python、C、Perl、TCL、PLSQL等等语言来扩展功能，在后续章节中，我将展现这种扩展是如何的方便，另外，开发新的功能模块、新的数据类型、新的索引类型等等非常方便，只要按照API接口开发，无需对PG重新编译。PG中contrib目录下的各个第三方模块，在GP中的postgis空间数据库、R、Madlib、pgcrypto各类加密算法、gptext全文检索都是通过这种方式实现功能扩展的。


➤  在诸如ACID事物处理、数据强一致性保证、数据类型支持、独特的MVCC带来高效数据更新能力等还有很多方面，Postgresql似乎在这些OLAP功能上都比mysql更甚一筹。


➤  最后，Postgresql许可是仿照BSD许可模式的，没有被大公司控制，社区比较纯洁，版本和路线控制非常好，基于Postgresql可让用户拥有更多自主性。反观Mysql的社区现状和众多分支（如MariaDB），确实够乱的。


好吧，不再过多列举了，这些特点已经足够了，据说很多互联网公司采用Mysql来做OLTP的同时，却采用Postgresql来做内部的OLAP分析数据库，甚至对新的OLTP系统也直接采用Postgresql。


相比之下，Greenplum更强悍，把Postgresql作为实例（注：该实例非Oracle实例概念，这里指的是一个分布式子库）架构在Interconnect下，在Interconnect的指挥协调下，数十个甚至数千个Sub Postgresql数据库实例同时开展并行计算，而且，这些Postgresql之间采用share-nothing无共享架构，从而更将这种并行计算能力发挥到极致，除此之外，MPP 采用两阶段提交和全局事务管理机制来保证集群上分布式事务的一致性，Greenplum像Postgresql一样满足关系型数据库的包括ACID在内的所有特征；





从上图进而可以看到，Greenplum的最小并行单元不是节点层级，而是在实例层级，安装过Greenplum的同学应该都看到每个实例都有自己的postgresql目录结构，都有各自的一套Postgresql数据库守护进程（甚至可以通过UT模式进行单个实例的访问）。正因为如此，甚至一个运行在单节点上的GreenplumDB也是一个小型的并行计算架构，一般一个节点配置6~8个实例，相当于在一个节点上有6~8个Postgresql数据库同时并行工作，优势在于可以充分利用到每个节点的所有CPU和IO 能力。


Greenplum单个节点上运行能力比其它数据库也快很多，如果运行在多节点上，其提供性能几乎是线性的增长，这样一个集群提供的性能能够很轻易的达到传统数据库的数百倍甚至数千倍，所管理数据存储规模达到100TB~数PB，而你在硬件上的投入，仅仅是数台一般的X86服务器和普通的万兆交换机。

            

         Greenplum 采用Postgresl作为底层引擎，良好的兼容了Postgresql的功能，Postgresql中的功能模块和接口基本上99%都可以在Greenplum上使用，例如odbc、jdbc、oledb、perldbi、python psycopg2等，所以Greenplum与第三方工具、BI报表集成的时候非常容易；对于postgresql的contrib中的一些常用模块Greenplum提供了编译后的模块开箱即用，如oraface、postgis、pgcrypt等，对于其它模块，用户可以自行将contrib下的代码与Greenplum的include头文件编译后，将动态so库文件部署到所有节点就可进行测试使用了。有些模块还是非常好用的，例如oraface，基本上集成了Oracle常用的函数到Greenplum中，曾经在一次PoC测试中，用户提供的22条Oracle SQL语句，不做任何改动就能运行在Greenplum上。

            

          最后，特别提示，Greenplum绝不仅仅只是简单的等同于“Postgresql+interconnect并行调度+分布式事务两阶段提交”，Greenplum还研发了非常多的高级数据分析管理功能和企业级管理模块，这些功能都是Postgresql没有提供的：


•      外部表并行数据加载

•      可更新数据压缩表

•      行、列混合存储

•      数据表多级分区

•      Bitmap索引

•      Hadoop外部表

•      Gptext全文检索

•      并行查询计划优化器和Orca优化器

•      Primary/Mirror镜像保护机制

•      资源队列管理

•      WEB/Brower监控




作者简介

李巍－－Pivotal大中国区资深架构师


   李巍先生，资深Greenplum 数据库专家， 拥有超过10年从事分布式计算和大数据计算的经历，对大规模数据计算有着丰富的实战经验。曾在包括大型电商、国有大银行、电信行业在内的数十个项目中担任架构师或技术专家，在很多关键性问题的解决上做出过多项贡献。作者长期关注开源技术，对开源数据库及Python、C、Perl语言极其熟练，信念“实践出真知”的真理。