论文阅读笔记- Dremel
作者：刘旭晖 Raymond 转载请注明出处
Email：colorant at 163.com
BLOG：http://blog.csdn.net/colorant/
更多论文阅读笔记 http://blog.csdn.net/colorant/article/details/8256145
阅读笔记 - Dremel: Interactive Analysis ofWebScaleDatasets
关键字
列存储
==目标问题 ==
在大规模的稀疏型结构化数据上的快速交互式Ad-hoc查询
==核心思想 ==
首先Dremel面向用户提供了一个类SQL语法的查询语言，但更重要的是它对嵌套式的结构化数据的处理方式
- 使用特定结构的Column Base的存储方案，用一个三元组表示一个数据单元，这个三元组包含了这个数据单元的值，以及它在嵌套的数据结构中的层级和重复级别。结合与数据表关联的Schema定义，可以高效的表达出该数据单元在整个数据结构中的实际存储情况，具体细节请参考论文相关章节。
- 在这种存储方案下，结合巧妙的算法strip部分空数据，在数据稀疏的情况下
- 能对数据采用更简单的压缩算法
- 能减少实际存储的数据量
- 针对Column结构优化的检索，在无需重构数据的前提下能够实现快速检索
- 在只检索部分域的情况下，因为按需读取（同时巧妙的算法又能构建比全表扫描更简单的扫描流程），能大量减少所需读取的数据。
再有就是集群节点的工作模型
- Serving Tree分层处理模型
- 每个leaf节点只处理少量的数据，结果分层汇总到上级节点，较少的层级拓扑对于通常的大量输入/中少量输出的检索能有效处理，较多的层级拓扑则有利于处理大量输出的情况。
总体上，个人理解 Dremel能在特定场合比Row base的MapReduce模式的应用快的原因，根本上来至于数据IO量的减少，辅助以大量叶结点的分层汇总结构来最大化并发处理数据。
==实现 ==
Query Plan的执行不转换成Map-Reduce任务，而是由Serving Tree模型自己处理。
在实现中，除了巧妙的算法实现Record和列式存储模型的快速转换外，还有各种优化，比如定义允许部分结果返回时就提前结束查询的Sample方式，牺牲适当的精度来换取速度等等
适用的场合应该是针对稀疏数据，对部分数据域进行ad-hoc类分析的场合
==数据 ==
Paper测试的典型数据在20-100T之间，一行（也就是一个Record）包含的域在30-1200个左右，当所需查询处理域在个位数的时候，提升的速度在3-10倍之间，基本上相当于所需读取数据量的比值除2的样子（比如相比完整的Row存储结构，读1/10的域，所花时间是1/5）
当所需处理的域增加到一定程度后，Row base的MR应用的速度则会反超（按Paper的说法，取决于具体的表的结构和稀疏程度，通常在几十个—ozens of）域（field）的情况下，速度对比会翻转）
==相关研究，项目等 ==
Apache Drill :http://incubator.apache.org/drill/ Dremel的开源实现版本，看起来还仅仅处于起步阶段，计划了很多功能，但是实现的并不多,目前大概核心的代码大概只有 2K行左右的JAVA code
Open Dremel :合并到Drill项目了
- 每个leaf节点只处理少量的数据，结果分层汇总到上级节点，较少的层级拓扑对于通常的大量输入/中少量输出的检索能有效处理，较多的层级拓扑则有利于处理大量输出的情况。
- Serving Tree分层处理模型
- 在这种存储方案下，结合巧妙的算法strip部分空数据，在数据稀疏的情况下