Tablet简介

一、Tablet定义

1.在Bigtable中，由于单个表（Table）存储的数据可能相当地多，那么读写的效率就会十分低下，于是Bigtable将Table分割为固定大小的Tablet，将其作为数据存储和查找的基本单位。

2.一定范围的row，视为一个tablet.

3.动态划分，是数据存储查找和负载均衡的最小单元。

4.tablet是数据存储的基本单元，是用户感知不到的。而Column Family则是访问的基本单元，是编程时指定的，两者一前一后，不是一个概念。

5.一个bigtable集群——> 若干张表table, 一个table——>若干个tablet，一个tablet——>某个表若干行的数据。

6.每个tablet大概100-200MB，每个集器存储100个左右的tablet，底层架构是GFS。

7.新建一张表时，只有一个tablet，随着插入数据不断增加，tablet达到一定大小后开始分裂，形成多个tablet。

8.采用Tablets的机制后，可以获得很好的负载均衡。比如：可以把经常响应的表移动到其他空闲机器上，然后快速重建。

9.Tablets在系统中的存储方式是不可修改的 immutable 的SSTables，一台机器一个日志文件。当系统的内存满后，系统会压缩一些Tablets。

二、Tablet组织结构

1.因为是在分布式系统中，那么每个Tablet所在的机器不同，需要记录相关信息（METADATA）对其进行管理。而存储这些METADATA又需要分布式的系统，所以Bigtable又将这些METADATA的METADATA记录在一个文件中，并将这个文件的位置保存在Chubby中。总结一下，Bigtable有以下三层结构：

• 在Chubby中保存着Root Tablet的位置
• Root Tablet中保存着METADATA Table中所有 Tablet 的位置。根据root tablet的每行数据可以定位到一个METADATA的tablet，也就是第二层的METADATA表的other tablet
• METADATA Table中保存着所有存储数据的Tablet的位置
  由于Root Tablet的特殊性，哪怕它的数据量再大，它也不允许被分割。METADATA tables被读取到内存中以加快速度，其中存储的是以开始和结尾的Row Key作为键，tablet位置作为值的映射。

2.如果客户端希望读取特定的数据，那么它会以此读取Chubby中的文件，Root Tablet，METADATA Tablet，最后读取存储改数据的Tablet。同时，为了加快读取的速度，它会将这些信息缓存到本地，直到信息失效。

3.基于 GFS 存储系统的 Bigtable 的存储逻辑则如下图所示：

特点是：

• 拥有相同 row key 的键值对分为多个 Tablet 进行分布式存储（每一个 Tablet 默认大小为 200 MB），如果字节大小不足以填满 200 MB，那么也需要占用一个 Tablet 大小（这种情况不常见）；
• Tablet 是 Bigtable 中数据分布和负载均衡的最基本单位，这个性质对于 GFS 系统来说，就是 GFS 会为每一个 Tablet 默认提供 3 个副本，每一个副本尽量存储在不同机架上的不同主机的磁盘上；

三、tablet的分配

核心——每个tablet server在chubby有一个对应的文件和该文件的锁

1.tablet server的变化

Bigtable使用Chubby来检测Tablet Server的变化。这里的操作和Zookeeper的用法类似，当有新节点加入时，它需要在Chubby的指定目录新建一个对应的文件，并获取该文件的锁。由于所有的节点在Chubby中都有对应的文件，那么Master可以通过监听Chubby来获取所有Tablet Server的信息。
master通过监控这个目录获取所有tablet server的地址信息的具体流程如下：
①master从chubby获取一个唯一的master锁，确保自己是主master ②扫描指定目录获取所有tablet server信息 ③和所有tablet server通信，获取每个tablet server正在维护的tablet信息 ④扫描METADATA表，获取tablet全集
通过上述流程，master可以获取tablet全集和当前已分配给tablet server的tablet集合，从而得到当前未被分配的tablet集合，并为其分配tablet server。
这里有两种节点失效的情况，一种是仅仅回收了锁但是文件还在，这种情况很可能是节点崩溃了。由于节点不能自己退出，所以在Master节点得到该文件的锁后，它会将文件删除，以此表示节点退出。另一种情况是，文件已经被删除，这种情况说明节点是主动退出系统，那么可以直接重新分配Tablet给其他节点即可。

