Hbase原理、架构、作业流程讲解【小二讲堂】

本篇博文是小二精心总结，面试重点。
小二课堂：https://blog.csdn.net/Mirror_w

一、Hbase概述

Hbase是一种hadoop数据库，是一种稀疏的、分布式的、持久化的、多维有序映射的NoSql性数据库。它数基于行键、列键和时间戳建立索引，是一个可以随机访问的存储和检索数据的平台，HBase不限制储存的数据的种类，允许动态地、灵活的数据模型，不强调数据之间的关系。Hase被设计成在一个服务器集群上运行，可以相应的横向扩展。
HBase是一个分布式的、面向列的开源数据库，它不同于一般的关系型数据库，是一个适合于非结构化数据存储的数据库，另一个不同的是Hbase是基于列的而不是基于行的模式。Hbase的数据模型是Google三篇论文的实现。用户的储存数据行在一个表里，一个数据行拥有一个可选择的键和任意数量的列，一个或多个列组成的一个ColumnFamily列族，一个Family的列位于一个File中，易于缓存数据。表是稀疏存储的，因此用户可以给定行定义的不同的列。在Hbase中数据按主键排序，同时表按照主键划分为多个Region。

1.Hbase优势

HBase是一种构建在HDFS之上的分布式、面向列的存储系统。在需要实时读写、随机访问超大规模数据集时，可以使用HBase。
尽管已经有许多数据存储和访问的策略和实现方法，但事实上大多数解决方案，特别是一些关系类型的，在构建时并没有考虑超大规模和分布式的特点。许多商家通过复制和分区的方法来扩充数据库使其突破单个节点的界限，但这些功能通常都是事后增加的，安装和维护都和复杂。同时，也会影响RDBMS的特定功能，例如联接、复杂的查询、触发器、视图和外键约束这些操作在大型的RDBMS上的代价相当高，甚至根本无法实现。
HBase从另一个角度处理伸缩性问题。它通过线性方式从下到上增加节点来进行扩展。HBase不是关系型数据库，也不支持SQL，但是它有自己的特长，这是RDBMS不能处理的，HBase巧妙地将大而稀疏的表放在商用的服务器集群上。
HBase 是Google Bigtable 的开源实现，与Google Bigtable 利用GFS作为其文件存储系统类似， HBase 利用Hadoop HDFS 作为其文件存储系统；Google 运行MapReduce 来处理Bigtable中的海量数据， HBase 同样利用Hadoop MapReduce来处理HBase中的海量数据；Google Bigtable 利用Chubby作为协同服务， HBase 利用Zookeeper作为对应。

• 1)大：一个表可以有上亿行，上百万列。
• 2)面向列：面向列表（簇）的存储和权限控制，列（簇）独立检索。
• 3)稀疏：对于为空（NULL）的列，并不占用存储空间，因此，表可以设计的非常稀疏。
• 4)无模式：每一行都有一个可以排序的主键和任意多的列，列可以根据需要动态增加，同一张表中不同的行可以有截然不同的列。
• 5)数据多版本：每个单元中的数据可以有多个版本，默认情况下，版本号自动分配，版本号就是单元格插入时的时间戳。
• 6)数据类型单一：HBase中的数据都是字符串，没有类型。
• 7.)速度快：充分利用了内存、使用了LSM树，有自己的缓存机制，溢写文件是顺序溢写磁盘
• 8.)可以实现高性能的并发读写操作

2.Hbase和关系型数据库的区别–面试

• a.数据量大不影响查询效率
  首先在传统的关系型数据库中，对着数据量的增大，数据的查询速度会越来越慢，一张有上百个字段的数据表有千万级别的数据量，查询效率是非常低的。而Hbase是一个分布式的数据存储系统，它的建立是基于HDFS分布式文件系统的，所以说存储大量的数据时它的特点了。
• b.随意添加列
  Hbase是面向列的存储的，其储存结构是一种key-value的方式，因此在数据有新的字段需求的是可以随意添加。而传统型的关系型数据库则只能通过关联表的方式，通过外键和索引，来处理新的字段。
• c.数据结构
  传统的关系型数据库读写数据是要考虑主外键和索引因素的，随着数据量的剧增，响应速度也是梯度下降的。而Hbase则不会有这样的问题，其写数据的性能和表的大小无关。并且由于key-value的储存格式，其读取数据的速度几乎是不会下降的。
• d.扩容
  Hbase的扩容只需要在集群上简单的增加节点。其新增节点的代价很小，并且由于节点很多，某个节点的宕机不会对整个集群造造成巨大的- 影响。
• e.索引的支持
  传统的关系型数据库则会随着数据量的增加，出现索引的膨胀问题。
• f:自动分区
  Hbase中的数据表会自动分裂，存入合适的RegionServer中。而传统型的数据库则需要手动操作来实现分区。

3.HBase的数据模型

• 1)rowkey 行键
  相当于Mysql中的主键，唯一表示的记录，rowkey是字典序，rowkey的长度最长是64k,但是一般推荐10-100个字节。
• 2)column family 列族
  列族，一组列的集合，列族必须作为表的schema定义给出，列族是存储的最小单元。
• 3)qulifier 列
  hbase中的列是可以随意的插入的，表的定义之后没有列，列是在插入数据时也把列也插入了，列必须属于某一个列族
• 4)timetamp 时间戳
  时间戳，64为整数，精度是毫秒，其版本号的作用，一个Cell中存在着多个版本的数据。时间戳可以自己定义，但一般不推荐
