Что такое broadcast join в Spark и зачем он нужен

Что проверяют

Понимаете ли вы, почему соединение в распределённой системе дорогое, и умеете ли выбирать стратегию осознанно. Для инженера данных это ежедневный инструмент: верно поставленный broadcast превращает многочасовой шаг конвейера в минуты.

Как отвечать

Обычное соединение в Spark это shuffle: обе стороны перераспределяются по хешу ключа, чтобы одинаковые ключи попали в один исполнитель. Shuffle пишет промежуточные файлы на диск и гоняет данные по сети, и это самая дорогая операция в задании.

Broadcast join убирает shuffle целиком. Маленькая сторона собирается на драйвере, рассылается на каждый исполнитель, там по ней строится хеш-таблица, и большая сторона соединяется локально, не двигаясь с места.

Когда включать: одна сторона мала, например справочник или список активных клиентов, вторая велика. Spark применяет стратегию сам, когда оценка размера ниже порога autoBroadcastJoinThreshold, но оценка часто врёт на сжатых и производных данных, поэтому подсказку ставят явно.

from pyspark.sql.functions import broadcast
result = large_df.join(broadcast(dim_df), "client_id")

Ограничения назовите сами: копия справочника лежит в памяти каждого исполнителя, полное внешнее соединение так не выполняется, а при одностороннем внешнем рассылать можно только противоположную сторону.

Где спотыкаются

Оценивают размер на глаз по файлам. Колоночный сжатый формат разворачивается в памяти в разы, и подсказка на такой таблице роняет драйвер, через который копия и собирается.

Ставят подсказку везде как универсальное ускорение. На средних таблицах она даёт нехватку памяти у исполнителей, и задание падает медленнее и дороже, чем отработало бы обычное соединение.

Не смотрят план и верят, что подсказка применилась. Spark вправе её проигнорировать, поэтому проверять надо по плану выполнения: там должен появиться broadcast hash join вместо sort merge join.