作业诊断功能可以基于作业在MaxCompute产品中运行时产生的各个阶段状态信息,与作业历史运行数据进行对比分析,得出作业相比历史在某些环节或诊断维度上的缺陷和问题,并针对问题给出相应的原因和解决方案,以此提升作业运行效率,实现运维自服务能力。
功能入口
您可以按照如下步骤进入作业诊断页面:
- 登录MaxCompute控制台MaxCompute控制台,在左上角选择区域。
- 单击管家页签,即可进入MaxCompute管家页面。
- 在左侧导航栏,单击诊断,即可进入作业诊断页面。
- 在作业诊断页面上方的搜索框中输入InstanceID,单击诊断,即可查看诊断结果。
获取InstanceID信息,请参见查看实例信息。
功能介绍
- 基础信息
包含当前诊断工具的状态、诊断时间及作业的基础信息。
- 作业历史耗时分析
包含当前诊断的Instance在历史3天内运行的Instance列表信息。
- 控制集群历史耗时分析
控制集群位于MaxCompute产品架构的管控层,该阶段主要完成作业的编译和优化,之后才会将作业提交至计算集群完成数据计算和存储。您可以查看作业在控制集群阶段的耗时原因,并根据耗时原因优化作业。
- 计算集群历史耗时分析
计算集群实现业务逻辑的计算和存储。您可以查看作业在计算集群阶段的耗时原因,并根据耗时原因优化作业。
使用限制
作业诊断功能只支持诊断阿里云账号下7天以内的SQL、MapReduce类型的作业。
基础信息

序号 | 类型 | 说明 |
---|---|---|
① | 诊断工具的状态 | 您可以基于诊断工具的状态信息,判断是否需要执行优化作业操作。诊断状态包含如下三种:
|
② | 诊断时间 | 包含诊断开始时间和结束时间,并非作业运行的开始时间和结束时间。因为诊断工具要获取诊断的Instance在历史3天内的作业运行信息,所以诊断会耗时,请耐心等待。 |
③ | 作业基础信息 | 作业基础信息包含如下内容:
|
作业历史耗时分析

以表格形式展示当前诊断的Instance在历史3天内运行的Instance列表。您可以在Instance列单击打开对应Instance的Logview。如果未检测到诊断的Instance有历史运行记录,则表格数据为空。
控制集群历史耗时分析

控制集群历史耗时分析主要有四个诊断项维度,您需要关注控制集群历史耗时分析下的汇总表格,根据耗时占比来判断该阶段的耗时主因。
检查项 | 说明 |
---|---|
检查executor资源 | 该诊断项主要检查作业编译是否异常,对应Logview中SubStatusHistory的1020 Waiting for execution 阶段。
executor是控制集群中负责作业编译和调度的角色,如果executor资源紧张或异常,会导致作业编译慢或延迟。如果该诊断项异常,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
检查生成物理执行计划 | 该诊断项主要检查作业的物理执行计划生成时间,对应Logview中SubStatusHistory的1235 SQLTask is splitting data sources 和1240 SQLTask is generating execution plan 阶段。
如果作业扫描的分区数量过多,或读取小文件过多,都会导致生成物理执行时间变长。如果该诊断项异常,处理方式请参见生成执行计划耗时优化。 |
检查集群并发 | 该诊断项主要检查计算集群当前运行作业数是否超过上限,对应Logview中SubStatusHistory的1011 Waiting for cluster resource 阶段。
如果作业数超过上限,控制集群会等待计算集群的作业处理完成后提交作业。如果该诊断项异常,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
检查资源等待 | 该诊断项会根据包年包月或按量计费模式检查当前用户的资源组中资源的消耗情况,对应Logview中SubStatusHistory的1250 SQLTask is submitting execution plan 和1041 Offline Job Waiting for running 阶段。
该诊断项异常时,如果您为包年包月用户,系统会根据历史资源使用情况提供扩容或错峰调度建议;如果您为按量计费用户,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
计算集群历史耗时分析

