Dremel导读

参考译文：

http://www.importnew.com/2617.html

importnew的很多译文真的很赞！赞 @疯狂编码中的xiaoY

虽然有超赞的译文，但还是认为某些章节最好看下原文。为了便于回顾，我这里也按自己的思路再整理下。

 

需求背景：

解决海量数据的交互性ad-hoc查询。 Dremel不是为了成为MR的替代品，而是经常与它协同使用来分析MR管道的输出或者创建大规模计算的原型系统。所谓交互式查询，最常见的是进行一些类似count等聚合操作，或再做一些类似top-K的排序，通常返回的结果量较小或适中，对需要返回大规模数据集的操作，宜使用MR直接在GFS或Bigtable上进行处理。从某种意义上，dremel是bigtable的一种替代系统（或互补系统）。

 

核心思想：

1. 借鉴分布式搜索引擎中的服务树概念， 通过聚合从下层树节点中收到的回复，不断装配查询的最终结果。

2. 使用了column-striped的存储结构，让 嵌套数据的更容易获取（更容易指的是当只需要局部数据信息时能直捣黄龙，无需整个record通读）。

 

数据模型（任何数据存储系统的核心部分）：

1.嵌套数据模型并不陌生，因为google protobuf是大家耳熟能详的玩意，核心问题是如何对pb描述的嵌套结构进行列式存储（也即树状结构扁平化的问题）

2.扁平化的实现：使用a.b.c的全路径表达一个字段名，然后 扁平化存储 叶子节点； 无损的用列存储的方式存储嵌套结构，解决option字段空和重复字段的自解释

3.重复深度：标记数据在那一层重复，这个比较好理解，通过重复深度可以重新构造重复字段的树形组合关系；record根的深度为0，如果重复深度为0，意味着切换record；重复深度不考虑路径中的required和optional字段

4.定义深度：如果一个字段为NULL，我们需要知道具体是哪个层级缺失，定义深度可推断该字段是在哪个层级缺失。 举例，如果某个重复字段包含在一个optional字段中，当record不包含任意该字段时，会存储一个重复深度为0的NULL，此时无法判断是因为其optional父子段为空导致还是该字段repeat数为0导致，但有了定义深度，为0则可判断是其父子段缺失，为1则可判断是repeat数为0

5.encoding时的优化：NULL值无需显式存储，因为如果定义深度小于路径中optional和repeat字段的数量，即可认为NULL；深度值如果能够被推导就可免存，而且使用变长的bits进行存储

 

有了数据模型，剩下的一个工作就是构建分割器和组装器来把pb数据分割成以上column-stripe结构以及读取时把各列重新组装成pb（清楚数据结构后，这个完全属于程序设计的问题，大家慢慢写应该都能写得出来，不赘述）。

 

查询语言也不赘述（类SQL语言）。支持嵌套查询、inter和intra-record聚合、top-k、join、UDF。

查询过程：

1.类似于Bigtable，数据也水平分成数量很大的tablets，一台机器可以hold多个tablets，同时执行几个slot线程（每个slot线程处理若干tablets）

2.查询类似于搜索引擎的检索系统，采取层层汇聚的结构，某一个查询，最终被query dispatcher分解为tablet级别的任务，然后分配到slot执行（读取并聚合若干个stripe的内容）。典型的并行分治思想。

3.如bigtable中的tablet，dremel中的tablet也根据其访问快慢而迁移到负载低的server、实现负载调整。

4.对一些统计量，其实并不需要严格的统计值，所以可以配置参数指定多少比例的tablets处理完即可返回（因为可以剔除长尾因素，可大大提高查询速度）

5.对一些count或top-K可以使用一些基于统计的sketch算法计算近似值

 

关于性能：

1.根据Google的测试，单机试验时，当读取的field较少时，列存储可以比行存储快一个数量级，当达到几十个field时性能相近，再往后就是行存储会优于列存储（因为不需要读很多文件）。列存储由更好的压缩比，从磁盘空间和IO上更省。

2.因为google的数据由成千上万个字段组成稀疏表，所以使用列存储在获取少量字段时由不可比拟的优势，即使同样使用MR，使用行存储和使用列存储都在执行时间上都可以差几个数量级（根本原因是从磁盘上读取的数据量差几个数量级）。

3.同样基于列存储，MR与dremel的差别在，dremal更像是一个service，不需要每次都调度MR作业，所以它可以再快一个数量级。

4.查询服务树对查询性能也有影响，通常多层结构可以提供更快的查询速度（层层聚合的方式可以提高并发度），但是层级数多少为宜要看具体的数据规模以及叶子服务节点的数量。

5.dremel的可伸缩性很好，当系统规模扩展时，内耗比例并没有增加，基本上处理能力可以正比于节点规模。

6.如果只需达到一定精度，速度提升会很多，最后那一点点的percent的数据往往无法再很tight的时间内获得。

转载于:https://www.cnblogs.com/fernnix/p/3541508.html