我的flink作业使用FlinkKafkaConsumer010从kafka使用者读取，并使用CustomBucketingSink陷入hdfs。我们有一系列转换kafka-> flatmaps（2-3个转换）-> keyBy-> tumblingWindow（5分钟）->聚合-> hdfsSink。卡夫卡平均输入300万/分钟的事件，高峰时间输入2000万/分钟的事件。检查点持续时间和两次检查之间的最小间隔为3分钟，我正在使用FsStateBackend。
这是我的假设：
Flink消耗来自kafka的固定数量的事件（一次来自多个分区的多个偏移量），并等待直到到达下沉点和检查点为止。如果成功，它将提交其读取的kafka分区偏移量，并保持与正在写入的hdfs文件相关的某些状态。在卡夫卡将事件移交给其他运营商之后，尽管进行了多种转换，但卡夫卡的消费者一直处于闲置状态，直到获得发送事件的成功确认。因此，可以说，当接收器将数据写入hdfs时，所有先前的操作员都处于空闲状态。如果发生故障，flink会转到先前的检查点状态，并指向kafka提交的最后一个分区偏移量，并指向应该开始写入的hdfs文件。
这是基于上述假设的疑问：
1）以上假设是正确的。 2）无论我们从最后一个kafka分区提交的偏移量开始，翻转窗口都具有状态（如发生故障）是否有意义？ 3）在滚动窗口生成状态的情况下，flink可以何时使用此状态。 4）为什么检查点和保存点状态大小会有所不同。 5）万一发生故障，flink总是从sorce运算符开始。是吗？
答案 0 :(得分：2)
您的假设不正确。
（1）检查点不以任何方式取决于到达接收器的事件或结果。
（2）Flink进行自己的Kafka偏移量管理。从检查点还原时，在发生故障后，将使用检查点中的偏移量，而不是可能已经提交回Kafka的偏移量。
（3）运营商从来没有像您描述的那样闲着。管道不会因检查点而停止。
了解检查点如何工作的最佳方法是遍历Flink操作场所，尤其是Observing Failure and Recovery上的部分。这将使您对该主题有更清晰的了解，因为您将能够准确观察正在发生的事情。
我还建议阅读https://ci.apache.org/projects/flink/flink-docs-master/training/fault_tolerance.html，并跟随其中包含的链接。
但是要逐步了解应用程序中检查点的工作方式，请按以下基本步骤操作：
（1）当检查点协调员（作业管理器的一部分）决定是时候启动另一个检查点时，它通知每个任务管理器开始检查点 n 。
（2）所有源实例都检查点自己的状态，并将检查点障碍 n 插入其输出流。在您的情况下，源是Kafka使用者，它们检查每个分区的当前偏移量。
（3）每当有状态运算符中检查点屏障到达输入队列的开头时，该运算符就会检查其状态并转发屏障。这部分具有一定的复杂性-但基本上，状态保存在多版本，并发控制的哈希图中。操作员创建状态的新版本 n + 1 ，可以通过检查点屏障后面的事件进行修改，并创建新线程以异步快照版本 n 中的所有状态。 em>。
在您的情况下，窗口和接收器是有状态的。窗口的状态包括当前窗口的内容，触发器的状态以及用于窗口处理的其他状态（如果有）。
（4）接收器使用障碍的到达来刷新所有排队的输出，并提交未决的事务。再次，这里有一些复杂性，因为事务接收器使用两阶段提交协议。
在您的应用程序中，如果检查点间隔比窗口持续时间小得多，那么接收器将在从窗口接收任何输出之前完成许多检查点。
（5）当检查点协调员从每个任务中听到检查点已完成时，它将最终确定检查点元数据。
在恢复期间，每个操作员的状态都将重置为最新检查点中的状态。这意味着将源倒退到检查点的偏移量，然后继续处理窗口和接收器中的状态，该状态对应于将事件消耗到这些偏移量后应具有的状态。
注意：为使这一过程简单易行，我详细介绍了许多细节。另外，FLIP-76将引入一种新的检查点方法。