Add min==max check to ensure bucket transform correctness in AddFiles

[claudevdm]

Please add a meaningful description for your change here

---

Thank you for your contribution! Follow this checklist to help us incorporate your contribution quickly and easily:

• Mention the appropriate issue in your description (for example: addresses #123), if applicable. This will automatically add a link to the pull request in the issue. If you would like the issue to automatically close on merging the pull request, comment fixes #<ISSUE NUMBER> instead.
• Update CHANGES.md with noteworthy changes.
• If this contribution is large, please file an Apache Individual Contributor License Agreement.

See the Contributor Guide for more tips on how to make review process smoother.

To check the build health, please visit https://github.com/apache/beam/blob/master/.test-infra/BUILD_STATUS.md

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI or the workflows README to see a list of phrases to trigger workflows.

[ahmedabu98]

This is meant to create a partitioned writer. Why remove it?

[claudevdm]

I dont think .withPartition has any impact on how bytes are written to the parquet files. Rather withPartition adds some metadata to the DataFile (for manifests?) which is not written into the actual parquet file. These tests operate only on the parquet files?

[ahmedabu98]

This is too strict and will lead to false negatives. It's normal for a file to contain different values that hash to the same bucket. This will incorrectly turn them away.

Bucketing is a common transform so we need to be careful how we deal with it.

[ahmedabu98]

We used to have a more thorough but costly validation In the initial implementation.

If we encountered a bucket partitioned column, we would iterate through every value of that column and apply the transform to check that they all map to the same partition value. We ended up removing it though because we expected it to be a big bottleneck

[claudevdm]

But we cannot guarantee from summary statistics bucket transform is valid unless max == min. Should we consider making it safe by default and have a flag for opting into unchecked bucketing?

Users might think "oh neat I can apply bucket transforms on any column safely?". Instead they should read the fine print and assert that "my files are already clustered by this spec's buckets, trust them.".

[ahmedabu98]

I don't think max == min is a good enough condition to condition our behavior on. It will be false more often than not since bucket transform does not group by identical values.

Another option is to assume safety (note: this is what Spark does), and add a stricter "validate" option that would iterate through the whole bucket-partitioned column to verify.

[github-actions]

Assigning reviewers:

R: @kennknowles for label java.

Note: If you would like to opt out of this review, comment assign to next reviewer.

Available commands:

• stop reviewer notifications - opt out of the automated review tooling
• remind me after tests pass - tag the comment author after tests pass
• waiting on author - shift the attention set back to the author (any comment or push by the author will return the attention set to the reviewers)

The PR bot will only process comments in the main thread (not review comments).