Logview是MaxCompute Job提交后查看和Debug任務(wù)的工具。通過(guò)Logview可看到一個(gè)Job的運(yùn)行狀態(tài)、運(yùn)行結(jié)果以及運(yùn)行細(xì)節(jié)和每個(gè)步驟的進(jìn)度。當(dāng)Job提交到MaxCompute后，會(huì)生成Logview的鏈接，用戶可以直接在瀏覽器上打開(kāi)Logview鏈接，進(jìn)入查看Job的信息，而對(duì)于Logview上的諸多參數(shù)信息，究竟應(yīng)該怎么“撥開(kāi)云霧”，發(fā)現(xiàn)問(wèn)題所在呢？又如何通過(guò)Logview了解每個(gè)instance、task運(yùn)行狀態(tài)及資源占用情況，如何分析執(zhí)行計(jì)劃，分析query存在問(wèn)題，找到Long-Tails task，讓數(shù)據(jù)分析業(yè)務(wù)高效又省錢呢？本文中，阿里巴巴計(jì)算平臺(tái)產(chǎn)品專家云花將為大家揭曉答案。

直播視頻回看，戳這里！https://yq.aliyun.com/webinar/play/484
分享資料下載，戳這里！https://yq.aliyun.com/download/2953

更多精彩內(nèi)容傳送門：大數(shù)據(jù)計(jì)算技術(shù)共享計(jì)劃 — MaxCompute技術(shù)公開(kāi)課第二季?

?

以下內(nèi)容根據(jù)演講視頻及PPT整理而成。

本文將主要圍繞以下4個(gè)方面進(jìn)行分享：

什么是Logview

相關(guān)概念和原理

Logview參數(shù)詳解

使用Logview排查問(wèn)題

很多用戶在使用MaxCompute的時(shí)候會(huì)遇到一些問(wèn)題，但是卻苦于不知道如何去定位這些問(wèn)題，也不知道應(yīng)該如何進(jìn)行優(yōu)化。因此，本文整理了一些Logview參數(shù)以及問(wèn)題定位的相關(guān)知識(shí)與大家分享。

一、什么是Logview？
Logview是一個(gè)在MaxCompute上提交任務(wù)之后用來(lái)查看和Debug任務(wù)的工具，大家可以通過(guò)Logview看到任務(wù)的運(yùn)行狀態(tài)，包括任務(wù)的排隊(duì)情況以及資源的使用情況，甚至在每個(gè)節(jié)點(diǎn)上Instance運(yùn)行的細(xì)節(jié)及其進(jìn)度。當(dāng)提交的任務(wù)出錯(cuò)了或者運(yùn)行時(shí)間過(guò)長(zhǎng)，就可以借助Logview分析具體的原因，進(jìn)而對(duì)任務(wù)進(jìn)行精準(zhǔn)優(yōu)化。

二、相關(guān)概念和原理
在使用Logview的時(shí)候可能會(huì)遇到很多名詞，這些名詞都是MaxCompute特有的，因此在本部分中也進(jìn)行簡(jiǎn)單介紹，幫助大家更好地理解Logview的運(yùn)行原理。

MaxCompute系統(tǒng)架構(gòu)
如下圖所示的是MaxCompute的系統(tǒng)架構(gòu)。從上往下看，首先最上層就是數(shù)據(jù)源和客戶端接入的部分，各種外部數(shù)據(jù)源都可以通過(guò)外部傳輸?shù)墓ぞ呷鏣unnel以及DataHub將數(shù)據(jù)同步到分布式文件存儲(chǔ)系統(tǒng)盤古中。在客戶端，用戶可以使用命令行工具、MaxCompute Studio以及DataWorks等開(kāi)發(fā)完任務(wù)提交之后，以Restful API形式提交到HTTP服務(wù)，當(dāng)HTTP服務(wù)接收到請(qǐng)求之后，先向用戶中心做身份鑒權(quán)，因此整個(gè)接入層其實(shí)承載了數(shù)據(jù)上傳下載、用戶鑒權(quán)以及負(fù)載均衡等工作。接入層之下就是管理層，這也是MaxCompute最為核心的部分，這部分負(fù)責(zé)對(duì)用戶空間和對(duì)象的管理、命令的解析與執(zhí)行、對(duì)象的訪問(wèn)控制以及授權(quán)等功能，其主要有三種角色，即Workers、Scheduler以及Executor。MaxCompute的元數(shù)據(jù)其實(shí)是存儲(chǔ)在阿里云開(kāi)放服務(wù)——分布式元數(shù)據(jù)服務(wù)上。

MaxCompute的計(jì)算集群就是架構(gòu)在飛天系統(tǒng)之上的，而飛天系統(tǒng)的核心模塊包括了分布式文件存儲(chǔ)系統(tǒng)盤古、分布式資源調(diào)度系統(tǒng)伏羲、分布式協(xié)同服務(wù)女媧以及分布式監(jiān)控系統(tǒng)神農(nóng)、遠(yuǎn)程過(guò)程調(diào)用系統(tǒng)夸父、以及安全管理系統(tǒng)鐘馗等。以上就是MaxCompute的基礎(chǔ)架構(gòu)，其最核心和復(fù)雜的邏輯就在管理層與伏羲之間的任務(wù)調(diào)度和管理。

MaxCompute元數(shù)據(jù)模型
其實(shí)MaxCompute以前還有個(gè)名字叫做ODPS，從2016年開(kāi)始ODPS正式改名為MaxCompute，所以其實(shí)在Logview中出現(xiàn)的ODPS字樣其實(shí)就是指MaxCompute。MaxCompute最常見(jiàn)的兩種對(duì)象就是Job，也就是Instance，另外一個(gè)就是ODPS Task。比如當(dāng)提交一個(gè)SQL Query的請(qǐng)求，系統(tǒng)就會(huì)創(chuàng)建一個(gè)Instance，而當(dāng)這個(gè)Instance在MaxCompute上執(zhí)行的時(shí)候就會(huì)被分解成多個(gè)Task，但是多數(shù)情況下Instance與Task是一一對(duì)應(yīng)的。這個(gè)Task有SQL類型的、有MR類型的，還有機(jī)器學(xué)習(xí)的。而在底層的分布式系統(tǒng)Fuxi上面也有Job和Task和Instance的概念，而這些需要和MaxCompute上的Task以及Instance的概念區(qū)分清楚。當(dāng)ODPS Task提交到服務(wù)器上之后，每個(gè)Task會(huì)被分解成為多個(gè)Fuxi Job，而每個(gè)Fuxi Job會(huì)根據(jù)執(zhí)行計(jì)劃分解成不同的執(zhí)行階段，比如Map、Reduce以及Join等。而每個(gè)Task又會(huì)啟動(dòng)多個(gè)Instance來(lái)執(zhí)行，相當(dāng)于啟動(dòng)多個(gè)節(jié)點(diǎn)。

MaxCompute作業(yè)處理流程
首先，用戶會(huì)在客戶端提交一個(gè)SQL語(yǔ)句，客戶端會(huì)通過(guò)Restful API形式提交到HTTP服務(wù)，HTTP服務(wù)的前端接收到這個(gè)請(qǐng)求之后會(huì)先去用戶中心做鑒權(quán)，通過(guò)鑒權(quán)之后會(huì)根據(jù)所在集群信息轉(zhuǎn)交給MaxCompute相應(yīng)的Worker去執(zhí)行。Worker則會(huì)解析這個(gè)請(qǐng)求，首先做API的鑒權(quán)，有了權(quán)限之后才會(huì)響應(yīng)請(qǐng)求。Worker會(huì)判斷作業(yè)類型，一種是同步任務(wù)，也就是說(shuō)當(dāng)Worker自己執(zhí)行完就可以返回，比如SQL DDL以及Job的查詢狀態(tài)等，Worker會(huì)訪問(wèn)OTS獲取元數(shù)據(jù)信息，然后交給Executor執(zhí)行，執(zhí)行完成之后就直接返回給客戶端。另外一種是異步任務(wù)，所謂異步任務(wù)就是對(duì)后續(xù)節(jié)點(diǎn)進(jìn)行處理，需要提交到Fuxi去處理的任務(wù)，比如SQL的DML或者M(jìn)R這類的任務(wù)請(qǐng)求。Worker會(huì)創(chuàng)建一個(gè)Instance然后交給Scheduler去執(zhí)行，Scheduler負(fù)責(zé)對(duì)所有異步任務(wù)的調(diào)度，它會(huì)把Instance分解為Task并做全局的計(jì)算調(diào)度。當(dāng)所有資源以及條件都滿足Scheduler就會(huì)將Task交給Executor進(jìn)行執(zhí)行，Executor上其實(shí)封裝了各種業(yè)務(wù)邏輯，比如SQL以及算法模塊，Executor會(huì)根據(jù)不同的作業(yè)類型拉取不同的作業(yè)模塊。當(dāng)Executor空閑的時(shí)候會(huì)向Scheduler進(jìn)行心跳上報(bào)并請(qǐng)求任務(wù)，當(dāng)其拿到任務(wù)之后會(huì)根據(jù)任務(wù)類型啟動(dòng)一個(gè)相應(yīng)的業(yè)務(wù)模塊來(lái)執(zhí)行。Executor會(huì)生成一個(gè)任務(wù)的執(zhí)行計(jì)劃，并將任務(wù)以及執(zhí)行計(jì)劃一起交給Fuxi進(jìn)行執(zhí)行。有時(shí)候提交到Fuxi的任務(wù)會(huì)出現(xiàn)回退的情況，比如第一次是按照Online Job的作業(yè)類型來(lái)提交的，到Fuxi之后可能會(huì)提交失敗并回退到Scheduler，然后按照Offline的方式再提交一次，這樣就會(huì)在Logview看到對(duì)應(yīng)的情況。當(dāng)Executor將Task提交給Fuxi之后，還會(huì)去監(jiān)控Task的執(zhí)行狀態(tài)，當(dāng)執(zhí)行完成之后則會(huì)更新OTS里面的Task信息并匯報(bào)給Scheduler，Scheduler則會(huì)判斷整個(gè)Instance是否執(zhí)行完畢，如果執(zhí)行完畢也會(huì)去更新OTS中的Instance信息，將其設(shè)置為Terminated，以上這些就是完整的作業(yè)處理流程。

