This is an automated email from the ASF dual-hosted git repository.
agrove pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/datafusion-comet.git
The following commit(s) were added to refs/heads/main by this push:
new dba523d99 docs: Various documentation updates (#2674)
dba523d99 is described below
commit dba523d994f3f8336d2c5ca469c61672768611a1
Author: Andy Grove <[email protected]>
AuthorDate: Mon Nov 3 13:52:32 2025 -0700
docs: Various documentation updates (#2674)
---
docs/source/contributor-guide/index.md | 1 +
docs/source/contributor-guide/parquet_scans.md | 137 +++++++++++++++++++++++++
docs/source/user-guide/latest/compatibility.md | 68 ++----------
docs/source/user-guide/latest/datasources.md | 72 +------------
4 files changed, 149 insertions(+), 129 deletions(-)
diff --git a/docs/source/contributor-guide/index.md
b/docs/source/contributor-guide/index.md
index ba4692a97..eb79f7ab5 100644
--- a/docs/source/contributor-guide/index.md
+++ b/docs/source/contributor-guide/index.md
@@ -26,6 +26,7 @@ under the License.
Getting Started <contributing>
Comet Plugin Overview <plugin_overview>
Arrow FFI <ffi>
+Parquet Scans <parquet_scans>
Development Guide <development>
Debugging Guide <debugging>
Benchmarking Guide <benchmarking>
diff --git a/docs/source/contributor-guide/parquet_scans.md
b/docs/source/contributor-guide/parquet_scans.md
new file mode 100644
index 000000000..4aec9f347
--- /dev/null
+++ b/docs/source/contributor-guide/parquet_scans.md
@@ -0,0 +1,137 @@
+<!--
+Licensed to the Apache Software Foundation (ASF) under one
+or more contributor license agreements. See the NOTICE file
+distributed with this work for additional information
+regarding copyright ownership. The ASF licenses this file
+to you under the Apache License, Version 2.0 (the
+"License"); you may not use this file except in compliance
+with the License. You may obtain a copy of the License at
+
+ http://www.apache.org/licenses/LICENSE-2.0
+
+Unless required by applicable law or agreed to in writing,
+software distributed under the License is distributed on an
+"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+KIND, either express or implied. See the License for the
+specific language governing permissions and limitations
+under the License.
+-->
+
+# Comet Parquet Scan Implementations
+
+Comet currently has three distinct implementations of the Parquet scan
operator. The configuration property
+`spark.comet.scan.impl` is used to select an implementation. The default
setting is `spark.comet.scan.impl=auto`, and
+Comet will choose the most appropriate implementation based on the Parquet
schema and other Comet configuration
+settings. 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 this
configuration property to one of the following
+implementations.
+
+| Implementation | Description
|
+| ----------------------- |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
+| `native_comet` | This implementation provides strong compatibility
with Spark but does not support complex types. This is the original scan
implementation in Comet and may eventually be removed. |
+| `native_iceberg_compat` | This implementation delegates to DataFusion's
`DataSourceExec` but uses a hybrid approach of JVM and native code. This scan
is designed to be integrated with Iceberg in the future. |
+| `native_datafusion` | This experimental implementation delegates to
DataFusion's `DataSourceExec` for full native execution. There are known
compatibility issues when using this scan. |
+
+The `native_datafusion` and `native_iceberg_compat` scans provide the
following benefits over the `native_comet`
+implementation:
+
+- Leverages the DataFusion community's ongoing improvements to `DataSourceExec`
+- Provides support for reading complex types (structs, arrays, and maps)
+- Removes the use of reusable mutable-buffers in Comet, which is complex to
maintain
+- Improves performance
+
+The `native_datafusion` and `native_iceberg_compat` scans share the following
limitations:
+
+- When reading Parquet files written by systems other than Spark that contain
columns with the logical types `UINT_8`
+ or `UINT_16`, Comet will produce different results than Spark because Spark
does not preserve or understand these
+ logical types. Arrow-based readers, such as DataFusion and Comet do respect
these types and read the data as unsigned
+ rather than signed. By default, Comet will fall back to `native_comet` when
scanning Parquet files containing `byte` or `short`
+ types (regardless of the logical type). This behavior can be disabled by
setting
+ `spark.comet.scan.allowIncompatible=true`.
+- No support for default values that are nested types (e.g., maps, arrays,
structs). Literal default values are supported.
+
+The `native_datafusion` scan has some additional limitations:
+
+- Bucketed scans are not supported
+- No support for row indexes
+- `PARQUET_FIELD_ID_READ_ENABLED` is not respected [#1758]
+- There are failures in the Spark SQL test suite [#1545]
+- Setting Spark configs `ignoreMissingFiles` or `ignoreCorruptFiles` to `true`
is not compatible with Spark
+
+## S3 Support
+
+There are some
+
+### `native_comet`
+
+The default `native_comet` Parquet scan implementation reads data from S3
using the [Hadoop-AWS
module](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html),
which
+is identical to the approach commonly used with vanilla Spark. AWS credential
configuration and other Hadoop S3A
+configurations works the same way as in vanilla Spark.
+
+### `native_datafusion` and `native_iceberg_compat`
+
+The `native_datafusion` and `native_iceberg_compat` Parquet scan
implementations completely offload data loading
+to native code. They use the [`object_store`
crate](https://crates.io/crates/object_store) to read data from S3 and
+support configuring S3 access using standard [Hadoop S3A
configurations](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html#General_S3A_Client_configuration)
by translating them to
+the `object_store` crate's format.
+
+This implementation maintains compatibility with existing Hadoop S3A
configurations, so existing code will
+continue to work as long as the configurations are supported and can be
translated without loss of functionality.
+
+#### Additional S3 Configuration Options
+
+Beyond credential providers, the `native_datafusion` implementation supports
additional S3 configuration options:
+
+| Option | Description |
+|--------|-------------|
+| `fs.s3a.endpoint` | The endpoint of the S3 service |
+| `fs.s3a.endpoint.region` | The AWS region for the S3 service. If not
specified, the region will be auto-detected. |
+| `fs.s3a.path.style.access` | Whether to use path style access for the S3
service (true/false, defaults to virtual hosted style) |
+| `fs.s3a.requester.pays.enabled` | Whether to enable requester pays for S3
requests (true/false) |
+
+All configuration options support bucket-specific overrides using the pattern
`fs.s3a.bucket.{bucket-name}.{option}`.
+
+#### Examples
+
+The following examples demonstrate how to configure S3 access with the
`native_datafusion` Parquet scan implementation using different authentication
methods.
+
+**Example 1: Simple Credentials**
+
+This example shows how to access a private S3 bucket using an access key and
secret key. The `fs.s3a.aws.credentials.provider` configuration can be omitted
since `org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider` is included in
Hadoop S3A's default credential provider chain.
+
+```shell
+$SPARK_HOME/bin/spark-shell \
+...
+--conf spark.comet.scan.impl=native_datafusion \
+--conf spark.hadoop.fs.s3a.access.key=my-access-key \
+--conf spark.hadoop.fs.s3a.secret.key=my-secret-key
+...
+```
+
+**Example 2: Assume Role with Web Identity Token**
+
+This example demonstrates using an assumed role credential to access a private
S3 bucket, where the base credential for assuming the role is provided by a web
identity token credentials provider.
+
+```shell
+$SPARK_HOME/bin/spark-shell \
+...
+--conf spark.comet.scan.impl=native_datafusion \
+--conf
spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.auth.AssumedRoleCredentialProvider
\
+--conf
spark.hadoop.fs.s3a.assumed.role.arn=arn:aws:iam::123456789012:role/my-role \
+--conf spark.hadoop.fs.s3a.assumed.role.session.name=my-session \
+--conf
spark.hadoop.fs.s3a.assumed.role.credentials.provider=com.amazonaws.auth.WebIdentityTokenCredentialsProvider
+...
+```
+
+#### Limitations
+
+The S3 support of `native_datafusion` has the following limitations:
+
+1. **Partial Hadoop S3A configuration support**: Not all Hadoop S3A
configurations are currently supported. Only the configurations listed in the
tables above are translated and applied to the underlying `object_store` crate.
+
+2. **Custom credential providers**: Custom implementations of AWS credential
providers are not supported. The implementation only supports the standard
credential providers listed in the table above. We are planning to add support
for custom credential providers through a JNI-based adapter that will allow
calling Java credential providers from native code. See [issue
#1829](https://github.com/apache/datafusion-comet/issues/1829) for more details.
+
+
+
+[#1545]: https://github.com/apache/datafusion-comet/issues/1545
+[#1758]: https://github.com/apache/datafusion-comet/issues/1758
diff --git a/docs/source/user-guide/latest/compatibility.md
b/docs/source/user-guide/latest/compatibility.md
index ac2be802d..908693ff5 100644
--- a/docs/source/user-guide/latest/compatibility.md
+++ b/docs/source/user-guide/latest/compatibility.md
@@ -25,59 +25,11 @@ This guide offers information about areas of functionality
where there are known
## Parquet
-### Data Type Support
+Comet has the following limitations when reading Parquet files:
-Comet does not support reading decimals encoded in binary format.
-
-### Parquet Scans
-
-Comet currently has three distinct implementations of the Parquet scan
operator. The configuration property
-`spark.comet.scan.impl` is used to select an implementation. The default
setting is `spark.comet.scan.impl=auto`, and
-Comet will choose the most appropriate implementation based on the Parquet
schema and other Comet configuration
-settings. 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 this
configuration property to one of the following
-implementations.
-
-| Implementation | Description
|
-| ----------------------- |
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
|
-| `native_comet` | This implementation provides strong compatibility
with Spark but does not support complex types. This is the original scan
implementation in Comet and may eventually be removed. |
-| `native_iceberg_compat` | This implementation delegates to DataFusion's
`DataSourceExec` but uses a hybrid approach of JVM and native code. This scan
is designed to be integrated with Iceberg in the future. |
-| `native_datafusion` | This experimental implementation delegates to
DataFusion's `DataSourceExec` for full native execution. There are known
compatibility issues when using this scan. |
-
-The `native_datafusion` and `native_iceberg_compat` scans provide the
following benefits over the `native_comet`
-implementation:
-
-- Leverages the DataFusion community's ongoing improvements to `DataSourceExec`
-- Provides support for reading complex types (structs, arrays, and maps)
-- Removes the use of reusable mutable-buffers in Comet, which is complex to
maintain
-- Improves performance
-
-The `native_datafusion` and `native_iceberg_compat` scans share the following
limitations:
-
-- When reading Parquet files written by systems other than Spark that contain
columns with the logical types `UINT_8`
- or `UINT_16`, Comet will produce different results than Spark because Spark
does not preserve or understand these
- logical types. Arrow-based readers, such as DataFusion and Comet do respect
these types and read the data as unsigned
- rather than signed. By default, Comet will fall back to `native_comet` when
scanning Parquet files containing `byte` or `short`
- types (regardless of the logical type). This behavior can be disabled by
setting
- `spark.comet.scan.allowIncompatible=true`.
+- Comet does not support reading decimals encoded in binary format.
- No support for default values that are nested types (e.g., maps, arrays,
structs). Literal default values are supported.
-The `native_datafusion` scan has some additional limitations:
-
-- Bucketed scans are not supported
-- No support for row indexes
-- `PARQUET_FIELD_ID_READ_ENABLED` is not respected [#1758]
-- There are failures in the Spark SQL test suite [#1545]
-- Setting Spark configs `ignoreMissingFiles` or `ignoreCorruptFiles` to `true`
is not compatible with Spark
-
-[#1545]: https://github.com/apache/datafusion-comet/issues/1545
-[#1758]: https://github.com/apache/datafusion-comet/issues/1758
-
-### S3 Support with `native_iceberg_compat`
-
-- When using the default AWS S3 endpoint (no custom endpoint configured), a
valid region is required. Comet
- will attempt to resolve the region if it is not provided.
-
## ANSI Mode
Comet will fall back to Spark for the following expressions when ANSI mode is
enabled, unless
@@ -101,18 +53,14 @@ Sorting on floating-point data types (or complex types
containing floating-point
Spark if the data contains both zero and negative zero. This is likely an edge
case that is not of concern for many users
and sorting on floating-point data can be enabled by setting
`spark.comet.expression.SortOrder.allowIncompatible=true`.
-There is a known bug with using count(distinct) within aggregate queries,
where each NaN value will be counted
-separately [#1824](https://github.com/apache/datafusion-comet/issues/1824).
-
## Incompatible Expressions
-Some Comet native expressions are not 100% compatible with Spark and are
disabled by default. These expressions
-will fall back to Spark but can be enabled by setting
`spark.comet.expression.allowIncompatible=true`.
-
-## Array Expressions
+Expressions that are not 100% Spark-compatible will fall back to Spark by
default and can be enabled by setting
+`spark.comet.expression.EXPRNAME.allowIncompatible=true`, where `EXPRNAME` is
the Spark expression class name. See
+the [Comet Supported Expressions Guide](expressions.md) for more information
on this configuration setting.
-Comet has experimental support for a number of array expressions. These are
experimental and currently marked
-as incompatible and can be enabled by setting
`spark.comet.expression.allowIncompatible=true`.
+It is also possible to specify `spark.comet.expression.allowIncompatible=true`
to enable all
+incompatible expressions.
## Regular Expressions
@@ -127,7 +75,7 @@ Cast operations in Comet fall into three levels of support:
- **Compatible**: The results match Apache Spark
- **Incompatible**: The results may match Apache Spark for some inputs, but
there are known issues where some inputs
will result in incorrect results or exceptions. The query stage will fall
back to Spark by default. Setting
- `spark.comet.expression.allowIncompatible=true` will allow all incompatible
casts to run natively in Comet, but this is not
+ `spark.comet.expression.Cast.allowIncompatible=true` will allow all
incompatible casts to run natively in Comet, but this is not
recommended for production use.
- **Unsupported**: Comet does not provide a native version of this cast
expression and the query stage will fall back to
Spark.
diff --git a/docs/source/user-guide/latest/datasources.md
b/docs/source/user-guide/latest/datasources.md
index 7525c2f45..e2f3f8d1a 100644
--- a/docs/source/user-guide/latest/datasources.md
+++ b/docs/source/user-guide/latest/datasources.md
@@ -163,23 +163,11 @@ Or use `spark-shell` with HDFS support as described
[above](#using-experimental-
## S3
-DataFusion Comet has [multiple Parquet scan
implementations](./compatibility.md#parquet-scans) that use different
approaches to read data from S3.
-
-### `native_comet`
-
-The default `native_comet` Parquet scan implementation reads data from S3
using the [Hadoop-AWS
module](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html),
which is identical to the approach commonly used with vanilla Spark. AWS
credential configuration and other Hadoop S3A configurations works the same way
as in vanilla Spark.
-
-### `native_datafusion` and `native_iceberg_compat`
-
-The `native_datafusion` and `native_iceberg_compat` Parquet scan
implementations completely offload data loading to native code. They use the
[`object_store` crate](https://crates.io/crates/object_store) to read data from
S3 and support configuring S3 access using standard [Hadoop S3A
configurations](https://hadoop.apache.org/docs/stable/hadoop-aws/tools/hadoop-aws/index.html#General_S3A_Client_configuration)
by translating them to the `object_store` crate's format.
-
-This implementation maintains compatibility with existing Hadoop S3A
configurations, so existing code will continue to work as long as the
configurations are supported and can be translated without loss of
functionality.
-
#### Root CA Certificates
-One major difference between `native_comet` and the other scan implementations
is the mechanism for discovering Root
-CA Certificates. The `native_comet` scan uses the JVM to read CA Certificates
from the Java Trust Store, but the native
-scan implementations `native_datafusion` and `native_iceberg_compat` use
system Root CA Certificates (typically stored
+One major difference between Spark and Comet is the mechanism for discovering
Root
+CA Certificates. Spark uses the JVM to read CA Certificates from the Java
Trust Store, but native Comet
+scans use system Root CA Certificates (typically stored
in `/etc/ssl/certs` on Linux). These scans will not be able to interact with
S3 if the Root CA Certificates are not
installed.
@@ -200,57 +188,3 @@ AWS credential providers can be configured using the
`fs.s3a.aws.credentials.pro
|
`com.amazonaws.auth.WebIdentityTokenCredentialsProvider`<br/>`software.amazon.awssdk.auth.credentials.WebIdentityTokenFileCredentialsProvider`
| Authenticate using web identity token file | None |
Multiple credential providers can be specified in a comma-separated list using
the `fs.s3a.aws.credentials.provider` configuration, just as Hadoop AWS
supports. If `fs.s3a.aws.credentials.provider` is not configured, Hadoop S3A's
default credential provider chain will be used. All configuration options also
support bucket-specific overrides using the pattern
`fs.s3a.bucket.{bucket-name}.{option}`.
-
-#### Additional S3 Configuration Options
-
-Beyond credential providers, the `native_datafusion` implementation supports
additional S3 configuration options:
-
-| Option | Description |
-|--------|-------------|
-| `fs.s3a.endpoint` | The endpoint of the S3 service |
-| `fs.s3a.endpoint.region` | The AWS region for the S3 service. If not
specified, the region will be auto-detected. |
-| `fs.s3a.path.style.access` | Whether to use path style access for the S3
service (true/false, defaults to virtual hosted style) |
-| `fs.s3a.requester.pays.enabled` | Whether to enable requester pays for S3
requests (true/false) |
-
-All configuration options support bucket-specific overrides using the pattern
`fs.s3a.bucket.{bucket-name}.{option}`.
-
-#### Examples
-
-The following examples demonstrate how to configure S3 access with the
`native_datafusion` Parquet scan implementation using different authentication
methods.
-
-**Example 1: Simple Credentials**
-
-This example shows how to access a private S3 bucket using an access key and
secret key. The `fs.s3a.aws.credentials.provider` configuration can be omitted
since `org.apache.hadoop.fs.s3a.SimpleAWSCredentialsProvider` is included in
Hadoop S3A's default credential provider chain.
-
-```shell
-$SPARK_HOME/bin/spark-shell \
-...
---conf spark.comet.scan.impl=native_datafusion \
---conf spark.hadoop.fs.s3a.access.key=my-access-key \
---conf spark.hadoop.fs.s3a.secret.key=my-secret-key
-...
-```
-
-**Example 2: Assume Role with Web Identity Token**
-
-This example demonstrates using an assumed role credential to access a private
S3 bucket, where the base credential for assuming the role is provided by a web
identity token credentials provider.
-
-```shell
-$SPARK_HOME/bin/spark-shell \
-...
---conf spark.comet.scan.impl=native_datafusion \
---conf
spark.hadoop.fs.s3a.aws.credentials.provider=org.apache.hadoop.fs.s3a.auth.AssumedRoleCredentialProvider
\
---conf
spark.hadoop.fs.s3a.assumed.role.arn=arn:aws:iam::123456789012:role/my-role \
---conf spark.hadoop.fs.s3a.assumed.role.session.name=my-session \
---conf
spark.hadoop.fs.s3a.assumed.role.credentials.provider=com.amazonaws.auth.WebIdentityTokenCredentialsProvider
-...
-```
-
-#### Limitations
-
-The S3 support of `native_datafusion` has the following limitations:
-
-1. **Partial Hadoop S3A configuration support**: Not all Hadoop S3A
configurations are currently supported. Only the configurations listed in the
tables above are translated and applied to the underlying `object_store` crate.
-
-2. **Custom credential providers**: Custom implementations of AWS credential
providers are not supported. The implementation only supports the standard
credential providers listed in the table above. We are planning to add support
for custom credential providers through a JNI-based adapter that will allow
calling Java credential providers from native code. See [issue
#1829](https://github.com/apache/datafusion-comet/issues/1829) for more details.
-
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
