web-dev-qa-db-fra.com

Pourquoi les travaux Spark échouent-ils avec org.Apache.spark.shuffle.MetadataFetchFailedException: il manque un emplacement de sortie pour la lecture aléatoire 0 en mode spéculation?

J'exécute un travail Spark avec dans un mode de spéculation. J'ai environ 500 tâches et environ 500 fichiers compressés à 1 Go. Je continue à obtenir dans chaque travail, pour 1-2 tâches, l'erreur jointe qui se répète des dizaines de fois (empêchant l'exécution du travail).

org.Apache.spark.shuffle.MetadataFetchFailedException: emplacement de sortie manquant pour la lecture aléatoire 0

Avez-vous une idée de la signification du problème et de la façon de le surmonter?

org.Apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 0
    at org.Apache.spark.MapOutputTracker$$anonfun$org$Apache$spark$MapOutputTracker$$convertMapStatuses$1.apply(MapOutputTracker.scala:384)
    at org.Apache.spark.MapOutputTracker$$anonfun$org$Apache$spark$MapOutputTracker$$convertMapStatuses$1.apply(MapOutputTracker.scala:381)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
    at scala.collection.TraversableLike$$anonfun$map$1.apply(TraversableLike.scala:244)
    at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
    at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:108)
    at scala.collection.TraversableLike$class.map(TraversableLike.scala:244)
    at scala.collection.mutable.ArrayOps$ofRef.map(ArrayOps.scala:108)
    at org.Apache.spark.MapOutputTracker$.org$Apache$spark$MapOutputTracker$$convertMapStatuses(MapOutputTracker.scala:380)
    at org.Apache.spark.MapOutputTracker.getServerStatuses(MapOutputTracker.scala:176)
    at org.Apache.spark.shuffle.hash.BlockStoreShuffleFetcher$.fetch(BlockStoreShuffleFetcher.scala:42)
    at org.Apache.spark.shuffle.hash.HashShuffleReader.read(HashShuffleReader.scala:40)
    at org.Apache.spark.rdd.ShuffledRDD.compute(ShuffledRDD.scala:92)
    at org.Apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:263)
    at org.Apache.spark.rdd.RDD.iterator(RDD.scala:230)
    at org.Apache.spark.rdd.MappedRDD.compute(MappedRDD.scala:31)
    at org.Apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:263)
    at org.Apache.spark.rdd.RDD.iterator(RDD.scala:230)
    at org.Apache.spark.rdd.FlatMappedRDD.compute(FlatMappedRDD.scala:33)
    at org.Apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:263)
    at org.Apache.spark.rdd.RDD.iterator(RDD.scala:230)
    at org.Apache.spark.rdd.MappedRDD.compute(MappedRDD.scala:31)
    at org.Apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:263)
    at org.Apache.spark.rdd.RDD.iterator(RDD.scala:230)
    at org.Apache.spark.rdd.MappedRDD.compute(MappedRDD.scala:31)
    at org.Apache.spark.rdd.RDD.computeOrReadCheckpoint(RDD.scala:263)
    at org.Apache.spark.rdd.RDD.iterator(RDD.scala:230)
    at org.Apache.spark.scheduler.ResultTask.runTask(ResultTask.scala:61)
    at org.Apache.spark.scheduler.Task.run(Task.scala:56)
    at org.Apache.spark.executor.Executor$TaskRunner.run(Executor.scala:196)
    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:722)
apache-spark
70
dotan

Cela m'est arrivé lorsque j'ai donné plus de mémoire au nœud de travail qu'il n'en a. Comme il n’a pas été échangé, spark est tombé en panne en essayant de stocker des objets à réorganiser sans plus de mémoire.

La solution consistait soit à ajouter un swap, soit à configurer le travailleur/exécuteur afin qu'il utilise moins de mémoire en plus d'utiliser le niveau de stockage MEMORY_AND_DISK pour plusieurs persistes.

42
Joren Van Severen

Nous avons eu une erreur similaire avec Spark, mais je ne suis pas sûr que cela soit lié à votre problème.

Nous avons utilisé JavaPairRDD.repartitionAndSortWithinPartitions sur des données de 100 Go et l’échec a été similaire à celui de votre application. Nous avons ensuite examiné les journaux de fil sur les nœuds spécifiques et découvert que nous avions un problème de mémoire insuffisante. Le fil a donc interrompu l'exécution. Notre solution consistait à changer/ajouter spark.shuffle.memoryFraction 0 dans .../spark/conf/spark-defaults.conf. Cela nous a permis de traiter une quantité de données beaucoup plus grande (mais malheureusement pas infinie) de cette façon.

14
Notinlist

J'ai eu le même problème sur mon cluster 3 machines YARN. Je n'arrêtais pas de changer RAM mais le problème persistait. Enfin, j'ai vu les messages suivants dans les journaux:

17/02/20 13:11:02 WARN spark.HeartbeatReceiver: Removing executor 2 with no recent heartbeats: 1006275 ms exceeds timeout 1000000 ms
17/02/20 13:11:02 ERROR cluster.YarnScheduler: Lost executor 2 on 1worker.com: Executor heartbeat timed out after 1006275 ms

et après cela, il y avait ce message:

org.Apache.spark.shuffle.MetadataFetchFailedException: Missing an output location for shuffle 67

J'ai modifié les propriétés dans spark-defaults.conf comme suit:

spark.yarn.scheduler.heartbeat.interval-ms 7200000
spark.executor.heartbeatInterval 7200000
spark.network.timeout 7200000

C'est ça! Mon travail s'est terminé avec succès après cela.

10
xplorerdev

J'ai résolu cette erreur en augmentant la mémoire allouée dans executorMemory et driverMemory. Vous pouvez le faire dans HUE en sélectionnant le programme qui cause le problème Spark) et dans la liste Propriétés -> Option, vous pouvez ajouter quelque chose comme ceci:

--driver-memory 10G --executor-memory 10G --num-executors 50 --executor-cores 2

Bien entendu, les valeurs des paramètres varient en fonction de la taille de votre cluster et de vos besoins.

1
Ignacio Alorre

Pour moi, je faisais du fenêtrage sur des données volumineuses (environ 50 milliards de lignes) et obtenais une charge de bateau de

ExternalAppendOnlyUnsafeRowArray:54 - Seuil de déversement de 4096 lignes atteint, passage à org.Apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter

Dans mes journaux. Évidemment, 4096 peut être petit sur une telle taille de données ... cela m'a conduit à la JIRA suivante:

https://issues.Apache.org/jira/browse/SPARK-21595

Et finalement aux deux options de configuration suivantes:

  • spark.sql.windowExec.buffer.spill.threshold
  • spark.sql.windowExec.buffer.in.memory.threshold

Les deux valeurs par défaut sont 4096; Je les ai beaucoup plus élevés (2097152) et les choses semblent bien se dérouler. Je ne suis pas sûr à 100% que ce soit la même chose que le problème soulevé ici, mais c'est une autre chose à essayer.

1
MichaelChirico

Dans mon cas (cluster autonome), l'exception a été levée car le système de fichiers de certains Spark esclaves était rempli à 100%. La suppression de tous les éléments de la spark/work Les dossiers des esclaves ont résolu le problème.

0
i000174

J'ai eu le même problème, mais j'ai cherché beaucoup de réponses qui ne peuvent pas résoudre mon problème. finalement, je débogue mon code étape par étape. Je trouve que le problème causé par la taille des données n’est pas équilibré pour chaque partition, ce qui conduit à MetadataFetchFailedException à map stage et non à reduce stage. il suffit de faire df_rdd.repartition(nums) avant reduceByKey()

0
DoG