云计算及应用课件：分布式结构化数据表Bigtable

分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化设计动机与目标需要存储的数据种类繁多：Google目前向公众开放的服务很多，需要处理的数据类型也非常多。包括URL、网页内容、用户的个性化设置在内的数据都是Google需要经常处理的海量的服务请求：Google运行着目前世界上最繁忙的系统，它每时每刻处理的客户服务请求数量是普通的系统根本无法承受的商用数据库无法满足Google的需求：一方面现有商用数据库设计着眼点在于通用性，根本无法满足Google的苛刻服务要求；另一方面对于底层系统的完全掌控会给后期的系统维护、升级带来极大的便利设计动机设计动机与目标基本目标高可用性

Bigtable设计的重要目标之一就是确保几乎所有的情况下系统都可用

广泛的适用性

Bigtable是为了满足系列Google产品而非特定产品存储要求

简单性

底层系统简单性既可减少系统出错概率，也为上层应用开发带来便利

很强的可扩展性

根据需要随时可以加入或撤销服务器

分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化数据模型

Bigtable是一个分布式多维映射表，表中的数据通过一个行关键字（RowKey）、一个列关键字（ColumnKey）以及一个时间戳（TimeStamp）进行索引

Bigtable对存储在其中的数据不做任何解析，一律看做字符串

Bigtable的存储逻辑可以表示为：

(row:string,column:string,time:int64)→stringBigtable数据模型数据模型行

Bigtable的行关键字可以是任意的字符串，但是大小不能超过64KB。Bigtable和传统的关系型数据库有很大不同，它不支持一般意义上的事务，但能保证对于行的读写操作具有原子性（Atomic）

表中数据都是根据行关键字进行排序的，排序使用的是词典序。

一个典型实例，其中n.www就是一个行关键字。不直接存储网页地址而将其倒排是Bigtable的一个巧妙设计。这样做至少会带来以下两个好处

同一地址域的网页会被存储在表中的连续位置，有利于用户查找和分析

倒排便于数据压缩，可以大幅提高压缩率

数据模型列

Bigtable并不是简单地存储所有的列关键字，而是将其组织成所谓的列族（ColumnFamily），每个族中的数据都属于同一个类型，并且同族的数据会被压缩在一起保存。引入了列族的概念之后，列关键字就采用下述的语法规则来定义：

族名：限定词（family：qualifier）

族名必须有意义，限定词则可以任意选定

图中，内容（Contents）、锚点（Anchor）都是不同的族。而和my.look.ca则是锚点族中不同的限定词

族同时也是Bigtable中访问控制（AccessControl）基本单元，也就是说访问权限的设置是在族这一级别上进行的数据模型时间戳

Google的很多服务比如网页检索和用户的个性化设置等都需要保存不同时间的数据，这些不同的数据版本必须通过时间戳来区分。图2中内容列的t3、t5和t6表明其中保存了在t3、t5和t6这三个时间获取的网页。Bigtable中的时间戳是64位整型数，具体的赋值方式可以采取系统默认的方式，也可以用户自行定义

为了简化不同版本的数据管理，Bigtable目前提供了两种设置：一种是保留最近的N个不同版本，图中数据模型采取的就是这种方法，它保存最新的三个版本数据。另一种就是保留限定时间内的所有不同版本，比如可以保存最近10天的所有不同版本数据。失效的版本将会由Bigtable的垃圾回收机制自动处理

分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化系统架构

一个分布式的任务调度器，主要被用来处理分布式系统队列分组和任务调度

系统架构

在Bigtable中Chubby主要有以下几个作用：（1）选取并保证同一时间内只有一个主服务器（MasterServer）（2）获取子表的位置信息（3）保存Bigtable的模式信息及访问控制列表

另外在Bigtable的实际执行过程中，Google的MapReduce和Sawzall也被用来改善其性能系统架构

