HbaseArchitecture
HBase架构
原文地址：http://wiki.apache.org/hadoop/Hbase/HbaseArchitecture
本文来自 博客园 逖靖寒 http://gpcuster.cnblogs.com
关于HBase，有一篇非常容易入门的文章，可以参考：Understanding HBase and BigTable介绍
为了更好地理解本文所讲的内容，强烈建议您先去阅读Google的论文Bigtable paper。
HBase是一个Apache开源项目，它的目标是提供一个在Hadoop分布式环境中运行的类似于BigTable的存储系统。正如同Google将BigTable架设在自己的分布式存储系统GFS中一样，HBase基于HDFS。
数据在逻辑上被组织成为表，行和列。我们可以使用类似于iterator的接口来遍历我们的行数据，同时也可以通过行的值来获取这一列的值。同一个行对应多个不同版本的列值。
数据模型
HBase使用的数据模型和Bigtable类似。应用程序将数据行存储在打上标签的表中。一个数据行包含有一个排好序的行键值和任意长度的列值。
一个列名的格式为"<family>:<label>" ，其中<family> 与 <label> 可以为任意的字节数组。一个表的<family>集合是固定的。如果希望修改一个表的<family>字段，需要使用管理员来操 作。不过，你可以在任何时候新增加一个<label> 而无需事先声明它。HBase在磁盘上按照<family>储存数据，所以一个<family>里的所有项应该有相同的读/写方 式。
默认每次将一行数据进行锁定，行数据的写入时原子操作，不过它可以对一行数据进行锁定，然后同时进行读和写的操作。
我们也可以一次性锁定多个行数据，不过这个操作需要我们现实去指定才可以。
概念模型
从概念上来看，一个表由多个数据行组成，每一个数据行中的列不一定有值。下面的这个例子来自Bigtable Paper。
| Row Key | Time Stamp | Column "contents:" | Column "anchor:" | Column "mime:" | |
| "com.cnn.www" | t9 | | "anchor:cnnsi.com" | "CNN" | |
| t8 | | "anchor:my.look.ca" | "CNN.com" | | |
| t6 | "<html>..." | | | "text/html" | |
| t5 | "<html>..." | | | | |
| t3 | "<html>..." | | | | |
物理存储模型
从概念上看，表数据是按照稀疏的行来存储的，但是物理上，他们是按照列来存储的。理解这个概念对考虑表的设计和程序设计时非常重要的。
回到先前的那个例子，按照物理存储的图如下：
| Row Key | Time Stamp | Column "contents:" |
| "com.cnn.www" | t6 | "<html>..." |
| t5 | "<html>..." | |
| t3 | "<html>..." |
| Row Key | Time Stamp | Column "anchor:" |
| "com.cnn.www" | t9 | "com.cnn.www" "CNN" |
| t8 | "anchor:my.look.ca" "CNN.com" |
| Row Key | Time Stamp | Column "mime:" |
| "com.cnn.www" | t6 | "text/html" |
从上面的图示可以看出来：空的列并没有被存储，因为他们并不需要面向列的存储格式。所以一个当请求列值为"contents:" 的时候，会返回空值。
如果请求数据的时候，没有提供timestamp的值，那么最新的数据将返回最新的值，并且在实际的存储中，所有的值也是按照timestamps降序排列的。
行的范围：区域
对 于一个程序而言，数据表是由一系列按升序排序的数据列组成，数据行按照名字的升序，时间戳按照降序。在物理上，数据表被拆分成多个数据行的区域（这个概念 对于在Bigtable中就是tablet）。每一个数据行的区域包含从开始行（包含）到中止行（排除）。所有的数据行的区域构成一个数据表。与 Bigtable不同的是，在Bigtable中，一个数据行区域有表名和结束行值决定，而HBase由表名和开始行值决定。
在 区域中的每一个列族都被一个称为HStore的对象管理。每一个HStore由一个或多个MapFiles（这是Hadoop中的一个文件类型）组成。 HStore的概念类似于Google的SSTable。MapFiles一旦被关闭，就是不可修改的类型了。MapFiles被存储在Hadoop的 HDFS中，其他不同的点如下：
-
MapFiles目前还无法进行内存的映射。
-
MapFiles由一些稀疏的索引文件来维护，而SSTable在其文件的最后。
-
HBase扩展了MapFiles，所以使用bloom filter的时候可以提高查找的性能。
架构与实现
HBase由以下三个主要构件组成：
-
HBaseMaster (类似于Bigtable master server)
-
HRegionServer(类似于Bigtable tablet server)
- HBase Client, 由org.apache.hadoop.hbase.client.HTable定义
下面，我们以此讨论这几个部分。
HBaseMaster
HBaseMaster 负责给HRegionServer分配区域。第一个分配的区域就是ROOT区域，它用于定位所有的META区域。每一个META区域用于定位一些列用户区 域。一旦所有的META区域被分配好了以后，master便开始分配用户区域给HReginServer，同时维护每一个HReginServer的负载 平衡。
同时HBaseMaster还含有一个指向包含有ROOT区域的HReginServer地址。
同时，HBaseMaster会监控每一台HReginServer的健康状况，如果某一台HReginServer不可用，它将会把不可用的HReginServer来提供服务的HLog和表由其他HReginServer来提供。
另外，HBaseMaster还负责对数据表进行管理，比如让表处于有效（online）或失效（offline）的状态，改变表的结构（增加或者减少列族），等等。
与 Bigtable不同的是，目前，如果HBaseMaster失效了，整个集群就会关闭。在Bigtable中，即使Master机器失效 了，Tabletserver还是可以提供服务的。Bigtable使用了而外的锁管理机制，而我们的HBase使用的单点访问模式：所有的 HReginServer都访问HBaseMaster。
The META Table
META 表存储了所有的用户区域的信息，同时包括HReginServer对象的信息，其中有每一个行值的开始到结束的键值，一个表是否有效或失效，每一个HReginServer的地址，等等。META 表的大小随着用户区域的增加而增加。
The ROOT Table
ROOT表被限制在一个区域中，它指定了所有的META表信息。这些信息包括每一个META所处的区域和HReginServer信息。
ROOT表和META表每一行的大小大概是1KB左右。每一个区域的大小是256MB，这意味着ROOT表可以装载2.6 x 105 META区域，转化成用户区域就是6.9 x 1010，转化成可以存储的字节数就是1.8 x 1019 (264) 。
HRegionServer
HReginServer负责处理用户的读和写的操作。HReginServer通过与HBaseMaster通信获取自己需要服务的数据表，并向HBaseMaster反馈自己的运行状况。
Write Requests
当一个写的请求到来的时候，它首先会写到一个叫做HLog的write-ahead log中。HLog被缓存在内存中，称为Memcache，每一个HStore只能有一个Memcache。
Read Requests
当一起读取的请求到来的时候，HReginServer会先在Memcache中寻找该数据，当找不到的时候，才会去在MapFiles 中寻找。
Cache Flushes
当Memcache到达配置的大小以后，将会创建一个MapFile，将其写到磁盘中去。这将减少HReginServer的内存压力。
在读和写的过程中，Cache flushes将会经常发生。当创建一个新的MapFile的时候，读和写的操作会被挂起，知道新的MapFile创建好，并被加入到HStroe的管理中后才可以使用。
Compactions
当一定数量的MapFiles超过一个配置的阀值之后，压缩操作就会开始执行。压缩操作的主要工作就是周期性地将一些MapFiles合并成一个MapFile。
在执行压缩操作的过程中，HReginServer的读和写操作将被挂起，直到操作执行完毕。
Region Splits
当一个HStore所管理的MapFiles超过一个配置（当前是256MB）的值以后，将会执行区域的切分操作。区域的切分操作将原先的区域对半分割为2个新的区域。
在进行区域切分的操作过程中，读和写的操作将被挂起，直到完成为止。
HBase Client
HBase Client负责寻找提供需求数据的HReginServer。在这个过程中，HBase Client将首先与HBaseMaster通信，找到ROOT区域。这个操作是Client和Master之间仅有的通信操作。
一旦ROOT区域被找到以后，Client就可以通过扫描ROOT区域找到相应的META区域去定位实际提供数据的HReginServer。
当定位到提供数据的HReginServer以后，Client就可以通过这个HReginServer找到需要的数据了。
这些信息将会被Client缓存起来，当下次请求的时候，就不需要走上面的这个流程了。
当这些区域中的某个区域不可用的时候，Client将会逆向执行上面的过程，直到找到实际提供数据的HReginServer为止。
Client API
参考Javadoc中关于HTable和HBaseAdmin的介绍。
Scanner API
为了获取一个Scanner，需要实例化一个HTable，然后调用他的getScanner方法。这个方法将返回一个Scanner对象，通过这个对象你可以使用next和close的方法。