DataModel
BigTable在逻辑上本质上是用一个超大的Map进行存储所有数据的。是一个三维的map:（key_row,key_col,key_time）-> value。如下图：
因此原文对BigTable给出了如下的定义：
A Bigtable is a sparse, distributed, persistent multidimensional sorted map. The map is indexed by a row key, column key, and a timestamp; each value in the map is an uninterpreted array of bytes.
这里如何理解”sparse“？（参考了康巴尔的解释）
左边是标准的关系型数据库的数据模型：每条记录（行）的格式通常是固定的，包含所有的信息（当然也可以有null，但逻辑上排列紧凑）
右边是BigTable的数据模型：允许有些行数据没有对应的列（逻辑上排序相对稀疏）
Structure
总体来说，Big Table主要依赖于两个组件：GFS和Chubby。下面具体描述一下Big Table的架构是怎么样的，以及为什么要依赖这两个组件，这两个组件在整个系统中扮演了什么样的地位。
Structure
如上图所示，BigTable主要由以下部分组成
Client：通过读取chubby的tablet目录，获取元数据（METADATA）信息，直接和Tablet Server通信。
Master Server：Tablet分配、Tablet状态监控、负载均衡、GFS文件的垃圾回收、模式修改等。
Tablet Server：存储Tablet数据，每个Tablet包含了某个范围内的行的所有数据。
Building Blocks
GFS：首先需要明确的是GFS是一个文件系统，而Big Table是一个存储系统（MapReduce是一种计算模型）。存储系统是干嘛的？通俗一点就是通过这个存储系统，我们能够根据某条数据记录获取该条数据记录的位置，并对它进行操作。BigTable就是将所有的数据存储在GFS中，而自身存储数据的位置信息，GFS为BigTable提供了数据容错和高性能。如上图所示，BIgTable中有许多Tablet Server，这个Tablet Server就是存储数据位置信息的，在文章中被定义为 “Tablet”。
Chubby：由于没细看过Chubby的论文，这里就只能粗略地讲一下Chubby。chubby是一个高可用的、持久性的分布式锁服务，它提供一个名字空间，包含了目录和小文件。每个目录和文件可以被用作一个锁，针对文件的读和写操作都是原子的。Chubby是有5台服务器组成的，其中一台是master，使用chubby服务的客户端通过RPC与chubby的master进行通信，其他服务器只是Chubby的容错保证，使用的是Paxos算法。那BigTable用它做啥？总体来说就是需要它这个分布式锁的服务来维护BigTable的各种操作正常，以及监控一些状态。由于Chubby这个分布式锁有点老，这里就不细究了。
Master
Master是如何管理的呢？
当一个Tablet服务器启动，它会在Chubby的一个指定目录下建立一个唯一的文件，并且获取该文件的独占锁。Master服务器则通过轮询Tablet服务器文件锁的状态来检测何时Tablet服务器不再为Tablet提供服务。Master服务器还会实时监控着整个服务器目录，因此Master服务器能够知道有新的Tablet服务器加入了。当Tablet服务器终止时（比如，集群的管理系统将该Tablet服务器的主机从集群中移除），它会尝试释放它持有的文件锁，这样一来，Master服务器就能尽快把Tablet分配到其它的Tablet服务器。
Tablet
下面是Tablet的结构，就是一层层地往下找数据的位置（类似B+树），第一个是Chubby文件，存储了root tablet的位置信息，由于是chubby文件，也就意味着一旦chubby不可用，整个Big Table就丢失了root tablet，整个服务也就不可用了。第二个是RootTablet，它永远不会被分割，因此这个存储结构最多不会超过三层。最后一层就是Google SSTable文件，存储于GFS上。因此客户端找数据的过程，就是通过chubby先找到RootTablet的位置，然后去访问它，再通过RootTablet内的信息找到METADATA Tablet的位置，然后访问它，类似的最后找到SSTable的位置，去GFS中寻找最终数据。这个过程客户端当然也有缓存处理。
Tablet的持久化保证是通过WAL日志来实现的，WAL存储于GFS中，在Tablet Server重启时重放日志即可。
