SQL-проверки качества данных: дубли, пропуски и скачки метрик

Коротко

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

• Проверь размер таблицы и период загрузки.
• Найди NULL в ключевых полях и неожиданные пустые значения.
• Проверь дубли на уровне бизнес-события.
• Найди события без пользователя и платежи без связанной сущности.
• Сравни дневной объём с предыдущими днями и ожидаемым диапазоном.

Сначала зафиксируй контракт данных

SQL-проверка имеет смысл только относительно ожидаемого правила. Для `users` одна строка — один пользователь, `user_id` уникален и заполнен. Для `events` одна строка — одно событие, user_id может быть анонимным только по согласованному правилу. Для payments сумма не должна быть отрицательной без отдельного типа возврата.

Проверка NULL и обязательных полей

Начни с полей, без которых метрика меняет смысл: user_id, event_date, event_name, amount. Не каждый NULL является ошибкой, но каждый должен иметь объяснение. Если user_id может быть анонимным, это правило нужно отразить в расчёте DAU, а не скрывать фильтром.

select\n  count(*) as all_events,\n  count(*) filter (where user_id is null) as missing_user_id,\n  count(*) filter (where event_date is null) as missing_event_date,\n  count(*) filter (where event_name is null) as missing_event_name\nfrom events;

Дубли: одна строка или повтор события

Дубликат нужно определять по бизнес-ключу, а не только по полному совпадению строки. Для события это может быть event_id, либо комбинация user_id, event_date, event_name и session_id. Для payments лучше иметь отдельный payment_id. Если ключа нет, сначала договорись, что именно считается повтором.

select\n  user_id,\n  event_date,\n  event_name,\n  count(*) as rows_count\nfrom events\ngroup by user_id, event_date, event_name\nhaving count(*) > 1\norder by rows_count desc;

Orphan rows: события без пользователя

Событие с user_id, которого нет в users, может быть нормальным для ещё не загруженного справочника, а может означать сломанную связь или неверный идентификатор. LEFT JOIN помогает найти такие строки, не теряя события из исходной таблицы.

select\n  e.user_id,\n  count(*) as events_count\nfrom events as e\nleft join users as u using (user_id)\nwhere u.user_id is null\ngroup by e.user_id\norder by events_count desc;

• Проверь, не различаются ли типы user_id: integer и text.
• Сверь задержку загрузки users и events.
• Отдельно обработай anonymous_id, если он есть в продукте.
• Не удаляй orphan rows до понимания причины.

Скачки дневного объёма

Аномальный объём событий не всегда означает рост активности. Причиной может быть дубль загрузки, новый SDK, изменение названия события или задержка нескольких дней, которая пришла одной пачкой. Сначала агрегируй объём по дню, затем сравни с предыдущим днём через LAG.

with daily as (\n  select\n    event_date,\n    count(*) as events_count\n  from events\n  group by event_date\n), daily_with_previous as (\n  select\n    event_date,\n    events_count,\n    lag(events_count) over (order by event_date) as previous_count\n  from daily\n)\nselect\n  event_date,\n  events_count,\n  previous_count,\n  events_count - previous_count as change\nfrom daily_with_previous\norder by event_date;

Сверка метрики с независимым расчётом

Если дашборд показывает DAU, полезно иметь простой контрольный запрос с тем же определением active action. Сверяй не только итоговое число, но и период, таймзону, фильтры тестовых аккаунтов и количество уникальных пользователей.

select\n  event_date,\n  count(distinct user_id) as dau\nfrom events\nwhere event_name = 'core_action'\n  and user_id is not null\n  and event_date >= date '2026-06-01'\n  and event_date < date '2026-07-01'\ngroup by event_date\norder by event_date;

Чеклист перед публикацией отчёта

Проверка качества не должна превращаться в ритуал из десятков непонятных запросов. Начни с пяти вопросов, сохрани результат и добавь ссылку на него к дашборду или задаче аналитика.

• Размер таблицы и свежесть последней даты ожидаемые?
• Ключи заполнены и не дублируются?
• Связи между таблицами не дают неожиданное число orphan rows?
• Дневной объём и доля событий по типам не скачут без объяснения?
• Контрольный расчёт метрики совпадает с дашбордом по определению?

Мини-практика и следующий шаг

Собери мини-аудит таблицы events: пропуски, дубли, orphan user_id и дневной объём. Затем сравни контрольный DAU с результатом из отчёта. В конце запиши, какие проверки можно запускать автоматически перед обновлением дашборда.