7.8 Качество данных и наблюдаемость

Обзор и мотивация

Качество данных это пригодность к использованию: степень, в которой данные служат решениям, продуктам и отчётам, зависящим от них. Набор данных не хорош и не плох в абстракции. Он достаточно хорош для цели или нет. Адрес клиента, годный для маркетингового подсчёта, может быть непригоден для юридического уведомления. Эта рамка важна, потому что она переводит разговор от «идеальны ли наши данные» (никогда) к «пригодны ли наши данные для того, что мы собираемся с ними делать» (на что можно ответить и что можно проверить). Классические измерения: точность, полнота, согласованность, своевременность, валидность и уникальность, и большинство реальных проблем сводится к одному из них.

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

Наблюдаемость данных это дисциплина, ловящая это раньше ваших потребителей. Это прямая параллель наблюдаемости и телеметрии программного обеспечения (глава 9.2): тот же инстинкт, что велит мониторить задержку запросов и долю ошибок, велит мониторить свежесть, объём, схему и распределение данных. Эта глава опирается на стратегию данных и управление данными (глава 7.1) и инженерию данных (глава 7.2) и питает моделирование данных и семантический слой (глава 7.7) и ответственный и надёжный ИИ (глава 6.5). Для корпораций, сверяющих многие системы-источники, и государств, публикующих законодательную статистику, воспринимание надёжности данных как инженерной проблемы с владельцами и уровнями обслуживания это разница между доверием и очень публичным исправлением.

Ключевые принципы

Качество данных это пригодность к использованию, а не совершенство; определяйте его относительно цели.
Плохие данные хуже отсутствия данных, потому что молча портят решения.
Тестируйте данные, как код: утверждения, ожидания и проверки схемы в конвейере.
Контракты между производителями и потребителями делают ожидания явными и принуждаемыми.
Наблюдайте свежесть, объём, схему и распределение так же, как наблюдаете сервисы.
Происхождение превращает «что-то не так» в «вот что сломалось и что это затрагивает».
Воспринимайте инциденты с данными как производственные инциденты, с владением, серьёзностью и уровнями обслуживания.
Обнаруживайте проблемы там, где они входят, а не тремя слоями ниже в панели.

Рекомендации

Определяйте качество по измерениям и измеряйте его

Расплывчатые цели качества дают расплывчатые результаты. Разбейте качество на измеримые измерения и привяжите конкретные проверки к каждому. Точность спрашивает, отражают ли значения реальность (совпадает ли записанная выручка с исходной книгой). Полнота спрашивает, присутствуют ли ожидаемые записи и поля (не пропущены ли дни, не пусты ли обязательные столбцы). Согласованность спрашивает, согласуется ли один факт между системами (совпадает ли число клиентов в финансах с числом в хранилище). Своевременность спрашивает, приходят ли данные вовремя, чтобы быть полезными (готовы ли вчерашние данные до утреннего отчёта). Валидность спрашивает, соответствуют ли значения правилам и форматам (все ли коды валют настоящие, в диапазоне ли даты). Уникальность спрашивает, появляются ли сущности один раз (нет ли дублирующихся заказов, раздувающих итог). Выберите измерения, важные для каждого набора данных, задайте пороги и отслеживайте их во времени. Качество, которое вы не измеряете, качество, о котором вы гадаете.

Тестируйте конвейеры утверждениями и ожиданиями

Данные заслуживают той же строгости тестирования, что и код приложения. Используйте проверку данных на каждой стадии: тесты на основе утверждений, проваливающие конвейер при нарушении инварианта, и тесты на основе ожиданий, объявляющие, как выглядит «норма» для таблицы, и помечающие отклонения. Утверждайте, что первичные ключи уникальны и непусты, что внешние ключи разрешаются, что категориальные столбцы содержат только принятые значения, что числовые столбцы лежат в правдоподобных диапазонах и что число строк попадает в ожидаемую полосу. Добавьте проверки схемы, громко отказывающие, когда вышестоящий добавил, удалил, переименовал или сменил тип столбца. Запускайте эти проверки в непрерывной интеграции, чтобы плохое преобразование ловилось до слияния, и снова в производстве на живых данных, чтобы плохой источник ловился до потребителей. Цель отказывать рано и громко, потому что сломанный конвейер безопаснее молча неверного.

Устанавливайте контракты данных между производителями и потребителями

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

Мониторьте четыре сигнала наблюдаемости данных

