1.Hbase 的基本介绍

1. HBase 时建立在hdfs之上的数据库
2. 不支持join等SQL事务等繁杂的操作
3. 支持的数类型：byte[]
4. 依靠横向扩展，一个表可以有上十亿行，上百万列
5. 面向列族存储和权限控制
6. 对于空（null）的列，并不占用存储空间，是一个稀疏表

 2.HBASE的使用场景 （12个字）

1. 海量数据
2. 精确查询
3. 快速返回

3.Hbase 和hadoop之间的关系

    HDFS:

1. 海量数据储存，适合一次扫描大量数据
2. 适合一次写入，多出读取
3. 不适合频繁修改数据

    Hbase

1.  适合一词扫描少量数据
2. 合适多次写入多次读取
3. 支持数据更新
4. 支持删除数据

4.Hbase 与Rdbms 的关系

    RDBMS：

1. 支持SQL查询
2. 支持事务
3. 支持join

    hbase:

1. 不支持SQL查询
2. 不支持事务
3. 不支持join

 5.HBase 详细架构 

      Client：

       访问数据的入口，包含访问hbase的API接口,维护着一些cache来加快对hbase的访问

      Zookeeper：

       1.zookeeper的选举机制保证任何时候，集群中只有一个master

       2.实时监控Region Server的状态，将Region server的上线和下线信息实时通知给Master

       3.存储Hbase的schema

      4.存贮所有Region的寻址入口

      Master：

     1.为Region server分配region

     2.负责region server的负载均衡

     3.发现失效的region server并重新分配其上的region

     4.处理schema（元数据）更新请求

     说明：Hmaster短时间下线，hbase集群依然可用，长时间不行。

      Region server：

      1.Region server维护Master分配给它的region，处理对这些region的IO请求

     2.Region server负责切分在运行过程中变得过大的region

6. Row Key

最大长度是 64KB，完全可以自行设计。Hbase会对表中的数据按照rowkey排序（字典序）

7.列族Column Family

列族是表的schema的一部分，而列不是。（schema包含表名和列族）

每个列都所属于某一个列族。一个列族可以包含多个列。一个列族与列的关系是一对多。

8.时间戳

标记一个数据的不同版本，时间戳可以由hbase(在数据写入时自动 )赋值，hbase支持工程师自己定义时间戳。每个 cell中，不同版本的数据按照时间倒序排序

9.hbase本身提供数据回收机制

1．保存数据的最后n个版本

2．保存最近一段时间内的版本

10. Cell

存储数据的最小单位，由{row key, column( = + ), version} 唯一确定的单元确定一个精确的数据

11.VersionNum

数据的版本号，默认值为系统时间戳。

12. hbase物理存储

1.一个regionserver内部可以有多个region,这多个region可能来自多个表或一个表。一个region只能属于一个 regionserver.

2.一个regionserver只有一个HLog

3.一个region里面可以有多个store

4.一个store里面只有一个memstore

13.rtegion的切分

region按大小分割的(默认10G)。每个表一开始只有一个region，随着数据的增加，一个region逐渐变大，达到 10G，进行分裂，等分成两个region.

14. Memstore与storefile

一个region由多个store组成，每个store包含一个列族的所有数据 Store包括位于内存的memstore和位于硬盘的 storefile

客户端检索数据时，先在memstore找，找不到再找storefile

15.HLog(WAL log)

每个Region Server维护一个Hlog,而不是每个Region一个.

Hlog的切分机制

1.当数据写入hlog以后，hbase发生异常。关闭当前的hlog文件

2.当日志的大小达到HDFS数据块的0.95倍的时候，关闭当前日志，生成新的日志

3.每隔一小时生成一个新的日志文件

16.读请求过程

meta表是hbase系统自带的一个表。里面存储了hbase用户表的元信息。

元信息为meta表内记录一行数据是用户表一个region的start key 到endkey的范围。

meta表存储在regionserver里。 具体存储在哪个regionserver里？zookeeper知道。

过程:

1.客户端到zookeeper询问meta表在哪

2.客户端到meta所在的节点（regionserver）读取meta表的数据

3.客户端找到region 获取region和regionserver的对应关系，直接到regionserver读取region数据

17.HBase的特征

1.海量存储:Hbase适合存储PB级别的海量数据，在几十到百毫秒内返回数据。

2.列式存储:这里的列式存储其实说的是列族存储列族理论上可以很多，但实际上建议不要超过6个

3.极易扩展:处理能力（RegionServer）的扩展，是基于存储的扩展（HDFS）

4.高并发:这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多

5.稀疏:在列数据为空的情况下，是不会占用存储空间的。

18. 写请求过程

1.Client先访问zookeeper，找到Meta表，并获取Meta表元数据。确定当前将要写入的数据所对应的HRegion和 HRegionServer服务器。

2.Client向该HRegionServer服务器发起写入数据请求。

