BigTable简单翻译

Bigtable: A Distributed Storage System for StructuredData

简述：Google的很多产品在进行数据存储的时候都用到了Bigtable，例如网页检索、Google地图和Google Finance。这些应用对Bigtable有各异的要求，包括：数据的大小（简单的网页URL到卫星数据级别的数据）和时延要求（后端处理到实时数据服务）。尽管要求众多，但是Bigtable能够提供统一的易扩展、高性能的解决方案。

 

1 Data model

Bigtable是一个稀疏的、分布式永久存储的排序多维度关联图。这个关联图中的索引有行关键字、列关键字和时间戳组成；在关联图中的每个值都是未解释的字节数组。

（row:string,column:string, time:int64）-->string

举例：在一个叫webtable中的某一行存储了CNN被引用的几个地方。其行关键字是CNN的web网址，这个网址是倒转的，即：com.cnn.www。在列关键字上有多个，例如有achor:cnnsi.com和anchor:my.look.ca，通过行关键字和列关键字，定位到一系列有时间戳的内容上。整个webtable的解释就是，cnn网站被列上的网站索引（anchor）时间戳显示的内容可以查找到。

1.1关于行

   行关键字是二进制字符串，目前最大支持64KB，一般用的大小为1-100字节。Bigtable中的行顺序按照行关键字的字典顺序进行排序，每行叫做一个tablet，作为分发和负载均衡的单位。在例子中webtable，通过把web地址逆序，把相同域的放在连续行，这样提高素具访问速度。

1.2关于列

    列关键将table分为了列族，每族列作为访问控制的基本单元。每族列上的数据都是同一种类型，必须在数据存储前创建。列的数目不会太多，一般不会超过百，列的修改很少在操作的时候被修改，但是还是允许列数量的改变。

一个列关键字可以定义为如下语义：列族：条件。就是说在列族中，可以通过条件进行排序和筛选。在上面的webtable中，假设有一列上为语言，那么对于列族可以通过语言进行条件筛选，比如通过给语言设置ID，可以快速筛选；上面提到的anchor，也能够进行筛选。

1.3时间戳

   在Bigtable中通过行关键字和列关键字找到的内容，可以针对同样数据有不同版本；不同的版本依靠时间戳来标记。时间戳是一个64位的整数，由应用程序进行实时的标记，精确到微秒。应用程序要负责产生独一无二的时间戳，不同版本的排序是按照时间戳下降排序，保证访问的时候，最新版本在前面。

2 API

Bigtable目前允许对单行进行读写和修改的操作，不支持同时对多行的操作；但是允许对多行在客户端进行打包。Goolge还为操作Bigtable开发了语言Sawzal。

Bigtable是基于Google的基础设施的，其中的数据和日志文件存储时在GFS中。在Goolge中，利用SSTable文件来存储Bigtable数据。在SSTable中，提供一个排序的不可修改的从关键字到值的关联图，并且关键字和值都是二进制字符串。可以通过关键字搜索到相应的值，并进行遍历。每个SSTable文件由块构成（一般是64KB，这个可以配置）；块的索引存在在SSTable的末尾。通过块索引能够定位块；当SSTable被打开的时候，将该索引加载到内存中。在单个硬盘中查找：首先在内存中的块索引定位合适的块，然后从硬盘读取相应的块。有的时候，可以将整个SSTable文件加载到内存中，这样就不用读取硬盘了。

 

Bigtable中使用了该可以用性和持久性的锁服务Chubby。Chubby服务中包含了五个活跃的副本服务器，其中一个作为主服务器响应请求。只要副本服务器能够运行，它们之间能够通信，Chubby服务就能执行。Chubby服务中采用了Paxos算法来保证副本一致性。每个目录或者文件都可以看作是一个锁。Chubby客户端和Chubby服务之间建立session，当用户的session在期限内没有更新session的租赁时间，那么session将会过期。当用户的session过期，那么他获得的锁将会被解除。

Bigtable中利用Chubby有如下作用：保证只有一个活跃的主服务器；保存Bigtable数据的启动位置；发现tablet服务器，终结死忙的tablet服务器；存储Bigtable的模式信息；存储访问控制列表（ACL）。

3 运行的Bigtable

Bigtable实例中包含三个主要部分：一个和所有客户端连接的库、一个主服务器和多个tablet服务器。tablet服务器可以根据负载的变化动态增加。

主服务器负责分配tablets到tablet服务器，发现新增的和过期的tablet服务器，对tablet服务器进行负载均衡，搜集在GFS中的文件。此外，还要处理模式的改变。

每个tablet服务器管理一系列的tablets。每个tablet服务器处理对tablets的读和写，当tablet过大的时候，还需要对其进行分割。

每个用户有多个table，每个table包含多个tablets，每个tablet包含了一行中的所有相关数据。初始的时候，一个table中只包含了一个tablet，随着table的增长，会进行分割。

Tablet的定位

采用三层结构构建成B+树来存储tablet的位置信息。Chubbyfile—>Root tablet(1^st metadata tablet)-->Other metadata tablet--->table1 … table N。

第一层存储在Chubby中的文件，包含了根tablet。根tablet包含了所有tablet的特殊metadata表。其中每个metadatatablet包含了用户一部分tablet的位置信息。其实根tablet就是metadata tablet中的第一个tablet，但是改tablet不会被分割。

一般metadata tablet的数量限制在128MB左右，加上tablet的大小在64KB，那么通过该三层结构可以寻址到2³⁴个tablet。

在用户库中缓存了tablet位置信息。如果用户不知道某个tablet的位置，或者缓存的talet位置信息部准确，会递归通过三层结构搜寻。如果用户缓存为空，在定位的时候就需要进行三次的往返，包括从Chubby读取文件；如果用户缓存过时，那么久需要六次往返，过期的缓存只能通过tablet的未命中来判定。

3.1 Tablet的分配

每个tablet服务器都一次只分配了一个tablet。主服务器需要跟踪这些有效的tablet服务器，并将tablet分配到这些服务器上。当一个tablet服务器启动的时候，它会创建并获得对在Chubby目录中一个唯一命名文件的独立锁。主服务器通过监控这个目录，来发现tablet服务器。主服务器需要发现down掉的tablet服务器，然后马上重新分配tablet。为了发现不再服务的tablet服务器，主服务器周期性的询问tablet服务器的锁状态。如果tablet服务器告知其锁丢失或者主服务器不能联系到该服务器，主服务器就会获得对该服务器文件的锁；在主服务器获得锁后，Chubby正常运行下，会将tablet服务器上的文件删除；待其上文件被删除，主服务器会重新分配tablet。

主服务器发现当前的tablet分配情况，过程如下：1.获得在Chubby中的master锁 2.主服务器浏览Chubby目录来发现活跃的服务器3.主服务器和每个活跃的服务器进行通信，得到已经在活跃服务器上的tablet信息4.主服务器浏览Metadata表（由各个tablets构成）知道所有tablets，如果发现有tablet尚未分配就会进行分配。

4优化

1本地组

用户可以将一些列组合为本地组。为每个tablet的本地组分配一个单独的SSTable。这样可以更加高效的读取数据。例如在webtable中，网页的元数据（例如语言）在一个本地组，网页内容在一个不同的组；当应用想要读取元数据时，就不用读取网页内容了。

2.压缩

两种压缩方式：Bentley和McIlroy模式，该模式通过一个窗口对常见的长串进行压缩；第二种压缩算法，利用16KB大小窗口寻找重复的串。

3.Bloom Filter

利用该过滤器来查找SSTable中是否包含了指定row/column对。