Наблюдаемость данных следит за четырьмя сигналами, в прямой параллели с тем, как вы следите за работающим сервисом (глава 9.2). Свежесть: так ли недавни данные, как должны, или конвейер остановился. Объём: в ожидаемом ли диапазоне число строк или таблица пришла наполовину пустой или загруженной дважды. Схема: не изменилась ли структура неожиданно. Распределение: не дрейфовали ли сами значения, так что столбец, где было 2 процента пустых, внезапно имеет 40 процентов, или среднее сдвинулось так, что сигнализирует об ошибке выше по течению. Инструментируйте эти сигналы на своих важных таблицах, изучите их нормальные шаблоны и оповещайте о нарушениях. Так вы заменяете «руководитель заметил, что панель выглядит неправильно» на «владеющую команду вызвали в точке отказа». Худший из возможных детекторов проблемы с данными нижестоящий человек, доверяющий числу.

Добавьте обнаружение аномалий, но настройте его против усталости от оповещений

Статические пороги ловят очевидные отказы. Для более тонкого дрейфа добавьте обнаружение аномалий, изучающее нормальный сезонный шаблон каждой метрики и помечающее статистически необычные отклонения, так что вы ловите медленную утечку до того, как она станет потоком. Будьте дисциплинированы в этом. Шумные оповещения об аномалиях приучают людей игнорировать оповещения, что хуже отсутствия оповещений. Начинайте с таблиц наивысшей ценности, оповещайте только о том, на что человек должен отреагировать, направляйте каждое оповещение названному владельцу и настраивайте безжалостно. Оповещение, на которое никто не реагирует, ошибка вашего мониторинга, а не функция.

Отслеживайте происхождение для анализа влияния и первопричины

Когда что-то ломается, сразу важны два вопроса: что вызвало и что это затрагивает. Происхождение данных отвечает на оба, отображая, как данные текут от источника через каждое преобразование к каждой нижестоящей таблице, панели и модели. Для первопричины вы прослеживаете неверную цифру вверх по течению до преобразования или источника, внёсшего её. Для анализа влияния вы прослеживаете вперёд, чтобы увидеть каждого потребителя, затронутого плохой загрузкой, и уведомить их и поместить ущерб в карантин, пока он не распространился. Захватывайте происхождение автоматически из ваших инструментов преобразования и оркестрации, а не сопровождайте диаграмму вручную, потому что нарисованная вручную диаграмма неверна на следующий день после рисования. В корпорациях с многими источниками публикуйте происхождение в каталог данных, чтобы любой потребитель видел, откуда взялось поле, и доверял ему соответственно.

Воспринимайте инциденты с данными как производственные инциденты

Практики, делающие сервисы надёжными, применимы к данным напрямую. Дайте каждому важному набору данных владельца. Определите уровни серьёзности для «простоя данных», периодов, когда данные отсутствуют, неверны или запоздали. Задайте уровни обслуживания: цели свежести, приемлемый бюджет ошибок и целевое время обнаружения и решения. Поставьте дежурства по данным за самыми критичными конвейерами, пишите ранбуки и проводите разборы без обвинений после инцидентов, чтобы тот же отказ не повторился. Когда платёжная таблица запоздала или публичная метрика неверна, это инцидент, и он заслуживает той же серьёзности, что и сбой. Это культурный сдвиг, окупающий все инструменты.

Профилируйте и сверяйте непрерывно

Профилирование означает регулярное исследование формы ваших данных: распределений значений, долей пустых, кардинальности, минимума и максимума и шаблонов формата. Оно выявляет проблемы, которые вы не подумали утверждать, и говорит, как выглядит «норма», чтобы вы могли задать хорошие ожидания. Сверка означает проверку того, что независимые источники согласуются: совпадает ли итог хранилища с системой-источником записи, равна ли сумма частей целому. Автоматизируйте сверку между критичными системами и оповещайте о расхождении, потому что разрыв сверки нередко самый ранний и ясный сигнал, что что-то выше по течению пошло не так.

Компромиссы: плюсы и минусы

