Problem mit -libjars in hadoop

8

Ich versuche, einen MapReduce-Job auf Hadoop auszuführen, sehe aber einen Fehler und bin mir nicht sicher, was falsch läuft. Ich muss Bibliotheksgläser pastieren, die von meinem Mapper benötigt werden.

Ich erledigte folgendes am Terminal:

hadoop @ ubuntu: / usr / lokal / hadoop $ bin / hadoop jar /home/hadoop/vardtst.jar -libjars /home/hadoop/clui.jar -libjars /home/hadoop/model.jar Gutenberg ou101

und ich erhalte die folgende Ausnahme:

unter java.net.URLClassLoader $ 1.run (URLClassLoader.java:202)

unter java.security.AccessController.doPrivileged (Native Methode)

unter java.net.URLClassLoader.findClass (URLClassLoader.java:190)

bei java.lang.ClassLoader.loadClass (ClassLoader.java306)

bei java.lang.ClassLoader.loadClass (ClassLoader.java:247)

bei java.lang.Class.forName0 (native Methode)

bei java.lang.Class.forName (Class.java:247)

unter org.apache.hadoop.util.RunJar.main (RunJar.java:149)

Bitte Hilfe .. Danke

    
Shrish Bajpai 31.07.2011, 14:43
quelle

3 Antworten

3

Ich habe die Antwort gefunden, es war ein Fehler beim Werfen, weil mir der Klassenname "main" im Befehl fehlte.

Der richtige Weg zum Ausführen ist: hadoop @ ubuntu: / usr / local / hadoop $ bin / hadoopglas /home/hadoop/vardtst.jar VardTest -libjars /home/hadoop/clui.jar/home/hadoop/model.jar Gutenberg ou101

Dabei ist VardTest die Klasse, die die main () -Methode enthält.

Danke

    
Shrish Bajpai 01.08.2011, 01:14
quelle
17

Beachten Sie auch den subtilen, aber wichtigen Punkt: die Möglichkeit, zusätzliche JARs für JVMs anzugeben, auf denen verteilte Map-Reduce-Tasks ausgeführt werden, und für JVM-Running-Job-Clients ist dies sehr unterschiedlich.

  • -libjars macht Jars nur für JVMs verfügbar, die eine Remote-Map ausführen und die Aufgabe reduzieren

  • Um dieselben JARs für die Client-JVM verfügbar zu machen (die JVM, die beim Ausführen des Befehls hadoop jar erstellt wird), müssen Sie die Umgebungsvariable HADOOP_CLASSPATH festlegen:

%Vor%

Siehe: Ссылка

Eine andere Ursache für falsches -libjars-Verhalten könnte in der falschen Implementierung und Initialisierung der benutzerdefinierten Job-Klasse liegen.

  • Die Jobklasse muss die Toolschnittstelle implementieren
  • Die Konfigurationsklasseninstanz muss durch Aufrufen von getConf () abgerufen werden, anstatt eine neue Instanz zu erstellen.

Siehe: Ссылка

    
Vladimir Kroz 23.10.2013 10:55
quelle
3

Wenn Sie die -LIBJARS mit dem Hadoop jar-Befehl angeben. Stellen Sie zunächst sicher, dass Sie Ihre Treiberklasse wie folgt bearbeiten:

%Vor%

Bearbeiten Sie nun Ihren "hadoop jar" -Befehl wie folgt:

  

hadoop jar YourApplication.jar [myDriverClass] args -libjars Pfad / zu / jar / file

Lasst uns jetzt verstehen, was darunter passiert. Im Grunde behandeln wir die neuen Befehlszeilenargumente, indem wir die TOOL-Schnittstelle implementieren . ToolRunner wird zum Ausführen von Klassen verwendet, die die Tool-Schnittstelle implementieren. Es funktioniert in Verbindung mit GenericOptionsParser , um das Generische zu analysieren hadoop Befehlszeilenargumente und modifiziert die Konfiguration des Tools.

In unserem Main () rufen wir ToolRunner.run (new Configuration (), new myDriverClass (), args) auf - dies führt das angegebene Tool nach Tool.run (String []), nach dem Parsen mit gegebene generische Argumente . Sie verwendet die angegebene Konfiguration oder erstellt eine, wenn sie null ist, und legt dann die Konfiguration des Tools mit der möglicherweise geänderten Version von conf fest.

Wenn wir getConf () aufrufen, erhalten wir innerhalb der run-Methode die modifizierte Version der Konfiguration. Achten Sie also darauf, dass Sie die untere Zeile in Ihrem Code haben. Wenn Sie alles andere implementieren und weiterhin Configuration conf = new Configuration () verwenden, würde nichts funktionieren.

  

Konfiguration conf = getConf ();

    
Isaiah4110 27.03.2016 00:08
quelle

Tags und Links