任务诊断最佳实践

发起诊断

诊断有对话式和页面版两条路径。页面版在运维中心实例列表单击 运行诊断，按固定步骤展示单个实例的结论，详见 任务运行诊断 与 智能诊断。对话式支持描述现象、跨上下游追溯和多实例归因，使用方式如下。

Web 端入口：

• Data Agent：登录 DataWorks 控制台，选择目标地域后进入运维中心，在左侧导航栏单击 AI 工作台 > Data Agent，并在会话中选择目标工作空间。

• AI 助理服务：登录DataWorks 控制台，选择目标地域，在左侧导航栏单击 AI助理服务，找到目标实例后单击操作列的 对话。

IM 端入口：在已配置的 IM 群聊中向对应机器人发送消息。IM 渠道与账号映射的配置方式请参见 AI 助理实战：配置 IM 端账号映射。

提问时提供任务实例 ID，并说明观察到的现象。现象决定诊断优先检查哪一层证据，例如“首次失败、重跑成功”“一直等待资源”或“今天明显变慢”。

提问示例：

• 帮我诊断这个实例为什么失败：实例 ID

• 这个实例一直没有运行，帮我看看卡在哪里：实例 ID

• 这个实例等待资源很久，是否需要扩容：实例 ID

• 这个任务今天比平时慢很多，帮我分析一下：实例 ID

• 这批实例同时异常，帮我找共同原因：实例 ID 列表

1～2 个实例逐个诊断；3 个及以上先做批量诊断识别共性问题，再对重点实例单独深入诊断。

提交后以对话形式返回诊断报告，内容构成与阅读方法参见下文「阅读诊断结果」

阅读诊断结果

报告固定包含四段内容：

1. 诊断结论：任务名与括号中的当前状态，作为报告标题。

2. 根因：一句话说明问题发生在哪一层，以及当前能够确认的原因。

3. 关键证据：支持该结论的日志行号、错误码、原始报错、依赖状态、变更记录或指标数值，构成可复核的证据链。

4. 建议：与根因直接对应、能够执行的动作，按优先级排列。

另有两段按需出现：与主根因相互独立的问题列在同时发现中，不并入根因；证据缺口与结论适用范围以灰色文字附在报告末尾，说明哪些信息未能采集以及是否影响当前判断。

诊断结论：wengzi_test_migration_table_4（未运行）
根因：上游实例阻塞，当前实例尚未被调度执行。
关键证据：
实例状态为 NotRun，触发时间为 2026-08-17 23:55:00，但从未开始运行（startedTime 为空）。
上游阻塞节点为同名任务 wengzi_test_migration_table_4（实例 ID 400343380392），状态同样为 NotRun，形成自依赖或同链路阻塞。
失败链路共 1 个异常节点，即上游自身未运行导致下游无法调度。
该任务为小时调度离线同步任务（MySQL 到 MySQL），已重跑 1 次，但仍未进入运行。
建议：
检查上游实例 400343380392 为何未运行（可能存在更上游的阻塞、冻结或定时未到），解除上游阻塞后当前实例将自动调度。
如确认上游无需等待，可手动重跑当前实例以触发执行。

根据报告内容，进行根因诊断：

• 阅读顺序：先查看根因，再核对关键证据，最后参考 处理建议。

• 根因原则：报告仅呈现能直接解释当前实例状态的主根因。当证据不足时，会明确指出当前已确认的范围，避免基于零散信息进行推测。常见的根因现象定位，可参见按现象定位根因。

任务未运行

适用于分析处于未运行、等待定时、暂停或等待上游状态的实例。

• 诊断目标

  准确识别实例未开始运行的原因，并将其与代码、资源等运行期失败区分开。诊断逻辑按以下顺序执行：

  1. 检查定时时间

  2. 检查冻结或暂停状态

  3. 检查上游依赖，若发现上游存在失败链，系统将向上追溯，直至定位到最早需要处理的异常节点。

• 诊断示例：定位上游失败链

  当前实例未运行，直接阻塞来自上游实例A。进一步追溯发现，实例B是该依赖链中最早的失败节点。建议：优先处理实例B。待其成功后，下游实例将自动恢复调度。

