Вопросы по теме «Теория множеств и дедупликация»
Объединение, пересечение, разность множеств, DISTINCT, дедупликация — базовые операции при работе с данными. На собеседовании просят найти пользователей, которые есть в одной таблице, но отсутствуют в другой, или объяснить, почему UNION и UNION ALL дают разные результаты. Ошибки в дедупликации ведут к двойному подсчёту метрик.
Всего в этом разделе 20 вопросов. Каждый — с правильным ответом и кратким разбором теории. Разбито на 4 части по 5 вопросов.
Вопросы 1–5 из 20
1В таблице `orders` каждая строка — один `order` (`event`), а один `user_id` может сделать несколько `orders`. Вы хотите посчитать число `buyers` как `unique users`. Какой счётчик соответствует задаче `deduplication` `buyers`?
A`COUNT(*)` по `orders`
B`COUNT(DISTINCT order_id)`
C`COUNT(DISTINCT user_id)`
D`SUM(order_amount)`
Ответ: Для подсчёта `buyers` как `unique users` нужна `deduplication` по `user_id`, а не по `events`.
Счётчик `COUNT(*)` или `COUNT(DISTINCT order_id)` показывает количество `orders`, то есть `events`, и растёт, если один `user` покупает много раз. Для аудитории `buyers` нужно считать уникальные `user_id`, то есть размер `set` `buyers`. Этот `проверка здравого смысла` помогает не перепутать метрики объёма продаж и охвата `unique users`.
2В `events` за день 2 млн `events`, а в отчёте по `audience` 1.2 млн `unique users`. Какое объяснение наиболее вероятно?
AОдин и тот же `user_id` может сгенерировать много `events`, поэтому `events` обычно больше, чем `unique users`.
BПосле `deduplication` количество `events` всегда должно стать равно числу `unique users`.
C`unique users` считаются как `intersection` двух `set`, поэтому число всегда меньше `events`.
D`unique users` — это то же самое, что `union` всех `events`, поэтому разницы быть не должно.
Ответ: Число `events` и число `unique users` измеряют разные `units` и не обязаны совпадать.
В одном `set` `events` один `user_id` может встречаться много раз, поэтому счётчик `events` растёт быстрее. Метрика `unique users` делает `deduplication` по `user_id` и считает каждого `user` один раз за период. Такой `проверка здравого смысла` помогает не перепутать объём `events` с размером `audience`.
3Для метрики `retention` вы определяете `set` `A` = `unique users`, активные в неделю 1, и `set` `B` = `unique users`, активные в неделю 2. Какой `set` соответствует вернувшимся `users`?
A`union` `A` и `B`
B`set` `A` без `intersection` с `B` (активны только в неделе 1)
C`intersection` `A` и `B`
D`set` `B` без `intersection` с `A` (активны только в неделе 2)
Ответ: Вернувшиеся `users` — это `intersection` между `set` активных в разные периоды.
Для `retention` важно найти `unique users`, которые присутствуют в обоих периодах, то есть в `intersection`. `Union` показывает всех, кто был активен хотя бы раз, и не отражает возвращаемость. Такая логика помогает корректно строить когортные отчёты и избегать ошибок в `deduplication`.
4В `channel` `search` 400 тыс `unique users`, в `channel` `social` 300 тыс `unique users`, а `overlap` (`intersection`) между ними 100 тыс `unique users`. Сколько `unique users` в `union` этих двух `set`?
A700 тыс
B600 тыс
C500 тыс
D300 тыс
Ответ: Для двух `set` размер `union` равен сумме размеров минус `intersection` по принципу `включение–исключение`.
Если просто сложить два `channel`, `overlap` будет посчитан дважды. Поэтому используйте `включение–исключение`: `|A union B| = |A| + |B| - |A intersection B|`. Это базовый приём для оценки `unique users` по нескольким `channel`.
5В отчёте вы видите `unique users` по `channel`: `email` 200 тыс, `push` 150 тыс, `sms` 50 тыс. Сумма по строкам 400 тыс, но общий итог по всем `channel` показывает 260 тыс `unique users`. Что это чаще всего означает?
AВ итоговой строке ошибка: общий итог обязан быть равен сумме по `channel`.
BВ отчёте перепутаны `units`: нужно делить сумму на количество `channel`.
CЕсть `overlap` между `channel`, а общий итог считает `union` с `deduplication`, поэтому сумма по `channel` может быть больше итога.
D`intersection` между всеми `channel` равна 0, поэтому итог должен быть больше суммы.
Ответ: Суммирование по `channel` обычно двойно считает `overlap`, а общий итог считает `union` после `deduplication`.
Один `user_id` мог попасть сразу в несколько `channel`, поэтому он окажется в нескольких строках. Общая строка обычно строится как `union` по всем `channel` и делает `deduplication` на уровне `unique users`. Поэтому несхождение суммы и итога — нормальный сигнал наличия `overlap`, а не обязательно баг.
Хотите тренировать интерактивно?
В приложении — таймер, прогресс, стрики и 1700+ вопросов по всем темам.
Тренировать в Telegram