1

これは私のステップです：

  1. Spark アプリを EMR クラスターに送信する
  2. ドライバーが起動し、Spark-ui が表示されます (ステージはまだ作成されていません)
  3. ドライバーは、s3 から約 3000 個のパーツを含む orc ファイルを読み取り、いくつかの変換を行って、それを s3 に保存します。
  4. 保存を実行すると、spark-ui にいくつかのステージが作成されますが、ステージが spark-ui に表示されるまでに非常に時間がかかります。
  5. ステージが出現し実行開始

ステップ 4 で大幅な遅延が発生するのはなぜですか? この間、クラスターは明らかに何かを待っており、CPU 使用率は 0% です。

ありがとう

4

2 に答える 2

2

その利点にもかかわらず、S3 はファイル システムではなく、通常は実際のファイル システムを念頭に置いて設計されている複雑なバイナリ形式を操作するには、最適な選択肢ではありません。多くの場合、セカンダリ タスク (メタデータの読み取りなど) は、実際のデータ フェッチよりもコストがかかります。

于 2017-01-09T22:54:58.860 に答える
2

おそらく3と4の間のコミットプロセスです。Hadoop MR および Spark コミッターは、名前変更が O(1) アトミック操作であると想定し、作業のアトミック コミットを行うためにそれに依存します。S3 では、ディレクトリ内の複数のファイルが関係する場合、名前の変更は O(データ) であり、非アトミックです。CPU 負荷が 0 であることは問題です。クライアントは S3 からの応答を待っているだけで、S3 は 6 ～ 10 MB/秒で内部的に COPY を実行しています。

HADOOP-13345 では、S3 で 0-rename コミットを行う作業が進行中です。今のところ、Databricks の Direct Committer という、有名だが興味深い方法で失敗するものを探すことができます。

もう 1 つ: コミットに「アルゴリズム 2」を使用していることを確認してください。アルゴリズム 1 は、最終的なジョブ マスター コミットでより多くの名前変更を行うためです。Hadoop 2.7 での ORC/Parquet パフォーマンスの完全な推奨設定は次のとおりです (use s3a: urls とともに):

spark.sql.parquet.filterPushdown true
spark.sql.parquet.mergeSchema false
spark.hadoop.parquet.enable.summary-metadata false

spark.sql.orc.filterPushdown true
spark.sql.orc.splits.include.file.footer true
spark.sql.orc.cache.stripe.details.size 10000

spark.sql.hive.metastorePartitionPruning true
spark.speculation false
spark.hadoop.mapreduce.fileoutputcommitter.algorithm.version 2
spark.hadoop.mapreduce.fileoutputcommitter.cleanup.skipped true
于 2017-01-10T13:39:40.083 に答える