Hbase 原理

Posted 2021-04-19 大数据

大 数 据

专注于前沿大数据案例资讯

介绍Hbase之前先谈谈HDFS的优缺点，以方便大家从整体架构方面了解其优越性。

      HDFS是为了处理大型数据集分析任务时，主要是为达到高的数据吞吐量而设计的，这就要求以高延迟作为代价。对于那些有低延时要求的应用程序，Hbase是一个更好的选择。通过上层数据管理项目来尽可能地弥补这个不足。在性能上有很大提升，它的口号就是 goes real time。使用缓存或多 master 设计可以降低 client 的数据请求压力，以减少延时。还有就是对 HDFS 系统内部的修改，这就得权衡大吞吐量与低延时了，HDFS 不是万能的银弹。

     接下来开始Hbase之旅：

1.Habse简介

    Hbase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用Hbase技术可在廉价PC Serve 上搭建起大规模结构化存储集群。

    Hbase的目标是存储并处理大型的数据，更具体来说是仅需使用普通的硬件配置，就能够处理 由成千上万的行和列组成的大型数据。

    Hbase是GoogleBigTable开源实现，但是有很多不同之处，比如：Google BigTable利用GFS作为其文件存储系统，Hbase利用Hadoop HDFS作为其文件存储系统；Google利用MapReduce处理Bigtable海量数据；Hbase利用hadoop MapReduce处理Hbase中海量数据；Google BigTable利用Chubby作为协同服务，Hbase利用Zookeeper作为对应。

     上图描述Ecosystem中的各层系统，其中Hbase位于结构化存储层，Hadoop HDFS为Hbase提供高可靠性的存储支持Hadoop Mapreduce为Hbase提供高性能的计算能力，Zookeeper为Hbase提供了稳定的服务和failover机制。

     此外，Pig和Hive还为Hbase提供了 高层语言支持，是的在Hbase上机型统计处理变得非常简单。Sqoop则为Hbase提供了方便的RDBMS的导入功能，使得传统数据库数据向Hbase中迁移变得非常方便。

    另外，Hbase存储的是松散型数据，具体来说，HBase 存储的数据介于映射（key/value） 和关系型数据之间。进一步讲，HBase 存储的数据可以理解为一种 key 和 value 的映射关系， 但又不是简简单单的映射关系。除此之外它还有许多其他的特性。HBase 存储的数据从逻辑 上来看就像一张很大的表，并且它的数据列可以根据需要动态增加。除此之外，每个 cell（由行和列所确定的位置）中的数据又可以具有多个版本（通过时间戳来区别）。

2.Hbase体系结构

         HBase 的服务器体系结构遵从简单的主从服务器架构，它由 HRegin 服务器（HRegion Server）群和 HBase Master 服务器（HBase Master Server）构成。HBase Master 服务器负 责管理所有的HRegion服务器，而HBase中所有的服务器都是通过 ZooKeeper来进行协调， 并处理 HBase 服务器运行期间可能遇到的错误。HBase Master Server 本身并不存储 HBase 中的任何数据，HBase 逻辑上的表可能会被划分成多个 HRegion，然后存储到 HRegion Server 群中。HBase Master Server 中存储的是从数据到 HRegion Server 的映射。因此，HBase 体系 结构如图  所示。

2.1 client

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

2.2 Zookeeper

2.3 HMaster

     每台 HRegion Server 都会 HMaster 通信，HMaster 的主要任务就是要告诉每台 HRegion Server 它要维护那些 HRegion。 当一台新的 HRegion Server 登录到 HMaster 时，HMaster 会告诉它等待分配数据。而当 一台 HRegionServer 死机时，HMaster 会把它负责的 HRegion 标记为未分配，然后再把它们分配到 其他 HRegion Server 中。 HMaster 没有单点问题（SPFO），HBase 中可以启动多个 HMaster，通过 Zookeeper 的 Master Election 机制保证总有一个 Master 运行，HMaster 在功能上主要负责 Table 和 Region 的管理工作：  管理用户对 Table 的增、删、改、查操作；  管理 HRegion Server 的负载均衡，调整 Region 分布；  在 Region Split 后，负责新 Region 的分配；  在 HRegion Server 停机后，负责失效 HRegion Server 上的 Regions 迁移。

2.4 HRegion

       当表的大小超过设置值的时候，HBase 会自动地将表划分为不同的区域，每个区域包含 所有行的一个子集。对用户来说，每个表是一堆数据的集合，靠主键来区分。从物理上来说， 一张表被拆分成了多块，每一块就是一个 HRegion。我们用表名+开始/结束主键，来区分每 一个 HRegion，一个 HRegion 会保存一个表里面某段连续的数据，从开始主键到结束主键， 一张完整的表格是保存在多个 HRegion 上面。

 上图表示当 Table 随着记录数不断增加而变大后，会逐渐分裂成多份 splits，成为 regions， 一个 region 由[startkey,endkey]表示，不同的 region 会被 Master 分配给相应的 RegionServer 进行管理。