计算集群历史耗时分析主要有九个诊断项维度,您需要关注计算集群历史耗时分析下的汇总表格,根据耗时占比来判断该阶段的耗时主因。
检查项 | 说明 |
---|---|
检查作业重跑 | 作业运行过程中可能因为各种原因失败,MaxCompute可以做到在不干预业务的情况下,自动重新运行失败作业。重新运行作业会造成相应的作业延迟,故该诊断项主要从作业重新执行维度对比分析重新执行造成的时间延迟情况。 |
检查Online Job回退 | MaxCompute支持以在线模式运行简单作业,可以达到秒级或分钟级运行效率。但在线模式有条件限制,例如运行时间不超10分钟;运行的Worker数量不超过2000。如果不满足条件会导致在线模式回退为离线模式,即Online Job回退为Offline Job。回退会造成相应的作业延迟,故该诊断项主要从Online Job回退维度对比分析回退造成的时间延迟情况。 |
检查作业PVC | 作业计算运行时由DAG顺序图控制,当下游Reduce读取上游Map产生数据异常时,会触发上游Map重新执行,生成新数据,该现象为PVC。PVC会造成作业运行延迟,故该诊断项主要从作业PVC维度对比分析PVC造成的时间延迟情况。
如果该诊断项异常,诊断项下会展示各个Task阶段的PVC信息,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
检查Worker资源等待 | 该诊断项为计算集群Worker运行时资源等待检查。当资源组的资源已全部被占用,且存在优先级争抢时,会导致低优先级Worker排队等待。
如果该诊断项异常,且单Worker等待时间超过5分钟,该诊断项下会展示各个Task阶段的Worker资源等待信息,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
检查Worker失败 | Worker运行过程中也会因为各种原因失败,例如申请和使用内存不合理,导致内存溢出,Worker运行失败。Worker运行有Failover机制,Worker运行失败会自动重新执行。Worker重新执行会带来相应的作业延迟,故该诊断项主要从Worker运行失败维度对比分析失败造成的时间延迟情况。
如果该诊断项异常,且为内存溢出,您需要设置合理的内存申请值。例如JOIN阶段的OOM可通过 |
检查数据倾斜 | 作业在计算处理过程中通常会因为源表数据的分布不均匀问题,或者JOIN笛卡尔积产生的数据倾斜,导致部分Worker处理的数据量是同阶段其他Worker的几十甚至几百倍,从而该Worker的运行时间相较其他Worker会有延迟。故该诊断项主要从数据倾斜维度对比分析倾斜造成的时间延迟情况。
如果该诊断项异常,该诊断项下会展示各个Task阶段数据倾斜的信息,处理方式请参见数据倾斜优化。 |
检查Worker长尾 | 除了数据倾斜造成Worker运行时间变长外,仍有其他原因会导致同阶段Worker的耗时不一致,出现个别Worker有长尾现象(相较其他Worker运行时间过长)。故该诊断项主要从Worker长尾维度对比分析长尾造成的时间延迟情况。
如果该诊断项异常,该诊断项下会展示各个Task阶段的Worker长尾信息,您需要提工单提工单联系MaxCompute技术支持做进一步判断和处理。 |
检查作业输入 | 作业处理的源表数据发生变化,会使作业输入的数据量不同,从而造成作业运行时间的延迟。故该诊断项主要从作业输入数据量维度对比分析输入数据变化带来的时间延迟情况。
如果该诊断项异常,可能是源表数据量有增长,您需要联系源表所有人确认数据是否正常。 |
检查数据膨胀 | 业务处理逻辑问题会导致输出数据量远超输入数据量,从而导致写数据耗时增加,下游读取上游输出数据耗时增加,从而造成作业运行时间延迟。
如果该诊断项异常,该诊断项下会展示各个Task阶段的输入和输出数据量信息,处理方式请参见数据膨胀优化。 |
在文档使用中是否遇到以下问题
更多建议
匿名提交