Google在推出了三大论文之后，并没有停止震撼世界的步伐，例如在Dremel中，借助精巧的数学模型，可以在3秒中分析1PB数据，便是又一大创新。
让我们来看一下Dremel的魅力：Dremel号称能够3秒分析1PB数据，如果在一个PB级别的数据集上面，将任务缩短到秒级，无疑需要大量的并发，假设磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的同时并发读操作。虽然Google一向是用廉价机器办大事的好手，但是做过大数据的研发都知道，机器越多，出问题概率越大，强如MapReduce都会经常遇到慢节点的问题，而Sql查询引擎在如此大的集群规模中实现短时间计算操作，就需要有足够的容错考虑，保证整个分析的速度不被集群中的个别慢节点影响。
Dremel是MR交互式查询能力不足的补充，和MapReduce一样，Dremel也需要和数据运行在一起，将计算移动到数据上面，所以它需要GFS这样的文件系统作为存储层。在设计之初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立分析原型。Dremel中的数据是用列式存储的，在分析数据的时候，可以只扫描需要的那部分数据，减少CPU和磁盘的访问量。同时，列式存储是压缩友好的，可以综合CPU和磁盘的性能，在存储效率和查询效率上起到平衡的作用。Dremel结合了Web搜索 和并行DBMS的技术，首先借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询，实现大事化小、小事化了的分布式数据处理思想；其次，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样使用起来非常方便。
设想一个使用场景：我们有一名美女数据分析师，她有一个新的想法要验证，要验证这个想法，需要在一个上亿条数据上面，跑一个查询，看看结果和她的想法是不是一样，她可不希望等太长时间，最好几秒钟结果就出来，因为想法不一定完善，还需要不断调整语句，最后她验证了想法，发现了数据中的价值，将这个语句完善成一个长期运行的任务。或许每一个大数据开发人员都或多或少的遇到了类似的场景，也许巧合的是数据的PM一般都是女士，当然每个人应对的方法也都不同，有一些态度强硬，也有一些会据理力争，但基本没有谁会为了一位美女而额外增加许许多多的工作量。如果有一天Dremel的技术普及了，或许大家会将更多的心思放在沟通上，吵架少了，氛围也会变得更加的和谐。
对于Google的分析人员，由于集团内部的开发统一性，数据都是存在GFS上的，可以方便的通过MapReduce将数据导入到Dremel中去，还可以做一些额外的预处理工作，然后分析师使用Dremel，轻松愉悦的分析数据、建立模型，最后可以编制成一个长期运行的MapReduce任务。这种处理方式，让笔者联想到Greenplum的Chorus，Chorus也可以为分析师提供快速的数据查询，不过解决方案是通过预处理，导入部分数据，减少数据集的大小，避开的瞬时分析大数据的难题。Chorus最近即将开源，可以关注下。
让我们把目光放到Dremel的数据模型上：
在Google, 用Protocol Buffer常常作为序列化的方案。其数据模型可以用数学方法严格的表示如下：
t=dom|<A1:t[?|?],...,An:t[?|?]>
其中t可以是一个基本类型或者组合类型，其中基本类型可以是integer、float和string，组合类型可以是若干个基本类型拼凑。星号 (*)指的是任何类型都可以重复，就是数组一样。问号(?)指的是任意类型都是可以是可选的。简单来说，除了没有Map外，和一个Json几乎没有区别。
下图是一个典型的例子，Schema定义了一个组合类型Document，有一个必选列DocId，可选列Links，还有一个数组列Name，可以用Name.Language.Code来表示Code列。
这种数据格式是语言无关，平台无关的。可以使用Java来写MR程序来生成这个格式，然后用C++来读取。在这种列式存储中，能够快速通用处理也是非常的重要的。上图是一个示例数据的抽象的模型，下图是这份数据在Dremel实际的存储的格式。
如果是关系型数据，而不是嵌套的结构。存储的时候，我们可以将每一列的值直接排列下来，不用引入其他的概念，也不会丢失数据。对于嵌套的结构，我们 还需要两个变量R (Repetition Level)、D (Definition Level) 才能存储其完整的信息。
Repetition Level是记录该列的值是在哪一个级别上重复的。举个例子说明：对于Name.Language.Code 我们一共有三条非Null的记录。
1. 第一个是”en-us”，出现在第一个Name的第一个Lanuage的第一个Code里面，在此之前，这三个元素是没有重复过的，都是第一个，所以其R为0；
2. 第二个是”en”，出现在下一个Lanuage里面，也就是说Lanague是重复的元素，Name.Language.Code中Lanague排第二个，所以其R为2；
3. 第三个是”en-gb”，出现在下一个Name中，Name是重复元素，排第一个，所以其R为1。
我们可以想象，将所有的没有值的列，设值为NULL，如果是数组列，我们也想象有一个NULL值。有了Repetition Level，我们就可以很好的用列表示嵌套的结构了。但是还有一点不足。就是还需要表示一个数组是不是我们想象出来的。
Definition Level 是定义的深度，用来记录该列是否是”想象”出来的。所以对于非NULL的记录，是没有意义的，其值必然为相同。同样举个例子，如Name.Language.Country,
第一个”us”是在R1里面，其中Name、Language、Country是有定义的，所以D为3；
第二个”NULL”也是在R1的里面，其中Name,Language是有定义的，其他是想象的，所以D为2；
第三个”NULL”还是在R1的里面，其中Name是有定义的,其他是想象的，所以D为1；
第四个”gb”是在R1里面，其中Name、Language、Country是有定义的，所以D为3。
就是这样，如果路径中有required，可以将其减去，因为required必然会define，记录其数量没有意义。
理解了如何存储这种嵌套结构。写没有难度。读的时候，我们只读其中部分字段，来构建部分的数据模型。例如，只读取DocID和 Name.Language.Country。我们可以同时扫描两个字段，先扫描DocID，记录下第一个，然后发现下一个DocID的R是0，于是该读 Name.Language.Country，如果下一个R是1或者2就继续读，如果是0就开始读下一个DocID。
下图展示了一个更为复杂的读取的状态机示例。在读取过程中使用了Definition Level来快速Jump,提升性能。
到此为止，我们已经知道了Dremel的数据结构，就像其他数据分析系统一样，数据结构确定下来，功能就决定了一大半。对于Dremel的数据查询，必然是“全表扫描”，但由于其巧妙的列存储设计，良好的数据模型设计可以回避掉大部分Join需求和扫描最少的列。
Dremel可以使用一种SQL-like的语法查询嵌套数据。由于Dremel的数据是只读的，并且会密集的发起多次类似的请求。所以可以保留上次请求的信息，还优化下次请求的explain过程。那又是如何explain的呢？
这是一个树状架构，当Client发其一个请求，根节点受到请求，根据metadata，将其分解到枝叶，直到到位于数据上面的叶子Server。经过不断的扫描处理数据，不断汇总到根节点，最终计算出结果。
举个例子：对于请求：
SELECT A, COUNT(B) FROM T GROUP BY A
根节点收到请求，会根据数据的分区请求，将请求变成可以拆分的样子。原来的请求会变为：
SELECT A, SUM(c) FROM (R1 UNION ALL ... Rn) GROUP BY A
R1,…RN是T的分区计算出的结果集。越大的表有越多的分区，越多的分区可以越好的支持并发。然后再将请求切分，发送到每个分区的叶子Server上面去，对于每个Server：
Ri = SELECT A, COUNT(B) AS c FROM Ti GROUP BY A
结构集一定会比原始数据小很多，处理起来也更快。根服务器可以很快的将数据汇总，至于具体的聚合方式，可以使用现有的并行数据库技术。
Dremel是一个多用户的系统。切割分配任务的时候，还需要考虑用户优先级和负载均衡；不仅如此，对于大型系统，还需要考虑容错，如果一个叶子Server出现故障或变慢，不能让整个查询也受到明显影响。通常情况下，每个计算节点，执行多个任务。例如，有3000个叶子Server，每个Server使用8个线程，有可以有24000个计算单元；如果一张表可以划分为100000个区，就意味着大约每个计算单元需要计算5个区；这执行的过程中，如果某一个计算单元太忙，就会另外启一个来计算，而这个过程是动态分配的。对于GFS这样的存储，一份数据一般有3份拷贝，计算单元很容易就能分配到数据所在的节点上，典型的情况可以到达95%的命中率。Dremel还有一个配置，就是在执行查询的时候，可以指定扫描部分分区，比如可以扫描30%的分区，在使用的时候，相当于随机抽样，加快查询。
说了这么多，那么Dremel的实际性能如何呢？实验的数据源如下表示，大部分数据复制了3次，也有一个两次，每个表会有若干分区，每个分区的大小在100K到800K之间。假设压缩率是25%，并且计入复制3份的事实的话，T1的大小已经达到PB级别，这么小且巨量的分区，对于GFS的要求很高，现在的Hdfs稳定版恐怕受不了。接下来的测试会逐步揭示其是如何超过MR，并对性能作出分析。
我们继续进行列存测试。首先，我们测试看看列存的效果，对于T1表，1GB的数据大约有300K行，使用列存的话压缩后大约在375MB，这台机器磁盘的吞吐在70MB/s左右，这1GB的数据，就是我们的现在的测试数据源，测试环境是单机。
曲线A是用列存读取数据并解压的耗时；曲线B是一条一条记录挨个读的时间；曲线C是在B的基础上，加上了反序列化的时间；曲线D是按行存读并解压的耗时；曲线E加上了反序列化的时间。因为列很多，反序列化耗时超过了读并解压的50%。从图上可以看出。如果需要读的列很少的话，列存的优势就会特别的明显。对于列的增加，产生的耗时也几乎是线性的，而一条一条该个读和反序列化的开销是很大的，几乎都在原来基础上增加了一倍。而按行读，列数的增加没有影响，因为一次性读了全部列。
将Dremel与MapReduce进行对比测试，MR和Dremel最大的区别在于行存和列存，如果不能击败MapReduce，Dremel可以说就没有意义了。我们使用最常见的WordCount测试，计算这个数据中Word的个数：
Q1: SELECT SUM(CountWords(txtField)) / COUNT(*) FROM T1
上图是测试的结果。使用了两个MR任务。这两个任务和Dremel一样都运行在3000个节点上面。如果使用列存，Dremel的按列读的MR只需 要读0.5TB的数据，而按行存需要读87TB。MR提供了一个方便有效的途经来讲按行数据转换成按列的数据，Dremel可以方便的导入MapReduce的处理结果。
接下来我们要对比在T2表示使用两个不同的Group BY查询。T2表有24 billion 行的记录。每个记录有一个 item列表，每一item有一个amount 字段，总共有40 billion个item.amount，这两个Query分别是：
Q2: SELECT country, SUM(item.amount) FROM T2 GROUP BY country
Q3: SELECT domain, SUM(item.amount) FROM T2 WHERE domain CONTAINS ’.net’ GROUP BY domain
Q2需要扫描60GB的压缩数据，Q3需要扫描180GB，同时还要过滤一个条件。
上图是这两个Query在不同的server拓扑下的性能，每个测试都是有2900个叶子Server；在2级拓扑中，根server直接和叶子 Server通信；在3级拓扑中，各个级别的比例是1:100:2900，增加了100个中间Server；在4级拓扑中，比例为 1:10:100:2900。
Q2可以在3级拓扑下3秒内执行完毕，但是为他提供更高的拓扑级别，对性能提升没有裨益。相比之下，为Q3提供更高的拓扑级别，性能可以有效提升。这个测试体现了树状拓扑对性能提升的作用。
对于刚刚的两个查询，具体的每个分区的执行情况是这样的：
可以看到99%的分区都在1s内完成了。Dremel会自动调度，使用新的Server计算拖后腿的任务。
由于Demel支持List的数据类型，有的时候，我们需要计算每个记录里面的各个List的聚合：
Q4 : SELECT COUNT(c1 > c2) FROM
(SELECT SUM(a.b.c.d) WITHIN RECORD AS c1,
SUM(a.b.p.q.r) WITHIN RECORD AS c2
FROM T3)
我们需要count所有sum(a.b.c.d)比sum(a.b.p.q.r)，执行这条语句实际只需要扫描13GB的数据，耗时15s，而整张表有70TB。如果没有这样的嵌套数据结构，这样的查询会很复杂。
Dremel有良好的扩展性，可以通过增加机器来缩短查询的时间。并且可以处理数以万亿计的记录。对于下列查询，使用不同的叶子Server数目来进行测试：
Q5: SELECT TOP(aid, 20), COUNT(*) FROM T4 WHERE bid = fvalue1g AND cid = fvalue2g
可以发现CPU的耗时总数是基本不变的，在30万秒左右，但是随着节点数的增加，执行时间也会相应缩短，几乎呈线性递减。如果我们使用通过CPU时间计费的“云计算”机器，每个租户的查询都可以很快，成本也会非常低廉。
一个大团队里面，总有几个拖油瓶，对于有万亿条记录的T5，我们执行下面的语句：
Q6: SELECT COUNT(DISTINCT a) FROM T5
值得注意的是T5的数据只有两份拷贝，所以有更高的概率出现坏节点和拖油瓶，这个查询需要扫描大约1TB的压缩数据，使用2500个节点。
可以看到99%的分区都在5S内完成的。不幸的是，有一些分区需要较长的时间来处理，尽管通过动态调度可以加快一些，但在如此大规模的计算上面，很难完全不出问题。如果不在意太精确的结果，完全可以小小减少覆盖的比例，大大提升相应速度。
Google Dremel的能在如此短的时间内处理这么大的数据，的确是十分惊艳的，有个伯克利分校的教授Armando Fox说过一句话“如果你曾事先告诉我Dremel声称其将可做些什么，那么我不会相信你能开发出这种工具”。这么给力的技术，必然对业界造成巨大的影响，第一个被波及到的必然是Hadoop。Dremel的公开论文里面已经说的很明白，Dremel不是用来替代MapReduce，而是和其更好的结合。Hadoop的Hive、Pig无法提供及时的查询，而Dremel的快速查询技术可以给Hadoop提供有力的补充，同时Dremel可以用来分析MapReduce的结果集，只需要将 MapReduce的OutputFormat修改为Dremel的格式，就可以几乎不引入额外开销，将数据导入Dremel。使用Dremel来开发数 据分析模型，MapReduce来执行数据分析模型。
Hadoop的Hive、Pig现在也有了列存的模式，架构上和Dremel也接近，但是无论存储结构还是计算方式都没有Dremel精致。要想在Hadoop中山寨一个Dremel，并且相对现有解决方案有突破，Hadoop自身需要一些改进。一个是HDFS需要对并发细碎的数据读性能有大的改进，HDFS需要更加的低延迟，再者是Hadoop需要不仅仅支持MapReduce这一种计算框架。其他部分Hadoop都有对应的开源组件，所以说万事俱备只欠东风。
Dremel现在还没有一个可以运行的开源实现，不过我们看到很多努力，一个是Apache的Drill，一个是OpenDremel/Dazo。
OpenDremel是一个开源项目，最近改名为Dazo。可以在GoogleCode上找到http://code.google.com/p/dremel/，目前还没有发布。作者声称他已经完成了一个通用执行引擎和OpenStack Swift的集成。
Drill是 Hadoop的赞助商之一MapR发起的。Drill作为一个Dremel的山寨项目，有和Dremel相似的架构和能力，他们希望Drill最终会想 Hive、Pig一样成为Hadoop上的重要组成部分，为Hadoop提供快速查询的能力。和Dremel有一点不同，在数据模型上，开源的项目需要支持更标准的数据结构，比如CSV和JSON，同时Drill还有更大的灵活性，支持多重查询语言、多种接口。现在Drill的目标是完成初始的需求架构，完成一个初始的实现，这个实现包括一个执行引擎和DrQL。DrQL是一个基于列的格式，类似于Dremel，目前已经完成的需求和架构设计，总共分为了四个组件：
1. Query language：类似Google BigQuery的查询语言，支持嵌套模型，名为DrQL；
2. Low-lantency distribute execution engine：执行引擎，可以支持大规模扩展和容错，可以运行在上万台机器上计算数以PB的数据；
3. Nested data format：嵌套数据模型，和Dremel类似，也支持CSV、JSON、YAML类似的模型，这样执行引擎就可以支持更多的数据类型。
4. Scalable data source：支持多种数据源，现阶段以Hadoop为数据源。
目前这四个组件在分别积极的推进，Drill也非常希望有社区其他公司来加入，Drill希望加入到Hadoop生态系统中去。
在介绍了Google Dremel的使用场景、设计实现、测试实验和对开源世界的影响之后，相信不久的将来，Dremel的技术会得到广泛的应用。
