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

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

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

Как отвечать

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

Broadcast join это стратегия для случая «большая таблица фактов и маленький справочник». Копия справочника отправляется на каждый узел, и большая таблица соединяется с ней на месте, никуда не переезжая. Ситуация типичная для аналитика: витрина транзакций и словарь категорий, регионов или тарифов.

Попросить явно можно подсказкой прямо в запросе:

select /*+ BROADCAST(d) */ t.client_id, d.category_name
from transactions t
join dim_category d on d.id = t.category_id

В PySpark то же делает функция broadcast вокруг маленького датафрейма. Проверка одна: в плане выполнения вместо sort merge join появляется broadcast hash join, план виден через explain или во вкладке SQL в интерфейсе Spark.

Граница применимости: справочник должен быть действительно небольшим, его копия живёт в памяти каждого узла.

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

Считают подсказку волшебной настройкой и вешают её на обе стороны соединения. Рассылать большую таблицу бессмысленно, и запрос либо игнорирует подсказку, либо падает по памяти.

Меряют размер справочника числом строк. Важен объём в памяти, а таблица из немногих строк с длинными текстовыми полями и вложенными структурами разворачивается заметно больше, чем кажется по счётчику.

Не смотрят план вообще. Вывод «стало быстрее» после случайной правки ничего не стоит: на тёплом кэше и другом объёме данных замер повторится иначе, а план показывает выбранную стратегию однозначно.