三、Logview參數(shù)詳解
分享完基本概念和理論之后就可以介紹Logview的參數(shù)了。主要的信息包括ODPS Instance，其涵蓋了隊(duì)列信息以及子狀態(tài)信息，另外一部分包括Fuxi Job，這可以進(jìn)一步拆解成Task信息和Fuxi Instance信息。在整個(gè)任務(wù)結(jié)束之后可以看到其Summary以及Diagnosis診斷信息，此外還有上傳下載的小功能。

ODPS Instance信息
下圖中最上面的表中有這樣的幾個(gè)字段：URL、Project、InstanceID、Owner、StartTime、EndTime、Latency、Status以及Process等。URL是Endpoint的地址，Project存放項(xiàng)目的名稱，InstanceID其實(shí)是時(shí)間戳跟著隨機(jī)字符串，這個(gè)時(shí)間戳是精確到毫秒的，而這個(gè)時(shí)間是UTC時(shí)間，與電腦提交任務(wù)的時(shí)間是不一致的。StartTime和EndTime分別是任務(wù)開(kāi)始和結(jié)束的時(shí)間，Latency則是任務(wù)運(yùn)行所消耗的時(shí)間。而對(duì)于Status而言，則有四種狀態(tài)：Waiting狀態(tài)代表任務(wù)正在ODPS中處理，還沒(méi)提交到Fuxi中運(yùn)行；Waiting List代表任務(wù)已經(jīng)到了Fuxi，并且在Fuxi中排隊(duì)，N代表排隊(duì)的位置；Running代表在Fuxi中運(yùn)行；Terminated代表運(yùn)行已經(jīng)結(jié)束了。在表格里面，只要Status不是Terminated的狀態(tài)，只要雙擊就能打開(kāi)Queue Detail和SubStatus History詳細(xì)信息。

Queue Detail&SubStatus History信息
如下圖所示最上面的Table是關(guān)于隊(duì)列的信息，首先是Fuxi Job的name，SubStatus則是目前Job的運(yùn)行狀態(tài)，Progress是目前的執(zhí)行進(jìn)度。紅框里面有兩個(gè)字段，分別是WaitPOS和QueueLength，前者是目前排隊(duì)的位置，后者是隊(duì)列長(zhǎng)度，根據(jù)這兩個(gè)字段就能看到整個(gè)隊(duì)列里面有多少任務(wù)在排隊(duì)，這個(gè)任務(wù)排在第幾位。Total Priority是其優(yōu)先級(jí)，點(diǎn)擊SubStatus History的圖標(biāo)可以打開(kāi)下圖中下側(cè)的Table。對(duì)于SubStatus History而言著重介紹一下SubStatus Code以及其含義，在下圖中列出了一些常見(jiàn)的SubStatus Code以及其對(duì)應(yīng)含義。

