1

AWSのEMRでのHadoopジョブがS3に保存されないという問題があります。小さいサンプルでジョブを実行すると、ジョブは出力を適切に保存します。同じコマンドを実行すると、完全なデータセットでジョブが再び完了しますが、出力を指定したS3には何も存在しません。

どうやら2009年にAWSEMRにバグがあったようですが、それは「修正」されました。

他の誰かがこの問題を抱えていますか?データがサーバーのどこかに埋め込まれていることを期待して、クラスターはまだオンラインになっています。私がこのデータを見つけることができる場所を誰かが知っているなら、私に知らせてください!

更新:レデューサーの1つからのログを見ると、すべてが正常に見えます。

2012-06-23 11:09:04,437 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Creating new file 's3://myS3Bucket/output/myOutputDirFinal/part-00000' in S3
2012-06-23 11:09:04,439 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' writing to tempfile '/mnt1/var/lib/hadoop/s3/output-3834156726628058755.tmp'
2012-06-23 11:50:26,706 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' is being closed, beginning upload.
2012-06-23 11:50:26,958 INFO org.apache.hadoop.fs.s3native.NativeS3FileSystem (main): Outputstream for key 'output/myOutputDirFinal/part-00000' upload complete
2012-06-23 11:50:27,328 INFO org.apache.hadoop.mapred.Task (main): Task:attempt_201206230638_0001_r_000000_0 is done. And is in the process of commiting
2012-06-23 11:50:29,927 INFO org.apache.hadoop.mapred.Task (main): Task 'attempt_201206230638_0001_r_000000_0' done.

このタスクのノードに接続すると、上記の一時ディレクトリは空になります。

更新2:HadoopでAmazon S3とS3nの違いを読んだ後、問題が出力パスとして「s3n://」ではなく「s3://」を使用しているのではないかと思います。私の小さなサンプル(うまく保存されている)と完全な仕事の両方で、「s3://」を使用しました。これが私の問題になる可能性があるかどうかについて何か考えはありますか?

アップデート3: AWSのEMRでは、s3://とs3n://の両方がS3ネイティブファイルシステムにマッピングされていることがわかります(AWS EMRドキュメント)。

アップデート4:サーバーとレデューサーの数を増やすたびに、このジョブをさらに2回再実行しました。これら2つのうちの最初のものは、89/90レデューサー出力がS3にコピーされて終了しました。90番目は、ログによると正常にコピーされたと述べましたが、AWSサポートはファイルがそこにないと言います。彼らはこの問題をエンジニアリングチームにエスカレートしました。さらに多くのレデューサーとサーバーを使用した2回目の実行では、すべてのデータがS3にコピーされて実際に終了しました(ありがたいことに!)。ただし、奇妙な点の1つは、一部のレデューサーがデータをS3にコピーするのにFOREVERを使用することです。これらの新しい実行の両方で、出力がS3にコピーするのに1〜2時間かかったレデューサーがありましたが、他のレデューサーは最大10分しかかかりませんでした。 (ファイルは3GB程度です)。これは、EMRで使用されているS3NativeFileSystemの問題に関連していると思います(たとえば、長い間ぶら下がっています-もちろん請求されます。アップロードが成功したとされるが、アップロードされない)。最初にローカルHDFSにアップロードし、次にS3にアップロードしましたが、この面でも問題があります(AWSエンジニアリングチームのレビュー待ち)。

TLDR; AWSEMRを使用してS3に直接保存するのはバグがあるようです。彼らのエンジニアリングチームが調査しています。

4

1 に答える 1

1

これはAWS側のバグであることが判明し、最新のAMIバージョン2.2.1で修正されました。これらのリリースノートで簡単に説明されています。

AWSから得た長い説明は、レデューサーファイルがS3のブロック制限(つまり5GB?)を超える場合、マルチパートが使用されますが、適切なエラーチェックが行われていなかったため、それが時々機能する理由です、および他の場合はそうではありません。

これが他の誰かのために続く場合は、私のケース番号62849531を参照してください。

于 2012-09-12T00:53:53.343 に答える