HBase存储及读写原理介绍

一、HBase介绍及其特点

        HBase是一个开源的非关系型分布式数据库，它参考了谷歌的BigTable建模，实现的编程语言为Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。因此，它可以容错地存储海量稀疏的数据。

        HBase是一个高可靠、高性能、面向列、可伸缩的分布式数据库，是谷歌BigTable的开源实现，主要用来存储非结构化和半结构化的松散数据。HBase的目标是处理非常庞大的表，可以通过水平扩展的方式，利用廉价计算机集群处理由超过10亿行数据和数百万列元素组成的数据表。

        Hadoop HDFS 是无法处理高速随机写入和读取，也无法在不重写文件的情况下对文件进行修改。HBase 正好解决了 HDFS 的缺点，因为它使用优化的方式快速随机写入和读取。此外，随着数据呈指数增长，关系数据库无法提供更好性能去处理海量的数据。HBase提供可扩展性和分区，以实现高效的存储和检索。

 

1.1、海量存储

       Hbase适合存储PB级别的海量数据，在PB级别的数据以及采用廉价PC存储的情况下，能在几十到百毫秒内返回数据。这与Hbase的极易扩展性息息相关。正式因为Hbase良好的扩展性，才为海量数据的存储提供了便利。

1.2、列式存储

       这里的列式存储其实说的是列族存储，Hbase是根据列族来存储数据的。列族下面可以有非常多的列，列族在创建表的时候就必须指定。

1.3、极易扩展

       Hbase的扩展性主要体现在两个方面，一个是基于上层处理能力（RegionServer）的扩展，一个是基于存储的扩展（HDFS）。通过横向添加RegionSever的机器，进行水平扩展，提升Hbase上层的处理能力，提升Hbsae服务更多Region的能力。

1.4、高并发

       由于目前大部分使用Hbase的架构，都是采用的廉价PC，因此单个IO的延迟其实并不小，一般在几十到上百ms之间。这里说的高并发，主要是在并发的情况下，Hbase的单个IO延迟下降并不多。能获得高并发、低延迟的服务。

1.5、稀疏

       稀疏主要是针对Hbase列的灵活性，在列族中，你可以指定任意多的列，在列数据为空的情况下，是不会占用存储空间的。

二、HBase存储

2.1 HBase数据模型

        2.1.1 与传统关系型数据库对比

         下图是针对Hbase和关系型数据库的基本的一个比较：

1）数据类型：关系数据库采用关系模型，具有丰富的数据类型和存储方式， HBase则采用了更加简单的数据模型，它把数据存储为未经解释的字符串。

2）数据操作：关系数据库中包含了丰富的操作，其中会涉及复杂的多表连接。 HBase操作则不存在复杂的表与表之间的关系，只有简单的插入、查询、删除、 清空等，因为HBase在设计上就避免了复杂的表和表之间的关系。

3）存储模式：关系数据库是基于行模式存储的。HBase是基于列存储的，每个列族都由几个文件保存，不同列族的文件是分离的。

4）数据索引：关系数据库通常可以针对不同列构建复杂的多个索引，以提高数 据访问性能。HBase只有一个索引——行键，通过巧妙的设计，HBase中的所有访 问方法，或者通过行键访问，或者通过行键扫描，从而使得整个系统不会慢下来 。

5）数据维护：在关系数据库中，更新操作会用最新的当前值去替换记录中原来 的旧值，旧值被覆盖后就不会存在。而在HBase中执行更新操作时，并不会删除数 据旧的版本，而是生成一个新的版本，旧有的版本仍然保留。

6）可伸缩性：关系数据库很难实现横向扩展，纵向扩展的空间也比较有限。相反，HBase和BigTable这些分布式数据库就是为了实现灵活的水平扩展而开发的， 能够轻易地通过在集群中增加或者减少硬件数量来实现性能的伸缩。

      　　Table（表格）

　　　　• 一个HBase表格由多行组成。

　　　　Row Key:

　　　　• 决定一行数据的唯一标识

　　　　• RowKey是按照字典顺序排序的。

　　　　• Row key最多只能存储64k的字节数据。

　　　　Column Family列族（CF1、CF2、CF3） & qualifier列：

　　　　• HBase表中的每个列都归属于某个列族，列族必须作为表模式(schema) 定义的一部分预先给出。如create ‘test’, ‘course’；

　　　　• 列名以列族作为前缀，每个“列族”都可以有多个列成员(column，每个列族中可以存放几千~上千万个列)；如 CF1:q1, CF2:qw,新的列族成员（列）可以随后按需、动态加入，Family下面可以有多个                                 Qualifier，所以可以简单的理解为，HBase中的列是二级列，也就是说Family是第一级列，Qualifier是第二级列。两个是父子关系。