Подход	Плюсы	Минусы	Лучше всего подходит
Тесты-утверждения (жёсткий отказ)	Останавливает плохие данные наглухо, ясные инварианты	Может блокировать конвейеры из-за мелочей	Критичные ключи, ссылочная целостность
Тесты-ожидания (мягкая пометка)	Ловит дрейф, менее хрупко	Требует настройки, можно проигнорировать	Распределения, полосы объёма
Контракты данных	Предотвращают сюрпризы выше по течению, ясное владение	Накладные расходы координации и управления	Межкомандные границы производителя и потребителя
Обнаружение аномалий	Ловит тонкий непредвиденный дрейф	Усталость от оповещений, ложные срабатывания	Таблицы высокой ценности, сезонные метрики
Ручные выборочные проверки	Дёшево начать, не нужны инструменты	Не масштабируется, пропускает молчаливые ошибки	Только самая ранняя стадия
Полная платформа наблюдаемости	Широкое покрытие, происхождение, оповещения	Цена, настройка, ещё одна система для эксплуатации	Многие источники, регулируемая отчётность

Центральное напряжение между покрытием и шумом. Не инструментируйте ничего, и проблемы дойдут до потребителей первыми, что разрушает доверие. Инструментируйте всё с оповещениями на волоске, и вы утопите команду в ложных срабатываниях, пока она не отключит канал, что тоже позволяет проблемам дойти до потребителей. Разрешайте это, ранжируя данные по радиусу поражения. Таблицы, питающие метрики совета директоров, продукты для клиентов, регуляторные отчёты и модели машинного обучения, получают полное лечение: контракты, жёсткие утверждения, наблюдаемость и дежурное владение. Длинный хвост исследовательских таблиц получает лёгкое профилирование. Тратьте бюджет надёжности там, где неверные данные ударили бы сильнее всего, и будьте намеренно скупы везде остальное.

Вопросы для обсуждения с командой

