简介：MaxCompute 致力于批量结构化数据的存储和计算，提供海量数据仓库的解决方案及剖析建模服务，在 MaxCompute 执行 sql 工作的时候有时候作业会很慢，本文通过查看 logview 排查具体任务慢的起因
在这里把工作跑的慢的问题划分为以下几类
- 资源有余导致的排队 (个别是包年包月我的项目)
- 数据歪斜，数据收缩
- 用户本身逻辑导致的运行效率低下
一、资源有余
个别的 SQL 工作会占用 CPU、Memory 这两个维度的资源，logview 如何查看参考链接
1.1 查看作业耗时和执行的阶段
1.2 提交工作的期待
如果提交工作当前始终显示“Job Queueing…”则有可能是因为其他人的工作占用了资源组的资源，使得本人的工作在排队。
在 SubStatusHistory 中看 Waiting for scheduling 就是期待的工夫。
1.3 工作提交后的资源有余
这里还有另一种状况，尽管工作能够提交胜利，然而因为所需的资源较大，以后的资源组不能同时启动所有的实例，导致呈现了工作尽管有进度，然而执行并不快的状况。这种能够通过 logview 中的 latency chart 性能察看到。latency chart 能够在 detail 中点击相应的 task 看到。
上图显示的是一个资源短缺的工作运行状态，能够看到蓝色局部的下端都是平齐的，示意简直在同一时间启动了所有的实例。
而这个图形的下端出现阶梯向上的状态，示意工作的实例是一点一点的调度起来的，运行工作时资源并不短缺。如果工作的重要性较高，能够思考减少资源，或者调高工作的优先级。
1.4 资源有余的起因
1. 通过 cu 管家查看 cu 是否占满，点到对应的工作点，找到对应工夫看作业提交的状况
按 cpu 占比进行排序
（1）某个工作占用 cu 特地大，找到大工作看 logview 是什么起因造成（小文件过多、数据量的确须要这么多资源）。
（2）cu 占比平均阐明是同时提交多个大工作把 cu 资源间接打满。
2. 因为小文件过多导致 cu 占慢
map 阶段的并行度是依据输出文件的分片大小，从而间接管制每个 Map 阶段下 Worker 的数量。默认是 256m。如果是小文件会当作一个块读取如下图 map 阶段 m1 每个 task 的 i /o bytes 都只有 1m 或者几十 kb, 所以造成 2500 多个并行度霎时把资源打满，阐明该表下文件过多须要合并小文件。
合并小文件 https://help.aliyun.com/knowl…
3. 数据量大导致资源占满
能够减少购买资源，如果是长期作业能够加 setodps.task.quota.preference.tag=payasyougo; 参数，能够让指定作业长期跑到按量付费大资源池。
1.5 工作并行度如何调节
MaxCompute 的并行度会依据输出的数据和工作复杂度主动揣测执行，个别不须要调节，现实状况并行度越大速度解决越快然而对于包年包月资源组可能会把资源组占满，导致工作都在期待资源这种状况会导致工作变慢
map 阶段并行度
odps.stage.mapper.split.size：批改每个 Map Worker 的输出数据量，即输出文件的分片大小，从而间接管制每个 Map 阶段下 Worker 的数量。单位 MB，默认值为 256 MB
reduce 的并行度
odps.stage.reducer.num：批改每个 Reduce 阶段的 Worker 数量
odps.stage.num：批改 MaxCompute 指定工作下所有 Worker 的并发数，优先级低于 odps.stage.mapper.split.size、odps.stage.reducer.mem 和 odps.stage.joiner.num 属性。
odps.stage.joiner.num：批改每个 Join 阶段的 Worker 数量。
二、数据歪斜
数据歪斜
【特色】task 中大多数 instance 都曾经完结了，然而有某几个 instance 却迟迟不完结（长尾）。如下图中大多数（358 个）instance 都完结了，然而还有 18 个的状态是 Running，这些 instance 运行的慢，可能是因为解决的数据多，也可能是这些 instance 解决特定数据慢。
解决办法：https://help.aliyun.com/docum…
三、逻辑问题
这里指用户的 SQL 或者 UDF 逻辑低效，或者没有应用最优的参数设定。体现进去的景象时一个 Task 的运行工夫很长，而且每个实例的运行工夫也比拟平均。这里的状况更加多种多样，有些是的确逻辑简单，有些则有较大的优化空间。
数据收缩
【特色】task 的输入数据量比输出数据量大很多。
比方 1G 的数据通过解决，变成了 1T，在一个 instance 下解决 1T 的数据，运行效率必定会大大降低。输入输出数据量体现在 Task 的 I/O Record 和 I/O Bytes 这两项：
解决办法：确认业务逻辑的确须要这样，增大对应阶段并行度
UDF 执行效率低
【特色】某个 task 执行效率低，且该 task 中有用户自定义的扩大。甚至是 UDF 的执行超时报错：“Fuxi job failed – WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout, usually caused by bad udf performance”。
首先确定 udf 地位，点看慢的 fuxi task，能够看到 operator graph 中是否蕴含 udf，例如下图阐明有 java 的 udf。
通过查看 logview 中 fuxi instance 的 stdout 能够查看该 operator 运行速度，失常状况 Speed(records/s) 在百万或者十万级别。
解决办法：查看 udf 逻辑尽量应用内置函数
原文链接
本文为阿里云原创内容，未经容许不得转载。