HBASE 实现论文

1.背景介绍
Bigtable通常放在大数据课程NoSQL中，NoSQL解决方案主要落实在两个领域：（1）key-value形式，其代表是Bigtable和Dynamo；（2）Scheme-less形式，代表是Cassandra（接下来也会分享到Cassandra相关论文）。其中Cassandra是处于传统数据库和key-value形式中间。Biatable这篇论文是Google大数据领域的“三驾马车”之一，之前已经分享过另外两篇：GFS和MapReduce。

简单来说，Bigtable是一个用于管理结构化数据的分布式存储系统，主要针对大的数据规模：数千个商用服务器上的数PB数据。Google的许多项目都在Bigtable中存储数据，包括网络索引，Google Earth和Google Finance。这些应用程序会对Bigtable提出非常不同的需求，无论是在数据块大小方面（从URL链接的网页到卫星图像），抑或是延迟要求（从后端批量处理到实时数据服务）。尽管需求多种多样，但是Bigtable已经成功地为这些Google产品提供了灵活，高性能的解决方案。文章介绍了Bigtable提供的数据模型，Bigtable不支持完整的关系数据模型; 相反，它为client提供了一个简单的数据模型，使得client可以动态控制数据的布局和格式。数据是使用行和列名称索引的，可以是任意字符串。Bigtable还将数据视为未解释的字符串，尽管client通常会将各种形式的结构化和半结构化数据序列化为这些字符串。

2.数据模型
Bigtable是一个稀疏的，分布式的，持久的多维有序map。 map由行键，列键和时间戳索引;每个值都是未解释的byte数组。

Rows：表中的行键（row keys）是任意字符串（当前大小为64KB，但对于大多数用户来说，10-100字节是典型大小）。单个行键下的每次数据读取或写入都是atomic（无论行中读取或写入的不同列的数量如何）。Bigtable按字典顺序排列行键来维护数据。表的行范围（row range）是动态划分的。规划的row range也被称为tablet（简单来说，就是确定一定的行数被称作tablet），它是分配和负载平衡的单位。较短的行范围读取效率更高，并且通常仅需要与少量机器通信。
Column Families：列的key通过以下形式命名：family:qualifier。列的key被分组为Column Families，存储在Column Families中的所有数据通常具有相同的类型。Column Families创建之后，才可以将数据存放在此family的qualifier下。一个表中的不同Column Families的数量很小（最多几百个），而且这些Column Families在运行期间很少发生变化。但是table可以具有无限数量的列（通过qualifier），Column Families构成了访问控制的基本单元。
Timestamps：时间戳的两个主要作用是：管理不同版本和垃圾回收。Bigtable中的每个单元格都可以包含相同数据的多个版本；这些版本由时间戳索引。Bigtable时间戳是64位整数。它们可以由Bigtable分配，在这种情况下，它们以微秒表示“实时”，或者由客户端应用程序显式分配。需要避免冲突的应用程序必须自己生成唯一的时间戳。以递减的时间戳顺序存储不同版本的单元，以便可以首先读取最新版本。可以通过两种设置，告诉Bigtable自动垃圾回收，来保证保存的数据版本不会过多。客户端可以指定仅保留单元的最近n个版本，或者仅保留足够新版本（例如，保留不超过特定时间的版本，如五天）。上面图中显示只保留每个页面的最近三个版本。
3.API
Bigtable 的API提供了创建和删除表和column families的功能。它还提供用于更改cluster，表和column families元数据的功能，例如访问控制权限。客户端应用程序可以在Bigtable中写入或删除值，从单个行中查找值，或迭代表中数据的子集。

    //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);
1
2
3
4
5
6
7
8
以上为c++代码。使用了RowMutation抽象类，来执行一系列更新，同时为了代码的简洁删除了无关代码。进而调用Apply操作，来执行原子性操作。

    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());
    }
1
2
3
4
5
6
7
8
9
10
11
12
以上为c++代码。使用Scanner抽象类来iterate特定行的anchors。Clients可以iterate多column families，有很多机制可以限制扫描的行、列和时间戳。例如可以采用正则表达式。
Bigtable支持执行客户端提供的脚本。 这些脚本是用Google开发的一种语言编写的，被称为Sawzall。目前，基于Sawzall的API不允许客户端写回Bigtable，但它确实允许各种形式的数据转换，基于任意表达式的过滤以及通过各种运算符进行汇总。Bigtable可以与MapReduce一起使用，MapReduce是一个用于运行Google开发的大规模并行计算的框架。Google工程师编写了一组包装器（wrappers），允许Bigtable既可以用作输入源，也可以用作MapReduce作业的输出目标。

4.Building Blocks
Bigtable建立在其他几个Google基础架构上。Bigtable使用分布式Google文件系统（GFS）来存储日志和数据文件。一个Bigtable集群通常运行在一个共享机器群中（这些机器上面运行着各种分布式应用），Bigtable要与其他机器共享这些计算资源。Bigtable依赖于集群管理系统来调度作业，管理共享机器上的资源，处理机器故障以及监视机器状态。

