You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem or challenge?
When scanning Parquet files, we'd often like to provide an expected schema, since:
The Parquet files might not all have an identical physical schema, but we may know the unified schema up front, such as when we are using a table format like Delta Lake.
A given Parquet type can map to many different Arrow types. For example, when possible it would be nice to read a string column as a DictionaryArray, especially if the data is already dictionary-encoded.
Describe the solution you'd like
It would be nice to be able to provide an Arrow schema in ParquetScanOptions, and then the scan would try in order:
Read the Parquet data directly into the output type
Read the Parquet data into a supported Arrow type then cast
Return an error stating which types can't be mapped
This probably would require some changes upstream in the parquet crate, but for at least some of the functionality datafusion seems like the right place. LMK if you think differently.
Describe alternatives you've considered
Right now our current issue is that our expected schema (from the Delta Lake log) doesn't match the physical schema (at least when written by Spark). So as a workaround we are looking at the metadata of one of the Parquet files. This will partially solve the issue, but will likely fail for tables where Spark wasn't the only engine to write to the table.
Additional context
Here's a simple example where PyArrow's scanner works but Datafusions doesn't seem to:
Is your feature request related to a problem or challenge?
When scanning Parquet files, we'd often like to provide an expected schema, since:
Describe the solution you'd like
It would be nice to be able to provide an Arrow schema in
ParquetScanOptions
, and then the scan would try in order:This probably would require some changes upstream in the parquet crate, but for at least some of the functionality datafusion seems like the right place. LMK if you think differently.
Describe alternatives you've considered
Right now our current issue is that our expected schema (from the Delta Lake log) doesn't match the physical schema (at least when written by Spark). So as a workaround we are looking at the metadata of one of the Parquet files. This will partially solve the issue, but will likely fail for tables where Spark wasn't the only engine to write to the table.
Additional context
Here's a simple example where PyArrow's scanner works but Datafusions doesn't seem to:
The text was updated successfully, but these errors were encountered: