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

refactor(iceberg): support eq delete merge on read with hash join #19126

Merged
merged 26 commits into from
Dec 2, 2024

Conversation

xxhZs
Copy link
Contributor

@xxhZs xxhZs commented Oct 25, 2024

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.

What's changed and what's your intention?

In this pr,#18448. We support iceberg merge on read.
But he still has some problems, such as when there is too much delete data, we may oom, and this pr, we use hashjoin to implement the merge on read of eq delete

Checklist

  • I have written necessary rustdoc comments
  • I have added necessary unit tests and integration tests
  • I have added test labels as necessary. See details.
  • I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features Sqlsmith: Sql feature generation #7934).
  • My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
  • All checks passed in ./risedev check (or alias, ./risedev c)
  • My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)
  • My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

  • My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note

If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

xxhZs added 4 commits October 15, 2024 11:41
save

save

save

save

support all
@xxhZs xxhZs marked this pull request as ready for review October 28, 2024 05:03
Copy link

gitguardian bot commented Oct 28, 2024

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request
GitGuardian id GitGuardian status Secret Commit Filename
9425213 Triggered Generic Password 0ec5b56 ci/scripts/e2e-source-test.sh View secret
🛠 Guidelines to remediate hardcoded secrets
  1. Understand the implications of revoking this secret by investigating where it is used in your code.
  2. Replace and store your secret safely. Learn here the best practices.
  3. Revoke and rotate this secret.
  4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider


🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.

@graphite-app graphite-app bot requested a review from a team October 28, 2024 05:48
@stdrc
Copy link
Member

stdrc commented Nov 1, 2024

Is this PR ready to review or just a draft?

@xxhZs
Copy link
Contributor Author

xxhZs commented Nov 1, 2024

Is this PR ready to review or just a draft?

ready to review

@stdrc
Copy link
Member

stdrc commented Nov 4, 2024

Is this PR ready to review or just a draft?

ready to review

What about adding some description? Thanks. Also, what does "mor" mean in the title? Is it "more"?

@xxhZs xxhZs changed the title refactor(iceberg): support eq delete mor with hash join refactor(iceberg): support eq delete merge on read with hash join Nov 4, 2024
@xxhZs xxhZs requested review from chenzl25 and kwannoel November 5, 2024 03:31
Comment on lines 56 to 60
let delete_column_names = std::thread::spawn(move || {
FRONTEND_RUNTIME.block_on(s.get_all_delete_column_names())
})
.join()
.unwrap()?;
Copy link
Contributor

Choose a reason for hiding this comment

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

Use tokio::task::block_in_place to wrap it. See

let schema = tokio::task::block_in_place(|| {

Copy link
Contributor

Choose a reason for hiding this comment

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

get_all_delete_column_names() internally calls iceberg plan_files(), so there will be at least 2 calls when we execute an iceberg query. I think we should consider moving the plan_files form IcebergSplitEnumerator to here after supporting the position delete hash join in the future.

@@ -266,7 +344,6 @@ impl IcebergSplitEnumerator {
data_files.push(IcebergFileScanTaskJsonStr::serialize(&task));
}
iceberg::spec::DataContentType::EqualityDeletes => {
task.project_field_ids = task.equality_ids.clone();
Copy link
Contributor

Choose a reason for hiding this comment

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

Why remove these field ids?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Because after this pr, we can make sure that the filed id from the select() step is the final id, so doesn't need to be changed here

Comment on lines 44 to +45
impl LogicalIcebergScan {
pub fn new(logical_source: &LogicalSource) -> Self {
pub fn new(logical_source: &LogicalSource, iceberg_scan_type: IcebergScanType) -> Self {
Copy link
Contributor

Choose a reason for hiding this comment

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

In my mind, different iceberg scan types should have different schemas. For example, equality delete should contain the exact delete columns that appear in the files instead of all columns of the iceberg table. Maybe we should change the core to have a generic::IcebergScan instead of generic::Source

save

save

fix comm
Copy link
Contributor

@kwannoel kwannoel left a comment

Choose a reason for hiding this comment

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

A more general question: Why only equality_delete leads to OOM, and position_delete is fine?

I see that the position_delete and file_scan tasks are grouped together. Only equality_delete is separate.

@kwannoel
Copy link
Contributor

A more general question: Why only equality_delete leads to OOM, and position_delete is fine?

I see that the position_delete and file_scan tasks are grouped together. Only equality_delete is separate.

Oh I suppose it's because equality_delete can be out-of-order, and requires the file_scan data to be buffered, so it can lookup and delete the corresponding records. Does this apply to position_delete?

@kwannoel
Copy link
Contributor

kwannoel commented Nov 11, 2024

Could you add an explain test inside iceberg e2e tests? We need to ensure that predicates will be pushed down through the hash_join that we constructed for eq delete merge on read. If the filter does not get pushed down, a lot of data could be joined, before filtering.

Something like https://github.com/risingwavelabs/risingwave/pull/19228/files#r1835945726

@xxhZs
Copy link
Contributor Author

xxhZs commented Nov 11, 2024

A more general question: Why only equality_delete leads to OOM, and position_delete is fine?

I see that the position_delete and file_scan tasks are grouped together. Only equality_delete is separate.

Oh, There will be the same problem, the position del will be modified in the next pr

Copy link
Contributor

@chenzl25 chenzl25 left a comment

Choose a reason for hiding this comment

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

Rest LGTM

use crate::utils::{Condition, FRONTEND_RUNTIME};

#[derive(Debug, Clone, Default)]
pub struct IcebergMergeOnReadRewriter {}
Copy link
Contributor

Choose a reason for hiding this comment

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

Currently, our optimizer rule supports returning an error after #19381 I think we can do a refactor later

@xxhZs xxhZs force-pushed the xxh/support_iceberg_mor branch from 93bd1cc to 8a306cf Compare November 28, 2024 03:39
@xxhZs xxhZs requested a review from a team as a code owner November 28, 2024 03:39
@xxhZs xxhZs requested a review from MrCroxx November 28, 2024 03:39
@xxhZs xxhZs force-pushed the xxh/support_iceberg_mor branch from 8a306cf to aea0f93 Compare November 28, 2024 03:42
@xxhZs xxhZs enabled auto-merge November 29, 2024 03:54
@xxhZs xxhZs force-pushed the xxh/support_iceberg_mor branch from 3f73545 to 7eb87de Compare November 29, 2024 09:54
@xxhZs xxhZs added this pull request to the merge queue Dec 2, 2024
@graphite-app graphite-app bot requested a review from a team December 2, 2024 05:29
Merged via the queue into main with commit 4dddbac Dec 2, 2024
33 of 34 checks passed
@xxhZs xxhZs deleted the xxh/support_iceberg_mor branch December 2, 2024 05:40
@chenzl25 chenzl25 mentioned this pull request Jan 7, 2025
17 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants