Expose per-file write metadata from DataFrame.write_parquet()
Ninguém assumiu esta issue ainda.
Avaliação
- Dificuldade
- 4/5
- Tempo estimado
- 3-5 dias
- Facilidade para iniciantes
- 48/100
- Tipo de issue
- Funcionalidade
- Clareza
- Razoavelmente clara
- Status de atividade
- Pouca atividade
- Domínio
- backend-api-design, data-engineering
Direção de pesquisa
Comece verificando se apache/datafusion#23656 foi integrado e, em seguida, leia o binding Python de DataFrame.write_parquet() e a issue e o pull request vinculados do core Rust. O formato da API ainda está em aberto: a issue sugere retornar os metadados diretamente ou por meio de um WriteResult. Considera-se concluído quando os bindings expuserem os caminhos por arquivo, as contagens de linhas e os tamanhos em bytes; metadados serializados são opcionais.
Escrita pelo modelo de indexação a partir do texto da issue.
Descrição
Is your feature request related to a problem or challenge?
DataFrame.write_parquet() currently returns None. After writing, there is no way to retrieve per-file metadata (row counts, byte sizes, column statistics) for the files that were produced. This forces consumers that need file-level statistics — such as Apache Iceberg, Delta Lake, and Apache Hudi — to either:
- Re-read Parquet footers from object storage after writing (extra I/O round-trips)
- Bypass DataFusion's write pipeline entirely and use PyArrow's
ParquetWriterwithmetadata_collector
This is a blocker for building a complete DataFusion-based write backend for table formats that require per-file column statistics in their commit metadata (e.g., Iceberg's DataFile entries need column_sizes, null_counts, lower_bounds, upper_bounds, split_offsets).
Describe the solution you'd like
After apache/datafusion#23472 / apache/datafusion#23656 lands in the Rust core, ParquetSink will expose a file_metadata() method returning per-file path, row count, and byte size. The Python bindings should surface this:
# Option A: write_parquet returns metadata directly
metadata = df.write_parquet("/path/to/output/")
# metadata: list[dict] = [
# {"path": "part-0.parquet", "row_count": 500, "byte_size": 4096},
# {"path": "part-1.parquet", "row_count": 500, "byte_size": 3840},
# ]
# Option B: write_parquet returns a WriteResult object
result = df.write_parquet("/path/to/output/")
result.count # 1000
result.file_metadata # list of per-file metadata dicts
At minimum, each file metadata entry should include:
path(str): Object-store path of the written filerow_count(int): Number of rows in this filebyte_size(int): Sum of compressed row group sizes
Optionally (for full table-format integration):
metadata(bytes | None): Serialized ParquetFileMetaData(Thrift compact), enabling consumers to extract column statistics without re-reading the file
Describe alternatives you've considered
- Return just the count (status quo): Insufficient for table format integration.
- Expose via a separate accessor: e.g.
ctx.last_write_metadata()— awkward API, not composable. - Return raw bytes of the full Parquet footer: Maximally informative but heavier. A structured dict with optional raw bytes is more ergonomic.
Additional context
- Upstream dependency: apache/datafusion#23656 adds
DataSink::file_metadata()to the Rust core. This issue tracks exposing it through the Python bindings. - Motivation: PyIceberg is building a pluggable execution backend with DataFusion for bounded-memory operations. A DataFusion write backend would enable single-pass Copy-on-Write deletes (read → filter → write entirely in Rust with spill-to-disk), but requires per-file metadata to construct Iceberg
DataFilecommit entries. - Related: #1624 (per-session object store config) is the other piece needed for a complete DataFusion write backend in PyIceberg.
- Linguagem predominante
- Python
- Estrelas
- 605
- Forks
- 176
- Merge médio
- 1d 23h
- PRs com merge (30d)
- 8
Guia de contribuição
Nenhum guia de contribuição indexado para este repositório
Primeiros passos
- Leia a issue inteira e depois o guia de contribuição do projeto.
- Comente na issue dizendo que vai assumir — evita que duas pessoas façam o mesmo trabalho.
- Faça um fork do repositório e trabalhe em uma branch.
- Abra um pull request que referencie o número da issue.
Mais de apache/datafusion-python
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
apache/datafusion-python#1757 ·
-
documentation
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 72/100
apache/datafusion-python#1726 ·
-
Dificuldade 2/5 Meio dia Facilidade para iniciantes 88/100
apache/datafusion-python#1691 ·
-
bug
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 78/100
apache/datafusion-python#1644 ·
-
enhancement
Dificuldade 5/5 Mais de uma semana Facilidade para iniciantes 30/100
apache/datafusion-python#1737 ·
Todas as issues de apache/datafusion-python
Issues semelhantes
-
enhancement
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 70/100
canonical/paas-charm#368 · 1 comentário ·
-
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
tech debt
Dificuldade 2/5 1-3 horas Facilidade para iniciantes 75/100
-
addition to tracking list Aberta
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100
StevenBlack/hosts#3256 ·
-
Dificuldade 1/5 Menos de uma hora Facilidade para iniciantes 90/100
qualcomm/qai-appbuilder#275 ·