Когда плохие данные достигают производства, кто узнаёт первым и как? Это самый показательный вопрос о надёжности ваших данных, потому что честный ответ обычно «потребитель, случайно». Если аналитик, руководитель или клиент ваша система обнаружения, ваше среднее время обнаружения измеряется днями, а ваша репутация получает удар каждый раз. Альтернатива инструментирование, вызывающее владеющую команду в точке отказа, до того как плохое число распространится. Принесите реальные числа: сколько из ваших последних десяти инцидентов с данными поймал мониторинг против сообщённых нижестоящим человеком и как долго каждый сидел необнаруженным. Ответ говорит, есть ли у вас наблюдаемость или только надежда, и он должен прямо направить, куда вкладываться в проверки свежести, объёма, схемы и распределения в первую очередь.
У каких наборов данных есть владелец, контракт и уровень обслуживания, а какие сироты? В масштабе большинство сбоев качества данных восходит к бесхозному интерфейсу: производящая команда что-то изменила, не зная, кто от этого зависит, потому что ни один контракт этого не говорил. Владение это основа, делающая возможными контракты, маршруты оповещений и реагирование на инциденты, а сиротские наборы данных то место, где живёт молчаливая порча. Пройдите по вашим важнейшим таблицам и спросите для каждой, кто подотчётен, что обязался производитель и какие свежесть и точность обещаны потребителям. Принесите ваше происхождение: таблицы с наибольшим нижестоящим радиусом поражения те, которым это нужнее всего, и нередко те, у которых этого нет. Разрыв между «важным» и «имеющим владельца» ваш список приоритетов на следующий квартал.
Какова реальная цена инцидента с качеством данных для нас и обращаемся ли мы с ним соответственно? Команды недоинвестируют в качество данных, потому что цена плохих данных рассеяна и отложена, так что никогда не появляется строкой в статьях расходов, тогда как цена построения инструментов качества конкретна и немедленна. Переформулируйте, оценив настоящий инцидент от начала до конца: неверное решение, переделку, часы инженеров, потраченные на поиск первопричины без происхождения, подорванное доверие, заставляющее людей тихо перестраивать собственные теневые наборы данных, и, в регулируемых или публичных условиях, уведомление об исправлении и его репутационный ущерб. Принесите конкретный пример прошлого года и честно подсчитайте итог. Если один молчаливый отказ в платёжном конвейере или конвейере публичной статистики мог бы стоить больше года инструментов наблюдаемости, бизнес-обоснование складывается само, и разговор смещается от того, вкладываться ли, к тому, куда.
Ранжировали ли мы наши наборы данных по радиусу поражения и следуют ли вложения в мониторинг этому ранжированию? Центральный режим отказа в масштабе это равномерная трата усилий на надёжность, так что исследовательская таблица, которой никто не доверяет, получает то же внимание, что питающая метрики совета директоров, а оповещение на волоске по малоценной таблице приучает людей отключать канал, несущий и критический вызов. Нельзя инструментировать всё, не утонув в шуме, и нельзя инструментировать ничего, не дав проблемам дойти до потребителей первыми, поэтому настоящее решение в том, куда идёт полное лечение (контракты, жёсткие утверждения, наблюдаемость и дежурное владение), а где хватает лёгкого профилирования. Принесите опись ваших таблиц, помеченных тем, что от них зависит: метрики совета директоров, продукты для клиентов, регуляторные отчёты и модели машинного обучения, затем сравните это ранжирование с тем, где ваши проверки и оповещения на самом деле стоят сегодня. Для корпорации, сверяющей многие источники, или государства, публикующего законодательные цифры, таблицы с юридической или публичной экспозицией принадлежат верху списка, а любой разрыв между «навредило бы сильнее всего, будь оно неверно» и «мониторится больше всего» ошибка приоритизации, которую нужно исправить сейчас.
Какие модели машинного обучения и аналитика принимают решения по данным, которые мы никогда не проверяем, и какие ошибки они могут молча кодировать? Панель показывает неверное число одному человеку, который может усомниться, а модель обучается на неверных признаках и кодирует эти ошибки в каждое предсказание, в масштабе и непрозрачности, делающих ущерб гораздо труднее заметить или отменить. Конкурирующее давление скорость: команды науки о данных хотят двигаться быстро на новых признаках, а добавление проверки, контрактов и гарантий свежести к каждой подаче кажется трением, пока модель тихо не деградирует, потому что столбец выше по течению дрейфовал. Принесите опись ваших производственных моделей и аналитики, наборов данных, потребляемых каждой, и честную отметку того, у каких из этих подач есть тесты, контракты и наблюдаемость, а какие без защиты. В корпоративной или государственной среде, где модель влияет на кредитные, пенсионные или правоприменительные решения, непроверенные обучающие данные становятся обязательством аудита и справедливости сверх риска качества, поэтому вопрос о том, какие подачи ограничивают выпуск модели, должен иметь владельца и документированный ответ (глава 6.5).
Когда ошибка качества всплывает через недели, можем ли мы на самом деле переобработать и сверить или мы уже выбросили то, что нам понадобилось бы? Многие сбои качества невидимы во время загрузки и становятся ясны позже, когда разрыв сверки или подозрительный тренд заставляет кого-то посмотреть, и к тому времени возможность исправить чисто зависит от выборов, сделанных гораздо раньше: хранили ли вы неизменяемые сырые записи, можно ли сверить независимые источники и позволяет ли происхождение проследить неверную цифру до её истока. Напряжение между ценой и простотой и воспроизводимостью, потому что хранение сырых данных и непрерывная сверка между системами не бесплатны, и соблазнительно удалить сырые входы, как только преобразованные таблицы выглядят верно. Принесите вашу политику хранения и неизменяемости сырых данных, список критичных пар систем, которые вы сверяете автоматически, и реальный пример ошибки, из которой вы смогли или не смогли выбраться переобработкой. Для государственного ведомства с законодательным обязательством прослеживать любое опубликованное число до исходных записей или корпорации перед регуляторным пересмотром отчётности неизменяемые сырые данные и автоматическая сверка не необязательная гигиена, а механизм, делающий исправление защитимым.

Взгляд по секторам

Стартап. Скорость и доверие важнее покрытия. Поместите горстку лёгких тестов в ваш инструмент преобразований (уникальность и непустота на ключах, принятые значения на столбцах, несущих смысл, полоса числа строк на источник) и добавьте мониторинг свежести и объёма только на немногих таблицах, питающих метрики компании. Направляйте каждое оповещение в один канал, которым владеет один инженер, и сопротивляйтесь покупке платформы наблюдаемости, пока у вас нет таблиц или команды, чтобы это оправдать. Цель заметить неверно помеченное поле до того, как оно раздует число, которое цитируют основатели, а не инструментировать всё.

Малый бизнес. Без инженера данных и при ограниченном бюджете опирайтесь на функции качества, уже встроенные в хранилище, инструмент BI или платформы SaaS, за которые вы платите, а не поднимайте отдельный стек. Сосредоточьте усилия на горстке чисел, действительно двигающих решения (выручка, воронка продаж, запасы), регулярно сверяйте их с независимым источником и воспринимайте оповещения поставщика о свежести и схеме как достаточно хорошие, когда они есть. Покупка качества, встроенного в уже работающие инструменты, побеждает построение конвейера, который некому сопровождать.

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

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