2.5  HRegion Server

          所有的数据库数据一般是保存在 Hadoop HDFS 分布式文件系统上面，用户通过一系列 HRegion Server 获取这些数据，一台机器上面一般只运行一个 HRegion Server，且每一个区 段的 HRegion 也只会被一个 HRegion Server 维护。下面是 HRegion Server 数据存储关系图。

                                                         HRegion Server 数据存储关系

        HRegion Server 主要负责响应用户 I/O 请求，向 HDFS 文件系统中读写数据，是 HBase 中最核心的模块。 HRegion Server 内部管理了一系列 HRegion 对象，每个 HRegion 对应了 Table 中的一 个 Region，HRegion 中由多个 HStore 组成。每个 HStore 对应了 Table 中的一个 Column Family 的存储，可以看出每个 Column Family 其实就是一个集中的存储单元，因此最好将 具备共同 IO 特性的 column 放在一个 Column Family 中，这样最高效。 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 上。 下图描述了 Compaction 和 Split 的过程。

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

2.6 HBase 存储格式

HBase 中的所有数据文件都存储在 Hadoop HDFS 文件系统上，主要包括上述提出的两

种文件类型： 

  HFile，   HBase中KeyValue数据的存储格式， HFile 是 Hadoop的二进制格式文件，

实际上StoreFile 就是对 HFile 做了轻量级包装，即StoreFile底层就是HFile。

  HLog File，HBase 中WAL（Write Ahead Log） 的存储格式，物理上是 Hadoop的

Sequence File。

1）HFile详细描述 

下图是HFile的存储格式： 

首先HFile文件是不定长的，长度固定的只有其中的两块：Trailer和 File Info。正如图

中所示的，Trailer 中有指针指向其他数据块的起始点。File Info 中记录了文件的一些 Meta

信息，例如：AVG_KEY_LEN，AVG_VALUE_LEN，LAST_KEY，COMPARATOR，

MAX_SEQ_ID_KEY 等。Data Index和 Meta Index 块记录了每个Data块和 Meta块的起始

点。 

Data Block是HBase I/O 的基本单元，为了提高效率，HRegion Server中有基于LRU 的

Block Cache机制。每个Data块的大小可以在创建一个 Table的时候通过参数指定，大号的

Block有利于顺序Scan，小号Block 利于随机查询。 每个Data块除了开头的 Magic以外就

是一个个 KeyValue 对拼接而成，Magic 内容就是一些随机数字，目的是防止数据损坏。后

面会详细介绍每个KeyValue 对的内部构造。 

HFile里面的每个 KeyValue对就是一个简单的 byte数组。但是这个byte数组里面包含

了很多项，并且有固定的结构。我们来看看里面的具体结构： 

          开始是两个固定长度的数值，分别表示Key的长度和Value的长度。紧接着是 Key，开

始是固定长度的数值，表示 RowKey  的长度，紧接着是RowKey，然后是固定长度的数值，

表示 Family 的长度，然后是 Family，接着是 Qualifier，然后是两个固定长度的数值，表示

Time Stamp和Key Type（Put/Delete）。Value部分没有这么复杂的结构，就是纯粹的二进制

数据了。 

  2）HLogFile详细描述 

其实HLog文件就是一个普通的Hadoop Sequence File， Sequence File  的Key是HLogKey

对象，HLogKey 中记录了写入数据的归属信息，除了 table 和 region 名字外，同时还包括 

sequence number和 timestamp，timestamp 是“写入时间”，sequence number的起始值为0，

或者是最近一次存入文件系统中sequence number。 

HLog Sequece File 的Value是HBase 的 KeyValue 对象，即对应HFile 中的KeyValue，

可参见上文描述。下图中示意了HLog 文件的结构：

 2.7ROOT表和META表

用户表的Regions元数据被存储在.META.表中，随着 Region 的增多，.META.表中的数

据也会增大，并分裂成多个 Regions。为了定位.META.表中各个Regions的位置，把.META.

表中所有 Regions 的元数据保存在-ROOT-表中，最后由 ZooKeeper 记录-ROOT-表的位置

信息。所有客户端访问用户数据前，需要首先访问ZooKeeper获得-ROOT-的位置，然后访

问-ROOT-表获得.META.表的位置， 最后根据.META.表中的信息确定用户数据存放的位置

 -ROOT-表永远不会被分割，它只有一个 Region，这样可以保证最多需要三次跳转就可

以定位任意一个 Region。为了加快访问速度，.META.表的 Regions 全部保存在内存中，如

果.META.表中的每一行在内存中大约占 1KB，且每个 Region 限制为 128MB，那么上图所

示的三层结构可以保存的Regions数目为：（128MB/1KB）*（128/1KB）=234

个。客户端会将查询过的位置信息缓存起来，且缓存不会主动失效。如果客户端根据缓存信息还访问不到

数据，则询问只有相关.META.表的 Region 服务器，试图获取数据的位置，如果还是失败，

则询问-ROOT-表相关的.META.表在哪里。最后，如果前面的信息全部失效，则通过

ZooKeeper 重新定位 Region 的信息。所以如果客户端上的缓存全部是失效，则需要进行 6

次网络来回，才能定位到正确的 Region。 

2.8 MapReduce On Hbase

在 HBase系统上运行批处理运算，最方便和实用的模型依然是 MapReduce，如下图

HBase Table 和Region 的关系，比较类似 HDFS File 和Block 的关系，HBase提供了配

套的 TableInputFormat 和 TableOutputFormat API，可以方便的将 HBase Table 作为 Hadoop 

MapReduce 的 Source 和 Sink，对于 MapReduce Job 应用开发人员来说，基本不需要关注HBase系统自身的细节

数据工匠                         专注  专业   聚焦