從0到1進行Spark history分析

xiha00發表於2020-12-28

一、總體思路

從0到1進行Spark history分析總體思路

以上是我在平時工作中分析spark程式報錯以及效能問題時的一般步驟。當然,首先說明一下,以上分析步驟是基於企業級大資料平臺,該平臺會抹平很多開發難度,比如會有排程日誌(spark-submit日誌)、運維平臺等加持,減少了開發人員直接接觸生成伺服器命令列的可能,從物理角度進行了硬控制,提高了安全性。

下面我將帶領大家從零到一,從取日誌,到在Spark WebUI進行視覺化分析相關報錯、效能問題的方法。

二、步驟

(一)獲取applicationID

1.從排程日誌獲取

一般企業級大資料平臺會相對重視日誌的採集,這不僅有助於事後對相關問題、現象的分析;同時也是相關審計環節的要求。

我們知道,spark的排程是通過spark-submit執行觸發的,每一次spark-submit都會有對應的applicationID生成,所以,一般我們可以在排程日誌中可以找到本次排程的applicationID。

2.從運維平臺獲取

企業級大資料平臺為了減少開發、運維人員直接通過ftp、putty、xshell等工具直連生產伺服器,避免誤操作等風險發生,一般會提供一個運維平臺,在頁面上便可直接檢視到job粒度的作業執行情況,以及其唯一標誌applicationID,縮短了開發、運維人員獲取applicationID的“路徑”,減少了機械性的步驟。

(二)從HDFS下載Spark history

我們假設我們的大資料平臺把spark history儲存到了HDFS的/sparkJobHistory/目錄下,下面我們來看看具體如何獲取我們對應applicationID的spark history。

1.命令列下載HDFS檔案

hadoop fs -get /sparkJobHistory/applicationID_xxxxx_1-meta localfile
hadoop fs -get /sparkJobHistory/applicationID_xxxxx_1-part1 localfile

2.HUE工具下載HDFS檔案

我們使用租戶登入HUE工具,進入到File Browser頁面,並通過頁面上的目錄訪問按鈕進入到sparkJobHistory目錄下,然後在搜尋框中輸入applicationID ,就可以看到該applicationID對應的spark history(meta和part1兩個檔案)顯示在了頁面中,勾選並下載,便可以將spark history下載到我們本地。

(三)上傳Spark history到開發環境

接下來我們要做的工作就是將從生產上獲取到的spark history放到我們開發環境上,以便進行後續分析。

1.命令列推送spark history到HDFS上

首先我們需要將從生產下載到本地的spark history上傳到我們測試環境的任意一個節點上,這裡我們將其上傳到測試環境01節點的${WORK_ROOT}/etluser/tmp/spark_history/applicationID_xxxxx/路徑下,接下來在測試環境命令列執行以下命令,將spark history上傳到HDFS:

