簡(jiǎn)介： MaxCompute致力于批量結(jié)構(gòu)化數(shù)據(jù)的存儲(chǔ)和計(jì)算，提供海量數(shù)據(jù)倉(cāng)庫(kù)的解決方案及分析建模服務(wù)，在MaxCompute執(zhí)行sql任務(wù)的時(shí)候有時(shí)候作業(yè)會(huì)很慢，本文通過(guò)查看logview排查具體任務(wù)慢的原因

在這里把任務(wù)跑的慢的問(wèn)題劃分為以下幾類

資源不足導(dǎo)致的排隊(duì)(一般是包年包月項(xiàng)目)

數(shù)據(jù)傾斜，數(shù)據(jù)膨脹

用戶自身邏輯導(dǎo)致的運(yùn)行效率低下

一、資源不足

一般的SQL任務(wù)會(huì)占用CPU、Memory這兩個(gè)維度的資源，logview如何查看參考鏈接

1.1 查看作業(yè)耗時(shí)和執(zhí)行的階段

1.2 提交任務(wù)的等待

如果提交任務(wù)以后一直顯示“Job Queueing...”則有可能是由于其他人的任務(wù)占用了資源組的資源，使得自己的任務(wù)在排隊(duì)。

在SubStatusHistory中看Waiting for scheduling就是等待的時(shí)間

1.3 任務(wù)提交后的資源不足

這里還有另一種情況，雖然任務(wù)可以提交成功，但是由于所需的資源較大，當(dāng)前的資源組不能同時(shí)啟動(dòng)所有的實(shí)例，導(dǎo)致出現(xiàn)了任務(wù)雖然有進(jìn)度，但是執(zhí)行并不快的情況。這種可以通過(guò)logview中的latency chart功能觀察到。latency chart可以在detail中點(diǎn)擊相應(yīng)的task看到

上圖顯示的是一個(gè)資源充足的任務(wù)運(yùn)行狀態(tài)，可以看到藍(lán)色部分的下端都是平齊的，表示幾乎在同一時(shí)間啟動(dòng)了所有的實(shí)例。

而這個(gè)圖形的下端呈現(xiàn)階梯向上的形態(tài)，表示任務(wù)的實(shí)例是一點(diǎn)一點(diǎn)的調(diào)度起來(lái)的，運(yùn)行任務(wù)時(shí)資源并不充足。如果任務(wù)的重要性較高，可以考慮增加資源，或者調(diào)高任務(wù)的優(yōu)先級(jí)。

1.4資源不足的原因

1.通過(guò)cu管家查看cu是否占滿，點(diǎn)到對(duì)應(yīng)的任務(wù)點(diǎn)，找到對(duì)應(yīng)時(shí)間看作業(yè)提交的情況

?按cpu占比進(jìn)行排序

（1）某個(gè)任務(wù)占用cu特別大，找到大任務(wù)看logview是什么原因造成（小文件過(guò)多、數(shù)據(jù)量確實(shí)需要這么多資源）。

（2）cu占比均勻說(shuō)明是同時(shí)提交多個(gè)大任務(wù)把cu資源直接打滿。

?

2.由于小文件過(guò)多導(dǎo)致cu占慢

map階段的并行度是根據(jù)輸入文件的分片大小，從而間接控制每個(gè)Map階段下Worker的數(shù)量。默認(rèn)是256m。如果是小文件會(huì)當(dāng)作一個(gè)塊讀取如下圖map階段m1每個(gè)task的i/o bytes都只有1m或者幾十kb,所以造成2500多個(gè)并行度瞬間把資源打滿，說(shuō)明該表下文件過(guò)多需要合并小文件

合并小文件https://help.aliyun.com/knowledge_detail/150531.html?spm=a2c4g.11186623.6.1198.60ea4560Hr5H8d#section-5nj-hoa-d7f

3.數(shù)據(jù)量大導(dǎo)致資源占滿

可以增加購(gòu)買(mǎi)資源，如果是臨時(shí)作業(yè)可以加set odps.task.quota.preference.tag=payasyougo;參數(shù)，可以讓指定作業(yè)臨時(shí)跑到按量付費(fèi)大資源池，

