最小延迟的 Flink 优化配置

Question

对于 Flink 流式传输/Flink 有状态函数，众所周知，将setBufferTimeout 设置为较小的值（例如 5 毫秒）将提供“最佳”延迟体验。在优化 Flink 流或有状态函数作业中的延迟时，还必须注意哪些其他推荐的配置值（设置、重置、修改..）？

Answer 1

端到端延迟受许多因素影响。忽略 Flink 摄取事件之前产生的延迟，需要考虑以下问题：

• 网络缓冲区超时
• 序列化
• 对象重用
• 水印延迟（用于适应乱序事件）
• 自动水印间隔
• 状态访问（取决于状态后端）
• 垃圾回收
• 定时器
• 聚合（例如，窗口化）
• 交易汇
• 检查点
• 背压

利用运营商链。避免不必要地使用 keyBy 和更改并行度。在适当的地方使用reinterpretAsKeyedStream。

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

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

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

如果你避开这两点，你可能

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

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

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

避免同时触发多个计时器。安排窗口让不同的按键在不同的时间触发。

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

如果您不需要完全一次保证，请通过将检查点配置为使用CheckpointConfigInfo.ProcessingMode.AT_LEAST_ONCE 来禁用检查点屏障对齐。

在某些情况下，未对齐的检查点非常有用。

最后，尽你所能避免背压。为工作提供足够的资源。不要在你的用户函数中做任何阻塞 i/o。尽量避免数据倾斜（热键）。