Чому завдання Spark не справляються з org.apache.spark.shuffle.MetadataFetchFailedException: Немає вихідного розташування для перетасовки 0 у режимі спекуляції?

Я запускаю роботу Spark у режимі спекуляції. У мене близько 500 завдань і близько 500 файлів стисненими 1 Гб. Я продовжую отримувати в кожному завданні по 1-2 завдання прикріплену помилку, де вона повторюється після цього десятки разів (заважаючи завершити роботу).

org.apache.spark.shuffle.MetadataFetchFailedException: Відсутнє вихідне розташування для перетасовки 0

Будь-яка ідея, у чому сенс проблеми та як її подолати?

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)

Це трапилося зі мною, коли я віддав робочому вузлу більше пам'яті, ніж він має. Оскільки у нього не було обміну, іскра розбилася, намагаючись зберегти об'єкти для перетасовки, не залишивши більше пам'яті.

Рішення полягало в тому, щоб або додати обмін, або налаштувати працівника / виконавця, щоб він використовував менше пам'яті, крім того, використовуючи рівень зберігання MEMORY_AND_DISK протягом декількох персистів.

У нас була подібна помилка із Spark, але я не впевнений, що це пов’язано з вашою проблемою.

Ми використовували JavaPairRDD.repartitionAndSortWithinPartitions100 Гб даних, і вони продовжували відмовляти, як і ваш додаток. Потім ми переглянули журнали Yarn на конкретних вузлах і з’ясували, що у нас є якась проблема, пов’язана з відсутністю пам’яті, тому Yarn перервала виконання. Наше рішення було змінити / додати spark.shuffle.memoryFraction 0в .../spark/conf/spark-defaults.conf. Це дозволило нам обробляти набагато більший (але, на жаль, нескінченний) обсяг даних таким чином.

Я отримав таку саму проблему на моєму 3 машинному кластері YARN. Я постійно міняв оперативну пам’ять, але проблема не зникала. Нарешті я побачив у журналах такі повідомлення:

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

і після цього було таке повідомлення:

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

Я змінив властивості в spark-defaults.conf наступним чином:

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

Це воно! Моя робота після цього успішно виконана.

Для мене я робив деякі вікна на великі дані (близько 50B рядків) і отримував завантаження човна

ExternalAppendOnlyUnsafeRowArray:54 - Досягнуто порогу розливу 4096 рядків, перемикання на org.apache.spark.util.collection.unsafe.sort.UnsafeExternalSorter

У моїх журналах. Очевидно, що 4096 може бути невеликим за такого розміру даних ... це призвело мене до наступного JIRA:

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

І зрештою до наступних двох параметрів конфігурації:

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

Обидва за замовчуванням - 4096; Я підняв їх набагато вище (2097152), і зараз, здається, справи йдуть добре. Я не впевнений на 100%, що це те саме, що питання, порушене тут, але інша справа спробувати.

Я вирішив цю помилку, збільшивши виділену пам'ять у executorMemory та driverMemory. Ви можете зробити це в HUE, вибравши програму Spark, яка спричиняє проблему, а у властивостях -> Список опцій ви можете додати щось подібне:

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

Звичайно, значення параметрів будуть змінюватися залежно від розміру кластера та ваших потреб.

у веб-інтерфейсі Spark, якщо є якась інформація, наприклад Executors lost, вам потрібно перевірити журнал пряжі, переконатися, що ваш контейнер вбито.

Якщо контейнер був убитий, можливо, це пов’язано з відсутністю пам’яті.

Як знайти ключову інформацію в журналах пряжі? Наприклад, можуть бути такі попередження:

Container killed by YARN for exceeding memory limits. 2.5 GB of 2.5 GB physical memory used. 
Consider boosting spark.yarn.executor.memoryOverhead.

У цьому випадку це передбачає збільшення spark.yarn.executor.memoryOverhead.

У моєму випадку (автономний кластер) було вилучено виняток, оскільки файлова система деяких підлеглих Spark була заповнена на 100%. Видалення всього, що було в spark/workпапках рабів, вирішило проблему.

У мене така сама проблема, але я шукав багато відповідей, які не можуть вирішити мою проблему. зрештою, я налагоджую свій код поетапно. Я вважаю, що проблема, спричинена розміром даних, не збалансована для кожного розділу, що призвело до того, MetadataFetchFailedExceptionщо mapстадія не reduceстадія. просто зробітьdf_rdd.repartition(nums) ранішеreduceByKey()