Простое объяснение памяти исполнителей Spark: где обрабатываются части данных, что бывает при нехватке места и как искать причину.
Координатор и рабочие процессы
Spark распределяет большую работу между несколькими процессами. Управляющий процесс, который называют драйвером, строит план и отправляет задачи. Исполнители получают части данных и выполняют вычисления. Поэтому свободное место у драйвера не означает, что отдельному исполнителю хватит памяти для своей части работы. Это похоже на редакцию: у главного редактора может быть свободный стол, но сотруднику всё равно негде разложить большую пачку документов.
В официальном обзоре архитектуры Spark разделены роли драйвера и исполнителей: исполнители запускают задачи и хранят данные для приложения. Называть их просто «серверами» неточно: на одном рабочем узле могут работать процессы с собственными пределами ресурсов. Если ошибка возникла у исполнителя, исследовать надо его работу, а не только память управляющего процесса.
На что расходуется память исполнителя
Память нужна не только для исходной части таблицы. Во время вычисления Spark сортирует записи, соединяет наборы и собирает итоги; иногда он сохраняет промежуточный результат для повторного использования. Документация Spark разделяет память на область вычислений и область хранения. Они могут делить доступное пространство, поэтому решение сохранить ещё один набор для ускорения следующего шага влияет на текущую обработку.
Объём в файле не равен объёму в оперативной памяти. После чтения данные превращаются во внутренние структуры, а операции над ними создают дополнительные объекты. Поэтому оценка «файл небольшой, всё поместится» ненадёжна. В статье о кэше Spark отдельно объясняется, когда сохранение промежуточных данных помогает, а когда только расходует ресурс.
Что происходит, когда места не хватает
Часть промежуточных данных Spark может перенести на диск; обработка при этом обычно замедляется. Если рабочему процессу всё равно недостаёт памяти, задача может завершиться ошибкой или повторяться после сбоя. Но долгая работа сама по себе не доказывает именно нехватку памяти: причиной могут быть медленное хранилище, неравномерное распределение данных или ожидание соседнего шага. Диагноз ставят по показателям задачи и сообщениям о сбое.
Важно различать место для обработки у исполнителя и ситуацию, когда итоговые данные пытаются собрать у драйвера. Это разные места отказа. Отдельный материал про память драйвера Spark помогает понять вторую ситуацию. Увеличение общего числа машин не всегда лечит первую: если одну часть данных должен обработать один перегруженный исполнитель, нагрузка остаётся неравномерной.
Условный пример с перекосом
Представьте миллион заказов, которые распределили по городам. Большинство городов дали небольшие группы, а один мегаполис — почти половину всех записей. Если операция требует обработать целую группу вместе, исполнитель с этой группой получает гораздо больше работы и временных данных, чем остальные. Дополнительные свободные исполнители в этот момент могут простаивать. В таком случае сначала проверяют, почему работа распределилась именно так; простое увеличение памяти может лишь отложить проблему.
Это условная иллюстрация, а не правило для любого соединения или группировки. Разные операции Spark распределяют данные по-разному. Перед изменением ресурсов полезно посмотреть размеры частей, длительность задач и место сбоя. Результат сравнивают с обычным запуском на том же объёме данных, а не только с одним удачным повтором.
Как искать причину без догадок
Начните с ответа на три вопроса: какой процесс сообщил об ошибке, на каком этапе она возникла и одинаково ли долго работали части задания. Интерфейс мониторинга Spark показывает задачи и показатели исполнителей; официальная документация описывает метрики памяти, передаваемые от исполнителей. Затем выясните, не вырос ли входной набор, не изменилось ли распределение и не добавили ли сохранение промежуточных данных.
Такой разбор полезнее универсального совета «добавить памяти»: он показывает, нужен ли другой порядок обработки, исправление перекоса или действительно больше ресурсов. Если вы хотите разбираться в распределённой обработке на практике, посмотрите курс «PySpark для инженеров и аналитиков данных» и сопоставьте его темы со своими задачами.
