Flink和SparkStreaming中检查点机制的差异
但是Flink医生说：
在启用Flink检查点的情况下，Flink Kafka使用者将使用来自主题的记录，并以一致的方式定期检查其所有的Kafka偏移量以及其他操作的状态。在作业失败的情况下，Flink会将流程序恢复到最新检查点的状态，并从检查点中存储的偏移量开始重新使用来自Kafka的记录。
阅读其他来源，我猜Flink检查点将保存程序的状态以及消耗的偏移量，但Spark检查点只是保存消耗的偏移量，因为这个火花，说：
有谁能说一下，在阅读Kafka主题的数据时，有什么不同，以及人们如何能够达到准确的--一次语义？
共有1个答案
我想这包含了您正在寻找的内容：https://data-artisans.com/blog/high-through-low-latency-and-extracty-once-stream-processing-with-apache-flink
精确一次和至少一次之间的最大区别是，精确一次可以保证不会输出重复的数据。至少一次保证您不会丢失任何数据（与精确一次相同），但可能会有重复的数据输出。
编辑：
-
我知道stackoverflow上也有类似的问题，但在调查了其中几个之后，我知道 > 他们正在使用不同的存储格式 但这些并不是令人困惑的地方，我不知道什么时候该用一个，什么时候该用另一个。 考虑以下两种情况： 如果由于某种原因（例如错误修复或意外崩溃）需要关闭或重新启动整个应用程序，那么我必须使用保存点来恢复整个应用程序
-
一、状态分类 相对于其他流计算框架，Flink 一个比较重要的特性就是其支持有状态计算。即你可以将中间的计算结果进行保存，并提供给后续的计算使用： 具体而言，Flink 又将状态 (State) 分为 Keyed State 与 Operator State： 2.1 算子状态 算子状态 (Operator State)：顾名思义，状态是和算子进行绑定的，一个算子的状态不能被其他算子所访问到。官方
-
下面是我对Flink的疑问。 我们可以将检查点和保存点存储到RockDB等外部数据结构中吗？还是只是我们可以存储在RockDB等中的状态。 状态后端是否会影响检查点？如果是，以何种方式？ 什么是状态处理器API？它与我们存储的保存点和检查点直接相关吗？状态处理器API提供了普通保存点无法提供的哪些额外好处？ 对于3个问题，请尽可能描述性地回答。我对学习状态处理器API很感兴趣，但我想深入了解它的应
-
我正在kubernetes中运行一个Flink作业。我的设置如下 1个作业管理器吊舱 我的flink作业从kafka源获取时间序列数据（时间、值），进行聚合和其他转换，并将其发布到kafka接收器。 有时，我的作业因检查点异常（10分钟后超时）而失败，主要是由一名操作员完成的。我不理解异步持续时间（在图中）的含义，为什么它花费的时间最长。在这个异常之前，Kafka的吞吐量非常高，有500-800万
-
我可以在文档中看到： Flink目前只为没有迭代的作业提供处理保证。对迭代作业启用检查点会导致异常。为了在迭代程序上强制检查点，用户需要在启用检查点时设置一个特殊的标志：env.enablecheckpointing（interval,force=true）。 如果是一个而不是一个（这意味着它也可以保存状态），会有什么变化吗？
-
简而言之，我想从一开始就对Kafka的数据重新运行Flink管道。 Flink0.10.2，Kafka0.8.2。 我在Kafka中有一个保留2小时的推文主题，以及Flink中的一个管道，该管道以每10秒5分钟的滑动窗口计算推文。 如果我中断管道并重新运行它，我希望它重新读取旧推文，从而发出价值5分钟的推文计数。相反，它似乎从新到达的推文重新开始，因此需要5分钟才能计数为“处于状态”。 我已经尝试