docs: Update Parquet scan documentation#3433
Conversation
Fix grammar, add encryption fallback and native_iceberg_compat hard-coded config limitations, clarify S3 section applies to both scan implementations, and remove orphaned link references. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Clarify which limitations fall back to Spark vs which may produce incorrect results. Add missing documented limitations for native_datafusion (DPP, input_file_name, metadata columns). Fix misleading wording for ignoreCorruptFiles/ignoreMissingFiles. Note that auto mode currently always selects native_iceberg_compat. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
The section intro already states all limitations fall back to Spark, so individual bullet points don't need to repeat it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Restructure shared and per-scan limitation lists into two clear categories: features that fall back to Spark (safe) and issues that may produce incorrect results without falling back. Remove redundant "Comet falls back to Spark" from individual bullets where the section intro already states it. Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
| Comet currently has two distinct implementations of the Parquet scan operator. | ||
|
|
||
| The two implementations are `native_datafusion` and `native_iceberg_compat`. They both delegate to DataFusion's |
There was a problem hiding this comment.
| Comet currently has two distinct implementations of the Parquet scan operator. | |
| The two implementations are `native_datafusion` and `native_iceberg_compat`. They both delegate to DataFusion's | |
| Comet currently has following distinct implementations of the Parquet scan operator | |
| - `native_datafusion` | |
| - `native_iceberg_compat` | |
mbutrovich
left a comment
There was a problem hiding this comment.
Some suggested changes.
| If the data originates from `native_comet` scan (deprecated, will be removed in a future release) or from | ||
| `native_iceberg_compat` in some cases, then ownership is not transferred to native and the JVM may re-use the | ||
| underlying buffers in the future. | ||
| If the data originates from a scan that uses mutable buffers (such Iceberg scans using the Iceberg Java integration path), |
There was a problem hiding this comment.
Iceberg Java is a bit ambiguous since the native reader still needs Iceberg Java for planning. We could link to the hybrid reader here:
https://datafusion.apache.org/comet/user-guide/latest/iceberg.html#hybrid-reader
I am interested in standardizing terminology on referring to this codepath as a legacy path.
|
|
||
| The two implementations are `native_datafusion` and `native_iceberg_compat`. They both delegate to DataFusion's | ||
| `DataSourceExec`. The main difference between these implementations is that `native_datafusion` runs fully natively, and | ||
| `native_iceberg_compat` is a hybrid JVM/Rust implementation that can support some Spark features that |
There was a problem hiding this comment.
This sentence is hard to follow with the subject switching back and forth, making it unclear what "but has some performance overhead due to crossing the JVM/Rust boundary." is actually referring to. Suggest breaking it up.
| The configuration property | ||
| `spark.comet.scan.impl` is used to select an implementation. The default setting is `spark.comet.scan.impl=auto`, which | ||
| currently always uses the `native_iceberg_compat` implementation. Most users should not need to change this setting. | ||
| However, it is possible to force Comet to try and use a particular implementation for all scan operations by setting |
There was a problem hiding this comment.
"to try and" is not doing anything here. Suggest removing.
| Julian/Gregorian calendar), dates/timestamps will be read as if they were written using the Proleptic Gregorian | ||
| calendar. This may produce incorrect results for dates before October 15, 1582. | ||
|
|
||
| The `native_datafusion` scan has some additional limitations. All of these cause Comet to fall back to Spark. |
There was a problem hiding this comment.
mostly related to Parquet metadata columns.
Co-authored-by: Oleks V <comphead@users.noreply.github.com>
Overview
This PR removes all references to the deprecated
native_cometscan implementation from the documentation andconfiguration, and improves the accuracy and clarity of the Parquet scan documentation.
Changed Files
common/src/main/scala/org/apache/comet/CometConf.scalaspark.comet.scan.implfromCATEGORY_SCANtoCATEGORY_PARQUETnative_datafusionandnative_iceberg_compatwithout referencingnative_comet.internal()marker, making this configuration visible to usersdocs/source/contributor-guide/parquet_scans.mdMajor rewrite of the Parquet scan documentation:
native_cometscan (previously listed as one of three implementations)native_cometand the "benefits over native_comet" sectionnative_cometS3 section (which described Hadoop-AWS-based S3 access)native_datafusionandnative_iceberg_compat(previously only referenced
native_datafusion)automode currently always selectsnative_iceberg_compatresults with reduced performance
for both scans, hard-coded config defaults for
native_iceberg_compat)native_datafusionlimitations that cause fallback:input_file_name(),input_file_block_start(),input_file_block_length()SQL functions_metadata.file_path)ignoreMissingFiles/ignoreCorruptFiles(previously said "not compatible with Spark",now clarifies it falls back to Spark)
#1545,#1758) that referenced oldnative_datafusionissuesdocs/source/contributor-guide/ffi.mdnative_cometwith a general description of scans that use mutable buffersdocs/source/contributor-guide/roadmap.mdnative_comettonative_iceberg_compattransition