Apache Hudi并发读写场景下的FileNotFoundException问题分析与解决方案

问题背景

在使用Apache Hudi构建数据湖平台时，开发团队遇到了一个典型的生产环境问题：当Spark SQL查询正在执行过程中，如果同时有写入操作更新同一张Hudi表，查询作业会抛出FileNotFoundException异常。这种情况在数据湖架构中尤为常见，因为现代数据平台通常需要支持实时或近实时的数据更新与查询。

问题现象

具体表现为：当读取作业启动后，如果此时有写入作业完成并提交了新版本的数据，读取作业在后续处理阶段（如执行checkpoint操作时）会失败，错误信息显示无法找到S3上的某个分区路径文件。从错误堆栈可以看出，问题发生在HoodieFileIndex尝试列出分区文件时。

根本原因分析

经过深入排查，发现这个问题主要由以下几个因素共同导致：

1. 写入模式影响：测试环境中使用了mode(overwrite)写入模式，这种模式会完全删除表目录并重新创建，导致正在进行的读取作业无法找到原有文件引用。

2. 文件索引机制：Hudi默认启用了文件索引(hoodie.file.index.enable=true)，该机制会动态列出分区文件。当底层文件被写入作业删除或更新时，读取作业的文件索引操作就会失败。

3. 并发控制缺失：虽然Hudi本身支持MVCC(多版本并发控制)，但在特定场景下(如overwrite模式)仍然需要额外的并发控制配置来保证读写一致性。

技术原理深入

Apache Hudi通过时间线(Timeline)机制实现多版本控制，每个提交(commit)都会生成一个新的版本。在正常情况下：

• 读取作业会基于某个时间点的快照(view)进行
• 写入作业会创建新的版本而不影响正在进行的读取
• 旧版本文件只有在确保没有作业引用后才会被清理

但在overwrite模式下，这个保证被打破，因为该模式相当于重建了整个表结构，而非增量更新。

解决方案

针对这类问题，我们推荐以下几种解决方案：

1. 避免使用overwrite模式：改用upsert等增量更新模式，保持文件版本的连续性。

2. 配置合理的清理策略：调整hoodie.cleaner.policy和hoodie.cleaner.commits.retained等参数，确保不会过早删除正在被读取的文件版本。

3. 启用并发控制：对于生产环境，建议配置：

   hoodie.write.concurrency.mode=optimistic_concurrency_control
   hoodie.cleaner.policy=KEEP_LATEST_COMMITS
   hoodie.cleaner.commits.retained=10
   

4. 稳定文件索引：对于长时间运行的读取作业，可以考虑：

   hoodie.file.index.enable=false
   

最佳实践建议

1. 生产环境设计：

   • 区分实时更新表和批量刷新表的不同处理方式
   • 为关键业务表设置适当的文件保留策略
   • 监控长时间运行的查询作业

2. 测试环境验证：

   • 模拟真实负载的压力测试
   • 验证不同并发控制配置下的表现
   • 建立自动化测试用例覆盖读写并发场景

3. 运维监控：

   • 监控Hudi表的commit频率和clean操作
   • 设置文件版本数的告警阈值
   • 跟踪查询作业的持续时间

总结

Apache Hudi作为新一代数据湖框架，提供了强大的增量处理和版本控制能力。通过合理配置并发控制参数和写入策略，可以有效避免读写冲突问题。对于生产环境，建议充分理解Hudi的MVCC实现原理，根据业务特点选择适当的配置方案，并在上线前进行充分的并发场景测试。