柚子快報(bào)邀請(qǐng)碼778899分享：Spark web UI 介紹

http://yzkb.51969.com/

前言

在日常的開(kāi)發(fā)工作中，我們總會(huì)遇到 Spark 應(yīng)用運(yùn)行失敗、或是執(zhí)行效率未達(dá)預(yù)期的情況。對(duì)于這樣的問(wèn)題，想找到根本原因，可以通過(guò) Spark UI 提供的"體檢報(bào)告"中的一些信息來(lái)獲取最直接、最直觀的線索，本篇就是介紹如何解讀Spark UI “體檢報(bào)告”，和用他定位分析問(wèn)題。

一、Web UI 頁(yè)面介紹

打開(kāi) Spark UI，首先映入眼簾的是默認(rèn)的 Jobs 頁(yè)面。Jobs 頁(yè)面記錄著應(yīng)用中涉及的 Actions 動(dòng)作，以及與數(shù)據(jù)讀取、移動(dòng)有關(guān)的動(dòng)作。

其中，每一個(gè) Action 都對(duì)應(yīng)著一個(gè) Job，而每一個(gè) Job 都對(duì)應(yīng)著一個(gè)作業(yè)。 可以看到，導(dǎo)航條最左側(cè)是 Spark Logo 以及版本號(hào)，后面則依次羅列著 6 個(gè)一級(jí)入口。每個(gè)入口的功能與作用如下的表格介紹

1.1 Executors頁(yè)（一級(jí)入口）

Executors Tab 的主要內(nèi)容如下，主要包含“Summary”和“Executors”兩部分。這兩部分所記錄的度量指標(biāo)是一致的，其中“Executors”以更細(xì)的粒度記錄著每一個(gè) Executor 的詳情

，而第一部分“Summary”是下面所有 Executors 度量指標(biāo)的簡(jiǎn)單加和。

1.1.1 Metrics 指標(biāo)介紹

1.2 Environment頁(yè)（一級(jí)入口）

Environment 頁(yè)面記錄的是各種各樣的環(huán)境變量與配置項(xiàng)信息，如下圖所示：

1.2.1 Metrics 指標(biāo)介紹

其中Spark Properties 是重點(diǎn)，其中記錄著所有在運(yùn)行時(shí)生效的 Spark 配置項(xiàng)設(shè)置。

通過(guò) Spark Properties，我們可以確認(rèn)運(yùn)行時(shí)的設(shè)置，與我們預(yù)期的設(shè)置是否一致，從而排除因配置項(xiàng)設(shè)置錯(cuò)誤而導(dǎo)致的穩(wěn)定性或是性能問(wèn)題。

1.3 Storage頁(yè) （一級(jí)入口）

Storage 詳情頁(yè)，記錄著每一個(gè)分布式緩存（RDD Cache、DataFrame Cache）的細(xì)節(jié)，包括緩存級(jí)別、已緩存的分區(qū)數(shù)、緩存比例、內(nèi)存大小與磁盤(pán)大小。但下圖為空，原因沒(méi)有使用或者未對(duì)使用的RDD或DataFrame使用persist()或cache()操作

1.4 SQL頁(yè) （一級(jí)入口）

當(dāng)我們的應(yīng)用包含 DataFrame、Dataset 或是 SQL 的時(shí)候，Spark UI 的 SQL 頁(yè)面，就會(huì)展示相應(yīng)的內(nèi)容，（所以hive on spark 不會(huì)有這個(gè)頁(yè)面）如下圖所示:

在這里以 Actions 為單位，記錄著每個(gè) Action 對(duì)應(yīng)的 Spark SQL 執(zhí)行計(jì)劃。我們需要點(diǎn)擊“Description”列中的超鏈接，才能進(jìn)入到二級(jí)頁(yè)面，去了解每個(gè)執(zhí)行計(jì)劃的詳細(xì)信息。

1.4.1 SQL 詳情頁(yè)（二級(jí)入口）

其中Exchange代表的是 Shuffle 操作，Sort是排序，Aggregate表示的是（局部與全局的）數(shù)據(jù)聚合。下面詳細(xì)介紹

1.4.1.1 Metrics 指標(biāo)介紹

1.4.1.1.1 Exchange

如圖兩個(gè) Exchange的詳細(xì)的metrics 指標(biāo)信息如下：（為了展示的指標(biāo)更全，下本分別是spark 3.x和2.x 的版本的展示信息。表格中是竟可能的詳細(xì)的羅列一些信息）

Metrics 整理如下：

Metrics 案例分析：

根據(jù)上圖一，我們觀察到過(guò)濾之后的輔表數(shù)據(jù)大小不足 10MB（7.4MB），這時(shí)我們首先會(huì)想到，對(duì)于這樣的大表 Join 小表，Spark SQL 選擇了 SortMergeJoin 策略是不合理的。

