撸论文系列之——Bigtable

特征：分布式，结构化，海量数据，PB级集群

使用案例：web索引、Google Earth、Google Finance等

优势：适用性广、可扩展、灵活、高性能和高可用

目的：可靠处理PB级数据，分布式部署

劣势：不支持完整关系数据模型

数据模型：

定义——Bigtable是一个稀疏的、分布式的、持久化存储的多维度排序Map。Map的索引是行关键字、列关键字以及时间戳；Map中的每个value都是一个未经解析的byte数组。

行

最大支持64KB，读写操作均是原子操作。字典顺序组织数据，分区Tablet使得读取少量列时效率很高。访问充分利用位置相关性相同域连续存储。

列族

同一列族可压缩，先创建再使用，列族最多几百个，列可以无限多个。命名语法：列族:限定词。可进行访问控制、磁盘内存统计的管理。

时间戳

64位整型，可以Bigtable生成也可用户程序生成。数据按时间戳倒序排序。根据设置的参数对废弃版本进行自动GC。

API

写：

// Open the tableTable *T = OpenOrDie(“/bigtable/web/webtable”);// Write a new anchoranddelete an old anchor RowMutationr1(T, “com.cnn.www”);

r1.Set(“anchor:www.c-span.org”, “CNN”);

r1.Delete(“anchor:www.abc.com”);Operation op;Apply(&op, &r1);

读：

可跨行批量写入，不支持跨行事务处理。可以同MapReduce一起使用（下一篇文章将主要介绍MR）

BigTable构件

使用GFS存储日志和数据文件（GFS相关介绍可以参见我的上一篇文章），内部存储文件格式Google SSTable（一个持久化、排序、不可更改的Map）格式，SSTablee使用块索引定位数据块，索引存储在内存中，查询复杂度O(1)。使用分布式锁Chubby（Zookeeper的鼻祖）。Chubby使用Paxos算法保证副本一致性。目录或文件为一个锁，读写原子。客户端和Chubby使用会话维持连接，租约到期会话失效。通过回调函数实现通知。

Master职责：

1 分配，检测Tablet以及对Tablet进行负载均衡；

2 对GFS文件进行GC；

3 建立表和列族。

客户程序直接和Tablet通信，Master服务器负载很轻。

经验：很多Single-Master类型的分布式存储系统都是这样设计的，客户端读取的数据都不经过Master。

我们使用三层、类似B+树的结构存储Tablet的位置信息。RootTablet永远不可被分割。

一般通过预取Tablet地址进一步减少访问开销。另外还存放事件日志。

一个Tablet只能分配给一个Tablet服务器。Master记录Tablet的分配情况，Chubby跟踪记录Tablet服务器的状态。通过独占锁对Tablet服务器进行监控。

Tablet持久化信息保存在GFS上。更新操作提交到Redo日志中。最近提交的更新存放在排序的缓存即memtable；较早的存放在SSTable（冷热分离）。SSTable的索引放在内存里，通过重复Redo Point之后提交的变更重建memtable。

写操作先通过Chubby中读取出来的具有写权限的操作者列表进行验证，然后修改，最终记录在提交日志中。可采用批量提交实现吞吐量的提升。写内容插入到memtable里。

合并和分割Tablet时，读写操作不受影响。

每一次Minor Comapaction都会创建一个新的SSTable。合并所有的SSTable并生成新的SSTable的Merging Compaction称作Major Compaction。不包含已经删除的信息或数据。

最后要讲的是Bigtable的性能评估。

在序列写的基准测试中，使用的列关键字的范围是0到R-1。这个范围又被划分为10N个大小相同的区间。随机写入基准测试采用类似方法，除了行关键字写入前先做Hash，采用按R取模的方式，保证了写入的工作负载均匀分布在列存储空间内。随机读和随机写类似。

提升：由于Tablet服务器数量由一台增加到500台，吞吐量有了极大的正增长，倍率超过了100。可以得出结论，基准测试的瓶颈是单台Tablet服务器的CPU。但有一个问题就是基准测试程序产生的负载会有波动。随机读性能随Tablet服务器数量增加的幅度也是有一定限制的。当增加过多服务器时，每1Kbyte的读操作都会导致一个64KB大的Block在网络上传输，消耗了共享的1GB的链路导致。

经验教训：

1 很多类型的错误都会导致大型分布式系统受损。设计系统的部分功能时，不对其他部分功能做任何的假设；

2 彻底了解一个新特性之后才能决定是否要添加；

3 系统级监控非常重要；

4 简单设计的价值。