HBase 简介、架构、工作原理深析——（一）

一、 简介

HBase是一种构建在HDFS之上的分布式、面向列的存储系统。在需要实时读写、随机访问超大规模数据集时，可以使用HBase。

尽管已经有许多数据存储和访问的策略和实现方法，但事实上大多数解决方案，特别是一些关系类型的，在构建时并没有考虑超大规模和分布式的特点。许多商家通过复制和分区的方法来扩充数据库使其突破单个节点的界限，但这些功能通常都是事后增加的，安装和维护都和复杂。同时，也会影响RDBMS的特定功能，例如联接、复杂的查询、触发器、视图和外键约束这些操作在大型的RDBMS上的代价相当高，甚至根本无法实现。

HBase从另一个角度处理伸缩性问题。它通过线性方式从下到上增加节点来进行扩展。HBase不是关系型数据库，也不支持SQL，但是它有自己的特长，这是RDBMS不能处理的，HBase巧妙地将大而稀疏的表放在商用的服务器集群上。

HBase 是Google Bigtable 的开源实现，与Google Bigtable 利用GFS作为其文件存储系统类似， HBase 利用Hadoop HDFS 作为其文件存储系统；Google 运行MapReduce 来处理Bigtable中的海量数据， HBase 同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable 利用Chubby作为协同服务， HBase 利用Zookeeper作为对应。

二、 特点

1.  大 ： 一个表可以有上亿行，上百万列。
2.  面向列 ： 面向列表（簇）的存储和权限控制，列（簇）独立检索。
3.  稀疏 ： 对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
4.  无模式 ： 每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
5.  数据多版本 ： 每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
6.  数据类型单一 ： HBase中的数据都是字符串，没有类型。

三、 Nosql数据库
此部分详见 nosql一篇

四、 Hbase与hadoop及其组件的关系

HBase参考了Google的BigTable建模，且将下面三篇博文作为HBase实现的理论基础：
　　■ BigTable by Google (2006).
　　■ HBase and HDFS Locality by Lars George (2010).
　　■ No Relation: The Mixed Blessings of Non-Relational Databases by Ian Varley (2009).
 HBase和HDFS有着非常紧密的关系，HBase使用HDFS作为底层存储系统。因此，如果要使用HBase，前提是首先必须有Hadoop系统。 
 Hadoop的组件之一MapReduce可以直接访问HBase，但是，这不是必须的，因为HBase中最重要的访问方式是原生Java API，而不是MapReduce这样的批量操作方式。下图展示了HBase在Hadoop生态系统中的位置。

五、 架构

从HBase的架构图上可以看出，HBase中的组件包括Client、Zookeeper、HMaster、HRegionServer、HRegion、Store、MemStore、StoreFile、HFile、HLog等，接下来介绍他们的作用。

HBase中的每张表都通过行键按照一定的范围被分割成多个子表（HRegion），默认一个HRegion超过256M就要被分割成两个，这个过程由HRegionServer管理，而HRegion的分配由HMaster管理。

1、  Client
包含访问HBase的接口，并维护cache来加快对HBase的访问。 

2、  zookeeper
HBase依赖Zookeeper，默认情况下HBase管理Zookeeper实例(启动或关闭Zookeeper),Master与RegionServers启动时会向Zookeeper注册。
Zookeeper的作用：
    1.  保证任何时候，集群中只有一个master
    2.  存储所有Region的寻址入口
    3.  实时监控Region server的上线和下线信息。并实时通知给master
    4.  存储HBase的schema和table元数据

3、  HMaster
    1.  为Region server分配region
    2.  负责Region server的负载均衡
    3.  发现失效的Region server并重新分配其上的region。
    4.  HDFS上的垃圾文件回收。
    5.  处理schema更新请求。

4、  HRegionServer
    1.  维护master分配给他的region，处理对这些region的io请求。
    2.  负责切分正在运行过程中变的过大的region。
    注意：client访问hbase上的数据时不需要master的参与，因为数据寻址访问zookeeper和region server，而数据读写访问region server。master仅仅维护table和region的元数据信息，而table的元数据信息保存在zookeeper上，因此master负载很低。

5、  HRegion
table在行的方向上分隔为多个Region。Region是HBase中分布式存储和负载均衡的最小单元，即不同的region可以分别在不同的Region Server上，但同一个Region是不会拆分到多个server上。
Region按大小分隔，每个表一般是只有一个region。随着数据不断插入表，region不断增大，当region的某个列族达到一个阈值（默认256M）时就会分成两个新的region。
    每个region由以下信息标识：
    1.  < 表名,startRowkey,创建时间>
    2.  由目录表(-ROOT-和.META.)记录该region的endRowkey
Region被分配给哪个Region Server是完全动态的，所以需要机制来定位Region具体在哪个region server。 

 HRegion定位
    1.  通过zk里的文件/hbase/rs得到-ROOT-表的位置。-ROOT-表只有一个region。
    2.  通过-ROOT-表查找.META.表的第一个表中相应的region的位置。其实-ROOT-表是.META.表的第一个region；.META.表中的每一个region 
    在-ROOT-表中都是一行记录。
    3.  通过.META.表找到所要的用户表region的位置。用户表中的每个region在.META.表中都是一行记录。
    -ROOT-表永远不会被分隔为多个region，保证了最多需要三次跳转，就能定位到任意的region。client会将查询的位置 信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行6次网络来回，才能定位到正确的region，其中三次用来发现 缓存失效，另外三次用来获取位置信息。