基于這樣的判斷，我們完全可以讓 Spark SQL 選擇 BroadcastHashJoin 策略來(lái)提供更好的執(zhí)行性能。至于調(diào)優(yōu)的具體方法，要么用強(qiáng)制廣播，要么利用 3.x 版本提供的 AQE 特性。

1.4.1.1.2 Sort

相比 Exchange，Sort 的度量指標(biāo)沒(méi)那么多，如圖（為了展示的指標(biāo)更全，下本分別是spark 3.x和2.x 的版本的展示信息。表格中是竟可能的詳細(xì)的羅列一些信息） Metrics 整理如下：

Metrics 案例分析：

“Peak memory total”和“Spill size total”這兩個(gè)數(shù)值，可以指導(dǎo)我們更有針對(duì)性地去設(shè)置 spark.executor.memory、spark.memory.fraction、spark.memory.storageFraction。

日比如。結(jié)合第二張圖 18.8GB 的峰值消耗，以及 12.5GB 的磁盤(pán)溢出這兩條信息，我們可以去思考，當(dāng)前 Executor Memory 是否足夠？如果不夠那么我們可以去=通過(guò)調(diào)整上面的 3 個(gè)參數(shù)，來(lái)加速 Sort 的執(zhí)行性能。

1.4.1.1.3 Aggregate

與 Sort 類似，衡量 Aggregate 的度量指標(biāo)，主要記錄的也是操作的內(nèi)存消耗

Metrics 案例分析：

對(duì)于 Aggregate 操作，Spark UI 也記錄著磁盤(pán)溢出與峰值消耗，即 Spill size 和 Peak memory total。這兩個(gè)數(shù)值也為內(nèi)存的調(diào)整提供了依據(jù)，

以圖二為例，0溢出與 2GB 的峰值消耗，證明當(dāng)前 Executor Memory 設(shè)置，對(duì)于 Aggregate 計(jì)算來(lái)說(shuō)是綽綽有余。

1.5 Jobs 頁(yè)（一級(jí)入口）

Jobs 頁(yè)面也是以 Actions 為粒度，記錄著每個(gè) Action 對(duì)應(yīng)作業(yè)的執(zhí)行情況。具體作業(yè)詳情，可以通過(guò)“Description”頁(yè)面提供的二級(jí)入口鏈接。

1.6 Stages（一級(jí)入口）

Stages 頁(yè)面，更多地是一種預(yù)覽，要想查看每一個(gè) Stage 的詳情，同樣需要從“Description”進(jìn)入 Stage 詳情頁(yè)（二級(jí)頁(yè)面）

1.6.1 Stages 詳情頁(yè)（二級(jí)入口）

除了從Job 的二級(jí)頁(yè)跳轉(zhuǎn)進(jìn)來(lái)，另一種就是這里了?？梢钥吹剿饕?3 大類信息，分別是 Stage DAG、Event Timeline 與 Task Metrics。

如圖：

下面我們沿著“Stage DAG -> Event Timeline -> Task Metrics”的順序，依次講講這些頁(yè)面所包含的內(nèi)容。

1.6.1.1 Stage DAG

點(diǎn)開(kāi)藍(lán)色的“DAG Visualization”按鈕，我們就能獲取到當(dāng)前 Stage 的 DAG，如下圖所示

這里Stage DAG 只是 SQL 頁(yè)面完整 DAG 的一個(gè)子集，而SQL 頁(yè)面的 DAG卻是針對(duì)的是作業(yè)（Job）。所以我們可以不看這里，優(yōu)先去看SQL 的DAG 。

1.6.1.2 Event Timeline

Event Timeline，記錄著分布式任務(wù)調(diào)度與執(zhí)行的過(guò)程中，不同計(jì)算環(huán)節(jié)主要的時(shí)間花銷。圖中的每一個(gè)條帶，都代表著一個(gè)分布式任務(wù)，條帶由不同的顏色構(gòu)成。其中不同顏色的矩形，代表不同環(huán)節(jié)的計(jì)算時(shí)間。

Metrics 整理如下：

Metrics 案例分析：

理想情況下，條帶的大部分應(yīng)該都是綠色的（如圖中所示），也就是任務(wù)的時(shí)間消耗，大部分都是執(zhí)行時(shí)間。不過(guò)，實(shí)際情況并不總是如此。

比如：

有些時(shí)候，藍(lán)色的部分占比較多，或是橙色的部分占比較大。在這些情況下，我們就可以結(jié)合 Event Timeline，來(lái)判斷作業(yè)是否存在調(diào)度開(kāi)銷過(guò)大、或是 Shuffle 負(fù)載過(guò)重的問(wèn)題，從而有針對(duì)性地對(duì)不同環(huán)節(jié)做調(diào)優(yōu)。

