本页面介绍如何排查 Dataflow 流式作业和批处理作业缓慢或卡住的常见原因。
流式
如果您发现以下症状,则表示您的 Dataflow 流式作业可能运行缓慢或卡住:
使用以下部分中的信息来识别和诊断问题。
调查重复失败
在流处理作业中,部分失败会无限期重试。这些重试操作会导致流水线无法继续运行。如需识别重复失败,请检查工作器日志中是否存在异常。
- 如果用户代码出现异常,请调试并修复代码或数据中的问题。
- 为防止意外失败导致流水线停滞,请实现死信队列。如需实现示例,请参阅 Apache Beam 文档中的 BigQuery 模式。
- 如果异常是内存不足 (OOM) 错误,请参阅排查 Dataflow 内存不足错误。
- 如需了解其他异常,请参阅排查 Dataflow 错误。
识别运行状况不佳的工作器
如果处理流式作业的工作器运行状况不佳,则作业可能运行缓慢或卡住。如需识别运行状况不佳的工作器,请执行以下操作:
- 使用内存利用率指标并查找工作器日志中的内存不足错误,以检查内存压力。如需了解详情,请参阅排查 Dataflow 内存不足错误。
- 如果您使用的是 Streaming Engine,请使用持久性指标找出包含磁盘输入/输出操作 (IOPS) 的瓶颈。
- 检查工作器日志中是否存在其他错误。如需了解详情,请参阅使用流水线日志和排查 Dataflow 错误。
确定 Straggler
Straggler 是一种工作项,与阶段中的其他工作项相比速度较慢。如需了解如何识别和修复 Straggler,请参阅排查流处理作业中的 Straggler 问题。
排查并行性不足问题
为了提高可扩缩性和效率,Dataflow 会跨多个工作器并行运行流水线的各个阶段。Dataflow 中的最小并行处理单元是键。每个融合阶段的传入消息都与键相关联。密钥通过以下方式定义:
- 键由来源的属性(例如 Pub/Sub 分区)隐式定义。
- 键由流水线中的聚合逻辑明确定义,例如
GroupByKey
。
如果流水线的给定阶段没有足够的键,则会限制并行处理。此阶段可能会成为瓶颈。
确定并行性较低的阶段
如需确定流水线运行缓慢是否由并行性低导致,请查看 CPU 利用率指标。如果 CPU 较低,但在工作器之间均匀分布,则作业可能并行性不足。如果您的作业使用 Streaming Engine,如需了解阶段是否具有并行性,请在作业指标查看并行指标。 为了缓解这一问题:
- 在 Google Cloud 控制台的作业信息页面上,使用“自动扩缩”标签页查看作业在纵向扩容时是否遇到问题。如果问题与自动扩缩有关,请参阅排查 Dataflow 自动扩缩问题。
- 使用作业图检查阶段中的步骤。如果阶段是从来源读取数据或向接收器写入数据,请参阅来源或接收器服务的文档。使用该文档确定该服务是否配置为具有足够的可扩缩性。
- 如需收集更多信息,请使用 Dataflow 提供的输入和输出指标。
- 如果您使用的是 Kafta,请检查 Kafka 分区的数量。如需了解详情,请参阅 Apache Kafka 文档。
- 如果您使用的是 BigQuery 接收器,请启用自动分片以提高并行性。如需了解详情,请参阅适用于 BigQuery 的自动分片的 3 倍 Dataflow 吞吐量。
检查热键
如果任务在工作器之间分布不均匀,且工作器利用率非常不均匀,则您的流水线可能具有热键。与其他键相比,热键是需要处理更多元素的键。如需解决此问题,请执行以下步骤之一:
- 重新生成数据键。如需输出新的键值对,请应用
ParDo
转换。 如需了解详情,请参阅 Apache Beam 文档中的 JavaParDo
转换页面或 PythonParDo
转换页面。 - 在 Combine 转换中使用
.withFanout
。如需了解详情,请参阅 Java SDK 中的Combine.PerKey
类或 Python SDK 中的with_hot_key_fanout
操作。 - 如果您有 Java 流水线来处理大量无界限
PCollections
,我们建议您执行以下操作:- 使用
Combine.Globally.withFanout
,而不要使用Combine.Globally
。 - 使用
Combine.PerKey.withHotKeyFanout
,而不要使用Count.PerKey
。
- 使用
检查配额不足问题
确保您的来源和接收器有足够的配额。例如,如果您的流水线从 Pub/Sub 或 BigQuery 读取输入,则您的 Google Cloud 项目可能没有足够的配额。如需详细了解这些服务的配额限制,请参阅 Pub/Sub 配额或 BigQuery 配额。
如果您的作业生成了大量 429 (Rate Limit Exceeded)
错误,则配额可能不足。如需检查是否存在错误,请尝试执行以下步骤:
- 前往 Google Cloud 控制台。
- 在导航窗格中,点击 API 和服务。
- 点击菜单中的库。
- 使用搜索框搜索 Pub/Sub。
- 点击 Cloud Pub/Sub API。
- 点击管理。
- 在按响应代码划分的流量图表中,查找
(4xx)
客户端错误代码。
您还可以使用 Metrics Explorer 检查配额使用情况。如果您的流水线使用 BigQuery 来源或接收器来排查配额问题,请使用 BigQuery Storage API 指标。例如,如需创建显示 BigQuery 并发连接计数的图表,请按照以下步骤操作:
在 Google Cloud 控制台中,选择 Monitoring:
在导航窗格中,选择 Metrics Explorer。
在选择指标窗格,对于指标,过滤至 BigQuery 项目 > 写入 > 并发连接计数。
如需了解如何查看 Pub/Sub 指标,请参阅“监控 Cloud Monitoring 中的 Pub/Sub”中的监控配额用量。如需了解如何查看 BigQuery 指标,请参阅“创建信息中心、图表和提醒”中的查看配额用量和限制。
Batch
如果批量作业运行缓慢或卡住,请使用执行详情标签页查找有关作业的更多信息,并找出导致瓶颈的阶段或工作器。
确定 Straggler
Straggler 是一种工作项,与阶段中的其他工作项相比速度较慢。如需了解如何识别和修复 Straggler,请参阅排查批处理作业中的 Straggler 问题。
识别缓慢或卡住的阶段
如需识别缓慢或卡住的阶段,请使用阶段进度视图。 较长的柱形表示阶段需要较多时间。使用此视图可以确定流水线中最慢的阶段。
找到瓶颈阶段后,您可以执行以下步骤:
- 识别该阶段中的滞后工作器。
- 如果没有滞后工作器,请使用阶段信息面板确定最慢的步骤。使用此信息确定用户代码优化的候选对象。
- 如需找出并行性瓶颈,请使用 Dataflow 监控指标。
确定滞后的工作器
如需确定特定阶段的滞后工作器,请使用工作器进度视图。此视图会显示所有工作器是否会一直处理工作,直到阶段结束或者单个工作器卡在延迟任务上。如果您发现滞后的工作器,请执行以下步骤:
- 查看该工作器的日志文件。如需了解详情,请参阅监控和查看流水线日志。
- 查看滞后工作器的 CPU 利用率指标和工作器进度详细信息。如果您发现该工作器的日志文件中 CPU 利用率异常高或低,请查看以下问题:
用于调试的工具
如果流水线运行缓慢或卡住,以下工具可帮助您诊断问题。
- 如需关联突发事件并识别瓶颈,请使用 Cloud Monitoring for Dataflow。
- 如需监控流水线性能,请使用 Cloud Profiler。
- 某些转换比其他转换更适合用于高容量流水线。日志消息可以识别批处理或流式处理流水线中卡住的用户转换。
- 如需详细了解卡住的作业,请使用 Dataflow 作业指标。以下列表包含有用的指标:
- 积压字节数指标 (
backlog_bytes
) 按阶段衡量未得到处理的输入量(以字节为单位)。使用此指标查找无吞吐量的组合步骤。 类似地,积压元素指标 (backlog_elements
) 用于衡量一个阶段中未得到处理的输入元素数量。 - 处理并行键 (
processing_parallelism_keys
) 指标用于衡量流水线特定阶段在过去 5 分钟内的并行处理键数。使用此指标可通过以下方式进行调查:- 将问题范围缩小到特定阶段,并确认热键警告,例如
A hot key ... was detected
。 - 找出由并行性不足引起的吞吐量瓶颈。 这些瓶颈可能会导致流水线运行缓慢或卡住。
- 将问题范围缩小到特定阶段,并确认热键警告,例如
- 系统延迟时间指标 (
system_lag
) 和每个阶段的系统延迟时间指标 (per_stage_system_lag
) 用于衡量某个数据项已处理或等待处理的最长时间。使用这些指标来识别数据源中效率低下的阶段和瓶颈。
- 积压字节数指标 (
如需了解 Dataflow 监控网页界面中未包含的其他指标,请参阅 Google Cloud 指标中 Dataflow 指标的完整列表。