Какой тип JOIN используется по умолчанию при написании просто JOIN

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

Базовый SQL плюс понимание, как соединение меняет выборку для анализа или обучения модели. Сильный кандидат сразу говорит, что потерянные строки означают смещение в данных. Следом просят сравнить поведение по умолчанию в SQL и в pandas или Spark.

Как отвечать

В SQL просто JOIN означает INNER JOIN: остаются только строки, у которых нашлась пара по условию ON. Слова INNER и OUTER необязательны.

Для data-роли важно, что умолчания в инструментах разные:

• SQL, Spark SQL, PySpark: df.join(other, on="user_id") без how делает внутреннее соединение;
• pandas merge: по умолчанию how="inner";
• pandas DataFrame.join: по умолчанию how="left", соединение по индексу;
• polars join: по умолчанию how="inner".

Отсюда практические правила при сборке признаков:

• считайте строки до и после соединения: если таблица событий после JOIN со справочником заметно похудела, вы потеряли объекты без пары, и они почти никогда не случайны. Например, пропадают новые пользователи без профиля, и модель потом плохо работает именно на них;
• проверяйте кратность ключа: при связи «один ко многим» строки размножаются, а агрегаты и веса классов плывут. В pandas помогает validate="many_to_one", в SQL предварительный GROUP BY key HAVING COUNT(*) > 1;
• indicator=True в merge: добавляет колонку _merge и сразу показывает, сколько строк было только слева или только справа.

Если терять строки нельзя, берите LEFT JOIN от основной таблицы и заполняйте пропуски осознанно.

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

Отвечают «LEFT JOIN», потому что привыкли к DataFrame.join в pandas. Путаница умолчаний между SQL и pandas встречается постоянно.

Не замечают, что NULL в ключе не совпадает ни с чем. Строки с пустым user_id пропадают из обучающей выборки без единой ошибки в логах.

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