果然 https://github.com/apache/hbase/blob/4d90b918a3702b4e4ae2f9ee890c14665e821c01/hbase-server/src/main/java/org/apache/hadoop/hbase/regionserver/StripeStoreEngine.java#L84
这个方法里压根就没用过那个 forceMajor 参数 可以开个 issue 吧，看看这块怎么改一下，至少得把 forceMajor 这个参数传递下去，在 stripe 内部做 compact 的时候需要能拿到这个参数 张铎(Duo Zhang) <palomino...@gmail.com> 于2023年11月29日周三 14:18写道： > > 我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数 > > leojie <leo...@apache.org> 于2023年11月21日周二 11:42写道： > > > > 张老师， > > 您好！ > > 请教一个HBase的问题，我们线上有张表，应用了Stripe > > Compaction策略，每个region均值40G，被分成8个Stripe，每个Stripe5g，业务删除大量数据，表整体和单个region手动触发major > > compaction不起作用，挑选不出来合适的文件参与合并。 > > > > 看了源码，每个Stripe下面应用的合并策略是，ExploringCompactionPolicy，这个策略有一个关键点，筛选耽搁Stripe的Store > > file列表，候选文件列表中，只要存在一个文件的大小过大，满足条件，fileSize > (totalFileSize - fileSize) * > > (hbase.hstore.compaction.ratio 默认值1.2)，就不会筛选出来文件参与major > > 如果支持一个强制合并的机制，是否合理？针对大量删除场景，或bulkload，存在大量数据被标记删除，可以在手动触发major时， > > 显式传入一个foreMajor之类的参数，就是 > > 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？ > > 期待张老师的解惑，十分感谢😁😁
