Теория множеств и дедупликация: вопросы для собеседования (часть 3)
Объединение, пересечение, разность множеств, DISTINCT, дедупликация — базовые операции при работе с данными. На собеседовании просят найти пользователей, которые есть в одной таблице, но отсутствуют в другой, или объяснить, почему UNION и UNION ALL дают разные результаты. Ошибки в дедупликации ведут к двойному подсчёту метрик.
Вопросы 11–15 из 20
11В отчёте: `set` `A` = 400 тыс `unique users`, `set` `B` = 300 тыс `unique users`. При этом заявлено, что `union` равен 900 тыс `unique users`. Какой `проверка здравого смысла` по `границы` самый верный?
AЭто невозможно: по `границы` размер `union` должен быть между `нижняя граница` 400 тыс и `верхняя граница` 700 тыс.
BЭто возможно, если `intersection` очень большая.
CЭто возможно, если выполнить `deduplication` по `event_id`.
DЭто возможно, если `overlap` равен 0 и добавить ещё один `channel`.
Ответ: Для двух `set` размер `union` имеет очевидные `границы`: не меньше максимума и не больше суммы.
Нижняя граница (`нижняя граница`) равна `max(|A|, |B|)`, потому что `union` содержит как минимум самый большой `set`. Верхняя граница (`верхняя граница`) равна `|A| + |B|`, когда `overlap` отсутствует. Если отчёт нарушает эти `границы`, скорее всего перепутали `units`, ключ `deduplication` или сложили метрики неправильно. Такой `проверка здравого смысла` быстро отсекает невозможные значения.
12Маркетинг просит сегмент `unique users`, которые являются `buyers` продукта `A` и `buyers` продукта `B` за месяц. Какая операция над `set` `buyers` соответствует запросу?
A`union` `buyers` продукта `A` и `buyers` продукта `B`
B`overlap` `buyers` продукта `A` и `buyers` продукта `B` плюс `union`
C`intersection` `buyers` продукта `A` и `buyers` продукта `B`
D`deduplication` по `order_id` без учёта `user_id`
Ответ: Сегмент `users`, совершивших оба действия, соответствует `intersection` двух `set`.
`Union` отвечает на вопрос кто является `buyer` хотя бы одного продукта, а `intersection` — кто является `buyer` обоих. В аналитике это типичный источник ошибок, когда считают «кросс-селл» как сумму или `union`. Правильная постановка через `set` операции сразу делает задачу однозначной и помогает избежать неверной `deduplication`.
13У вас `unique users` в `web` = 500 тыс, в `app` = 400 тыс, а общий `union` по `user_id` = 700 тыс. Какой `intersection` (`overlap`) между `web` и `app`?
A200 тыс
B700 тыс
C900 тыс
D100 тыс
Ответ: Для двух `set` `intersection` можно восстановить из `union`: `|A intersection B| = |A| + |B| - |A union B|`.
Если вы знаете размеры `set` по отдельности и их `union`, то `intersection` — это то, что было посчитано дважды. В примере 500 + 400 - 700 = 200 тыс. Такие расчёты помогают объяснить, почему сумма по источникам не сходится с общим `unique users`. Также это полезный `проверка здравого смысла` на реалистичность `overlap`.
14Для `campaign` у вас есть таблицы `impressions` и `clicks` (оба — `events`). Маркетинг спрашивает, сколько `unique users` и видели, и кликали. Что нужно посчитать?
AСложить `unique users` из `impressions` и `unique users` из `clicks`.
BПосчитать `union` `impressions` и `clicks` и назвать это кликнувшими.
CСделать `deduplication` по `user_id` в обоих `set` и взять их `intersection`.
DПосчитать количество `clicks` `events`, потому что каждый клик — это уникальный `user`.
Ответ: Сколько `unique users` сделали два действия, определяется как `intersection` двух `set` по `user_id`.
Сначала определите два `set`: `user_id`, которые есть в `impressions`, и `user_id`, которые есть в `clicks`. Затем найдите их `intersection`, потому что вам нужны те, кто принадлежит обоим `set`. Сумма или `union` ответит на другой вопрос и будет завышена из-за отсутствия правильной `deduplication`. Это частая ошибка, когда путают `events` и `unique users`.
15Вы хотите оценить общий `union` `unique users` между `web` и `app`. В `web` ключ — `cookie_id`, в `app` ключ — `user_id`, и прямого соответствия между ними нет. Какое решение наиболее корректно с точки зрения `deduplication` и `constraints`?
AПросто сложить `unique users` из `web` и `app`: `overlap` можно игнорировать.
BВсегда считать, что `overlap` равен 0, потому что ключи разные.
CВсегда считать, что `overlap` равен 100%, потому что это один продукт.
DПризнать, что точный `deduplication` невозможен без `identity` связи, и либо построить маппинг `cookie_id`→`user_id`, либо дать `границы` для `union` (между `нижняя граница` и `верхняя граница`).
Ответ: Без общего `identity` ключа точный `union` `unique users` нельзя получить, остаются маппинг или `границы`.
Разные идентификаторы создают неопределённый `overlap`: часть людей будет в обоих источниках, но вы не знаете, какая именно. Корректная аналитика либо строит `identity` маппинг, либо честно даёт диапазон `границы` для `union`. `Lower bound` — это максимум из двух аудиторий, `верхняя граница` — их сумма. Такой ответ показывает зрелое понимание ограничений `deduplication`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram