Теория множеств и дедупликация: вопросы для собеседования (часть 4)
Объединение, пересечение, разность множеств, DISTINCT, дедупликация — базовые операции при работе с данными. На собеседовании просят найти пользователей, которые есть в одной таблице, но отсутствуют в другой, или объяснить, почему UNION и UNION ALL дают разные результаты. Ошибки в дедупликации ведут к двойному подсчёту метрик.
Вопросы 16–20 из 20
16При расчёте `union` трёх `set` вы посчитали `|A union B union C| = |A| + |B| + |C| - |A intersection B| - |A intersection C| - |B intersection C|`, но не добавили `|A intersection B intersection C|`. Какое смещение в оценке `union` вы получите?
AПереоцените `union`, это станет `верхняя граница`.
BНедооцените `union`, потому что тройной `overlap` нужно добавить обратно; без него получается `нижняя граница`.
CОценка не изменится, тройной `intersection` всегда равен 0.
DНедооцените `intersection`, но `union` останется точным.
Ответ: В `включение–исключение` для трёх `set` тройной `intersection` добавляют, иначе `union` получается заниженным.
Тройной `overlap` входит в каждое одиночное множество и в каждое парное `intersection`, поэтому при вычитании парных пересечений он обнуляется. Но в `union` он должен учитываться один раз, поэтому его нужно добавить обратно. Если тройной `intersection` неизвестен, выражение без него даёт `нижняя граница` для `union`. Это типичный `проверка здравого смысла` при работе с тремя `channel`.
17У вас три `set` для трёх `campaign`: известны `|A|`, `|B|`, `|C|` и все парные `intersection`, но тройная `intersection` неизвестна. Что корректнее всего сделать, если нужно оценить `union` без доступа к сырым данным?
AПосчитать `union` как `|A| + |B| + |C|` и игнорировать `overlap`.
BИспользовать принцип `включение–исключение`, но признать неопределённость тройной `intersection` и дать `границы` для `union` (или запросить тройную `intersection`).
CВзять среднее из `|A|`, `|B|`, `|C|` и назвать это `union`.
DВыбрать максимальный `set` и считать его `union`, потому что `intersection` всё исправит.
Ответ: Для трёх `set` точный `union` по `включение–исключение` требует тройной `intersection`, иначе остаются только `границы`.
Парные `intersection` недостаточны, потому что тройной `overlap` влияет на итог через плюс в формуле `включение–исключение`. Без него вы можете построить диапазон возможных значений `union`, используя `нижняя граница` и `верхняя граница` для тройной `intersection`. В продуктовой аналитике важно явно проговаривать такие `assumptions`, чтобы не выдавать оценку за точный факт. Лучший вариант — запросить расчёт тройной `intersection` по сырым данным.
18Вы делаете `JOIN` таблицы `users` (1 строка на `user_id`) с таблицей `events` (много строк на `user_id`) и считаете `COUNT(users.user_id)` как `unique users` в `campaign`. Получилось завышение. Какое исправление наиболее корректно?
AЗаменить `JOIN` на `union`, тогда `intersection` исчезнет.
BОставить `COUNT(users.user_id)` и разделить на среднее число `events`.
CСчитать `COUNT(DISTINCT event_id)`, это и есть `unique users`.
DСделать `deduplication` на уровне `user_id`: использовать `COUNT(DISTINCT users.user_id)` или предварительно агрегировать `events` до `set` `user_id`.
Ответ: После `JOIN` один `user_id` может повториться много раз, поэтому для `unique users` нужна `deduplication` через `DISTINCT`.
Когда вы присоединяете `events` к `users`, каждая строка `events` размножает строку `user_id`. Счётчик без `deduplication` превращается в счётчик `events`, а не аудитории `unique users`. Правильный `проверка здравого смысла` — убедиться, что вы считаете размер `set` `user_id`, например через `COUNT(DISTINCT user_id)`. Это одна из самых частых ошибок уникальных подсчётов в аналитике.
19Вы строите отчёт по `platform` и видите `ios` и `android`. Какое утверждение о `intersection` наиболее корректно в зависимости от ключа `deduplication`?
AЕсли считать по `user_id`, то `intersection` между `ios` и `android` всегда равна 0.
BЕсли считать по `device_id`, то `intersection` между `ios` и `android` всегда больше 0.
CЕсли `intersection` между `ios` и `android` не нулевая, значит обязательно ошибка в данных.
DЕсли считать `unique users` по `user_id`, возможен `overlap` (`intersection`), потому что один `user` может использовать два `device`; если считать по `device_id`, такие `set` обычно не пересекаются.
Ответ: Размер `intersection` зависит от ключа `deduplication`: `user_id` даёт кросс-`platform` `overlap`, `device_id` делает `set` почти раздельными.
Если цель — считать людей, используйте `user_id`, и тогда один `user` может попадать в `ios` и `android`, создавая `intersection`. Если цель — считать устройства, то `device_id` обычно уникален в пределах одного `platform`, и `intersection` будет близка к 0. В интервью важно уточнять `units` и ключ `deduplication`, иначе выводы про `overlap` будут неверными.
20У вас три `set` `channel`: `email` 100 тыс `unique users`, `push` 120 тыс `unique users`, `sms` 60 тыс `unique users`. Парные `intersection`: `email` и `push` = 40 тыс, `email` и `sms` = 10 тыс, `push` и `sms` = 20 тыс. Тройной `overlap` (`intersection` всех трёх) = 5 тыс. Сколько `unique users` в `union` трёх `set` по `включение–исключение`?
A210 тыс
B205 тыс
C280 тыс
D215 тыс
Ответ: Для трёх `set` `включение–исключение` использует сумму размеров, минус парные `intersection`, плюс тройной `intersection`.
При суммировании тройной `overlap` учитывается три раза, а при вычитании парных `intersection` он вычитается тоже три раза, поэтому его нужно добавить обратно один раз. Формула: `|A union B union C| = |A| + |B| + |C| - |A intersection B| - |A intersection C| - |B intersection C| + |A intersection B intersection C|`. Это типовая задача для оценки `unique users` охвата по нескольким `channel`.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram