Apache Flink 1.14中StreamingFileSink无法同步全部文件至S3的排查请求

1. 检查Checkpoint与两阶段提交（2PC）配置 #

Flink 1.14中StreamingFileSink的文件提交完全依赖Checkpoint的正常触发，从1.9升级后需重点确认：

• 查看Flink UI的Checkpoints标签页，确认Checkpoint的触发间隔、成功率是否正常。若Checkpoint未成功触发，sink的两阶段提交会被阻塞，无法生成新的最终文件。
• 核对状态后端配置：1.9到1.14默认状态后端可能变更，确保state.backend配置的存储路径（EKS中PVC或S3路径）有足够读写权限，状态能正常持久化。
• 确认sink的语义配置：StreamingFileSink默认使用exactly-once语义，依赖Checkpoint完成提交流程。若Checkpoint持续失败，sink会卡在等待提交状态，停止生成新文件。

2. 排查ContinuousFileReaderOperatorFactory的状态与水位线问题 #

替换Operator为Factory后，source的状态管理和水位线传播可能出现异常：

• 检查source状态持久化：在Flink UI的Task Managers页查看source任务的状态大小，确认文件读取偏移量等状态是否被正确保存。若状态未持久化，source可能停止读取新数据，导致sink无新输入、无法滚动生成文件。
• 验证水位线推进：若source未正常发送水位线，依赖时间的滚动策略会失效。检查withRollingPolicy中的时间配置，同时确认ContinuousFileReaderOperatorFactory是否正确配置了水位线分配器，保证事件时间/处理时间水位线正常推进。

3. 处理S3 Committer的恢复冲突 #

日志中Trying to commit after recovery提示sink在恢复时的提交逻辑可能存在阻塞：

• 清理S3临时目录：StreamingFileSink会生成_tmp/_pending等临时目录，若之前作业残留未提交的临时文件，会导致新作业的committer卡住，手动清理后重启作业测试。
• 更新S3 Committer配置：Flink 1.14推荐使用magic committer（配置fs.s3a.committer.name=magic），相比传统file committer在Kubernetes环境中更稳定，避免提交冲突。
• 确认EKS Pod权限：确保Task Manager Pod拥有S3完整读写权限（通过IAM角色或Secret配置），权限不足会导致committer无法完成文件提交，文件一直停留在临时状态。

4. 排查作业隐性重启与资源问题 #

文件数量等于并行度，说明每个并行实例仅完成一次提交，需确认：

• 查看Flink UI的Job History，检查作业是否有频繁重启或故障转移。若作业反复重启，每次恢复时sink会优先处理遗留提交，无法生成新文件。
• 调整Task Manager资源：EKS中Pod内存/CPU不足会引发OOMKilled，导致作业重启。优化Pod的资源请求与限制，保证Task Manager稳定运行。

代码层面验证 #

虽然sink代码未变更，仍需结合新Operator Factory确认：

• 核对ContinuousFileReaderOperatorFactory的inputFormat配置：确保文件监控间隔、过滤规则等参数正确，避免source停止读取新文件。
• 确认并行度匹配：检查source与sink的并行度是否一致，若sink并行度不足可能引发数据积压，但你的场景更可能是source无新输出或sink提交阻塞。

内容的提问来源于stack exchange，提问作者Nikhil