　　　　• 权限控制、存储以及调优都是在列族层面进行的；

　　　　• HBase把同一列族里面的数据存储在同一目录下，由几个文件保存。

　　　　• 目前为止HBase的列族能能够很好处理最多不超过3个列族。

　　　　Timestamp时间戳：

　　　　• 在HBase每个cell存储单元对同一份数据有多个版本，根据唯一的时间 戳来区分每个版本之间的差异，不同版本的数据按照时间倒序排序，最新的数据版本排在最前面。

　　　　• 时间戳的类型是64位整型。

　　　　• 时间戳可以由HBase(在数据写入时自动)赋值，此时时间戳是精确到毫 秒的当前系统时间。

　　　　• 时间戳也可以由客户显式赋值，如果应用程序要避免数据版本冲突， 就必须自己生成具有唯一性的时间戳。

　　　　Cell单元格：

　　　　• 由行和列的坐标交叉决定；

　　　　• 单元格是有版本的（由时间戳来作为版本）；

　　　　• 单元格的内容是未解析的字节数组（Byte[]），cell中的数据是没有类型的，全部是字节码形式存贮。

　　　　• 由{row key，column(= +)，version}唯一确定的单元。

2.2 HBase 的架构设计

Client

• 包含访问HBase的接口并维护cache来加快对HBase的访问

Zookeeper

• 保证任何时候，集群中只有一个master。HBase 会启动多个 HMaster，并通过 ZooKeeper 选举出一个主服务器

• 存贮所有Region的寻址入口。

• 实时监控Region server的上线和下线信息。并实时通知Master

• 存储HBase的schema和table元数据

 Master

• 为Region server分配region

• 负责Region server的负载均衡

• 发现失效的Region server并重新分配其上的region

• 管理用户对table的增删改操作

RegionServer

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

• Region服务器负责存储和维护分配给自己的Region，处理来自客户端的读写请求， 客户端并不是直接从Master主服务器上读取数据，而是在获得Region的存储位置信息后，直接从Region服务器上读取数据，      客户端并不依赖Master，而是通过Zookeeper来获得Region位置信息，大多数客户 端甚至从来不和Master通信，这种设计方式使得Master负载很小。

HLog(WAL log)：

      • HStore在系统正常工作的前提下是没有问题的，但是在分布式系统环境中，无法避免系统出错或者宕机，因此一旦HRegionServer意外退出，MemStore中的内存数据将会丢失，这就需要引入HLog了。每个HRegionServer中都有一个HLog对象，HLog是一个实现Write Ahead Log的类，在每次用户操作写入MemStore的同时，也会写一份数据到HLog文件中，HLog文件定期会滚动出新的，并删除旧的文件（已持久化到StoreFile中的数据）。当HRegionServer意外终止后，HMaster会通过Zookeeper感知到，HMaster首先会处理遗留的 HLog文件，将其中不同Region的Log数据进行拆分，分别放到相应region的目录下，然后再将失效的region重新分配，领取 到这些region的HRegionServer在Load Region的过程中，会发现有历史HLog需要处理，因此会Replay HLog中的数据到MemStore中，然后flush到StoreFiles，完成数据恢复。

Region

• HBase自动把表水平划分成多个区域(region)，每个region会保存一个表里面某段连续的数据；每个表一开始只有一个region，随着数据不断插 入表，region不断增大，当增大到一个阀值的时候，region就会等分会 两个新的region（裂变）；

• 当table中的行不断增多，就会有越来越多的region。这样一张完整的表 被保存在多个Regionserver上。

Memstore 与 storefile

• 一个region由多个store组成，一个store对应一个CF（列族）

• store包括位于内存中的memstore和位于磁盘的storefile写操作先写入 memstore

• HStore存储是HBase存储的核心了，其中由两部分组成，一部分是MemStore，一部分是StoreFiles。MemStore是Sorted Memory Buffer，用户写入的数据首先会放入MemStore，当MemStore满了以后会Flush成一个StoreFile（底层实现是HFile），当StoreFile文件数量增长到一定阈值，会触发Compact合并操作，将多个StoreFiles合并成一个StoreFile，合并过程中会进行版本合并和数据删除，因此可以看出HBase其实只有增加数据，所有的更新和删除操作都是在后续的compact过程中进行的，这使得用户的写操作只要进入内存中就可以立即返回，保证了HBase I/O的高性能。当StoreFiles Compact后，会逐步形成越来越大的StoreFile，当单个StoreFile大小超过一定阈值后，会触发Split操作，同时把当前Region Split成2个Region，父Region会下线，新Split出的2个孩子Region会被HMaster分配到相应的HRegionServer上，使得原先1个Region的压力得以分流到2个Region上。

