如何防止高负载导致级联的Flink检查点故障

Question

我将自愿提出几点建议：

1. 我是Flink的新手（大约工作了一个月）
2. 我正在使用Kinesis Analytics（AWS托管的Flink解决方案）。众所周知，这并没有真正限制Flink的多功能性或容错选项，但无论如何我都会称呼它。

我们有一个相当简单的滑动窗口应用程序。密钥流通过特定的密钥（例如IP地址）组织事件，然后在ProcessorFunction中对其进行处理。我们主要使用它来跟踪事物计数。例如，最近24小时内某个IP地址的登录次数。每隔30秒，我们就按键对窗口中的事件进行计数，然后将该值保存到外部数据存储中。状态也会更新，以反映该窗口中的事件，以便旧事件过期并且不会占用内存。

有趣的是，基数不是问题。如果我们有24万人在24小时内登录，那么一切就完美了。当一个IP在24小时内登录200k次时，事情开始变得繁琐。此时，检查点开始花费的时间越来越长。平均检查点需要2-3秒，但是按照这种用户行为，检查点开始需要5分钟，然后是10分钟，然后是15分钟，然后是30分钟，然后是40分钟，依此类推。

令人惊讶的是，该应用程序在这种情况下可以顺利运行一段时间。大概10或12个小时。但是，迟早检查点完全失败，然后我们的最大迭代器寿命开始增加，并且不处理任何新事件，等等。

目前我已经尝试了一些方法：

1. 在问题上投入更多金属（自动缩放功能也已打开）
2. 检查点间隔和检查点之间的MinimumPauseBetween https://docs.aws.amazon.com/kinesisanalytics/latest/apiv2/API_CheckpointConfiguration.html
3. 进行重构以减少所存储状态的占用空间

（1）并没有做太多事情。（2）这似乎有所帮助，但随后的流量峰值又比我们在压缩任何优势之前看到的流量大得多（3）尚不清楚这是否有帮助。与您在Yelp或Airbnb中都使用Flink群集用于大型应用程序的情况相比，我认为我们的应用程序内存占用量很小，因此我无法想象我的状态确实有问题。

我会说我希望我们不必深刻改变应用程序输出的期望。滑动窗口是非常有价值的数据。

编辑：有人问我的状态看起来像是ValueState [FooState]

case class FooState(
                         entityType: String,
                         entityID: String,
                         events: List[BarStateEvent],
                         tableName: String,
                         baseFeatureName: String,
                       )

case class BarStateEvent(target: Double, eventID: String, timestamp: Long)

我将自愿提出几点：我是Flink的新手（大约工作了一个月），我正在使用Kinesis Analytics（AWS托管的Flink解决方案）。从所有方面来看，这实际上并没有限制...

Answer 1

如果您的滑动窗口长24小时，并且滑动了30秒，那么每次登录都会分配给2880个单独的窗口。没错，Flink的滑动窗口可以制作副本。在这种情况下为24 * 60 * 2份。