КабинетПоиск
Инженерия данных

Data Quality

Качество данных

актуальноТекущий рабочий стандарт

Направления: Инженерия ИИ · Инженерия данных

Автоматические проверки, которые ловят поломку источника раньше, чем она попадёт в модель.

Ключевые тезисы

  • Проверяйте объём, свежесть, долю пропусков, уникальность ключей и распределения.
  • Great Expectations, Soda, dbt tests — готовые инструменты для описания проверок.
  • Правило: должен падать при нарушении контракта, а не тихо писать мусор.

Какую задачу решает

Модель не отличает испорченные данные от настоящих: она просто учится на том, что пришло. Сломанный источник, изменившийся формат, сдвинутый часовой пояс, задвоенные строки — всё это не вызывает ошибок, а тихо портит и обучение, и предсказания.

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

Пять проверок, которые ловят большинство проблем

1) Число строк за период отличается от медианы за две недели не более чем в полтора раза. 2) Все ожидаемые колонки на месте и нужных типов. 3) Доля пропусков в каждом ключевом признаке не выросла более чем вдвое. 4) Числовые в допустимом диапазоне (возраст 0–120, сумма не отрицательна). 5) Доля новых, ранее не встречавшихся значений категориального признака ниже порога. Эти пять проверок пишутся за час и ловят подавляющее большинство реальных инцидентов с данными.

Подробный разбор

2 подтемы — объяснения, формулы, примеры и интерактивные графики.

ПроверкаПример правила
Свежестьмаксимальная дата не старше 26 часов
Объёмчисло строк в пределах ±30% от медианы за 7 дней
Уникальностьнет дублей по первичному ключу
доля NULL в ключевых полях ниже порога
Диапазонысумма ≥ 0, вероятность в [0,1]
Ссылочная целостностьвсе user_id есть в таблице пользователей

Если источник отдал половину данных, а молча их записал, модель обучится на искажённой выборке и будет портить решения неделями. Упавший джоб чинят за час; тихий сдвиг находят через квартал по жалобам бизнеса.

На практике

Разделяйте критичные проверки (останавливают ) и предупреждающие (пишут алерт, но пропускают данные). Всё подряд делать блокирующим — верный способ научить команду игнорировать алерты.

Где применяется

  • Приём внешних данныхПоставщик меняет формат без предупреждения — проверка ловит это в первый же день.
  • Перед обучениемГарантия, что соответствует ожиданиям.
  • Перед Отказ обслуживать запрос на явно испорченных данных лучше, чем случайное предсказание.
  • Регрессия Изменение в коде обработки не должно менять статистики выхода.

Плюсы, минусы и альтернативы

Плюсы

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

Минусы

  • Слишком строгие проверки вызывают ложные срабатывания и падения на законных изменениях.
  • Требуют сопровождения: данные эволюционируют, ожидания надо обновлять.
  • Не ловят содержательно неверные, но формально корректные данные.

Брать, если

  • Данные поступают из внешних или неподконтрольных источников.
  • работает автоматически, без человека в цикле.

Не брать, если

  • Разовый анализ, где данные просматриваются глазами.

Чем заменяют

Data ContractsновинкаКонтракты данных · Инженерия данныхНужно зафиксировать ожидания как договор с поставщиком данных.MonitoringактуальноМониторинг · MLOpsРечь о наблюдении за данными в проде, а не о проверках в пайплайне.Data preprocessingактуальноПредобработка данных · ДанныеДанные проверены — дальше их подготовка к обучению.
Тема также относится к главам:ДанныеОчисткаMLOpsЭксплуатация

Видеолекции

Тайм-кода именно на эту тему в записях нет. Но глава «Инженерия данных» разобрана в курсе целиком — с той оговоркой, что место в записи придётся искать самому.

Курс: Большие данные29 записей

Связанные темы

Надёжность данных

Data Contracts85%

Контракты данных · Инженерия данных

Явная договорённость между источником и потребителем: какие поля, каких типов и с какими гарантиями.

Idempotency & Exactly-once85%

Идемпотентность и гарантии доставки · Инженерия данных

Что происходит при повторной обработке события и как не задвоить данные.

Change Data Capture85%

Захват изменений (CDC) · Инженерия данных

Чтение журнала изменений базы вместо периодических полных выгрузок.

Feature Stores85%

Хранилища признаков · MLOps

Централизованное хранилище признаков, единое для обучения и онлайн-инференса.

Data leakage85%

Утечка данных · Данные

Ситуация, когда в обучении присутствует информация, недоступная в момент реального предсказания. Главная причина «слишком хороших» метрик.

Data leakage85%

Утечка данных · Практика ML

Самая дорогая ошибка в ML: модель отлично работает офлайн и разваливается в проде.

Data preprocessing85%

Предобработка данных · Данные

Приведение сырых данных к виду, пригодному для обучения: типы, форматы, дубликаты, согласованность единиц измерения.

Кому эта тема нужна

Профильная компетенция для роли: Data Engineer.

Усиливает профиль: Аналитик данных, MLOps-инженер.

Спрашивают на собеседовании: Сбер — Промышленный ML и MLOps, ВТБ — Данные и витрины, билайн — Продукты на данных, BI.ZONE — Данные и аналитика угроз, Arenadata — ML на платформе данных.

Добавить в учебную программу
Проверить себя

Тема встречается в тесте по направлениям — ошибки приведут обратно на эту страницу.

Тест: SQL и инженерия данных24
Тема в работе целиком

Разбор архитектуры, где эта тема — один из кирпичей: требования, развилки, цифры и режимы отказа.

Кейс: Телеметрия с битыми датчиками
Следующий шагПроверить себя: SQL и инженерия данныхТема встречается в этом тесте 1 раз. Ошибка приведёт обратно на эту страницу — с объяснением, что именно не сошлось.Перейти →
← OrchestrationData Contracts →

Глава «Инженерия данных» последний раз правилась . Нашли ошибку — напишите.