hbase compact和split策略

最新推荐文章于 2024-01-01 09:42:18 发布
原创 最新推荐文章于 2024-01-01 09:42:18 发布 · 343 阅读 · 0 ·
CC 4.0 BY-SA版权
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
文章标签：

#hbase #compact #split #触发 #策略

---compact split笔记

 

compact策略：

在启动region之后，memflush之后，用户compact调用compact

使用策略类needsCompaction方法，hfile数量大于hbase.hstore.compaction.min 和 hbase.hstore.compactionThreshold的最大值数（默认值为3）

 

major compact触发：(hfile由mem flush生成)

HStore检查是否进行compact时候，现在now - 上次major时间大于hbase.hregion.majorcompaction下次时间间隔  =》 hfile个数大于1 || 只有一个hfile（最早的ts>ttl）整个文件过期 => 进行marjor compact

hbase shell和admin进行major_compact

compact file <= sum(hfile) * hbase.hstore.compaction.ratio 将small compact转为major compact

最小的tts到时间了，进行major compact

 

 

compact策略：（一次compact不会compact提供所有的hfile，会选择最好的一组）

ExploringCompactionPolicy

一、选择符合要求的一组hfile进行compact

1.hfile数>=minFiles

2.hfile数<=maxFiles

3.sum(hfile)大小<=hbase.hstore.compaction.max

4.一个hfile大小<sum(hfile)-hfile(不让一个hfile过大)

二、选择最优解（最优的一组hfile）

选择sum（hfile）大小最小的作为第一个组合，选择能合并更多的hfile，并且sum（hfile）大小更小的

 

 split触发：

1.flush之前会检测区域中HStoreFile数目是否超过hbase.hstore.blockingStoreFiles，如果超过且没有等待超时会调用CompactSplitThread.requestSplit(HRegion) 

2.flush之后会调用HRegion.checkSplit()检测是否需要split，如果需要则调用CompactSplitThread.requestSplit(HRegion)

3.compact之后会调用CompactSplitThread.requestSplit(HRegion)

4.hbaseadmin split table or region

 

split策略：

IncreasingToUpperBoundRegionSplitPolicy

（init）initialSize = hbase.increasing.policy.initial.size（预先设置初始值大小） 或hbase.hregion.memstore.flush.size （memflush大小）

获取this.region所在表的所有region数 getCountOfCommonTableRegions 为regioncount

当regioncount在0到100之间，取配置hbase.hregion.max.filesize（默认10G）或initialSize*(regioncount^3)的最小值  否则取配置hbase.hregion.max.filesize（默认10G）

如，只有一个region，128*1^3=128M

        之后：                 128*2^3=1024M

                                    128*3^3=3456M

                                    128*4^3=8192M

                                    128*5^3=16000M(15G) => 10G 当有5个region就可以用配了

 

结论：

compact

无法避免，

增大hbase.hstore.compaction.min 和 hbase.hstore.compactionThreshold可以减少compact频率，但是延迟compact时间，反之亦然

通过减少生成hfile数量减少compact，

通过设置较大的hbase.hregion.majorcompaction可以减少marjor compact频率

可以定时人为进行mar compact

split

可以避免，split可以只设置hbase.hregion.max.filesize很大就停止了region split操作

