Почему Spark решил сделать всю работу на одном узле? - PullRequest
Новая
       22

Почему Spark решил сделать всю работу на одном узле?

0 голосов
/ 28 января 2019

У меня возникли проблемы с заданием Spark, которое примерно в половине случаев выберет обработку всех данных на одном узле, который затем исчерпывает память и умирает.

Вопрос: Как я могу гарантировать, что это происходит не раз?

Система использует Spark 1.6.0 на Yarn, вытягивая из хранилища данных Hadoop 2.6,со всем кодом, написанным на Java.У меня есть ресурсы, динамически распределяемые по кластеру с дюжиной узлов (Amazon).

Группа обеспечения доступности баз данных относительно проста: 

RDD --> mapToPair \  
                   coGroup --> flatMapToPair --> reduceByKey --> save
RDD --> mapToPair /

При правильной работе все задачи выполняются успешно.распределены по кластеру и вся работа занимает порядка 20 минут.Мы назовем это «хорошим поведением».Однако иногда этап flatMapToPair эффективно выполняется в одном исполнителе.Мы будем называть это «плохим поведением»

Когда я загружаю интерфейс Spark для задания «плохого поведения» и углубляюсь в стадию flatMapToPair, я вижу, что на самом деле около 3-4 исполнителей работаютна каждом узле (так же, как в случае «хорошего поведения»).Однако все, кроме одного, заканчиваются за доли секунды, а оставшийся исполнитель работает в течение 10 секунд, прежде чем его убьет пряжа за превышение пределов памяти.

То, что я уже пробовал:

  1. Интернет.Выполняется поиск таких вещей, как «запуск по искру на одном узле», и вариации почти повсеместно приводят к тому, что люди работают в локальном режиме в оболочке искры или схожими проблемами конфигурации.Учитывая, что я получаю хорошее поведение, по крайней мере, в какое-то время, такие проблемы конфигурации кажутся маловероятными (и я проверил, что я не случайно в локальном режиме, у меня ~ 100 разделов, ...).

  2. Другие задания Spark, запущенные в том же кластере, работают хорошо.Казалось бы, это исключает некоторую неверную конфигурацию всего кластера (черт, даже это задание иногда работает хорошо).

  3. Использование кластера, похоже, не влияет на то, получаю ли яхорошее поведение или плохое поведение.Я видел оба поведения как при интенсивном использовании кластера, так и когда в кластере больше ничего не работает.

  4. Это не похоже на проблему пряжи со времен исполнителей все они хорошо распределены по кластеру.Конечно, я могу ошибаться, но на самом деле проблема заключается в распределении работы между исполнителями.

  5. Существует более одного ключа внабор данных.Я вставил countByKey между coGroup и flatMapToPair и напечатал результаты (для примерно 20 самых популярных ключей).Данные были довольно равномерно распределены между этими верхними клавишами.

Вещи, которые я пробовал в ответ на комментарии

  1. ПеределСДР прямо перед вызовом flatMapToPair для форсирования 500 разделов.Это только переместило плохое поведение на стадию передела.

  2. Увеличьте параллелизм по умолчанию.Таким образом я получаю больше разделов, но плохое поведение остается на этапе flatMapToPair.

  3. Сокращение данных (на самом деле я сделал много этого перед публикацией, но не смог включить егов первоначальном списке).У нас всего несколько десятков ГБ, и я уже загружаю необходимые минимальные данные.

Это был "забавный" маленький гейзенбаг с плохим поведением, уходящим последобавление журнала отладки, а затем удаление после удаления журнала, только чтобы появиться через некоторое время.У меня нет идей, поэтому, если у кого-то есть какие-то рекомендуемые диагностические шаги, я весь в ушах.

...