GOOGLE分布式数据库技术演进研究--从Bigtable、Dremel到Spanner（二）

首先申明，里面对技术背景和后续技术发展方向的内容，来自于个人技术上的思考和判断，并非引经据典，仅供参考。

3  Dremel

3.1背景

大规模交互性数据分析处理在整个行业中应用越来越广泛，对于交互型分析对于数据处理的响应时间要求比较高，而原有Bigtable数据库设计上并没有考虑对于交互式场景要求，对于大大规模交互数据分析处理响应性不够，因此Dremel就应运而生，Dremel解决大规模交互数据分析的实时性问题，可以做到秒级的数据响应，GOOGLE在测试中宣称，可以在3秒钟的时间处理1PB数据。

在大规模交互数据分析中，会有这样一种场景，需要参加数据分析的原始数据量非常大，但是最终结果集数据量会很小，往往是一个分析结果或者是汇总型的数据，这种场景就是大型交互时数据分析的典型场景。从GOOGLE分布式数据库产品的战略定位看，Dremel和Bigtable的定位有所不同，Dremel更适合对于交互式场景，而Bigtable通常会跟MapReduce配置，做为大数据处理搭配处理，当然Dremel同样可以与MAPReduce结合使用。因此Dremel并不是取代Bigtable的一种分布式数据库，而是一种补充，从技术演进角度看，由于Dremel数据库公开时间晚于Bigtable，因此做为Google第二代分布式数据库代表之一。

3.2Dremel的数据模型

3.2.1Dremel嵌套列数据模型

Dremel采用是嵌套列数据模型，该数据模型把嵌套数据拆分为列结构加以存储，在查询时把数据重建为嵌套数据，原有列存储数据库通常属于关系型数据库，在嵌套类型的数据处理还未采用这种结构，GOOGLE创造性的把嵌套数据处理为列数据库，并且技术指标还能大幅提升，满足大型数据的交互式查询要求，不得不说这个GOOGLE的一个新创造，但为什么是这样的列嵌套结构，而不是其他数据结构，这点GOOGLE并没有进行介绍说明，因此这一点理解上面有一定困难，不过在后续介绍中，会发现这种结构在数据查询处理时的优势和特点。

一提起数学模型，很多程序员就会晕，不过仔细看看，稍微有一点数据知识的人，应该就能够看明白，Dremel的数学模型如下：

π = dom | <A1 : π[*|?],…,An :π[*|?]>

π是数据库中的一条记录类型，Ai是数据库记录的一个字段，*为一个重复字段，?为可选字段，这个数据模型说明该一条记录是由多个字段构成，字段类型由可选字段、必选字段、重复字段组成，可选字段可以出现，也可以不出现；必选字段必须会出现，重复字段则会出现多次。在GOOGLE公开的资料中，在图3-1给出嵌套记录样例和数据模式定义，Document是一个网页类型的数据模式，该网页有整形的DocId和可选的Link分组属性，Link分组属性包含了多个Backword和Forward可

图3-1  嵌套式记录样例和数据模式定义

重复的整型属性构成列表，一个网页包括了多个可以重复的名字分组，每个名字分组，可以包括多个语言分组和可选的URL地址，语言分组包括必选的CODE字段，可选的Country属性。整个Document嵌套层次关系如图3-2：

图3-2 嵌套层次关系图

3.2.2Dremel的重复深度和定义深度

在Dremel中如何对于嵌套式数据结构，在列存储后进行重建，依赖于二个重要参数，一个是RepetitionLevel重复深度，一个是Definition Level定义深度.重复深度和定义深度仅针对重复字段来计算层次，用于描述这个值什么重复字段的此值重复了，以此确定重复的位置；定义深度描述多个嵌套层次的路径上，有多少个字段是有值的，通过这二个参数可以完成嵌套数据的列式化存储。

3.2.3Dremel的存储和重构

Dremel存储是采用列式模型，按照列进行嵌套式数据的存储，读取数据时，根据定义在列式模型中的数据，按照顺序，把列式存储数据还原到原有的嵌套式数据结构。

3.3Dremel的系统架构和查询

Dremel采用的是多层次服务树架构，最上层Dremel的根服务器，根服务器接收所有的查询请求，读取数据库相关的元数据，并把相关请求下发到下一级查询服务器查询。中间层查询服务器负责根服务器请求的派发和叶子服务器的查询结果的处理。叶子服务器与具体存储层直接通讯，完成存储系统上相关数据的读取和查询动作，整个系统架构图如下图所示。

图3-3 Dremel多层次查询树架构

Dremel查询语句基于SQL语法，并根据自身列存储模型进行了定制，构成在Dremel的存储结构上面高效的执行，对于Dremel查询树结构，会对于根查询服务器收到查询请求进行层层拆分，最终传递到叶节点的查询服务器，叶节点查询服务器获取的数据结果后，进行过滤和汇总这样的计算，然后在上传到上级查询服务器，层层汇总结果后，最终返回结果数据。

Dremel支持多客户端并发查询，通常情况下查询请求会被同时运行，查询派发器，会根据系统的负载情况和查询优先级进行一定的查询调度操作，并提供容错性，对于查询节点响应缓慢和访问数据不达的情况进行调整。

3.4应用场景和关键技术

3.4.1应用场景

Dremel定位为交互系统大型数据处理的数据库系统，适合数据读取数据量大，但是返回数据量小的场景，对于返回数据量大的场景，采用Dremel就不太合适。

3.4.2关键技术

Dremel采用的嵌套式列存储结构+多层次查询查询树，大型数据处理快速响应的关键，列存储结构可以只对查询关心的列数据读取，多层次查询树结构对于数据查询的拆分和聚合的方式有效的匹配，这是Dremel在该场景速度快于Bigtable的关键技术；

Dremel号称可以在秒级进行1PB级的数据运行，没有看到公开的验证数据，该这种1PB级的数据，从个人推断应该是所有列存储数据占用空间的总大小，而不是仅仅该字段占用空间的大小。

Dremel结构解决了传统的多表数据通过外键关联效率缓慢的问题，通过存储列数据的顺序结构解决了多表数据的关联问题，思路非常巧妙。

3.4.2技术展望

Dremel对于标准的SQL语法是不支持的，为了满足高效率查询，设计了与自身结构相匹配的查询语句，因此Dremel对于数据库一些通用SQL查询支持是不够的，更像是一种处理交互式数据查询的分支数据库，与通常意义上面讲的BIGTABLE数据库使用场景有很大的区别，因此应该属于分布式数据库发展的分支技术方向，而不是主流发展方向。

后续Dremel是否能够对于嵌套式数据库模型进一步的优化，提供部分SQL标准接口，这些都是Dremel后续可能的发展方向。

--剩下的第三个部分是spanner和整个对比总结，任务很重，要完成有点悬。

本文出自 “南方的熊熊” 博客，请务必保留此出处http://802796.blog.51cto.com/8476804/1355155