大数据那些事(22):Interactive的Dremel

对于那些喜欢读我文章的读者，还请见谅耐心等等，一篇文章要写好了，是需要很多时间精力，以及写作状态。写出不好的文章来，其实还不如给自己多点时间写好一些。不然写出来的就没人喜欢读了。要是喜欢我写的文章，还请在朋友圈里帮忙转一下多宣传，在这里谢谢大家了。要是真的觉得我写的好呢，还请多多点赞赞赏啊，钱多总是比钱少好看。

2010年的时候Google发表了一篇论文，介绍了一个新的系统Dremel。这个系统号称能提供比MapReduce更快的查询速度。所以从此开启了所谓的Interactive Query的阶段。这个系统若干年后也就成了Google的BigQuery的后端。

MapReduce的慢其实在这个之前已经被无数次的证实，无论Google内部还是外部。所以Google内部一直寻求更加快速的查询的解决方案的努力从未停止过。Dremel起于2006年，是由新人在Google的Kirkland的办公室，远离总部的地方做出来的。这也是我们在Google比较重大的，对BigData有影响的论文里面第一次没有见到Jeff Dean的名字。

从我知道的内部消息来看，Dremel是战胜了好多个其他系统最后在Google确立起江湖地位的。有个我认识的老工程师，曾经作为Dremel team的人，曾经有段时间的工作就是写从其他的系统的查询语言转化到Dremel，以便它们的application们可以顺利过渡过来。据说内部差不多竞争的至少有4个。这些竞争对手的系统们各个都被杀死了，很多也没有留下遗体。有个叫PowerDrill的项目，临死前在VLDB发了一篇论文，这算得上是公开有据可考的唯一的一个。

Dremel刚出来的时候还是非常小心翼翼的避免和MapReduce冲突的。从无数的宣传资料和ppt上可以看到，他们出来演讲的时候都会说自己是MapReduce的一个补充，是为少量到中等规模的数据查询服务的，而MapReduce则用来处理更大量的数据。这种宣传在Dremel越来越成功，以及FlumeJava差不多把整个MapReduce的team都要收编了的今天就显得多余了。所以胆肥的Dremel队伍现在已经比较少再提自己是MapReduce的有益补充了。

其实MapReduce慢早就不是什么不知道的问题，Dremel之前的半年微软Cosmos组也打算做interactive query了。当然虽然说是论文发表半年前，但是Dremel是2006年开始做的，而Cosmos在06年连影子都还没有，09年才开始有这个想法。之后因为一些非技术的原因，Architect跳去Google做Dremel了更是对此有直接的影响。至于最后论文发出来那是2015年的VLDB，那个时候早就天下大乱，Cosmos经过无数次的Reorg，早已经物是人非了。

说到Dremel当然要提一个在华盛顿大学读了本科的中国人 JingJing Long。他是Dremel的早期员工之一，后来成了那个team的manager，再后来又自立门户了。这位算得上是在Google Kirkland里混得相当不错的华人了。此人有一个最大的特点就是从来不说中文，尽管他会说。所以在Google Kirkland的华人里面赢得了装B华人的美称。

Dremel出来没多久，开源社区，尤其是Hadoop的批发商们都纷纷雀跃而起。Cloudera开始做Impala，MapR则做了Drill，Hortonworks说我们干脆直接improve HIVE好了，所以就有了包括Apache Tez在内的effort。当然按照业内人士的观点，这几个都借了Dremel的名而已，实际上挂羊头卖狗肉这个事情不但中国人会，老外也会做。名不正言不顺好像在哪里都讲得通。

作为一个狗黑，我每次都不得不承认Google在Distributed System的基础框架的开发上有着得天独厚的优势。所以每次Google的系统出来，有几个方面的表现都非常的好，一是Scalability，二是Fault Tolerance。Dremel也不例外。关于这方面的积累，短期内不是其他公司可以超越的，长期我最看好Uber。

然而Google对分布式系统的精湛不能掩盖Google在application上的无能。Google好像从来都没有明白过什么样的user experience是重要的。Dremel的论文来看主要两大卖点，第一是那个execution engine，通过streaming直接pipeline结果，加之同时让多个node执行同一个任务来提供fault tolerance。这些其实都是老调调了。在我个人看来并无本质上的创新。这是体现Google Engineering水平的地方。不可否认，Google的Engineering水平是相当的高。

至于第二点，是在于数据模型的选择上。Dremel选择了和protocol buffer兼容的nested data model。通常来说这种model是比较难优化的，对analytical query尤其。然后这些聪明的engineer又发明了一套通过增加两个id来达到对每个nested field可以进行用column store的方式存储。 这样一来，column store相对于OLAP的所有优点都能用上，速度当然是快了。

但是我想对于任何一个有一定研究经历，对数据模型有一些了解的人，恐怕都会觉得这个Data Model实在是选的非常的糟糕，而在这个模型上建立起来的那套column store的存储方式，只能说是奇巧淫技。既然已经用了column store，又有compression，而且数据本来就是要预处理的，直接上一个flat的model简单得多，反正数据冗余在compression面前很容易就可以被解决。这个问题我问过不少大牛，学术圈的工业界的，大牛们其实基本上和我一个观点。当然最近我听说Dremel team自己也为自己当初做的那个决定而在哭。

这种对于protocol buffer毫无条件的兼容和妥协，其实很大程度上反应了Dremel的人很多不是科班出身的，对database的理论尤其data modeling并不熟悉。不过我们也不能怪太多。毕竟Dremel还是给大家展现了Google非常强大的distributed system的底蕴和精湛的软件开发能力。

所以还是那个观点，一离开分布式系统，Google就开始各种抓瞎。我有天和一个朋友吃饭，朋友问我到底是一群很好的engineer重要还是说有商业头脑和眼界的人带一群二流的engineer就够了。仔细想想，前者是Google后者是Amazon。前者黑科技多的一个又一个的，从眼镜到球，从Google Wave到Google Plus，每次来一个死一个，来一个死一个，前赴后继的。后者除了那个Phone以外，很难看到什么实质性的糟点。来一个卖一个。所以由此看来，空有一群聪明的Engineer也不代表长治久安啊。Dremel这个nested model真的是一个大傻逼的决定。

当然，Google喷出来的都是香的，所以Apache的人比如Cloudera很快就搞了一个东西叫做Parquet，这个东西就成了Dremel的那个nested model的开源克隆版。我们必须要说，这个东西现在被大量的项目和公司使用。那么到底是公司们啥呢，还是我在这边瞎BB了呢？