1.5任務(wù)并行度如何調(diào)節(jié)

MaxCompute的并行度會(huì)根據(jù)輸入的數(shù)據(jù)和任務(wù)復(fù)雜度自動(dòng)推測(cè)執(zhí)行，一般不需要調(diào)節(jié)，理想情況并行度越大速度處理越快但是對(duì)于包年包月資源組可能會(huì)把資源組占滿，導(dǎo)致任務(wù)都在等待資源這種情況會(huì)導(dǎo)致任務(wù)變慢

map階段并行度

odps.stage.mapper.split.size ：修改每個(gè)Map Worker的輸入數(shù)據(jù)量，即輸入文件的分片大小，從而間接控制每個(gè)Map階段下Worker的數(shù)量。單位MB，默認(rèn)值為256 MB

reduce的并行度

odps.stage.reducer.num ：修改每個(gè)Reduce階段的Worker數(shù)量

odps.stage.num：修改MaxCompute指定任務(wù)下所有Worker的并發(fā)數(shù)，優(yōu)先級(jí)低于odps.stage.mapper.split.size、odps.stage.reducer.mem和odps.stage.joiner.num屬性。

odps.stage.joiner.num：修改每個(gè)Join階段的Worker數(shù)量。

二、數(shù)據(jù)傾斜

數(shù)據(jù)傾斜

【特征】task 中大多數(shù) instance 都已經(jīng)結(jié)束了，但是有某幾個(gè) instance 卻遲遲不結(jié)束（長(zhǎng)尾）。如下圖中大多數(shù)（358個(gè)）instance 都結(jié)束了，但是還有 18 個(gè)的狀態(tài)是 Running，這些 instance 運(yùn)行的慢，可能是因?yàn)樘幚淼臄?shù)據(jù)多，也可能是這些instance 處理特定數(shù)據(jù)慢。

?解決方法：https://help.aliyun.com/document_detail/102614.html?spm=a2c4g.11186623.6.1160.28c978569uyE9f

三、邏輯問(wèn)題

這里指用戶的SQL或者UDF邏輯低效，或者沒(méi)有使用最優(yōu)的參數(shù)設(shè)定。表現(xiàn)出來(lái)的現(xiàn)象時(shí)一個(gè)Task的運(yùn)行時(shí)間很長(zhǎng)，而且每個(gè)實(shí)例的運(yùn)行時(shí)間也比較均勻。這里的情況更加多種多樣，有些是確實(shí)邏輯復(fù)雜，有些則有較大的優(yōu)化空間。

數(shù)據(jù)膨脹

【特征】task 的輸出數(shù)據(jù)量比輸入數(shù)據(jù)量大很多。

比如 1G 的數(shù)據(jù)經(jīng)過(guò)處理，變成了 1T，在一個(gè) instance 下處理 1T 的數(shù)據(jù)，運(yùn)行效率肯定會(huì)大大降低。輸入輸出數(shù)據(jù)量體現(xiàn)在 Task 的 I/O Record 和 I/O Bytes 這兩項(xiàng)：

?解決方法：確認(rèn)業(yè)務(wù)邏輯確實(shí)需要這樣，增大對(duì)應(yīng)階段并行度

UDF執(zhí)行效率低

【特征】某個(gè) task 執(zhí)行效率低，且該 task 中有用戶自定義的擴(kuò)展。甚至是 UDF 的執(zhí)行超時(shí)報(bào)錯(cuò)：“Fuxi job failed - WorkerRestart errCode:252,errMsg:kInstanceMonitorTimeout, usually caused by bad udf performance”。

首先確定udf位置，點(diǎn)看慢的fuxi task， 可以看到operator graph 中是否包含udf，例如下圖說(shuō)明有java 的udf。

?

?通過(guò)查看logview 中fuxi instance 的stdout 可以查看該operator 運(yùn)行速度，正常情況 Speed(records/s) 在百萬(wàn)或者十萬(wàn)級(jí)別。

?解決方法：檢查udf邏輯盡量使用內(nèi)置函數(shù)

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的MaxCompute中如何通过logview诊断慢作业的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。