Flink 最小延迟的最佳配置

Question

对于 Flink 流/Flink 有状态功能，已知较小setBufferTimeout的值（例如 5 毫秒）将提供“最佳”延迟体验。在优化 Flink 流或有状态函数作业中的延迟时，必须注意的其他推荐配置值（设置、重置、修改......）是什么？

Answer 1

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

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

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

上述几点将有助于避免不必要的序列化，但您还应该注意优化序列化。使用缓慢的序列化器可能会产生巨大的影响，就像使用复杂的、深度嵌套的集合类型一样，在更简单的情况下也可以做到这一点。

您应该始终启用对象重用。默认情况下，Flink 会防御性地复制沿算子链传递的对象。启用对象重用时，请记住，这样做是不安全的

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

如果你避免了这两点，你可能

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

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

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

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

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

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

在某些情况下，未对齐的检查点可能非常有帮助。

最后，尽一切努力避免背压。为工作提供充足的资源。不要在用户函数中执行任何阻塞 I/O。尽量避免数据倾斜（热键）。