SSTable：Google SSTable文件格式用于在内部存储Bigtable数据。SSTable提供从键到值的持久的，有序的不可变映射，其中键和值是任意字节串。SSTable提供操作以查找与指定key相关联的value。在内部，每个SSTable包含一系列块（通常每个块的大小为64KB，但这是可配置的）。块索引（存储在SSTable的末尾）用于定位块; 打开SSTable时，索引将加载到内存中。查找过程如下：我们首先通过在内存索引中执行二分查找，然后从磁盘读取相应的块。SSTable也可以完全映射到内存中，这允许不碰磁盘的情况下执行查找和扫描。
Chubby：Bigtable同时依赖于一种名为Chubby的高可用性和持久性分布式锁定服务。Chubby服务由五个活动副本组成，其中一个被选为master并主动提供服务。当大多数副本正在运行并且可以相互通信时，该服务是存活的（live）。Chubby使用Paxos算法来保证其副本在失败时保持一致。Chubby提供了一个由目录和小文件组成的命名空间。每个目录或文件都可以用作锁，对文件的读写是原子性的。Chubby客户端库提供了Chubby文件的一致缓存。每个Chubby客户端都使用Chubby服务维护会话。如果客户的会话在租约到期时间内无法续订ssession租约，则会话到期结束。当客户端的会话到期结束时，它会丢失任何锁并释放句柄。Bigtable使用Chubby执行各种任务：确保任何时候最多只有一个active master; 存储Bigtable数据的引导位置（bootstrap location）; 发现tablet服务器并最终确定tablet服务器的死亡率; 存储Bigtable的schema信息（每个表的column family信息）;以及存储访问控制列表。 如果Chubby长时间不可用，Bigtable将无法使用，同时，Chubby不可用的概率是非常低的。
5.实现
Bigtable实现有三个主要组件：链接到每个client的库，一个master server和许多tablet服务器。可以在集群中增加或删除Tablet server，以适应工作负载的变化。HBase可以看作是Bigtable的开源实现，下图为在《Hadoop权威指南》第三版上的HBase架构图，仅仅作为参考，Big table的实现又类似之处，但千万不能混淆。

master负责将tablet分配给Tablet server，检测Tablet server的添加和到期，平衡Tablet server负载以及GFS中文件的垃圾收集。此外，它还处理架构更改，例如表和column family的创建。
每个Tablet server都管理一组tablet（通常是Tablet server之间的Tablet）。Tablet server处理对已加载的tablet的读写请求，并且还会拆分具有较大容量的tablet。
与许多single-master分布式存储系统一样，client数据不通过master：client直接与Tablet server通信以进行读取。因为Bigtable的client不依赖于master来获得定位信息，很多client从来不与master通信。
Bigtable集群存储了许多表。每个表包含一组tablet，每个tablet包含与行范围相关的所有数据。最初，每个表只包含一个tablet。随着表的增长，它会自动分成多个tablet，每个tablet大小约为100-200MB。

Tablet location：使用类似于B+树的数据结构（三层），来存储tablet的位置信息。第一级是存储在Chubby中的文件，其中包含root tablet的位置。root tablet包含METADATA表的位置。每个METADATA tablet都包含一组用户tablet的位置。root tablet只是METADATA表中的第一个tablet，但是经过特殊处理（它永远不会拆分）以确保tablet位置层次结构不超过三层。METADATA表将tablet的位置存储在行键下，该行键是tablet的表标识符及其结束行的编码。每个METADATA行在内存中存储大约1KB的数据。限制 METADATA为128MB，三级定位方案足以满足234个tablet定位。
tablet 分配：每个tablet一次分配到一台tablet服务器。master会跟踪tablet服务器的集合，以及tablet到tablet服务器的当前分配，包括哪些tablet未分配。如果tablet未分配，并且tablet服务器具有足够的空间，则master会通过向tablet服务器发送tablet加载请求来分配tablet。Bigtable使用Chubby来跟踪tablet服务器。当tablet服务器启动时，它会在特定的Chubby目录中创建并获取一个唯一命名文件的独占锁。master监视此目录（服务器目录）以发现tablet服务器。如果一个tablet服务器失去其独占锁，则该服务器将停止为其tablet提供服务：例如，由于网络分区导致服务器丢失其Chubby会话。Chubby提供了一种有效的机制，允许tablet服务器在不引起网络流量的情况下检查它是否仍然保持锁定。tablet服务器将尝试重新获取锁。如果文件不再存在，则tablet服务器将永远无法再次服务，因此它会自行终止。每当tablet服务器终止时（例如，因为集群管理系统正在从集群中移除tablet服务器的机器），它就会尝试释放锁，以便master能够更快地重新分配其tablet。
Tablet Serving：tablet的持久状态存储在GFS中。更新被提交到提交日志。在这些更新中，最近提交的更新存储在称为memtable的排序缓冲区的内存中; 之前的更新存储在一系列SSTable中。要恢复tablet，tablet服务器会从METADATA表中读取其元数据。 此元数据包含组成tablet的SSTable列表和一组重做点（redo points），这些重做点是指向可能包含tablet数据的任何提交日志的指针。服务器将SSTable的索引读入内存，并通过应用自重做点以来已提交的所有更新来重构memtable。
compactions：当写操作执行时，memtable的大小增加。当memtable大小达到阈值时，memtable被冻结，同时创建一个新的memtable，冻结的memtable转换为SSTable并写入GFS。这个compaction过程有两个目标：它缩小了tablet服务器的内存使用量，并减少了恢复期间必须从提交日志中读取的数据量（如果此服务器死机）。compaction发生时，传入的读写操作可以继续.