Quelles sont les raisons possibles pour recevoir TimeoutException: les contrats à terme ont expiré après [n secondes] lorsque vous utilisez Spark
Je travaille sur un programme Spark SQL et je reçois l'exception suivante:
16/11/07 15:58:25 ERROR yarn.ApplicationMaster: User class threw exception: Java.util.concurrent.TimeoutException: Futures timed out after [3000 seconds]
Java.util.concurrent.TimeoutException: Futures timed out after [3000 seconds]
at scala.concurrent.impl.Promise$DefaultPromise.ready(Promise.scala:219)
at scala.concurrent.impl.Promise$DefaultPromise.result(Promise.scala:223)
at scala.concurrent.Await$$anonfun$result$1.apply(package.scala:190)
at scala.concurrent.BlockContext$DefaultBlockContext$.blockOn(BlockContext.scala:53)
at scala.concurrent.Await$.result(package.scala:190)
at org.Apache.spark.sql.execution.joins.BroadcastHashJoin.doExecute(BroadcastHashJoin.scala:107)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:132)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:130)
at org.Apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:150)
at org.Apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:130)
at org.Apache.spark.sql.execution.Project.doExecute(basicOperators.scala:46)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:132)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:130)
at org.Apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:150)
at org.Apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:130)
at org.Apache.spark.sql.execution.Union$$anonfun$doExecute$1.apply(basicOperators.scala:144)
at org.Apache.spark.sql.execution.Union$$anonfun$doExecute$1.apply(basicOperators.scala:144)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:245)
at scala.collection.immutable.List.foreach(List.scala:381)
at scala.collection.TraversableLike$class.map(TraversableLike.scala:245)
at scala.collection.immutable.List.map(List.scala:285)
at org.Apache.spark.sql.execution.Union.doExecute(basicOperators.scala:144)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:132)
at org.Apache.spark.sql.execution.SparkPlan$$anonfun$execute$5.apply(SparkPlan.scala:130)
at org.Apache.spark.rdd.RDDOperationScope$.withScope(RDDOperationScope.scala:150)
at org.Apache.spark.sql.execution.SparkPlan.execute(SparkPlan.scala:130)
at org.Apache.spark.sql.execution.columnar.InMemoryRelation.buildBuffers(InMemoryColumnarTableScan.scala:129)
at org.Apache.spark.sql.execution.columnar.InMemoryRelation.<init>(InMemoryColumnarTableScan.scala:118)
at org.Apache.spark.sql.execution.columnar.InMemoryRelation$.apply(InMemoryColumnarTableScan.scala:41)
at org.Apache.spark.sql.execution.CacheManager$$anonfun$cacheQuery$1.apply(CacheManager.scala:93)
at org.Apache.spark.sql.execution.CacheManager.writeLock(CacheManager.scala:60)
at org.Apache.spark.sql.execution.CacheManager.cacheQuery(CacheManager.scala:84)
at org.Apache.spark.sql.DataFrame.persist(DataFrame.scala:1581)
at org.Apache.spark.sql.DataFrame.cache(DataFrame.scala:1590)
at com.somecompany.ml.modeling.NewModel.getTrainingSet(FlowForNewModel.scala:56)
at com.somecompany.ml.modeling.NewModel.generateArtifacts(FlowForNewModel.scala:32)
at com.somecompany.ml.modeling.Flow$class.run(Flow.scala:52)
at com.somecompany.ml.modeling.lowForNewModel.run(FlowForNewModel.scala:15)
at com.somecompany.ml.Main$$anonfun$2.apply(Main.scala:54)
at com.somecompany.ml.Main$$anonfun$2.apply(Main.scala:54)
at scala.Option.getOrElse(Option.scala:121)
at com.somecompany.ml.Main$.main(Main.scala:46)
at com.somecompany.ml.Main.main(Main.scala)
at Sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at Sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.Java:62)
at Sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.Java:43)
at Java.lang.reflect.Method.invoke(Method.Java:498)
at org.Apache.spark.deploy.yarn.ApplicationMaster$$anon$2.run(ApplicationMaster.scala:542)
16/11/07 15:58:25 INFO yarn.ApplicationMaster: Final app status: FAILED, exitCode: 15, (reason: User class threw exception: Java.util.concurrent.TimeoutException: Futures timed out after [3000 seconds])
La dernière partie de mon code que je reconnais dans la trace de pile est com.somecompany.ml.modeling.NewModel.getTrainingSet(FlowForNewModel.scala:56), ce qui m'amène à cette ligne: profilesDF.cache() Avant la mise en cache, j'effectue une union entre 2 images de données. J'ai vu une réponse à propos de la persistance des deux images avant la jointure ici Je dois encore mettre en cache l'unité de données unifiée, car je l'utilise dans plusieurs de mes transformations.
Et je me demandais ce qui pouvait causer cette exception? Cette recherche m’a amené à un lien traitant de l’exception de temporisation rpc ou de problèmes de sécurité qui ne sont pas mon problème Si vous savez également comment le résoudre, je l'apprécierais évidemment, mais le simple fait de comprendre le problème m'aidera à le résoudre.
Merci d'avance
Question: Je me demandais ce qui pouvait causer la levée de cette exception?
Réponse :
spark.network.timeout120s Délai d'attente par défaut pour toutes les interactions réseau ..spark.network.timeout (spark.rpc.askTimeout),spark.sql.broadcastTimeout,spark.kryoserializer.buffer.max(si vous utilisez la sérialisation kryo ), etc. sont accordés avec des valeurs supérieures à celles par défaut dans afin de traiter des requêtes complexes. Vous pouvez commencer avec ces valeurs et Adaptez-vous à vos charges de travail SQL.
Note: Doc dit que
Les options suivantes (voir propriétés spark.sql.) Peuvent également être utilisées pour optimiser les performances d'exécution des requêtes. Il est possible que ces options soient obsolètes dans les versions ultérieures à mesure que d'autres optimisations seront effectuées automatiquement. *
De même, pour une meilleure compréhension, vous pouvez voir BroadCastHashJoin où la méthode execute est le point de déclenchement de la trace de pile ci-dessus.
protected override def doExecute(): RDD[Row] = {
val broadcastRelation = Await.result(broadcastFuture, timeout)
streamedPlan.execute().mapPartitions { streamedIter =>
hashJoin(streamedIter, broadcastRelation.value)
}
}
Bon à savoir que la suggestion de Ram fonctionne dans certains cas. Je voudrais mentionner que je suis tombé sur cette exception à quelques reprises (y compris celle décrite ici ).
La plupart du temps, cela était dû à des MOO presque silencieux sur certains exécuteurs testamentaires. Recherchez les tâches ayant échoué sur SparkUI, dernière colonne de ce tableau: 
Vous remarquerez peut-être des messages de MOO.
Si vous comprenez bien les composants internes de l’étincelle, les données diffusées passent par le pilote. Le pilote dispose donc d’un mécanisme de thread permettant de collecter les données auprès des exécuteurs et de les renvoyer à tous. Si un exécuteur échoue à un moment donné, vous risquez de vous retrouver avec ces délais.
Si vous avez activé dynamicAllocation, essayez de désactiver cette configuration (spark.dynamicAllocation.enabled = false). Vous pouvez définir cette configuration d'étincelle sous conf/spark-defaults.conf, en tant que --conf ou dans le code.
Voir également:
J'avais défini master as local[n] lorsque j'ai soumis le travail à Yarn-cluster.
Ne définissez pas maître dans le code lors de l'exécution sur le cluster, utilisez plutôt --master.