HBase详解

HBase

是什么

面向列的支持复杂数据结构的nosql分布式数据库，依赖Zookeeper和HDFS。
可以实时的随机访问超大规模的数据集

我们先来看一下它的数据模型

首先可以看到他啊是有行和列组成的，每一行有一个有序的rowkey，行中的列被分为列族，列族中间还有字段，字段的值中还有时间戳。所以它要定位到一个数据需要四个维度的信息，这里称他为四维定位吧，普通的RDBMS只需要知道表和字段就可以知道值，而HBASE需要知道rowkey + CF + col + timestamp 才能定位到数据，那么设计这么复杂有什么好处呢？
下面我们来看一下它到底能解决哪些问题。

---

我们先来看一下RDBMS从一个单机版本到数据量巨大的时候的一个发展过程

1. 服务提供访问，数据量较小
2. 服务开始受欢迎，数据库有大量的读操作，此时会添加缓存缓解数据库压力
3. 服务变的多样化，写的请求越来越多，服务器压力非常大，此时会购买服务器来缓解压力
4. 用户呈现井喷式发展数据库已经扛不住压力了，此时需要反规范化优化查询语句，读写分离，分库分表等等一系列操作
   确实这样解决了大部分问题，但是此时RDBMS系统已经非常复杂了，不管是后期维护还是新业务的开发都比较困难，而且当服务器出现问题会造成服务的瘫痪对现在的企业来说是不可接受的

那么HBASE的出现解决了什么问题呢？

• 首先它本身是分布式的，横向的扩展非常方便，而且不需要非常昂贵的服务器
• Hbase会自动负载均衡，自动分区不需要人手动管理
• Hbase的rowkey是排序的查询效率也非常高

所以Hbase天生就是为了超大数据集的访问和管理服务的

---

先放一张Hbase的基本架构图在来详细的说一下它的组件的功能

如上图所示：HBAS由一个Hmaster节点管理多个HRegionServer组成的并且依赖Zookeeper和HDFS

组件介绍

• Hmaster[可配置多个且消耗资源少没有单点问题]
  • 管理分配Region，并做Region的负载均衡
  • RegionServer出现故障时负责Region的转移
  • 实现DDL操作(HBaseAdmin实例化)
  • acl权限控制
• RegionServer
  • 管理Region
  • 为Client提供读写的操作
  • 操作HDFS数据[上传HFiles,合并HDFS文件]
• HLog
  • 存储到Hdfs的数据（持久化数据）后，会生成新的Log，当当前HRegionServer中WAL的大小超过了hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量
    会再次触发flush到hdfs的操作
• Region
  • 将表以rowkey切割的实例
  • 从HMaster的角度，每个HRegion都纪录了它的StartKey和EndKey（第一个HRegion的StartKey为空，最后一个HRegion的EndKey为空），由于RowKey是排序的，因而Client可以通过HMaster快速的定位每个RowKey在哪个HRegion中
    • Store [ColFamily的逻辑划分]
      • MemStore(16k):用来写的数据内存块，超过阀值会添加到某个队列中，队列会按顺序生成新的HFile
      • LRUBlockCache:用来存储最近读的数据
      • HFile:MemStore生成的数据文件[有固定的格式]

依赖组件介绍

• zookeeper
  • 与RegionSever保持心跳，存储节点状态信息和节点信息（Hmaster/RegionServer），regionserver下线是会通知HMaster
  • 存储-Root-或是-meta-表的位置信息
• HDFS
  • 存储数据,可能与regionserver不在同一个节点，做Major compaction时会将数据移动过来做数据本地化。

hbase：meta表

它是hbase内部的特殊表，它维护着当前集群上所有区域的列表。它的键为：表名：区域起始行：区域创建时间：hash值
如table1,xxx,321312331,9das9dsad9.。
因为rowkey是排序的所以只要找到第一个键大于或者等于要查询的键。

Hbase读数据流程

