Flink如何通过Task Metrics来定位反压节点？

Flink 提供的 Task Metrics 是更好的反压监控手段，但也要求更加丰富的背景 知识。 首先我们简单回顾下 Flink 1.5 以后的网路栈，熟悉的读者可以直接跳过。 TaskManager 传输数据时，不同的 TaskManager 上的两个 Subtask 间通 常根据 key 的数量有多个 Channel，这些 Channel 会复用同一个 TaskManager 级别的 TCP 链接，并且共享接收端 Subtask 级别的 Buffer Pool。 在接收端，每个 Channel 在初始阶段会被分配固定数量的 Exclusive Buffer， 这些 Buffer 会被用于存储接受到的数据，交给 Operator 使用后再次被释放。 Channel 接收端空闲的 Buffer 数量称为 Credit，Credit 会被定时同步给发送端被后 者用于决定发送多少个 Buffer 的数据。 在流量较大时，Channel 的 Exclusive Buffer 可能会被写满，此时 Flink 会向 Buffer Pool 申请剩余的 Floating Buffer。这些 Floating Buffer 属于备用 Buffer，哪 个 Channel 需要就去哪里。而在 Channel 发送端，一个 Subtask 所有的 Channel 会共享同一个 Buffer Pool，这边就没有区分 Exclusive Buffer 和 Floating Buffer。 我们在监控反压时会用到的 Metrics 主要和 Channel 接受端的 Buffer 使用率有 关，最为有用的是以下几个 Metrics: 其中 inPoolUsage 等于 floatingBuffersUsage 与 exclusiveBuffersUsage 的 总和。 分析反压的大致思路是：如果一个 Subtask 的发送端 Buffer 占用率很高，则表 明它被下游反压限速了；如果一个 Subtask 的接受端 Buffer 占用很高，则表明它将 反压传导至上游。反压情况可以根据以下表格进行对号入座 ( 图片来自官网 ): outPoolUsage 和 inPoolUsage 同为低或同为高分别表明当前 Subtask 正 常或处于被下游反压，这应该没有太多疑问。而比较有趣的是当 outPoolUsage 和 inPoolUsage 表现不同时，这可能是出于反压传导的中间状态或者表明该 Subtask 就是反压的根源。 如果一个 Subtask 的 outPoolUsage 是高，通常是被下游 Task 所影响，所以 可以排查它本身是反压根源的可能性。如果一个 Subtask 的 outPoolUsage 是低， 但其 inPoolUsage 是高，则表明它有可能是反压的根源。因为通常反压会传导至其 上游，导致上游某些 Subtask 的 outPoolUsage 为高，我们可以根据这点来进一步 判断。值得注意的是，反压有时是短暂的且影响不大，比如来自某个 Channel 的短 暂网络延迟或者 TaskManager 的正常 GC，这种情况下我们可以不用处理。 对于 Flink 1.9 及以上版本，除了上述的表格，我们还可以根据 floatingBuffersUsage/exclusiveBuffersUsage 以及其上游 Task 的 outPoolUsage 来进行进一 步的分析一个 Subtask 和其上游 Subtask 的数据传输。 通常来说，floatingBuffersUsage 为高则表明反压正在传导至上游，而 exclusiveBuffersUsage 则表明了反压是否存在倾斜（floatingBuffersUsage 高、exclusiveBuffersUsage 低为有倾斜，因为少数 channel 占用了大部分的 Floating Buffer）。 至此，我们已经有比较丰富的手段定位反压的根源是出现在哪个节点，但是具体 的原因还没有办法找到。另外基于网络的反压 metrics 并不能定位到具体的 Operator， 只能定位到 Task。特别是 embarrassingly parallel（易并行）的作业（所有的 Operator 会被放入一个 Task，因此只有一个节点），反压 metrics 则派不上用场。