3.Client先把数据写入到HLog，以防止数据丢失，然后将数据写入到Memstore。  

4.Memstore达到阈值，会把Memstore中的数据flush到Storefile中

5.当Storefile越来越多，达到一定数量时，会触发Compact合并操作，将多个小文件合并成一个大文件。

6.Storefile越来越大，Region也会越来越大，达到阈值后，会触发Split操作，变成两个文件。

说明：hbasez 支持数据修改（伪修改），实际上是相同rowkey数据的添加。hbase只显示最后一次的添加

19. region的分配过程

前提：一个region只能分配给一个region server

1.master记录了当前有哪些可用的region server。以及当前哪些region分配给了哪些region server，哪些region还没有分配。

2.当需要分配的新的region，并且有一个region server上有可用空间时，master就给这个region server发送一个装载请求，把region分配给这个region server。

3.region server得到请求后，就开始对此region提供服务。

20. region server上线

前提：master使用zookeeper来跟踪region server状态。

1.当某个region server启动时，首先在zookeeper上的/hbase/rs目录下建立代表自己的znode。

2.master订阅了/hbase/rs目录上的变更消息，当/hbase/rs目录下的文件出现新增或删除操作时，master可以得到来自zookeeper的实时通知。因此一旦region server上线，master能马上得到消息

21.region server下线

前提：master使用zookeeper来跟踪region server状态。

1.当region server下线时，它和zookeeper的会话断开。

2.zookeeper而自动释放代表这台server的文件上的独占锁（znode）

3.zookeeper将变化发送给master

4.master 将挂掉的region server的region分配给其它还活着的regionserver

22.Hmaster的上线

前提：hbase集群中可以设置多个Hmaster，真正对外提供服务的只有一个

1.从zookeeper上获取唯一 一个代表active master的锁，用来阻止其它master成为真正的master。

2.扫描zookeeper上的/hbase/rs节点，获得当前可用的region server列表。

3.master和每个region server通信，获得当前已分配的region和region server的对应关系。 4.master扫描.META.表，计算得到当前还未分配的region，将他们放入待分配region列表。

23.Hmaster下线后的影响

master只维护表和region的元数据，不参与表数据IO的过程，所以master下线短时间内对整个hbase集群没有影响。表的数据读写还可以正常进行。

无法创建删除表，无法修改表的schema，无法进行region的负载均衡，无法处理region 上下线，无法进行region的 合并（region的split可以正常进行） 当hmaster下线后，启动Zookeeper的选举机制，选出新的Hmaster,新的Hmaster上线，执行上线流程。

24.flush机制

全局的memstore的flush机制默认为堆总大小（多个memstore 多个region）的40%，超过该大小会触发flush到磁盘的操作，会阻塞客户端读写，flush将所有的memstore全部flush.

单个的memstore默认为数据达到128M或1h或者数据为堆大小 0.95倍将会flush. memstore默认将会先提前flush 5M.(先flush一小部分，等后面数据达到阈值在flush后 面的数据) 这样会比一次flush效率高

hbase不建议配置过多列族：过多的列族会消耗大量的内存，同时数据在flush时消耗磁盘IO. 一个regionserver续写操作可用堆内存的80%，读取占用40% ，写入占用40%。这两个参数直接影响hbase读写性能。

25.compact机制

默认3个小的storeFile文件达到三个，合并成大的Storefile文件。

26.split机制

默认一个HFile达到10Gb的时候就会进行切分

27.hbase预分区的优点

1.增加数据读写效率:数据分布在多台regionserver节点

2.负载均衡，防止数据倾斜:当数据时离散的发送时，预分区可以解决数据倾斜

3.方便集群调度region: 分布在多个节点便于调度

4.优化Map数量

28.rowKey的获取方式

1.通过rowkey直接查找

2.通过startkey endkey 范围查找

3.全表扫描

29.rowkey散列原则

建议将rowkey的高位(左边)作为散列字段， 低位（右边）放时间字段，这样将提高数据均衡分布在每个 RegionServer，以实现负载均衡的几率。

若不按照此原则：

让时间戳作为高位，数据将按照时间的顺序进行存储会引发热点问题

30.rowkey散列原则

建议将rowkey的高位(左边)作为散列字段， 低位（右边）放时间字段，这样将提高数据均衡分布在每个 RegionServer，以实现负载均衡的几率。

若不按照此原则：

让时间戳作为高位，数据将按照时间的顺序进行存储会引发热点问题

31.什么是热点问题

当有一点时间业务数据爆炸增长时，这个阶段的数据将存储在少数的节点上。

32.如何解决热点问题

原则：将分散的数据，放在rowkey的高位

1.哈希（随机数）:将哈希值放在高位

2.反转:反转固定长度或者数字格式的数据（时间戳反转、手机号反转，订单号反转）

3.加盐:本质时是加随机数，并且放在高位。