HN讨论 · 身份未知
多引擎数据管线中 Parquet 互操作性失败的自动化检测与复现
面向 Parquet 引擎维护者和多引擎管线开发者，跨引擎读写 Parquet 文件时存在兼容性失败且难以定位。作者构建的 Python CLI 工具通过 fuzzing 和引擎矩阵自动发现并最小化失败，已在实际引擎中提交两个 issue。
查看原始信号hn:49285166
目标用户
Parquet 引擎维护者，以及在数据管线中同时使用多个 Parquet 引擎的开发者
潜在需求
需要一种工具自动将大量或随机生成的 Parquet 文件跑过多个引擎，定位失败并最小化输出复现用例，以便确认问题归属并向引擎维护者提交可用的报告。
发生场景
数据管线中同一 Parquet 文件会被多个引擎（如 Polars、DuckDB）读取，任一引擎对格式处理不一致都会导致任务报错或数据损坏，而手动构造用例和排查失败非常耗时。
来源证据
作者构建了一个 Python CLI，可让 Parquet 文件通过多个引擎运行并最小化失败，已用它发现 Polars 和 DuckDB 的两个互操作性 issue。
I built a Python CLI for Parquet interoperability. It runs a given Parquet file through selected readers and shows where it fails with a command. Also uses Hypothesis for fuzzing. Generates tables, runs through a matrix of engines and minimizes the found failures. You can also create a schema beforehand and fuzz within it. I believe it can be useful for Parquet engine maintainers and people with multiple Parquet engines involved in their pipeline. Already found and filed two issues with it, onehttps://news.ycombinator.com/item?id=49285166
为什么值得留意
作者已用该工具扫描 Apache 语料库和 fuzzing，在 Polars 和 DuckDB 上发现并提交了两个互操作性失败 issue，说明问题真实存在且自动化方法能产出维护者可用的结果。
未满足部分
- 不同引擎之间的 Parquet 兼容性仍存在实际失败，需要持续识别、复现和修复
可能延伸 · 模型推测
- 将 fuzzing 扩展到更多 Parquet 引擎或版本组合
- 提供 CI 集成，自动验证管线中多引擎的兼容性
目前未知
- 该工具目前主要由作者使用，独立用户采用情况未知
- 已提交的 issue 是否被维护者接受或修复未知
继续核实
- Parquet 互操作性失败在日常多引擎管线中出现的频率和影响有多大？
- 引擎维护者对这类自动化发现工具的工作流接受度如何？
- 现有官方 Parquet 测试套件为何未能覆盖这些失败？
主题词
parquet interoperabilityfile format compatibilitydata pipeline reliabilityengine fuzzing