HBase Split分析
dcswin的博客
08-27 5572
本人结合HBase的源代码，对HBase的Split流程做了整体的分析，并结合实际的操作列出了一些注意的点，望能给对HBase感兴趣的人提供一定的帮助。
Hbase 面试题（六）
闲依农圃邻，偶似山林客。
06-03 1017
1. 简述下HBASE中Split机制 ？ 2. 简述Region如何预建分区 ？ 3. 请描述HBase中scan对象的setCache和setBatch方法的使用？ 4. 简述start-hbase.sh 为起点，Hbase 启动的流程是什么？ 5. 简述HBase的大合并、小合并？ 6. Hbase 如何解决热点写，Hbase如何解决热点问题？ 7. 简述 HBase 中 compact 用途和机制 ？
hbase分析之split策略
u012447842的博客
12-24 1863
目录 RegionSplitPolicy IncreasingToUpperBoundRegionSplitPolicy策略： SteppingSplitPolicy策略： ConstantSizeRegionSplitPolicy策略： KeyPrefixRegionSplitPolicy策略： DelimitedKeyPrefixRegionSplitPolicy策略： Busy...
hbase split策略
刘光华的专栏
03-31 1705
hbase版本：1.2.4    当前版本默认的region split策略是      hbase.regionserver.region.split.policy org.apache.hadoop.hbase.regionserver.IncreasingToUpperBoundRegionSplitPolicy hbase-default.xml         同一
HBASE-region的SPLIT策略
泰格数据
04-19 914
Hbase 0.94.0版本中，对于region的split方式引入了一个非常方便的SplitPolicy，通过这个SplitPolicy，可以主动的干预控制region split的方式。在org.apache.Hadoop.hbase.regionserver包中，可以找到这么几个自带的splitPolicy： ConstantSizeRegionSplitPolicy, Increasi
hbase split 源码分析之split策略
weixin_34102807的博客
06-15 192
　　在工作中接触到split，于是查看了这块的源代码，先看到了split的策略，今天就说说这个吧，后续还会有split的其他源码分析和compact相关的源码分析。 　　看了很多其他人的博客，很多都是转发的，原创的也都没有注明是哪个版本。其实给很多读者造成混淆，我这里是基于Hbase-0.98.13 版本作为分析的，注意：不同版本的此部...
Hbase Split 解析
Kuzury
07-04 3936
HBase Split是hbase根据一定的触发条件和一定的分裂策略将HBase的一个region进行分裂成两个子region并对父region进行清除处理的过程。Region是HBase中一个非常核心的组织单元，所有的region组成了整个HBase集群，如下面的HBase的体系结构所示：在HBase中，split其实是进行sharding的一种技术手段，通过HBase的split条件和split
【原创】HBase的分裂（Split）与紧缩（Compaction）
weixin_42162155的博客
02-28 4976
Hbase的紧缩与分裂 Hbase的紧缩与分裂过程是对数据管理中必不可少的功能，正是因为它们的存在为Hbase拥有高效读写性能及集群的负载均衡提供了保证，接下来对这两个过程作一下详细的介绍。 Region概述 Hbase的紧缩与分裂的发生都在在Region中进行的，了解过Hbase的伙伴应该不会陌生，这里再对Region的结构功能作一个简单介绍。Region是 HBase中分布式存储和负载均衡的最...
HBase的split分析
PunC的专栏
07-31 1991
HBase在新建一个表的时候，默认会把所有数据都会放在一个HRegion上，主节点HMaster根据一定的策略把HRegion分配到不同的HRegionServer从节点上，客户端在进行读写操作的时候，就会访问对应HRegionServer的HRegion。当HRegion的数据量超过阀值的时候，为了防止单个热点访问带来的压力，HBase就会对HRegion进行split操作，一个父HRegion
HBase 1.1.2 split 策略
程序员成长软技能
11-01 2036
背景：今天用ycsb做HBase的性能测试，region大小配置的是10G，单总是在10G前自动split，所以跟着日志查看代码，发现每次flush时候都会调用IncreasingToUpperBoundRegionSplitPolicy类中的shouldSplit方法，方法内容如下：
LSM学习分享——compact策略
weixin_44483474的博客
10-05 723
详细介绍在LSM学习分享——LSM读写流程中提到的copaction操作。主要介绍两种基本策略：size-tiered和leveled。 前提知识： (1)、读放大:读取数据时实际读取的数据量大于真正的数据量。例如在LSM树中需要先在MemTable查看当前key是否存在，不存在继续从SSTable中寻找。 (2)、写放大:写入数据时实际写入的数据量大于真正的数据量。例如在LSM树中写入时可能触发Compact操作，导致实际写入的数据量远大于该key的数据量。 (...
Hbase split的过程以及解发条件
weixin_30593261的博客
09-10 247
一、Split触发条件 1、 有任一一个Hfile的大小超过默认值10G时，都会进行split 2、 达到这个值不在拆分，默认为int_max，不进行拆分 3、compaction时，如果compact的store的大小超过了，则进行split 4、flush之前会检测区域中HStoreFile数目是否超过hba...
Hbase Compaction 队列数量较大分析(压缩队列、刷新队列）
萌兔兔MMQ！！
06-05 3828
前几天朋友公司Hbase集群出现Compaction队列持续处于比较大的情况，并且mem flush队列也比较大，一起看了下问题，大概情况如下图 从图中可以看出来压缩队列总和持续在1000-2000，平对压缩队列在200左右，刷新队列也比较高，当然压缩队列高的原因就是因为我们 MemStore Flush 比较频繁，导致写入的StoreFile数量增加，触发了Compcation。 问题原因分析 我们先说下什么情况下会触发Compaction 1.后台线程周期性检查： multiplier=1000，c
HBase Compaction
初阳
10-21 2521
文章目录1. Compaction1.1. 基本原理1.2. Compaction 的核心作用1.3. Compaction 基本流程1.3.1. Compaction 触发时机1.3.2. 待合并 HFile 集合选择策略 1. Compaction Compaction是以Store为单位进行的 Compaction使读取延迟更加稳定，但是读取时间产生了很大的毛刺 Compaction 操作的主要源头来自flush操作 根据待合并HFile文件的选择策略可以得知，正在进行Compaction的HFi
深入分析HBase Compaction机制
热门推荐
Hadoop、HBase、ElasticSearch、Storm、Kafka、Spark
09-03 1万+
Compaction介绍 Compaction是buffer->flush->merge的Log-Structured Merge-Tree模型的关键操作，主要起到如下几个作用： 1）合并文件 2）清除删除、过期、多余版本的数据 3）提高读写数据的效率 Minor & Major Compaction的区别 1）Minor操作只用来做部分文件的合并操作以及包括minVersion=0并
Hbase split的三种方式和split的过程
weixin_34326558的博客
12-31 556
在Hbase中split是一个很重要的功能，Hbase是通过把数据分配到一定数量的region来达到负载均衡的。一个table会被分配到一个或多个region中，这些region会被分配到一个或者多个regionServer中。在自动split策略中，当一个region达到一定的大小就会自动split成两个region。table在region中是按照row key来排序的，并且一个row key...
HBase内容分享（五）：HBase读写性能优化
之乎者也·的博客
01-01 2841
HDFS数据通常存储三份，假如当前RegionA处于Node1上，数据a写入的时候三副本为(Node1,Node2,Node3)，数据b写入三副本是(Node1,Node4,Node5)，数据c写入三副本(Node1,Node3,Node5)，可以看出来所有数据写入本地Node1肯定会写一份，数据都在本地可以读到，因此数据本地率是100%。这里需要澄清一下，如果不对列数据做限制，数据总是一行一行返回的，即使一行数据大小大于设置的返回结果限制大小，也会返回完整的一行数据。
Hbase compact入门
鸭梨的博客
11-30 787
模糊概念区分 StoreFile是HFile的外观。在压缩方面，StoreFile的使用似乎在过去很盛行。 Store与ColumnFamily是同一件事。 StoreFiles与Store或ColumnFamily相关。 当MemStore达到给定大小（hbase.hregion.memstore.flush.size）时，它将其内容刷新到StoreFile。存储中的StoreFiles数量随时间增加。压缩是一种通过合并存储来减少存储中StoreFile数量的操作，以提高读取操作的性能。压缩可能会占用大量
hbase bulkload引起大量小文件compact
最新发布
02-27
<think>嗯，用户问的是HBase BulkLoad引起大量小文件Compact的问题。首先，我需要回忆一下HBase的BulkLoad机制。BulkLoad通常用于将大量数据直接导入HBase，而无需经过RegionServer的写路径，这样可以避免写放大，提升导入效率。但问题出在BulkLoad生成的小文件可能导致后续的Compaction压力增大。 首先，得解释BulkLoad的基本流程。BulkLoad是通过生成HFile文件，然后直接加载到HBase的表中。这些HFile文件会被移动到对应Region的目录下。如果导入的数据量不大，或者Region的划分比较粗，可能会导致每个Region都生成很多小的HFile文件。这时候，HBase在后续的Compaction过程中需要合并这些小文件，消耗大量资源，甚至影响集群性能。 接下来，需要考虑为什么BulkLoad会产生小文件。可能的原因有几个：比如每次BulkLoad生成的文件大小没有达到HFile的配置大小，或者导入的数据分布不均匀，导致多个小文件被分配到不同的Region。另外，如果频繁执行BulkLoad，每次导入的数据量都不大，自然会产生很多小文件。 然后，要分析Compaction的作用。HBase的Compaction分为Minor和Major两种。Minor Compaction合并少量的HFile，减少读取时的IO次数；Major Compaction则合并所有HFile，并清理过期数据。当存在大量小文件时，RegionServer需要频繁进行Compaction，尤其是Major Compaction，这会占用大量磁盘IO和CPU资源，可能导致请求延迟增加，甚至RegionServer宕机。 接下来，需要思考如何解决这个问题。可能的解决方案包括调整HFile的大小配置，确保每次BulkLoad生成的文件足够大；或者在BulkLoad之前对数据进行预处理，比如按照Region的划分进行排序，减少小文件的数量。另外，调整Compaction策略，比如使用Stripe Compaction或者Date-Tiered Compaction，可能更有效地处理小文件。还可以考虑在非高峰时段手动触发Major Compaction，或者增加Compaction的线程数，提高处理能力。 不过，用户可能需要更具体的步骤，比如配置参数的调整，或者实际操作中的最佳实践。比如，设置hbase.hstore.compaction.min.size和hbase.hstore.compaction.max.size来控制哪些文件会被合并，或者通过HBase的预分区策略，提前规划Region的分布，减少数据导入后的分裂和移动。 还要注意，BulkLoad生成的文件是否进行了压缩，如果使用合适的压缩算法，可能减少文件数量和大小。另外，HBase的版本和HDFS的配置也可能影响这一过程，需要确认是否相关参数优化到位。 可能还需要考虑HBase的写入模式和读取模式的平衡，BulkLoad虽然高效，但后续的维护成本也需要权衡。比如，是否可以在BulkLoad之后立即触发Compaction，或者是否有工具可以合并小文件，避免对线上服务造成影响。 最后，总结一下，需要从BulkLoad的数据准备、HBase的配置优化、Compaction策略调整等多个方面入手，才能有效减少小文件带来的Compaction压力。</think>HBase BulkLoad 引起大量小文件 Compact 的问题通常与数据导入方式和存储机制有关。以下是逐步分析及解决方案： --- ### **1. BulkLoad 机制回顾** - **BulkLoad 原理** 通过 MapReduce/Spark 等工具直接生成 HFile 文件，绕过 RegionServer 的写路径（WAL、MemStore），直接将文件移动到 HBase 表目录。适合海量数据快速导入。 - **优点** 避免写放大、减少 RegionServer 压力。 - **潜在问题** 若每次 BulkLoad 生成大量小文件（例如每个文件远小于默认 HFile 大小 10GB），会导致后续 Compaction 压力剧增。 --- ### **2. 小文件 Compact 问题的成因** #### **(1) 文件粒度不合理** - 每次 BulkLoad 的数据量过小，生成多个小 HFile。 - 未合理预分区（Pre-split），导致数据分散到过多 Region。 #### **(2) HFile 合并逻辑** - HBase 自动触发 **Minor Compaction**（合并少量文件）和 **Major Compaction**（合并所有文件）。 - 大量小文件会频繁触发 Compaction，消耗 CPU/IO 资源，甚至阻塞读写。 #### **(3) 负载不均衡** - 小文件分布在多个 Region 中，导致全局 Compaction 风暴。 --- ### **3. 解决方案** #### **(1) 优化 BulkLoad 流程** - **增大单个 HFile 大小** 调整 MapReduce/Spark 作业的 `hbase.mapreduce.hfileoutputformat.blocksize`（默认 64KB），确保生成较大的 HFile。 ```xml <property> <name>hbase.hregion.max.filesize</name> <value>10737418240</value> <!-- 10GB --> </property> ``` - **预分区（Pre-split）** 根据 RowKey 分布提前创建 Region，避免数据写入后自动分裂产生小文件。 ```java byte[][] splits = new byte[][] { "1000".getBytes(), "2000".getBytes() }; admin.createTable(tableDesc, splits); ``` - **合并输入数据** 在 BulkLoad 前对数据进行排序，减少输出文件数量（例如通过 MapReduce 的 CombineFileInputFormat）。 --- #### **(2) 调整 Compaction 策略** - **选择 Compaction 算法** 根据场景选择 `StripeCompaction`（适合时间序列数据）或 `DateTieredCompaction`。 ```xml <property> <name>hbase.hstore.engine.class</name> <value>org.apache.hadoop.hbase.regionserver.StripeStoreEngine</value> </property> ``` - **限制 Compaction 频率** 调整触发阈值： ```xml <property> <name>hbase.hstore.compaction.min</name> <value>3</value> <!-- 至少3个文件触发 --> </property> <property> <name>hbase.hstore.compaction.max</name> <value>10</value> <!-- 单次最多合并10个文件 --> </property> ``` --- #### **(3) 手动干预** - **主动触发 Major Compaction** 在业务低峰期手动合并： ```bash hbase shell> major_compact 'table_name' ``` - **合并小文件工具** 使用 HBase 内置工具（如 `HFileMerge`）或自定义脚本合并小文件。 --- #### **(4) 监控与调优** - **监控指标** 关注 HBase UI 中的 **Compaction Queue Length**、**StoreFile Count**。 - **调整 RegionServer 资源** 增加 Compaction 线程数： ```xml <property> <name>hbase.regionserver.thread.compaction.large</name> <value>4</value> </property> ``` --- ### **4. 总结** 通过优化 BulkLoad 数据分布、调整 Compaction 策略、合理预分区以及资源控制，可有效减少小文件引发的 Compact 压力。核心目标是 **减少小文件数量** 和 **降低 Compaction 频率**，平衡写入性能与存储稳定性。
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值