http://www.csdn.net/article/2012-08-20/2808870
Mike Olson是Hadoop运动背后的主要推动者，但这还远远不够，目前Google内部使用的大数据软件Dremel使大数据处理起来更加智能。
Mike Olson目前任职于世界上最热的软件专业公司——Cloudera（硅谷的创业企业），并担任Cloudera的首席执行官。Cloudera围绕开源软件平台Hadoop发展自身的业务，开源软件平台Hadoop已经使得Google变身网络上最主导的力量。
预计到2016年Hadoop将会推动软件市场，并创造8.13亿美元的价值。不过Mike Olson表示这已经是老新闻了。
Hadoop的火爆要得益于Google在2003年底和2004年公布的两篇研究论文，其中一份描述了GFS（Google File System），GFS是一个可扩展的大型数据密集型应用的分布式文件系统，该文件系统可在廉价的硬件上运行，并具有可靠的容错能力，该文件系统可为用户提供极高的计算性能，而同时具备最小的硬件投资和运营成本。
另外一篇则描述了MapReduce，MapReduce是一种处理大型及超大型数据集并生成相关执行的编程模型。其主要思想是从函数式编程语言里借来的，同时也包含了从矢量编程语言里借来的特性。基于MapReduce编写的程序是在成千上万的普通PC机上被并行分布式自动执行的。8年后（2012年），Hadoop已经被广泛使用在网络上，并涉及数据分析和各类数学运算任务。但Google却提出更好的技术。
在2009年，网络巨头开始使用新的技术取代GFS和MapReduce。Mike Olson表示“这些技术代表未来的趋势。如果你想知道大规模、高性能的数据处理基础设施的未来趋势如何，我建议你看看Google即将推出的研究论文”。
自Hadoop兴起以来，Google已经发布了三篇研究论文，主要阐述了基础设施如何支持庞大网络操作。其中一份详细描述了Caffeine，Caffeine主要为Google网络搜索引擎提供支持。
在Google采用Caffeine之前，Google使用MapReduce和分布式文件系统（如GFS）来构建搜索索引（从已知的Web页面索引中）。在2010年，Google搜索引擎发生了重大变革。Google将其搜索迁移到新的软件平台，他们称之为“Caffeine”。Caffeine是Google出自自身的设计，Caffeine使Google能够更迅速的添加新的链接（包括新闻报道以及博客文章等）到自身大规模的网站索引系统中，相比于以往的系统，新系统可提供“50%新生”的搜索结果。
在本质上Caffeine丢弃MapReduce转而将索引放置在由Google开发的分布式数据库BigTable上。作为Google继GFS和MapReduce两项创新后的又一项创新，其在设计用来针对海量数据处理情形下的管理结构型数据方面具有巨大的优势。这种海量数据可以定义为在云计算平台中数千台普通服务器上PB级的数据。
提供的企业存储空间达到PB级别，即100万GB空间。 （1PB=1000TB，1TB=1000GB，1GB=1000MB）
另一篇介绍了Pregel，Pregel主要绘制大量网上信息之间关系的“图形数据库”。而最吸引人的一篇论文要属被称之为Dremel的工具。
点击查看大图
专注于大型数据中心规模软件平台的加利福尼亚伯克利分校计算机科学教授Armando Fox表示“如果你事先告诉我Dremel可以做什么，那么我不会相信你可以把它开发出来”。
Dremel是一种分析信息的方式，Dremel可跨越数千台服务器运行，允许“查询”大量的数据，如Web文档集合或数字图书馆，甚至是数以百万计的垃圾信息的数据描述。这类似于使用结构化查询语言分析传统关系数据库，这种方式在过去几十年被广泛使用在世界各地。
Google基础设施负责人Urs Hölzle表示“使用Dremel就好比你拥有类似SQL的语言，并可以无需任何编程的情况下只需将请求输入命令行中就可以很容易的制定即席查询和重复查询”。
区别在于Dremel可以在极快的速度处理网络规模的海量数据。据Google提交的文件显示你可以在几秒的时间处理PB级的数据查询。
目前Hadoop已经提供了在庞大数据集上运行类似SQL的查询工具（如Hadoop生态圈中的项目Pig和Hive）。但其会有一些延迟，例如当部署任务时，可能需要几分钟的时间或者几小时的时间来执行任务，虽然可以得到查询结果，但相比于Pig和Hive，Dremel几乎是瞬时的。
Holzle表示Dremel可移执行多种查询，而同样的任务如果使用MapReduce来执行通差需要一个工作序列，但执行时间确实前者的一小部分。Dremel可在大约3秒钟时间里处理1PB的数据查询请求。
Armando Fox表示Dremel是史无前例的，Hadoop作为大数据运动的核心一直致力构建分析海量数据工具的生态圈。但就目前的大数据工具往往存在一个缺陷，与传统的数据分析或商业智能工具相比，Hadoop在数据分析的速度和精度上还无法相比。但目前Dremel做到了鱼和熊掌兼得。
Dremel做到了“不可能完成的任务”，Dremel设法将海量的数据分析于对数据的深入挖掘进行有机的结合。Dremel所处理的数据规模的速度实在令人印象深刻，你可以舒适的探索数据。在Dremel出现之前还没有类似的系统可以做的像Dremel这样出色。
据Google提交的文件来看，Google从2006年就在内部使用这个平台，有“数千名”的Google员工使用Dremel来分析一切，从Google各种服务的软件崩溃报告到Google数据中心内的磁盘行为。这种工具有时会在数十台服务器上使用，有时则会在数以千计的服务器上使用。
Mike Olson表示尽管Hadoop取得的成功不容置疑，但构建Hadoop生态圈的公司和企业显然慢了，而同样的情况也出现在Dremel上，Google在2010年公布了Dremel的相关文档，但这个平台还没有被第三方企业充分利用起来，目前以色列的工程团队正在建设被称为OpenDremel的克隆平台。David Gruzman表示OpenDremel目前仅仅还在开始阶段，还需要很长时间进行完善。
换句话说即使你不是Google的工程师你同样可以使用Dremel。Google现在提供的BigQuery的服务就是基于Dremel。用户可通过在线API来使用这个平台。用户可以把数据上传到Google，并在Google基础设施中运行用户的查询服务。而这只是Google越来越多云服务的一部分。
早期用户通过Google App Engine构建、运行、并将应用托管在Google基础设施平台之上。而现今Google提供了包括BigQuery和Google Compute Engine等服务和基础设施，这些服务和基础设施可使用户瞬时接入虚拟服务器。
全球很多技术都落后于Google，而Google自身的技术也正在影响全球。（李智/编辑）
Google Dremel 原理 – 如何能3秒分析1PB
简介
Dremel 是Google 的“交互式”数据分析系统。可以组建成规模上千的集群，处理PB级别的数据。MapReduce处理一个数据，需要分钟级的时间。作为MapReduce 的发起人，Google开发了Dremel将处理时间缩短到秒级，作为MapReduce的有力补充。Dremel作为Google BigQuery的report引擎，获得了很大的成功。最近Apache计划推出Dremel的开源实现Drill，将Dremel的技术又推到了浪尖 上。
Google Dremel设计
根据Google公开的论文《Dremel: Interactive Analysis of WebScaleDatasets》可以看到Dremel的设计原理。还有一些测试报告。论文写于2006年，公开于2010年，Google在处理大数据方面，果真有得天独厚的优势。下面的内容，很大部分来自这篇论文。
随着Hadoop的流行，大规模的数据分析系统已经越来越普及。数据分析师需要一个能将数据“玩转”的交互式系统。如此，就可以非常方便快捷的浏览数据，建立分析模型。Dremel系统有下面几个主要的特点：
1, Dremel是一个大规模系统。在一个PB级别的数据集上面，将任务 缩短到秒级，无疑需要大量的并发。磁盘的顺序读速度在100MB/S上下，那么在1S内处理1TB数据，意味着至少需要有1万个磁盘的并发读! Google一向是用廉价机器办大事的好手。但是机器越多，出问题概率越大，如此大的集群规模，需要有足够的容错考虑，保证整个分析的速度不被集群中的个 别慢(坏)节点影响。
2, Dremel是MR交互式查询能力不足的补充。和 MapReduce一样，Dremel也需要和数据运行在一起，将计算移动到数据上面。所以它需要GFS这样的文件系统作为存储层。在设计之 初，Dremel并非是MapReduce的替代品，它只是可以执行非常快的分析，在使用的时候，常常用它来处理MapReduce的结果集或者用来建立 分析原型。
3, Dremel的数据模型是嵌套(nested)的。互 联网数据常常是非关系型的。Dremel还需要有一个灵活的数据模型，这个数据模型至关重要。Dremel支持一个嵌套(nested)的数据模型，类似 于Json。而传统的关系模型，由于不可避免的有大量的Join操作，在处理如此大规模的数据的时候，往往是有心无力的。
4, Dremel中的数据是用列式存储的。使用列式存储，分析的时候，可 以只扫描需要的那部分数据的时候，减少CPU和磁盘的访问量。同时列式存储是压缩友好的，使用压缩，可以综合CPU和磁盘，发挥最大的效能。对于关系型数 据，如果使用列式存储，我们都很有经验。但是对于嵌套(nested)的结构，Dremel也可以用列存储，非常值得我们学习。
5, Dremel结合了Web搜索 和并行DBMS的技术。首先，他借鉴了Web搜索中的“查询树”的概念，将一个相对巨大复杂的查询，分割成较小较简单的查询。大事化小，小事化了，能并发的在大量节点上跑。其次，和并行DBMS类似，Dremel可以提供了一个SQL-like的接口，就像Hive和Pig那样。
Google Dremel应用场景
设想一个使用场景。我们的美女数据分析师，她有一个新的想法要验证。要验证她的想法，需要在一个上亿条数据上面，跑一个查询，看看结果和她的想法是不是一 样，她可不希望等太长时间，最好几秒钟结果就出来。当然她的想法不一定完善，还需要不断调整语句。然后她验证了想法，发现了数据中的价值。最后，她可以将 这个语句完善成一个长期运行的任务。
对于Google,数据一开始是放在GFS上的。可以通过MapReduce将数据导入到Dremel中去，在这些MapReduce中还可以做一些处理。然后分析师使用Dremel，轻松愉悦的分析数据，建立模型。最后可以编制成一个长期运行的MapReduce任务。
这种处理方式，让笔者联想到Greenplum的Chorus. Chorus也可以为分析师提供快速的数据查询，不过解决方案是通过预处理，导入部分数据，减少数据集的大小。用的是三十六计，走为上计，避开的瞬时分析大数据的难题。Chorus最近即将开源，可以关注下。
还有一点特别的就是按列存储的嵌套数据格式。如图所示，在按记录存储的模式中，一个记录的多列是连续的写在一起的。在按列存储中，可以将数据按列分 开。也就是说，可以仅仅扫描A.B.C而不去读A.E或者A.B.C。难点在于，我们如何能同时高效地扫描若干列，并做一些分析。
Google Dremel数据模型
在Google, 用Protocol Buffer常常作为序列化的方案。其数据模型可以用数学方法严格的表示如下：
其中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需求和扫描最少的列。
Google Dremel查询方式
Dremel可以使用一种SQL-like的语法查询嵌套数据。由于Dremel的数据是只读的，并且会密集的发起多次类似的请求。所以可以保留上次请求的信息，还优化下次请求的explain过程。那又是如何explain的呢？
这是一个树状架构。当Client发其一个请求，根节点受到请求，根据metadata，将其分解到枝叶，直到到位于数据上面的叶子Server。他们扫描处理数据，又不断汇总到根节点。
举个例子：对于请求：
|
1
|
SELECT
A,
COUNT
(B)
FROM
T
GROUP
BY
A
|
根节点收到请求，会根据数据的分区请求，将请求变成可以拆分的样子。原来的请求会变为：
|
1
|
SELECT
A,
SUM
(c)
FROM
(R1
UNION
ALL
... Rn)
GROUP
BY
A
|
R1,…RN是T的分区计算出的结果集。越大的表有越多的分区，越多的分区可以越好的支持并发。
然后再将请求切分，发送到每个分区的叶子Server上面去,对于每个Server
|
1
|
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%的分区，在使用的时候，相当于随机抽样，加快查询。
Google Dremel测试实验
实验的数据源如下表示。大部分数据复制了3次，也有一个两次。每个表会有若干分区，每个分区的大小在100K到800K之间。如果压缩率是25%， 并且计入复制3份的事实的话。T1的大小已经达到PB级别。这么小且巨量的分区，对于GFS的要求很高，现在的Hdfs稳定版恐怕受不了。接下来的测试会 逐步揭示其是如何超过MR，并对性能作出分析。
| 表名 | 记录数 | 大小(已压缩) | 列数 | 数据中心 | 复制数量 |
| T1 | 85 billion | 87 TB | 270 | A | 3× |
| T2 | 24 billion | 13 TB | 530 | A | 3× |
| T3 | 4 billion | 70 TB | 1200 | A | 3× |
| T4 | 1+ trillion | 105 TB | 50 | B | 2× |
| T5 | 1+ trillion | 20 TB | 30 | B | 3× |
列存测试
首先，我们测试看看列存的效果。对于T1表，1GB的数据大约有300K行，使用列存的话压缩后大约在375MB。这台机器磁盘的吞吐在70MB/s左右。这1GB的数据，就是我们的现在的测试数据源，测试环境是单机。
见上图。
· 曲线A，是用列存读取数据并解压的耗时。
· 曲线B是一条一条记录挨个读的时间。
· 曲线C是在B的基础上，加上了反序列化的时间。
· 曲线d，是按行存读并解压的耗时。
· 曲线e加上了反序列化的时间。因为列很多，反序列化耗时超过了读并解压的50%。
从图上可以看出。如果需要读的列很少的话，列存的优势就会特别的明显。对于列的增加，产生的耗时也几乎是线性的。而一条一条该个读和反序列化的开销是很大的，几乎都在原来基础上增加了一倍。而按行读，列数的增加没有影响，因为一次性读了全部列。
Dremel和MapReduce的对比测试
MR和Dremel最大的区别在于行存和列存。如果不能击败MapReduce，Remel就没有意义了。使用最常见的WordCount测试，计算这个数据中Word的个数。
|
1
|
Q1:
SELECT
SUM
(CountWords(txtField)) /
COUNT
(*)
FROM
T1
|
上图是测试的结果。使用了两个MR任务。这两个任务和Dremel一样都运行在3000个节点上面。如果使用列存，Dremel的按列读的MR只需 要读0.5TB的数据，而按行存需要读87TB。 MR提供了一个方便有效的途经来讲按行数据转换成按列的数据。Dremel可以方便的导入MapReduce的处理结果。
树状计算Server测试
接下来我们要对比在T2表示使用两个不同的Group BY查询。T2表有24 billion 行的记录。每个记录有一个 item列表，每一item有一个amount 字段。总共有40 billion个item.amount。这两个Query分别是。
|
1
2
3
|
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的聚合。如
|
1
2
3
4
5
6
7
|
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有良好的扩展性，可以通过增加机器来缩短查询的时间。并且可以处理数以万亿计的记录。
对于查询：
|
1
|
Q5:
SELECT
TOP
(aid, 20),
COUNT
(*)
FROM
T4
WHERE
bid = fvalue1g
AND
cid = fvalue2g
|
使用不同的叶子Server数目来进行测试。
可以发现CPU的耗时总数是基本不变的，在30万秒左右。但是随着节点数的增加，执行时间也会相应缩短。几乎呈线性递减。如果我们使用通过CPU时间计费的“云计算”机器，每个租户的查询都可以很快，成本也会非常低廉。
容错测试
一个大团队里面，总有几个拖油瓶。对于有万亿条记录的T5，我们执行下面的语句。
|
1
|
Q6:
SELECT
COUNT
(
DISTINCT
a)
FROM
T5
|
值得注意的是T5的数据只有两份拷贝，所以有更高的概率出现坏节点和拖油瓶。这个查询需要扫描大约1TB的压缩数据，使用2500个节点。
可以看到99%的分区都在5S内完成的。不幸的是，有一些分区需要较长的时间来处理。尽管通过动态调度可以加快一些，但在如此大规模的计算上面，很难完全不出问题。如果不在意太精确的结果，完全可以小小减少覆盖的比例，大大提升相应速度。
Google Dremel 的影响
Google Dremel的能在如此短的时间内处理这么大的数据，的确是十分惊艳的。有个伯克利分校的教授Armando Fox说过一句话“如果你曾事先告诉我Dremel声称其将可做些什么，那么我不会相信你能开发出这种工具”。这么给力的技术，必然对业界造成巨大的影 响。第一个被波及到的必然是Hadoop。
Dremel与Hadoop
Dremel的公开论文里面已经说的很明白，Dremel不是用来替代MapReduce，而是和其更好的结合。Hadoop的Hive，Pig无 法提供及时的查询，而Dremel的快速查询技术可以给Hadoop提供有力的补充。同时Dremel可以用来分析MapReduce的结果集，只需要将 MapReduce的OutputFormat修改为Dremel的格式，就可以几乎不引入额外开销，将数据导入Dremel。使用Dremel来开发数 据分析模型，MapReduce来执行数据分析模型。
Hadoop的Hive,Pig现在也有了列存的模式，架构上和Dremel也接近。但是无论存储结构还是计算方式都没有Dremel精致。对 Hadoop实时性的改进也一直是个热点话题。要想在Hadoop中山寨一个Dremel，并且相对现有解决方案有突破，笔者觉得Hadoop自身需要一 些改进。一个是HDFS需要对并发细碎的数据读性能有大的改进，HDFS需要更加的低延迟。再者是Hadoop需要不仅仅支持MapReduce这一种计 算框架。其他部分,Hadoop都有对应的开源组件，万事俱备只欠东风。
Dremel的开源实现
Dremel现在还没有一个可以运行的开源实现，不过我们看到很多努力。一个是Apache的Drill，一个是OpenDremel/Dazo。
OpenDremel/Dazo
OpenDremel是一个开源项目，最近改名为Dazo。可以在GoogleCode上找到http://code.google.com/p/dremel/。目前还没有发布。作者声称他已经完成了一个通用执行引擎和OpenStack Swift的集成。笔者感觉其越走越歪，离Dremel越来越远了。
Apache Drill
Drill 是 Hadoop的赞助商之一MapR发起的。Drill作为一个Dremel的山寨项目，有和Dremel相似的架构和能力。他们希望Drill最终会想 Hive,Pig一样成为Hadoop上的重要组成部分。为Hadoop提供快速查询的能力。和Dremel有一点不同，在数据模型上，开源的项目需要支 持更标准的数据结构。比如CSV和JSON。同时Drill还有更大的灵活性，支持多重查询语言，多种接口。
现在Drill的目标是完成初始的需求，架构。完成一个初始的实现。这个实现包括一个执行引擎和DrQL。DrQL是一个基于列的格式，类似于Dremel。目前，Drill已经完成的需求和架构设计。总共分为了四个组件
· Query language:类似Google BigQuery的查询语言，支持嵌套模型，名为DrQL.
· Low-lantency distribute execution engine:执行引擎，可以支持大规模扩展和容错。可以运行在上万台机器上计算数以PB的数据。
· Nested data format:嵌套数据模型，和Dremel类似。也支持CSV,JSON,YAML类似的模型。这样执行引擎就可以支持更多的数据类型。
· Scalable data source: 支持多种数据源，现阶段以Hadoop为数据源。
目前这四个组件在分别积极的推进，Drill也非常希望有社区其他公司来加入。Drill希望加入到Hadoop生态系统中去。
最后的话
本文介绍了Google Dremel的使用场景，设计实现，测试实验，和对开源世界的影响。相信不久的将来，Dremel的技术会得到广泛的应用。