• 常见诊断结论与处理方式

  结论	含义	处理方式
  等待定时	尚未到触发时间，不属于运行失败	核对业务日期与定时时间，无需重跑
  暂停或冻结	实例未真正执行，不判断 SQL 或引擎根因	确认是否符合预期；需要恢复时先解除暂停或冻结
  等待上游	指出直接阻塞对象；存在失败链时定位到最早的异常节点	先处理失败链最上游的根因实例，不逐个重跑下游
  信息不足	仅能确认实例未运行	按报告说明补充缺失的判断依据后重新诊断

等待资源

适用于实例长时间处于等待资源状态的场景。

• 诊断目标

  准确区分实例排队的原因是并发限制还是资源容量不足，并判断是否需要扩容。诊断逻辑如下：

  1. 首先检查任务自身或其所属工作流的 最大实例数并发限制。

  2. 若未达到并发限制，则进一步分析资源组在实例等待期间的容量瓶颈，综合判断 资源组CU水位、调度并发、排队任务数 及配额。

• 诊断示例

  结论：资源组的调度并发已达到上限，但在实例等待期间，计算单元（CU）平均水位较低。建议：瓶颈在于调度能力而非计算能力。应优先评估并适当调高资源组的调度并发上限，而不是直接扩容计算资源。

• 常见诊断结论

  结论	含义	处理方式
  最大实例数限制	瓶颈来自任务或工作流的并发配置，与资源组容量无关	调整任务或工作流的最大并发实例数
  调度并发达到上限	调度并发满载，与 CU 水位高低无关	评估并放宽调度并发上限
  持续容量不足	等待窗口内持续高水位并伴随排队	具备扩容依据，按业务时效要求决定是否扩容
  证据不足	指标缺失或等待窗口过短	补充观测窗口后重新诊断，不据此扩容

  • 扩容决策不应仅依赖单一指标（如单个时间点的资源水位或总等待时长）。

  • 调高并发、扩容或迁移资源组均为变更操作，执行前必须充分评估其对线上任务的影响。

数据集成失败

适用于分析离线同步任务的失败原因，包括当前失败或历史失败。诊断过程结合了DataWorks调度层与数据集成引擎层的信息，进行联合分析。

• 诊断逻辑

  1. 调度层分析：首先检查实例状态、上游依赖、运行历史和原始日志。

  2. 数据集成引擎层分析：若任务已进入引擎执行，则进一步分析Reader（读取端）、Writer（写入端）、字段映射类型、脏数据策略、数据量及性能证据。

  3. 对于重跑成功但需要分析历史失败的场景，诊断将优先定位并分析对应的历史失败日志。

• 典型失败场景及处理

  失败模式	现象	处理方式
  字段类型不兼容	Reader 已读取数据，Writer 写入时源端字符串无法转换为目标数值类型，记录全部成为脏数据，而允许的脏数据条数为 0	修正字段映射、目标字段类型或转换规则，再重新运行验证
  源端连接超时	Reader 初始化阶段连续连接超时，多次重试后仍未读取到数据	检查资源组到数据源的连通性、白名单、安全组、地址和端口配置

Spark 失败或变慢

适用于分析DataWorks中Spark任务的失败或性能问题。诊断过程会深入Spark应用内部，定位Driver、Stage或Executor的根因。

• 诊断逻辑

  1. 失败任务：优先定位Driver或Stage的根本性失败原因（如编译错误、资源溢出），而不是分析任务停止、清理等次要日志。

  2. 慢任务：重点分析长尾Task、数据倾斜、Executor丢失等性能问题。

• 诊断示例

  任务已经进入 Spark 引擎，失败发生在 SQL 分析阶段。Driver 明确提示目标表不存在，因此尚未生成 Job 或 Stage。建议检查表名、项目空间和访问权限后重新运行。

  或：

  未发现 Driver 失败，但某个 Stage 中少量 Task 耗时明显高于其他 Task，存在长尾特征。建议检查数据分布、分区规模和并行度配置。

• 典型场景及分析

  结论	含义	处理方式
  Driver 明确失败	失败发生在 SQL 分析阶段，尚未生成 Job 或 Stage	按 Driver 报错检查表名、项目空间和访问权限
  Stage 存在 Task 长尾	未发现 Driver 失败，但某个 Stage 中少量 Task 耗时明显高于其他 Task	检查数据分布、分区规模和并行度配置

数据质量（DQC）校验异常

