9.3.1 · блок 9
Data quality
Data quality
Зачем это нужно
Даже корректный pipeline выдаёт плохую модель, если выгрузка стала пустой, колонка поменяла тип или label появился с задержкой. Проверки качества превращают такие сюрпризы в ранний и понятный сбой CI или data pipeline.
Основные идеи
Data quality contract описывает ожидаемые схему, диапазоны, заполненность, уникальность, свежесть и распределения. Порог — продуктовая договорённость, а не магическое число библиотеки.
Great Expectations описывает expectations и формирует отчёты; Pandera задаёт schema и проверки для DataFrame в Python. Инструменты разные, принцип один: данные проверяются автоматически и воспроизводимо.
Schema checks в CI полезны для маленьких sample и преобразований кода. Полная проверка production snapshot обычно запускается рядом с данными как отдельный pipeline step.
Fail fast. Если входной dataset не проходит критический контракт, train или publish не должны продолжаться. Некритичные предупреждения фиксируются как telemetry и получают владельца.
Как это выглядит на практике
Перед обучением churn-модели выполняются проверки:
age: integer, 18..120, null_rate < 1%
user_id: unique
event_ts: свежесть < 24 ч
churn: доля положительного класса 3..40%
Смена age с integer на строку останавливает job и сообщает владельцу источника. Это лучше, чем неявно преобразовать «unknown» в 0 и обнаружить проблему после релиза.
Что сделать после занятия
- [ ] Сформулируйте schema contract для трёх колонок.
- [ ] Отметьте одну проверку как blocking и одну как warning.
- [ ] Добавьте schema-check на тестовом DataFrame в CI.