[HUDI-52] Enabling savepoint and restore for MOR table

[nsivabalan]

What is the purpose of the pull request

Adding/Enabling restore for MOR table

Brief change log

• Enabling restore for MOR table.

Verify this pull request

This change added tests and can be verified as follows:

• TestHoodieSparkMergeOnReadTableRollback.testMORTableRestore

• Verified the below cases manually (without metadata enabled) via hudi-cli
  a. insert, upsert, upsert, savepoint, upsert, rollback. validate records.
  b. insert, upsert, upsert, savepoint, upsert, upsert, rollback. validate records.
  c. insert, upsert, upsert, savepoint, upsert, insert, rollback. validate records.
  d. insert, upsert, upsert, savepoint, upsert, upsert, compact, rollback. validate records.
  e. insert, upsert, upsert, savepoint, upsert, upsert, compact, upsert, rollback. validate records. upsert, validate records.

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.

[codope]

Change looks good to me. Can you please check the CI failure? The same test failed even after retrying.

[hudi-bot]

CI report:

• cb52a5a Azure: SUCCESS

Bot commands

@hudi-bot supports the following commands:

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

[vinothchandar]

I was kind of (pleasantly) surprised how simple this was.
How about these scenarios?

• If we perform a savepoint from the CLI, while there are inflight writes or pending table services?
• In line 92, we only work with the base file view? how would this correctly restore the log data?

[vinothchandar]

Key thing to verify here is that - compaction or cleaning does not affect the file slice that is part of the save point

[nsivabalan]

If we perform a savepoint from the CLI, while there are inflight writes or pending table services?
A: Do you mean "savepoint" or "restore" in above question? If its "savepoint", savepoint can be done only on completed commit. so should not matter if there are any new write in flight. if you meant "restore", as we know, restore is a destructive operation and users are advised to stop all pipelines before they trigger restore. or can expect all queries to fail when they trigger restore.

In line 92, we only work with the base file view? how would this correctly restore the log data?
A: yes, even I was surprised. Its mainly because of the way our cleaning and rollback works. Both works at file slice level. i..e cleaner will clean up only entire file slice(if entire file slice is eligible to be cleaned up). and rollback will remove/delete data and log files only if entire file slice is expected to be rolledback. If not, rollback will just do a append of log blocks. And so, we don't need to do any special handling for log files in general wrt savepoint and restore.

[nsivabalan]

Key thing to verify here is that - compaction or cleaning does not affect the file slice that is part of the save point
A: I understand cleaning should not affect the file slice as part of the savepoint. but don't quite get you why compaction should not ? can you please clarify.

[nsivabalan]

Tested savepoint/restore for all cases that I can think of. documented the cases here https://issues.apache.org/jira/browse/HUDI-3705