Flink 1.14: Fix the flaky testHashDistributeMode by ingesting all rows in one checkpoint cycle.

[openinx]

This PR is trying to fix the flaky testHashDistributeMode unit test fundamentally. The following are the explannation about the current fix.

1. Flink: fix flink unit test testHashDistributeMode #4117 (comment)
2. Flink: fix flink unit test testHashDistributeMode #4117 (comment)
3. Flakey flink unit tests TestFlinkTableSink#testHashDistributeMode #2575 (comment)

[openinx]

Run this 20 times in my host, everything seems OK:

for i in `seq 1 20`; do
./gradlew :iceberg-flink:iceberg-flink-1.14_2.12:test --tests "org.apache.iceberg.flink.TestFlinkTableSink"
if [ ! $? -eq 0 ] ; then
exit 1
fi
done

[yittg]

shall we produce more than one checkpoint? and add enough records in each part instead of enumerating them?

[openinx]

I think a single checkpoint is good enough to validate the PartitionKeySelector. More checkpoints will make the unit test more complex but validate the same thing in my mind.

Mocking more records as the testing data set looks good to me.

[yittg]

check records based on dataSet?

[yittg]

LGTM

[stevenzwu]

@openinx I have run the test hundreds of times locally in a test loop like you did before and was never able to reproduce it.

Think again about the root cause that we discussed in the issue where we may miss the notifyCheckpointComplete callback. As a result, two checkpoint cycles got squashed into one Iceberg commit and hence have 2 files for a partition in one Iceberg commit.

I misunderstood the PR earlier. Looks like the change is to make sure we have one checkpoint cycle for all rows to bypass the potential problem from multiple checkpoint cycles.

[stevenzwu]

LGTM.

nit: can we change the description to "by ingesting all rows in one checkpoint cycle"? Earlier, I misunderstood the PR. I mistakenly thought we are still doing multiple checkpoint cycles and we are just precisely control rows in each checkpoint cycle.

[openinx]

@stevenzwu The root cause is : Previous design could not guarantee that a single checkpoint could commit all rows to a given transaction. Here is another example. That's why we are now trying to guarantee this in this PR.

The new description looks good to me if you think it's more clear.

[stevenzwu]

@openinx looks good. can you merge this? should be safe.

[rdblue]

Thanks for fixing the flaky test, @openinx!