写点什么

【迁移】撸论文系列之——Bigtable

用户头像
罗琦
关注
发布于: 2020 年 05 月 22 日

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



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



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



目的:可靠处理PB级数据,分布式部署



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



数据模型: 

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





行 

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



列族 

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



时间戳 

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



API 

写:



// Open the table
Table *T = OpenOrDie(“/bigtable/web/webtable”); // Write a new anchor and delete an old anchor RowMutation
r1(T, “com.cnn.www”);
r1.Set(“anchor:www.c-span.org”, “CNN”);
r1.Delete(“anchor:www.abc.com”);Operation op;Apply(&op, &r1);

读:

Scanner scanner(T);ScanStream *stream;
stream = scanner.FetchColumnFamily(“anchor”);
stream->SetReturnAllVersions();
scanner.Lookup(“com.cnn.www”);
for (; !stream->Done(); stream->Next()) {
printf(“%s %s %lld %s\n”,
scanner.RowName(),
stream->ColumnName(),
stream->MicroTimestamp(),
stream->Value());
}

可跨行批量写入,不支持跨行事务处理。可以同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 简单设计的价值。

发布于: 2020 年 05 月 22 日阅读数: 261
用户头像

罗琦

关注

后浪 2017.12.15 加入

字节跳动工程师

评论

发布
暂无评论
【迁移】撸论文系列之——Bigtable