Fuxi Job的兩種作業(yè)類型
前面也提到了Fuxi Job有兩種作業(yè)類型，分別是Online Job和Offline Job，這兩種Job到底有什么區(qū)別呢？首先，對(duì)于Offline的作業(yè)而言，當(dāng)每次提交作業(yè)時(shí)在Fuxi上都會(huì)有一個(gè)環(huán)境準(zhǔn)備的時(shí)間，對(duì)于大數(shù)據(jù)量并且不需要返回查詢結(jié)果的作業(yè)比較合適。而對(duì)于小數(shù)據(jù)量并且實(shí)時(shí)作業(yè)要求比較高的作業(yè)是不合適的。所以Fuxi提供了Service Mode這種準(zhǔn)實(shí)時(shí)的作業(yè)形式，首先會(huì)有一個(gè)服務(wù)去預(yù)先申請(qǐng)計(jì)算一些資源并加載出來(lái)，比如會(huì)預(yù)先分配一萬(wàn)個(gè)Instance，當(dāng)有作業(yè)提交過(guò)來(lái)的時(shí)候會(huì)根據(jù)作業(yè)規(guī)模分配一些Instance進(jìn)行執(zhí)行，這樣就省去環(huán)境準(zhǔn)備的時(shí)間，所以就會(huì)比較快，這就是兩種類型作業(yè)的主要差異。

對(duì)于FuxiJob的命名規(guī)則而言，如上圖所示“odps/”后面的部分就是：

<project_name>_<instanceId>_<task_type>_<odps_task_index>_<task_history>_<fuxi_job_index>_<jobtail>。

ODPS Task信息
如下圖所示的是ODPS Task信息，上面的表格的第一個(gè)字段是TaskName，Type指的是作業(yè)類型，Status指的是運(yùn)行狀態(tài)，雙擊Rusult會(huì)輸出作業(yè)的整個(gè)結(jié)果集，雙擊Detail信息則會(huì)打開(kāi)整個(gè)Fuxi Job的詳細(xì)Table。

Fuxi Job Detail信息
Fuxi Job詳細(xì)信息主要分為三個(gè)部分，最左側(cè)是任務(wù)的執(zhí)行計(jì)劃，這個(gè)執(zhí)行計(jì)劃是在Executor里面生成的，執(zhí)行計(jì)劃就是將一個(gè)任務(wù)分成不同的Stage來(lái)執(zhí)行，每個(gè)Stage的都可以看做一個(gè)圖上的點(diǎn)，而Stage之間的依賴關(guān)系就可以看做圖的邊，這樣就構(gòu)成一個(gè)有向無(wú)環(huán)圖。在下圖例子中，將Fuxi Job分解成了四個(gè)Map的Task，兩個(gè)Join的Task，還有3個(gè)Reduce的Task。舉例而言，對(duì)于J3_1_2這個(gè)Task而言，需要在M1和M2執(zhí)行完成之后才會(huì)執(zhí)行，也就是說(shuō)M1和M2的輸出就是J3_1_2的輸入，并且在名字上也可以體現(xiàn)其依賴關(guān)系，也就是說(shuō)命名其實(shí)是和執(zhí)行計(jì)劃相關(guān)的。下圖中右上方這部分就是每個(gè)Task的詳細(xì)信息，也是每個(gè)Stage的詳細(xì)信息。圖中下面部分則是每個(gè)Instance的詳細(xì)信息。

Fuxi Task Detail信息
對(duì)于Fuxi Job Detail信息而言，又有哪些需要關(guān)注呢？第一個(gè)字段就是TaskName，其和執(zhí)行計(jì)劃的生成是相關(guān)的。后面的字段Fatal/Finished/TotalInstCount，在表格里面Fatal表示嚴(yán)重錯(cuò)誤個(gè)數(shù)，因此被標(biāo)紅了；Finished表示已經(jīng)結(jié)束的Instance的個(gè)數(shù)，后面的TotalInstCount指的是為每個(gè)Task啟動(dòng)的總Task數(shù)量。下一個(gè)字段I/O Records指的是輸入和輸出的記錄的個(gè)數(shù)，I/O Bytes指的是輸入和輸出的字節(jié)數(shù)。FinishedPercentage指的是進(jìn)度條，Status則指的是每個(gè)Task的運(yùn)行狀態(tài)。

