2016-07-07 3 views
2

Ich rufe diese Methode für eine RDD [String] mit Ziel in den Argumenten auf. (Scala)Spark RDD-Methode "saveAsTextFile" wirft Ausnahme Auch nach dem Löschen des Ausgabeverzeichnisses. org.apache.hadoop.mapred.FileAlreadyExistsException

Auch nach dem Löschen des Verzeichnisses vor dem Start gibt der Prozess diesen Fehler. Ich führe diesen Prozess auf EMR-Cluster mit Ausgabestandort in aws S3. Unten ist der Befehl:

spark-submit --deploy-mode cluster --class com.hotwire.hda.spark.prd.pricingengine.PRDPricingEngine --conf spark.yarn.submit.waitAppCompletion=true --num-executors 21 --executor-cores 4 --executor-memory 20g --driver-memory 8g --driver-cores 4 s3://bi-aws-users/sbatheja/hotel-shopper-0.0.1-SNAPSHOT-jar-with-dependencies.jar -d 3 -p 100 --search-bucket s3a://hda-prod-business.hotwire.hotel.search --prd-output-path s3a://bi-aws-users/sbatheja/PRD/PriceEngineOutput/ 

Log:

16/07/07 11:27:47 INFO BlockManagerMaster: BlockManagerMaster stopped 
16/07/07 11:27:47 INFO OutputCommitCoordinator$OutputCommitCoordinatorEndpoint: OutputCommitCoordinator stopped! 
16/07/07 11:27:47 INFO SparkContext: Successfully stopped SparkContext 
16/07/07 11:27:47 INFO ApplicationMaster: Unregistering ApplicationMaster with FAILED (diag message: User class threw exception: **org.apache.hadoop.mapred.FileAlreadyExistsException: Output directory s3a://bi-aws-users/sbatheja/PRD/PriceEngineOutput already exists)** 
16/07/07 11:27:47 INFO RemoteActorRefProvider$RemotingTerminator: Shutting down remote daemon. 
16/07/07 11:27:47 INFO RemoteActorRefProvider$RemotingTerminator: Remote daemon shut down; proceeding with flushing remote transports. 
16/07/07 11:27:47 INFO AMRMClientImpl: Waiting for application to be successfully unregistered. 
16/07/07 11:27:47 INFO RemoteActorRefProvider$RemotingTerminator: Remoting shut down. 
16/07/07 11:27:47 INFO ApplicationMaster: Deleting staging directory .sparkStaging/application_1467889642439_0001 
16/07/07 11:27:47 INFO ShutdownHookManager: Shutdown hook called 
16/07/07 11:27:47 INFO ShutdownHookManager: Deleting directory /mnt/yarn/usercache/hadoop/appcache/application_1467889642439_0001/spark-7f836950-a040-4216-9308-2bb4565c5649 

It "_temporary" Verzeichnis in der Lage erzeugt, die leere Teiledateien enthält.

+0

Sind Sie sicher, dass Ordner nicht existiert, bevor Sie den Auftrag ausführen? Warum benutzt du 's3a' und nicht' s3' oder 's3n'? –

+0

Ja, ich löschte das Verzeichnis vor allem. im Grunde Grund ist s3 unterstützt bis zu 5 GB, s3a hat keine solche Grenze. Auch mit s3 versucht. Das gleiche Problem :( – saurabh7389

+0

Vielleicht ist Ihr Problem woanders im Code, der fehlschlägt und deshalb die temporären Dateien, und Sie haben einige Wiederholungsmechanismen, die versucht, den Code erneut auszuführen und dann fehlschlägt, weil das Verzeichnis bereits mit dem vorherigen Versuch und der existiert overs? –

Antwort

1

Kurz gesagt, ein Wort:
Stellen Sie sicher, die scala Version von spark-core und scala-library konsistent ist.


Ich stieß auf das gleiche Problem. Während ich die Datei auf das HDFS speichere, löst es eine Ausnahme aus: org.apache.hadoop.mapred.FileAlreadyExistsException
Dann habe ich das HDFS-Dateiverzeichnis überprüft, es gibt einen leeren temporären Ordner: TARGET_DIR/_temporary/0.

Sie können den Auftrag senden, öffnen Sie die detaillierte Konfiguration: ./spark-submit --verbose. Und dann schauen Sie sich den vollen Kontext und log, dort müssen andere Fehler verursacht werden. Mein Job im RUNNING Zustand wird der erste Fehler ausgelöst:

17/04/23 11:47:02 ERROR executor.Executor: Exception in task 1.0 in stage 0.0 (TID 1) 
java.lang.NoSuchMethodError: scala.Predef$.refArrayOps([Ljava/lang/Object;)[Ljava/lang/Object; 

Dann wird der Job erneut versucht wird und erneut ausgeführt. Zu diesem Zeitpunkt, Job-Re-Implementierung, wird es nur das Verzeichnis gefunden wurde erstellt. Und wirft auch das Verzeichnis bereits existiert.

Nach der Bestätigung, dass der erste Fehler ist Version Kompatibilitätsprobleme. Die Spark-Version ist 2.1.0, die entsprechende spark-core Scala-Version ist 2.11, und die scala-library Abhängigkeit der Scala-Version ist 2.12.xx.

Wenn die zwei Scala-Version der Änderung konsistent ist (in der Regel ändern Sie die Version), können Sie das Problem der ersten Ausnahme lösen, dann kann der Auftrag normal FINISHED sein.
pom.xml Beispiel:

<!-- Spark --> 
<dependency> 
    <groupId>org.apache.spark</groupId> 
    <artifactId>spark-core_2.11</artifactId> 
    <version>2.1.0</version> 
</dependency> 
<!-- scala --> 
<dependency> 
    <groupId>org.scala-lang</groupId> 
    <artifactId>scala-library</artifactId> 
    <version>2.11.7</version> 
</dependency> 
Verwandte Themen