Можно ли джойнить с базой данных по артикулу для получения категории товара?

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

Вопрос обычно задают посреди задачи на пайплайн: есть поток продаж или событий с артикулом, нужна категория. Проверяют, подумаете ли вы о ключе, кратности связи и объёме, а не только напишете JOIN. Следом спрашивают, что будет, если артикул не уникален или категория меняется.

Как отвечать

Да, можно, но сначала задайте три вопроса к данным:

• уникален ли артикул в справочнике товаров. На маркетплейсе он часто уникален только в паре с продавцом, и джойн по одному артикулу размножит строки. Проверка простая: GROUP BY article HAVING count(*) > 1;
• что делать с неизвестными артикулами. INNER JOIN молча выкинет продажи без карточки, и выручка в отчёте уменьшится. Обычно берут LEFT JOIN, кладут такие строки в категорию «неизвестно» и следят за их долей как за метрикой качества;
• меняется ли категория во времени. Если товар переносили между категориями, джойн с текущим справочником перепишет историю. Нужна версионность (SCD Type 2 с valid_from и valid_to) и условие по дате события.

Отдельно нормализуйте ключ: тип (строка против числа), ведущие нули, пробелы, регистр. Заметная часть «потерянных» строк в таких джойнах получается из-за '00123' против 123.

Дальше про исполнение. Справочник товаров обычно намного меньше фактов, поэтому в Spark это broadcast join: явно через broadcast(dim) или автоматически, пока таблица меньше spark.sql.autoBroadcastJoinThreshold (по умолчанию 10 МБ). Если справочник живёт в продовой OLTP-базе, не ходите в неё из пайплайна построчно: выгрузите снапшот в хранилище и джойните уже там.

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

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

Берут INNER JOIN по привычке и теряют данные без единой ошибки в логах.

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