スパーク：ジョブ

Question

間の長い遅延だから我々は、データを抽出して、いくつかの広大なデータ変換を行うと、いくつかの異なるファイルに書き込みスパークジョブを実行しています。すべてが正常に実行されていますが、リソース集約的なジョブの終了と次のジョブの開始の間にランダムな広範な遅延が発生しています。

以下の画像では、我々は、私は次のジョブが午後五時37分02秒の周りにスケジュールすることを期待してる意味し、完了するために15分を要した午前17時22分02秒で予定されていたその仕事を見ることができます。しかし、次の仕事は仕事の成功後+4時間である22:05:59に予定されていた。

、私は次の仕事のスパークUIを掘り下げた場合、それは< 1秒スケジューラの遅延を示しました。だから私はこの4時間の長い遅延がどこから来ているのか混乱している。

（Hadoopの2とスパーク1.6.1）

更新：

を、私は以下のDavidさんの答えはIOのOPSはスパークに扱われるかについてのスポットであることを確認することができますビットです予期しない。 （それは注文考慮および/または他の操作を書き込む前にカーテンの後ろに「収集」ん。基本的に、そのファイルの書き込みに理にかなっている）しかし、私は、ビットI/O時間は、ジョブの実行時間に含まれていないという事実によってdiscomfortedよ。私は、クエリはまだでも、すべてのジョブが成功していると実行されていますが、全くそれに飛び込むことができないとして、あなたがスパークUIの「SQL」タブでそれを見ることができますね。

私はそこに改善するためのより多くの方法があるが、確信している二つの方法は私のために十分であったの下：

2. は、多くの場合、偽

Answer 1

I/O操作にparquet.enable.summary-metadataを設定するファイル数を減らしますマスターノードで発生する重大なオーバーヘッドが発生します。この作業は並列化されていないため、かなり時間がかかります。ジョブではないので、リソースマネージャのUIに表示されません。マスターノードによって行われてI/Oタスクのいくつかの例としては、

• スパークは、多くの場合、マスターノード
で発生
• マスターノードを使用してファイルを移動し、その後、一時的なS3のディレクトリにテキストファイルの読み込みを書きます
• 寄木細工のファイルを作成する場合、マスターノードは、これらの問題は、糸の設定を微調整したり、コードを再設計することによって解決することができ、スキーマ

をチェックするために、すべてのファイルにポストライトをスキャンします。ソースコードを提供している場合は、問題を特定できる可能性があります。

Discussion of writing I/O Overhead

Discussion of reading I/O Overhead