HBase系列（三）、读写原理，Flush刷写，HFile Compact合并，Region Split切分

比眉伴天荒 2022-12-05 15:15 126阅读 0赞

**目录**

写原理

读原理

Flush流程

HFile合并流程

Region拆分流程

数据删除时间

--------------------

**HBase系列：**

*  [HBase系列（一）、数据模型][HBase] 
 *  [HBase系列（二）、架构原理][HBase 1]

--------------------

# 写原理 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70][]

**客户端请求HBase写请求（PUT,DELETE）流程如下：**

1.  Client 先访问ZK中的*/hbase/meta-region-server *这个Znode，获取 hbase:meta 表所在的RegionServer；
2.  ZK返回META表所在的RS01信息；
3.  Client 访问META所在的RS01，查询hbase:meta；
4.  RS01将HBase元数据信息meta返回给客户端；
5.  Client 将得到的元数据信息进行缓存，之后再有读取请求时可以免去步骤1~5节约时间和资源；
6.  Client 向目标表所在的RS02发送写请求（PUT/DELETE）；
7.  RS02将数据顺序追加到WAL（HLog）内；
8.  RS02将数据写入对应的Region内的MemStore，数据会在MemStore 进行排序；
9.  RS02向Client 返回应答信息完成写操作；
10. 当满足Flush策略时，memstore内的数据会被刷写至HFile内；

# 读原理 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 1][]

**客户端请求HBase读请求（GET）流程如下：** 前面1~5步骤和写请求一样。

1.  Client 先访问ZK中的*/hbase/meta-region-server *这个Znode，获取 hbase:meta 表所在的RegionServer；
2.  ZK返回META表所在的RS01信息；
3.  Client 访问META所在的RS01，查询hbase:meta；
4.  RS01将HBase元数据信息meta返回给客户端；
5.  Client 将得到的元数据信息进行缓存，之后再有读取请求时可以免去步骤1~5节约时间和资源；
6.  Client 向目标表所在的RS02发送读请求（GET）；
7.  从BlockCache（块缓存），MemStore 和 StoreFile（HFile）中查询目标数据，然后根据RowKey和时间戳进行数据合并；
8.  将从StoreFile（HFile）中读到的数据缓存到BlockCache内供下次查询时使用，免去再次读取文件的磁盘IO消耗；
9.  将合并后的结果返回给客户端；

> **注意**：
> 
>  *  这里并不是先读内存，如果内存没有该数据再读磁盘，而是同时查询内存（BlockCache，MemStore）以及磁盘（StoreFile）。这样做的原因是当相同的rowkey在StoreFile文件内的数据时间戳大于MemStore中的时间戳时，如果先读MemStore的话会给客户端返回一个旧的数据，因此需要同时读内存和磁盘里的数据，然后根据rowkey为主键，以timestamp为版本进行数据合并；
>  *  同时，在读磁盘的时候会将磁盘中的HFile缓存到BlockCache内，这样的话在下一次访问该HFile时就可以先到BlockCache中拿了，如果BlockCache内没有该文件，再去StoreFile中取。这里不必担心万一缓存到BlockCache之后又修改了该rowkey的数据会不会与BlockCache内的数据不一致，因为当数据被修改之后再次读取时：
>     
>      *  如果在此期间没有触发flush，该数据会在MemStore内，下次读取数据时会将BlockCache和MemStore中的该rowkey的数据进行合并；
>      *  如果在此期间触发了flush，新的数据会在StoreFile中另一个新的HFile内，此时客户端再次请求读该RowKey的数据时会同时访问BlockCache内的包含旧版本数据的HFile以及StoreFile中的新HFile进行数据合并，然后会再将新的HFile缓存至BlockCache；
>  *  也即是说每次读HBase时，如果该数据不在内存中，都会产生一次磁盘IO，而写数据是直接追加写WAL和内存，因此HBase是写比读更快。

# Flush流程 #

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 2][]

上面多次提到了**Flush刷写机制**，表示的就是将内存中的MemStore数据持久化到HDFS内，即可以避免内存压力过大又可以保证数据安全，我们知道一个Region内包含多个列族，即在同一个Region内的每个Store表示了不同的列族，而每次Flush都会将MemStore持久化到HDFS内的一个HFile中，因此一个Store的数据最终会落到很多HFile中。

MemStore触发Flush刷写的条件如下，基本上就是按时间和容量：

1.  当Region内某个MemStore 的大小达到了参数（ hbase.hregion.memstore.flush.size）的值（默认值 128M），该Region内所有 MemStore 都会刷写；
2.  当MemStore 的大小达到了公式 \[hbase.hregion.memstore.flush.size（默认128MB） \* hbase.hregion.memstore.block.multiplier（默认4）\] 时，会阻止继续往该MemStore中写数据；
3.  当 RegionServer 中 MemStore 的总大小达到公式\[java\_heapsize \* hbase.regionserver.global.memstore.size（默认值 0.4）\*hbase.regionserver.global.memstore.size.lower.limit（默认值 0.95）\] 时，Region会按照其所有MemStore 的大小顺序（由大到小）依次进行刷写。直到 该RegionServer 中所有 MemStore 的总大小减小到上述值以下。
4.  当 RegionServer 中 MemStore 的总大小达到公式\[java\_heapsize \* hbase.regionserver.global.memstore.size（默认值 0.4）\] 时，会阻止继续往该RegionServer 中所有MemStore中写数据；
5.  通过配置参数（hbase.regionserver.optionalcacheflushinterval）进行自动刷写（默认 1 小时）；
6.  当 WAL 文件的数量超过最大数量 hbase.regionserver.max.logs，region 会按照时间顺序依次进行刷写，直到 WAL 文件数量减小到 hbase.regionserver.max.log 以下（该属性名已经废弃，现无需手动设置，默认值为 32）。

