Перейти на PRO

Что происходит после отправки задания в Spark (spark-submit)?

Тип вопроса: Apache Spark Вероятность: 33% Категория: Data Инженер

Ответ

После выполнения spark-submit запускается цепочка событий для распределенного выполнения кода. Вот что происходит под капотом на примере кластера YARN:

1. Запуск драйвера (Driver Program):

  • Команда spark-submit инициирует запуск Spark Driver — главного процесса вашего приложения.
  • В режиме --deploy-mode client драйвер работает на той же машине, откуда была запущена команда. В режиме cluster — на одной из нод кластера (обычно на ApplicationMaster в YARN).
  • Драйвер создает SparkContext, который является точкой входа во все функции Spark.

2. Запрос ресурсов у кластера:

  • SparkContext подключается к менеджеру ресурсов кластера (YARN ResourceManager, Mesos Master или Spark Standalone Master).
  • Он запрашивает ресурсы (ядра CPU и память) для Executor'ов — рабочих процессов, которые будут выполнять задачи.

3. Распределение и выполнение кода:

  • Менеджер ресурсов выделяет контейнеры на Worker-нодах и запускает в них Executor'ы.
  • Driver отправляет код приложения (JAR или Python-файлы) и задачи на Executor'ы.
  • Планировщик (DAGScheduler) внутри драйвера:
    1. Разбивает вычисления, построенные на RDD или DataFrame, на Directed Acyclic Graph (DAG) операций.
    2. Разделяет DAG на Stages (этапы) на основе операций shuffle (например, groupBy, join).
    3. Каждый Stage состоит из множества Tasks — элементарных единиц работы, которые выполняют одну и ту же функцию над разными частями данных (партициями).
  • TaskScheduler отправляет Tasks на свободные Executor'ы для параллельного выполнения.

4. Мониторинг и завершение:

  • Driver отслеживает выполнение Tasks, собирает результаты (например, при действиях collect(), count()) или записывает данные во внешние системы.
  • После завершения всех задач или при вызове spark.stop() Spark освобождает ресурсы, и приложение завершается.

Пример и наблюдение:

spark-submit 
  --master yarn 
  --deploy-mode cluster 
  --executor-memory 4g 
  my_etl_job.py

Ход выполнения можно отслеживать через веб-UI Spark на порту 4040 драйвера или через интерфейс YARN ResourceManager.

Ответ 18+ 🔞

А, ну это же классика! Слушай, тут всё просто, как три копейки, но под капотом творится ёперный театр. Представь, ты запускаешь spark-submit — и понеслась, блядь, цепная реакция, как в хорошем голливудском боевике, только вместо взрывов — контейнеры и таски.

1. Драйвер встаёт на крыло (Driver Program): Твоя команда — это как красная кнопка. Жмёшь — и выезжает главный по тарелкам, Spark Driver. Это мозг всей операции, чувак. Если ты указал --deploy-mode client, то этот мозг остаётся прямо у тебя на машине, откуда запустил. А если cluster — то он, хитрая жопа, улетает исполняться куда-то в недра кластера, обычно на какую-то ноду. Его первое дело — создать SparkContext. Это типа пропуск в закрытый клуб, без него нихуя не сделаешь.

2. Начинается дележка ресурсов: Дальше наш SparkContext идёт, сука, выпрашивать бюджеты у большого начальства — у менеджера ресурсов кластера (YARN ResourceManager, например). Он там такой: «Слушай, дай мне ядер и памяти, мне надо рабочих запустить, Executor'ов!». И начинает торговаться, как на базаре.

3. Главное представление — распределёнка и работа: Менеджер, если ресурсы есть, выделяет контейнеры на рабочих нодах и запускает в них этих самых Executor'ов. Это уже реальные паханы, которые будут таски таскать. Драйвер шлёт им код твоего приложения (твой JAR или питоновский файл) и задания. А внутри драйвера сидит ещё один важный чувак — Планировщик (DAGScheduler). Вот его работа — это просто песня, ядрёна вошь!

  1. Он берёт все твои красивые преобразования над RDD или DataFrame и строит из них граф — Directed Acyclic Graph (DAG). Это чтобы понимать, что от чего зависит.
  2. Потом он режет этот граф на Stages (этапы). Режет он его по швам, по операциям shuffle (типа groupBy или join). Каждый такой Stage — это как отдельный забег.
  3. А каждый Stage уже состоит из кучи Tasks — это самые мелкие кирпичики, одинаковые кусочки работы, которые надо выполнить над разными кусками данных. Дальше TaskScheduler хватает эти таски и, как опытный диспетчер, швыряет их на свободные Executor'ы, чтобы те пахали параллельно. Вот тут и начинается настоящая магия распределёнки.

4. Финишная прямая — слежка и уборка: Драйвер не спит, он следит, как его подчинённые работают. Собирает результаты (когда ты вызываешь collect() или count()), или пишет всё в итоговую систему. Когда всё сделано или ты сказал spark.stop(), Spark со вздохом облегчения отпускает все захваченные ресурсы обратно в кластер, и приложение накрывается медным тазом. Всё, шоу окончено.

Пример для наглядности и где смотреть:

spark-submit 
  --master yarn 
  --deploy-mode cluster 
  --executor-memory 4g 
  my_etl_job.py

Запустил такую команду — и можешь идти пить чай. А чтобы не скучать, наблюдай за цирком через веб-морду Spark (обычно на порту 4040 у драйвера) или через интерфейс YARN ResourceManager. Там всё красиво, блядь, стрелочки бегают, проценты заполняются. Удовольствие, ёпта!

© ХакСобесов, 2026
support@hacksobesov.com