人工智能：EMC GP发布Pivotal HD和HAWG详解
独家供稿：移动Labs
美国时间的今天，也就是2013年2月27日，三年前被EMC收购的GreenPlum公司拿出了他们在2013年的重大动作，发布了Pivotal HD，这是一个Hadoop协议栈。与之前OEM的MapR的Hadoop协议栈不一样，这个新的协议栈是GreenPlum自己研发的，主要的目的就是支撑其上被称为HAWG的技术。
发布会演讲可以在这里看到：https://www.brighttalk.com/webcast/6499/68121
PPT也有下载哦：
http://221.179.130.210:81/1Q2W3E4R5T6Y7U8I9O0P1Z2X 3C4V5B/public.brighttalk.com/resource/core/9757/hadoop-the_foundation_for_change_15465.pdf
在发布会中，其CTO称HAWG为GreenPlum的“皇冠上的明珠”，并用苹果公司的操作系统做了类比，这说明这个东西非常重要。什么是HAWG呢？从发布会的分析来看，这就是一个构建在HDFS上的MPP DB。
据内部不可靠消息称，这个东西GreenPlum已经研究开发了很久，去年已经发布了内部版本，并且腾讯公司搭建了一个2000节点的环境来对其进行POC测试，意图替换现在的HIVE查询器。
可以看出今天的发布的东西会对GreenPlum有长远的影响。因为发布会的主题是“Hadoop: The Foundation For Change”，并且CTO骄傲地宣布“We are all in on Hadoop”。在这里暂且不分析他这个英语语法对不对，我主要关心的是，GreenPlum是将HAWG视为“银弹”，以后不再更新支持构建在POSIX文件系统上的MPP DB；还是作为一个Option，让客户在HDFS文件系统和POSIX文件系统中进行选择。这将是一个重要的方向。
其实GreenPlum从很早的时候（Hadoop诞生的时候）就与Hadoop有不解之缘。为什么这么说呢？因为最早（也许是2007年）我听说GreenPlum的时候，他们给人留下的深刻映像就是在其DB之上既可以支持SQL解释器，也能支持MapReduce的操作（就和AsterData一样），虽然后来我发现，它当时的这个MapReduce运行框架相当的简陋。
后来其DB可以支持存储在HDFS上的“外部表”可以视为第二次与Hadoop的亲密接触，也就是可以支持用户将一些文件，通常是价值低、数据量大的文件存储在HDFS上，支持SQL的操作。跟第一个阶段不同，这是在DBMS之下对Hadoop的支持，而不是之上。由于HDFS不支持文件的更新，只能新建、打开和追加。而且外部表的机制实际上是在DBMS和下层文件系统（特别是HDFS）之间提供了一种透明性，所以DBMS没有太多的方式可以控制具体的物理存储位置。这将导致无法发挥DBMS的最大魅力。早期的DBMS甚至要求要完全控制到裸设备一级，当然现在也至少要求控制到每个节点的POSIX文件系统系统一级。所以这个时候外部表的解决方案只能是一个过渡阶段，支持有限的存储和查询，应该是不能支持UPDATE等操作，对JOIN类操作支撑也不会太好。当然，我没有实际进行研究测试过，这只是技术上的思考。
这次的HAWG可以算是GreenPlum与Hadoop的第三次亲密接触。亲密到几乎完全投奔了Hadoop的怀抱。以前可以看作是DB特征为主，Hadoop为辅，现在交换了。就是一个Hadoop上支持SQL的产品。无怪乎CTO说“We are all in on Hadoop”。
发布会上干货不多，实际上你要想期望在这上面听到什么也不可能，干货我挑出来，大概是这样。
这是Pivotal HD的架构。可以看到，除了标准的Apache Hadoop外，GreenPlum增加的不是太多。除了所有Hadoop发布版都必不可少的管理工具之外，它还提供了一个高效的数据装载器（基于以前Hadoop DB的那个分布式装载机制，我猜的），另外还有一个Hadoop的虚拟机（这个应该是EMC控股的Vmware的东东，以前见过他们介绍，没有想到整合到这个里面来了）。除了管理工具、装载器和虚拟机外，
其实重头戏就是HAWQ了。
看到这个图你就知道了，所谓的HAWG就是一个构建在HDFS上的MPP DB。相比Hive、PIG等其他SQL解释器，它有完备的DBMS管理功能，支持标准SQL语法，在性能上更加接近原有DB（我是这样理解的，稍后继续分析性能）。
在发布会上，其介绍了几项关键的技术
1、基于成本的优化模型。这个很重要，关系数据库的成功很大程度是靠它，基于成本的优化提供了一定的透明性，降低了用户对数据结构的理解。SQL之父曾经说SQL语言不是为开发人员设计的，而是为用户设计的，即有这个意思。
2、分布式执行器。根据查询优化的结果进行执行，不使用MapReduce的方法。这有点与Impala类似，但是差别还是挺大的，后面再说。不使用MapReduce的原因大概是因为原生的MapReduce执行框架很有强的阶段性，是典型的批处理，而很多时候，小查询占多数，需要的是交互性而不是批处理，这点在CTO之前自豪的介绍中也说了，这是他们的特点。
3、动态管道技术。主持人强调说你们一定要记住这个词哦，甚至他们为此申报了商标（你说至于嘛），可见非常重要。没有具体介绍，但是我猜，这个就是将DBMS执行计划中的流水线移植到HAWG中来了。这对于交互式SQL查询来说是必不可少的，可以实现秒级反馈，这些是原来Hadoop中不具备的。不过Hadoop本来就不是为交互式设计的，人家强调的是大数据量处理，所以也没有必要。（One Size Doesn’t Fit All）
其实除了这三个关键技术，GreenPlum应该更重要的是修改了HDFS上“放置文件”的方式，也就是修改了HDFS文件系统的底层实现，给予了DBMS更大的权限来控制物理文件放置位置。这样才使得HAWG与外部表的解决方案不一样。在其PPT中，有HASH的方式实现JOIN的描述，这必须修改数据放置策略。因为默认的HDFS放置是随机的，不可以控制放置在哪个具体的节点上。之前有一篇论文对这种被成为Colocation的特性进行了讨论（见我的翻译稿http://labs.chinamobile.com/mblog/52251_192742）。我觉得这才是HAWG方案的关键，这也是其Pivotal HD不使用MapR的原因，因为它按照上层DBMS的需要进行了改造。
除了数据放置的关键技术外，要实现完整的DBMS而不只是一个查询解释器，应该还需要具备并发管理，也就是锁、多版本等一系列的东西；负载管理；权限控制；增量更新等等。这应该是HAWG对于Cohadoop多出来的东西。
经过了这些改动，基本可以实现构建在HDFS上的DBMS了，也就是它说的HAWG。跟前面说的一样，我不知道GreenPlum的策略是从此选择HDFS作为底层文件系统一条道路，还是HDFS和原来的POSIX文件系统兼容的方式，当然这取决于功能性能对比。
我仍然怀疑这种方案下性能是否能超过原来的POSIX文件方式，特别是插入、更新等操作以及大批量小查询。因为在原来的环境中，DBMS可以尽可能多的控制文件系统，控制文件的摆放，控制副本的位置等等，而现在不得不通过一个HDFS层后再到POSIX上。而且HDFS还是分布式，有Master等瓶颈的。所以我大胆的猜测GreenPlum是提供的一个Option，而不是下一代演进，虽然其宣称是下一代。在小的集群下，原来POSIX上的DBMS性能应该比HDFS上的要好。而就像在发布会的案例中暗示的那样，基于HDFS的DBMS方案，或者称为HAWG，瞄准的是Hadoop使用场景类似的大集群，是2000个节点的级别。而原来的POSIX上的DBMS，虽然是Share Noting架构，但是仍旧在扩展性上会有问题（见我的另一个分析《哪些设计影响了MPP DB的扩展性》，http://labs.chinamobile.com/mblog/52251_189687），所以它们大多是100个节点的。事实上，悄悄地说，当年淘宝、支付宝抛弃了GreenPlum DB正是因为此，嘿嘿。
果然，在发布会的性能比较中。HAWG的对比对象是HIVE以及Impala。当然要比这两个快得多。这是因为HIVE是原生的文件放置，而且使用MapReduce，又没有流水线。当然这里比的是单个查询，稍有片面啦。而Impala，你更是不应该把这两个对比了，因为不是一个东西嘛，虽然也是支持SQL。Impala是基于预定模型的，更像原来的MOLAP。我感觉最有意义的应该是GreenPlum两个版本的DB对比，以及所有MPP DB的对比。
目前只有这些发布会的数据可以分析，以后等拿到具体的东东后，做出测试再分享更细的东西。
最后还是总结一句：HAWG是一个大规模节点上通过SQL进行数据分析的好方案，但是要警惕重新向“One Size Fits All”的方向发展，这是大数据时代了嘛。
附加一个信息：华为也有类似的解决方案，2012实验室在搞，不过他们低调一些嘛。
本博文发表在移动Labs的文链是： http://labs.chinamobile.com/mblog/52251_195772
本博文发表在移动Labs的文链是： http://labs.chinamobile.com/mblog/52251_195772