大数据那些事(23):我是怎么分析Dremel系统的

做公众号到今天也算小半年了，有很多的收获。大数据系列转眼之间也若干万字了，最开始的时候的确没有能想到会写到今天这个规模。上篇关于Dremel的文章，读者给了我很多不同的反馈。其中很重要的一点就是，我的文章里面有一些东西，尤其是我下的结论和观点，对于吃瓜群众来说理解起来很困难。我假设了很多的背景知识。所以就出现有些人读起来觉得很爽，很多人觉得一头雾水。其中包括一名来自Google的员工反映说他是在用过了Dremel一段时间以后才能模糊的理解为什么选择那个protocol buffer定义的nested model是个错误。所以我觉得我有必要对自己这个系列作个简单小结，并在这个小结之外，探讨一下我是怎么样得出了这些结论，以及如果说是一个小白，有志于去学习大数据体系架构的一些东西，应该从什么地方开始。

我的大数据系列的文章，严格的来讲是混杂了三类不同的内容：

1. 江湖八卦，大数据历史
2. 一些基础知识和技术的普及和介绍
3. 我个人对于不同系统的观点和评价

我想对于第一类的话题，吃瓜群众多少都可以看得明白，如果看不明白，当然是我自己写得不好，对于第二类话题，我在写Google的三驾马车的时候，写得比较仔细一些，等到后来的系列里面其实就写得少了，最主要的原因有两个，其一是有读者留言觉得这些东西都比较简单，不需要再普及了，其二是这些文章的阅读量和赞赏金额往往是整个系列里面最惨不忍睹的。然而从上篇文章的反馈来看，有一部分人其实是希望有这个背景普及的，不然对于理解我文章的其他部分会觉得困难。

至于第三类的东西，我其实一直都在讲，经常的讲。这可能也是我文章系列里面喜欢的人读起来非常的high，而更多的人会觉得一头雾水的地方。从另外一个方面看，其实这多少也反应了这个读者是不是在大数据体系架构上有过足够的积累，尤其是开发经验上的积累。我想，我没有把有些结论的背景讲得更加的清楚，而是默认了我的读者们其实能明白这些背景知识，也是导致这种一头雾水很重要的原因。

一个大数据系统出来，我们通常去怎么学习呢？最直观的途径当然是自己去玩去摸这个系统。实践出真知。但是这个途径的学习是有很多问题的。最大的问题是很多人没有这个条件去接触这样的系统，我说的接触不是自己搞个虚拟机装上然后自娱自乐一番。而是说在实际的生产中应用。比如说，一般来说很多人是不会有机会去接触一个实际的HBase的集群的。所以有条件实践的人，就比没有条件实践的人有了更多第一手经验。这种第一手经验其实是很宝贵的。代表了这个人的眼界。

第二个办法就干脆去读源代码了。系统的实现最终体现在源代码上。但是我们必须要说，去读源代码的过程，有利有弊。而且很多时候代码不跑起来，很多东西其实是看不明白的。因此，还是说，有那个实际的环境很重要。如果没有的话，学习起来就会难很多。

第三个途径是读书读论文。对我来说，Dremel作为一个Google的内部系统，我其实没有任何办法去玩这个系统。所以我对于Dremel这个系统的了解只能从对方发表的资料里面去判断。书和论文其实是两种不同的东西，书好读，论文难读。原因是书往往是经过整合的知识，写书的人很多时候不是那些知识最开始发明的人，所以书写得客观，优点缺点都列出来，有比较有收益。书的坏处在于很多知识会滞后，有些时候的滞后会很久。论文难读，难读的原因很简单，在论文里面，不会有谎言，但也只会有片面的真相。你所读到和看到的，都是这个系统里面，作者们看来非常好的那一面，而作者们绝对不会告诉你这次成功的尝试之外的9999次失败的尝试都尝试了一些什么。作者们也绝对不会告诉你这个系统在哪哪哪有这样那样的缺陷。为什么？如果人老老实实的说了，论文就发不出来了啊。都是千疮百孔的东西，现在的review如此的激烈，在数据库一个顶级会议比如SIGMOD或者VLDB上，自己揭自己家丑的论文，除非背后站了个有权有势的SugarDaddy，对大部分人来说，那只能是老寿星上吊。

所以论文难读，是你需要理解论文里面传达的作者想要你看到的那一面，更需要理解作者不想让你看到的那一面，还得能够明白作者们可能在哪些地方失败了多少次，为什么失败了。惟其如此，才能有效的把握住一个论文里的系统到底好在哪里不好在哪里。说到这里自卖自夸一下，如果哪位读者有兴趣让我改论文或者对论文提供评价建议合作的话，起码数据库领域的三大顶级会议SIGMOD/VLDB/ICDE我还是非常有信心提供很有价值的服务的。毕竟在这个圈子里10余年，程序委员会成员也做过好几次了。

