Ich habe ein Problem, bei dem mein Hadoop-Auftrag in AWS EMR nicht in S3 gespeichert wird. Wenn ich den Job für ein kleineres Beispiel ausführe, speichert der Job die Ausgabe einwandfrei. Wenn ich denselben Befehl auf meinem gesamten Datensatz ausführe, wird der Auftrag erneut ausgeführt, aber auf S3 ist nichts vorhanden, für das ich meine Ausgabe angegeben habe.

Anscheinend gab es eineFehler mit AWS EMR im Jahr 2009, aber es wurde "behoben".

Hat noch jemand dieses Problem? Ich habe meinen Cluster immer noch online und hoffe, dass die Daten irgendwo auf den Servern vergraben sind. Wenn jemand eine Idee hat, wo ich diese Daten finden kann, lass es mich wissen!

Aktualisieren: Wenn ich mir die Protokolle von einem der Reduzierer ansehe, sieht alles gut aus:

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.

Wenn ich mich mit dem Knoten dieser Aufgabe verbinde, ist das erwähnte temporäre Verzeichnis leer.

Update 2: Nach dem LesenUnterschied zwischen Amazon S3 und S3n in HadoopIch frage mich, ob mein Problem "s3: //" anstelle von "s3n: //" als Ausgabepfad verwendet. In meinem kleinen Beispiel (das gut speichert) und meinem vollständigen Job habe ich "s3: //" verwendet. Irgendwelche Gedanken, ob dies mein Problem sein könnte?

Update 3: Ich sehe jetzt, dass in AWSs EMR s3: // und s3n: // beide dem systemeigenen S3-Dateisystem zugeordnet sind (AWS EMR-Dokumentation).

Update 4: Ich habe diesen Job noch zweimal wiederholt, wobei ich jedes Mal die Anzahl der Server und Reduzierer erhöht habe. Die erste dieser beiden Ausgaben endete damit, dass 89/90 Reduziererausgaben nach S3 kopiert wurden. Die 90. gab an, dass das Kopieren gemäß den Protokollen erfolgreich war, aber der AWS-Support meldet, dass die Datei nicht vorhanden ist. Sie haben dieses Problem an ihr Ingenieurteam weitergeleitet. Mein zweiter Lauf mit noch mehr Reduzierungen und Servern endete tatsächlich damit, dass alle Daten in S3 kopiert wurden (Gott sei Dank!). Eine Kuriosität ist jedoch, dass einige Reduzierungen NIEMALS benötigen, um die Daten in S3 zu kopieren. In beiden neuen Läufen gab es eine Reduzierung, deren Ausgabe 1 oder 2 Stunden in S3 dauerte, während die anderen Reduzierungen nur maximal 10 Minuten dauerten (Dateien sind 3 GB oder so). Ich denke, dies hängt mit dem von EMR verwendeten S3NativeFileSystem zusammen (z. B. der langen Wartezeit - die mir natürlich in Rechnung gestellt wird; und den angeblich erfolgreichen Uploads, die nicht hochgeladen werden). Ich würde zuerst auf lokales HDFS hochladen, dann auf S3, aber das war ichProbleme auf dieser Front auch haben (In Erwartung der Überprüfung durch das AWS-Entwicklungsteam).

TLDR; Die Verwendung von AWS EMR zum direkten Speichern in S3 scheint fehlerhaft zu sein. ihr Engineering-Team sucht in.