何时清理flink检查点文件？
我有一份流媒体工作：
读Kafka--
启动时，一切都很好。问题是，过了一段时间，磁盘空间被我认为是链接检查点的东西填满了。
我的问题是，在链接作业运行时是否应该清除/删除检查点？找不到此上的任何资源。
我使用的是写入/tmp的文件系统后端（无hdfs设置）
共有2个答案
默认情况下，检查点不会在外部持久化，仅用于从故障中恢复作业。当程序被取消时，它们会被删除。
如果您使用外部检查点，那么它有两个策略
外部化检查点清理。RETAIN_ON_CANCELLATION：取消作业时保留外部化的检查点。请注意，在这种情况下，取消后必须手动清除检查点状态。
外部化检查点清理。DELETE\u ON\u CANCELLATION：取消作业时删除外部化的检查点。检查点状态仅在作业失败时可用。
有关更多详细信息https://ci.apache.org/projects/flink/flink-docs-release-1.4/ops/state/checkpoints.html
Flink在运行时清理检查点文件。有一些角落的情况下，它“忘记”清理所有文件，以防系统故障。但对于Flink 1.3来说，社区正在努力解决所有这些问题。
在您的情况下，我假设您没有足够的磁盘空间将窗口的数据存储在磁盘上。
-
我有一份很轻松的工作，在创建检查站方面很吃力。它几乎没有州（除了一些Kafka偏移）。 工作本身有以下基本设置： Kafka索资源- 迭代函数再次执行HTTP调用并转发成功的消息，丢弃4xx并重试5xx。从我的指标中可以看到，所有这些都发生了，我得到了一些5xx（返回迭代源）、一些4xx（忽略）和很多2xx（转发到HDFS）。 如果我查看线程转储，我可以看到某个任务被阻止了： 这一个正在等待对象监
-
下面是我对Flink的疑问。 我们可以将检查点和保存点存储到RockDB等外部数据结构中吗？还是只是我们可以存储在RockDB等中的状态。 状态后端是否会影响检查点？如果是，以何种方式？ 什么是状态处理器API？它与我们存储的保存点和检查点直接相关吗？状态处理器API提供了普通保存点无法提供的哪些额外好处？ 对于3个问题，请尽可能描述性地回答。我对学习状态处理器API很感兴趣，但我想深入了解它的应
-
一、状态分类 相对于其他流计算框架，Flink 一个比较重要的特性就是其支持有状态计算。即你可以将中间的计算结果进行保存，并提供给后续的计算使用： 具体而言，Flink 又将状态 (State) 分为 Keyed State 与 Operator State： 2.1 算子状态 算子状态 (Operator State)：顾名思义，状态是和算子进行绑定的，一个算子的状态不能被其他算子所访问到。官方
-
我可以在文档中看到： Flink目前只为没有迭代的作业提供处理保证。对迭代作业启用检查点会导致异常。为了在迭代程序上强制检查点，用户需要在启用检查点时设置一个特殊的标志：env.enablecheckpointing（interval,force=true）。 如果是一个而不是一个（这意味着它也可以保存状态），会有什么变化吗？
-
我们正在接收来自多个独立数据源的事件，因此，到达我们Flink拓扑（通过Kafka）的数据将是无序的。 我们正在Flink拓扑中创建1分钟的事件时间窗口，并在源操作符处生成事件时间水印（当前事件时间-某些阈值（30秒））。 如果一些事件在设置的阈值之后到达，那么这些事件将被忽略（在我们的例子中这是可以的，因为属于该分钟的大多数事件都已经到达并在相应的窗口中得到处理）。 现在的问题是，如果程序崩溃（
-
我想在flink中测试一次端到端的处理。我的工作是： Kafka资料来源- 我在mapper1中放了一个< code > thread . sleep(100000)，然后运行了这个作业。我在停止作业时获取了保存点，然后从mapper1中删除了< code > thread . sleep(100000)，我希望该事件应该会被重放，因为它没有下沉。但这并没有发生，乔布斯正在等待新的事件。 我的Ka