Je suis exécutant un travail d'étincelle sur EMR et en utilisant DataStax Connector pour vous connecter au cluster Cassandra. Je suis confronté à des problèmes avec le pot de Guava, veuillez trouver les détails ci-dessous J'utilise ci-dessous Cassandra Deps
ava.lang.ExceptionInInitializerError
at com.datastax.spark.connector.cql.DefaultConnectionFactory$.clusterBuilder(CassandraConnectionFactory.scala:35)
at com.datastax.spark.connector.cql.DefaultConnectionFactory$.createCluster(CassandraConnectionFactory.scala:87)
at com.datastax.spark.connector.cql.CassandraConnector$.com$datastax$spark$connector$cql$CassandraConnector$$createSession(CassandraConnector.scala:153)
at com.datastax.spark.connector.cql.CassandraConnector$$anonfun$2.apply(CassandraConnector.scala:148)
at com.datastax.spark.connector.cql.CassandraConnector$$anonfun$2.apply(CassandraConnector.scala:148)
at com.datastax.spark.connector.cql.RefCountedCache.createNewValueAndKeys(RefCountedCache.scala:31)
at com.datastax.spark.connector.cql.RefCountedCache.acquire(RefCountedCache.scala:56)
at com.datastax.spark.connector.cql.CassandraConnector.openSession(CassandraConnector.scala:81)
at ampush.event.process.core.CassandraServiceManagerImpl.getAdMetaInfo(CassandraServiceManagerImpl.java:158)
at ampush.event.config.metric.processor.ScheduledEventAggregator$4.call(ScheduledEventAggregator.java:308)
at ampush.event.config.metric.processor.ScheduledEventAggregator$4.call(ScheduledEventAggregator.java:290)
at org.apache.spark.api.java.JavaRDDLike$$anonfun$foreachPartition$1.apply(JavaRDDLike.scala:222)
at org.apache.spark.api.java.JavaRDDLike$$anonfun$foreachPartition$1.apply(JavaRDDLike.scala:222)
at org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfun$apply$29.apply(RDD.scala:902)
at org.apache.spark.rdd.RDD$$anonfun$foreachPartition$1$$anonfun$apply$29.apply(RDD.scala:902)
at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1850)
at org.apache.spark.SparkContext$$anonfun$runJob$5.apply(SparkContext.scala:1850)
at org.apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:66)
at org.apache.spark.scheduler.Task.run(Task.scala:88)
at org.apache.spark.executor.Executor$TaskRunner.run(Executor.scala:214)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
Caused by: java.lang.IllegalStateException: Detected Guava issue #1635 which indicates that a version of Guava less than 16.01 is in use. This introduces codec resolution issues and potentially other incompatibility issues in the driver. Please upgrade to Guava 16.01 or later.
at com.datastax.driver.core.SanityChecks.checkGuava(SanityChecks.java:62)
at com.datastax.driver.core.SanityChecks.check(SanityChecks.java:36)
at com.datastax.driver.core.Cluster.<clinit>(Cluster.java:67)
... 23 more
6 Réponses :
Il suffit d'ajouter dans votre (ou une version> 16.0.1 que vous préférez)
Aussi selon Link GITUB.COM/DATASTAX/SPARK-CASSANDRA-Connector J'utilise 1.5 Connecteur Cassandra 1.5, 1.6 (SPAK) 3.0 (Cassandra)? pas sûr alors pourquoi je reçois un problème
Je ne sais pas ce que tu demandais. Si vous êtes intéressé à savoir pourquoi Maven résolvait l'ancienne version de Guava, vous pouvez utiliser dépendance MVN: arborescence qu'il vous montre comment chaque dépendance est résolue (ou ignorée) de manière transitaire
J'ai eu la cause première que le problème que j'ai mentionné ici est lié à EMR. Ici, Spark et Cassandra tentent d'utiliser Guava 16 et EMR ajoute de la vieille Hadoop Lib à Spark SparkPath chercher de la vieille Guava 11. Je travaille avec une autre demande avec Amazon pour résoudre ce problème. Merci
Oh mec, j'aimerais que c'était aussi facile. Pour moi, l'étincelle elle-même a une tonne de pots. L'écran tiré ci-dessus fonctionne presque, mais pour notre version de Spark, nous avons eu différentes versions de Guava partout. J'ai fini par les filtrer tout de suite, comme partout. Et j'ai ajouté les trucs dans la classe de classe comme @Adri
@TonyFraser c'est ce que Spark déclaré dans Dépendencymanagement de votre POMME parent, avoir des problèmes de dépendance exclus. Ce faisant, les POMS héritant de votre parent pom, lors de la déclaration Spark comme dépendance, aura ces dépendances des problèmes exclus. Bien sûr, vous devez ajouter les dépendances correctes correspondantes.
J'ai eu le même problème et je l'ai résolu en utilisant le plugin Maven Shade pour ombrer la version de Guava que le connecteur Cassandra apporte.
Je devais exclure les classes facultatives, présentes et absentes explicitement parce que j'étais Concentant des problèmes avec une étincelle essayant de jeter du type présent de guitage non ombragé au type optionnelle ombragé. Je ne sais pas si cela provoquerait des problèmes plus tard, mais cela semble fonctionner pour moi pour l'instant.
Vous pouvez ajouter ceci à la section
Cela ne résoudra pas le but ici. La raison ici est notre plate-forme de déploiement EMR. La façon dont EMR utilise pour construire la catégorie de classe d'étincelle par défaut utilise moins <16 Version de Guava dans ClassPath, qui est due au fait qu'il tire les bibliothèques Hadoop, toujours anciennes avec EMR 4.2 \ 4.4 \ 4.6. J'ai fixé le mien en ajoutant un processus de bootstrap à EMR pour remplacer par défaut Spark ClassPath avec mis à jour.
Je confirme que cela corrige le problème pour moi sur un cluster Spark Standalone V1.5.2 et Spark Cassandra Connector V1.5.1. Merci.
Une autre solution, allez au répertoire
étincelle / pots
. Renommer
GUAVA-14.0.1.JAR CopierGUAVA-19.0.0.JAR Comme cette image:
En tant que note, Guava 20 ne fonctionnera pas pour cela. Guava 19 fonctionne, cependant.
Un tel bon hack!
Renommer le vieux pot et ajouter le nouveau qui n'a pas fonctionné pour moi (Spark 2.4.0). Supprimer le vieux pot a résolu le problème.
J'ai pu contourner cela en ajoutant le pot en goyave 16.0.1 à l'extérieur, puis spécifiant le chemin de classe sur Spark Soumettre avec l'aide des valeurs de configuration ci-dessous:
J'espère que cela aide quelqu'un d'erreur similaire!
Merci Adrian pour votre réponse.
Je suis sur un peu d'architecture différente que tout le monde sur le fil, mais le problème de Guava est toujours le même. J'utilise Spark 2.2 avec la mésosphère. Dans notre environnement de développement, nous utilisons SBT-Native-Packager pour produire nos images Docker pour passer à des mésos.
se révèle, nous devions avoir une guava différente pour les exécutants Spark Soumettre que nous n'avons besoin que le code que Nous courons sur le conducteur. Cela a fonctionné pour moi.
build.sbt Lorsque j'ai essayé de remplacer GUAVA 14 sur les exécuteurs avec GUAVA 16.0.1 ou 19, il reste ne fonctionnerait pas. SOUMISSION SOUMISSION JUSTE JUSTE. Mon gros bocal qui est en fait la goyave qui est utilisé pour ma demande dans le conducteur, j'ai obligé d'être 19, mais mon étincelle Soumettre l'exécuteur que je devais remplacer à être 23. J'ai essayé de remplacer les 16 et 19, mais Spark vient de mourir Là aussi. Désolé de détourner, mais à chaque fois après toutes mes recherches Google, celle-ci est arrivée à chaque fois. J'espère que cela aide également les autres personnes SBT / MESOS.
Je faisais face au même problème lors de la récupération des enregistrements de la table de Cassandra à l'aide de Spark (Java) sur Spark Submit.
Vérifiez votre GUAVA STRAND> Version JAR utilisée par HADOOOOP et Stincez-la dans le cluster en utilisant Trouver Strong> Commandez et changez-le en conséquence. P> spark-submit --class com.my.spark.MySparkJob --master local --conf 'spark.yarn.executor.memoryOverhead=2048' --conf 'spark.cassandra.input.consistency.level=ONE' --conf 'spark.cassandra.output.consistency.level=ONE' --conf 'spark.dynamicAllocation.enabled=false' --conf "spark.driver.extraClassPath=lib/guava-19.0.jar" --conf "spark.executor.extraClassPath=lib/guava-19.0.jar" --total-executor-cores 15 --executor-memory 15g --jars $(echo lib/*.jar | tr ' ' ',') target/my-sparkapp.jar
Vos blocs de dépendance sont incomplets