Flink Kinesis使用者未存储上次成功处理的序列号

Question

我们正在使用Flink Kinesis Consumer将Kinesis流中的数据消费到我们的Flink应用程序中。

KCL库使用DynamoDB表存储最后成功处理的Kinesis流序列号。以便下次启动应用程序时，它将从上次停止的地方恢复。

但是，似乎Flink Kinesis Consumer没有维护任何此类序列号。在任何持久性存储中。因此，我们需要依赖ShardIteratortype（trim_horizen，latest等）来确定在应用程序重新启动时在哪里恢复Flink应用程序处理。

对此的一种可能的解决方案是依靠Flink检查点机制，但是仅当应用程序在失败时恢复时才起作用，而不是在应用程序被故意取消并且需要从最近成功使用的Kinesis流序列中重新启动时才起作用不。

我们是否需要自己存储这些最后一次成功使用的序列？

Answer 1

Flink的最佳实践是使用检查点和保存点，因为它们创建一致的快照，这些快照包含消息队列中的偏移量（在本例中为Kinesis流序列号），以及整个作业图中其余所有状态，是因为消耗了数据直到这些偏移量。这样就可以恢复或重新启动，而不会丢失或重复数据。

Flink的checkpoints是Flink自身自动拍摄的快照，目的是从故障中恢复，并且采用可快速恢复的优化格式。 Savepoints使用相同的基础快照机制，但是手动触发的，其格式更关注操作的灵活性而不是性能。

保存点是您想要的。 cancel with savepoint和resume from savepoint特别有用。

另一种选择是将retained checkpoints与ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION一起使用。

Answer 2

为补充David的回答，我想解释不存储序列号的原因。

任何一种提交到源系统中的偏移量都只会将检查点/保存点功能限制为容错能力。也就是说，只有最新的检查点/保存点才能恢复。

但是，Flink实际上支持跳回到上一个检查点/保存点。考虑应用程序升级。您之前先创建了一个保存点，然后进行升级并使其运行了几分钟，并在其中创建了几个检查点。然后，您发现一个严重的错误。您想回滚到已保存的保存点，并放弃所有检查点。

现在，如果Flink仅将源偏移量提交给源系统，那么我们将无法在现在和还原的保存点之间重播数据。因此，正如David David指出的那样，Flink需要将偏移量存储在保存点本身中。在这一点上，另外提交到源系统不会产生任何好处，并且在还原到先前的保存点/检查点时会造成混乱。

您发现额外存储偏移量有什么好处吗？