[HUDI-3598] Row Data to Hoodie Record Operator parallelism needs to always be consistent with input operator for chaining purpose

[JerryYue-M]

…o adjust the number of parallelism

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

(For example: This pull request adds quick-start document.)

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.

[JerryYue-M]

@wangxianghu
thanks for review, I had fixed the problem you pointed out

[danny0405]

Can you explain why this param is needed ? Generally we avoid introducing too many options if it is not necessary.

The default parallelism would make the map operator chain with source if the souce also has default parallelism.

[JerryYue-M]

@danny0405
in the real product scene，source operator don't use the default parallelism of job. for example, kafka source will set the parallelism mapping to partition num. in this case we can't chain the source operator with map function.that's why we need the config.

[JerryYue-M]

@danny0405
in the real product scene，source operator don't use the default parallelism of job. for example, kafka source will set the parallelism mapping to partition num. in this case we can't chain the source operator with map function.that's why we need the config.

[danny0405]

@danny0405 in the real product scene，source operator don't use the default parallelism of job. for example, kafka source will set the parallelism mapping to partition num. in this case we can't chain the source operator with map function.that's why we need the config.

The more proper way is using the source/input parallelism so that the options can be avoided.

[wangxianghu]

@wangxianghu thanks for review, I had fixed the problem you pointed out

Thanks @JerryYue-M, I am ok with the change.
will merge as long as @danny0405 approve it

[wangxianghu]

@danny0405 in the real product scene，source operator don't use the default parallelism of job. for example, kafka source will set the parallelism mapping to partition num. in this case we can't chain the source operator with map function.that's why we need the config.

The more proper way is using the source/input parallelism so that the options can be avoided.

This could be a better way, avoid introducing new options.

[JerryYue-M]

@danny0405 @wangxianghu
indeed, i will follow this way
thanks all

[danny0405]

+1

[wangxianghu]

@hudi-bot run azure

[hudi-bot]

CI report:

• 8d9fe30 Azure: FAILURE Azure: FAILURE

Bot commands

@hudi-bot supports the following commands:

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

[yihua]

@JerryYue-M could you rebase this PR on the latest master? The CI failure is due to clustering failure which has been fixed on the latest master. Once CI passes, the PR is ready for merging.

[danny0405]

@yihua I would just merge it because this change is trivial.