1. 首先去zookeeper上拿到meta表所在位置的信息，老版本需要拿到root表的信息位置，拿到表后会进行缓存
2. 根据root表的信息拿到meta表的位置信息，缓存该信息
3. 根据meta表获取Region所在位置信息，缓存key所在region位置的信息
4. 进入到Region所在RegionServer，首先会读取MemoryStore内存中的数据，因为这个内存只负责写，它里面存储了最近写入的数据（LRU），如未读取到则进入下一步，否则返回。
5. 未读取到时会读取BlockStore内存中的数据。这块区域存储这用户最近读取的数据（LRU），读取到则返回，未读取到进入下一步
6. 读取HFile的数据，如果读取到后会先将该数据写入BlockStore的内存中，然后返回结果数据

Hbase写入流程

1. 首先向zookeeper请求节点信息
2. 取得节点信息后，首先会向RegionServer中的WAL（Hlog）中写入操作信息和数据
3. 根据tablename和rowkey找到应该写入的region，然后找到ColFamily中的Memstore，然后写入数据
4. Hlog和MemStore都写入成功则返回成功

HFile的溢写

• 当memoryStore存满时默认16k，会将这个memestore提交到队列中，每个Memstore都会溢写成HFile文件
• 当RegionServer空闲时会自动合并小文件并删除旧文件

触发memoryStore flush到Hdfs的条件

• 当一个Region中MemStore大小[所有HFiles]超过hbase.hregion.memstore.flush.size的大小，默认128MB，会将这个region中的
  数据flush到hdfs上
• 当RegionSever上所有的MemStore[所有HFiles]大小超过hbase.regionserver.global.memstore.upperLimit的大小，默认40％的内存使用量
  当前所有的Region会flush到HDFS上。flush顺序为MemStore的大小
• 当WAL[HLog]的大小超过hbase.regionserver.hlog.blocksize * hbase.regionserver.max.logs的数量，当前所有的Region会flush到
  hdfs上，flush按照时间顺序

HBase的Region split[根据rowkey切割],负载均衡

当一个region到达Hbase.hregion.max.filesiez(默认10G)，在当前的regionserver上创建两个新的Region，完成后原来的region下线，新的region会向Hmaster注册
出于负载均衡的考虑两个Region可能会被分到不同的RegionServer上。但是数据（datanode）可能在别的节点，当下次major时
会将数据移动过来（数据本地化）

HBase的Compaction [会产生大量的IO操作，网络IO，单集群空闲时才会进行]

• minor compaction
  • 选取小的Hfile合并
• major compaction [可以手动触发]
  • 将一个regionserver所有的Hfile合并生成一个Hfile溢写到磁盘并flush到hdfs然后删除旧数据
  • 会删除标记为删除的数据或达到最大版本的数据

灾备问题

• Hmaster 节点下线
  读写可以正常工作，不能负载均衡，数据在同一个RegionSever，会导致集群瘫痪
• RegionServer 节点下线
  RegionServer和zookeeper有心跳机制，当节点下线后，zookeeper可以感知到，然后他会通知HMaster，
  HMaster将他所有的Region分配到别的节点并将Hlog拆分到所在节点
• Hbase灾备过程复杂且恢复较慢

最后给一些常用的命令行命令吧

create 'test','cf' // 创建表和列族
describe 'test' // 表结构
put 'test','row2','cf:name', 'xiaoming'  // 插入数据
scan 'test' // 查询数据
get 'test'. 'row2' // 查询列族数据
disable 'test' // 删除或者变更表的设置前使用
enable 'test'
drop 'test' // 删除表
deleteall 'test','row' // 删除某个列族全部数据
delete 'test','row','cf:name' // 删除某个列族的某一列数据
count 'test' // 统计行数,统计rowkey个数

---

好了这次的Hbase介绍就到这结束了，感谢打击看我的文章。最后说一句HBase是一个设计的非常好，且非常复杂的分布式数据库，想要继续深入的了解的话还要自己耐下心来看源码。