大数据那些事(26):Apache Drill之我很土但我毕业了

写大数据系列越来越进入到不知所云和胡说八道的边界了。最大的原因还是我对open source的了解并不来源于亲身的实践。所谓纸上得来终觉浅说的就是我这样的人吧。

每次想到MapR的时候，我都不得不联想到那个快男歌手张杰。不论他是多么的有唱歌技术，最为吸引大众的依旧是那个和鲁迅笔下的闰土如出一辙的土味。MapR在Hadoop的众多厂商里面，就有那种无论自称技艺多么高超，但是就是无法去除那种土味的感觉。

当然这多少和MapR这个公司有关。自从Yahoo出了Zookeeper以后，Hadoop的整个社区整的和动物园一样，连麒麟神兽都出来凑热闹，哪个顶级项目要不整个动物名都说不过去。可MapR不一样，作为Hadoop的批发商，直接就把MapReduce给缩写做商标了。作为要做Dremel的opensource版，来应对更快更高更强的要求的MapR又一次发扬了懒土省的美德，取了个名字叫Drill。

这个项目很快成了Apache的孵化器项目，然后就到顶级了。差不多这个项目起来的时候在2013年，比Impala开始进展要慢，但是Drill毕业的却比Impala还早。Impala现在还在孵化器里，而Drill则已经堂而皇之的成了顶级项目了。

Drill是不是Dremel呢？当然不是的。从我能看到的关于Drill来介绍以外。Drill有那么几个重要的特点。首先是Drill对nested data的支持。关于这种半结构化的支持来说，Drill做得看起来是相当不错。在SQL语言的使用上也是很简单的使用点来引用下一层的数据。Drill对于数据已经包含了Schema的类型比如JSON的表现，至少从使用性来看，可谓我见过的工具里面很好的。但是当这个界限成为自己并不是包含了Schema的时候，那就需要额外指定schema或者就只能指望drill把数据给乱parse了。这在CSV文件里面就会显得非常的糟糕。

但我想Drill最重要的一个卖点还是Data Federation。Data Federation并不是什么新鲜东西。IBM199x年就提出来了。至于市面上出现的产品也有很多。但是实际情况怎么样，我想日渐壮大的ETL队伍和产品，对于Data Federation给出了一个非常好的回答。

说实话因为工作的关系我也需要处理Data Federation的一些设计，但是我们公司产品在这个方面的要求基本上就是能用就好。能够连接若干种不同的数据源并且在它们之间做federation，任何已知的系统都不可能表现得太好。不是说人不聪明，是问题太难太多情况。不是国军太烂，是鬼子太猛。所以我看到Drill是一个定义在Data Federation上的系统，那我大致也能想象这个系统的性能不可能好到哪里去。但是应该是一个还不错的ad-hoc查询分析的工具。非常适合需要在多个数据源里面做简单的分析的数据科学家们用。但是应该不太适合来做workflow啊dashboard之类的东西。

作为自称的Dremel的替代品，现在流行什么说什么，比如说cost-base的optimization这个基本上从HIVE到IMPALA到Drill都在吹，到底有多好，我想很多做的其实非常的差。因为cost本身是应该怎么定义，在一个大规模的分布式系统下本身就不容易。如果有多个数据源，做Data Federation，以我亲身的经验来说，这个cost的定义实在是难！难！难！最终大家都只能妥协，在凑合能用的前提下，尽量的能快点就不错。 同理，vectorization还有code generation现在也是大坑。Drill当然也必须说自己是做的。至于做得到底有多好，我想，小人之心的我估计它们做得不咋地。

Drill的Data Federation和通常意义上的Data Federation系统还不一样，它可以通过自己定义plugin来增加对新数据源的支持。我的理解应该就是实现了一个TableScan这样的东西。对于是否能有效的把一整个subquery全部都送去数据源那边执行，从我阅读理解来看是不能。所以这个Data Federation的系统，应该灵活有余，而实际的性能不怎么样。