[HUDI-2732][RFC-38] Spark Datasource V2 Integration

[leesf]

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.

[leesf]

CC @vinothchandar @bvaradar @nsivabalan @codope @umehrot2 @YannByron @li36909 @EdwinGuo @xushiyan

[vinothchandar]

lets separate the number update into a different PR? as mentioned in the process?

[leesf]

In fact the PR has been merged #3964, will update the PR

[vinothchandar]

@xushiyan @YannByron and I can be approvers if you don't mind

[leesf]

sure

[vinothchandar]

@leesf Love to understand the plan going forward here and how we plan to migrate the existing v1 write path onto the v2 APIs. Specifically, current v1 upsert pipeline consists of the following logical stages preCombine -> index -> partition -> write before committing out the files. In other words, we benefit from v1 API providing ways to shuffle the dataframe further before writing to disk and IIUC v2 takes this flexibility away?

Assuming I am correct (and spark has not introduced any new APIs that help us mitigate this), should we do the following?

• introduce a new hudiv2 datasource i.e spark.write.format("hudiv2") that just supports bulk_insert on the datasource write path.
• We also add a new SparkDatasetWriteClient which exposes methods for upsert,delete, .. and we use that as the basis for our SQL/DML layer as well.
• We continue to support the v1 hudi datasource as-is for sometime. There are lots of users who like how they can do upserts/deletes by executing a spark.write.format("hudi").option()...

[leesf]

@leesf Love to understand the plan going forward here and how we plan to migrate the existing v1 write path onto the v2 APIs. Specifically, current v1 upsert pipeline consists of the following logical stages preCombine -> index -> partition -> write before committing out the files. In other words, we benefit from v1 API providing ways to shuffle the dataframe further before writing to disk and IIUC v2 takes this flexibility away?

Assuming I am correct (and spark has not introduced any new APIs that help us mitigate this), should we do the following?

• introduce a new hudiv2 datasource i.e spark.write.format("hudiv2") that just supports bulk_insert on the datasource write path.
• We also add a new SparkDatasetWriteClient which exposes methods for upsert,delete, .. and we use that as the basis for our SQL/DML layer as well.
• We continue to support the v1 hudi datasource as-is for sometime. There are lots of users who like how they can do upserts/deletes by executing a spark.write.format("hudi").option()...

@vinothchandar In fact, I do not intend to introduce "hudiv2" format when introducing V2 code path, since it will make end users change their code and the "hudiv2" is not a good name("hudi" is good enough) IMO, instead I would like to change the former "hudi" format into "hudi_internal" and make "hudi" format as the v2 code path as default to make it transparent for end users, and integrate with current bulk_insert V2 write path.
And In the first phase, we would fallback to V1 write path while introduce V2 interface(HoodieCatalog and HoodieInternalTableV2), and integrate with current bulk_insert V2 write path. In the second phase, we would explore the way to integrate with SparkDatasetWriteClient which @xushiyan did a PoC to make it purely V2 code path.

[vinothchandar]

And In the first phase, we would fallback to V1 write path

Can this be done? Love to see some code for this.

[leesf]

And In the first phase, we would fallback to V1 write path

Can this be done? Love to see some code for this.

yes, will open a PR in recent days.

[nsivabalan]

@leesf : I did not go through the lineage of this patch. But I do know we landed the another PR related to spark datasource V2. so, is this patch still valid or can we close it out.

[xushiyan]

@leesf : I did not go through the lineage of this patch. But I do know we landed the another PR related to spark datasource V2. so, is this patch still valid or can we close it out.

@nsivabalan this is the RFC PR. Current work is in #4611

[xushiyan]

@leesf thanks for the rfc; please kindly update some parts to reflect our latest discussion.

[hudi-bot]

CI report:

• 3f6276e Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

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

[xushiyan]

LGTM

[vinothchandar]

We can land this RFC and keep it evolving as we enter the next phases