Примеры

Стартап. Компания из двадцати человек ведёт свой выход на рынок на хранилище, питаемом событиями продукта и платёжным провайдером. Рано неверно помеченное поле валюты тихо раздуло сообщаемую выручку на две недели, прежде чем кто-либо заметил, что потрясло доверие команды к каждой панели. Они ответили лёгким набором тестов в своём инструменте преобразований: уникальность и непустота на ключах, проверки принятых значений на столбцах валюты и статуса и полоса числа строк на источник. Они добавили базовый мониторинг свежести и объёма на немногих таблицах, питающих метрики компании, направляемый в один канал Slack, которым владеет один инженер. Это скромно, но ловит важные отказы, и основатели снова доверяют числам.

Крупная организация. Международный банк сверяет данные клиентов и транзакций из десятков систем-источников в управляемое хранилище, питающее регуляторные отчёты, модели риска и панели руководителей. Он ведёт контракты данных на каждой границе производителя, так что изменение схемы выше по течению версионируется и согласуется, а не обрушивается на потребителей. Платформа наблюдаемости мониторит свежесть, объём, схему и распределение по тысячам таблиц, с обнаружением аномалий на высокоценных и происхождением, публикуемым в каталог данных для анализа влияния. Инциденты с данными следуют тому же процессу серьёзности и дежурств, что и сбои сервисов, с уровнями обслуживания на конвейерах, питающих регуляторные подачи. Когда система-источник дрейфует, владеющую команду вызывают, а затронутые нижестоящие отчёты известны в течение минут, а не обнаруживаются регулятором.

Государственный сектор. Национальное статистическое ведомство публикует экономические индикаторы, которые рынки, политики и общество воспринимают как авторитетные, так что точность законодательное обязательство, а каждая опубликованная цифра должна быть проверяемой. Его конвейеры приземляют неизменяемые сырые записи обследований и административные записи, затем преобразуют их слоистыми протестированными стадиями со сверкой с итогами источников на каждом шаге. Полное происхождение позволяет аналитикам проследить любое опубликованное число до исходных записей, что и инструмент качества, и юридическое требование. Перед выпуском цифры проходят барьеры проверки валидности, полноты и согласованности с прошлыми периодами, а любая аномалия расследуется и документируется, а не публикуется. Неверная публичная статистика серьёзный инцидент, поэтому ведомство обращается с простоем данных с той серьёзностью, которой требует общественное доверие.

Бизнес-обоснование: мотивы, ROI и TCO

Отдача от качества данных и наблюдаемости приходит от сохранённого доверия, сокращённых инцидентов и избегнутых плохих решений. Заслуживающие доверия данные это фундамент, заставляющий каждое нижестоящее вложение в аналитику, бизнес-аналитику и ИИ действительно окупаться, потому что модель или панель хороши настолько, насколько хороши данные под ними. Когда проверки качества ловят плохую загрузку на границе, вы избегаете гораздо большей цены неверного числа, достигшего решения, клиента или отчёта. Происхождение сжимает расследование первопричины от дней ручного прослеживания до минут, что чистое возвращённое инженерное время. Наблюдаемость сокращает среднее время обнаружения от «когда потребитель пожалуется» до «когда конвейер откажет», и именно там избегается большая часть ущерба доверию.

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

Антипаттерны и ловушки

Воспринимание качества данных как разового проекта очистки вместо постоянной инженерной практики.
Обнаружение отказов от нижестоящих потребителей, а не от мониторинга в точке отказа.
Нет владения наборами данных, так что никто не подотчётен, когда что-то ломается, и никого не вызывают.
Производители меняют схемы или семантику без контракта, молча ломая каждого потребителя.
Оповещения об аномалиях настолько шумны, что команда отключает канал и пропускает настоящий инцидент.
Подача непроверенных данных прямо в модели машинного обучения, кодирующие ошибки в масштабе (глава 6.5).
Сопровождение происхождения как нарисованной вручную диаграммы, неверной на следующий день после рисования.
Погоня за совершенными данными везде вместо пригодного к использованию качества на таблицах, которые важны.
Удаление сырых данных, так что невозможно переобработать или сверить, когда ошибка качества всплывает позже.

Модель зрелости