Bigtable主要由三个部分组成：客户端程序库（ClientLibrary）、一个主服务器（MasterServer）和多个子表服务器（TabletServer）

客户访问Bigtable服务时，首先要利用其库函数执行Open()操作来打开一个锁（实际上就是获取了文件目录），锁打开以后客户端就可以和子表服务器进行通信

和许多具有单个主节点分布式系统一样，客户端主要与子表服务器通信，几乎不和主服务器进行通信，这使得主服务器的负载大大降低

主服务主要进行一些元数据操作以及子表服务器之间负载调度问题，实际数据是存储在子表服务器上

分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化主服务器

当一个新子表产生时，主服务器通过一个加载命令将其分配给一个空间足够的子表服务器。创建新表、表合并以及较大子表的分裂都会产生一个或多个新子表。对于前面两种，主服务器会自动检测到，而较大子表的分裂是由子服务发起并完成的，所以主服务器并不能自动检测到，因此在分割完成之后子服务器需要向主服务发出一个通知

由于系统设计之初就要求能达到良好的扩展性，所以主服务器必须对子表服务器的状态进行监控，以便及时检测到服务器的加入或撤销

Bigtable中主服务器对子表服务器的监控是通过Chubby完成的——子表服务器在初始化时都会从Chubby中得到一个独占锁。通过这种方式所有子表服务器基本信息被保存在Chubby中一个称为服务器目录（ServerDirectory）的特殊目录之中主服务器

主服务器会定期向其询问独占锁的状态。如果子表服务器的锁丢失或没有回应，则此时可能有两种情况

要么是Chubby出现了问题（虽然这种概率很小，但的确存在，Google自己也做过相关测试）

要么是子表服务器自身出现了问题。对此主服务器首先自己尝试获取这个独占锁，如果失败说明Chubby服务出现问题，需等待恢复；如果成功则说明Chubby服务良好而子表服务器本身出现了问题

当在状态监测时发现某个子表服务器上负载过重时，主服务器会自动对其进行负载均衡操作

主服务器

基于系统出现故障是一种常态的设计理念，每个主服务器被设定了一个会话时间的限制。当某个主服务器到时退出后，管理系统就会指定一个新的主服务器，这个主服务器的启动需要经历以下四个步骤：

（1）从Chubby中获取一个独占锁，确保同一时间只有一个主服务器（2）扫描服务器目录，发现目前活跃的子表服务器（3）与所有的活跃子表服务器取得联系以便了解所有子表的分配情况（4）扫描元数据表，发现未分配的子表并将其分配到合适子表服务器如果元数据表未分配，则首先需要将根子表（RootTablet）加入未分配的子表中。由于根子表保存了其他所有元数据子表的信息，确保了扫描能够发现所有未分配的子表分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化SSTable及子表基本结构

SSTable是Google为Bigtable设计的内部数据存储格式。所有的SSTable文件都存储在GFS上

SSTable中数据被划分成一个个的块（Block），每个块的大小是可以设置的，一般为64KB

在SSTable的结尾有一个索引（Index），这个索引保存了块的位置信息，在SSTable打开时这个索引会被加载进内存，用户在查找某个块时首先在内存中查找块的位置信息，然后在硬盘上直接找到这个块

由于每个SSTable一般都不是很大，用户还可以选择将其整体加载进内存，这样查找起来会更快

SSTable结构

子表实际组成

每个子表都是由多个SSTable以及日志（Log）文件构成

不同子表的SSTable可以共享Bigtable中的日志文件是一种共享日志，每个子表服务器上仅保存一个日志文件，某个子表日志只是这个共享日志的一个片段。这样会节省大量的空间，但在恢复时却有一定的难度Google为了避免这种情况出现，对日志做了一些改进。Bigtable规定将日志的内容按照键值进行排序，这样不同的子表服务器都可以连续读取日志文件了

一般来说每个子表的大小在100MB到200MB之间。每个子表服务器上保存的子表数量可以从几十到上千不等，通常情况下是100个左右

