Hbase 基础理论

是一种分布式,可扩展,支持海量数据存储的NOSQL的数据库

一.数据模型

看上去hbase的数据模型和关系的数据库很像的,数据存储只有一张表,有行有列,但是hbase的底层是key-value 这样看hbase 更像一个多维的地图.

1.hbase逻辑结构

2.hbase 物理存储结构

 

3.数据模型

3.1  name space  主要是有hbase和default 两个组成,default是默认的表空间

3.2  region    主要是由rowkey和所有的列族组成.

3.3  time stamp 指的是每条数据 在写入的时候都会有时间戳

4. 基本架构

架构角色:

  (1.Region server 也就是 HRegion server 对数据进行get put delete操作对Region进行 splitRegion compactRegion

   (2.Master  是 Region Server的管理者

  (3.zookeeper 管理元数据 高可用  region server监管 集群配置管理

  (4.hdfs hbase底层 存储服务

5.架构原理

1. StoreFile

 这里存储着实际 中的数据, storeFile 以Hfile的形式在hdfs上存储,每个store会有一个或者多个Hfile,数据在Hfile中都是有序的.
2) memStore 写缓存, 数据在进入Hfile之前都会在MEMstore中排好序.等到一个定程度写到Hfile.

3)  wal 在MenStore 排好序才会写到HFIle中,这一过程记录在Wal中,一旦发生意外,数据可以通过wal 重新建立.

二. hbase 深究

2.1写过程

1.Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。

2.访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。

3.与目标Region Server进行通讯；

4.将数据顺序写入（追加）到WAL；

5.将数据写入对应的MemStore，数据会在MemStore进行排序；

6.向客户端发送ack；

7.等达到MemStore的刷写时机后，将数据刷写到HFile

2.2 Hbase 之MemStore Flush 机制

MemStore刷写时机：
   1)当某个memstroe的大小达到了hbase.hregion.memstore.flush.size（默认值128M），其所在region的所有memstore都会刷写。
当memstore的大小达到
  hbase.hregion.memstore.flush.size（默认值128M）
  hbase.hregion.memstore.block.multiplier（默认值4） 时，会阻止继续往该memstore写数据
 
2)当region server中memstore的总大小达到
 java_heapsize
 hbase.regionserver.global.memstore.size（默认值0.4）
 hbase.regionserver.global.memstore.size.upper.limit（默认值0.95），
 region会按照其所有memstore的大小顺序（由大到小）依次进行刷写。直到region server中所有memstore的总大小减小到hbase.regionserver.global.memstore.size.lower.limit以下.
 当region server中memstore的总大小达到java_heapsize*hbase.regionserver.global.memstore.size（默认值0.4）时，会阻止继续往所有的memstore写数据
3)到达自动刷写的时间，也会触发memstore flush。自动刷新的时间间隔由该属性进行配置hbase.regionserver.optionalcacheflushinterval（默认1小时）。
4)当WAL文件的数量超过hbase.regionserver.max.logs，region会按照时间顺序依次进行刷写，直到WAL文件数量减小到hbase.regionserver.max.log以下（该属性名已经废弃，现无需手动设置，最大值为32）

2.3读过程

1)Client先访问zookeeper，获取hbase:meta表位于哪个Region Server。
2)访问对应的Region Server，获取hbase:meta表，根据读请求的namespace:table/rowkey，查询出目标数据位于哪个Region Server中的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。
3)与目标Region Server进行通讯；
4)分别在Block Cache（读缓存），MemStore和Store File（HFile）中查询目标数据，并将查到的所有数据进行合并。此处所有数据是指同一条数据的不同版本（time stamp）或者不同的类型（Put/Delete）。
5)将从文件中查询到的数据块（Block，HFile数据存储单元，默认大小为64KB）缓存到Block Cache。
6)将合并后的最终结果返回给客户端
 

2.4StoreFile Compaction

由于memstore每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的HFile中，因此查询时需要遍历所有的HFile。为了减少HFile的个数，以及清理掉过期和删除的数据，会进行StoreFile Compaction。
Compaction分为两种，分别是Minor Compaction和Major Compaction。Minor Compaction会将临近的若干个较小的HFile合并成一个较大的HFile，但不会清理过期和删除的数据。Major Compaction会将一个Store下的所有的HFile合并成一个大HFile，并且会清理掉过期和删除的数据

2.5Region Split

默认情况下，每个Table起初只有一个Region，随着数据的不断写入，Region会自动进行拆分。刚拆分时，两个子Region都位于当前的Region Server，但处于负载均衡的考虑，HMaster有可能会将某个Region转移给其他的Region Server。

Region Split时机：

1)当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize，该Region就会进行拆分（0.94版本之前）。

2)当1个region中的某个Store下所有StoreFile的总大小超过Min(R^2 * "hbase.hregion.memstore.flush.size",hbase.hregion.max.filesize")，该Region就会进行拆分，其中R为当前Region Server中属于该Table的个数（0.94版本之后）