Spark写入Iceberg表后Dremio读取报错“不是Parquet文件”，Spark/Trino可正常访问

碰到这种跨引擎的兼容性问题确实头疼，明明文件本身没问题，却只有某一个引擎读不了。结合你的场景，我整理了几个可能的原因和对应的排查/解决思路：

1. Dremio的Parquet读取校验逻辑更严格 #

不同引擎对Parquet文件的容错机制不一样：

• Parquet标准要求文件首尾都有PAR1魔数（对应字节[80, 65, 82, 49]），Dremio可能会严格校验尾部魔数，而Spark/Trino、parquet-tools对尾部的微小异常有容错处理。
• 排查：用hexdump -C 你的报错文件.parquet | tail查看文件最后几个字节，确认是否真的魔数异常；同时检查Dremio版本，有没有已知的Parquet兼容bug。
• 解决：尝试升级Dremio到最新稳定版，或者在Dremio的配置中调整Parquet读取的容错参数（比如关闭严格的尾部魔数校验，具体可查Dremio官方文档的Parquet相关配置）。

2. Spark流式写入的文件完整性问题 #

Structured Streaming持续写入的场景下，容易出现文件未完全提交就被扫描的情况：

• 可能是网络波动、StorageGRID的一致性延迟，导致部分Parquet文件尾部未完全写入就被Iceberg元数据标记为完成，Dremio读取时刚好拿到不完整的文件。
• 排查：查看Spark Streaming的任务日志，找写入该报错文件时的异常信息；检查Iceberg的manifest文件，确认这个文件是否被标记为COMMITTED状态。
• 解决：
  • 调整Spark流式任务的触发间隔，比如trigger(Trigger.ProcessingTime("5 minutes"))，减少频繁小文件写入的概率，保证每个微批的文件都能完整flush并提交。
  • 定期执行Iceberg的修复命令：CALL system.rewrite_data_files('你的表名')，自动修复可能损坏的文件；也可以配置Iceberg自动清理未完成的临时文件。

3. NetApp StorageGRID的S3兼容性差异 #

虽然是S3兼容存储，但厂商实现可能有细节差异：

• 比如分段上传的合并逻辑、文件一致性模型（最终一致性vs强一致性），可能导致Dremio读取到的文件内容和本地下载的不一致。
• 排查：对比Dremio导出的该文件片段和本地parquet-tools解析的内容，看是否存在差异；检查StorageGRID的日志，有没有文件读写的异常记录。
• 解决：
  • 在Spark写入时，关闭小文件的分段上传：设置spark.hadoop.fs.s3a.multipart.size为较大值（比如1GB），避免小文件分段上传导致的合并问题。
  • 如果StorageGRID支持，切换到强一致性模式；或者在Dremio读取时增加适当的延迟，等待存储层的文件状态完全一致。

4. Nessie Catalog的元数据同步问题 #

Nessie作为版本化catalog，可能存在元数据缓存或同步延迟：

• Dremio可能缓存了旧的表元数据，导致它读取的文件路径/状态和实际S3上的文件不匹配，进而读到错误的内容。
• 排查：在Dremio中手动执行ALTER TABLE 你的表名 REFRESH METADATA刷新元数据，之后再查询看是否还报错；对比Nessie中该表的元数据和Spark/Trino看到的元数据是否一致。
• 解决：配置Dremio定期自动刷新Iceberg表的元数据；或者在Spark每次写入commit后，触发Nessie的元数据通知，让Dremio及时更新。

建议先从刷新Dremio元数据、升级Dremio版本入手，这些操作成本最低；如果无效再逐步排查存储层和Spark写入的问题，最后用Iceberg的rewrite工具修复现有文件。

备注：内容来源于stack exchange，提问作者chris922