适用于分析DataWorks数据质量（DQC）监控规则的执行结果。

• 诊断逻辑

  诊断的首要目标是区分 “规则执行失败” 与 “规则校验未通过”。

  1. 首先，判断规则是否成功执行。

     • 检查是否存在分区不存在、数据源无法访问、SQL无法生成等 执行失败 问题。若存在，诊断到此为止，结论为执行失败。

  2. 其次，若规则成功执行，则判断校验结果。

     • 分析规则是否 未通过，即数据出现了重复、空值、波动等不符合预期的现象。

  系统会优先输出已确认的事实。仅当证据不足或用户明确要求时，才会进一步分析“为什么”数据不符合规则（如追溯上下游、代码变更等）。

• 典型场景及分析

  情况	含义	处理方式
  规则正常执行但未通过	确认存在重复、空值或波动等异常现象	按规则指向的字段与分区核查数据
  校验执行失败	分区不存在、数据源不可解析或查询 SQL 无法生成，不能解释为数据不符合规则	先排除执行障碍（如确认上游已产出分区），再重新运行校验

MaxCompute 失败或变慢

适用于分析MaxCompute（ODPS）任务的失败或性能问题。诊断过程结合了DataWorks调度层信息与MaxCompute引擎层LogView详情。

• 诊断逻辑

  1. 调度层分析：首先分析实例状态与运行日志，获取初步结论，如SQL错误、权限问题、变量替换失败等。

  2. 引擎层分析 (LogView)：然后，通过匹配的LogView深入引擎层，补充失败阶段、执行时间线、任务分布等证据，用于验证或深化调度层结论。

  原则：调度层已明确的结论（如权限、分区错误）优先级更高。LogView详情用于补充和验证，不会覆盖已有结论。

• 诊断示例

  调度日志已经确认分区值非法，错误码为 ODPS-0130071，变量 ${bizdate}` 未替换为合法分区值。引擎信息进一步确认作业在完整计算阶段前失败。建议检查调度参数赋值和分区表达式后重新运行。

• 典型场景及分析

  结论	含义	处理方式
  调度侧已确认的错误	SQL、变量替换、权限、表或分区错误，引擎侧证据仅用于补充失败阶段	按报错修正配置或代码后重新运行
  数据倾斜、长尾、资源等待或热点算子	LogView 中存在明确的执行时间和任务分布证据	依据 LogView 的执行时间线与任务分布定位具体阶段
  运行正常，无性能问题	各项性能指标均无异常特征	无需优化

• 关键原则与能力边界

  • 无有效LogView：若无法获取匹配的LogView，报告将仅返回调度层结论，并说明分析的局限性。

  • 多个Job：单次诊断聚焦于日志中最后一个作业。若存在更早的作业，报告会提示未分析的数量。

  • 数据质量优先：若实例失败的直接原因是数据质量（DQC）校验不通过，诊断将优先展示DQC结论，避免信息冲突。

  • 权限限制：LogView的访问受限于执行诊断的账号权限及作业自身的访问策略。

多实例同时异常

适用于分析同一业务流程或时间窗口内出现的多个相关异常实例。

• 诊断目标

  快速分析一批实例，将相似问题归类，并识别出需要优先处理的根因实例。诊断报告将汇总以下信息：

  • 影响范围：受影响的实例状态与数量。

  • 根因实例：建议优先处理的上游根因节点。

  • 问题分组：按相似现象对实例进行分组。

• 诊断示例

  某工作流中的 3 个下游实例同时未运行。批量诊断还原出连续依赖链：查询节点被汇总节点阻塞，汇总节点又被上游加工节点阻塞，最终收敛到最上游待处理实例。

  本批次 3 个实例均未开始运行，共同现象是上游依赖链尚未完成。建议优先处理依赖链最上游的异常实例，无需分别重跑每个下游节点。

• 处理建议

  1. 优先使用批量诊断：当同一业务流程或时间窗口出现多个相关失败时，应首先使用批量诊断。

  2. 先处理共性根因：优先处理报告中识别出的根因实例，然后观察下游是否自动恢复。

  3. 区分现象与根因：被归入同一组仅表示 现象相似，不保证其 根因完全相同。

  4. 结合单实例深诊：对于关键实例，或在处理完共性问题后仍未解决的个例，应再进行单实例诊断以获取完整的运行证据。