You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-zh@hbase.apache.org by leojie <le...@apache.org> on 2023/11/21 03:41:44 UTC
Stripe Compaction 策略遇到的一些问题请教
张老师，
您好！
请教一个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之类的参数，就是
不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
期待张老师的解惑，十分感谢😁😁
Re: Stripe Compaction 策略遇到的一些问题请教
Posted by leojie <le...@apache.org>.
张老师
您好！接上次的问题，还有一些疑问，需要向您请教下。
对于StripeCompaction策略。按照Stripe 为单位挑选待合并文件，如何记录单个Stripe是否被合并过呢？
举个例子：用户触发了 major_compact 'region_encoded_name'，目标region下分了5个Stripe，
每个Stripe下平均包含10个hfile，major_compact 触发后，先选Stripe1下的hfile参与合并，然后选Stripe2
...... Stripe5。
而不是5个Stripe下的hfile一起被选出来参与合并。这样串行执行，可避免Region下所有hfile一起合并消耗大量IO。
只是现在的代码逻辑是：
我执行一次major_compact
'region_encoded_name'，会从5个Stripe下选择一个最适合参与合并的Stripe。然后返回一个CompactionRequest，丢给合并线程池
如果我想做到，串行执行每个Stripe的Compaction，最优实现是怎样？
是串行执行每个Region的Stripe级别的Compaction，记录Stripe合并状态，避免重复执行Stripe的合并，
还是把Region的每个Stripe包装成一个CompactionRequest，然后返回一个CompactionRequest列表，依次丢到合并线程池中，这样依靠合并的队列机制，避免单次合并执行消耗大量资源的问题
leojie <le...@apache.org> 于2023年11月29日周三 14:37写道：
> issue已创建，https://issues.apache.org/jira/browse/HBASE-28227
>
> leojie <le...@apache.org> 于2023年11月29日周三 14:22写道：
>
>> 好的，感谢张老师回复，我提个issue，描述下这个问题
>>
>> 张铎(Duo Zhang) <pa...@gmail.com> 于2023年11月29日周三 14:21写道：
>>
>>> 果然
>>>
>>>
>>> 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) <pa...@gmail.com> 于2023年11月29日周三 14:18写道：
>>> >
>>> > 我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数
>>> >
>>> > leojie <le...@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之类的参数，就是
>>> > > 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
>>> > > 期待张老师的解惑，十分感谢😁😁
>>>
>>
Re: Stripe Compaction 策略遇到的一些问题请教
Posted by leojie <le...@apache.org>.
issue已创建，https://issues.apache.org/jira/browse/HBASE-28227
leojie <le...@apache.org> 于2023年11月29日周三 14:22写道：
> 好的，感谢张老师回复，我提个issue，描述下这个问题
>
> 张铎(Duo Zhang) <pa...@gmail.com> 于2023年11月29日周三 14:21写道：
>
>> 果然
>>
>>
>> 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) <pa...@gmail.com> 于2023年11月29日周三 14:18写道：
>> >
>> > 我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数
>> >
>> > leojie <le...@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之类的参数，就是
>> > > 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
>> > > 期待张老师的解惑，十分感谢😁😁
>>
>
Re: Stripe Compaction 策略遇到的一些问题请教
Posted by leojie <le...@apache.org>.
好的，感谢张老师回复，我提个issue，描述下这个问题
张铎(Duo Zhang) <pa...@gmail.com> 于2023年11月29日周三 14:21写道：
> 果然
>
>
> 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) <pa...@gmail.com> 于2023年11月29日周三 14:18写道：
> >
> > 我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数
> >
> > leojie <le...@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之类的参数，就是
> > > 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
> > > 期待张老师的解惑，十分感谢😁😁
>
Re: Stripe Compaction 策略遇到的一些问题请教
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
果然
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) <pa...@gmail.com> 于2023年11月29日周三 14:18写道：
>
> 我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数
>
> leojie <le...@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之类的参数，就是
> > 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
> > 期待张老师的解惑，十分感谢😁😁
Re: Stripe Compaction 策略遇到的一些问题请教
Posted by "张铎(Duo Zhang)" <pa...@gmail.com>.
我印象里应该是有这个机制的，是不是 StripeCompaction 里没考虑这个参数
leojie <le...@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之类的参数，就是
> 不应用挑选策略，直接选择合并全部文件，目前是否存在这样的功能，或者这样的功能是否合理？除此之外，针对这样的情况，是否有更理想的方案呢？
> 期待张老师的解惑，十分感谢😁😁