详细讲解Hadoop中的简单数据库HBase-Mysql Tutorial-php.cn

数据模型 HBase数据库使用了和Bigtable非常相似的数据模型。用户在表格里存储许多数据行。每个数据行都包括一个可排序的关键字，和任意数目的列。表格是稀疏的，所以同一个表格里的行可能有非常不同的列，只要用户喜欢这样做。写操作是行锁定的，你不能一次

数据模型

HBase数据库使用了和Bigtable非常相似的数据模型。用户在表格里存储许多数据行。每个数据行都包括一个可排序的关键字，和任意数目的列。表格是稀疏的，所以同一个表格里的行可能有非常不同的列，只要用户喜欢这样做。

写操作是行锁定的，你不能一次锁定多行。所有对行的写操作默认是原子的。

所有数据库更新操作都有时间戳。HBase对每个数据单元，只存储指定个数的最新版本。客户端可以查询“从某个时刻起的最新数据”，或者一次得到所有的数据版本。

概念模型

从概念上，一个表格是一些行的集合，每行包含一个行关键字（和一个可选的时间戳），和一些可能有数据的列（稀疏）。下面的例子很好的说明了问题：

详细讲解Hadoop中的简单数据库HBase

物理模型

在概念上表格是一个稀疏的行/列矩阵，但是在物理上，它们按照列存储。这是我们的一个重要设计考虑。

上面“概念上的”表格在物理上的存储方式如下所示：

详细讲解Hadoop中的简单数据库HBase

请大家注意，在上面的图中，没有存储空的单元格。所以查询时间戳为t8的“content:”将返回null，同样查询时间戳为t9，“anchor:”值为“my.look.ca”的项也返回null。

不过，如果没有指明时间戳，那么应该返回指定列的最新数据值，并且最新的值在表格里也时最先找到的，因为它们是按照时间排序的。所以，查询“contents:”而不指明时间戳，将返回t6时刻的数据；查询“anchor:”的“my.look.ca”而不指明时间戳，将返回t8时刻的数据。

例子

为了展示数据在磁盘上是怎么存储的，考虑下面的例子：

程序先写了行“[0-9]”，列“anchor:foo”；然后写了行“[0-9]”，列“anchor:bar”；最后又写了行“[0-9]”，列“anchor:foo”。当把memcache刷到磁盘并紧缩存储后，对应的文件可能如下形式：

详细讲解Hadoop中的简单数据库HBase

注意，列“anchor:foo”存储了2次（但是时间戳不同），而且新时间戳排在前面（于是最新的总是最先找到）。

HRegion (Tablet)服务器

对用户来说，一个表格是是一些数据元组的集合，并按照行关键字排序。物理上，表格分为多个HRegion（也就是子表，tablet）。一个子表用它所属的表格名字和“首/尾”关键字对来标识。一个首/尾关键字为和的子表包含[,)范围内的行。整个表格由子表的集合构成，每个子表存储在适当的地方。

物理上所有数据存储在Hadoop的DFS上，由一些子表服务器来提供数据服务，通常一台计算机只运行一个子表服务器程序。一个子表某一时刻只由一个子表服务器管理。

当客户端要进行更新操作的时候，先连接有关的子表服务器，然后向子表提交变更。提交的数据添加到子表的HMemcache和子表服务器的HLog。HMemcache在内存中存储最近的更新，并作为cache服务。HLog是磁盘上的日志文件，记录所有的更新操作。客户端的commit()调用直到更新写入到HLog中后才返回。

提供服务时，子表先查HMemcache。如果没有，再查磁盘上的HStore。子表里的每个列族都对应一个HStore，而一个HStore又包括多个磁盘上的HStoreFile文件。每个HStoreFile都有类似B树的结构，允许快速的查找。

我们定期调用HRegion.flushcache()，把HMemcache的内容写到磁盘上HStore的文件里，这样给每个HStore都增加了一个新的HStoreFile。然后清空HMemcache，再在HLog里加入一个特殊的标记，表示对HMemcache进行了flush。

启动时，每个子表检查最后的flushcache()调用之后是否还有写操作在HLog里未应用。如果没有，那么子表里的所有数据就是磁盘上HStore文件里的数据；如果有，那么子表把HLog里的更新重新应用一遍，写到HMemcache里，然后调用flushcache()。最后子表会删除HLog并开始数据服务。

所以，调用flushcache()越少，工作量就越少，而HMemcache就要占用越多的内存空间，启动时HLog也需要越多的时间来恢复数据。如果调用flushcache()越频繁，HMemcache占用内存越少，HLog恢复数据时也越快，不过flushcache()的消耗费也需要考虑。

flushcache()调用会给每个HStore增加一个HStoreFile。从一个HStore里读取数据可能要访问它的所有HStoreFile。这是很耗时的，所以我们需要定时把多个HStoreFile合并成为一个HStoreFile，通过调用HStore.compact()来实现。

Google的Bigtable论文对主要紧缩和次要紧缩描述有些模糊，我们只注意到2件事：