子表地址结构

子表地址的查询是经常碰到的操作。在Bigtable系统的内部采用的是一种类似B+树的三层查询体系

所有子表地址都被记录在元数据表中，元数据表也是由一个个的元数据子表（Metadatatablet）组成

根子表是元数据表中一个比较特殊的子表，它既是元数据表的第一条记录，也包含了其他元数据子表的地址，同时Chubby中的一个文件也存储了这个根子表的信息。

查询时，首先从Chubby中提取这个根子表的地址，进而读取所需的元数据子表的位置，最后就可以从元数据子表中找到待查询的子表。除了这些子表的元数据之外，元数据表中还保存了其他一些有利于调试和分析的信息，比如事件日志等

为了减少访问开销，提高客户访问效率，Bigtable使用了缓存（Cache）和预取（Prefetch）技术

子表的地址信息被缓存在客户端，客户在寻址时直接根据缓存信息进行查找。一旦出现缓存为空或缓存信息过时的情况，客户端就需要按照图示方式进行网络的来回通信（NetworkRound-trips）进行寻址，在缓存为空的情况下需要三个网络来回通信。如果缓存的信息是过时的，则需要六个网络来回通信。其中三个用来确定信息是过时的，另外三个获取新的地址

预取则是在每次访问元数据表时不仅仅读取所需的子表元数据，而是读取多个子表的元数据，这样下次需要时就不用再次访问元数据表

子表数据存储及读/写操作

Bigtable数据存储及读/写操作

Bigtable将数据存储划分成两块：较新的数据存储在内存中一个称为内存表（Memtable）的有序缓冲里，较早的数据则以SSTable格式保存在GFS中

写操作（WriteOp）——先查询Chubby中保存的访问控制列表确定用户具相应写权限，通过认证之后写入的数据首先被保存在提交日志（CommitLog）中。提交日志中以重做记录（RedoRecord）的形式保存着最近的一系列数据更改，这些重做记录在子表进行恢复时可以向系统提供已完成的更改信息。

读操作（ReadOp）——先通过认证，之后读操作就要结合内存表和SSTable文件来进行，因为内存表和SSTable中都保存了数据

三种形式压缩之间的关系

Bigtable中有三种形式的数据压缩：

次压缩（MinorCompaction）

合并压缩（MergingCompaction）

主压缩（MajorCompaction）数据压缩问题每一次旧的内存表停止使用时都会进行一个次压缩操作，这会产生一个SSTable。但如果系统中只有这种压缩的话，SSTable的数量就会无限制地增加下去而在Bigtable中，读操作实际上比写操作更重要，因此Bigtable会定期地执行一次合并压缩的操作，将一些已有的SSTable和现有的内存表一并进行一次压缩主压缩其实是合并压缩的一种，只不过它将所有的SSTable一次性压缩成一个大的SSTable文件。主压缩也是定期执行，执行一次主压缩之后可以保证将所有的被压缩数据彻底删除分布式结构化数据表Bigtable

设计动机与目标

数据模型

系统架构

主服务器

子表服务器

性能优化局部性群组（Localitygroups）

局部性群组(LocalityGroup)

根据需要，将原本不存储在一起的数据，以列族为单位存储至单独的子表

有的用户可能只对网页内容感兴趣，那么它可以通过设置局部性群组（见下图）只看内容这一列；有的对诸如网页语言、网站排名等可以用于分析的信息比较感兴趣，他也可以将这些列设置到一个群组中

压缩

压缩

压缩可以有效地节省空间，Bigtable中的压缩被应用于很多场合

首先压缩可以被用在构成局部性群组的SSTable中，可以选择是否对个人的局部性群组的SSTable进行压缩。这种压缩是对每个局部性群组独立进行，虽然会浪费一些空间，但是在需要读时解压速度非常快

通常情况下，用户可