提示：
-ROOT-表：表包含.META.表所在的region列表，该表只有一个Region;Zookeeper中记录了-ROOT-表的location
-META-表：表包含所有的用户空间region列表，以及Region Server的服务器地址

6、  Store
每一个region由一个或多个store组成，至少是一个store，hbase会把一起访问的数据放在一个store里面，即为每个 ColumnFamily建一个store，如果有几个ColumnFamily，也就有几个Store。一个Store由一个memStore和0或者 多个StoreFile组成。 HBase以store的大小来判断是否需要切分region

7、  MemStore
memStore 是放在内存里的。保存修改的数据即keyValues。当memStore的大小达到一个阀值（默认64MB）时，memStore会被flush到文 件，即生成一个快照。目前hbase 会有一个线程来负责memStore的flush操作。

8、  StoreFile
memStore内存中的数据写到文件后就是StoreFile，StoreFile底层是以HFile的格式保存。

9、  HLog
HLog(WAL log)：WAL意为write ahead log，用来做灾难恢复使用，HLog记录数据的所有变更，一旦region server 宕机，就可以从log中进行恢复。

HLog文件就是一个普通的Hadoop Sequence File， Sequence File的value是key时HLogKey对象，其中记录了写入数据的归属信息，除了table和region名字外，还同时包括sequence number和timestamp，timestamp是写入时间，sequence number的起始值为0，或者是最近一次存入文件系统中的sequence number。 Sequence File的value是HBase的KeyValue对象，即对应HFile中的KeyValue。

10、 LogFlusher
前面提到，数据以KeyValue形式到达HRegionServer，将写入WAL之后，写入一个SequenceFile。看过去没问题，但是因为数 据流在写入文件系统时，经常会缓存以提高性能。这样，有些本以为在日志文件中的数据实际在内存中。 
这里提供了一个LogFlusher的类。它调用 HLog.optionalSync(),后者根据 hbase.regionserver.optionallogflushinterval (默认是10秒)，定期调用Hlog.sync()。另外，HLog.doWrite()也会根据 
hbase.regionserver.flushlogentries (默认100秒)定期调用Hlog.sync()。Sync() 本身调用HLog.Writer.sync()，它由SequenceFileLogWriter实现。

11、 LogRoller
Log的大小通过$HBASE_HOME/conf/hbase-site.xml 的 hbase.regionserver.logroll.period 限制，默认是一个小时。所以每60分钟，会打开一个新的log文件。久而久之，会有一大堆的文件需要维护。

首先，LogRoller调用 HLog.rollWriter()，定时滚动日志，之后，利用HLog.cleanOldLogs()可以清除旧的日志。它首先取得存储文件中的最大的 sequence number，之后检查是否存在一个log所有的条目的“sequence number”均低于这个值，如果存在，将删除这个log。 每个region server维护一个HLog，而不是每一个region一个，这样不同region（来自不同的table）的日志会混在一起，这样做的目的是不断追加 单个文件相对于同时写多个文件而言，可以减少磁盘寻址次数，因此可以提高table的写性能。带来麻烦的时，如果一个region server下线，为了恢复其上的region，需要将region server上的log进行拆分，然后分发到其他region server上进行恢复。

六、 数据模型

1.  数据模型 

    HBase是一个类似于BigTable的分布式数据库，它是一个稀疏的长期存储的（存在HDFS上）、多维度的、排序的映射表。这张表的索引是行关键字、列关键字和时间戳。HBase的数据都是字符串，没有类型。

    用户在表格中存储数据，每一行都有一个可排序的主键和任意多的列。由于是稀疏存储，同一张里面的每一行数据都可以有截然不同的列。

    列名字的格式是"<family>:<qualifier>"，都是由字符串组成的，每一张表有一个列族集合，这个集合是固定不变的，只能通过改变表结构来改变。

    但是qulifier值相对于每一行来说都是可以改变的。

    HBase把同一个列族里面的数据存储在同一个目录下，并且HBase的写操作是锁行的，每一行都是一个原子元素，都可以加锁。

    HBase所有数据库的更新都有一个时间戳标记，每个更新都是一个新的版本，HBase会保留一定数量的版本，这个值是可以设定的，客户端可以

    选择获取距离某个时间点最近的版本单元的值，或者一次获取所有版本单元的值。


 2. 概念模型        
    可以将一个表想象成一个大的映射关系，通过行健、行健+时间戳或行键+列（列族：列修饰符），就可以定位特定数据，HBase是稀疏存储数据的，因此某些列可以是空白的

    test表有r1和r2两行数据，并且c1和c2两个列族，在r1中，列族c1有三条数据，列族c2有两条数据；在r2中，列族c1有一条数据，列族c2有一条数据，每一条数据对应的时间戳都用数字来表示，编号越大表示数据越旧，反而表示数据越新。

3.  物理模型
    虽然从概念视图来看每个表格是由很多行组成的，但是在物理存储上面，它是按照列来保存的。

   需要注意的是，在概念视图上面有些列是空白的，这样的列实际上并不会被存储，当请求这些空白的单元格时，会返回null值。如果在查询的时候不提供时间戳，那么会返回距离现在最近的那一个版本的数据，因为在存储的时候，数据会按照时间戳来排序。