Flink中保存点和检查点之间的差异
我知道stackoverflow上也有类似的问题，但在调查了其中几个之后，我知道
>
他们正在使用不同的存储格式
但这些并不是令人困惑的地方，我不知道什么时候该用一个，什么时候该用另一个。
考虑以下两种情况：
- 如果由于某种原因（例如错误修复或意外崩溃）需要关闭或重新启动整个应用程序，那么我必须使用保存点来恢复整个应用程序
共有1个答案
Flink是否使用检查点进行状态恢复？
基本上你是对的。正如您所说，检查点通常在Flink内部用于容错，它更像是框架内的一个概念。当应用程序失败时，程序将尝试从最新的检查点重新启动。这就是检查站在Flink的工作方式，没有任何人为干预。
我应该使用savepoint恢复整个应用程序以修复bug吗？
对在这些情况下，您不想从检查点恢复，因为最新的检查点可能发生在几分钟前。相反，您希望快照整个应用程序的当前状态，并从最新的保存点重新启动它，这可能是恢复应用程序最快的方式，不会有太多延迟。
外部化检查点。
它仍然是检查点，但将根据您的配置在外部持久化。它可用于恢复应用程序，但状态不是那么实时，因为检查点之间存在间隔。
有关更多信息，请查看此博客文章：https://data-artisans.com/blog/differences-between-savepoints-and-checkpoints-in-flink.
-
下面是我对Flink的疑问。 我们可以将检查点和保存点存储到RockDB等外部数据结构中吗？还是只是我们可以存储在RockDB等中的状态。 状态后端是否会影响检查点？如果是，以何种方式？ 什么是状态处理器API？它与我们存储的保存点和检查点直接相关吗？状态处理器API提供了普通保存点无法提供的哪些额外好处？ 对于3个问题，请尽可能描述性地回答。我对学习状态处理器API很感兴趣，但我想深入了解它的应
-
但是Flink医生说： 在启用Flink检查点的情况下，Flink Kafka使用者将使用来自主题的记录，并以一致的方式定期检查其所有的Kafka偏移量以及其他操作的状态。在作业失败的情况下，Flink会将流程序恢复到最新检查点的状态，并从检查点中存储的偏移量开始重新使用来自Kafka的记录。 阅读其他来源，我猜Flink检查点将保存程序的状态以及消耗的偏移量，但Spark检查点只是保存消耗的偏移
-
如果Flink应用程序在发生故障或更新后正在启动备份，那么不明确属于KeyedState或OperatorState的类变量是否会持久化？ 例如，Flink的留档中描述的BoundedOutOfOrdernessGenerator有一个电流最大时间戳变量。如果更新了Flink应用程序，电流最大时间戳中的值是否会丢失，或者是否会写入在应用程序更新之前创建的保存点？ 这样做的真正原因是我想实现一个自定
-
我想在flink中测试一次端到端的处理。我的工作是： Kafka资料来源- 我在mapper1中放了一个< code > thread . sleep(100000)，然后运行了这个作业。我在停止作业时获取了保存点，然后从mapper1中删除了< code > thread . sleep(100000)，我希望该事件应该会被重放，因为它没有下沉。但这并没有发生，乔布斯正在等待新的事件。 我的Ka
-
我试图检查/保存我在EMR上运行的flink状态到AWS上的s3存储桶。请注意： 实例（主节点和核心节点）正确设置了IAM角色，以访问s3 bucket及其内部的所有目录/文件（AmazonS3FullAccess策略附加到该角色，没有任何内容覆盖它） jobmanager日志：
-
考虑使用以下管道的Apache Flink流媒体应用程序： 其中每个函数都是非状态运算符（例如