三、Hbase的数据读写原理

3.1 Hbase寻址原理

3.1.1 -ROOT-表和.META.表的介绍

       HBase用-ROOT-表记录.META.表的位置信息(即元数据信息)，而.META.表记录了用户表Region的位置信息。为了定位.META.表中各个Region的位置信息，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-Root-表的位置信息。所以客户端Client要先访问ZK获取-ROOT-表的位置，然后访问-ROOT-表获取.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置。

3.2 -ROOT-表结构

       HBase的用-ROOT-表来记录.META.的Region信息，就和.META.记录用户表的Region信息一模一样。-ROOT-只会有一个Region。这么一来Client端就需要先去访问-ROOT-表。所以需要知道管理-ROOT-表的RegionServer的地址。这个地址被存在ZooKeeper中。默认的路径是：/hbase/root-region-server

3.3 META.表结构

3.4 两个表的关系

        HBase的所有Region元数据被存储在.META.表中，随着Region的增多，.META.表中的数据也会增大，并分裂成多个新的Region。为了定位.META.表中各个Region的位置，把.META.表中所有Region的元数据保存在-ROOT-表中，最后由Zookeeper记录-ROOT-表的位置信息。所有客户端访问用户数据前，需要首先访问Zookeeper获得-ROOT-的位置，然后访问-ROOT-表获得.META.表的位置，最后根据.META.表中的信息确定用户数据存放的位置，如下图所示。

 

        -ROOT-表永远不会被分割，它只有一个Region，这样可以保证最多只需要三次跳转就可以定位任意一个Region。为了加快访问速度，.META.表的所有Region全部保存在内存中。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到数据，则询问相关.META.表的Region服务器，试图获取数据的位置，如果还是失败，则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过ZooKeeper重新定位Region的信息。所以如果客户端上的缓存全部是失效，则需要进行6次网络来回，才能定位到正确的Region。

3.5 读流程

1. Client访问Zookeeper，查找-ROOT-表，获取.META.表信息。
2. 从.META.表查找，获取存放目标数据的Region信息，从而找到对应的RegionServer。
3. 通过RegionServer获取需要查找的数据。
4. Regionserver的内存分为MemStore和BlockCache两部分，MemStore主要用于写数据，BlockCache主要用于读数据。读请求先到MemStore中查数据，查不到就到BlockCache中查，再查不到就会到StoreFile上读，并把读的结果放入BlockCache。
读取过程：client–>Zookeeper–>-ROOT-表–>META表–>RegionServer–>Region–>client

 3.6  写流程

       1.Client通过Zookeeper调度获取表的元数据信息；

　　2.Cilent通过rpc协议与RegionServer交互，通过-ROOT-表与.META.表找到对应的对应的Region；

　　3.将数据写入HLog日志中，如出现意外可以同通过HLog恢复信息；

　　4.将数据写入Region的MemStore中，当MemStore达到阈值开始溢写，将其中的数据Flush成一个StoreFile；

　　5.MemStore不断生成新的StoreFile，当StoreFile的数量到达阈值后会出发Compact合并操作，将多个StoreFile合并成一个StoreFile；

　　6.StoreFile文件会不断增大，当达到阈值后会出发Split操作，把当前的Region且分为两个新的Region。父Region会下线，两个子Region会被HMaster分配到相应的RegionServer。

        可以看出HBase只有增添数据，所有的更新和删除操作都是在后续的Compact历程中举行的，使得用户的写操作只要进入内存就可以立刻返回，实现了HBase I/O的高性能。

 3.7 缓存的刷新

        •系统会周期性地把MemStore缓存里的内容刷写到磁盘的StoreFile文 件中，清空缓存，并在Hlog里面写入一个标记

•每次刷写都生成一个新的StoreFile文件，因此，每个Store包含多个 StoreFile文件
•每个Region服务器都有一个自己的HLog 文件，每次启动都检查该文 件，确认最近一次执行缓存刷新操作之后是否发生新的写入操作；如果发现更新，则先写入MemStore，再刷写到StoreFile，最后删除旧的Hlog文件，开始为用户提供服务

 

参考文章：

http://archive.apache.org/dist/hbase/ hbase各版本

https://www.jianshu.com/p/e3b764871c68

https://blog.csdn.net/yyl424525/article/details/77505749

https://baike.baidu.com/item/HBase/7670213?fr=aladdin

https://www.jianshu.com/p/d27b31808c8a hbase shell操作