Уровень 1, Начальный: Качество ничья работа. Проблемы находят потребители, обычно после того как неверное число достигло отчёта. Нет ни тестов, ни мониторинга, ни владения. Исправления это ручное тушение пожаров, и те же отказы повторяются.
Уровень 2, Развитие: Некоторые команды добавляют базовые тесты на критичные таблицы (ключи, пустые значения, принятые значения) и немного мониторинга свежести и объёма на наборах данных, которые им важнее всего. Практики работают там, где существуют, но покрытие и строгость различаются от команды к команде, ничто не стандартизировано, а инциденты по-прежнему обрабатываются реактивно.
Уровень 3, Стандартизация: Измерения качества определены с порогами, и те же ожидания применяются по командам, а не зависят от того, кто построил конвейер. Контракты данных управляют ключевыми границами производителей, наблюдаемость охватывает свежесть, объём, схему и распределение на важных таблицах, а происхождение поддерживает анализ влияния. У каждого важного набора данных есть названный владелец, а инциденты с данными следуют документированному процессу серьёзности и реагирования по организации.
Уровень 4, Управление: Качество и надёжность измеряются и контролируются относительно базовых значений. Простой данных отслеживается реальными метриками: среднее время обнаружения, среднее время решения, свежесть и точность относительно согласованных уровней обслуживания и бюджеты ошибок, которые набор данных может потратить, прежде чем запустится действие. Доли разрывов сверки, доли прохождения тестов и доли ложных срабатываний обнаружения аномалий отслеживаются во времени, оповещения настраиваются по этим числам, а не наугад, а решения «пускать или нет» о выпуске данных принимаются по измеренному качеству относительно базового значения, а не на надежде.
Уровень 5, Оркестрация: Качество и наблюдаемость всепроникающие, автоматизированные и адаптивные. Обнаружение аномалий ловит тонкий дрейф, контракты принуждаются механически, а происхождение захватывается автоматически и публикуется в каталог. У данных есть уровни обслуживания и дежурное владение, как у производственных сервисов, сверка идёт непрерывно, а разборы без обвинений питают устойчивое сокращение простоя данных. Качество интегрировано с управлением данными, машинным обучением и бизнес-планированием, а организация непрерывно пересматривает пороги, покрытие и владение по мере сдвигов ландшафта данных.

Идеи для обсуждения

Какие из ваших таблиц нанесли бы наибольший ущерб, будучи молча неверными неделю, и именно ли их вы мониторите больше всего?
Где контракт данных предотвратил бы ваш последний инцидент, вызванный выше по течению, и почему его не было?
Сколько инженерного времени сейчас занимает типичное расследование первопричины и сколько сэкономило бы автоматическое происхождение?
Обучаются ли какие-то из ваших моделей машинного обучения на данных, которые вы не проверяете, и какие ошибки они могут кодировать?
Достаточно ли хорошо настроены ваши оповещения, чтобы люди реагировали на каждое, или кто-то отключил канал?
На какие уровни обслуживания по свежести и точности ваши важнейшие потребители действительно подписались бы и могли бы вы выполнить их сегодня?

Главные выводы

Качество данных это пригодность к использованию по точности, полноте, согласованности, своевременности, валидности и уникальности.
Плохие данные хуже отсутствия данных, потому что молча портят решения и модели.
Тестируйте данные, как код: тесты-утверждения и ожидания плюс проверки схемы, в CI и в производстве.
Используйте контракты данных, чтобы сделать ожидания производителя и потребителя явными и принуждаемыми.
Наблюдайте свежесть, объём, схему и распределение, параллельно наблюдаемости программного обеспечения (глава 9.2).
Захватывайте происхождение для быстрой первопричины и анализа влияния и публикуйте его для потребителей.
Воспринимайте инциденты с данными как производственные инциденты, с владением, серьёзностью и уровнями обслуживания.
Инструментируйте там, где неверные данные вредят сильнее всего; стремитесь к пригодному к использованию качеству, а не совершенству везде.

Источники и дополнительное чтение

Barr Moses, Lior Gavish, and Molly Vorwerck, “Data Quality Fundamentals.”
Jacek Majchrzak, Sven Balnojan, and Marian Siwiak, “Data Contracts.”
Danette McGilvray, “Executing Data Quality Projects.”
Thomas C. Redman, “Data Driven: Profiting from Your Most Important Business Asset.”
Laura Sebastian-Coleman, “Measuring Data Quality for Ongoing Improvement.”
Joe Reis and Matt Housley, “Fundamentals of Data Engineering.”
DAMA International, “DAMA-DMBOK: Data Management Body of Knowledge.”
ISO/IEC 25012, “Data quality model.”