HBase-架构原理组件，写数据流程，读数据流程解析

以你之姓@ 2022-11-30 01:19 191阅读 0赞

### 文章目录 ###

*   *  架构原理
     *  写数据流程
     *  读数据流程

## 架构原理 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center]

**1）HDFS**

HDFS 为 HBase 提供最终的底层数据存储服务，同时为 HBase 提供高可用的支持。

**2）Client**

利用 RPC 机制与 Master 和 RegionServer 通信，并维护Meta Cache 来加快对HBase的访问。Client 访问用户数据前需要首先访问 ZooKeeper，找到 hbaes:meta 表的 Region 所在的位置，最后才能找到用户数据的位置去访问，不过 client 端会做 cache 缓存。

**3）Zookeeper**

协调 Master 单点故障问题，实现 Master 主从节点的 Failover（HBase 中可以配置多个备用 Master（只有一个Active），ZooKeeper 负责管理这些 Master ，当 Master 宕机时，通过 ZooKeeper 的 Master Election 机制，从备用 Master 选举一个为Active，保证总有一个 Master 在运行）

*  注： Master 通过监听 ZooKeeper 中的 Ephemeral节点 (默认：`/hbase/rs/*`) 来监控 RegionServer 的加入和宕机。在第一个 Master 连接到 ZooKeeper 时会创建 Ephemeral节点(默认：`/hbasae/master`) 来表示 Active 的 Master，其后加进来的 Master 则监听该 Ephemeral节点。如果当前 Active 的 Master宕机，则该节点消失，因而其他 Master 得到通知，ZooKeeper 会从其他 Master 选举出一个 Master 为 Active，在变为 Active 的 Master 之前，它会在`/hbase/masters/`下创建自己的 Ephemeral节点。

存储 hbaes:meta （元数据信息）表所在的位置，即 hbaes:meta 表在哪台服务器（RegionServer）的哪个 Region 上。

实时监控 RegionServer 的状态，将 RegionServer 的 上线 和 下线 信息实时通知给 Master（RegionServer 会向zookeeper 注册，提供RegionServer 状态信息（是否在线），通过心跳检测机制）

**4）Master**

Master是所有Region Server的管理者，其实现类为HMaster，主要作用如下：

管理 RegionServer 的负载均衡（分配 Region，比如在Region Split时，分配新的 Region，确保每台 RegionServer 的 Region 数量差不多）

管理 RegionServer 中 Region的迁移（发现某 Region server 宕机，会重新分配其上 Rregion，将其负责的Region 迁移到，其他运行的 RegionServer上。

Admin职能：对表Table的操作，创建（create）、删除（delete）、修改（alter） 。实现DDL操作（NameSpace 和 Table的增删改，Column Familiy的增删改等），管理 NameSpace 和 Table的元数据（实际存储在HDFS上）。

权限控制（ACL），监控集群中所有HRegion Server的状态（通过Heartbeat和监听ZooKeeper中的状态）。

**5）Region Server**

Region Server为 Region的管理者，其实现类为HRegionServer，主要作用如下:

维护 Master 分配给他的 Region，处理对这些 Region 的IO请求（对数据的get, put, delete）

读写HDFS，管理 Table 中的数据。

负责 Region 的 split、compact

Client直接通过 RegionServer 读写数据。

*  注：在写数据时，都是先写到 RegionServer 的 WAL 日志中，写入 WAL 成功后，再由 RegionServer 将数据写到 MemStore 中，用户并不直接接触 Region。

**6）Region**

Region 是 HBase中 分布式存储 和 负载均衡 的最小单元，Region 包括完整的行，所以 Region 是以行为单位 表的一个子集。不同的 Region 可以分别在不同的 RegionServer 上。

每个表一开始只有一个 Region，每个 Region 会保存一个表里 某段连续的数据，随着数据不断插 入表，Region不断增大，当增大到一个阀值的时候，Region就会二等分，生成两个新的Region；

Table 中的所有行都按照 RowKsey 的字典序排列，Table 在行的方向上分割为多个 Region，基于 Rowkey 的不同范围分配到不通的 Region 中（Rowkey的范围，第一个Rowkey的起始索引 和 最后一Rowkey的结束索引为空串`" "`，每个Region是前闭后开`[起始索引, 结束索引)` ）

**7）Store**

每一个 Region 由一个或多个 Store 组成，一个store对应一个ColumnFamily（列簇）。一个 Store 由一个 memStore 和（0个或多个）StoreFile组成。 HBase 以 Store 的大小来判断是否需要切分 Region。

**8）MemStore**

