Spark 报文件不存在怎么办？开启 ignoreMissingFiles 就修好了吗？
本文目录
面试怎么回答
我会先核对缺失路径、任务计划和文件变化记录，区分构建DataFrame后被删除、目录覆盖或清理并发等原因。ignoreMissingFiles只允许跳过特定缺失文件继续读取，不会补回数据。是否能使用部分结果要看业务契约；关键报表应固定输入版本并做清单与指标验收，再协调读写发布和清理生命周期。
先把这段讲顺；面试官追问时，再展开下面的原理和细节。
详细讲解
日志提示某个Parquet文件不存在，搜索后找到一个配置：ignoreMissingFiles=true。任务果然变绿了，但少读的文件并没有回来。绿色状态和数据完整，是两个不同结论。
忽略缺失文件是容错取舍，不是数据修复；先查文件生命周期与读写并发，再用完整性契约决定是否允许部分结果。
先拿到具体缺失路径
不要只看最外层任务失败。应记录最内层错误、文件完整路径、涉及分区、计划构建时间和执行时间，再核对这个对象当前是否存在。
如果文件存在但访问失败，还要继续检查权限、凭证和底层存储响应，不能把所有读取错误都归为“缺文件”。同样，文件损坏与文件不存在也不是一类问题，对应的容错选项不能混用。
日志里的路径可以与输入清单、目录覆盖记录和清理任务对照。这里最重要的是时间顺序：文件什么时候被发现，什么时候被读取，又在什么时候发生变化。
计划生成之后，文件可能已被替换
一种典型情况是读取方已记录待扫描文件，而写入方随后覆盖目录，移除了旧文件。读取方仍尝试打开原路径，就会遇到缺失。
数据清理、表格式维护或人工误删，也可能与在途读者发生冲突。对于带快照语义的表格式，要遵循其引用和保留机制；不能绕过元数据直接删文件，再期待上层恢复逻辑自动补救。
重新构建读取计划有时能看到新的文件集合，但这意味着输入版本可能改变。是否允许按新版本重跑，需要由任务的业务范围决定，而不是无条件刷新后继续发布。
ignoreMissingFiles真正改变了什么？
Spark 4.0.1文档将这里的缺失解释为构建DataFrame后，目录下的文件被删除。开启相关选项后，作业可以在遇到缺失文件时继续，返回已读取到的内容。
它没有恢复文件，也没有证明丢失部分不重要，更不是让任意不存在的根路径、权限错误或损坏数据全部变成可忽略。
因此把这个选项称为“修复文件不存在”并不准确。它改变的是失败策略：从遇到特定缺失就中断，变成允许继续产生部分结果。
诊断探索或明确允许缺口的场景，可以评估使用，但必须标识实际覆盖范围。完整性要求高的结算或正式指标，不能仅靠任务成功判定可以发布。
一个典型场景：成功作业少算了一个分区
假设某任务读取活动明细时，清理任务删掉了仍被使用的旧文件。开发开启忽略缺失后，任务完成，报表某渠道金额明显下降，第一反应是渠道业务下滑。
旧验收只检查输出不为空以及总波动未超过宽松阈值；丢失分区占整体比例不大，所以没有告警。按输入分区与渠道拆分后，才发现缺口对应被清理的文件。
修正先确认能否从可靠源或受控备份恢复输入，重新生成同一业务范围结果，再核对分区覆盖、主键和关键金额。随后调整清理与读者保留窗口，防止问题重复出现。
不能随意把缺失分区补成零。零业务表示完整输入下确实没有发生，文件缺失表示不知道发生了多少，二者必须在数据状态上区分。
从生命周期解决，而不是永远跳过
稳定方案可以包括不可变批次路径、完整输入清单、受控发布入口与足够的在途读者保留时间。哪一种适合，要看实际文件系统和表格式的能力。
验收除了行数，还应核对预期分区、文件或来源批次覆盖，保留缺失清单和受影响消费方。恢复后检查的是缺口已补齐，而不是错误日志不再出现。
在面试里把“故障绕过”和“正确性恢复”分开讲，就能解释为什么一个看似简单的配置，需要结合数据契约才能决定是否使用。
资料与适用边界
机制以所链接版本为准；业务示例用于说明判断方法，不代表作者真实项目或已验证的生产性能。