比方說(shuō)，如果條帶中深藍(lán)的部分（Scheduler Delay）很多，那就說(shuō)明任務(wù)的調(diào)度開(kāi)銷很重。這個(gè)時(shí)候，我們就需要參考“三足鼎立”的調(diào)優(yōu)技巧，去相應(yīng)地調(diào)整 CPU、內(nèi)存與并行度，從而減低任務(wù)的調(diào)度開(kāi)銷。

再比如：

如果條帶中黃色（Shuffle Write Time）與橙色（Shuffle Read Time）的面積較大，就說(shuō)明任務(wù)的 Shuffle 負(fù)載很重，這個(gè)時(shí)候，我們就需要考慮，有沒(méi)有可能通過(guò)利用 Broadcast Join 來(lái)消除 Shuffle，從而緩解任務(wù)的 Shuffle 負(fù)擔(dān)。

1.6.1.3 Task Metrics

是這個(gè)二級(jí)頁(yè)面里最重要的地方，分位兩項(xiàng)，其中“Tasks” 項(xiàng)目以 Task 為粒度，記錄著每一個(gè)分布式任務(wù)的執(zhí)行細(xì)節(jié)。而“Summary Metrics”則是對(duì)于所有 Tasks 執(zhí)行細(xì)節(jié)的統(tǒng)計(jì)匯總。

1.6.1.3.1 Summary Metrics

首先，我們點(diǎn)開(kāi)“Show Additional Metrics”按鈕，勾選“Select All”，讓所有的度量指標(biāo)都生效，如下圖所示。這么做的目的，在于獲取最詳盡的 Task 執(zhí)行信息 下面詳細(xì)的介紹下各種Metrics 。其中Task Deserialization Time、Result Serialization Time、Getting Result Time、Scheduler Delay 與剛剛表格中的含義相同，不再贅述，這里我們僅整理新出現(xiàn)的 Task Metric

Metrics 整理如下：

Metrics 案例分析：

對(duì)于這些詳盡的 Task Metrics，我們可以非常清晰地量化任務(wù)的負(fù)載分布。根據(jù)不同 Metrics 的統(tǒng)計(jì)分布信息去判定當(dāng)前作業(yè)的不同任務(wù)之間，是相對(duì)均衡，還是存在嚴(yán)重的傾斜。

如果判定計(jì)算負(fù)載存在傾斜，根據(jù)不同傾斜的場(chǎng)景我們就可以選擇不用的方式去處理。

注意：如何估算數(shù)據(jù)在內(nèi)存中大小這一問(wèn)題。 可以借助這里的 Spill（Memory）除以 Spill（Disk），得到“數(shù)據(jù)膨脹系數(shù)”的近似值，記為 Explosion ratio。

有了 Explosion ratio，對(duì)于一份存儲(chǔ)在磁盤(pán)中的數(shù)據(jù)，我們就可以估算它在內(nèi)存中的存儲(chǔ)大小，從而準(zhǔn)確地把握數(shù)據(jù)的內(nèi)存消耗。

1.6.1.3.2 Tasks

Tasks 的不少指標(biāo)，與 Summary 是高度重合的，如下圖所示。唯一的區(qū)別，就是這些指標(biāo)是針對(duì)每一個(gè) Task 進(jìn)行度量的。而上面的Summary 是Executor。

Metrics 整理如下：

Metrics 案例分析：

是 Locality level，也就是本地性級(jí)別。在調(diào)度系統(tǒng)中，每個(gè) Task 都有自己的本地性傾向。結(jié)合本地性傾向，調(diào)度系統(tǒng)會(huì)把 Tasks 調(diào)度到合適的 Executors 或是計(jì)算節(jié)點(diǎn)，盡可能保證“數(shù)據(jù)不動(dòng)、代碼動(dòng)”。

Logs 與 Errors 屬于 Spark UI 的三級(jí)入口，它們是 Tasks 的執(zhí)行日志，詳細(xì)記錄了 Tasks 在執(zhí)行過(guò)程中的運(yùn)行時(shí)狀態(tài)與報(bào)錯(cuò)信息，使用他們可以訊速地定位問(wèn)題。

1.7 頁(yè)面總結(jié)

Executors、Environment、Storage 是詳情頁(yè)，開(kāi)發(fā)者可以通過(guò)這 3 個(gè)頁(yè)面，迅速地了解集群整體的計(jì)算負(fù)載、運(yùn)行環(huán)境，以及數(shù)據(jù)集緩存的詳細(xì)情況；

而 SQL、Jobs、Stages，更多地是一種羅列式的展示，想要了解其中的細(xì)節(jié)，還需要進(jìn)入到二級(jí)入口。里面 涉及的 Metrics 紛繁而又復(fù)雜，需要去結(jié)合日常的開(kāi)發(fā)，去多多摸索與體會(huì)。

柚子快報(bào)邀請(qǐng)碼778899分享：Spark web UI 介紹

http://yzkb.51969.com/

好文閱讀