analyze-data-quality

analyze-data-quality — это навык для проверки того, достаточно ли надёжны структурированные данные, результаты запросов, дашборды и аналитические свидетельства для дальнейшего использования. Его применяют, когда нужно оценить качество таблицы, согласовать конфликтующие определения метрик или понять, безопасно ли ссылаться на конкретное доказательство. Работа начинается не с механического подсчёта пропусков, а с контекста: нужно зафиксировать назначение набора данных, единицу наблюдения, фактический grain, downstream-сценарий, интересующий слой — сырые данные или преобразованную модель — и сопоставительный baseline. Важны предполагаемые ключи, даты и часовой пояс, допустимые значения, бизнес-правила и пороги. Если контекста не хватает, навык допускает осторожное предположение, но требует пометить его как допущение. Для воспроизводимости предлагается выбирать проверяемый путь анализа: при использовании SQL или Python предпочтителен companion notebook, чтобы пользователь видел точный код и мог повторить проверку; при необходимости отдельного notebook-workflow можно подключить jupyter-notebooks. Для таблиц, к которым есть запросный доступ, сначала подтверждаются схема, grain и примеры строк через structured_data, а для проверки свежести и lineage применяются operations_logs, когда эти факторы действительно важны. После этого строится компактный профиль: число строк и столбцов, имена и типы, возможные ключи, доля дубликатов, минимальные и максимальные даты, null-rate, число уникальных значений и базовые числовые сводки. Основной набор проверок подбирается под форму данных и включает completeness, uniqueness, validity, consistency, integrity, timeliness, volume и shape. Важны не только абсолютные количества, но и доли; полезно разбивать результат по времени, источнику, стране, платформе, версии модели или другому измерению, если это помогает отличить дефект от нормального сегментного различия. Для событий проверяются повторные event ID, будущие временные метки, покрытие пользователей или сессий и резкая смена состава событий. Для dimension-таблиц — неуникальные бизнес-ключи, orphan-ссылки и несогласованность статусов с датами. Для fact-таблиц — смешанный grain, неожиданный рост после join, невозможные меры, поздние партиции и неполные backfill. Для ML-таблиц дополнительно ищутся leakage, скачки разреженности, drift диапазонов и сдвиги классов, а для экспериментов — повторные назначения, дисбаланс вариантов, exposure без assignment и события до момента назначения. При наличии истории приоритет получают first-seen и last-seen даты, тренды пропусков и дублей, динамика строк, доли категорий, distribution drift и точки изменений вокруг релизов, миграций, инцидентов, смены модели или backfill. Каждый результат связывается с аналитическим риском: сломанный join, смещённое решение, устаревший дашборд, неверный эксперимент, leakage или недостоверный сегмент. Для дубликатов и ключей учитываются также near-duplicates из-за пробелов, регистра, форматирования и поздних обновлений; для missingness отделяется допустимая разреженность от поломки обязательного поля; для domain validity проверяются форматы, диапазоны, enum и противоречия между полями. Для выбросов рекомендуются quantile, MAD или IQR, а не автоматический z-score. Итог должен объяснять набор данных и grain, выполненные проверки, находки, временные аномалии, причины, затронутые сценарии, минимальные исправления или устойчивые автотесты, а также допущения. Для каждой находки нужны evidence с counts, rates, сегментами и датами, значимость, severity, confidence, вероятная причина и следующий шаг. Автоматизировать стоит стабильные правила — not-null, уникальность ключа, accepted values, referential integrity, freshness и сезонно устойчивый объём; жёсткие пороги распределений для волатильных метрик и строгую уникальность грязных entity-данных нужно вводить осторожно. Навык не заменяет интерпретацию сырым profiling dump: он требует компактных проверяемых доказательств, нормализации строк перед сравнением и сохранения query, notebook, source path и расчётов.