是一块内存区域，写缓存(In Memory Sorted Buffer)，由于 HFile 中的数据要求是有序的，所以数据是先存储在 MemStore ，排好序后，等到达刷写时机才会刷写到 HFile，每次刷写都会形成一个新的 HFile。

**9）StoreFile**

保存实际数据的物理文件，StoreFile 以 HFile 的形式存储在HDFS上，数据在每个 StoreFile 中都是有序的。

**10）HFile**

HBase 中 Key-Value 数据的存储格式，HFile 是 Hadoop 的 二进制格式文件，实际上 StoreFile 就是对 HFile 做了轻量级包装，即 StoreFile 底层就是HFile。

**11）HLOG（WAL）**

一个 RegionServer 只有一个 HLOG，数据会先写在一个叫做 Write-Ahead logfile 的文件中，然后再写入 MemStore，HLOG文件会定期滚动生成新HLOG，并删除旧文件中，已经持久化到 StoreFile 中的数据（即新的 HLOG会排除已经落盘的数据，HLOG 主要是针对 MemStore 的数据），所以在系统出现故障的时候，数据可以通过这个日志文件重建。

HLog 文件就是一个普通的 Hadoop Sequence File，Sequence File 的Key是 HLogKey对象，HLogKey中记录了写入数据的归属信息，除了 Table 和 Region 名字外，同时还包括 sequence number 和 timestamp，timestamp是” 写入时间”，sequence number 的起始值为0，或者是最近一次存入文件系 统中 sequence number。

## 写数据流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center 1]  
**写流程**：

1.  Client 向 Zookeeper 发起获取元数据位置的请求，即获取`hbase:meta表`位于哪个RegionServer。
2.  Zookeeper 返回元数据所在位置（在哪个RegionServer的哪个Region里）给Client
3.  Client向元数据所在的 RegionServer 发起读取元数据请求，即读取hbase:meta表。注：Client 只能接触 RegionServer，所有的访问 Region 操作，都是由对应的 RegionServer 来完成。
4.  元数据所在的 RegionServer 会返回元数据信息给 Client
5.  Client 根据元数据信息（hbase:meta表），得知数据该写入哪个RegionServer 的哪个Region中。并将该Table的Region信息，以及meta表的位置信息缓存在客户端的Meta Cache，方便下次访问。
6.  Client 向目标 Region 所在的 RegionServer 发起写入数据的请求
7.  RegionServer 先将数据顺序写入（追加）到WAL，确保 RegionServer 宕机不丢失数据，WAL写入完成之后，再将数据写入MemStore中，数据会在 MemStore 进行排序
8.  最后向客户端发送ack，告知写入完成

## 读数据流程 ##

![在这里插入图片描述][watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center 2]  
**读流程**：

1.  Client 向 Zookeeper 发起获取元数据位置的请求，即获取hbase:meta表位于哪个RegionServer。
2.  Zookeeper 返回元数据所在位置（在哪个RegionServer的哪个Region里）给Client
3.  Client向元数据所在的 RegionServer 发起读取元数据请求，即读取hbase:meta表
4.  元数据所在的 RegionServer 会返回元数据信息给 Client
5.  Client 根据元数据信息（hbase:meta表），得知目标数据位于哪个RegionServer 的哪个Region中。并将该table的region信息以及meta表的位置信息缓存在客户端的meta cache，方便下次访问。
6.  Client 向目标 Region 所在的 RegionServer 发起读取数据的请求
7.  首先从Block Cache中读取数据，若无目标数据，  
    则从MemStore中读取数据，若还是没有目标数据，  
    则再从storeFile中读取数据，首先通过布隆过滤器来判断，当前读取的 RowKey 在哪个 StoreFile 中，再通过 HFile 这种文件格式中的数据索引找到目标数据所在的位置。
    
        Store中StoreFile 个数可能比较多，如何快速找到数据处于哪个storeFile？
         	1、通过布隆过滤器，判断数据可能存在哪些storeFile
         				布隆过滤器特点:  如果判断存在，则不一定存在；
         							   如果判断不存在，则一定不存在
         	2、通过HFile这种文件格式中的数据索引找到数据所在的位置
         				HFile文件： Hfile中包含数据信息，数据的索引信息，数据元数据信。。。
8.  将数据返回给Client

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center]: /images/20221124/b29f196a064e4b09b31e7f6d5f17f8d1.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center 1]: /images/20221124/940532d9760c4724a3f324a608f67d45.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3FxXzMyNzI3MDk1_size_16_color_FFFFFF_t_70_pic_center 2]: /images/20221124/1a88465403e24f7797786de29751f707.png