一探究竟：善用 MaxCompute Studio 分析 SQL 做業

摘要： 頭疼的問題 MaxCompute 用戶一個常見的問題是：同一個週期任務，爲何最近幾天比以前慢了不少？或者爲何以前都能按時產出的做業最近常常破線？ 一般來講，引發做業執行變慢的緣由有：quota 組資源不足、輸入數據量變更、數據分佈狀況變更、平臺硬件故障引起重跑等。

頭疼的問題

MaxCompute 用戶一個常見的問題是：同一個週期任務，爲何最近幾天比以前慢了不少？或者爲何以前都能按時產出的做業最近常常破線？

一般來講，引發做業執行變慢的緣由有：quota 組資源不足、輸入數據量變更、數據分佈狀況變更、平臺硬件故障引起重跑等。本文主要針對數據變更引發的做業慢問題，介紹用戶如何經過 MaxCompute Studio 的做業執行圖及做業詳情功能來自助定位問題。

MaxCompute Studio 登場

咱們舉個例子來講。 下面是同一個任務分別在5月7日，5月9日的執行狀況，下面分別稱爲做業1、做業二：

做業一，執行時長 24分38秒

做業二，執行時長 9分40秒

先來，對比下 SQL 和執行計劃

一般來講，進行兩次執行對比前，要先對比一下兩次執行的 SQL 腳本是否相同，若是在這之間用戶改動過做業腳本，就須要先分析改動的部分形成的影響。若是腳本內容一致，隨後還須要比較執行計劃是否一致，能夠經過  MaxCompute  Studio  的做業執行計劃圖功能來分析（參看文檔），可視化地看看兩次執行的計劃圖長得同樣不同。 （做業對比的功能正在開發中，下個版本的 Studio 中就能夠一鍵對比兩個做業，標註出 SQL 腳本及其它部分的不一樣之處啦，敬請期待）

在上面這個例子中兩個做業的 SQL 腳本及執行計劃徹底一致，出於數據安全考慮，此處不粘貼具體 SQL 的內容。

再來，對比數據量

第二步要看一下做業輸入數據量有沒有明顯變化，有多是某一天輸入表或分區的數據量暴漲致使了做業執行變慢。做業輸入數據在 Detail 頁面左側，那裏列出了這個做業全部輸入的數據表和最終輸出的數據表。 展開 輸入->Table Name 能夠查看詳細信息，包括是哪一個 Fuxi 任務讀取了這個表，讀取了多少條記錄以及讀取的數據量大小。這些信息，也標註在做業執行計劃圖 graph 上，方便查看。以下圖所示，

做業一的輸入表及讀取數據

做業二的輸入表及讀取數據

也能夠從graph上直接讀取輸入行數或者字節數（默認展現行數，可在邊上右鍵切換爲字節數）：

做業一 graph輸入行數

做業二 graph輸入行數

在這個例子中，從輸入數據量來看，兩次執行的輸入數據量差異不大。

做業回放是把利器

第三步，那到底做業運行狀況是怎樣的呢？運行那麼長時間，或花費在哪兒了呢？不急，快快使用做業回放！
在 Studio 中做業執行計劃圖底部提供的做業回放工具條，容許用戶在 30 秒內快速回放做業執行進度的全過程！這樣咱們就能夠迅速地瞭解究竟是哪一個 Task 耗時最多，或者處理得數據最多，或者輸出的數據最多等等。

經過回放重現做業執行過程，Studio 提供進度圖以及熱度圖方便從不一樣維度進行做業分析。

做業一 進度圖回放

做業二 進度圖回放

從回放中能夠看出
（1）J6_2_4_5 task是整個做業瓶頸，時間消耗最多，從task熱度圖中也能發現該節點明顯熱於其它節點。（時間熱度圖上越紅表明運行時間越長，數據熱度圖上越紅表明處理數據越多）

（2）同時對比兩個做業的回放過程，可以比較明顯地發現做業一在J6_2_4_5運行時長要大於做業二，說明做業一在J6_2_4_5階段變慢了，初步懷疑有長尾節點產生。

接下來切換到時序圖tab，比較兩個做業的執行timeline：

做業一 執行timeline

做業二 執行timeline

雖然兩個做業timeline的時間尺度不一樣，可是能夠明顯看出，做業一中J6_2_4_5 佔了更長的比例，由此能夠判定是J6_2_4_5 在05-07執行（也就是做業一）發生可能長尾，致使整個做業執行變慢。

進入深水區

第四步，經過graph或detail tab 對比J6_2_4_5 的輸入數據量

做業一 detail tab

做業二 detail tab

關注上圖中J6_2_4_5 輸入數據量和統計信息，經過比較可看出，兩次執行的J6_2_4_5 輸入數據量基本相同，1.58萬億字節 vs 1.7萬億字節，從統計信息來看，累計執行時間及平均時間也基本相同：292398 vs 307628， 72s vs 76s 但做業一 fuxi instances中的最長執行時間爲710s， 由此能夠認定是某幾個fuxi instance長尾致使了J6_2_4_5 這個fuxi task的長尾。

第五步，對兩個 J6_2_4_5 fuxi instance 列表按照latency 排序：

做業一

做業二

或者轉到分析tab下的長尾頁面查找長尾節點：注意這個圖中的比例尺是以等比而不是等差方式標定的，所以，上面突出的比較長的毛刺就極可能是長尾的實例了。能夠經過浮動窗口中的具體信息來判斷。 另外 Studio 也提供了診斷的頁面，來自動找出超過平均實例執行時間兩倍的長尾實例。

做業一

做業二

從上面fuxi instance 輸入數據對比能夠肯定，由於J6_2_4_5#1912_0 這個instance 數據傾斜致使整個做業一長尾。即J6_2_4_5#1912_0 是latency排第二的輸入數據量的7倍！

漸入佳境，刨根問底

第六步，查看單個instance的執行日誌，並經過job graph分析J6_2_4_5的具體執行計劃，找到致使長尾的數據來源。

打開J6_2_4_5的operator graph， 能夠看到有兩個join：Merge Join2和Merge Join3，這裏以Merge Join2爲例展現如何查找數據來源。

從Merge Join2中可看到join key：_col13, user_id。 其中_col13 來自於J5， 點開J5後發現_col13來自IF(ISNULL(HOT_SELLER_MAP(sellerid)),sellerid,CONCAT(seller,TOSTRING(RAND()))) 說明_col13由seller決定，該seller來自於M4和M3。

J5 operator詳細信息

分別打開M4和M3的Operator詳細信息，能夠看到seller 分別來自tmp_s_dw_log_app_user_track_pre_1_20180508 和dim_feed_shop。

M4 Operator詳細信息

M3 Operator詳細信息

同理能夠分析出Merge Join2 的user_id 來自於dim_tb_shop。

最後，經過寫sql模擬產生對應的userid及_col13，比較這兩個字段的數據量大小，在針對sql腳本進行優化便可。

原文連接