[HUDI-4338] resolve the data skew when using flink datastream write hudi

[liufangqi]

Tips

• Thank you very much for contributing to Apache Hudi.
• Please review https://hudi.apache.org/contribute/how-to-contribute before opening a pull request.

What is the purpose of the pull request

https://issues.apache.org/jira/browse/HUDI-4338

Brief change log

(for example:)

• Modify AnnotationLocation checkstyle rule in checkstyle.xml

Verify this pull request

(Please pick either of the following options)

This pull request is a trivial rework / code cleanup without any test coverage.

(or)

This pull request is already covered by existing tests, such as (please describe tests).

(or)

This change added tests and can be verified as follows:

(example:)

• Added integration tests for end-to-end.
• Added HoodieClientWriteTest to verify the change.
• Manually verified the change by running a job locally.

Committer checklist

• Has a corresponding JIRA in PR title & commit

• Commit message is descriptive of the change

• CI is green

• Necessary doc changes done or have another open PR

• For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

[liufangqi]

@hudi-bot run azure

[hudi-bot]

CI report:

• e827da2 Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

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

[LinMingQiang]

Different keys may be assigned the same fileid in different tasks, Is there a concurrency problem if you do not repartition by fileid?

[liufangqi]

Thanks for your review, actually, the bucket data stream is a keyed stream that repartition by hoodie record key.
If the bucket assgin opeator 's task num equals the write operator's, we don't need the repartition which repartition by location.

[liufangqi]

There will not be the differrent tasks that hold the same fileid. Cause the bucket assign operator task get the keyed stream that repatitioned by hoodie key which means that every bucket assign operator task hold the unique file id, and wirte operator task : bucket assgin operator task is 1 : 1 which is the preconditions of the improvement.

[LinMingQiang]

Thanks, I see what you mean, when repartition, each task has decided to write only one fileid.

[liufangqi]

Actually, I think we can build a map-only data stream when we don't need update or delete. I can create a new issue to discuss this for avoid confict.

[liufangqi]

Then why not try to promote the hash algorithm, say the murmur hash ?

@danny0405
The hash algorithm what flink use is the murmur hash.

The point is that the bucket num is small that equals to the downstream task num.
See this example code:
int bucketNum = 10;
int taskNum = 10;
int [] map = new int[taskNum];
for (int i = 0; i < bucketNum ; i++) {
map[Math.abs(murmurHash(UUID.randomUUID().hashCode())) % taskNum] += 1;
}
for (int num:
map) {
System.out.println(num);
}

if we just generate 10 buckets for 10 tasks, we can get like this:

if we generate more buckets for 10 tasks, it seems like more balance:

[danny0405]

But we should figure out more random algorithm here instead of just fix the case when bucket assign and write task have the same parallelism, how about the bucket assign has parallelism 4 and write task has parallelism 6 here ?

[liufangqi]

But we should figure out more random algorithm here instead of just fix the case when bucket assign and write task have the same parallelism, how about the bucket assign has parallelism 4 and write task has parallelism 6 here ?

@danny0405 Yeah, I approval this. We do need to resolve the problem completely. I will think about a better idea later.
But this pr can help resolve the network overhead and the data skew in some case. I think it should be a improvment not bug fix.

[danny0405]

It is a fix but the limitation is too strict here, so not that valid from my side.

[liufangqi]

It is a fix but the limitation is too strict here, so not that valid from my side.

Okay, I get you. Thanks for your reply whatever.

[yihua]

Closing the PR given that we should improve the hash algorithm as a general enhancement. Closing this PR.