• 5)cell
  是存储数据的最小单元。cell中的数据是没有类型的，存放的都是字节数组。存储的是key-value格式的数据：
  K:rowkey+column family+qulifier+timestamp
  V:vlaue

二、Hbase架构

1.Client

Clinet使用HBase的RPC机制与Master和HRegionServer进行通信，对于管理类的操作，Client与HMaster进行RPC通信，对于数据的读写，Client要与HRegionServer进行通信

2.zookeeper

Zookeeper中除了储存-ROOT-表的地址和HMaster的地址，HRegionServer也会把自己的信息储存到Zookeeper中，使得HMaster可以随时感知HRegionServer的健康状态，此外Zookeeper也避免了HMaster单点故障问题。

3.HMaster

HMaster没有单点问题，Hbase中可以启动多个HMaster，通过zookeeper的选举机制可以保证一个集群中只有一个是HMaster是active状态的。HMaster主要负责Table和HRegion的管理工作,例如

• 1)管理用户对Table的增删改查操作。
• 2)管理HRegion的负载均衡，调整Region的分布
• 3)在Region Split中，负责新的Region的分配
• 4)在HRegion Server宕机后负责失效的Server上的Region迁移

4.HRegionServer

负责响应用户的IO请求，向HDFS文件系统中读写数据，是HBase最核心的模块。HRegionServer内部管理了一系列的HRegion对象，每个HRegion对应着Table中的一个Region,HRegion中有许多HStore组成，每个HStore对应着Table中的一个列族的存储。

5.HRegion$Table

当Table随着记录数不断增加而变大后，会逐渐分裂成许多的splits,成为region,一个region是由startkey,endkey表示的，不同的region会被Master分配响应的RegionServer进行管理,HBase中两张特殊的表，-ROOT-,和.META
.META:记录用户表的Region信息，.META可以有多个region
-ROOT-:记录了.META表的Region信息，，-ROOT-只有一个Region
Clinet访问用户数据之前首先访问zookeeper，然后访问-ROOT-表，接着-META-表，最后才能找到用户数据取访问，中间会有多次网络操作，不过client端会进行cache缓存。

6.HStore

HStore由两部分组成，一部分是MemStore，另一部分是SoreFile,MemStore是一个内存缓冲区，数据写入时，首先会将数据写到这个缓冲区中，当MemStore中的数据写满时，就会通过flush形成一个SoreFile(底层实现是HFile),当StoreFile文件增多达到一定的阈值时，会触发compact合并操作， 将多个StoreFile合并成一个SoreFile,在合并过程中会进行版本的和文件的删除。因此可以看出HBase只有增加数据。所有的更新和删除都是在后续的compact过程中进行了。这就使得用的写操作只要进入内存就可以立即返回，保证了高效性。当SoteFile文件的大小达到一定的阈值时，会触发split操作，将对应的Region切分成两个子Region，然后将新切分的Regioin分配到相应的Region Server上，这样将原来一个region承担的压力分担到了两个region上。

7.HLog

每个HRegionServer都有一个HLog对象，HLog是一个实现WAL(Write AHead Log)的类，在每次用户将数据写入MemStore的同时，也会写一份数据到HLog中，HLog文件会定期更新的，达到一定阈值后会删除旧的文件（旧的文件：已持久化到StoreFile中的数据），当HRegionServer意外宕机时，HMaster会通过zookeeper感知到，HMaster会首先处理里遗留的HLog文件，将其中不同的HLog数据进行拆分。并放到相应的Region目录下，然后将失效的region重新分配，当RegionServer在加载分配到的region时，会发现有HLog处理，因此会重新读取Hlog中对应的数据到MemStore中，然后flush到storeFile完成数据恢复。

注意:
1.StoreFile实际上是HFile的封装。HFile最后是储存在HDFS上的。
2.blockcache是缓存，有大小限制，会有淘汰机制，默认将最早的数据淘汰。

三、HBase的作业流程

1.写入数据流程

a.首先clinet向zookeeper发送请求
b.Clinet提交请求,从zookeeper中拿到储存数据的region坐在的节点位置信息。
c.Client和HRegionServer开始建立RPC通信，开始向HRegion中写数据。
d.首先数据向MemStore和Hlog中写入数据，当写入MemStore的数据达到一定的阈值之后,开始flush到StoreFile中，然后落写成一个个HFile小文件，当StoreFile文件个数达到一定的阈值时，就会触发compact合并成一个大的StoreFile文件。落写成的HFile磁盘文件最后最终储存到了HDFS分布式文件系统中。
e.当MemStore中的数据flush完毕的时候，就会删除对应的文件。当一次请求数据文件上传后，当HLog文件中的数据为空时，则表示这次请求数据上传成功。

2.读数据流程

1)、client向zk发送请求
2)、从zk中拿到metadata的存储节点
3)、去存储matadata的节点获取对应region所在的位置
4)、访问对应的region写数据
5)、首先会向wal中写数据，写成功之后才会存储到memstore
6)、当memstore中的数据量达到阈值之后，进行溢写，溢写成storefile
7)、store file是一个个的小文件，会进行合并（minor,major）
8)、store file是对hfile的封装，hfile是实际存储再hdfs上的数据文件

后续还有HBase的性能优化！！！请关注小二讲堂，或者前往小二讲堂

大数据经典文章：https://blog.csdn.net/Mirror_w/article/details/89190381