我正在将Kafka使用者连接器（FlinkKafkaConsumer）和文件接收器（StreamingFileSink）与Flink流式传输一起使用，且群集模式只有一次策略。 文件接收器将文件写入本地磁盘。 我注意到，如果作业失败并启用了自动重新启动，则任务管理器会从上一个失败的作业（隐藏的文件）中查找剩余的文件。 显然，由于可以将任务分配给不同的任务管理器，因此一遍又一遍地总结出了更多的故障。 到目前为止，我发现的唯一解决方案是删除隐藏文件并重新提交作业。 如果我做对了（如果我做错了，请纠正我），隐藏文件中的事件未提交给引导服务器，因此不会丢失数据。
有没有办法强迫Flink忽略已经写入的文件？或者，也许有更好的方法来实现该解决方案（也许以某种方式使用保存点）？
答案 0 :(得分：0)
我在Flink邮件列表中得到了非常详细的答案。 TLDR，为了只实施一次，我必须使用某种分布式FS。
完整答案：
对于您要实现的目标，本地文件系统不是正确的选择。我认为您无法在此设置中实现一次真正的策略。让我详细说明为什么。 有趣的是它在检查点上的行为。该行为由RollingPolicy控制。由于您没有说使用哪种格式，因此假设您首先使用行格式。对于行格式，默认的滚动策略（将文件从进行中更改为挂起时）是如果文件达到128MB，文件早于60秒或尚未写入60秒将被滚动。它不会在检查点上滚动。此外，StreamingFileSink认为文件系统是可在还原后访问的持久接收器。这意味着从检查点/保存点还原时它将尝试附加到此文件。
即使在每个检查点上滚动了文件，您仍然可能会遇到一些残留问题，因为StreamingFileSink会在检查点完成后将文件从待处理状态转移到完成状态。如果在完成检查点和移动文件之间发生故障，则还原后将无法移动文件（如果具有访问权限，则可以这样做）。
最后一个完成的检查点将包含已成功端对端处理的记录的偏移量，这意味着假定StreamingFileSink提交了记录。这可以通过在StreamingFileSink检查点元数据中使用指针写入正在进行的文件中的记录，在该文件已完成的StreamingFileSink检查点元数据中带有条目的“待处理”文件中记录或在“完成”文件中记录。 1]
因此，您可以看到在重新启动后StreamingFileSink必须访问文件的情况有多种。
最后一件事，您提到“提交到”引导服务器”。请记住，Flink不会使用提交给Kafka的偏移量来保证一致性，它可以写回这些偏移量，但仅用于监视/调试目的。 Flink从其检查点存储/恢复已处理的偏移量。[3]
让我知道是否有帮助。我尽力了；）顺便说一句，我极力鼓励阅读链接的资源，因为它们试图以更加结构化的方式描述所有这些内容。 我还在抄送Kostas，他比我更了解StreamingFileSink，因此他可以在某个地方纠正我。
[1] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/connectors/streamfile_sink.html [2] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/connectors/kafka.html [3] https://ci.apache.org/projects/flink/flink-docs-release-1.10/dev/connectors/kafka.html#kafka-consumers-offset-committing-behaviour-configuration