Flink优化配置以实现最小延迟

端到端延迟受到许多因素的影响。忽略Flink摄入事件之前累积的延迟,这就需要考虑以下问题:

• 网络缓冲区超时
• 序列化
• 对象重用
• 水印延迟(用于适应无序事件)
• 自动水印间隔
• 状态访问(依赖于状态后端)
• 垃圾收集
• 定时器
• 聚合(例如窗口)
• 事务性汇
• 检查点
• 背压

利用操作员链。避免不必要地使用keyBy和更改并行度。使用 reinterpretAsKeyedStream 在适当的情况下。

以上这些点将有助于避免不必要的序列化,但您也应该注意优化序列化。使用缓慢的序列化程序可能会产生巨大的影响,使用复杂的、深度嵌套的集合类型也会产生巨大影响,而使用更简单的方法就可以做到这一点。

您应该始终启用对象重用。默认情况下,Flink会防御性地复制通过操作符链传递的对象。启用对象重用时,请记住 不安全 到

• 记住跨函数调用的输入对象引用,或
• 修改输入对象

如果你避开这两点,你 五月

• 修改输出对象并再次发出

如果您正在使用事件时间处理,最佳情况是能够依靠递增的时间戳,并相应地生成水印(零延迟)。如果您正在进行窗口化,则进行预聚合将避免窗口关闭时的负载峰值,配置较短的自动水印间隔将有助于最大限度地减少延迟。

FsStateBackend将状态作为堆上的对象进行维护,然后对其进行GC。此状态后端具有最佳的平均延迟,但您需要仔细调整垃圾收集器以避免GC停滞。虽然总体上要慢得多,但RocksDB状态后端可能有更好的最坏情况延迟,特别是如果你需要在每个任务管理器上运行多个任务槽。使用FsStateBackend,每个TM一个插槽将使GC的范围更小,这有助于减少延迟。

避免同时启动多个定时器。为不同的钥匙安排窗户,以便在不同的时间点火。

请记住,事务接收器的下游消费者将经历由检查点间隔控制的延迟。

如果您不需要精确的一次保证,请通过配置检查点来禁用检查点屏障对齐 CheckpointConfigInfo.ProcessingMode.AT_LEAST_ONCE .

在某些情况下,不对齐的检查点可能非常有用。

最后,尽你所能避免背压。给这份工作更多的资源。不要在用户函数中执行任何阻塞i/o。尽量避免数据倾斜(热键)。