Flink 窗口操作符检查点

Question

想知道flink是怎么做window operator的checkpoint的。恢复时如何保证恰好是一次？例如，保存当前窗口中的元组，保存当前窗口处理的进度。想知道window operator的checkpoint和recovery的详细过程。

Answer 1

Flink 的所有有状态操作符都参与相同的检查点机制。当检查点协调器（作业管理器的一部分）指示这样做时，任务管理器在每个源操作员的每个并行实例中启动一个检查点。源检查它们的偏移量并将检查点屏障插入到流中。这将流分成检查点之前和之后的部分。屏障流过图，每个有状态的操作符在处理流到检查点屏障时检查其状态。详细信息在@bupt_ljy 分享的链接中进行了描述。

因此，这些检查点捕获分布式管道的整个状态，将偏移量记录到输入队列中，以及整个作业图的状态，这些状态是由于在该点之前摄取数据而产生的。当发生故障时，源被倒带，状态被恢复，并且处理被恢复。

鉴于在恢复过程中源会被倒带和重放，“exactly once”意味着 Flink 管理的状态只受到一次影响，而不是流元素只被处理一次。

在这方面，windows 并没有什么特别之处。根据所应用的窗口函数的类型，窗口的内容保存在托管 ListState、ReducingState、AggregatingState 或 FoldingState 的元素中。当流元素到达并被分配给窗口时，它们会被追加、减少、聚合或折叠到该状态。窗口 API 的其他组件，包括触发器和 ProcessWindowFunctions，也可以具有被检查点的状态。例如，CountTrigger 使用 ReducingState 跟踪已分配给窗口的元素数量，并在将每个元素添加到窗口时将计数加一。

在窗口函数为ProcessWindowFunction的情况下，所有分配给窗口的元素都保存在Flink状态，并在窗口触发时以Iterable的形式传递给ProcessWindowFunction。该函数迭代内容并产生结果。 ProcessWindowFunction 的内部状态没有检查点；如果在 ProcessWindowFunction 执行期间作业失败，则作业将从最近完成的检查点恢复。这将涉及倒回到窗口接收到触发窗口触发的事件之前的时间（该事件不能包含在检查点中，因为它后面的检查点屏障还没有生效）。窗口迟早会再次到达触发点，并且 ProcessWindowFunction 将再次被调用——使用它第一次收到的相同窗口内容——希望这次它不会失败。 （请注意，我忽略了处理时间窗口的情况，它的行为不是确定性的。）

当 ProcessWindowFunction 使用托管/检查点状态时，它用于记住触发之间的内容，而不是单个触发中的内容。例如，允许延迟事件的窗口可能希望存储先前报告的结果，然后为每个延迟事件发布更新。