首先简单介绍一下Dremel是什么，能解决什么问题。第二部分着重讲Dremel的数据模型，即数据结构。第三部分将谈一下在此数据结构上设计的算法。
Dremel的数据模型起源于分布式系统的应用环境(Protocol Buffers，一种在Google内广泛使用，现已开源的实现)。其数据模型是基于强类型的嵌套记录，抽象语法可以表示成下面公式：
一个例子：
首先来看一下Dremel的数据模型是如何在列式存储下无损的表示出记录的结构的(lossless representation of record structure in a columnar format)。如果仅仅是数值(values)的话，数值本身无法传递出记录(record)的结构信息。我们不知道两个数值是属于两条不同的记录还是在一条记录下，同时我们也不知道一些可选的字段(field)是否显式定义。因此，我们引入了两个概念：Repetition Level和Definition Level。
为了说清楚Dremel模型是如何无损地表示数据的，我想到了两种画法。最终还是决定采用第一种画法，类似有向图，感觉与后面的FSM状态机能更好的对应上。
Dremel论文中对repetition level的定义听起来比较抽象：at what repeated field in the field‘s path the value has repeated。意思就是在路径上，在哪个repeated字段上重复了。还是看个例子解释一下吧，以之前的图例中的文档r1中的Code字段为例。
上图清晰地表示出三个Code字段与文档中字段的对应关系。下面来看一下这三个Code的repetition level(简写为r) 0，2，1是如何计算出来的。下图忽略无关的字段，将三个Code字段的完整路径都表示出来。那么就可以简单易懂地看出，r就是这些字段路径上，发生重复了的字段的level。请参考下图中的注释就能很快理解。
大家可能还注意到Name.Code表中除了en-us、en和en-gb三行外，还有两行NULL。第二个NULL是描述文档r2的，我们就分析一下第一个NULL的含义吧。因为文档r1的第二个Name字段下没有Code，而为了说明en-gb是属于第三个Name字段下的，所以在en和en-gb之间加了一行NULL，其r也等于1(Name重复)。同时，由于Code在定义中是required的字段，所以事实上这一行NULL也暗示了：在第二个Name字段下Language也是不存在的。不然Language存在而下面却没有Name，这是不符合文档定义的。
以此类推，其他字段的r值都是这样计算出来的。同时注意一点：我们只保存了有值的字段，如DocId、Name.Url、Name.Language.Code等，而像Links、Name.Language等字段是没必要保存的。
definition level(简写为d)在论文中的定义还比较清楚：Each value of a field with path p , esp. every NULL, has a definition level specifying how many fields in p that could be undefined (because they are optional or repeated) are actually present. 尤其对于NULL来说，路径p上有多少字段可以是不存在(例如在文档定义中是optional或repeated，而不是required)，然而实际却存在的。例如文档r1的Links下没有Backward字段，然而Links字段却存在(因为Links下有Forward)，所以我们在Links.Backward表中保存一条NULL，并且d=1。对于非NULL字段来说，意义不大，因为d的值对于每种字段来说都是相同的，例如Code都是2，Country都是3。
值得注意的几点是：
? 在路径上计算多少字段本可以不存在时，包含了当前字段本身。例如计算Country:us时，Country本身也是optional，也计入总数，所以d=3。
? 每种字段只计算1次。例如最下面的Country:gb，在其路径上的3个Name都满足条件，但只计1次，所以d=3，而不是5。(前面提过，也许是我这第一种画法的缘故，需要这一条规则来限定)
前面介绍了数据的保存方法，实际上真正保存时，数据还会被进一步压缩。
? 不显式保存NULL，因为它可以通过d来确定：d < 路径上repeated和optional字段总数，就说明是NULL。可以通过前面的例子印证一下。
? 总是会被定义的字段的d不会被保存。
? r也是仅在必要时才会保存。例如d=0暗示r=0，所以r可以省略不存。
? 像DocId这种所有level都是0的，实际上不会保存任何level信息。
? 尽可能使用位图。例如假如d最大是3，那么我们只使用2个bit来保存。
略，详见论文附录部分的伪代码。
高效地从列式存储数据中组装出记录，对像MapReduce这种面向记录的数据处理工具来说非常重要。我们的目标是：给定字段的子集，我们能重新构建出仅包含选中字段的原始记录，而过滤掉其他字段。核心思想是：使用有限状态机(finite state machine, FSM)读取每个字段的值和level，顺序地追加到输出流中。FSM为每种字段都关联一个field reader。状态转变通过repetition level来标记。一旦reader抓取到值，我们继续看下一repetition level来决定使用哪个reader。FSM就这样从开始状态到结束状态遍历完每条记录。
下面还是用前面的例子，通过DocId和Name.Language.Country这两个字段的重建，来详细解析一下FSM的工作过程。关键步骤用红色加粗标记。
1. FSM委托Reader1读取DocId第一行，通过r=0重建记录。
2. 检查DocId第二行，发现r=0，则Reader1停在当前“游标”位置。FSM将状态变化到Name.Language.Country。
3. FSM委托Reader2读取Name.Language.Country第一行，通过r=0重建记录。
4. FSM委托Reader2读取Name.Language.Country第二行。通过r=2(说明Language字段重复，即Language有多个)重建记录。
5. FSM委托Reader2读取Name.Language.Country第三行。通过r=1和d=1(说明只有Name字段不是NULL)重建记录。
6. 略过第四行。
7. 检查到第五行，发现r=0，Reader2停在当前位置。FSM再次发生状态变化，继续重建文档2的记录。
8. FSM委托Reader1继续读取DocId第二行(之前Reader1就停在这里了)。
9. 到这里应该已经很清楚了，最后过程就略说了：DocId中没有数据了，FSM状态变化，Reader2继续读取Country的最后一行数据，重建出记录。
注：论文原图中少了第二个Name字段，我觉得应该加上吧。在第五步被重新构建出来。为什么在原图中没有呢？
前面例子的完整FSM就是这样的：
待补充。
待补充。
原文：http://blog.csdn.net/dc_726/article/details/41627613