2.分配tablet

在正常的情况下，系统中会有大量数据写入，Master需要负责将这些数据分配到合适的Tablet Server。Bigtable并没有明确指出分配所使用的的算法，但是它提出了一个要求。为了保证数据的一致性，同一时间，一个 Tablet只能被分配给一个Tablet Server。Master通过向 Tablet Server 发送载入请求来分配 Tablet。如果该载入请求被Tablet Server接收到前Master仍是有效的，那么就可以认为此次 Tablet 分配操作已成功。

3.Master崩溃的情况下的恢复步骤：

①在 Chubby 上获取 Master 独有的锁，确保不会有另一个 Master 同时启动
②从 Chubby 了解在工作的 Tablet Server
③从各个 Tablet Server 处获取其所负责的 Tablet 列表，并向其表明自己作为新 Master 的身份，确保 Tablet Server 的后续通信能发往这个新 Master
④Master 确保 Root Tablet 及 METADATA 表的 Tablet 已完成分配
⑤Master 扫描 METADATA 表获取集群中的所有 Tablet，并对未分配的 Tablet 重新进行分配（通过query到的METADATA tablets复现METADATA table的信息：若query不到的METADATA tablets，需要分配；METADATA table中存在但是query不到的，放到未分配tablet的集合；METADATA table中不存在但是query到的，在METADATA table中记录路由）
其中，第四步是为了第五步的正确执行。

四、tablet的变更

tablet集合在如下几个情况下会发生变更：

• 新建表
• 删除表
• tablet合并或者分裂
  前两个时间都需要通过master进行，因此master可以跟踪这些事件。第三种情况比较特殊，是在client和tablet server通信过程中发生的，tablet server负责更新METADATA表中的tablet信息并通知到master

五、读写tablet

大致流程：bigtable是基于leveldb搭建的集群服务。
内存中维护一个memtable，存储按序排列的数据，写操作先落盘到log，再写入memtable，读操作在memtable和磁盘上的sstable的合并视图上做归并查找。sstable和log通过gfs实现副本管理，保证磁盘文件可用性。

1.每个Tablet由若干个位于 GFS 上的 SSTable、一个位于内存内的MemTable以及一份Tablet Log组成。
2.为了保证系统可恢复，Google首先使用Table Log（即WAL）将客户端发出的写操作请求记录在磁盘中，那么，一旦系统崩溃，仍然可以从磁盘读取数据，继续执行命令。然后，相关的数据被放入位于内存中的Memtable中，因为内存的速度相当快，那么执行排序等操作就要快得多。当Memtable的大小达到设定的值后，它就会以SSTable的形式被存储到GFS中，这被称为Minor Compaction。
3.客户端的读操作请求则要综合考虑Memtable和SSTable中的数据，如果Memtable中已经有需要读的数据，就无需读取SSTable。由于Memtable和SSTable都是有序的，所以读取的速度都相当快。
4.虽然论文没有明确指出，Memtable和SSTable的大小很可能是64MB。因为GFS将单个Chunk设置为64MB，那么为了最大化地利用磁盘空间，Memtable和SSTable的大小设置为这个值是相当合理的。
5.由于SSTable中的数据有可能被标记为删除，那么我们需要定期对其进行处理，Bigtable将其称为Major Compaction。在这个过程中，Bigtable会将过期或者被删除的数据删除，并合并多个SSTable。这里似乎和GFS的Garbage Collection有点类似，但是这可能是两个层面的活动。Bigtable清理的是单个Chunk中的数据，而GFS清理的是磁盘中的单个Chunk。