web-dev-qa-db-ja.com

Spark in AWS： "S3AbortableInputStream：すべてのバイトがS3ObjectInputStreamから読み取られたわけではありません"

私はPySparkアプリケーションを次の場所で実行しています：

  • emr-5.8.0
  • Hadoopディストリビューション：Amazon 2.7.3
  • Spark 2.2.0

非常に大きなクラスターで実行しています。アプリケーションは、s3からいくつかの入力ファイルを読み取ります。これらの1つがメモリに読み込まれ、すべてのノードにブロードキャストされます。もう1つは、SparkFiles機能を使用して、クラスター内の各ノードのディスクに配布されます。アプリケーションは機能しますが、パフォーマンスが大きいジョブの予想よりも遅くなります。ログファイルを見ると、次の警告がほぼ常に繰り返されています。

WARN S3AbortableInputStream: Not all bytes were read from the S3ObjectInputStream, aborting HTTP connection. This is likely an error and may result in sub-optimal behavior. Request only the bytes you need via a ranged GET or drain the input stream after use.

これは、メモリにロードされてブロードキャストされたファイルへのアクセスに関するメッセージの後に発生する傾向があります。この警告は警告するものですか？それを避ける方法は？

Googleの検索では、ネイティブのHadoopアプリケーションでこの警告に対処している人が何人か出てきますが、SparkまたはPySparkには何も見つかりませんでした。

ありがとう！

hadoopapache-sparkpysparkhdfs
8
Danny

それを無視します。 AWS SDKの最新バージョンでは、入力ストリームでabort()を呼び出すと、GB数のファイルを移動するときに必要な場合でも、常に通知されます。小さなファイルの場合、はい、EOFを読み取ることは正しいことですが、大きなファイルの場合はできません。

参照： SDKが「S3ObjectInputStreamからすべてのバイトを読み取ったわけではない」と繰り返し不平を言っている

これが頻繁に見られ、ORCやParquetなどの列データ形式で作業している場合は、プロパティfs.s3a.experimental.fadviseを次のように設定して、入力ストリームをランダムに切り替えますIO over順次random。これにより、ファイル全体を読み取ろうとするのをやめ、代わりに小さなブロックのみを読み取ることを防ぎます。完全なファイル読み取り（.gzファイルを含む）には非常に悪いですが、列IOを変換します。

S3AのHadoop 3.xの最後のクローズ時の小さな修正 HADOOP-14596 に注意してください。バックポートするかどうかは、EMRチーム次第です。

+ S3Aトラブルシューティングドキュメントにテキストを追加します。 ASFはこの問題を伴うhadoopリリースを出荷したことはありませんが、人々がAWS SDKと組み合わせてプレイしている場合（非常に壊れやすい）、これが表面化する可能性があります

13
Steve Loughran

注：AWSはs3aを提供していないため、これはEMR以外のインストールにのみ適用されます。

警告を無視するか、Steve Loughranの回答に従って設定を介して入力ストリームを変更する前に、s3://bucket/path表記を使用していないことを確認してください。

Spark 2から始めて、s3a://bucket/pathを介してs3aプロトコルを活用する必要があります。これは、表示されている警告に対処し（私たちにとっては）、S3の速度を大幅に向上させます）相互作用 違いの内訳の詳細についてはこの回答を参照してください 。

1
bsplosion