[Feature Discuss] Partition-Level Bucket Index

[zhangyue19921010]

Hi Hudis:

As we known, Hudi proposed and introduced Bucket Index in RFC-29. Bucket Index can well unify the indexes of Flink and Spark, that is, Spark and Flink could upsert the same Hudi table using bucket index.

However, Bucket Index has a limit of fixed number of buckets. In order to solve this problem, RFC-42 proposed the ability of consistent hashing achieving bucket resizing by splitting or merging several local buckets dynamically.

But from PRD experience, sometimes a Partition-Level Bucket Index and a offline way to do bucket rescale is good enough without introducing additional efforts (multiple writes, clustering, automatic resizing,etc.). Because the more complex the Architecture, the more error-prone it is and the greater operation and maintenance pressure.

In this regard, we could upgrade the traditional Bucket Index to implement a Partition-Level Bucket Index, so that users can set a specific number of buckets for different partitions through a rule engine (such as regular expression matching). On the other hand, for a certain existing partitions, an off-line command is provided to reorganized the data using insert overwrite(need to stop the data writing of the current partition).

More importantly, the existing Bucket Index table can be upgraded to Partition-Level Bucket Index smoothly and seamlessly.

Some thoughts on this change? Any feedback would be greatly appreciated !

[danny0405]

Are you saying to support configuring the bucket number in partition-level? Can the bucket number be changed after an explicit configuration?

[zhangyue19921010]

Are you saying to support configuring the bucket number in partition-level? Can the bucket number be changed after an explicit configuration?

Hi @danny0405

Thanks for your attention. Yes, we will provide a new mechanism to specify the number of buckets for different partitions through an expression. For existing partitions, we can change current partition's bucket number through an offline job (Insert Overwrite) with the new bucket number. For new partitions, the initial value of the bucket number is obtained based on the expression. Additionally, updates to the expression are also supported, but the updated expression will only take effect for new partitions.

Function similar to https://paimon.apache.org/docs/master/maintenance/rescale-bucket/

[danny0405]

Can the bucket number be dynamically inferred with the inputs? Hudi has a partition metadata file under each partition, maybe we can record the bucket number there.

[zhangyue19921010]

Can the bucket number be dynamically inferred with the inputs? Hudi has a partition metadata file under each partition, maybe we can record the bucket number there.

Hi @danny0405 , Thanks for your replay.
We could abstract a strategy to control the calculation logic of bucket number for example:

1. Calculate the bucket number based on regular expression.
2. Calculate the bucket number based on fixed value set by user.
3. Calculate the bucket number based on metadata(daily input size and average bucket size) based on MDT.

As for where to record partition bucket number. How about .hoodie_partition_metadata. Users who disable MDT also can use this partition-level bucket index.

[xiarixiaoyao]

@zhangyue19921010 We have implemented dynamic partition bucketing, which supports regular expressions, similar to your idea. The only difference is that we store bucket information in the ./hoodie/.bucket directory. Since the bucket information is minimal, it's efficient to store it in a single file. This approach simplifies the process of retrieving partition-level bucket counts and performing bucket pruning. At the same time, with the help of Hudi's timeline, we can easily ensure the consistency of bucket information

[zhangyue19921010]

@zhangyue19921010 We have implemented dynamic partition bucketing, which supports regular expressions, similar to your idea. The only difference is that we store bucket information in the ./hoodie/.bucket directory. Since the bucket information is minimal, it's efficient to store it in a single file. This approach simplifies the process of retrieving partition-level bucket counts and performing bucket pruning. At the same time, with the help of Hudi's timeline, we can easily ensure the consistency of bucket information

Hi @xiarixiaoyao Thanks for your replay! It seems that dynamic partition-level bucket index is indeed a common requirement.
./hoodie/.bucket directory is a good idea. But how to solve the problem of two jobs concurrently writing? At this time, there may be multiple tasks operating on the partition meta file(Even if wrote to different partitions)?

[danny0405]

@xiarixiaoyao Can you share the data structure under ./hoodie/.bucket ?