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

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

更多精彩內容傳送門：大數據計算技術共享計劃 — MaxCompute技術公開課第二季?

?

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

本文將主要圍繞以下4個方面進行分享：

什么是Logview

相關概念和原理

Logview參數詳解

使用Logview排查問題

很多用戶在使用MaxCompute的時候會遇到一些問題，但是卻苦于不知道如何去定位這些問題，也不知道應該如何進行優化。因此，本文整理了一些Logview參數以及問題定位的相關知識與大家分享。

一、什么是Logview？
Logview是一個在MaxCompute上提交任務之后用來查看和Debug任務的工具，大家可以通過Logview看到任務的運行狀態，包括任務的排隊情況以及資源的使用情況，甚至在每個節點上Instance運行的細節及其進度。當提交的任務出錯了或者運行時間過長，就可以借助Logview分析具體的原因，進而對任務進行精準優化。

二、相關概念和原理
在使用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，以上這些就是完整的作業處理流程。

三、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的信息。

四、使用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的時候最好指定相應的分區。對于優化這部分，大家也可以在官網上找到更加詳細的鏈接。

?

原文鏈接
本文為云棲社區原創內容，未經允許不得轉載。

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。