エグゼキューターのメモリが不足すると、Sparkはそれらを除去し、タスクを再試行します。 ジョブの処理速度が低下し、そしてエラーを繰り返した後、ステージとジョブが失敗します。
ジョブが失敗したり、Executor が削除されたりしても、コンピューティングのイベント ログにスポット インスタンスまたはプリエンプティブル インスタンスの損失や自動スケーリングが表示されない場合は、このページを使用してください。 イベント ログを確認するには、「ジョブまたは Executor の削除の失敗」を参照してください。 ステージが完了しても遅く、スピル(こぼれ)が見える場合は、Skew and spillを参照してください。
メモリの問題の確認
メモリの問題はしばしば以下のようなエラーを引き起こします:
SparkException: Job aborted due to stage failure: Task 3 in stage 0.0 failed 4 times, most recent failure: Lost task 3.3 in stage 0.0 (TID 30) (10.139.64.114 executor 4): ExecutorLostFailure (executor 4 exited caused by one of the running tasks) Reason: Remote RPC client disassociated. Likely due to containers exceeding thresholds, or network issues. Check driver logs for WARN messages.
これらのエラーはしばしば汎用的なものであり、他の問題が原因で発生することがあります。 メモリの問題が疑われる場合は、コアあたりのメモリを倍にして問題が解決するか確認してください。
例えば、ワーカータイプが4コアでメモリ16GBの場合、4コアでメモリ32GBのワーカータイプに切り替えます。 これにより、コアあたり4GBではなく8GBになります。 重要なのはメモリとコアの比率であって、総メモリではありません。 もし作業が失敗するまでに時間がかかったり、全く失敗しなかったりする場合、メモリが原因かもしれません。
メモリが増えれば問題が解決するなら、より大きなワーカータイプを使い続けてください。 もしうまくいかない場合、または追加コストが高すぎる場合は、次のセクションで考えられる原因を確認してください。
考えられる原因
記憶障害には多くの原因が考えられます。 まずは以下の一般的な原因から始めましょう。
- シャッフルパーティションが少なすぎる。
spark.sql.shuffle.partitionsをautoに設定して、Sparkがシャッフルパーティションの数を決定できるようにします。 AQE構成を参照してください。 - 大規模なブロードキャスト。 大きなテーブルでブロードキャスト結合のヒントを確認し、ランタイムブロードキャストの閾値を確認してください。 AQE構成を参照してください。
- UDFs. UDFを実行する各タスクは、そのパーティション内のすべてのデータをメモリにロードすることがあります。 UDFをネイティブ関数で書き直すか、適用前に再パーティションを行ってください。 「低速 UDF」を参照してください。
-
PARTITION BYのないウィンドウ関数。 節を追加して、PARTITION BYがデータセット全体にまたがらないようにしてください。 1 つのタスクを持つ Long Spark ステージを参照してください。 - スキュー。 ステージの サマリーメトリクスでスキューを確認してください。 Skewを参照してください。 ジョインについては、スキュージョインを動的に処理するを参照してください。
- ストリーミング状態。 ストリーミング状態を保持するクエリの場合は、RocksDBの状態ストアを使い、メモリ使用量を制限してください。 Cap RocksDB のメモリ使用量を参照してください。