Fuxi Instance Detail信息
Fuxi Instance是整個(gè)作業(yè)流中最小的顆粒，在如下圖所示的Demo中是一個(gè)Map的作業(yè)詳細(xì)信息。首先看All字段，這個(gè)字段后面有一個(gè)數(shù)字415，這說(shuō)明為M3_2這個(gè)Task啟動(dòng)了415個(gè)Instance，其左側(cè)的Terminated、Running、Ready以及Failed分別是相應(yīng)狀態(tài)的實(shí)例個(gè)數(shù)。而SmartFilter則會(huì)給出最早結(jié)束、最晚結(jié)束、運(yùn)行時(shí)間最短和運(yùn)行時(shí)間最長(zhǎng)的四個(gè)Instance，將其篩選處理方便觀察。Latency Chart則是以圖表的形式展示所有的Instance的運(yùn)行時(shí)長(zhǎng)分布，而在Latency里面則是最長(zhǎng)運(yùn)行時(shí)間和最短運(yùn)行時(shí)間以及平均運(yùn)行時(shí)長(zhǎng)，其實(shí)這三個(gè)時(shí)間對(duì)于分析長(zhǎng)尾任務(wù)是非常有用的。在每個(gè)Instance的表格里面詳細(xì)信息里面有一個(gè)StdOut，這是每個(gè)Instance在執(zhí)行過(guò)程中打印的信息，而StuErr則是當(dāng)Instance失敗的時(shí)候可以用來(lái)查看出錯(cuò)原因的。

Fuxi Job Detail信息 之 Summary信息
FuxiJob的Summary是在整個(gè)Job運(yùn)行完之后才能查看的信息，主要包括Job消耗的CPU、內(nèi)存、Job輸入的表名以及記錄數(shù)和字節(jié)數(shù)。此外，Job的運(yùn)行時(shí)間單位是秒。Fuxi Task的Summary信息則主要包括Instance數(shù)量、Task運(yùn)行時(shí)間、所有Instance里面的最大、最小和平均運(yùn)行時(shí)間。

Tips：用Summary信息做計(jì)量計(jì)費(fèi)參考
這里與大家分享一個(gè)Tips，就是如何用Summary信息做計(jì)量計(jì)費(fèi)參考，比如在這里執(zhí)行的是一個(gè)MapReduce作業(yè)，其計(jì)費(fèi)方法是MR任務(wù)當(dāng)日計(jì)算費(fèi)用=當(dāng)日總計(jì)算時(shí)*0.46元(RMB)，則任務(wù)的計(jì)算時(shí)=任務(wù)運(yùn)行時(shí)間(小時(shí))*任務(wù)調(diào)用的核數(shù)量。而在Summary信息里面就能夠直接拿到CPU的計(jì)算時(shí)，而不需要用公式計(jì)算了。而對(duì)于SQL計(jì)算而言，計(jì)算公式為：一次SQL計(jì)算費(fèi)用 = 計(jì)算輸入數(shù)據(jù)量 * SQL復(fù)雜度 * SQL價(jià)格。而輸入數(shù)據(jù)量與SQL復(fù)雜度都能夠通過(guò)cost sql <SQL Sentence>這個(gè)命令來(lái)計(jì)算。對(duì)于計(jì)量計(jì)算而言，更多的內(nèi)容請(qǐng)參考官網(wǎng)上的信息。

Diagnosis信息
Diagnosis是診斷信息，其是在作業(yè)執(zhí)行完成之后可以點(diǎn)擊小紅點(diǎn)進(jìn)而打開(kāi)如下圖所示的表格。Diagnosis主要會(huì)診斷三類信息，分別是對(duì)資源的診斷、對(duì)數(shù)據(jù)傾斜的診斷以及對(duì)重新運(yùn)行的診斷，每類信息會(huì)給出對(duì)于問(wèn)題的說(shuō)明和問(wèn)題嚴(yán)重等級(jí)，并且會(huì)給出改進(jìn)意見(jiàn)。

Logview信息的導(dǎo)入導(dǎo)出
Logview的信息可以導(dǎo)入和導(dǎo)出，因?yàn)槠湫畔⒅荒茉谙到y(tǒng)中保留7天，如果想要長(zhǎng)期保存就需要導(dǎo)出信息。大家可以點(diǎn)擊Logview右上角的小圖標(biāo)將Logview信息保存到本地，當(dāng)需要分析的時(shí)候再點(diǎn)擊“望遠(yuǎn)鏡”小圖標(biāo)，從本地將Logview信息上傳上去就可以還原出Logview的信息。

四、使用Logview排查問(wèn)題
常見(jiàn)的問(wèn)題有這樣幾種，首先就是任務(wù)一直在排隊(duì)等待或者任務(wù)直接運(yùn)行失敗了，而最常見(jiàn)的情況就是任務(wù)執(zhí)行時(shí)間太長(zhǎng)了，一直跑不完。其實(shí)大多數(shù)慢任務(wù)的原因都是因?yàn)殚L(zhǎng)尾，而大多數(shù)長(zhǎng)尾都是因?yàn)閿?shù)據(jù)傾斜帶來(lái)的。這不僅將會(huì)影響數(shù)據(jù)分析結(jié)果的產(chǎn)出，還會(huì)拉高數(shù)據(jù)資源的消費(fèi)，因此對(duì)于這種情況必須要進(jìn)行優(yōu)化。

1. 任務(wù)出錯(cuò)了
對(duì)于出錯(cuò)任務(wù)而言，從控制臺(tái)輸出就可以看到出錯(cuò)的原因，如果想要查看更加詳細(xì)的信息，則可以打開(kāi)Logview去查看ODPS的Result信息，如果失敗了可以看到Status變成紅色了。當(dāng)雙擊Result之后就可以看到報(bào)錯(cuò)輸出的整體信息。在出錯(cuò)信息里面會(huì)有錯(cuò)誤碼，而錯(cuò)誤碼與詳細(xì)錯(cuò)誤的對(duì)照表可以在官網(wǎng)找到。所以查看出錯(cuò)任務(wù)的方式有兩種，一種是在作業(yè)結(jié)束之后查看其Result信息，另外一種方式則是去查看Instance的StdErr信息。

2. 慢任務(wù)診斷
(1) 作業(yè)排隊(duì)
對(duì)于慢任務(wù)診斷而言，可能看到一種現(xiàn)象就是作業(yè)一直在排隊(duì)或者在控制臺(tái)看到Fuxi Job一直在Waiting。進(jìn)一步在Logview里面查看，發(fā)現(xiàn)Status到底是Waiting還是Waiting List，這樣就可以發(fā)現(xiàn)其到底在哪里排隊(duì)，如果狀態(tài)是Waiting List則可以進(jìn)一步地看其詳細(xì)隊(duì)列長(zhǎng)度到底是多少，排到了第幾位。還可以在SubStatus里面看到其子狀態(tài)的信息。

對(duì)于慢任務(wù)而言，很多用戶反映不能夠知道到底是哪一個(gè)作業(yè)是慢任務(wù)，因此在這里為大家介紹兩種查看慢任務(wù)的方法：一種是“show p”，可以查看所有示例信息；而“top instance”可以查看當(dāng)前正在執(zhí)行的作業(yè)，而運(yùn)行時(shí)間最長(zhǎng)的作業(yè)可能就是阻塞隊(duì)列導(dǎo)致其他任務(wù)排隊(duì)的任務(wù)。對(duì)于由于資源搶占所導(dǎo)致的問(wèn)題，可以做如下的優(yōu)化：

• 對(duì)于后付費(fèi)用戶而言，可以根據(jù)作業(yè)特性把相對(duì)穩(wěn)定的周期性常規(guī)任務(wù)放到預(yù)付費(fèi)資源組去執(zhí)行，可以保證資源不被搶占。
• 對(duì)于預(yù)付費(fèi)用戶而言，如果并行執(zhí)行多個(gè)作業(yè)，最好合理安排作業(yè)執(zhí)行時(shí)間，讓作業(yè)錯(cuò)峰執(zhí)行，臨時(shí)任務(wù)則建議在后付費(fèi)資源組執(zhí)行。而關(guān)于作業(yè)排隊(duì)的原因分析，可以參照云棲社區(qū)的一些相關(guān)資源文檔。

(2) 大量小文件問(wèn)題
大量小文件的存在也會(huì)導(dǎo)致任務(wù)執(zhí)行很慢，比如在作業(yè)開(kāi)始執(zhí)行的時(shí)候，執(zhí)行計(jì)劃可能如下圖中第一張所示，有兩個(gè)Map以及一個(gè)Join還有一個(gè)Reduce，當(dāng)Reduce的Task執(zhí)行之后，發(fā)現(xiàn)系統(tǒng)自動(dòng)增加一個(gè)MergeTask，這就是因?yàn)橄到y(tǒng)在做合并小文件的操作。

其實(shí)，分布式文件系統(tǒng)的數(shù)據(jù)文件是按照塊來(lái)存儲(chǔ)的，盤古的塊大小就是64M，所以如果文件小于64M就可以稱為小文件。小文件的產(chǎn)生主要有這樣的3種原因：(1)當(dāng)Reduce計(jì)算過(guò)程中會(huì)產(chǎn)生大量小文件;(2)Tunnel數(shù)據(jù)采集過(guò)程中會(huì)生成小文件;(2)Job執(zhí)行過(guò)程中生成的各種臨時(shí)文件、回收站保留的過(guò)期文件等。而因?yàn)樾∥募^(guò)多，就會(huì)導(dǎo)致在Map階段讀取的數(shù)據(jù)出現(xiàn)分布不均勻的情況，進(jìn)而引起長(zhǎng)尾。如果存在大量的小文件，除了會(huì)浪費(fèi)資源并降低磁盤空間利用率之外，還會(huì)影響整體的執(zhí)行性能，因此從存儲(chǔ)和性能兩方面考慮都需要將計(jì)算過(guò)程中的小文件都合并。其實(shí)MaxCompute系統(tǒng)已經(jīng)做了很多的優(yōu)化，系統(tǒng)會(huì)自動(dòng)分配一個(gè)Fuxi的MergeTask來(lái)做小文件的合并，但是其實(shí)還有很多情況下產(chǎn)生的小文件沒(méi)有被合并。因此，MaxCompute提供了一些參數(shù)幫助用戶進(jìn)行小文件的合并。

首先可以查看小文件的數(shù)量，也就是判斷自己的表里面是否存在很多小文件。可以用“desc extended TableName”命令就可以輸出小文件數(shù)量。如果小文件數(shù)量很多就可以通過(guò)如圖中下面的SQL來(lái)整合小文件。

為了避免小文件的操作，可以給出一些相關(guān)建議。比如在Reduce過(guò)程中產(chǎn)生的小文件建議可以使用insert overwrite向原表寫入數(shù)據(jù)，或者把數(shù)據(jù)寫入新表之后，將原表刪除。其次，為了避免在Tunnel的數(shù)據(jù)采集過(guò)程中產(chǎn)生小文件，可以調(diào)用Tunnel SDK。也就是在上傳數(shù)據(jù)的時(shí)候最好等到Buffer達(dá)到64M的時(shí)候再進(jìn)行提交，不要過(guò)于頻繁地進(jìn)行提交。在導(dǎo)入分區(qū)表的時(shí)候建議為表設(shè)置生命周期，對(duì)于過(guò)期的數(shù)據(jù)可以進(jìn)行自動(dòng)清理。而針對(duì)大量臨時(shí)表的情況，也可以加上生命周期，到期之后進(jìn)行自動(dòng)回收。對(duì)于小文件的優(yōu)化，在官網(wǎng)文檔中也有更加詳細(xì)的介紹。

?

(3)數(shù)據(jù)傾斜導(dǎo)致長(zhǎng)尾任務(wù)

數(shù)據(jù)傾斜導(dǎo)致長(zhǎng)尾任務(wù)也會(huì)導(dǎo)致慢作業(yè)。其實(shí)數(shù)據(jù)傾斜就是因?yàn)閿?shù)據(jù)分布不均勻，少數(shù)的Fuxi Instance處理的數(shù)據(jù)量遠(yuǎn)遠(yuǎn)超過(guò)其他的Instance，因此導(dǎo)致長(zhǎng)尾任務(wù)。在MaxCompute的Logview里面，將鼠標(biāo)放在Longtails標(biāo)簽上面就可以看到提示“Latency is more than twice average”，也就是說(shuō)運(yùn)行時(shí)間超過(guò)平均的兩倍，就將其定義為長(zhǎng)尾任務(wù)。

