[HUDI-2862] Table upgrade and metadata table bootstrap under the table lock #4124
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
manojpec
changed the title
manojpec
force-pushed
the
fix/HUDI-2862-table-upgrade-metadata-table-bootstrap-under-table-lock
branch
from
8f6c03b
to
bd1b6ab
Compare
manojpec
changed the title
vinothchandar
requested changes
Nov 26, 2021
hudi-client/hudi-spark-client/src/main/java/org/apache/hudi/client/SparkRDDWriteClient.java
Outdated
Show resolved
Hide resolved
hudi-client/hudi-spark-client/src/main/java/org/apache/hudi/client/SparkRDDWriteClient.java
Show resolved
Hide resolved
5 tasks
manojpec
force-pushed
the
fix/HUDI-2862-table-upgrade-metadata-table-bootstrap-under-table-lock
branch
from
bd1b6ab
to
4be51b1
Compare
manojpec
force-pushed
the
fix/HUDI-2862-table-upgrade-metadata-table-bootstrap-under-table-lock
branch
2 times, most recently
from
3e0ca30
to
ec2388b
Compare
…ites
- Across upgrades, metadata table may have to be re-bootstrapped from the
data table. Usually it is detected by the first write client, and the
metadata table is fully removed and attempt is made to bootstrap. This
bootstrapping is deferred if there are pending actions on the timeline
and until they are resolved.
- Today, spark write client gets the metadata writer for every write.
The metadata writer initialization attempt is made only once to avoid
on the expensive fs exists check on every write path. If the metadata
bootstrapping fails in the first time due to pending actions (which is
usually the case after upgrade), the writer client never tries to
recreate it again, leading to it not updating the metadata table even
after bootstrapping by other writers.
- Fix is to retry metadata table creation until it is successful by
either its own bootstrapping or from the concurrent table services or
other writers
- SparkRDDWriteClient constructor will no more create the metadata table writer as it is one time only for the continuous mode and also can potentially race with same metadata table bootstrapping from other concurrent writers - Made the HoodieTable#getMetadataWriter() to always create the metadata table and there by attempt bootstrapping if needed to avoid continuous writers missing out the metadata table update - SparkRDDWriteClient#getTableAndInitCtx() will also attempt to create the metadata table just after the table upgrade to bootstrap if needed.
- When getting the metadata writer, the inflight instant timestamp is passed in so that the MetadataTableWriter can ignore the inflight action when bootstrapping the table if needed.
- Incorporating review comments on the variable naming and code style
… table lock - Today table upgrade need is detected by the first write client after upgrade and if there is write concurrency mode configured it grabs the transaction lock to protect the table upgrade from other concurrent writers. However, the follow on metadata table creation and the initial bootstrapping also needs similar global protection to avoid race in inflight commits and the metadata table bootstrapping proces. Made the table upgrade and the follow-on metadata table creation and there by the initial bootstrapping process under the table level lock to avoid potential race with concurrent writers and other async table services.
… table lock - Moving the check for under the table lock to make sure concurrent writers don't redo the upgrade work redundantly on race
manojpec
force-pushed
the
fix/HUDI-2862-table-upgrade-metadata-table-bootstrap-under-table-lock
branch
from
ec2388b
to
0aed0f2
Compare
nsivabalan
approved these changes
Nov 26, 2021
Closed
5 tasks
|
@nsivabalan Have opened #4134 in place of this to workaround rebase/merge issues |
|
This change is pulled into #4114. Closing this. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What is the purpose of the pull request
Today table upgrade need is detected by the first write client after upgrade
and if there is write concurrency mode configured it grabs the transaction
lock to protect the table upgrade from other concurrent writers. However, the
follow on metadata table creation and the initial bootstrapping also needs
similar global protection to avoid race in inflight commits and the metadata
table bootstrapping proces. Made the table upgrade and the follow-on metadata
table creation and there by the initial bootstrapping process under the
table level lock to avoid potential race with concurrent writers and other
async table services.
Brief change log
(for example:)
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:)
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.