当某个步骤、阶段或工作器减慢整个作业的速度时，就会出现瓶颈。瓶颈可能会导致工作器闲置和延迟时间增加。
如果 Dataflow 检测到瓶颈，作业图会显示提醒，并且步骤信息面板会列出瓶颈的类型和原因（如果已知）。Dataflow 还会将瓶颈检测信息导出到 Stackdriver 指标，该指标以时间序列的形式呈现数据。这样一来，您就可以查看一段时间内或过去存在的瓶颈。
了解瓶颈
当 Dataflow 运行流处理流水线时，作业由一系列组件组成，例如流处理 shuffle、用户定义的函数 (DoFn) 处理线程和持久状态检查点。为了促进数据流，Dataflow 使用队列来连接这些组件。数据从上游推送到下游。
在许多流水线中，整体吞吐量容量受单个组件的限制，从而在流水线中形成瓶颈。数据通过瓶颈的速率限制了流水线接受和处理输入数据的速度。
例如，假设某个流水线中，DoFn 处理发生在流式 Shuffle 的下游。它们之间有一个队列，用于缓冲经过随机处理但未处理的数据。如果 DoFn 处理无法像流式 Shuffle 那样快速使用数据，队列就会增长。如果瓶颈持续存在，可能会导致队列达到容量上限。此时，系统会暂停进一步的随机播放，并将积压内容向上游传播。上游队列也会累积积压，最终导致速度减慢，并影响到数据源，这意味着整个流水线无法跟上输入的速度。
出现瓶颈时，流水线的大部分可能看起来都不正常，即使流水线中的单个点导致了积压也是如此。此行为可能会导致难以调试瓶颈。瓶颈检测的目标是确定确切的位置和原因，消除猜测，以便您解决根本原因。
当延迟时间超过 5 分钟的阈值时，Dataflow 会检测到瓶颈。如果延迟未超过此阈值，Dataflow 将不会检测到瓶颈。
瓶颈检测并不总是需要您采取行动，具体取决于您的使用情形。如果流水线出现超过 5 分钟的短暂延迟，仍可正常运行。如果您的使用情形可以接受这种情况，您可能无需解决指明的瓶颈。
瓶颈类型
当 Dataflow 检测到瓶颈时，监控界面会指明问题的严重程度。瓶颈分为以下几类：
- 处理卡住，没有任何进展
- 流水线在此步骤中完全停止。
- 正在进行处理，但进度落后。
- 流水线无法像接收数据那样快速处理传入的数据。因此，积压的订单越来越多。
- 正在进行处理，但一直存在积压
- 流水线正在取得进展，处理速率与输入速率相当。处理速度足够快，积压作业不会增加，但累积的积压作业也不会明显减少。
- 正在进行处理，且积压正在减少
- 积压在减少，但当前瓶颈阻止了流水线更快地赶上。如果您启动的流水线存在积压，则此状态可能属于正常情况，无需任何干预。监控进度，看看积压是否继续减少。
瓶颈的原因
监控界面会显示瓶颈的原因（如果已知）。请使用此信息来解决问题。
- 处理时间较长的操作
计算处理时间较长。每当输入软件包发送到执行
DoFn的工作器，并且在很长时间内没有结果可用时，就会发生这种情况。这通常是用户代码中单个长时间运行的操作造成的。其他问题可能会表现为处理时间较长的操作。例如，
DoFn内抛出并重试的错误、长时间的重试或因 OOM 等因素导致的工作器框架崩溃，都可能会导致处理时间过长。如果受影响的计算位于用户代码中，请寻找优化代码或限制执行时间的方法。为了帮助进行调试，工作器日志会显示卡滞时间超过 5 分钟的任何操作的堆栈轨迹。
- 持久状态读取速度缓慢
计算在执行
DoFn时花费了大量时间来读取持久状态。这可能是由于持久性状态过大或读取次数过多造成的。请考虑减小持久化状态大小或读取频率。这可能也是一个暂时性问题，原因是底层持久状态速度较慢。- 持久状态写入缓慢
计算在提交处理结果期间花费了大量时间来写入持久状态。这可能是持久状态过大造成的。考虑减小持久化状态的大小。这可能也是一个暂时性问题，原因是底层持久状态缓慢。
- 被拒绝的提交
由于数据无效，无法将数据处理提交到持久状态。 这通常是因为超出某项操作限制。 如需了解详情，请查看日志，或与支持团队联系。
- Apache Kafka 来源分区不足
Apache Kafka 来源计算的分区不足。如需解决此问题，请尝试执行以下操作：
- 增加 Kafka 分区的数量。
- 使用
Redistribute转换可以更高效地重新分布数据并实现数据并行化。
如需了解详情，请参阅从 Apache Kafka 读取到 Dataflow 页面中的并行处理。
- 来源并行度不足
来源计算的并行度不足。如果可能，请增加来源中的并行化程度。如果您无法提高并行化程度，并且作业使用“至少一次”模式，请尝试向流水线添加
Redistribute转换。- 热键，或键并行度不足
作业存在热键或键并行度不足。
对于每个分片键，Dataflow 会按顺序处理消息。当 Dataflow 正在处理某个键的一批消息时，该键的其他传入消息会排队等待，直到当前批次处理完毕。
如果 Dataflow 无法并行处理足够多的不同键，则可能会导致瓶颈。例如，数据可能具有过少的不同键，或者某些键可能在数据中过度表示（“热门键”）。如需了解详情，请参阅排查作业缓慢或卡住的问题。
- vCPU 预配不足
作业的工作器 vCPU 不足。当作业已扩缩到最大规模、vCPU 利用率较高且仍有积压时，就会出现这种情况。
- 与工作器通信时出现问题
Dataflow 无法与所有工作器虚拟机通信。检查作业的工作器虚拟机的状态。可能的原因包括：
- 工作器虚拟机的配置存在问题。
- 作业运行时，工作器虚拟机池被删除。
- 网络问题。
- Pub/Sub 来源的并行度不足
Pub/Sub 源计算的 Pub/Sub 键数量不足。如果您看到此警告，请与支持团队联系。
- Pub/Sub 来源因未知原因而受到限制
从 Pub/Sub 读取数据时，Pub/Sub 来源计算因未知原因而受到限制。此问题可能是暂时性的。 检查是否存在 Pub/Sub 配置问题、缺少 IAM 权限或配额限制。 不过，如果上述任何方面都不是根本原因，并且问题仍然存在，请与支持团队联系。
- Pub/Sub 接收器发布速度缓慢或卡住
Pub/Sub 接收器计算速度缓慢或卡住。此问题可能是由配置问题或配额限制导致的。
- 工作队列时间较长
由于密钥数量较多以及密钥处理速率，最旧的符合条件的工作年龄较高。在这种情况下，每次操作的时间可能并不异常长，但总体排队延迟时间较长。
Dataflow 为每个分片键使用一个处理线程，并且处理线程的数量有限。排队延迟时间大致等于键数与线程数的比率，乘以每个处理捆绑包的线程内延迟时间（针对某个键）：
(key count / total harness threads) * latency per bundle请尝试以下补救措施：
- Streaming Engine 后端存在暂时性问题
Streaming Engine 后端存在配置或运行问题。此问题可能是暂时性的。如果问题仍然存在，请与支持团队联系。