Janusgraph étincelle goyave Version

Question

Voici mon problème:

Nous utilisons Cloudera 5.7.0 avec java 1.8.0_74 et nous avons étincelle 1.6.0, 0.1.1 janusgraph, HBase 1.2.0.

je lance le code suivant dans shell Gremlin:

:load data/call-janusgraph-schema-groovy 
writeGraphPath='conf/my-janusgraph-hbase.properties' 
writeGraph=JanusGraphFactory.open(writeGraphPath) 
defineCallSchema(writeGraph) 
writeGraph.close() 

readGraph=GraphFactory.open('conf/hadoop-graph/hadoop-call-script.properties') 
gRead=readGraph.traversal() 
gRead.V().valueMap() 

//so far so good everything works perfectly 

blvp=BulkLoaderVertexProgram.build().keepOriginalIds(true).writeGraph(writeGraphPath).create(readGraph) 
readGraph.compute(SparkGraphComputer).workers(1).program(blvp).submit().get() 

Il étoiles exécution de la tâche d'allumage et la première étape se déroule bien mais à la deuxième étape, je reçois une exception:

java.lang.NoSuchMethodError: com.google.common.base.Stopwatch.createStarted()Lcom/google/common/base/Stopwatch; 
at org.janusgraph.graphdb.database.idassigner.StandarIdPool.waitForIDBlockGetter(StandartIDPool.java:136)....... 

Je pense c'est un problème de version de goyave

Voici comment je démarre la coquille de gremlin

#!/bin/bash 

export JAVA_HOME=/mnt/hdfs/jdk.1.8.0_74 

export HADOOP_HOME=/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/lib/hadoop 
export HADOOP_CONF_DIR= /etc/hadoop/conf.cloudera.yarn 
export YARN_HOME=/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/lib/hadoop-yarn 
export YARN_CONF_DIR=$HADOOP_CONF_DIR 
export SPARK_HOME=/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/lib/spark 
export SPARK_CONF_DIR=$SPARK_HOME/conf 
export HBASE_HOME=/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/lib/hbase 
export HBASE_CONF_DIR=$HBASE_HOME/conf 

source "$HADOOP_CONF_DIR"/hadoop-env.sh 
source "$SPARK_HOME"/bin/load-spark-env.sh 
source "$HBASE_CONF_DIR"/hbase-env.sh 

export JAVA_OPTIONS="$JAVA_OPTIONS -Djava.library.path=/opt/cloudera/parcels/CDH-5.7.0-1.cdh5.7.0.p0.45/lib/hadoop/lib/native -Dtinkerpop.ext=ext -Dlog4j.configuration=conf/log4j-console.properties -Dgremlin.log4j.level=$GREMLIN_LOG_LEVEL -javaagent:/mnt/hdfs/janusgraph-0.1.1-hadoop2/lib/jamm-0.3.0.jar -Dhdp.version=$HDP_VERSION" 

GREMLINHOME=/mnt/hdfs/janusgraph-0.1.1-hadoop2 
export HADOOP_GREMLIN_LIBS=$GREMLINHOME/lib 

export CLASSPATH=$HADOOP_HOME/etc/hadoop 

export CLASSPATH=$CLASSPATH:$HBASE_HOME/conf 

export CLASSPATH=$GREMLINHOME/lib/*:$YARN_HOME/*:$YARN_CONF_DIR:$SPARK_HOME/lib/*:$SPARK_CONF_DIR:$CLASSPATH 

cd $GREMLINHOME 
export GREMLIN_LOG_LEVEL=info 
exec $GREMLINHOME/bin/gremlin.sh $* 

et voici ma conf/Hadoop-graphique/fichier hadoop-call-script.properties:

gremlin.graph=org.apache.tinkerpop.gremlin.hadoop.structure.HadoopGraph 
gremlin.hadoop.GraphInputFormat=org.apache.tinkerpop.gremlin.hadoop.structure.io.script.ScriptInputFormat 
gremlin.hadoop.inputLocation=/user/hive/warehouse/tablex/000000_0 
gremlin.hadoop.scriptInputFormat.script=/user/me/janus/script-input-call.groovy 
gremlin.hadoop.outputLocation=output 
gremlin.hadoop.jarsInDistributedCache=true 

spark.driver.maxResultSize=8192 
spark.yarn.executor.memoryOverhead=5000 
spark.executor.cores=1 
spark.executor.instances=1000 
spark.master=yarn-client 
spark.executor.memory=10g 
spark.driver.memory=10g 
spark.serializer=org.apache.spark.serializer.JavaSerializer 

Si je change la ligne "spark.master = fil client" à « spark.master = local [*] "alors il fonctionne parfaitement et charge les données dans le janusgraph, aucune exception n'est levée. Cependant j'ai besoin d'utiliser du fil, c'est un must pour moi. J'ai donc ajouté le fichier guava-18.0.jar à hdfs et ajouté la ligne "spark.executor.extraClassPath = hdfs: ///user/me/guava-18.0.jar" à hadoop-call-script.properties. Cela n'a pas résolu le problème.

Actuellement, je suis à court d'idées et d'impuissance, toute aide est appréciée. Non: Je suis conscient que l'ombrage mvn est quelque chose lié à ce problème, mais dans ce cas, puisque j'utilise des codes janusgraph pour créer un étincelle, je ne suis pas en mesure d'intervenir et ombrer les paquets de goyave.

Thx à l'avance, Ali

Answer 1

Le problème se produit lorsque vous soumettez un travail Spark qui utilisera Janusgraph en lecture/écriture de/vers HBase. La vraie cause du problème est que chaque composant nécessite une version différente de goyave qui a des commits très rapides et la compatibilité entre les versions n'est pas assurée. Voici regard rapide sur la dépendance version -

• Spark v1.6.1 - Goyave v14.0.1
• HBase v1.2.4 - Goyave v12.0
• Janusgraph 0.1.1 - Goyave v18.0

Même si vous mettez les trois bocaux à votre disposition dans CLASSPATH, vous obtiendrez des goyaves spécifiques en raison des versions en conflit.La façon dont je l'ai résolu était en reconstruisant Janusgraph et en ombrant la goyave avec la relocalisation dans janusgraph-core et janusgraph-hbase-parent. Après avoir résolu cela, j'ai rencontré quelques autres problèmes de dépendances liés aux conflits de jetée dans Spark et HBase, pour lesquels j'ai exclu mortbay de l'ombrage janusgraph-hbase-parent.

J'espère que cela aide, si vous avez besoin de plus d'informations à ce sujet, je vais mettre à jour la réponse.

Answer 2

j'avais fait face au même problème il y a quelques jours. Cela se produit car l'artefact com.google.guava: gouave: 18.0 peut ne pas être présent dans le chemin de classe ou il peut y avoir plusieurs versions du même jar présentes sur le chemin de classe.

#from the projects home dir 
>ls -lrt lib/ | grep gua 
# should show guava-18.0.jar 

Si l'artefact (https://mvnrepository.com/artifact/com.google.guava/guava/18.0) n'est pas présent puis ajoutez-le dans le dossier lib.

Il est bon d'imprimer la CLASSPATH $ à partir du script shell pour vérifier si les pots nécessaires sont sur le chemin de classe