Тема «контроль качества продуктовых данных» поддерживает конкретное продуктовое решение. Единица «качество данных» — пригодность события и набора данных для конкретного решения. Вопрос «качество данных»: как обнаруживать пропуски, дубли, изменение схемы и смысловые противоречия до того, как они попадут в продуктовый отчёт. Методика «качество данных» согласует определения, данные и действия. Владелец «качество данных» отвечает за итоговую формулу.
Контекст и цель
Контур «качество данных» начинается с будущего решения. Для «качество данных» назовите субъект и период. Реакция на изменение «качество данных» задаётся заранее. Единица «пригодность события и набора данных для конкретного решения» отделяет результат от активности команды. Такой порядок защищает «качество данных» от декоративной отчётности.
Основание «качество данных»: W3C связывает качество данных с пригодностью использования. основание
Основание «качество данных»: JSON Schema описывает структуру и — в разборе «Контроль качества продуктовых данных» — условия JSON. основание
Основание «качество данных»: Snowplow применяет схемы для проверки событий. основание
Основание «качество данных»: DebugView показывает поступающие события в реальном времени. основание
Источники поддерживают принципы «качество данных». Локальные фильтры выбирает команда «качество данных». Полнота событий проверяется для «качество данных» отдельно. Стоимость ошибки также входит в решение «качество данных».
Рабочая модель
Формула «качество данных»: контроль сочетает полноту, валидность, уникальность, своевременность, согласованность и семантическую корректность. Модель «качество данных» содержит шесть самостоятельных частей. Каждая часть «качество данных» имеет владельца и пример.
-
Контракт схемы. В «качество данных» элемент «контракт схемы» задаёт границу. Пара «контракт схемы — обязательные поля» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
-
Обязательные поля. В «качество данных» элемент «обязательные поля» задаёт границу. Пара «обязательные поля — уникальность события» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
-
Уникальность события. В «качество данных» элемент «уникальность события» задаёт границу. Пара «уникальность события — временная последовательность» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
-
Временная последовательность. В «качество данных» элемент «временная последовательность» задаёт границу. Пара «временная последовательность — сверка с источником истины» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
-
Сверка с источником истины. В «качество данных» элемент «сверка с источником истины» задаёт границу. Пара «сверка с источником истины — мониторинг объёма и распределений» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
-
Мониторинг объёма и распределений. В «качество данных» элемент «мониторинг объёма и распределений» задаёт границу. Пара «мониторинг объёма и распределений — контракт схемы» проверяется на эпизоде. Исключения «качество данных» записываются до расчёта.
Конфликт вокруг «контракт схемы» блокирует модель «качество данных». Определение «качество данных» исправляется до публикации. Усреднение «качество данных» не решает смысловой конфликт.
Данные и расчёт
Паспорт «качество данных» фиксирует числитель и знаменатель. Субъект «качество данных» указывается отдельно. Для «пригодность события и набора данных для конкретного решения» задаётся источник времени. Часовая зона «качество данных» входит в контракт. Дедупликация «качество данных» описывает повторные события.
Ручная сверка «качество данных» использует реальные истории. Агрегат «качество данных» сравнивается с транзакционным источником. Компоненты «обязательные поля», «уникальность события» и «временная последовательность» сохраняются отдельно. Разложение «качество данных» показывает продуктовый сдвиг или дефект сбора.
Период «качество данных» следует естественному циклу. Календарная неделя подходит не всегда. Причина периода «качество данных» документируется. Дата пересмотра «качество данных» также фиксируется.
Интерпретация и решения
Правила чтения «качество данных» записываются заранее. После результата правила «качество данных» не переписываются.
-
Валидный json может быть семантически неверным. В «качество данных» правило связано с «контракт схемы». Владелец «качество данных» указывает действие и срок реакции.
-
Нулевое значение и отсутствие поля различаются. В «качество данных» правило связано с «обязательные поля». Владелец «качество данных» указывает действие и срок реакции.
-
Рост объёма после релиза требует проверки дублей. В «качество данных» правило связано с «уникальность события». Владелец «качество данных» указывает действие и срок реакции.
-
Запаздывающие события помечаются отдельно. В «качество данных» правило связано с «временная последовательность». Владелец «качество данных» указывает действие и срок реакции.
-
Отчёт не обновляется молча при нарушенном контракте. В «качество данных» правило связано с «сверка с источником истины». Владелец «качество данных» указывает действие и срок реакции.
Изменение «качество данных» сначала проходит техническую проверку. Релиз «качество данных» исключается первым. Затем «качество данных» сверяется с трафиком и задержкой. Гипотезы «качество данных» формулируются после проверки.
Практический пример
После обновления мобильного приложения событие purchase_completed выросло вдвое. Проверка уникального transaction_id показывает повторную отправку при восстановлении соединения. Дашборд временно использует дедупликацию, а команда исправляет клиент и пересчитывает затронутый период.
В примере «качество данных» восстанавливаются реальные истории. Поток «качество данных» проверяется по «контракт схемы». Затем изучаются «уникальность события» и «сверка с источником истины». Агрегат «качество данных» сверяется с операционной системой.
Итог примера — правило решения «качество данных». Правило «качество данных» различает эксперимент и исправление данных. Дополнительное исследование назначается отдельно. Дашборд «качество данных» остаётся каналом доставки сигнала.
Порядок внедрения
Внедрение «качество данных» делится на короткие шаги. Каждый шаг «качество данных» оставляет контрольный результат.
-
Назначить критические наборы данных. Шаг «назначить критические наборы данных» уточняет «контракт схемы». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
-
Задать схему и допустимые значения. Шаг «задать схему и допустимые значения» уточняет «обязательные поля». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
-
Ввести проверки на входе. Шаг «ввести проверки на входе» уточняет «уникальность события». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
-
Сверять агрегаты с транзакционными системами. Шаг «сверять агрегаты с транзакционными системами» уточняет «временная последовательность». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
-
Отслеживать резкие изменения. Шаг «отслеживать резкие изменения» уточняет «сверка с источником истины». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
-
Блокировать публикацию при критических дефектах. Шаг «блокировать публикацию при критических дефектах» уточняет «мониторинг объёма и распределений». В модели «качество данных» результат проверяют три роли. Переход «качество данных» сохраняется в журнале.
Первый расчёт «качество данных» повторяется независимым запросом. Расхождение «качество данных» разбирается по фильтрам. Время «качество данных» и идентификаторы сверяются далее. Версии «качество данных» проверяются отдельно.
Критерии качества
Определение «качество данных» готово при следующих условиях:
-
Критические поля валидируются автоматически. Критерий «критические поля валидируются автоматически» проверяет «контракт схемы». Подтверждение «качество данных» хранится запросом или событием.
-
Есть источник истины для сверки. Критерий «есть источник истины для сверки» проверяет «обязательные поля». Подтверждение «качество данных» хранится запросом или событием.
-
Дубли имеют устойчивый ключ. Критерий «дубли имеют устойчивый ключ» проверяет «уникальность события». Подтверждение «качество данных» хранится запросом или событием.
-
Мониторятся объём и распределения. Критерий «мониторятся объём и распределения» проверяет «временная последовательность». Подтверждение «качество данных» хранится запросом или событием.
-
Ошибки видимы владельцам. Критерий «ошибки видимы владельцам» проверяет «сверка с источником истины». Подтверждение «качество данных» хранится запросом или событием.
-
Известен процесс исправления исторических данных. Критерий «известен процесс исправления исторических данных» проверяет «мониторинг объёма и распределений». Подтверждение «качество данных» хранится запросом или событием.
Критерии «качество данных» оцениваются совместно. Формула «качество данных» не исправляет плохие данные. Точный поток «качество данных» бесполезен без решения.
Ограничения применимости
Перед публикацией «качество данных» укажите ограничения:
-
Схема не проверяет бизнес-смысл полностью. Ограничение «схема не проверяет бизнес-смысл полностью» меняет вывод «качество данных». В ответ добавляется «обязательные поля» или качественное исследование.
-
Редкие события дают шумные алерты. Ограничение «редкие события дают шумные алерты» меняет вывод «качество данных». В ответ добавляется «уникальность события» или качественное исследование.
-
Сверка может иметь временной лаг. Ограничение «сверка может иметь временной лаг» меняет вывод «качество данных». В ответ добавляется «временная последовательность» или качественное исследование.
-
Часть внешних данных недоступна для контроля. Ограничение «часть внешних данных недоступна для контроля» меняет вывод «качество данных». В ответ добавляется «сверка с источником истины» или качественное исследование.
-
Исправление истории требует версионирования отчётов. Ограничение «исправление истории требует версионирования отчётов» меняет вывод «качество данных». В ответ добавляется «мониторинг объёма и распределений» или качественное исследование.
Крупное ограничение отменяет общий итог «качество данных». Несколько представлений «качество данных» честнее одного числа. Ложная определённость «качество данных» опаснее сложности.
Вывод
Практика «качество данных» начинается с единицы «пригодность события и набора данных для конкретного решения». Затем «качество данных» связывает формулу, события и проверки. Реакция «качество данных» назначается владельцу. Ручная сверка предшествует автоматизации.
Минимум «качество данных»: ответить на вопрос «как обнаруживать пропуски, дубли, изменение схемы и смысловые противоречия до того, как они попадут в продуктовый отчёт». Далее проверяется формула «контроль сочетает полноту, валидность, уникальность, своевременность, согласованность и семантическую корректность». Ограничения «качество данных» записываются до регулярного review.
