為什麼我的 Spark 作業在 Amazon EMR 中失敗?
我想對 Amazon EMR 中失敗的 Apache Spark 作業進行疑難排解。
解決方法
應用程式失敗
「Spark shuffle block fetch」執行時期例外狀況
當 Amazon EMR 中的執行程式工作節點處於運作狀態不佳狀態時,您可能會收到以下錯誤:
「ERROR ShuffleBlockFetcherIterator: Failed to get block(s) from ip-192-168-14-250.us-east-2.compute.internal:7337
org.apache.spark.network .client.ChunkFetchFailureException: Failure while fetching StreamChunkId[streamId=842490577174,chunkIndex=0]: java.lang.RuntimeException: Executor is not registered (appId=application_1622819239076_0367, execId=661)」
當工作節點的磁碟使用率超過 90% 的使用率臨界值時,YARN NodeManager 運作狀態服務會將節點識別為 UNHEALTHY (運作狀態不佳)。Amazon EMR 會將運作狀態不佳的節點納入拒絕清單,且 YARN 容器不會配置到運作狀態不佳的節點。
若要疑難排解此問題,請採取以下動作:
- 從 Amazon EMR 叢集主節點檢閱資源管理員日誌,以找出運作狀態不佳的工作節點。如需更多資訊,請參閱由於運作狀態不佳節點造成的高磁碟使用率章節,其位於 如何解決 Amazon EMR 上 Spark 的「ExecutorLostFailure: Slave lost」錯誤?中
- 檢查受影響節點的磁碟空間使用率,檢閱耗用磁碟空間的檔案,並執行資料復原,讓節點恢復為良好狀態。如需更多資訊,請參閱為什麼我的 Amazon EMR 叢集中的核心節點磁碟空間會耗盡?
「NoSuchElementException」執行時期例外狀況
當應用程式碼和 SparkContext 初始化中發生問題時,您可能會收到以下例外狀況:
「ERROR [Executor task launch worker for task 631836] o.a.s.e.Executor:Exception in task 24.0 in stage 13028.0 (TID 631836) java.util.NoSuchElementException: None.get」
若要解決此問題,請確認同一個工作階段中沒有多個 SparkContext 作業處於作用中狀態。您一次只能有一個作用中的 SparkContext。如果您想要初始化另一個 SparkContext,則必須先停止作用中的作業,再建立新的作業。
如需更多資訊,請參閱 Spark 網站上的 SparkContext。
「Container exit code 137」錯誤
當任務超過已配置的實體記憶體時,YARN 容器會停止該任務,且您會收到以下錯誤:
「Container killed on request.Exit code is 137」
當您有隨機分區、不一致的分區大小,或大量執行程式核心時,就會收到此錯誤。
檢閱 Spark 驅動程式日誌中的錯誤詳細資訊,以判斷錯誤原因。如需更多資訊,請參閱如何存取 Amazon EMR 叢集上的 Spark 驅動程式日誌?
來自驅動程式日誌的錯誤範例:
ERROR YarnScheduler: Lost executor 19 on ip-10-109-##-###.aws.com : Container from a bad node: container_1658329343444_0018_01_000020 on host: ip-10-109-##-###.aws.com . Exit status: 137.Diagnostics:Container killed on request. Exit code is 137 Container exited with a non-zero exit code 137. Killed by external signal Executor container 'container_1658329343444_0018_01_000020' was killed with exit code 137. To understand the root cause, you can analyze executor container log. # java.lang.OutOfMemoryError: Java heap space # -XX:OnOutOfMemoryError="kill -9 %p" # Executing /bin/sh -c "kill -9 23573"...
前述錯誤堆疊追蹤顯示執行程式沒有足夠的可用記憶體來繼續處理資料。此錯誤可能發生在不同的作業階段中,包括窄轉換與寬轉換。
若要解決此問題,請採取以下動作:
- 增加執行程式記憶體。
**注意:**執行程式記憶體包含執行任務所需的記憶體和額外負荷記憶體。這些總和不得大於 Java Virtual Machine (JVM) 的大小和 YARN 的容器大小上限。 - 新增更多 Spark 分區。
- 增加隨機分區的數量。
- 減少執行程式核心數量。
如需更多資訊,請參閱如何解決 Amazon EMR 上 Spark 中的「Container killed on request.Exit code is 137」錯誤?
Spark 作業處於停滯狀態且未完成
Spark 作業可能因多種原因而卡住。例如,Spark 驅動程式程序變更或遺失執行程式容器都可能讓作業停止。
當您有高磁碟空間使用率,或將 Spot 執行個體用於叢集節點且 AWS 終止 Spot 執行個體時,Spark 作業可能會卡住。如需更多資訊,請參閱如何解決 Amazon EMR 上 Spark 中的「ExecutorLostFailure: Slave lost」錯誤?中
若要疑難排解此問題,請採取以下動作:
- 檢閱 Spark 驅動程式或驅動程式日誌中的例外狀況。
- 檢查 YARN 節點清單中的運作狀態不佳節點。當核心節點的磁碟使用率超過臨界值時,YARN Node Manager 運作狀態服務會將節點標示為 UNHEALTHY (運作狀態不佳)。Amazon EMR 會將運作狀態不佳的節點加入拒絕清單,並防止 YARN 將容器配置到這些節點。
- 監控磁碟空間使用率,並設定 Amazon Elastic Block Store (Amazon EBS) 磁碟區,讓 Amazon EMR 叢集工作節點的使用率維持在 90% 以下。
「Heartbeat communication」錯誤
Spark執行程式會依照 spark.executor.heartbeatInterval 屬性指定的間隔,將活動訊號傳送至 Spark 驅動程式。當發生長時間垃圾回收暫停時,執行程式可能無法傳送活動訊號。驅動程式會停止未在指定值內傳送活動訊號的執行程式,且您會收到以下錯誤:
「WARN Executor: Issue communicating with driver in heartbeater org.apache.spark.rpc.RpcTimeoutException: Futures timed out after [10000 milliseconds].This timeout is controlled by spark.executor.heartbeatInterval」
當執行程式處理資料時,記憶體限制或記憶體不足 (OOM) 問題會導致逾時例外狀況。這些問題也會影響垃圾回收程序,並可能造成進一步延遲。
若要解決活動訊號通訊錯誤,請使用以下其中一個選項:
- 增加執行程式記憶體。另外,也請根據應用程式程序重新分割您的資料。
- 調整垃圾回收。如需更多資訊,請參閱 Apache Spark 網站上的垃圾回收調整。
- 增加 spark.executor.heartbeatInterval 的間隔。
- 指定較長的 spark.network.timeout 期間。
「ExecutorLostFailure」錯誤
當高磁碟使用率導致核心或任務節點終止時,您可能會收到以下錯誤:
「ExecutorLostFailure "Exit status: -100.Diagnostics: Container released on a *lost* node」
當節點因長時間 CPU 使用率偏高或可用記憶體不足而沒有回應時,您也可能會收到前述錯誤。如需疑難排解步驟,請參閱如何解決 Amazon EMR 中的「Exit status: -100.Diagnostics: Container released on a lost node」錯誤?
**注意:**當您將 Spot 執行個體用於叢集節點且 AWS 終止 Spot 執行個體時,也可能發生此錯誤。Amazon EMR 叢集會佈建隨需執行個體以替換已終止的 Spot 執行個體,而應用程式可能會自行復原。如需更多資訊,請參閱 Amazon EMR 上適用於彈性和恢復能力的 Spark 增強功能。
「SQL connection timeout」錯誤
當資料庫連線嘗試因網路逾時而失敗時,您會收到以下錯誤:若要解決此問題,請確認資料庫主機可以從您的 Amazon EMR 叢集安全群組接收連接埠 1433 上的傳入連線。
另外,也請檢閱 SQL 資料庫所設定的資料庫平行連線數上限,以及資料庫執行個體類別的記憶體配置。資料庫連線也會耗用記憶體。如果使用率偏高,請檢閱資料庫組態和允許的連線數。如需更多資訊,請參閱資料庫連線數上限。
Amazon S3 例外狀況
HTTP 503「Slow Down」
當您超過字首的 Amazon Simple Storage Service (Amazon S3) 請求速率時,就會發生 HTTP 503 例外狀況。503 例外狀況不一定表示會發生失敗。不過,如果您解決此例外狀況,則可能會改善應用程式效能。
如需更多資訊,請參閱為什麼我在 Amazon EMR 上的 Spark 或 Hive 作業失敗,並出先 HTTP 503「Slow Down」AmazonS3Exception?
HTTP 403「Access Denied」
HTTP 403 錯誤是由不正確或無效的憑證所造成,包括以下憑證:
- 您未在應用程式碼中指定的憑證或角色。
- 附加至 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體設定檔角色的政策。
- 適用於 Amazon S3 的 Amazon Virtual Private Cloud (Amazon VPC) 端點。
- Amazon S3 來源和目的地儲存貯體政策。
若要解決 403 錯誤,請確認相關 AWS Identity and Access Management (IAM) 角色或政策允許存取 Amazon S3。如需更多資訊,請參閱為什麼我的 Amazon EMR 應用程式失敗,並出現 HTTP 403「Access Denied」AmazonS3Exception?
HTTP 404「Not Found」
當應用程式預期在 Amazon S3 中找到物件,但在提出請求時找不到該物件時,您會收到「HTTP 404 Not found」錯誤。
此錯誤可能由以下原因造成:
- 不正確的 Amazon S3 路徑。
- 應用程式外部的程序移動或刪除了檔案。
- 某個操作造成最終一致性問題,例如覆寫。
如需更多資訊,請參閱為什麼我的 Amazon EMR 應用程式失敗,並出現 HTTP 404「Not Found」AmazonS3Exception?
- 語言
- 中文 (繁體)

相關內容
已提問 3 年前
已提問 2 年前
已提問 3 年前