hbase原理详细解析

一、hbase架构

hbase是主从架构的设计模式，一般有一主多从或多主多从，zookeeper负责协调hbase集群主要是负责一些元数据的存储，主指的是hmaster，从指的是hregionserver

1、系统架构

ps：图片来源网络，若如侵权请联系删除

1.1各个client职责

ZooKeeper 职责

1）ZooKeeper为 HBase 提供 Failover 机制，选举master，避免单点 master 单点故障问题
2）存储所有 Region 的寻址入口:-root-表在哪台服务器上。-root-这张表的位置信息
3）实时监控 RegionServer的状态，将 RegionServer 的上线和下线信息实时通知给 Master
4）存储 HBase 的 schema，包括有哪些table，每个 table 有哪些 column family

HMaster 职责

1）为 RegionServer 分配 region
2）负责 RegionServer 的负载均衡
3）发现失效的 RegionServer 并重新分配其上的 region
4）HDFS 上的垃圾文件(hbase)回收
5）处理 schema 更新请求(表的创建，删除，修改，列簇的增加等等)

HRegionServer 职责

1）RegionServer 维护 Master 分配给它的 region，处理对这些 region 的 IO 请求
2）RegionServer 负责 Split 在运行过程中变得过大的 region，负责 Compact 操作

1.2hbase中的几个核心概念

1.2.1region

hbase中是以表结构在行的方向上划分的一个数据单元，一个region存储的是一个表中一定行键范围的数据，一个表在行的方向上进行划分会分成多个region
region是hbase进行分布式存储的最小单位
region是hbase各个节点进行均衡的最小单位
但是region不是物理存储的最小单位

在进行分布式存储的时候，一个region不可进行分割，只会被存储到hbase的一个节点上，hbase的一个hreginserver上会存储多个region
建表的时候，每一个表都有一个region
每一个region都会有一个编号，如：23b0608d5cb71109f73dea547ae13402.
每一个region的数据最终存储在hdfs上hbase-site.xml中配置的路径中
/user/hbase/hbasedata/data/default（namespace）/user_info(表名)/23b0608d5cb71109f73dea547ae13402（region编号）/base_info（列族）

随着这个表的数据的不断增大，当前这个region的数据量也会越来越大，当数据量足够大的时候就会进行region的切分 split
1个region—>2个region(对半切)这时候就会重新分配这两个region的存储位置，老的region就会下线

region进行分裂的标准：
<property>
	<name>hbase.hregion.max.filesize</name>
	<value>10737418240</value>
	<description>
	Maximum HStoreFile size. If any one of a column families' 
	HStoreFiles has grown to exceed this value, the hosting HRegion is 
	split in two.
	</description>
</property>

region中只要有一个列族大文件总大小超过10G，当前的这个region就会进行分裂

1.2.2Store

一个Store对应的是一个列族
最终对应一个物理存储
一个regionserver对应多个region —>每一个region 有几个列族最终对应几个Store

1.2.3memstore

每一个store 都是有一个memstore 和 0或多个 storefile组成
每一个store内部的一个内存存储
写入hbase的数据的时候，先写入到每一个region的内存中

memstore刷数据到磁盘的阈值配置如下：

<property>
	<name>hbase.hregion.memstore.flush.size</name>
	<value>134217728</value>
	<description>
	Memstore will be flushed to disk if size of the memstore
	exceeds this number of bytes.  Value is checked by a thread that runs 
	every hbase.server.thread.wakefrequency.</description>
</property>
	
	每一个region对应的缓存的大小128M就会flush到磁盘上

1.2.4storefile

每一个region中memstore flush到磁盘的文件称为storefile

1.2.5hfile

HFile就是hdfs file 的简称
storefile的数据最终存储在hdfs上，转换为hdfs对应的数据格式，这个数据就是hfile

1.2.6Hlog/WAL

write-ahead-log写前日志/预写日志
写数据 先写入 WAL中再写入memstore
一个regionserver维护一个WAL而不是一个region维护一个WAL，如果一个region维护一个，就会造成regionserver的压力很大，一个regionserver维护一个WAL文件，当region切分的时候，WAL是要进行拆分的

	WAL的作用是为了防止数据丢失

二、hbase的寻址机制

hbase中无论进行读取数据（get scan）还是数据的写入(put)，都要先确定region的位置才能到对应的region上进行写入或读取数据

1、hbase0.96 之前的版本

1）表原始数据直接存储在每一个region中
一个表中的数据量很大的时候有可能一个表被切分多个region，有可能存在多个regionserver上
hbase中是按照rowkey字典顺序排序，每一个region对应一定的rk范围，这就必然需要记录每一个region的存储位置
2）.meta表
元数据表是用来存储原始数据的，.meta表记录的region和regionserver的对应关系
3）-root-表
这个表是终极索引表，不会再进行region分裂，不管多大都只会有一个
一个region只会存储在一个regionserver上
这个表的存储位置就存储在zookeeper中

寻址机制：

