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