Теория множеств и дедупликация: вопросы для собеседования (часть 2)
Объединение, пересечение, разность множеств, DISTINCT, дедупликация — базовые операции при работе с данными. На собеседовании просят найти пользователей, которые есть в одной таблице, но отсутствуют в другой, или объяснить, почему UNION и UNION ALL дают разные результаты. Ошибки в дедупликации ведут к двойному подсчёту метрик.
Вопросы 6–10 из 20
6Чтобы посчитать `unique users` в `union` двух `set` `A` и `B`, зная `|A|`, `|B|` и `|A intersection B|`, какую формулу `включение–исключение` нужно использовать?
A`|A union B| = |A| + |B| + |A intersection B|`
B`|A union B| = |A| - |B| - |A intersection B|`
C`|A union B| = |A| * |B| / |A intersection B|`
D`|A union B| = |A| + |B| - |A intersection B|`
Ответ: Для двух `set` принцип `включение–исключение` требует вычесть `intersection`, чтобы убрать двойной счёт `overlap`.
Каждый `user` из `intersection` попадает и в `A`, и в `B`, поэтому при суммировании он считается дважды. Вычитание `|A intersection B|` возвращает правильный размер `union`. Эта формула лежит в основе многих задач про `unique users` по нескольким источникам.
7Вы считаете число `buyers` как `unique users` за день. В данных есть `device_id` и `user_id` (если `user` залогинен). Какой подход к `deduplication` чаще всего более корректен для подсчёта `buyers`?
AСчитать `unique users` по `user_id` там, где он есть, и отдельно продумать анонимных, чтобы один `user` на разных `device` не считался дважды.
BВсегда считать по `device_id`, потому что это гарантирует отсутствие `overlap`.
CСчитать по `order_id`, потому что это всегда равно `unique users`.
DСложить `unique users` по `device_id` и по `user_id`, чтобы получить полный `union`.
Ответ: Ключ `deduplication` должен соответствовать сущности, которую вы считаете: для `unique users` это обычно стабильный `user_id`.
Если один `user` совершает `purchase` с двух `device`, то подсчёт по `device_id` завышает аудиторию и увеличивает искусственный `overlap` между `platform`. Подсчёт по `user_id` ближе к бизнес-смыслу уникального человека, но требует решения для анонимных. Важно заранее определить, что считается `unique users`, и быть последовательным во всех отчётах.
8Аналитик сложил `DAU` за 30 дней и получил 3 млн, а `MAU` за тот же месяц равен 400 тыс `unique users`. Почему это может быть нормально?
AПотому что `MAU` всегда равен сумме `DAU` по дням.
BПотому что сумма `DAU` не делает `deduplication` между днями, а `MAU` — это `union` `unique users` за месяц.
CПотому что `DAU` считает `events`, а `MAU` считает `impressions`.
DПотому что `intersection` между днями всегда равна 0.
Ответ: Сумма `DAU` по дням двойно считает `overlap` пользователей между днями, а `MAU` считает `union`.
Один и тот же `user_id` может быть активен много дней подряд, и тогда он попадёт в каждый дневной `set` `DAU`. Сложение дневных значений не учитывает `intersection` между днями и завышает итог. `MAU` — это `deduplication` по `user_id` на уровне месяца, то есть `union` всех дневных `set`.
9У вас есть два источника `events`: `web_events` и `app_events`. В каждом вы умеете считать `unique users` по `user_id`. Как корректно получить общее число `unique users` по двум источникам?
AСделать `union` строк из обоих источников (по `user_id`) и затем посчитать `COUNT(DISTINCT user_id)` как `deduplication`.
BПосчитать `COUNT(DISTINCT user_id)` в каждом источнике и сложить результаты.
CПосчитать `COUNT(*)` в обоих источниках и назвать это `unique users`.
DВзять `intersection` источников и считать её как общий итог.
Ответ: Если `user_id` может быть и в `web_events`, и в `app_events`, то суммирование двух `unique users` без `union` завышает из-за `overlap`.
Здесь каждый источник — это `set` `user_id`, и вам нужен размер `union`. Самый прямой способ — объединить источники (`union`) и сделать `deduplication` через `COUNT(DISTINCT user_id)`. Если просто сложить два `COUNT(DISTINCT user_id)`, вы посчитаете `intersection` дважды и получите завышение. Такой `проверка здравого смысла` полезен для отчётов по `cross-platform` аудитории.
10В отчёте по `campaign` указано: `set` `A` имеет 100 тыс `unique users`, `set` `B` имеет 80 тыс `unique users`, а их `intersection` равна 120 тыс `unique users`. Какой вывод наиболее корректен?
AЭто возможно, потому что `intersection` может быть больше каждого `set`.
BЭто нарушает `constraints`: `intersection` не может превышать размер любого `set`, значит есть ошибка в `deduplication` или в определении `unique users`.
CЭто означает, что `union` равен 120 тыс `unique users`.
DЭто означает, что `overlap` отсутствует.
Ответ: По `constraints` размер `intersection` всегда меньше или равен размеру каждого `set`.
Если `intersection` больше `A`, значит вы считаете разные сущности или нарушили `deduplication` (например, в одном месте считаете `users`, а в другом `devices`). Такой `проверка здравого смысла` нужен, чтобы быстро обнаружить неверные ключи, дубли после джойнов или смешение `units`. До исправления нельзя интерпретировать `overlap` и `union`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram