帶你玩轉Logview: MaxCompute Logview參數詳解和問題排查

摘要： 對於Logview上的諸多參數信息，究竟應該怎麼「撥開雲霧」，發現問題所在呢？又如何經過Logview瞭解每一個instance、task運行狀態及資源佔用狀況，如何分析執行計劃，分析query存在問題，找到Long-Tails task，讓數據分析業務高效又省錢呢？本文中，阿里巴巴計算平臺產品專家雲花將爲你們揭曉答案。

摘要：Logview是MaxCompute Job提交後查看和Debug任務的工具。經過Logview可看到一個Job的運行狀態、運行結果以及運行細節和每一個步驟的進度。當Job提交到MaxCompute後，會生成Logview的連接，用戶能夠直接在瀏覽器上打開Logview連接，進入查看Job的信息，而對於Logview上的諸多參數信息，究竟應該怎麼「撥開雲霧」，發現問題所在呢？又如何經過Logview瞭解每一個instance、task運行狀態及資源佔用狀況，如何分析執行計劃，分析query存在問題，找到Long-Tails task，讓數據分析業務高效又省錢呢？本文中，阿里巴巴計算平臺產品專家雲花將爲你們揭曉答案。

直播視頻回看，戳這裏！https://yq.aliyun.com/webinar...
分享資料下載，戳這裏！https://yq.aliyun.com/downloa...
更多精彩內容傳送門：大數據計算技術共享計劃 — MaxCompute技術公開課第二季

如下內容根據演講視頻及PPT整理而成。

本文將主要圍繞如下4個方面進行分享：
什麼是Logview
相關概念和原理
Logview參數詳解
使用Logview排查問題
不少用戶在使用MaxCompute的時候會遇到一些問題，可是卻苦於不知道如何去定位這些問題，也不知道應該如何進行優化。所以，本文整理了一些Logview參數以及問題定位的相關知識與你們分享。

1、什麼是Logview？

Logview是一個在MaxCompute上提交任務以後用來查看和Debug任務的工具，你們能夠經過Logview看到任務的運行狀態，包括任務的排隊狀況以及資源的使用狀況，甚至在每一個節點上Instance運行的細節及其進度。當提交的任務出錯了或者運行時間過長，就能夠藉助Logview分析具體的緣由，進而對任務進行精準優化。

2、相關概念和原理

在使用Logview的時候可能會遇到不少名詞，這些名詞都是MaxCompute特有的，所以在本部分中也進行簡單介紹，幫助你們更好地理解Logview的運行原理。

MaxCompute系統架構

以下圖所示的是MaxCompute的系統架構。從上往下看，首先最上層就是數據源和客戶端接入的部分，各類外部數據源均可以經過外部傳輸的工具如Tunnel以及DataHub將數據同步到分佈式文件存儲系統盤古中。在客戶端，用戶可使用命令行工具、MaxCompute Studio以及DataWorks等開發完任務提交以後，以Restful API形式提交到HTTP服務，當HTTP服務接收到請求以後，先向用戶中心作身份鑑權，所以整個接入層其實承載了數據上傳下載、用戶鑑權以及負載均衡等工做。接入層之下就是管理層，這也是MaxCompute最爲核心的部分，這部分負責對用戶空間和對象的管理、命令的解析與執行、對象的訪問控制以及受權等功能，其主要有三種角色，即Workers、Scheduler以及Executor。MaxCompute的元數據實際上是存儲在阿里雲開放服務——分佈式元數據服務上。

MaxCompute的計算集羣就是架構在飛天系統之上的，而飛天系統的核心模塊包括了分佈式文件存儲系統盤古、分佈式資源調度系統伏羲、分佈式協同服務女媧以及分佈式監控系統神農、遠程過程調用系統夸父、以及安全管理系統鍾馗等。以上就是MaxCompute的基礎架構，其最核心和複雜的邏輯就在管理層與伏羲之間的任務調度和管理。

MaxCompute元數據模型

其實MaxCompute之前還有個名字叫作ODPS，從2016年開始ODPS正式更名爲MaxCompute，因此其實在Logview中出現的ODPS字樣其實就是指MaxCompute。MaxCompute最多見的兩種對象就是Job，也就是Instance，另一個就是ODPS Task。好比當提交一個SQL Query的請求，系統就會建立一個Instance，而當這個Instance在MaxCompute上執行的時候就會被分解成多個Task，可是多數狀況下Instance與Task是一一對應的。這個Task有SQL類型的、有MR類型的，還有機器學習的。而在底層的分佈式系統Fuxi上面也有Job和Task和Instance的概念，而這些須要和MaxCompute上的Task以及Instance的概念區分清楚。當ODPS Task提交到服務器上以後，每一個Task會被分解成爲多個Fuxi Job，而每一個Fuxi Job會根據執行計劃分解成不一樣的執行階段，好比Map、Reduce以及Join等。而每一個Task又會啓動多個Instance來執行，至關於啓動多個節點。

MaxCompute做業處理流程

首先，用戶會在客戶端提交一個SQL語句，客戶端會經過Restful API形式提交到HTTP服務，HTTP服務的前端接收到這個請求以後會先去用戶中心作鑑權，經過鑑權以後會根據所在集羣信息轉交給MaxCompute相應的Worker去執行。Worker則會解析這個請求，首先作API的鑑權，有了權限以後纔會響應請求。Worker會判斷做業類型，一種是同步任務，也就是說當Worker本身執行完就能夠返回，好比SQL DDL以及Job的查詢狀態等，Worker會訪問OTS獲取元數據信息，而後交給Executor執行，執行完成以後就直接返回給客戶端。另一種是異步任務，所謂異步任務就是對後續節點進行處理，須要提交到Fuxi去處理的任務，好比SQL的DML或者MR這類的任務請求。Worker會建立一個Instance而後交給Scheduler去執行，Scheduler負責對全部異步任務的調度，它會把Instance分解爲Task並作全局的計算調度。當全部資源以及條件都知足Scheduler就會將Task交給Executor進行執行，Executor上其實封裝了各類業務邏輯，好比SQL以及算法模塊，Executor會根據不一樣的做業類型拉取不一樣的做業模塊。當Executor空閒的時候會向Scheduler進行心跳上報並請求任務，當其拿到任務以後會根據任務類型啓動一個相應的業務模塊來執行。Executor會生成一個任務的執行計劃，並將任務以及執行計劃一塊兒交給Fuxi進行執行。有時候提交到Fuxi的任務會出現回退的狀況，好比第一次是按照Online Job的做業類型來提交的，到Fuxi以後可能會提交失敗並回退到Scheduler，而後按照Offline的方式再提交一次，這樣就會在Logview看到對應的狀況。當Executor將Task提交給Fuxi以後，還會去監控Task的執行狀態，當執行完成以後則會更新OTS裏面的Task信息並彙報給Scheduler，Scheduler則會判斷整個Instance是否執行完畢，若是執行完畢也會去更新OTS中的Instance信息，將其設置爲Terminated，以上這些就是完整的做業處理流程。

3、Logview參數詳解

分享完基本概念和理論以後就能夠介紹Logview的參數了。主要的信息包括ODPS Instance，其涵蓋了隊列信息以及子狀態信息，另一部分包括Fuxi Job，這能夠進一步拆解成Task信息和Fuxi Instance信息。在整個任務結束以後能夠看到其Summary以及Diagnosis診斷信息，此外還有上傳下載的小功能。

ODPS Instance信息

下圖中最上面的表中有這樣的幾個字段：URL、Project、InstanceID、Owner、StartTime、EndTime、Latency、Status以及Process等。URL是Endpoint的地址，Project存放項目的名稱，InstanceID實際上是時間戳跟着隨機字符串，這個時間戳是精確到毫秒的，而這個時間是UTC時間，與電腦提交任務的時間是不一致的。StartTime和EndTime分別是任務開始和結束的時間，Latency則是任務運行所消耗的時間。而對於Status而言，則有四種狀態：Waiting狀態表明任務正在ODPS中處理，還沒提交到Fuxi中運行；Waiting List表明任務已經到了Fuxi，而且在Fuxi中排隊，N表明排隊的位置；Running表明在Fuxi中運行；Terminated表明運行已經結束了。在表格裏面，只要Status不是Terminated的狀態，只要雙擊就能打開Queue Detail和SubStatus History詳細信息。

Queue Detail&SubStatus History信息

以下圖所示最上面的Table是關於隊列的信息，首先是Fuxi Job的name，SubStatus則是目前Job的運行狀態，Progress是目前的執行進度。紅框裏面有兩個字段，分別是WaitPOS和QueueLength，前者是目前排隊的位置，後者是隊列長度，根據這兩個字段就能看到整個隊列裏面有多少任務在排隊，這個任務排在第幾位。Total Priority是其優先級，點擊SubStatus History的圖標能夠打開下圖中下側的Table。對於SubStatus History而言着重介紹一下SubStatus Code以及其含義，在下圖中列出了一些常見的SubStatus Code以及其對應含義。

Fuxi Job的兩種做業類型

前面也提到了Fuxi Job有兩種做業類型，分別是Online Job和Offline Job，這兩種Job到底有什麼區別呢？首先，對於Offline的做業而言，當每次提交做業時在Fuxi上都會有一個環境準備的時間，對於大數據量而且不須要返回查詢結果的做業比較合適。而對於小數據量而且實時做業要求比較高的做業是不合適的。因此Fuxi提供了Service Mode這種準實時的做業形式，首先會有一個服務去預先申請計算一些資源並加載出來，好比會預先分配一萬個Instance，當有做業提交過來的時候會根據做業規模分配一些Instance進行執行，這樣就省去環境準備的時間，因此就會比較快，這就是兩種類型做業的主要差別。

對於FuxiJob的命名規則而言，如上圖所示「odps/」後面的部分就是<project_name>_<instanceId>_<task_type>_<odps_task_index>_<task_history>_<fuxi_job_index>_<jobtail>。

ODPS Task信息

以下圖所示的是ODPS Task信息，上面的表格的第一個字段是TaskName，Type指的是做業類型，Status指的是運行狀態，雙擊Rusult會輸出做業的整個結果集，雙擊Detail信息則會打開整個Fuxi Job的詳細Table。

Fuxi Job Detail信息

Fuxi Job詳細信息主要分爲三個部分，最左側是任務的執行計劃，這個執行計劃是在Executor裏面生成的，執行計劃就是將一個任務分紅不一樣的Stage來執行，每一個Stage的均可以看作一個圖上的點，而Stage之間的依賴關係就能夠看作圖的邊，這樣就構成一個有向無環圖。在下圖例子中，將Fuxi Job分解成了四個Map的Task，兩個Join的Task，還有3個Reduce的Task。舉例而言，對於J3_1_2這個Task而言，須要在M1和M2執行完成以後纔會執行，也就是說M1和M2的輸出就是J3_1_2的輸入，而且在名字上也能夠體現其依賴關係，也就是說命名實際上是和執行計劃相關的。下圖中右上方這部分就是每一個Task的詳細信息，也是每一個Stage的詳細信息。圖中下面部分則是每一個Instance的詳細信息。

Fuxi Task Detail信息

對於Fuxi Job Detail信息而言，又有哪些須要關注呢？第一個字段就是TaskName，其和執行計劃的生成是相關的。後面的字段Fatal/Finished/TotalInstCount，在表格裏面Fatal表示嚴重錯誤個數，所以被標紅了；Finished表示已經結束的Instance的個數，後面的TotalInstCount指的是爲每一個Task啓動的總Task數量。下一個字段I/O Records指的是輸入和輸出的記錄的個數，I/O Bytes指的是輸入和輸出的字節數。FinishedPercentage指的是進度條，Status則指的是每一個Task的運行狀態。

Fuxi Instance Detail信息

Fuxi Instance是整個做業流中最小的顆粒，在以下圖所示的Demo中是一個Map的做業詳細信息。首先看All字段，這個字段後面有一個數字415，這說明爲M3_2這個Task啓動了415個Instance，其左側的Terminated、Running、Ready以及Failed分別是相應狀態的實例個數。而SmartFilter則會給出最先結束、最晚結束、運行時間最短和運行時間最長的四個Instance，將其篩選處理方便觀察。Latency Chart則是以圖表的形式展現全部的Instance的運行時長分佈，而在Latency裏面則是最長運行時間和最短運行時間以及平均運行時長，其實這三個時間對於分析長尾任務是很是有用的。在每一個Instance的表格裏面詳細信息裏面有一個StdOut，這是每一個Instance在執行過程當中打印的信息，而StuErr則是當Instance失敗的時候能夠用來查看出錯緣由的。

Fuxi Job Detail信息 之 Summary信息

FuxiJob的Summary是在整個Job運行完以後才能查看的信息，主要包括Job消耗的CPU、內存、Job輸入的表名以及記錄數和字節數。此外，Job的運行時間單位是秒。Fuxi Task的Summary信息則主要包括Instance數量、Task運行時間、全部Instance裏面的最大、最小和平均運行時間。

Tips：用Summary信息作計量計費參考

這裏與你們分享一個Tips，就是如何用Summary信息作計量計費參考，好比在這裏執行的是一個MapReduce做業，其計費方法是MR任務當日計算費用=當日總計算時0.46元(RMB)，則任務的計算時=任務運行時間(小時)任務調用的核數量。而在Summary信息裏面就可以直接拿到CPU的計算時，而不須要用公式計算了。而對於SQL計算而言，計算公式爲：一次SQL計算費用 = 計算輸入數據量 SQL複雜度 SQL價格。而輸入數據量與SQL複雜度都可以經過cost sql <SQL Sentence>這個命令來計算。對於計量計算而言，更多的內容請參考官網上的信息。

Diagnosis信息

Diagnosis是診斷信息，其是在做業執行完成以後能夠點擊小紅點進而打開以下圖所示的表格。Diagnosis主要會診斷三類信息，分別是對資源的診斷、對數據傾斜的診斷以及對從新運行的診斷，每類信息會給出對於問題的說明和問題嚴重等級，而且會給出改進意見。

Logview信息的導入導出

Logview的信息能夠導入和導出，由於其信息只能在系統中保留7天，若是想要長期保存就須要導出信息。你們能夠點擊Logview右上角的小圖標將Logview信息保存到本地，當須要分析的時候再點擊「望遠鏡」小圖標，從本地將Logview信息上傳上去就能夠還原出Logview的信息。

4、使用Logview排查問題
常見的問題有這樣幾種，首先就是任務一直在排隊等待或者任務直接運行失敗了，而最多見的狀況就是任務執行時間太長了，一直跑不完。其實大多數慢任務的緣由都是由於長尾，而大多數長尾都是由於數據傾斜帶來的。這不只將會影響數據分析結果的產出，還會拉高數據資源的消費，所以對於這種狀況必需要進行優化。

1. 任務出錯了
對於出錯任務而言，從控制檯輸出就能夠看到出錯的緣由，若是想要查看更加詳細的信息，則能夠打開Logview去查看ODPS的Result信息，若是失敗了能夠看到Status變成紅色了。當雙擊Result以後就能夠看到報錯輸出的總體信息。在出錯信息裏面會有錯誤碼，而錯誤碼與詳細錯誤的對照表能夠在官網找到。因此查看出錯任務的方式有兩種，一種是在做業結束以後查看其Result信息，另一種方式則是去查看Instance的StdErr信息。

2. 慢任務診斷
(1) 做業排隊
對於慢任務診斷而言，可能看到一種現象就是做業一直在排隊或者在控制檯看到Fuxi Job一直在Waiting。進一步在Logview裏面查看，發現Status究竟是Waiting仍是Waiting List，這樣就能夠發現其到底在哪裏排隊，若是狀態是Waiting List則能夠進一步地看其詳細隊列長度究竟是多少，排到了第幾位。還能夠在SubStatus裏面看到其子狀態的信息。

對於慢任務而言，不少用戶反映不可以知道究竟是哪個做業是慢任務，所以在這裏爲你們介紹兩種查看慢任務的方法：一種是「show p」，能夠查看全部示例信息；而「top instance」能夠查看當前正在執行的做業，而運行時間最長的做業可能就是阻塞隊列致使其餘任務排隊的任務。對於因爲資源搶佔所致使的問題，能夠作以下的優化：
對於後付費用戶而言，能夠根據做業特性把相對穩定的週期性常規任務放到預付費資源組去執行，能夠保證資源不被搶佔。
對於預付費用戶而言，若是並行執行多個做業，最好合理安排做業執行時間，讓做業錯峯執行，臨時任務則建議在後付費資源組執行。而關於做業排隊的緣由分析，能夠參照雲棲社區的一些相關資源文檔。

(2) 大量小文件問題
大量小文件的存在也會致使任務執行很慢，好比在做業開始執行的時候，執行計劃可能以下圖中第一張所示，有兩個Map以及一個Join還有一個Reduce，當Reduce的Task執行以後，發現系統自動增長一個MergeTask，這就是由於系統在作合併小文件的操做。

其實，分佈式文件系統的數據文件是按照塊來存儲的，盤古的塊大小就是64M，因此若是文件小於64M就能夠稱爲小文件。小文件的產生主要有這樣的3種緣由：(1)當Reduce計算過程當中會產生大量小文件;(2)Tunnel數據採集過程當中會生成小文件;(2)Job執行過程當中生成的各類臨時文件、回收站保留的過時文件等。而由於小文件過多，就會致使在Map階段讀取的數據出現分佈不均勻的狀況，進而引發長尾。若是存在大量的小文件，除了會浪費資源並下降磁盤空間利用率以外，還會影響總體的執行性能，所以從存儲和性能兩方面考慮都須要將計算過程當中的小文件都合併。其實MaxCompute系統已經作了不少的優化，系統會自動分配一個Fuxi的MergeTask來作小文件的合併，可是其實還有不少狀況下產生的小文件沒有被合併。所以，MaxCompute提供了一些參數幫助用戶進行小文件的合併。

首先能夠查看小文件的數量，也就是判斷本身的表裏面是否存在不少小文件。能夠用「desc extended TableName」命令就能夠輸出小文件數量。若是小文件數量不少就能夠經過如圖中下面的SQL來整合小文件。

爲了不小文件的操做，能夠給出一些相關建議。好比在Reduce過程當中產生的小文件建議可使用insert overwrite向原表寫入數據，或者把數據寫入新表以後，將原表刪除。其次，爲了不在Tunnel的數據採集過程當中產生小文件，能夠調用Tunnel SDK。也就是在上傳數據的時候最好等到Buffer達到64M的時候再進行提交，不要過於頻繁地進行提交。在導入分區表的時候建議爲表設置生命週期，對於過時的數據能夠進行自動清理。而針對大量臨時表的狀況，也能夠加上生命週期，到期以後進行自動回收。對於小文件的優化，在官網文檔中也有更加詳細的介紹。

(3)數據傾斜致使長尾任務

數據傾斜致使長尾任務也會致使慢做業。其實數據傾斜就是由於數據分佈不均勻，少數的Fuxi Instance處理的數據量遠遠超過其餘的Instance，所以致使長尾任務。在MaxCompute的Logview裏面，將鼠標放在Longtails標籤上面就能夠看到提示「Latency is more than twice average」，也就是說運行時間超過平均的兩倍，就將其定義爲長尾任務。

經過Logview有兩種方式查看其是否屬於長尾任務，第一種方法就是查看Long-Tails的Fuxi Instances的Max Lantency。若是括號裏面的數量大於0，那就說明已經出現了長尾，點擊標籤以後就會將全部長尾Instance列出來，而且能夠查看其各類信息。另一種查看長尾任務的方法就是查看Fuxi Job的Summary信息以及Diagnosis信息，經過分析Summary能夠查看長尾分佈在哪一個階段。若是instance time的max和avg兩個值相差很大就說明出現了長尾；而對於input records而言，若是輸入數據量的max和avg相差也很大就說明發生了數據傾斜。在Diagnosis信息裏面專門有一項是檢查數據傾斜和長尾的，因此經過系統所給出的信息就可以查看出是否出現了長尾仍是數據傾斜，也同時給出了一些改進意見。

最後與你們分享對於不一樣種類的數據傾斜分別能夠作哪些優化。在Join階段出現的數據傾斜是由於Join Key分佈不均勻，致使某一個Key的值數據量特別大，會被分配到同一個Instance上進行處理，這個Instance處理時間就會比較長，所以形成長尾。好比用一個大表來join一個小表或者在key中有大量的空值都會形成Join階段的數據傾斜，對於這種狀況可使用Map Join進行優化，其原理是將Join操做提早到Join階段進行，其實就是將小表裏的數據加載到執行Join操做的程序內存中，因此就加速了Join的執行，而Map Join比普通Join性能要好不少，對於有空值的狀況，建議先過濾掉空值而後補上隨機數，至關於對Key作從新分配，而後再進行Join。第二種則是因爲Group By致使的數據傾斜，其產生緣由也是因爲Group By後面的Key分佈不均勻致使的，這裏有兩種優化方法，一種是設置方傾斜的參數，另一種則是對Key加上隨機數進行從新分配。第三種是因爲使用Distinct形成的數據傾斜，因爲Distinct是對於字段作去重的操做，那麼這樣就沒辦法在Map的Shuffle階段就根據GroupBy作一次聚合操做來減小數據傳輸，它只能將全部的數據全都傳入到Reduce端來處理，因此當Key的數據發生了不均勻的時候就會致使Reduce端出現長尾，針對這種狀況能夠用Count + GroupBy代替Distinct。最後一種就是因爲動態分區帶來的長尾，若是動態分區過多的時候就可能形成小文件過多，而爲了整理小文件，系統會在啓動一個Reduce的Task對數據進行整理，若是動態分區寫入數據有傾斜就會產生長尾，在這種狀況下就儘可能不要使用動態分區，在insert的時候最好指定相應的分區。對於優化這部分，你們也能夠在官網上找到更加詳細的連接。

原文連接

本文爲雲棲社區原創內容，未經容許不得轉載。