HBASE简介概述-----看过的人月薪都破万

什么是HBASE

hbase是基于Google BigTable模型开发的，典型的key/value系统。是建立在HBFS之上，提供高可靠性高性能、列存储、可伸缩、实时读写nosql的数据库系统。它是Apache Hadoop生态系统中的重要一员，主要用于海量结构化和半结构化数据存储。
它介于nosql和RDBMS之间，仅能通过主键(row key)和主键的range来检索数据，仅支持单行事务(可通过hive支持来实现多表join等复杂操作)。Hbase查询数据功能很简单，不支持join等复杂操作，不支持复杂的事务（行级的事务） 与hadoop一样，Hbase目标主要依靠横向扩展，通过不断增加廉价的商用服务器，来增加计算和存储能力。

HBASE的特点

大：一个表可以有上十亿行，上百万行

无模式：每行都有一个可排序的主键和任意多的列，列可以根据需要动态的增加，同一张表中不同的行可以有截然不同的列

面向列：面向列(族)的存储和权限控制，列(族)独立检索

稀疏：对于为空(null)的列，并不占用储存空间，因此，表可以设计的非常稀疏。

数据多版本：每个单元中的数据可以有多个版本，默认情况下版本号自动分配，是单元格插入时的时间戳

数据类型单一：HBase中的数据都是字节数组 byte[]

表结构逻辑视图

HBase以表的形式存储数据。表有行和列组成。列划分为若干个列族(column family)

A.一个value可以有多个版本,通过版本号(时间戳来区分)

B.HBASE 中通过rowkey和columns确定的为一个存贮单元称为cell)

C.HBASE 在建立表的时候,不需要指定表中的字段,只需要指定若干个列簇几个

D.插入数据的时候,列簇中可以存储任意多列

E.查询一个具体字段的值的时候,需要指定的坐标是表名–>行键–>列簇(columnFamily):列名–>版本

Hbase中各个角色作用

1. Row Key：row key是用来检索记录的主键，可以是任意字符串，实际应用中长度一般为 10-100bytes)，在hbase内部，row key保存为字节数组，数据按照Row key的字典序(byte order)排序存储。

2. Cell：由{row key, column( =family + label), version} 唯一确定的单元。cell中的数据是没有类型的，全部是字节码形式存贮。

3. Client：包含访问Hbase的接口，并维护cache来加快对Hbase的访问，比如region的位置信息。

4. HMaster：是hbase集群的主节点，可以配置多个，用来实现HA为RegionServer分配region负责RegionServer的负载均衡发现失效的RegionServer并重新分配其上的region

5. RegionServer：Regionserver维护region，处理对这些region的IO请求Regionserver负责切分在运行过程中变得过大的region

6. Region:分布式存储的最小单元。

7. Zookeeper作用:通过选举，保证任何时候，集群中只有一个活着的HMaster，HMaster与RegionServers 启动时会向ZooKeeper注册存贮所有Region的寻址入实时监控Region server的上线和下线信息。并实时通知给HMaster存储HBase的schema和table元数据Zookeeper的引入使得HMaster不再是单点故障

8. HLog(WAL log)：WAL 意为Write ahead log，该机制用于数据的容错和恢复，Hlog记录数据的所有变更,一旦数据修改，就可以从log中进行恢复。

Hbase整体结构

1. Table中的所有行都按照row key的字典序排列。

2. Table 在行的方向上分割为多个Hregion。

3. region按大小分割的(默认10G)，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。

4. Hregion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个regionserver上的。

5. HRegion虽然是负载均衡的最小单元，但并不是物理存储的最小单元。事实上，HRegion由一个或者多个Store组成，每个store保存一个column family。每个Strore又由一个memStore和0至多个StoreFile组成。如上图

Hbase寻址流程

现在假设我们要从Table2里面查询一条RowKey是RK10000的数据。那么我们应该遵循以下步骤：

1. 从.META.表里面查询哪个Region包含这条数据。

2. 获取管理这个Region的RegionServer地址。

3. 连接这个RegionServer, 查到这条数据。 系统如何找到某个row key (或者某个 row key range)所在的regionbigtable使用三层类似B+树的结构来保存region位置。
   第一层： 保存zookeeper里面的文件，它持有root region的位置。

第二层：root region是.META.表的第一个region其中保存了.META.表其它region的位置。通过root region，我们就可以访问.META.表的数据。

第三层： .META.表它是一个特殊的表，保存了hbase中所有数据表的region 位置信息。

说明：
(1) root region永远不会被split，保证了最需要三次跳转，就能定位到任意region 。

(2).META.表每行保存一个region的位置信息，row key 采用表名+表的最后一行编码而成。

(3) 为了加快访问，.META.表的全部region都保存在内存中。

(4) client会将查询过的位置信息保存缓存起来，缓存不会主动失效，因此如果client上的缓存全部失效，则需要进行最多6次网络来回，才能定位到正确的region(其中三次用来发现缓存失效，另外三次用来获取位置信息)。

Hbase读请求过程

（1） 客户端通过zookeeper以及root表和meta表找到目标数据所在的regionserver

（2）联系regionserver查询目标数据

（3）regionserver定位到目标数据所在的region，发出查询请求

（4）region先在memstore中查找，命中则返回

（5）如果在memstore中找不到，则在storefile中扫描（可能会扫描到很多的storefile----bloomfilter布隆过滤器）补充：布隆过滤器参数类型有2种：Row、row+col

Hbase写请求过程

（1）client向region server提交写请求

（2）region server找到目标region

（3）region检查数据是否与schema一致

（4）如果客户端没有指定版本，则获取当前系统时间作为数据版本

（5）将更新写入WAL log

（6）将更新写入Memstore

（7）判断Memstore的是否需要flush为StoreFile文件。

Master工作机制之master上线

master上线master启动进行以下步骤:
（1） 从zookeeper上获取唯一一个代表active master的锁，用来阻止其它master成为活着的master。

（2）扫描zookeeper上的server父节点，获得当前可用的region server列表。

（3）和每个region server通信，获得当前已分配的region和region server的对应关系。

（4）扫描.META.region的集合，计算得到当前还未分配的region，将他们放入待分配region列表。

Master下线

master下线由于master只维护表和region的元数据，而不参与表数据IO的过程，master下线仅导致所有元数据的修改被冻结(无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的合并，唯一例外的是region的split可以正常进行，因为只有region server参与)，表的数据读写还可以正常进行。因此master下线短时间内对整个hbase集群没有影响。