HBase 学习

      最近有一段时间没有写文章和学习技术，主要是在弄一个项目的需求调研和概要设计。通过一个多月来的项目需求、概要设计，明白了一些道理，软件工程部只是写代码。说这话可能有人会觉得很搞笑，到现在才知道，但是我想说的是：知道不等于明白，知道不等于领悟到。有时间，等任务完成将项目带回公司后，好好的说一下这次调研的感受和学习。

       今天主要是将项目要用的一个技术来阐述一下。hadoop项目中的hbase。对于hadoop很多人都应该知道和了解，主要是来处理分布式任务。其中的工作原理会在后面的时间内慢慢的通过学习和实践补充说明。对于hbase，我们先一定要知道他的存储机构，再去了解他的工作原理和优势。

       hbase和我们传统的关系性数据库不同，他的物理存储结构是列式存储，不同于关系性数据库的行存储。下面我会引用一篇文章来对这个列式存储做一个介绍，对hbase有一定的了解。

数据模型

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

列名是“<族名>:<标签>”形式，其中<族名>和<标签>可以是任意字符串。一个表格 的<族名>集合（又叫“列族”集合）是固定的，除非你使用管理员权限来改变表格的列族。不过你可以在任何时候添加新的<标签>。 HBase在磁盘上按照列族储存数据，所以一个列族里的所有项应该有相同的读/写方式。

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

所有数据库更新操作都有时间戳。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刷到磁盘并紧缩存储后，对应的文件可能如下形式：

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

 

 

下面我们简单的说一下hbase的工作原理以及他带来分布式存储的优势。

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的构造函数。

3.Info:startcode是一个序列化的long整数，由子表服务器启动的时候生成。子表服务器把这个整数发送给主服务器，主服务器判断元数据和根子表里的信息是否过时了。

所以，客户端只要知道了根子表的位置，就不用连接主服务器了。主服务器的负载相对很小：它处理超时的子表服务器，启动时扫描根子表和元数据子表，和提供根子表的位置（还有各个子表服务器间的负载均衡）。

HBase的客户端则相当复杂，并且经常需要结合根子表和元数据子表来满足用户扫描某个表格的需求。如果某个子表服务器挂了，或者本来应该在它上面 的子表不见了，客户端只能等待和重试。在启动的时候，或最近有子表服务器挂掉的时候，子表到子表服务器的映射信息很可能不正确。

结论:

1．子表服务器提供对子表的访问，一个子表只由一个子表服务器管理。

2．子表服务器需要向主服务器“报到”。

3．如果主服务器挂了，整个系统就挂了。

4．只有主服务器知道当前的子表服务器集合。

5．子表到子表服务器的映射存储在2种特殊的子表里，它们和其他子表一样被分配到子表服务器上。

6．根子表是特殊的，主服务器总是知道它的位置。

7．整合这些东西是客户端的任务。

 

对于hbase最终的物理数据还是存储在HDFS上，后面我会将很多文章都说到的hbase的物理存储结构进行分析，让我们更多的去了解他的工作原理。

废话：路漫漫其修远兮，吾将上下求索！