hadoop fs -put ${WORK_ROOT}/etluser/tmp/spark_history/applicationID_xxxxx/* /sparkJobHistory/

2.HUE工具上傳spark history到HDFS上

這個步驟和我們在生產HUE類似,首先使用租戶登入到測試環境HUE,然後進入File Browser的/sparkJobHistory/路徑下,點選Upload按鈕,上傳spark history到該路徑下即可。

(四)Spark WebUI進行分析

1.搜尋applicationID

進入Spark WebUI頁面,在搜尋框輸入applicationID,即可篩選出該applicationID的spark history。

2.進行stage視覺化分析

點選該App ID進去即可看到該applicationID的每一個Job詳細執行情況;點選進一個Job,即可看到該Job的DAG圖,以及對應的stage執行情況;點選進一個stage,即可看到該stage下所有的task執行情況。通過每一個頁面上的執行耗時、GC時間、input/output資料量大小等,根據這些資訊即可分析出異常的task、stage、job。

(五)檢視相關程式碼段

1.定位異常Job

通過applicationID進入到我們要分析的Job的執行情況頁面後,可以看到該App ID下每一個Job,一般通過觀察每一個Job的執行時長可以識別出哪一個Job是異常的,通常執行時間過長的Job就是異常的,可以進入該Job的詳細頁面進行進一步分析。

2.回溯Job對應程式碼段

一般定位到異常的Job我們就可以知道對應的程式碼段,通常這個Job執行情況頁會顯示其對應的程式碼行,通過回到程式碼中找到這個程式碼行,其前後一小部分程式碼段就是這個異常Job的執行程式碼段。

(六)分析與定位問題

1.列出程式碼段涉及的源表

如果是SparkSQL程式碼,可以通過SQL直觀獲取到其所涉及的源表,將這些源表記錄下來,以便後續分析。

如果是SparkRDD程式碼,可以通過程式碼中所使用的資料集追溯到該資料集所對應的源表,同樣,我們把它們記錄下來,以便後續進行分析。

2.分析源表的使用方式:廣播、普通關聯、…

我們可以通過程式碼中分析出這些源表的使用方式。最常見的應該是對小表進行廣播的方式。所謂廣播,就是把小表的資料完整地傳送到叢集的各個DataNode本地快取起來,當大表與之進行關聯操作時,存在於各個DataNode之上的大表資料塊便可以根據就近計算原則,與小表資料進行關聯計算,從而減少了網路傳輸,提高了執行速度。

在SparkSQL中,一般如果大表和小表進行關聯,會通過hint語法對小表進行廣播,具體來說是使用/*mapjoin(small_table_name)*/這樣的形式。
而在SparkRDD中,一般也會對小表進行廣播操作,通過broadcast()介面進行實現。在Java中,具體來說是使用Broadcast data_broadcast = JavaSparkContext.broadcast(table_data.collect());這樣的語法進行實現。

對於普通關聯,即沒有對錶進行特殊處理的關聯。這種寫法一般在大小表關聯的場景下容易出現效能問題,需要特別關注。經常可以作為問題分析的切入點。

3.檢視源表資料量

一般通過第一步把問題程式碼段中所涉及的源表羅列出來後,就需要到生產檢視這些源表的資料量是多少,以方便分析是否是因為資料量過大而導致的效能問題,一般如果是資料量導致的問題,多半是因為資源不足,可以考慮通過調整資源數量來解決。

當然,除了常規的檢視源表的記錄數外,還可以檢視該表在HDFS上佔用的空間大小。

檢視源表記錄數SQL:

select count(1) as cnt from db_name.table_name where pt_dt=’xxxx-xx-xx’;

檢視源表佔用的空間大小,這裡使用GB為單位(102410241024)顯示:

hadoop fs -du /user/hive/warehouse/db_name.db/ table_name/pt_dt='xxxx-xx-xx' | awk ‘${SUM+=$1} END {print SUM/(1024*1024*1024)}'

4.檢視源表資料塊分佈情況

有時候源表的資料量並不算大,但是還是出現了效能瓶頸,這時候通過觀察tasks數的多少,大致可以猜測到是因為源表的資料塊大小分佈不均勻,或是資料塊過少導致的。可以通過以下命令檢視源表的資料塊分佈情況:

hadoop fs -ls -h /user/hive/warehouse/db_name.db/ table_name/pt_dt='xxxx-xx-xx'

通過該命令的輸出我們可以看到源表的每一個資料塊大小,以此有多少個資料塊。舉個例子,如果資料塊只有2~3塊,第一個資料塊有80MB,第二、第三個資料塊分別只有1KB,那基本可以判定這幾個資料塊分佈不合理。

資料塊分佈不合理可以通過對源表資料進行重分佈(repartition)或設定spark處理的每個map資料塊大小上限來前置將過大的資料塊分散到各個task中處理,以減少關鍵task的處理耗時,提升程式效能。

三、總結

本文深入淺出,具體到步驟和實際操作,帶領大家從獲取作業applicationID,到下載Spark history,再到上傳Spark history至開發環境,再進行Spark WebUI分析異常stage,再而定位到問題程式碼段,最後給出一般問題的分析方向以及分析方法。

對於Spark相關問題的分析,最直接有效的就是對Spark history的分析了,希望大家能通過練習和實操掌握這項技能。當然,平時進行Spark、Hadoop生態體系的理論知識積累也是必不可少的,所謂萬丈高樓平地起,根基要穩,才能讓樓起得更高。

相關文章