首先简单介绍一下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就是这样的: