【问题标题】:Flink Checkpoint Failure - Checkpoints time out after 10 minsFlink 检查点失败 - 检查点在 10 分钟后超时
【发布时间】:2019-04-25 20:38:51
【问题描述】:

我们每天在处理数据的过程中都会遇到一两次检查点故障。数据量很低,比如不到 10k,我们的间隔设置是“2 分钟”。 (处理速度很慢的原因是我们需要在 flink 作业结束时将数据下沉到另一个 API 端点,这需要一些时间来处理,所以时间是 Streaming data + Sink to external API endpoint)。

根本问题是: Checkpoints 在 10 分钟后超时,这是由于数据处理时间超过 10 分钟造成的,所以 checkpoint 超时。我们可能会增加并行度以加快处理速度,但是如果数据变大,我们必须再次增加并行度,所以不想使用这种方式。

建议的解决方案: 我看到有人建议在新旧检查点之间设置暂停,但我有一个问题是,如果我在那里设置暂停时间,新检查点是否会丢失暂停时间的状态?

目标: 如何避免这个问题并记录正确的状态,不会丢失任何数据?

检查点失败: enter image description here

已完成的检查点: enter image description here

子任务没有响应 enter image description here

谢谢

【问题讨论】:

  • 它到底是怎么失败的?超时?
  • 检查点在 10 分钟后超时,所以我看到有人建议在旧检查点和新检查点之间设置暂停,但我有一个问题是,如果我在那里设置暂停时间,新检查点会不会缺少暂停时间的状态? @TobiSH

标签: stream apache-flink checkpoint


【解决方案1】:

您可以设置几个相关的配置变量——例如检查点间隔、检查点之间的暂停以及并发检查点的数量。这些设置的任何组合都不会导致数据被跳过以进行检查点。

设置检查点之间的间隔意味着 Flink 不会在前一个检查点完成(或失败)后的一段时间后启动新的检查点——但这对超时没有影响。

听起来你应该延长超时时间,你可以这样做:

env.getCheckpointConfig().setCheckpointTimeout(n);

n 以毫秒为单位。有关详细信息,请参阅 enabling and configuring checkpointing 上的 Flink 文档部分。

【讨论】:

  • 我发现一个有趣的事情是失败的检查点只记录了与完成检查点相比的较少状态,并且确认时间也比完成的时间短。任何的想法?我附上了截图。
  • 您的检查点这么小,却需要这么长时间才能完成,这似乎很奇怪。您是否有可能阻碍检查点障碍取得进展的沉重背压?
  • 我们确实有背压,但我不确定它是否会阻止检查点障碍取得进展。但是,我观察到一些子任务没有响应,我相信它会导致检查点失败。我附上了截图。有什么想法吗?
  • 其他子任务都很快完成,只有截图中的第一个直到超时才响应。不知道是什么原因。
猜你喜欢
  • 2021-01-10
  • 2021-01-27
  • 1970-01-01
  • 1970-01-01
  • 2022-11-13
  • 1970-01-01
  • 2015-09-25
  • 2023-01-18
  • 1970-01-01
相关资源
最近更新 更多