Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[HUDI-8570] Use secondary index only for snapshot queries #12322

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

codope
Copy link
Member

@codope codope commented Nov 23, 2024

Change Logs

Use secondary index only for snapshot queries. Skip sec index and fallback to regular query path for query types such as time travel and incremental. SecondaryIndexSupport subclasses RecordLevelIndexSupport and supportsQueryType of RLI is reused -

override def supportsQueryType(options: Map[String, String]): Boolean = {

Added a test with time travel query and filter having column for which secondary index available. Test validates record is as of previous timestamp provided in query, and attached screenshot below where supportsQueryType API returns false.
Screenshot 2024-11-23 at 5 52 09 PM

Impact

Use secondary index only for snapshot queries.

Risk level (write none, low medium or high below)

low

Documentation Update

Describe any necessary documentation update if there is any new feature, config, or user-facing change. If not, put "none".

  • The config description must be updated if new configs are added or the default value of the configs are changed
  • Any new feature or user-facing change requires updating the Hudi website. Please create a Jira ticket, attach the
    ticket number here and follow the instruction to make
    changes to the website.

Contributor's checklist

  • Read through contributor's guide
  • Change Logs and Impact were stated clearly
  • Adequate tests were added if applicable
  • CI passed

@github-actions github-actions bot added the size:M PR with lines of changes in (100, 300] label Nov 23, 2024
@hudi-bot
Copy link

CI report:

Bot commands @hudi-bot supports the following commands:
  • @hudi-bot run azure re-run the last Azure build

@nsivabalan
Copy link
Contributor

also, do we have a similar test for RLI ? if not can we add one

@codope
Copy link
Member Author

codope commented Nov 23, 2024

also, do we have a similar test for RLI ? if not can we add one

Yes we have one here -

def testReadOptimizedAndTimeTravelWithRecordIndex(): Unit = {

// updated record should still show in time travel view
assertEquals(1, timeTravelDF.where(s"_row_key = '$recordKeyToUpdate'").count())
// rider field (secondary key) should point to previous value
val secondaryKey = timeTravelDF.where(s"_row_key = '$recordKeyToUpdate'").select("rider").collect().head.getString(0)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

so, this test will succeed even if there is a bug where we poll sec index for time travel query right?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you corrupt one of the data files and ensure time travel fails. we are likely testing the reverse of it.
i.e. if sec index pruning kicked in, the corrupted file will not be read and the query will succeed.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you corrupt one of the data files and ensure time travel fails.

I did not get this part. If the data file is corrupt, then it should fail anyway irrespective of whether time travel used sec index or not. What this test checks is that we get valid previous value (as of first commit) and the screenshot in PR description shows that the secondary index pruning did not kick in at all because it does not support time travel query.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I trust w/ your screen shot that it works today. but the purpose of adding a test case is, tomorrow if someone changes anything the test should fail. i.e. unintentionally if time travel was looking up in secondary index.

So, to account for that. in addition to your existing assertions. can we do the following:

  • just go through ur usual test set up
  • add assertion that time travel works.
  • corrupt one of the data file which should not match if secondary index was looked up.
  • now re-execute the time travel query and assert for exception. Our theory here is that, SI lookup should not happen and hence all file slices will be read and hence the corrupt data file will be read and it will be thrown.
    here the assertion for exception is important.
    So, w/ this test, in future if someone untentionally reverts and ends up looking up in SI for a TT query, this test will fail since it may not throw exception

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
size:M PR with lines of changes in (100, 300]
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants