并行度大于 1 的 Flink 广播状态

Question

我先说一下，我是 Flink 的初学者，并试图尽可能地抓住概念。

假设，我有一个带有 10 个任务管理器的 flink 集群。我有一个在每个上面运行的 flink 作业。该作业也使用广播状态。这个广播状态是通过每10分钟读取5个S3文件，做一些处理，创建广播的int to list of strings的映射来创建的。

问题：文件读取发生在哪里，是在 JobManager 读取和处理文件并将处理后的内容发送给任务管理器。

或者

是任务管理器负责所有的阅读和处理吗？如果是这种情况，那么 flink 是如何确保一个任务管理器从 S3 读取失败时，所有任务管理器的广播状态都相同。

编辑

因此任务管理器读取广播流并将其广播到下游任务。

例如。假设有一个需要广播的 5 个分区的 Kafka 流。还有一个并行度为 5 的下游算子。

1. 分区 1 消费者任务，从流中读取元素并将其设置为广播状态。一旦设置好，状态就会广播到所有下游 operator 5 任务。
2. 分区 2 消费者任务，从流中读取元素并将其设置为广播状态。

问题：此时，当我们从分区 2 元素设置广播状态时，我们是否需要确保不覆盖分区 1 中的元素，或者 flink 自己管理这一点。

或

另外，我们如何确定在分区 2 消费了一个元素并设置广播状态时，分区 1 的广播状态已经达到分区 2 下游操作员任务。

Answer 1

文件读取发生在哪里？

任务管理器。 JobManager 只负责管理调度和故障转移等任务。

如何将处理后的内容发送给任务管理器？

您可以简单地将广播状态过程想象为向所有下游任务发送相同的消息，而不是发送给特定的任务。

如果任务管理器无法从 S3 读取，flink 如何处理？

如果源任务无法从 S3 读取，我相信会有重启（可能是完全重启，也可能是部分重启），检查点机制会确保状态的一致性。

所有任务管理器的广播状态都相同。

其实广播状态在所有任务中并不完全相同。原因是在网络传输过程中，不能保证事件按照相同的顺序传递给任务。