Apache Spark UI を使用したデバッグ
この記事では、 Apache Sparkアプリケーションの内部を覗くために使用できるさまざまなデバッグオプションの概要を説明します。 注目すべき3つの重要な場所は次のとおりです。
- Spark UI
- ドライバーログ
- エグゼキューター logs
Spark UI を使用したコストとパフォーマンスの問題の診断については、「 Spark UI を使用したコストとパフォーマンスの問題の診断 」を参照してください。
Spark UI
ジョブを開始すると、Spark UI にアプリケーションで何が起こっているかに関する情報が表示されます。 Spark UIにアクセスするには、添付のコンピュートをクリックします。
「ストリーミング」タブ
Spark UIに到達すると、このコンピュートでストリーミング ジョブが実行されている場合は、ストリーミング タブが表示されます。このコンピュートで実行中のストリーミング ジョブがない場合、このタブは表示されません。 ドライバー ログにスキップして、ストリーミング ジョブの開始中に発生した可能性のある例外を確認する方法を確認できます。
このページで最初に探すのは、ストリーミングアプリケーションがソースから入力イベントを受信しているかどうかを確認することです。 この場合、ジョブが 1000 イベント/秒を受信していることがわかります。
TextFileStreamの場合、ファイルは入力されるため、入力イベントの # は常に 0 です。このような場合は、ノートブックの [完了したバッチ ] セクションを見て、詳細情報を見つける方法を理解できます。
複数の入力ストリームを受信するアプリケーションがある場合は、[ 入力レート ] リンクをクリックすると、各レシーバーで受信したイベントの # が表示されます。
処理時間
下にスクロールしながら、[ Processing Time] (処理時間 ) のグラフを見つけます。 これは、ストリーミングジョブのパフォーマンスを理解するための重要なグラフの 1 つです。 一般的な経験則として、各バッチをバッチ処理時間の80%以内に処理できれば良いでしょう。
このアプリケーションの場合、バッチ間隔は 2 秒でした。 平均処理時間は 450 ミリ秒で、バッチ間隔をはるかに下回っています。 平均処理時間がバッチ間隔に近いか大きい場合、ストリーミングアプリケーションがキューイングを開始し、すぐにバックログが発生し、最終的にストリーミングジョブがダウンする可能性があります。
完了したバッチ
ページの終わりに向かって、完了したすべてのバッチのリストが表示されます。 このページには、完了した最後の 1000 バッチに関する詳細が表示されます。 テーブルから、各バッチで処理されたイベントの # とその処理時間を取得できます。 バッチの 1 つで何が起こったかについて詳しく知りたい場合は、バッチのリンクをクリックしてバッチの詳細ページにアクセスできます。
バッチ詳細ページ
このページには、バッチについて知りたいすべての詳細があります。 次の 2 つの重要な点があります。
- 入力: バッチへの入力に関する詳細が表示されます。 ApacheKafkaSparkこの場合、このバッチの 構造化ストリーミングによって読み取られた トピック、パーティション、およびオフセットに関する詳細が含まれます。TextFileStream の場合は、このバッチで読み取られたファイル名の一覧が表示されます。 これは、テキスト・ファイルから読み取っているストリーミング・アプリケーションのデバッグを開始するのに最適な方法です。
- 処理中: このバッチ中に行われた処理に関するすべての詳細が記載されたジョブ ID へのリンクをクリックできます。
ジョブの詳細ページ
ジョブの詳細ページには、DAG の視覚化が表示されます。 これは、各バッチの操作と依存関係の順序を理解するのに非常に役立ちます。 この場合、Kafka ダイレクト ストリームからのバッチ読み取り入力に続いてフラット マップ操作、次にマップ操作が行われたことがわかります。 次に、結果のストリームを使用して、updateStateByKey を使用してグローバル状態を更新しました。 (グレーのボックスはスキップされたステージを表しています。 Spark は、再計算の必要がない一部のステージをスキップできるほどスマートです。 データがチェックポイントまたはキャッシュされている場合、Spark はそれらのステージの再計算をスキップします。 この場合、これらのステージは、 updateStateBykeyによる前のバッチへの依存関係に対応します。 Spark構造化ストリーミングは内部的にストリームをチェックポイントし、前のバッチに依存するのではなくチェックポイントから読み取るため、灰色のステージとして表示されます。
ページの下部には、このバッチに対して実行されたジョブのリストも表示されます。 説明のリンクをクリックすると、タスク レベルの実行をさらに詳しく調べることができます。
タスクの詳細ページ
これは、Spark UI Sparkアプリケーションの から実行できる最も詳細なデバッグ レベルです。このページには、このバッチに対して実行されたすべてのタスクが表示されます。 ストリーミング アプリケーションのパフォーマンスの問題を調査している場合、このページには、実行されたタスクの数とそれらが実行された場所 (どのエグゼキューター) やシャッフル情報などの情報が表示されます
タスクがコンピュート内の複数のエグゼキューター (ノード) で実行されることを確認し、処理中に十分な並列処理を確保します。 レシーバーが 1 人の場合、コンピュートに複数のエグゼキューターがあっても、1 人のエグゼキューターだけがすべての作業を行っている場合があります。
スレッドダンプ
スレッド・ダンプは、JVM のスレッド状態のスナップショットを示します。
スレッドダンプは、特定のハングアップしたタスクや実行速度の遅いタスクをデバッグする場合に便利です。 Spark UI で特定のタスクのスレッドダンプを表示するには:
- 「ジョブ」 タブをクリックします。
- 「ジョブ」 テーブルで、表示したいスレッド・ダンプに対応するターゲット・ジョブを見つけ、「 説明 」列のリンクをクリックします。
- ジョブの 「ステージ」 テーブルで、表示したいスレッド・ダンプに対応するターゲット・ステージを見つけ、「 説明 」列のリンクをクリックします。
- ステージの タスク リストで、表示するスレッドダンプに対応するターゲットタスクを見つけ、その タスク ID と エグゼキューター ID の値をメモします。
- エグゼキューター タブをクリックします。
- エグゼキューター テーブルで、前にメモした エグゼキューター ID 値に対応する エグゼキューター ID 値を含む行を見つけます。その行で、[ スレッド ダンプ ] 列のリンクをクリックします。
- [エグゼキューターのスレッド ダンプ ] テーブルで、[ スレッド名 ] 列に TID が含まれ、その後に前にメモした タスク ID 値が続く行をクリックします。(タスクの実行が終了した場合、一致するスレッドは見つかりません)。 タスクのスレッド・ダンプが表示されます。
スレッド ダンプは、ドライバーがハングしているように見える (Spark の進行状況バーが表示されないなど) や、クエリの進行状況が進まない (Spark の進行状況バーが 100% でスタックしているなど) 問題のデバッグにも役立ちます。 Spark UI でドライバーのスレッド ダンプを表示するには:
- エグゼキューター タブをクリックします。
- エグゼキューター テーブルの ドライバー 行で、[ スレッド ダンプ ] 列のリンクをクリックします。ドライバーのスレッド ダンプが表示されます。
ドライバー ログ
ドライバー ログは、次の 2 つの目的で役立ちます。
- 例外: Spark UI に [ストリーミング] タブが表示されない場合があります。 これは、何らかの例外のためにストリーミング・ジョブが開始されなかったためです。 ドライバー ログをドリルダウンして、例外のスタック トレースを確認できます。 場合によっては、ストリーミング ジョブが正常に開始されている可能性があります。 ただし、すべてのバッチが[完了したバッチ]セクションに移動することはありません。 それらはすべて処理中または失敗状態である可能性があります。 このような場合も、ドライバー ログは、根本的な問題の性質を理解するのに便利です。
- 印刷: DAG の一部としての印刷ステートメントは、ログにも表示されます。
エグゼキューター logs
エグゼキューターのログは、特定のタスクが誤動作していることを確認し、特定のタスクのログを表示したい場合に役立つことがあります。 上記のタスク詳細ページから、タスクが実行されたエグゼキューターを取得できます。 それがわかったら、コンピュートUIページに移動し、#ノードをクリックしてからマスターをクリックできます。 マスター ページには、すべてのワーカーが一覧表示されます。 疑わしいタスクが実行されたワーカーを選択してから、log4j 出力を取得できます。