那么我们回到Dremel上来。我对Dremel这个系统的学习，作为一个非Google的人，主要是基于了对这篇的阅读和理解。次要的，是偶尔的和Google里面做这个那个的人吃饭聊天听八卦，以及和数据库领域的工业界和学术界大牛或者他们的弟子们聊天里面得到的消息得出的结论。在今天这篇文章里面，我们谈两个结论：（1）Dremel的execution系统并没有太多新的东西，但是反映了Google良好的Engineering水平（2）选择了Nested Model是个很错误的决定。

先说第一个。在数据库系统里，有个叫Volcano的系统，是Goetz做的。这个系统非常的有名，其中之一是确立了现代数据库的execution model。基本上的思想是一个Query是由很多个operator组成的execution Tree，这些operator从TableScan到filter到Join到Aggregate都有可能，但是它们都实现了同样的接口：open，getNext， close。所以如果我们要执行一个查询，只需要在Tree的Root上不停的call getNext，这样这棵书就像抽水机一样的开始从上往下抽。这个是非常典型的Pull Model。顺便插一句，广泛应用在数据库里面去解决并行执行问题的Exchange Operator也是这个系统先提出来的。

可以这样说，整个数据处理领域，很长的时间里面都是这样的execution model。Vocalno在很大程度上起到了一统江湖的目的。当然创新是有的，比如说MonteDB这个著名的Column Store，就把getNext从一个record变成了一个batch，里面有很多的record。再比如说HyperDB，用的是一个push model。但是呢，这个execution的整体框架和如何去pipeline数据的流动，本质上来说并没有那么翻天覆地的变化。Dremel的整个execution来说，读论文大家也可以感觉到，最多也只是修修补补的程度，谈不上什么推陈出新。这是我觉得这个系统并无太多新东西的缘由。

然而我们必须换个角度看问题，以前的时候，Parallel Database上面能搭上几十台机器稳定运行不算少了。Dremel这个系统所能处理的数据规模和它使用的节点数，早就不是一个数量级的了。能够让这个系统在更大规模上高效率的跑起来，Google的Engineering是不容小看的。

我们再来讨论一下Nested type的问题。Dremel的本质是一个数据仓库，上面跑的是OLAP的查询。但凡数据仓库了，数据逻辑层面的模型是Cube，而底下通常来说就是一个star schema或者snowflake schema，很多系统还会实现一些pre-aggregation，新的系统比如Apache Kylin在data model上也不可能跑开这一套。经典之所以成为经典是无数人犯错无数遍才得到的。

Dremel的存储是需要做一次ETL这样的工作，把其他的数据通过转化成为它自己的column store的格式之后才能高效率的查询的。这问题就来了，既然有这个ETL的过程，那么ETL完了以后，自己的系统却还保留了原始数据的那个nested model，这种完全不利于做查询优化的数据模型，不知道这个设计是怎么设计出来的。

而为了让这个nested model能更有效的工作，Dremel的成员还脑洞大开的发明了一套怎么把这个东西变成column store的办法。爱因斯坦说过，真理总是很美的。所以他的相对论在数学书很美。那么拿这个column store的东西来看，怎么样看都是生搬硬套的硬是要给按上去的感觉，岂止是丑，丑的不要太难看。如果选择了一个flat 的model，最大的顾虑是数据冗余造成的存储问题。但是因为选择了column store，这种数据冗余的问题常用的压缩办法，哪怕只是简简单单的dictionary编码加RLE也应该能够很有效的解决了。所以在我看来，作为一个要对数据进行预处理的系统的Dremel，选择了一个nested model，然后却在上面硬套上一个column store的办法，那只能说丑！丑！丑！明明可以用更简单的办法做出更高效率的东西来，非得上歪门邪道去，就是我个人对Dremel的数据模型的看法。

最后谈一谈Parquet，这个东西稍微复杂一些。Nested model并非一无是处。比如说service在写raw log的时候，用nested model对log来说非常的合理。但是通常log是一行一行直接写到文件后面去的。如果说一个公司说我希望只存一份数据，基于nested model，然后什么样的应用都能用起来，这个时候选择了用Parquet来存，是不是就是一个错误的决定，不一定。只是看公司是希望优化什么场景了。写log的场景，对单个log访问的速度，还是说OLAP query的查询。但是实话来说，我觉得给OLAP的查询提供一套单独设计的存储，只要公司条件允许，会是一个更好的选择。如果说公司规模不大，或者说财力有限，又希望保持nested model还希望OLAP的查询最快，但是并不在乎对single log的访问速度的时候，Parquet也是这种trade off下的一个选择。

关于我对Dremel的结论以及我是如何做出这些结论的，我就写到这里吧，希望能给大家，尤其是那些留言给我，希望我能更详细解释的朋友一个参考。也希望我这里写的如何去学习大数据系统的一些观点能对大家有所帮助。