[HUDI-8675] Flink schedule compaction with incremental partitions

[zhangyue19921010]

Change Logs

In Hudi, when scheduling Compaction, the default behavior is to scan all partitions under the current table. When there are many historical partitions, such as 640,000 in our production environment, this scanning and planning operation becomes very inefficient. For Flink, it often leads to checkpoint timeouts, resulting in data delays. This PR introduces the ability to schedule Compaction for incremental partitions. In the StreamOperatorCoordinator, it adds:

1. A state variable lastInstant to record the delta commit instant corresponding to the last successfully completed Compaction schedule, and it is saved with the state.
2. A temporary variable cacheWrittenPartitions to cache the incremental partitions corresponding to all delta commits from the last scheduled Compaction to the present.

Impact

no

Risk level (write none, low medium or high below)

low

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

• The config description must be updated if new configs are added or the default value of the configs are changed
• Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
  ticket number here and follow the instruction to make
  changes to the website.

Contributor's checklist

• Read through contributor's guide
• Change Logs and Impact were stated clearly
• Adequate tests were added if applicable
• CI passed

[hudi-bot]

CI report:

• fc67ac2 Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

• @hudi-bot run azure re-run the last Azure build

[danny0405]

Nice feature, the incremental compaction and clustering have always been a strong request from community users and they are valuable. I have some thoughts here:

1. we better generalize the incremental plan scheduling for both compaction and clustering;
2. try to avoid to relies on Flink state for the back-up of state-store, we might still utilities the timeline to fetch the incremental partitions added to the table like what we do to incremental cleaning;
3. if there is pending compaction in partition p1, and the p1 has been written into new logs since last compaction, how can we continue to schedule the plan for p1 for next compaction scheduling run?
4. we need to consider whether to design a new interface for incremental compaction planning, previously we pass around all the table partiitons to CompactionStrategy.filterPartitionPaths.

It's great if we can fire a RFC to address these issues.

[yuzhaojing]

This is a highly anticipated feature and a very important capability for improving the availability of Flink Hudi pipeline. I quite agree with @danny0405 proposal. I hope that the incremental capability can be applied to more scenarios instead of being limited to compaction only. I'm really looking forward to having an RFC to systematically solve these problems. Besides, here are some thoughts:

1. For NBCC, is it possible that some partitions may be missed in this implementation?

2. If the lastInstant has already been archived and there is no judgment made when initializing cache partitions (initCachePartitions), will there be a situation where some partitions are missed?

[zhangyue19921010]

Thanks For your attention @danny0405 AND @yuzhaojing，Will address a RFC implement incremental capability for all Hudi table service like compaction, clustering and clean, etc. I'll let you know when the RFC has a draft :)

[zhangyue19921010]

Hey @danny0405 and @yuzhaojing , Incremental table service related PR
#12513
#12514

PTAL ~