Reading a Variant column from Parquet files with different shredding layouts null-fills typed_value; every shredded field then reads as NULL, with no error

Aperta
#27,089 10 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
35/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Attiva
Stack tecnologico
rust
Ambito
backend, databases

Direzione di ricerca

Start with the linked schema inference and rewrite functions in datafusion/datasource-parquet/src/file_format.rs and datafusion/physical-expr-adapter/src/schema_rewriter.rs, then read #26282 and the Variant shredding specification. Reproduce with the two mixed-layout Parquet cases in the issue and trace how the adapter handles the missing typed_value children. Done means mixed layouts preserve the Variant fields across files, with coverage for both cases.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Part of #26517.

Is your feature request related to a problem or challenge?

I have a table of Parquet files with one Variant column, event. Each row is a small JSON object like {"service":"api","status":200,"latency_ms":12}. The files were not all written the same way:

  • a.parquet is shredded on service and status. Those two fields are stored as typed columns under typed_value; the rest stays in value.
  • b.parquet is not shredded. The whole object is in value, there is no typed_value.

Both files hold the same 3 rows. Spark reads a table like this fine. Each file also reads fine on its own in DataFusion.

Query (with datafusion-variant registered):

SELECT variant_get(event, 'service', 'VARCHAR') AS service FROM events

What I get:

+---------+
| service |
+---------+
| api     |   <- a.parquet
| api     |
| db      |
|         |   <- b.parquet
|         |
|         |
+---------+

What I expect: api, api, db for both files, so 6 non-null rows. That is what each file returns on its own.

What happens: the merged table schema has typed_value, and b.parquet does not. The schema adapter fills typed_value with NULL for that file. For a plain struct that is right. For Variant it is not: the shredding spec says a NULL typed_value means "this value is not an object", so the reader never looks in value for service. The data is still there, it is just skipped. No error, no warning.

The same thing happens when two files are shredded on different fields. Before #26195 that case failed at open; on branch-56 it null-fills too.

Describe the solution you'd like

Let an extension type decide how a file's layout maps to the table's layout, instead of the default struct null-fill. The Variant version would live in datafusion-variant. Per the discussion below I am starting with a PhysicalExprAdapter there and will report back on what, if anything, core needs.

Additional context

Repro: a 90-line Rust program that writes the two files with arrow-rs shred_variant and runs the query. It is in the edit history of this issue; I will replace it with a SQL-only version once datafusion-contrib/datafusion-variant#145 (COPY ... OPTIONS ('variant.shredding' ...)) lands.

DataFusion branch-56 at 1635ed9, arrow/parquet 60.1, datafusion-variant 642248a.

Lingua principale
Rust
Stelle
9.6k
Fork
2.6k
Merge medio
3g 4h
PR unite (30g)
345

Preparare l'ambiente

Apri in Codespaces

Avvia il container di sviluppo del progetto nel browser, con il tuo account GitHub.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di apache/datafusion

Tutte le issue di apache/datafusion

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.