feat: [iceberg] Native scan by serializing FileScanTasks to iceberg-rust #2528
+6,808
−397
Conversation
This file contains hidden or 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
Codecov Report❌ Patch coverage is Additional details and impacted files@@ Coverage Diff @@
## main #2528 +/- ##
============================================
+ Coverage 56.12% 60.33% +4.20%
- Complexity 976 1498 +522
============================================
Files 119 149 +30
Lines 11743 14553 +2810
Branches 2251 2496 +245
============================================
+ Hits 6591 8780 +2189
- Misses 4012 4482 +470
- Partials 1140 1291 +151 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Contributor
|
It is promising! |
mbutrovich
changed the title
mbutrovich
force-pushed
the
iceberg-rust
branch
from
227332c to
6966a12
Compare
mbutrovich
changed the title
# Conflicts: # native/Cargo.lock # spark/src/main/scala/org/apache/comet/rules/CometScanRule.scala
…eberg version back to 1.8.1 after hitting known segfaults with old versions.
This was referenced Oct 15, 2025
liurenjie1024
pushed a commit
to apache/iceberg-rust
that referenced
this pull request
Oct 16, 2025
## Which issue does this PR close? - Part of #1749. ## What changes are included in this PR? - Change `ArrowReaderBuilder::new` to be `pub` instead of `pub(crate)`. ## Are these changes tested? - No new tests for this. Currently being used in DataFusion Comet: apache/datafusion-comet#2528
# Conflicts: # docs/source/user-guide/latest/configs.md # native/Cargo.lock # native/Cargo.toml # native/core/Cargo.toml
# Conflicts: # native/Cargo.lock
mbutrovich
changed the title
Contributor
Author
|
CI runs these already for PRs tagged |
…bug in iceberg-rust
liurenjie1024
pushed a commit
to apache/iceberg-rust
that referenced
this pull request
Nov 5, 2025
…ame FileScanTask (#1778) ## What issue does this PR close? Partially address #1749. ## Rationale for this change This PR fixes a bug in delete file loading when a `FileScanTask` contains both positional and equality delete files. We hit this when running Iceberg Java test suite via Comet in apache/datafusion-comet#2528. The tests that failed were ``` TestSparkExecutorCache > testMergeOnReadUpdate() TestSparkExecutorCache > testMergeOnReadMerge() TestSparkExecutorCache > testMergeOnReadDelete() ``` **The Bug:** The condition in `try_start_eq_del_load` (delete_filter.rs:71-73) was inverted. It returned `None` when the equality delete file was not in the cache, causing the loader to skip loading it. When `build_equality_delete_predicate` was later called, it would fail with "Missing predicate for equality delete file". ## What changes are included in this PR? **The Fix:** - Inverted the condition so it returns `None` when the file is already in the cache (being loaded or loaded), preventing duplicate work across concurrent tasks - When the file is not in the cache, mark it as Loading and proceed with loading **Additional Changes:** - Added test case `test_load_deletes_with_mixed_types` that reproduces the bug scenario ## Are these changes tested? Yes, this PR includes a new unit test `test_load_deletes_with_mixed_types` that: - Creates a `FileScanTask` with both a positional delete file and an equality delete file - Verifies that `load_deletes` successfully processes both types - Verifies that `build_equality_delete_predicate` succeeds without the "Missing predicate" error - We hit this when running Iceberg Java test suite via Comet in apache/datafusion-comet#2528. I also confirmed that it fixes the tests in Iceberg Java's suite. The test would fail before this fix and passes after.
# Conflicts: # dev/diffs/iceberg/1.8.1.diff
… have the constants_map set up in RecordBatchTransformer.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
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.
This PR introduces a new approach for integrating Apache Iceberg with Comet using iceberg-rust, enabling fully-native Iceberg table scans without requiring changes to upstream Iceberg Java code.
Rationale for this change
I was inspired by @RussellSpitzer's recent talk and wanted to revisit the abstraction layer at which Comet integrates with Iceberg.
Our current
iceberg_compatapproach requires code changes in Iceberg Java to integrate with Parquet reader instantiation, creating a tight coupling between Comet and Iceberg. This PR instead works at theFileScanTasklayer after Iceberg's planning phase is complete. This enables fully-native Iceberg scans (similar to ournative_datafusionscans) without any changes in upstream Iceberg Java code.All catalog access and planning continues to happen through Spark's Iceberg integration (unchanged), but file reading is delegated to iceberg-rust, which provides better parallelism and integrates naturally with Comet's native execution engine.
What changes are included in this PR?
This implementation follows a similar pattern to
CometNativeScanExecfor regular Parquet files, but extracts and serializes Iceberg'sFileScanTaskobjects:Scala/JVM Side:
CometIcebergNativeScanExecoperator that replaces Spark's IcebergBatchScanExecFileScanTaskobjects from Iceberg's planning outputNative/Rust Side:
IcebergScanExecoperator that consumes serializedFileScanTaskobjectsFileIOandArrowReaderto read data filesHow are these changes tested?
CometIcebergNativeSuitewith basic scenarios, but also a number of challenging situations from the Iceberg Java test suiteCometFuzzIcebergSuitethat we can adapt to Iceberg-specific logicIcebergReadFromS3Suiteto test passing basic S3 credentialsBenefits over
iceberg_compatnative_datafusion, not constrained by Iceberg Java's reader designArrowReaderCurrent Limitations & Open Questions
ArrowReaderOptionsto benefit from previous work in Arrow-rs Support different TimeUnits and timezones when reading Timestamps from INT96 arrow-rs#7285iceberg_compatcode and its Iceberg Java entanglementRelated Work
Slides from the 10/9/25 Iceberg-Rust community call: iceberg-rust.pdf