# HFile合并流程 #

由于MemStore 每次刷写都会生成一个新的HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的 HFile 中，因此查询时需要遍历很多 HFile文件。为了减少 HFile 的个数，以及清理掉过期和删除的数据，HBase会对StoreFile 进行**Compaction（合并）**。

**Compaction 分为两种**：

*  **Minor Compaction**：将临近的若干个较小的 HFile 合并成一个较大的 HFile，但不会清理过期和删除的数据；minor的过程一般较快，而且IO相对较低。当HFile数量达到参数（minFilesToCompact，默认3个）最低标准时，此命令才会触发，否则忽略本次操作。当待合并的HFile大小超过参数（maxCompactSize）时会将多的文件过滤掉不进行合并。
 *  **Major Compaction**：将一个 Store 下的所有的 HFile 合并成一个大 HFile，并且会清理掉过期和删除的数据；由于此合并策略影响读写性能，因此一般在生产环境中，都会禁用major自动合并操作（参数hbase.hregion.majorcompaction设为0，默认是7天），只在空闲的时段手动或定时执行；

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 3][]

HBase会将队列中的HFile 按照文件年龄排序（older to younger），Minor Compaction总是从older HFile 开始选择，然后将选择出来的HFiles进行Minor Compaction：

1.  如果该文件小于hbase.hstore.compaction.min.size（为memestoreFlushSize）则一定会被添加到合并队列中。
2.  如果该文件大于hbase.hstore.compaction.max.size（Long.MAX\_VALUE）则一定会被排除，这个值很大，一般不会有。
3.  如果该文件的大小 小于它后面hbase.hstore.compaction.max（默认为10） 个HFile 的大小之和乘以一个ratio（配置项是hbase.hstore.compaction.ratio，默认为1.2），则该HFile 也将加入到minor compaction 中。如果他后面不足10个文件，那么也就是取他后面几个文件总和\*ratio。

**相关参数**：

<table> 
 <thead> 
  <tr> 
   <th>参数名</th> 
   <th>配置项</th> 
   <th> <p>默认值</p> </th> 
   <th>含义</th> 
  </tr> 
 </thead> 
 <tbody> 
  <tr> 
   <td>minFileToCompact</td> 
   <td>hbase.hstore.compactionThreshold</td> 
   <td>3</td> 
   <td>最低合并HFile数量</td> 
  </tr> 
  <tr> 
   <td>maxFileToCompact</td> 
   <td>hbase.hstore.compaction.max</td> 
   <td>10</td> 
   <td>最大合并HFile数量</td> 
  </tr> 
  <tr> 
   <td>minCompactSize</td> 
   <td>hbase.hstore.compaction.min.size</td> 
   <td>memstoreFlushSize</td> 
   <td>最小合并HFile文件大小</td> 
  </tr> 
  <tr> 
   <td>maxCompactSize</td> 
   <td>hbase.hstore.compaction.max.size</td> 
   <td>Long.MAX_VALUE</td> 
   <td>最大合并HFile文件大小</td> 
  </tr> 
  <tr> 
   <td>majorCompaction</td> 
   <td>hbase.hregion.majorcompaction</td> 
   <td>7天</td> 
   <td> <p>自动触发Major 间隔时间</p> </td> 
  </tr> 
 </tbody> 
</table>

# Region拆分流程 #

默认情况下，每个 Table 起初只有一个 Region，随着数据的不断写入，Region 会越来越大然后自动进行**拆分（Split）**。刚拆分时，两个子 Region 都位于当前的 RegionServer，但出于负载均衡的考虑，HMaster 有可能会将某个 Region 转移给其他的 RegionServer。

**Region 拆分时机**：

1.  当1个region中的某个Store下所有StoreFile的总大小超过hbase.hregion.max.filesize（默认10GB），该 Region 就会进行拆分（0.94 版本之前）。
2.  当1个region 中的某个 Store 下所有 StoreFile 的总大小超过公式Min(R^2 \* "hbase.hregion.memstore.flush.size(默认128MB)",hbase.hregion.max.filesize(默认10GB)")，该 Region 就会进行拆分，其中 R 为当前 RegionServer 中属于该 Table 的Region个数（0.94 版本之后）。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 4][]

可以看出，在新版之后，Region的拆分条件会默认从128MB不断的变大一直到10GB，这样就会导致某个表的不同Region内的数据不均衡的情况，因此在实际应用中都会提前设置预分区以及RowKey优化，避免因自动拆分导致的数据倾斜的情况。

# 数据删除时间 #

当HBase中执行PUT修改相同RowKey的数据或者执行DELETE删除RowKey的数据时，我们可以通过命令查看到历史版本，那么什么时候这些过期数据和删除数据才会被删除呢？

其实失效数据在Flush和Compact都会被删除，但它们实现的地方不一样：

*  **Flush刷写时**：
    
     *  Flush将MemStore内的数据进行合并然后去除小于该列族设置的VERSION号以前的数据，将剩余数据持久化到HFile；
     *  当执行DELETE时，Flush操作不会删掉MemStore里的该删除标记记录，只会删掉MemStore内该RowKey的在该删除标记操作的timestamp之前的操作，原因是可能在之前已持久化到HFile物理文件中也有该RowKey记录的历史版本，如果把内存里的删除标记也删除的话，再次查询就会将物理文件中的历史版本查出来，这样就不对了，因此Flush不会删除MemStore内的删除标记记录。
 *  **Compact合并时**：
    
     *  Compact命令会真正将内存和磁盘上的文件进行merge，去除小于该列族设置的VERSION号以前的数据，将剩余数据合并为一个新的HFile；

![202009110229166.png][]

希望本文对你有帮助，请点个赞鼓励一下作者吧~ 谢谢！

[HBase]: https://blog.csdn.net/wsdc0521/article/details/108505644
[HBase 1]: https://blog.csdn.net/wsdc0521/article/details/108514052
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70]: /images/20221123/933b14799db24646a51c84892b1dce3c.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 1]: /images/20221123/cc5e6c822a6d4f6b8dc5ea1b9d9d5e62.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 2]: /images/20221123/3cd37e0524864684830183424c4c7173.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 3]: /images/20221123/caf2f555496043d9ab6f5a393af29c5f.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L3dzZGMwNTIx_size_16_color_FFFFFF_t_70 4]: /images/20221123/6322c8e707bb4e369eabcc981791a696.png
[202009110229166.png]: /images/20221123/140dc2b098054b2096b721f9a91d58bd.png

发表评论取消回复

表情：

评论列表（有 0 条评论，126人围观）

还没有评论，来说两句吧...

相关阅读

相关 hbase 自动刷写API

1，旧的Htable API > storm_wxgz = Resources.hbasePro.getProperty("table_name"); > ...

绝地灬酷狼/ 2024年04月17日 15:09/ 0 赞/ 16 阅读

相关 hbase2.0.5中Region的切分策略

Region的切分目的：当表中数据增大时，将表切分多个region，可以将多个region负载到多个regionserver，以达到负载均衡！ hbase2.0.5

╰+攻爆jí腚メ/ 2023年01月09日 03:53/ 0 赞/ 106 阅读

相关 Hbase的刷写和合并机制

一、flush 1.1 flush作用 > memstore 达到 flush条件时，memstore所有的数据会被排序，之后书写到storefile! HFile

我就是我/ 2023年01月09日 03:53/ 0 赞/ 107 阅读

相关 HBase系列（三）、读写原理，Flush刷写，HFile Compact合并，Region Split切分

目录写原理读原理 Flush流程 HFile合并流程 Region拆分流程数据删除时间 -------------------- HBase系列：

比眉伴天荒/ 2022年12月05日 15:15/ 0 赞/ 127 阅读

相关 hbase hfile java_HBase之HFile解析

Sumary: Protobuf BinarySearch 本篇主要讲HFileV2的相关内容，包括HFile的构成、解析及怎么样从HFile中快速找到相关的KeyVal

不念不忘少年蓝@/ 2022年11月03日 04:23/ 0 赞/ 150 阅读

相关 HBase架构:HLog region store memstore compact storefile

HLog(WALlog)预写日志 write ahead log 写数据先写到日志再写memstore hbase的快在于内存和顺序写 region 即ta

布满荆棘的人生/ 2022年09月13日 11:20/ 0 赞/ 110 阅读

相关 HBase中region split的大致流程

经过和社区讨论，并参照网上的一些帖子，自己还看了一些源码，终于将region split的大致流程搞清楚了。 1. RegionServer开始split，首先会在ZK中创建

左手的ㄟ右手/ 2022年08月11日 07:29/ 0 赞/ 127 阅读

相关 HBase原理详解【Master、Region Server内部机制、Zookeeper、读写数据流程、hbase:meta表】

一、HBASE运行原理组件结构图 ![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG

末蓝、/ 2022年02月17日 02:27/ 0 赞/ 525 阅读

相关 Hbase中Region/Store/StoreFile/Hfile之间的关系

Region/Store/StoreFile/Hfile之间的关系 ![在这里插入图片描述][1d1de3ed846b2e0f45f6e88b19d86c0a.png]

谁借莪１个温暖的怀抱￠/ 2022年02月03日 20:15/ 0 赞/ 234 阅读

相关 HBase--Split和Compact

1 Region拆分一个Region代表一个表的一段Rowkey的数据集合，当Region太大，Master会将其拆分。Region太大会导致读取效率太低，遍历时间太长

你的名字/ 2021年12月18日 18:27/ 0 赞/ 289 阅读