問題

工作失敗的ExecutorLostFailure錯誤消息。

ExecutorLostFailure(執行人< 1 >退出正在運行的任務之一所致)原因:遺囑執行人心跳超時後< 148564 >

導致

的ExecutorLostFailure錯誤信息意味著一個執行人的Apache火花集群已經丟失。這是一個通用的錯誤消息,可以有一個以上的根源。在本文中,我們將看看如何解決問題根源時由於執行人耗盡內存

假設你的遺囑執行人有太多數據處理和執行程序中可用的內存量不足以處理的數據量,那麼這個問題可能發生。例如如果集群的遺囑執行人24 gb容量和如果累積的數據量大小對應於所有正在執行的任務執行人大於24 gb,那麼這個問題可能發生

你如何確定伯父執行人迷失的原因嗎?

1. 打開火花UI。
2. 點擊階段。
3. 點擊失敗的階段。
4. 單擊描述對應於失敗的階段。
5. 審查的底部階段的細節頁麵。
6. 上的任務列表錯誤列。

錯誤信息描述為什麼特定的任務失敗了。如果你看到一條錯誤消息,表示內存不足,或類似的錯誤java.lang.OutOfMemoryError這意味著任務失敗了,因為遺囑執行人耗盡內存。

解決方案

當一個執行人失敗是由於內存不足,你應該檢查下列事項。

有數據傾斜嗎?

檢查數據是否同樣分布在執行人,或者如果有任何傾斜的數據。

你可以找到這通過檢查階段總結表上的階段的細節頁麵的UI火花。

如果存在數據傾斜,如果這是唯一的遺囑執行人,更多的數據,您需要解決斜防止執行人耗盡內存。

在大多數情況下自適應查詢執行(AQE)自動檢測數據傾斜和解決這個問題。然而,也有一些邊緣AQE可能無法正確檢測數據傾斜的情況。請檢查為什麼沒有AQE檢測我的數據傾斜?(AWS|Azure|GCP更多信息)。

解決數據傾斜的如果你有麻煩,你可以嚐試增加分區的數量或明確提及斜暗示的解釋如何指定斜在數據集和DataFrame-based加入命令提示嗎篇文章。

一個分區是當兩個傾斜(分區大小> skewedPartitionFactor *值分區大小)和(分區大小> skewedPartitionThresholdInBytes)是真的。

例如,給定一個值分區大小為200 MB,如果任何分區超過1 GB (200 MB * 5(5是默認的skewedPartitionFactor值)),它被認為是傾斜的。在這個例子中,如果你有一個分區大小900 MB的它不會被視為傾斜使用默認設置。

現在說你的應用程序代碼(就像很多轉換數據爆炸笛卡爾連接,等等)。如果你執行大量的轉換,你可以壓倒執行人,即使分區不是通常認為是傾斜的。

使用我們的示例違約,你可能會發現,一個900 MB的分區是太多成功的過程。如果是這樣的話,你應該減少skewedPartitionFactor價值。通過降低這個值為4,然後係統認為任何超過800 MB的分區是傾斜並自動分配適當的傾斜提示。

請審查AQE文檔動態處理斜加入(AWS|Azure|GCP更多信息)。

執行程序能夠就夠了嗎?

如果數據是均勻分布在所有執行器,你還看到內存錯誤,執行程序沒有足夠的資源來處理你正試圖運行的負載。

增加橫向通過增加工人的數量和/或增加垂直通過選擇一個工作類型與更多的內存創建集群。

這是一個正確配置流媒體工作嗎?

如果沒有明顯的數據傾斜,但遺囑執行人仍讓太多數據過程中,您應該使用maxFilesPerTrigger和/或觸發頻率設置,以減少處理的數據量在任何時候。

減少執行人還有助於減少內存上的負載要求,稍高的延遲。以換取延遲時間的增加,流流事件更加可控的方式處理工作。穩定的事件流是可靠地處理每一個微觀的批處理。

請檢查優化與.trigger流交易文章以獲取更多信息。您還應該檢查火花結構化流媒體編程指南文檔輸入源和觸發器。

如果你想增加處理的速度,你需要增加集群的執行人。你也可以重新分配輸入流DataFrame,所以任務的數量小於或等於集群中核心的數量。