Flink 子任务数量与资源占用的关系

Relationship between number of subtasks in Flink and resource usage

我在 Flink 运行 中有以下工作流程,在 GCP 上有 3 台机器,每台机器有 4 个内核。

HDFS-Scan -> Filter -> Aggregate

我最初将这些操作符的并行度设置为 12,这样每个操作符可以有 12 个子任务(我禁用了链接)。我正在尝试研究子任务数量对资源使用的影响。以下是我所做的:

  1. Run 1:我使过滤器操作逻辑变得昂贵,以便它调用背压。总执行时间为 212 秒。

  2. Run 2:我让过滤器运算符很昂贵。由于扫描运算符无论如何都会受到背压,我将其并行度一直降低到 4。并行度较低意味着扫描生成数据的速度较慢,但​​ Filter 仍然是瓶颈。执行时间仍然在212秒左右。

  3. Run 3:我让过滤器运算符很昂贵。我把scan算子的并行度降低到2,此时scan成了瓶颈,执行时间变长了。

我的问题是关于 Run 2。我原以为减少扫描的并行性会对 VM 的 CPU 使用产生影响。我预计有两种情况 - 1) CPU 使用率应该下降,因为 CPU 会更自由,或者 2) 过滤子任务占用扫描子任务释放的 CPU。在这种情况下 CPU 使用率不会下降,但执行时间应该会下降。但这些都没有发生。

谁能帮我理解一下?有没有其他方法可以推断正在发生的事情?

我希望在 运行 1 和 运行 2 中花费在 HDFS-Scan 子任务集合上的总 CPU 努力大致相同。是否有这个 HDFS-Scan 运算符的 4 或 12 个子任务没有太大区别,因为他们大部分时间都在阻塞,在等待 Flink 的 credit-based 流控制为他们工作分配缓冲区时什么都不做与.

只是为了弥补一些数字,也许在 12 个实例中,每个实例都有 75% 的时间被阻止,而在 4 个实例中,每个实例都有 25% 的时间被阻止。虽然与 4 个相比,12 个的开销要多一些,但总体性能可能主要由 ser/de 加上过滤器正在执行的操作决定。

(子)任务可以处于三种状态之一:

  • idle,意思是无事可做
  • 背压,这意味着它不能做任何事情,因为它没有可用的输出缓冲区
  • busy,表示它正在积极处理事件

一个任务(算子链的一个实例)对应一个JVM线程。单个任务管理器中所有插槽中的所有任务都在相互竞争该任务管理器的 JVM 可用的资源(CPU、内存等)。

当空闲或背压时,任务不会消耗任何(大量)CPU 时间。因为在任何 Flink 管道中都有少量固定的缓冲,任何背压都会迅速向上游传播并最终限制源。

因此,在您的情况下,无论是有 12 个源任务在背压时几乎什么都不做,还是有 4 个有点忙,这些源任务共同产生相同数量的事件(无论下游瓶颈有多少可以处理)并花费(大约)相同数量的 CPU 来完成它。