Краткий ответ

Причина — удаление дубликатов при объединении. Операция типа UNION возвращает множество уникальных строк, поэтому одинаковые строки, присутствующие в обоих наборах, учитываются один раз; UNION ALL сохраняет все строки.

Исторический контекст

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

В SQL были добавлены два варианта поведения: объединение с удалением дублей для работы с логическими множествами и объединение всех строк для сохранения фактических наблюдений. Различие важно, потому что SQL-таблицы на практике могут содержать повторяющиеся строки.

Постановка проблемы

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

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

Подробное решение

Операция с удалением дублей сравнивает результирующие строки по всем выбранным столбцам. Если значения во всех этих столбцах совпадают, строки считаются одинаковыми и в результате остаётся одна строка.

SELECT user_id, event_date FROM source_a
UNION
SELECT user_id, event_date FROM source_b;

SELECT user_id, event_date FROM source_a
UNION ALL
SELECT user_id, event_date FROM source_b;

В первом случае повторяющиеся пары user_id и event_date удаляются, во втором — сохраняются. Выбор зависит от смысла данных: если источники являются двумя представлениями одного набора событий, нужна дедупликация; если это независимые поставки или повторные события, удалять строки нельзя.

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

Для контроля полезно отдельно сравнить количество строк в источниках, количество строк после объединения и число совпадений по предполагаемому ключу. Если требуется объединить данные по пользователям, но сохранить события, дедупликацию следует выполнять на уровне события, а не по одним только идентификаторам пользователя.

Ситуация из практики

Две системы выгружают покупки за день. В первой оказалось 100 000 строк, во второй — 20 000, причём 5 000 покупок присутствуют в обеих выгрузках.

Вариант с объединением и удалением дублей даст 115 000 строк. Его плюс — защита от повторной загрузки одних и тех же покупок; минус — корректные повторные события могут быть ошибочно удалены, если выбранные столбцы не образуют настоящий ключ.

Вариант с объединением всех строк даст 120 000 строк. Его плюс — сохранение всех поступивших записей; минус — дублированные покупки завысят число заказов и выручку. Выбранное решение — объединить все строки по техническому идентификатору покупки, а затем удалить только записи с одинаковым идентификатором и проверить конфликтующие атрибуты. Это сохраняет реальные покупки и устраняет повторную доставку одной покупки.

Что кандидаты часто упускают

Всегда ли совпадение всех выбранных столбцов означает дубликат?

Нет. Если в выборке отсутствует идентификатор события, два разных события могут иметь одинаковые значения даты, пользователя и суммы. Удаление таких строк исказит частоту событий и связанные метрики. Сначала нужно определить бизнес-сущность строки и её ключ.

Чем удаление дублей при объединении отличается от удаления дублей после объединения?

При обычном UNION результат сравнивается по всем столбцам, указанным в обеих частях операции. Если после объединения применить дедупликацию по бизнес-ключу, можно явно задать, какие записи считать одной сущностью, и выбрать приоритет источника или более свежую версию. Это обычно безопаснее, когда полный набор столбцов может различаться из-за исправлений или технических полей.

Почему нельзя выбирать вариант объединения только по ожидаемому числу строк?

Количество строк само по себе не показывает, сохранены ли реальные наблюдения. Меньшее число может означать корректное устранение повторной загрузки, а большее — сохранение необходимых повторных событий или неустранённые дубли. Решение должно опираться на гранулярность данных, ключ записи и правила формирования метрики; итог нужно проверять контрольными агрегатами, например числом уникальных покупок и общей выручкой.