YunTable开发日记（4）-BigTable的存储模型

本文是《YunTable开发日记》的第四篇。

经过这几天的开发工作，我已经将YunTable所需的一些基本类库搭建起来，比如内存管理，字符串处理，I/O处理和基本的数据结构等，由于之前的编程以Java为主，所以在这方面花了一定的时间，导致整个项目的进度偏离了之前的预期，但是我也有很多的收获，比如我感受到了Java和C之间的异同：异就是Java能通过JVM和JDK提供给程序员一个非常便捷和安全的开发环境，就好象一个温室那样，而C语言呢？则是提供一个简单到以至于简陋的工具给程序员，但是却导致其具有非常强大的灵活性，在这方面，有点类似围棋。而同呢？就是不论写Java代码还是C代码，最核心也是最关键的，就是使用优雅的方式将重复的代码降至最低，从而降低整体的代码数量和复杂度。在关于语言特性的讨论之后，接下来就将介绍本文的核心内容，也就是BigTable的存储模型，首先是Tablet的运行机制。

Tablet的运行机制

在之前的一篇，我已经给大家介绍了由于一个BigTable需要存储海量的数据，使得其不得不被分割成多个Tablet，并且存储在多个的服务器上，下面就给大家介绍一下Tablet的运行机制。

图1. Tablet的运行机制（源自BigTable的论文）

当一个写的请求传递给一个Tablet时，它首先会将这个操作提交给Redo日志，也就是图1的tablet log，接着，在这些已经提交的写操作中，最新提交的那些会被放置在内存的一个被排序的缓存中，称为“memtable”，而较早的更新则会被flush到用于存储数据的SSTable中。而当一个读操作传递给一个Tablet的时候，这个读操作会根据一个有一系列的SStable和memtable合并的视图来查询数据，并且由于SSTable和memtable是按字典排序的数据结构，因此可以高效生成这个合并视图。下面将介绍用于存储数据的SSTable。

SSTable的介绍

简单而言，SSTable是一个用于排序存储Key-Value对的文件格式，并且是不可变动的（immutable），也就是写了之后，只能将其更新附加至其之后，而不能直接进行修改，这样是为了让系统能执行disk所擅长的顺序访问，而不是随机访问。由于关于SSTable的内部实现和格式是不公开的，所以在这里选择SSTable开源克隆HFile作为介绍的样板。HBase本来使用Hadoop的文件格式MapFile作为其存储文件的格式，但由于效率等原因，HBase的开发组在HBase的0.20版中引入了SSTable的开源版本HFile，并且随着HFile不断成熟，而且有可能在今后也成为Hadoop默认的文件格式，下图为HFile的格式：

图2. HFile的格式

在格式方面，HFile主要可以被分为两个部分：其一是Metadata部分，其包括文件的信息，数据与Metadata的索引和Trailer等，Trailer主要用于存储文件中每个模块的偏移值（offset），以便于系统访问和使用这个HFile文件。其二则是Data部分，其主要有一系列存储Key-Value对的Block组成，每个Block的大小大概在64KB左右，但是可以根据存储数据的大小来进行调整，比如当存储的数据比较小时，可以通过将Block的大小设为16KB，使得减少每个Block存储的数据量，从而减少Block内部的查询。

在大小方面，64MB是HFile比较常见的大小，也可以将HFile扩大至GB级，但是越大HFile需要更多内存以保持其Index被装载至内存中，以减少磁盘的Seek操作。同时HFile也像SSTable那样，对压缩有很好的支持，特别是对LZO算法支持，因为通过这个算法不仅能将数据压至原有的1/4大小，而且运行效率很高，从而能提升整个系统的运行效率。

本篇结束，下篇日记将主要讲解BigTable的分布式模型。

参考资料：

1. Bigtable的论文（中文版）
2. HFile: A Block-Indexed File Format to Store Sorted Key-Value Pairs