1．一次flushcache()把所有的更新从内存写到磁盘里。通过flushcache()，我们把启动时的日志重建时间缩短到0。每次flushcache()都给每个HStore增加一个HStoreFile文件。

2．一次compact()把所有的HStoreFile变成一个。

和Bigtable不同的是，Hadoop的HBase可以把更新“提交”和“写入日志”的时间周期缩短为0（即“提交”就一定写到了日志里）。这并不难实现，只要它确实需要。

我们可以调用HRegion.closeAndMerge()把2个子表合并成一个。当前版本里2个子表都要处于“下线”状态来进行合并。

当一个子表大到超过了某个指定值，子表服务器就需要调用HRegion.closeAndSplit()，把它分割成2个新的子表。新子表上报给master，由master决定哪个子表服务器接管哪个子表。分割过程非常快，主要原因是新的子表只维护了到旧子表的HStoreFile的引用，一个引用HStoreFile的前半部分，另一个引用后半部分。当引用建立好了，旧子表标记为“下线”并继续存留，直到新子表的紧缩操作把对旧子表的引用全部清除掉时，旧子表才被删除。

总结：

1．客户端访问表格里的数据。

2．表格分成许多子表。

3．子表由子表服务器维护，客户端连接子表服务器来访问某子表关键字范围内的行数据。

4．子表又包括：

A．HMemcache，存储最近更新的内存缓冲

B．HLog，存储最近更新的日志

C．HStore，一群高效的磁盘文件。每个列族一个HStore。

HBase的Master服务器

每个子表服务器都维持与唯一主服务器的联系。主服务器告诉每个子表服务器应该装载哪些子表并进行服务。

主服务器维护子表服务器在任何时刻的活跃标记。如果主服务器和子表服务器间的连接超时了，那么：

A．子表服务器“杀死”自己，并以一个空白状态重启。

B．主服务器假定子表服务器已经“死”了，并把它的子表分配给其他子表服务器。

注意到这和Google的Bigtable不同，他们的子表服务器即使和主服务器的连接断掉了，还可以继续服务。我们必须把子表服务器和主服务器“绑”在一起，因为我们没有Bigtable那样的额外锁管理系统。在Bigtable里，主服务器负责分配子表，锁管理器（Chubby）保证子表服务器原子的访问子表。HBase只使用了一个核心来管理所有子表服务器：主服务器。

Bigtable这样做并没有什么问题。它们都依赖于一个核心的网络结构（HMaster或Chubby），只要核心还在运行，整个系统就能运行。也许Chubby还有些特殊的优点，不过这超过了HBase现在的目标范围。

当子表服务器向一个新的主服务器“报到”时，主服务器让每个子表服务器装载0个或几个子表。当子表服务器死掉了，主服务器把这些子表标记为“未分配”，然后尝试给别的子表服务器。

每个子表都用它所属的表格名字和关键字范围来标识。既然关键字范围是连续的，而且最开始和最后的关键字都是NULL，这样关键字范围只用首关键字来标识就够了。

不过情况并没这么简单。因为有merge()和split()，我们可能（暂时）会有2个完全不同的子表是同一个名字。如果系统在这个不幸的时刻挂掉了，2个子表可能同时存在于磁盘上，那么判定哪个子表“正确”的仲裁者就是元数据信息。为了区分同一个子表的不同版本，我们还给子表名字加上了唯一的region Id。

这样，我们的子表标识符最终的形式就是：表名+首关键字+region Id。下面是一个例子，表名字是hbaserepository，首关键字是w-nk5YNZ8TBb2uWFIRJo7V==，region Id是6890601455914043877，于是它的唯一标识符就是：

hbaserepository, w-nk5YNZ8TBb2uWFIRJo7V==,6890601455914043877

元数据表

元数据表可能增长，并且可以分裂成多个子表。为了定位元数据表的各个部分，我们把所有元数据子表的元数据保存在根子表（ROOT table）里。根子表总是一个子表。

在启动时，主服务器立即扫描根子表（因为只有一个根子表，所以它的名字是硬编码的）。这样可能需要等待根子表分配到某个子表服务器上。

一旦根子表可用了，主服务器扫描它得到所有的元数据子表位置，然后主服务器扫描元数据表。同样，主服务器可能要等待所有的元数据子表都被分配到子表服务器上。

最后，当主服务器扫描完了元数据子表，它就知道了所有子表的位置，然后把这些子表分配到子表服务器上去。

主服务器在内存里维护当前可用的子表服务器集合。没有必要在磁盘上保存这些信息，因为主服务器挂掉了，整个系统也就挂掉了。

Bigtable与此不同，它在Google的分布式锁服务器Chubby里储存“子表”到“子表服务器”的映射信息。但我们把这些信息存储到元数据表里，因为Hadoop里没有等价Chubby的东西。

这样，元数据和根子表的每行“info:”列族包含3个成员：

1.Info:regioninfo包含一个序列化的HRegionInfo对象。

2.Info:server包含一个序列化的HServerAddress.toString()输出字符串。这个字符串可以用于HServerAddress的构造函数。