通過(guò)Logview有兩種方式查看其是否屬于長(zhǎng)尾任務(wù)，第一種方法就是查看Long-Tails的Fuxi Instances的Max Lantency。如果括號(hào)里面的數(shù)量大于0，那就說(shuō)明已經(jīng)出現(xiàn)了長(zhǎng)尾，點(diǎn)擊標(biāo)簽之后就會(huì)將所有長(zhǎng)尾Instance列出來(lái)，并且可以查看其各種信息。另外一種查看長(zhǎng)尾任務(wù)的方法就是查看Fuxi Job的Summary信息以及Diagnosis信息，通過(guò)分析Summary可以查看長(zhǎng)尾分布在哪個(gè)階段。如果instance time的max和avg兩個(gè)值相差很大就說(shuō)明出現(xiàn)了長(zhǎng)尾；而對(duì)于input records而言，如果輸入數(shù)據(jù)量的max和avg相差也很大就說(shuō)明發(fā)生了數(shù)據(jù)傾斜。在Diagnosis信息里面專門有一項(xiàng)是檢查數(shù)據(jù)傾斜和長(zhǎng)尾的，所以通過(guò)系統(tǒng)所給出的信息就能夠查看出是否出現(xiàn)了長(zhǎng)尾還是數(shù)據(jù)傾斜，也同時(shí)給出了一些改進(jìn)意見(jiàn)。

最后與大家分享對(duì)于不同種類的數(shù)據(jù)傾斜分別可以做哪些優(yōu)化。在Join階段出現(xiàn)的數(shù)據(jù)傾斜是因?yàn)镴oin Key分布不均勻，導(dǎo)致某一個(gè)Key的值數(shù)據(jù)量特別大，會(huì)被分配到同一個(gè)Instance上進(jìn)行處理，這個(gè)Instance處理時(shí)間就會(huì)比較長(zhǎng)，因此造成長(zhǎng)尾。比如用一個(gè)大表來(lái)join一個(gè)小表或者在key中有大量的空值都會(huì)造成Join階段的數(shù)據(jù)傾斜，對(duì)于這種情況可以使用Map Join進(jìn)行優(yōu)化，其原理是將Join操作提前到Join階段進(jìn)行，其實(shí)就是將小表里的數(shù)據(jù)加載到執(zhí)行Join操作的程序內(nèi)存中，所以就加速了Join的執(zhí)行，而Map Join比普通Join性能要好很多，對(duì)于有空值的情況，建議先過(guò)濾掉空值然后補(bǔ)上隨機(jī)數(shù)，相當(dāng)于對(duì)Key做重新分配，然后再進(jìn)行Join。第二種則是由于Group By導(dǎo)致的數(shù)據(jù)傾斜，其產(chǎn)生原因也是由于Group By后面的Key分布不均勻?qū)е碌?#xff0c;這里有兩種優(yōu)化方法，一種是設(shè)置方傾斜的參數(shù)，另外一種則是對(duì)Key加上隨機(jī)數(shù)進(jìn)行重新分配。第三種是由于使用Distinct造成的數(shù)據(jù)傾斜，由于Distinct是對(duì)于字段做去重的操作，那么這樣就沒(méi)辦法在Map的Shuffle階段就根據(jù)GroupBy做一次聚合操作來(lái)減少數(shù)據(jù)傳輸，它只能將所有的數(shù)據(jù)全都傳入到Reduce端來(lái)處理，所以當(dāng)Key的數(shù)據(jù)發(fā)生了不均勻的時(shí)候就會(huì)導(dǎo)致Reduce端出現(xiàn)長(zhǎng)尾，針對(duì)這種情況可以用Count + GroupBy代替Distinct。最后一種就是由于動(dòng)態(tài)分區(qū)帶來(lái)的長(zhǎng)尾，如果動(dòng)態(tài)分區(qū)過(guò)多的時(shí)候就可能造成小文件過(guò)多，而為了整理小文件，系統(tǒng)會(huì)在啟動(dòng)一個(gè)Reduce的Task對(duì)數(shù)據(jù)進(jìn)行整理，如果動(dòng)態(tài)分區(qū)寫入數(shù)據(jù)有傾斜就會(huì)產(chǎn)生長(zhǎng)尾，在這種情況下就盡量不要使用動(dòng)態(tài)分區(qū)，在insert的時(shí)候最好指定相應(yīng)的分區(qū)。對(duì)于優(yōu)化這部分，大家也可以在官網(wǎng)上找到更加詳細(xì)的鏈接。

?

原文鏈接
本文為云棲社區(qū)原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

以上是生活随笔為你收集整理的带你玩转Logview: MaxCompute Logview参数详解和问题排查的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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