1）先去访问zookeeper中获取-root- 存储的 regionserver的位置以及region的编号
2）到对应的regionserver上去访问-root-表的region，返回对应的.meta表对应的region的位置以及region编号
3）到对应的regionserver上访问对应的.meta表的region获取最终的数据的存储的region的编号及位置
4）获取真正的数据

2、hbase0.96 之后的版本

1）表原始数据直接存储在每一个region中
一个表中数据量很大有可能一个表被切分多个region
有可能存在多个regionserver上 hbase中按照rk字典顺序排序
每一个region对应一定的rk范围
需要记录每一个region的存储位置
2）.meta表
元数据表是存储原始数据的，记录region和 regionserver的对应关系
这个.meta 只有一个不会再进行分裂
3）.meta表的存储regionserver的位置以及编号存在zookeeper中
zk中存储的是.meta表的存储路径

新版本寻址变的简单了，索引表取消了-root-只有.meta表

1）客户端–> zookeeper 获取 .meta表对应的region位置
2)到对应的reginserver上访问对应的region，获取需要的rowkey所在原始表的region位置及编号
3）访问原始表上的region

三、hbase的写数据流程

1）客户端经过3次往返最终确定需要插入数据的region存储的regionserver的位置以及region编号
2）客户端开始访问对应的regionserver上的region准备写入数据
3）写入数据之前检查数据结构是否符合标准，符合标准才开始写入数据
4）客户端先将数据写入 WAL 中，就是操作日志
5）客户端将数据写入到对应的region的对应store中的memstore中（有点绕，但是希望大家能多看几遍理解一下，可以对照着系统架构中的图）
6）memstore 达到溢写阀值开始flush到本地磁盘形成storefile，最终每一个store中可能存在多个 storefile文件
7）storefile文件要进行合并，多个storefile文件合并为一个storefile文件
，默认达到3个就开始触发合并，最终一个region中的一个store最终出来一个文件
这里面分为minor compact和major compact
minor compact就是对多个storefile文件进行物理累计，执行删除命令的时候hbase底层并没有被实际删除，而是对数据打了一个标签，不会真正的删除
major compact是主要合并，针对一个store(列簇)中所有的storefile进行合并，会进行标签数据的删除
8）将合并好的storefile文件进行转换为hdfs的格式形成hfile文件

四、hbase的读数据流程

1）客户端通过 zookeeper 以及-root-表和.meta.表找到目标数据所在的 regionserver(就是数据 所在的 region 的主机地址)
2）联系 regionserver 查询目标数据
3）regionserver 定位到目标数据所在的 region，发出查询请求
4）region 先在 memstore 中查找，命中则返回
5）如果在 memstore 中找不到，则在 storefile 中扫描(可能会扫描到很多的 storefile----BloomFilter)

五、RegionServer 工作机制

1、region 分配

任何时刻，一个 region 只能分配给一个 region server。master 记录了当前有哪些可用的 region server。以及当前哪些 region 分配给了哪些 region server，哪些 region 还没有分配。当需要 分配的新的 region，并且有一个 region server 上有可用空间时，master 就给这个 region server 发送一个装载请求，把 region 分配给这个 region server。region server 得到请求后，就开始 对此 region 提供服务。

2、region server 上线

master 使用 zookeeper 来跟踪 region server 状态。当某个 region server 启动时，会首先在 zookeeper 上的 server 目录下建立代表自己的 znode。由于 master 订阅了 server 目录上的变 更消息，当 server 目录下的文件出现新增或删除操作时，master 可以得到来自 zookeeper 的 实时通知。因此一旦 region server 上线，master 能马上得到消息。

3、region server 下线

当 region server 下线时，它和 zookeeper 的会话断开，zookeeper 而自动释放代表这台 server 的文件上的独占锁。master 就可以确定:
1、region server 和 zookeeper 之间的网络断开了。
2、region server 挂了。
无论哪种情况，region server 都无法继续为它的 region 提供服务了，此时 master 会删除 server 目录下代表这台 region server 的 znode 数据，并将这台 region server 的 region 分配给其它还活着的 region server。

六、Master 工作机制

1、master 上线

master 启动进行以下步骤:
a、从 zookeeper 上获取唯一一个代表 active master 的锁，用来阻止其它 master 成为 master。
b、扫描 zookeeper 上的 server 父节点，获得当前可用的 region server 列表。
c、和每个 region server 通信，获得当前已分配的 region 和 region server 的对应关系。
d、扫描.META.region 的集合，计算得到当前还未分配的 region，将他们放入待分配 region 列表。

2、master 下线

由于 master 只维护表和 region 的元数据，而不参与表数据 IO 的过程，master 下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的 schema，无法进行 region 的负载均衡，无法处理 region 上下线，无法进行 region 的合并，唯一例外的是 region 的 split 可以正常进行，因为只有 region server 参与)，表的数据读写还可以正常进行。因此 master 下 线短时间内对整个 hbase 集群没有影响。
从上线过程可以看到，master 保存的信息全是可以冗余信息(都可以从系统其它地方 收集到或者计算出来)
因此，一般 hbase 集群中总是有一个 master 在提供服务，还有一个以上的 master 在等 待时机抢占它的位置。