Apache flink Flink Kinesis Consumer未存储上次成功处理的序列号

我们使用Flink Kinesis Consumer将来自Kinesis流的数据消费到我们的Flink应用程序中

KCL库使用DynamoDB表存储最后一次成功处理的Kinesis流序列号。这样，下次应用程序启动时，它将从停止的位置恢复

但是，Flink Kinesis Consumer似乎在任何持久存储中都不维护任何这样的序列号。因此，我们需要依赖ShardIteratortype（trim_horizen、latest等）来决定在应用程序重新启动时恢复Flink应用程序处理的位置

一个可能的解决方案是依赖Flink检查点机制，但这仅在应用程序失败后恢复时有效，而不是在应用程序被故意取消并且需要从最后一个成功使用的Kinesis流序列号重新启动时有效

---

我们是否需要自己存储这些最后成功消费的序列号

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

Flink的快照是Flink为从故障中恢复而自动拍摄的快照，其格式针对快速恢复进行了优化。使用相同的底层快照机制，但它们是手动触发的，它们的格式更关注操作灵活性而不是性能

保存点就是您要寻找的。特别是，它们非常有用

---

另一个选项是与ExternalizedCheckpointCleanup一起使用。取消时保留。\n要补充David的回答，我想解释一下不存储序列号的原因

提交到源系统中的任何类型的偏移都会将检查点/保存点功能仅限于容错。也就是说，只有最新的检查点/保存点才能恢复

然而，Flink实际上支持跳回以前的检查点/保存点。考虑应用程序升级。在升级之前先创建一个保存点，让它运行几分钟，然后创建几个检查点。然后，您会发现一个关键的bug。您希望回滚到已获取的保存点并放弃所有检查点

现在，如果Flink只将源偏移提交给源系统，我们将无法重播从现在到恢复的保存点之间的数据。因此，正如David指出的，Flink需要将偏移量存储在保存点本身中。此时，额外提交到源系统不会带来任何好处，而且在恢复到以前的保存点/检查点时会造成混乱

您认为额外存储偏移有什么好处吗