简介： MaxCompute致力于批量结构化数据的存储和计算，提供海量数据仓库的解决方案及剖析建模服务，在MaxCompute执行sql工作的时候有时候作业会很慢，本文通过查看logview排查具体任务慢的起因

在这里把工作跑的慢的问题划分为以下几类

  1. 资源有余导致的排队(个别是包年包月我的项目)
  2. 数据歪斜，数据收缩
  3. 用户本身逻辑导致的运行效率低下

一、资源有余

个别的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逻辑尽量应用内置函数

原文链接

本文为阿里云原创内容，未经容许不得转载。