Бесплатный фрагмент - Книга по качеству данных

О том, как написана эта книга

Добро пожаловать. Прежде чем мы перейдём к метрикам, пайплайнам и правилам, которые экономят бизнесу время и деньги, важно честно рассказать, как появился этот текст.

Эту книгу создал не один человек в одиночку. Она родилась в тандеме живого автора-куратора и большой языковой модели. Мы работали по принципу «архитектор + строитель»:

— Человек задавал вектор, формулировал промпты, оттачивал метафоры, придумывал запоминающиеся акронимы (ЧПУ, НДУНФ, СВУПК+Д и другие) и собирал разрозненные фрагменты в единую логическую цепочку.

— ИИ выступал в роли неутомимого соавтора: генерировал черновики глав, писал примеры кода, составлял таблицы, чек-листы и формулировал «якорные фразы».

Тем не менее, IT-инструменты развиваются быстрее, чем печатаются книги. Синтаксис библиотек, интерфейсы Great Expectations или Airflow могут измениться. Все примеры кода — это рабочие шаблоны и концепции, а не готовые production-решения. Перед внедрением обязательно адаптируйте их под ваш стек и протестируйте.

Если вы цените честность, практическую пользу и отсутствие воды — вы в правильном месте. Переворачивайте страницу. Впереди только то, что действительно работает.

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

ВАЖНО

Все пороговые значения в этой книге — примеры. В вашем бизнесе 95% может быть критично, а 99% — избыточно. Устанавливайте пороги вместе с владельцем данных.

ЮРИДИЧЕСКОЕ ПРЕДУПРЕЖДЕНИЕ И ОГРАНИЧЕНИЕ ОТВЕТСТВЕННОСТИ

1. Относительно примеров кода

Все скрипты, SQL-запросы и фрагменты кода, приведенные в этой книге, носят исключительно иллюстративный и учебный характер. Они демонстрируют концепции, но не являются готовыми решениями для промышленной эксплуатации (продакшена). Использование этих примеров в ваших системах осуществляется на ваш собственный риск. Автор не несет ответственности за любые убытки, потерю данных, сбои в работе систем или инциденты безопасности, возникшие в результате применения, модификации или интеграции предоставленного кода. Перед внедрением обязательно: (1) адаптируйте код под свой стек, (2) протестируйте в среде, изолированной от боевых данных (staging), (3) получите одобрение вашей команды инженеров и безопасности.

2. Относительно законодательства и регуляторики
Упоминания законов (включая, но не ограничиваясь, 152-ФЗ, GDPR), штрафов и требований регуляторов приведены исключительно для иллюстрации бизнес-рисков. Юридические нормы динамичны, их толкование варьируется в разных юрисдикциях и зависит от конкретной деятельности компании. Данная книга не является юридической консультацией и не заменяет профессиональных комплаенс-специалистов. Для обеспечения правовой чистоты ваших процессов настоятельно рекомендуем обращаться к квалифицированным юристам.

3. Относительно бизнес-решений и финансовых показателей
Советы по оценке ROI, матрицы приоритетов и рекомендации по взаимодействию с руководством основаны на отраслевом опыте, но не гарантируют конкретного финансового результата. Любые управленческие решения, принятые на основе материалов книги, остаются на ответственности лица, их принимающего.

Почему качество данных — это отдельная дисциплина

Метафора

Представьте, что 100 лет назад вы строите дом. Вам нужны: плотник, каменщик, кровельщик. Но вам не нужен отдельный специалист по качеству гвоздей.

Почему? Потому что:

— Гвоздей мало (десяток коробок на дом)

— Их можно пересчитать вручную

— Если гвоздь кривой — это видно сразу

— Ошибка стоит недорого (заменил гвоздь — и дальше работаешь)

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

Качество данных — это тот же «специалист по болтам». Он появился не потому, что люди стали ленивее. А потому, что масштаб, скорость и цена ошибки выросли в миллионы раз.

Как менялись данные и почему контроль перестал быть ручным

Эпоха перфокарт (1960–1980): Данных было мало. Их можно было проверить глазами. За качество отвечал программист, который их и вводил.

Эпоха баз данных (1990–2010): Данных стало больше. Появились CHECK, FOREIGN KEY. База начала сама «не пускать» очевидный мусор. За качество отвечали администраторы и аналитики.

Эпоха Big Data и ИИ (2010–сейчас): Миллиарды записей, сотни источников, решения в реальном времени. Здесь человеческий контроль уже не работает. Появилась роль Data Quality Engineer.

Пять причин, почему DQ выделилось в отдельное направление

— Масштаб: Раньше — 10 000 строк в Excel. Сейчас — 10 миллионов событий в час. Никакой человек не проверит это вручную. Нужны автоматические конвейеры.

— Скорость: Раньше отчёт строился раз в месяц. Сейчас кредитный скоринг, фрод-детекция и персонализация работают в реальном времени. Ошибка стоит денег здесь и сейчас.

— Разнообразие источников: Раньше данные вводились в одну систему. Сейчас они летят из CRM, ERP, мобильных приложений, IoT-датчиков и внешних API. Каждый источник — свой формат и свои ошибки.

— Регуляторика. Раньше «ошиблись в отчёте — пересдадим». Сейчас 152-ФЗ, GDPR, отчётность в ЦБ и ФНС. Ошибка в данных — это штраф до 4% от оборота или блокировка счёта.

— ИИ и ML. Раньше данные шли в отчёты. Сейчас они кормят модели. Ошибка в обучающей выборке означает, что модель выучит неправильные паттерны и будет ошибаться автоматически и уверенно.

Короткая история профессии

DQ выросло из практики. В 1990-х появились хранилища (DWH) — и данные начали «портиться» при переносе. В 2000-х закон SOX в США заставил компании юридически отвечать за точность финансов. В 2010-х Big Data сделал ручной контроль невозможным. В 2015-м GDPR превратил качество из «хорошо бы» в юридическое требование. А сегодня генеративный ИИ усилил принцип GIGO: мусор на входе теперь порождает не просто ошибку, а уверенную галлюцинацию.

Что изменилось для вас лично?

Раньше вы могли быть «просто аналитиком» или «просто инженером», и качество данных было побочной задачей. Сейчас, если вы работаете с данными, вы автоматически отвечаете за их пригодность. Вопрос только в том, будете ли вы делать это осознанно — с инструментами и процессами — или продолжите «тушить пожары» вручную.

Почему эта книга написана сейчас?

Не потому, что DQ стало «модным». А потому, что практика опередила литературу:

DQ вышло из IT-подвала.

Это больше не техническая задача «админа базы». Это бизнес-дисциплина, которая напрямую влияет на выручку, комплаенс и устойчивость ИИ-моделей.

Инструменты готовы к продакшену.

Great Expectations, dbt, Data Contracts — это не эксперименты, а рабочий стек. Но знания о них размазаны по официальной документации, форумам и разрозненным статьям.

Между академикой и практикой — пустота.

Когда я сам искал материал, выбор был таким: либо 600-страничные энциклопедии стандартов (вроде DAMA DMBOK), либо фрагментарные посты без связной системы. Не хватало одного компактного руководства, которое соединяет теорию, код и реальные процессы без воды, пустых обещаний и попытки объять необъятное.

Эта книга — попытка заполнить этот пробел. Практический минимум для тех, кому нужно начать настраивать проверки, считать ROI и выстраивать процессы завтра, а не через полгода изучения теории.

⚓ Якорная фраза

Качество данных выделилось в отдельное направление не потому, что люди стали ленивее. А потому, что масштаб, скорость и цена ошибки выросли в миллионы раз. DQ — это не мода. Это ответ на объективную реальность.

Вы спросите: «Хорошо, я понял, что качество данных — это отдельная дисциплина. Но зачем мне, обычному аналитику или инженеру, в это вникать? У меня и так отчёты горят».

Затем, чтобы не быть голословным, перейдём к самому убедительному аргументу — деньгам. Одна ошибка в таблице может стоить миллионов. И сейчас вы увидите это на цифрах.

Почему качество данных — это деньги

Перед тем как нырять в технические детали, давайте договоримся о главном. Качество данных — это не про «нравится / не нравится». Это про деньги. Одна ошибка в таблице может стоить миллионов. Прочитайте эту главу — и вы никогда не скажете «подумаешь, опечатка».

Метафора

Представьте, что вы курьер в доставке еды. Навигатор показывает адрес, но координаты сбиты на 200 метров. Вы едете не туда. Клиент не получает пиццу. Компания теряет 500 рублей. За день так 10 раз. За месяц — 150 000 рублей. За год — почти 2 миллиона. И никто специально не врал. Просто данные чуть-чуть ошиблись.

Качество данных — это не про перфекционизм. Это про деньги, время и доверие.

Важное уточнение: чистота ≠ полезность

Перед тем как мы перейдём к страшным историям о потерянных деньгах, давайте зафиксируем одну тонкость, о которой молчат 90% статей по качеству данных.

Можно добиться 100% полноты, уникальности и валидности. Можно убрать все NULL, все дубликаты, все неверные форматы. И при этом данные останутся бесполезными для принятия бизнес-решений. Почему? Потому что вы чистили не те поля, не с той тщательностью и не для той задачи.

Пример

Команда полгода наводила порядок в справочнике «Товары»: убрала дубликаты, проставила все категории, унифицировала единицы измерения. Гордость отдела качества данных. Приходит аналитик и говорит: «Мне для прогноза продаж нужна история цен за последние 3 года. А у вас хранится только текущая цена. Ваш чистый справочник бесполезен».

Вывод

Чистота ради чистоты — это игрушки. Полезность для решения — это деньги. Перед тем как чистить данные, спросите себя: «Какое бизнес-решение будет принято на основе этих данных?» Если ответа нет — возможно, вы чистите не то.

Три страшных истории из реальной жизни

Эти истории не случайность. Их объединяет один и тот же механизм — закон GIGO. Давайте разберёмся, почему так происходит и как с этим жить.

Принцип GIGO (Garbage In, Garbage Out)

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

GIGO расшифровывается как Garbage In, Garbage Out — «мусор на входе, мусор на выходе».

Что это значит: Если в вашу систему попали грязные данные — на выходе вы получите грязные отчёты, предсказания и решения. Система не может «додумать» чистоту. Она честно переработает мусор в мусор.

И вот что важно понять: Это не метафора и не философия. Это инженерный факт. Алгоритм не знает, что 01.01.1900 — это не реальная дата рождения, а заглушка NULL. Модель не догадается, что возраст 999 — это опечатка. Система сделает ровно то, что вы сказали. А вы сказали: «возьми эти данные и обработай их как есть». Мусор на входе порождает не просто ошибку, а уверенную ошибку — компьютер не сомневается, он выдаёт результат с той же самоуверенностью, как если бы данные были идеальными. Именно поэтому GIGO — главный закон, с которого начинается любое качество данных.

Три уровня GIGO (как это выглядит в реальности)

Почему GIGO — это не просто поговорка, а закон

«Вы не можете „очистить“ данные волшебством. Алгоритм не догадается, что 01.01.1900 — это не реальная дата рождения, а заглушка NULL. Модель не поймёт, что возраст 999 — это опечатка. Система сделает ровно то, что вы сказали. А вы сказали: возьми эти данные и обработай их как есть.»

Что делать с GIGO (коротко)

⚓ Якорная фраза:

Мусор на входе — мусор на выходе. И компьютер не скажет «фу», он просто сделает свою работу.

Главная формула

Качество = пригодность для конкретной задачи

Данные не бывают «чистыми» или «грязными». Они бывают достаточно хорошими, чтобы принять правильное решение.

⚓ Якорная фраза

Чистота данных измеряется не в процентах, а в рублях и минутах простоя.

Шпаргалка по терминам

Итак, мы поняли, что грязные данные дорого стоят. Теперь закономерный вопрос: а откуда они вообще берутся? Кто виноват? Ответ — в следующей главе.

Но прежде чем кидаться чинить, давайте разберёмся: откуда вообще берутся эти дыры в данных? Спойлер: виноваты не только люди. Открываем первую дверь — «Комнату слухов».

ГЛАВА 1. Комната слухов (почему данные врут)

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

Метафора

Представьте игру в «испорченный телефон» в офисе из 50 человек. Вы шепчете: «В пятницу в 15:00 встреча в переговорной А». На выходе: «В пятницу 15 человек встречаются в переговорной, нужен торт».

С данными — то же самое. Каждый шаг вносит искажения:

— Человек вводит номер телефона в компьютер → может опечататься

— Сайт записывает действие в файл лога (журнал событий) → может потерять долю секунды

— Программа переноса данных (ETL) соединяет две таблицы → может случайно размножить строки

— Программа для отчётов (BI) строит график → может не так сгруппировать данные

Итог: вы смотрите на экран с графиками (дашборд), а там неправда. И никто специально не врал.

И здесь кроется главная ловушка: мы привыкли искать виноватого. «Кто ошибся? Кто не досмотрел?» Но в 70% случаев виноват не человек, а процесс, который не защищает от ошибки, или устройство, которое теряет данные на физическом уровне. Если каждый шаг цепочки добавляет по 1% искажений, на выходе вы получите не 99% правды, а 96% — и это уже критично для бизнеса. Поэтому вместо поиска «стрелочника» мы будем разбирать корневые причины. Их ровно три — и они скрываются за аббревиатурой ЧПУ. О них — дальше.

Почему данные врут?

Три корневые причины (далее — ЧПУ)

ЧПУ расшифровывается как Человек — Процесс — Устройство.

70% проблем — из Процесса и Устройства. Не вините людей.

Пять типов грязи (далее — НДУНФ)

НДУНФ расшифровывается как Неполнота — Дубликаты — Устарелость — Неверный формат — Физическая ошибка.

Важно: в аббревиатуре НДУНФ две буквы «Н» — это разные типы грязи (Неполнота и Неверный формат). Это не опечатка. Это напоминание: проблемы с данными могут выглядеть похоже, но лечиться по-разному.

Как думать об этих пяти типах грязи (короткое правило)

— Неполнота — «чего-то не хватает». Самая частая проблема. Начинайте проверку с неё. NULL в поле — самый очевидный свидетель того, что с данными что-то не так.

— Дубликаты — «одно и то же дважды». Бьёт по карману: две отгрузки, два начисления бонусов, двойной расчёт комиссии. Один дубликат в таблице заказов может обойтись компании в сотни тысяч рублей.

— Устарелость — «данные есть, но они старые». Коварная проблема: ошибку видно не сразу. Вы смотрите на цену в отчёте, она корректна по формату, но на самом деле уже не актуальна. Устарелость — единственный тип грязи, который убивает качество даже при 100% заполненности всех полей.

— Неверный формат — «данные есть, но их нельзя прочитать». Ломает интеграции. Если поле email содержит строку без @, а поле date — текст вместо даты, ваш ETL упадёт, и данные не загрузятся. Это самый «громкий» тип грязи — система сообщает об ошибке явно.

— Физическая ошибка — «данные есть, но они сломаны». Редко, но больно. Битые сектора на диске, повреждённые файлы, сбой при записи. Это уже не про бизнес-логику, а про инфраструктуру.

Почему порядок букв именно такой: Неполнота — самая частая проблема, с неё начинают. Дубликаты — самая дорогая, они идут второй. Устарелость — самая коварная, она третья. Неверный формат — самый «громкий», его нельзя игнорировать. Физическая ошибка — редкая, но фатальная, она замыкает список. Проверяйте данные в этом же порядке: сначала полноту, потом дубликаты, потом актуальность, потом форматы, и только в конце — физическую сохранность.

⚓ Якорная фраза

Никто Данные Уважать Не Фурычит

Если вы не знаете, с чего начать — начните с Неполноты. NULL — самый очевидный свидетель того, что с данными что-то не так.

Важное пояснение

В этой главе мы говорим об «Устарелости» как о типе грязи (буква «У» в НДУНФ). В главе 2 вы встретите «Своевременность» как одно из измерений качества (буква «С» в СВУПК+Д).

Это «одно и то же явление», просто мы смотрим на него с двух сторон:

— «Как тип грязи» (НДУНФ) → «В данных есть проблема: цены не обновлены».

— «Как измерение качества» (СВУПК+Д) → «Мы измеряем, насколько данные свежие, в днях».

Это не дублирование, а разный угол обзора. Как молоток: можно сказать «это инструмент», а можно — «это предмет весом 500 граммов». Оба утверждения верны, просто для разных задач.

Матрица «Боль × Частота»

Не каждая проблема одинаково опасна.

Правило: прежде чем чистить данные, ответьте на два вопроса:

— Что случится, если мы это не починим? (боль)

— Как часто это случается? (частота)

Что делать с найденным (чиним по типам грязи НДУНФ)

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

ГЛАВА 2. Семь дверей в подвале (измерения качества)

В предыдущей главе мы научились узнавать грязь в лицо: неполнота, дубликаты, устарелость… Но менеджер спросит: «Насколько плохо? А это критично?» Для этого нужны измерения. Но есть одна проблема. Прежде чем измерять качество, нужно убедиться, что данные вообще можно читать. Что фундамент не треснул. Поэтому мы начнём с фундамента дома. А потом откроем семь дверей в подвале.

Метафора

Вы решили купить дом. Заходите — красиво. Но вы идёте в подвал. Там семь дверей. За каждой — скрытый дефект. Но прежде чем их открывать, вы проверяете фундамент. Если фундамент треснул — остальные двери не имеют значения. В мире данных фундамент — это целостность данных (Data Integrity).

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

Итого у нас:

— Основа — Фундамент (целостность)

— Двери 1–6 — Классические измерения качества

— Дверь 7 — Доступность (раньше была заперта)

Часть 1. Фундамент дома (Data Integrity)

Прежде чем говорить о качестве, давайте убедимся, что данные не сломаны на базовом уровне.

Что такое Data Integrity (простым языком)

Data Integrity (целостность данных) — это набор правил на уровне базы данных, которые гарантируют, что:

— Данные физически сохранены правильно (не битые, не потерянные)

— Связи между таблицами не сломаны (нет заказа без клиента)

— Значения не нарушают базовые ограничения (возраст не отрицательный, email содержит @)

Отличие от качества данных: качество — про то, насколько данные хороши для задачи. Целостность — про то, можно ли им вообще доверять на базовом уровне.

СВУПК+Д

С — Своевременность, В — Валидность, У — Уникальность, П — Полнота, К — Консистентность, Д — Доступность

Важное пояснение: Порядок букв в акрониме — не случайный. Он выстроен от «внешних» характеристик данных (когда пришли, как выглядят) к «внутренним» (не противоречат ли сами себе) и заканчивается доступностью — тем, без чего все остальные измерения бессмысленны.

DBA (Database Administrator, администратор баз данных) — специалист, который отвечает за физическое здоровье базы данных: резервные копии, права доступа, производительность, настройку серверов. В контексте качества данных DBA отвечает за физическую целостность

Четыре кита целостности

Ссылочная — Структурная — Семантическая — Физическая

Четыре типа целостности выстроены в иерархию — от самого «строгого» (база данных не даст нарушить) к самому «гибкому» (человек решает, что считать правильным). Каждый следующий тип надстраивается над предыдущим. Нельзя проверить семантическую целостность, если сломана структурная. И нельзя проверить структурную, если нарушена физическая.

⚓ Якорная фраза для Integrity

Целостность — это когда база данных не даст вам выстрелить себе в ногу. Качество — когда вы сами не целитесь в ногу.

Разберём каждый тип

1. Ссылочная целостность (Referential Integrity)

Вопрос: Каждый customer_id в таблице orders существует в таблице customers?

Как проверяется: Внешними ключами (FOREIGN KEY) в базе данных.

sql

— Правильно: внешний ключ защищает от сиротских записей

CREATE TABLE orders (

order_id INT PRIMARY KEY,

customer_id INT,

FOREIGN KEY (customer_id) REFERENCES customers (customer_id)

);

— Теперь нельзя вставить заказ с customer_id = 999, если такого нет в customers

Что происходит без ссылочной целостности

Важно: Многие компании отключают внешние ключи «для скорости». Это как снять ремни безопасности, чтобы быстрее ехать. Работает до первого удара.

2. Структурная целостность (Structural Integrity)

Вопрос: Соответствуют ли данные схеме таблицы?

Что проверяет:

Пример без структурной целостности

sql

— Плохо: никаких ограничений

CREATE TABLE users (

email VARCHAR (255),

age INT

);

— Можно вставить что угодно

INSERT INTO users VALUES (NULL, -500); — email пустой, возраст -500

INSERT INTO users VALUES (’a’, 200); — email без @, возраст 200

Пример со структурной целостностью

sql

— Хорошо: ограничения на месте

CREATE TABLE users (

email VARCHAR (255) NOT NULL UNIQUE CHECK (email LIKE '%@%»),

age INT NOT NULL CHECK (age BETWEEN 0 AND 120)

);

— Следующие вставки не пройдут:

INSERT INTO users VALUES (NULL, 30); — NOT NULL violation

INSERT INTO users VALUES (’a’, 30); — CHECK (email) violation

INSERT INTO users VALUES ('a@b.com’, -5); — CHECK (age) violation

3. Семантическая целостность (Semantic Integrity)

Вопрос: Имеют ли значения смысл в реальном мире?

Это бизнес-правила, которые база данных не знает, но вы можете добавить через CHECK или триггеры.

Отличие от валидности (В из СВУПК+Д): Валидность проверяет формат (email содержит @). Семантическая целостность проверяет смысл (дата рождения не в будущем).

4. Физическая целостность (Physical Integrity)

Вопрос: Данные физически сохранены и доступны?

Это уже не про SQL, а про инфраструктуру.

Простым языком

Физическая целостность — это когда вы можете спать спокойно, зная, что база данных не исчезнет за ночь.

Матрица «Integrity vs Quality»

Золотое правило: Сначала Integrity, потом Quality. Бесполезно чистить полноту телефона, если база данных может хранить возраст -500.

Чек-лист «Проверка фундамента» (Integrity Audit)

Перед тем как заниматься качеством данных, проверьте:

Ссылочная целостность

— На все ли внешние ключи (FOREIGN KEY) созданы индексы?

— Есть ли сиротские записи? (заказы без клиентов, платежи без заказов)

— Можно ли удалить клиента, если у него есть заказы? (ON DELETE RESTRICT или CASCADE?)

Структурная целостность

— Во всех ли критических полях стоит NOT NULL?

— Есть ли дубликаты там, где должен быть UNIQUE?

— Есть ли первичные ключи (PRIMARY KEY) во всех таблицах?

Семантическая целостность

— Есть ли CHECK на возраст, даты, email, телефон?

— Есть ли правила, которые проверяют согласованность связанных полей? (статус и дата)

Физическая целостность

— Настроены ли автоматические бэкапы? Когда последний успешный?

— Есть ли мониторинг здоровья дисков?

— Поддерживают ли транзакции ACID?

Если хотя бы на один вопрос «нет» — начинайте с Integrity, а не с Quality.

Часть 2. Семь дверей качества (СВУПК+Д)

Фундамент проверили. Теперь можно открывать семь дверей в подвале. За каждой — одно измерение качества данных. Запомнить их поможет акроним.

Акроним для запоминания: «СВУПК + Д»

⚓ Якорная фраза

Семь Врат Указывают Путь: Качество Достигается

Примечание про Точность

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

Качество — это всегда компромисс

Теперь, когда вы знаете семь измерений качества, у вас может возникнуть соблазн: «Давайте везде выставим строгие пороги! 99.9% полноты! 100% уникальности! Никаких NULL!»

Не торопитесь. Качество данных конфликтует с тремя другими важными вещами.

Первое — скорость

Чем больше проверок вы добавите, тем медленнее данные будут загружаться. Если вы навесите 10 CHECK-ограничений на таблицу, вставка 1000 строк может замедлиться в 3–5 раз.

Второе — гибкость

Жёсткие правила мешают быстро менять процессы. Вы запретили NULL в новом поле — а через месяц бизнес говорит: «Это поле теперь необязательное, мы от него отказались». Ваше правило придётся переписывать.

Третье — стоимость

Качество требует ресурсов. Лицензия на Monte Carlo — $50 000 в год. Время инженера, который настраивает Great Expectations, — тоже деньги. Иногда дешевле терпеть 5% NULL, чем строить систему, которая их ловит.

Реальность

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

Практический совет

Используйте слоёную защиту. На сырых данных (Bronze) — минимум проверок (только «не сломалось ли»). На витринах (Gold) — максимум проверок (потому что туда идёт бизнес). И всегда заранее договаривайтесь с бизнесом: чем мы жертвуем?

А теперь вернемся к СВУПК + Д и пройдемся по каждой двери с инструментами в руках.

Итак, мы договорились: не нужно гнаться за 100% везде. Но как тогда выбирать, что проверять, а что — нет? Для этого нам и нужны наши семь дверей — каждое измерение подскажет, где компромисс приемлем, а где — нет. Давайте пройдём по ним по порядку.

Детали за каждой дверью

С — Своевременность

Вопрос: Не устарели ли данные?

sql

SELECT

MAX (order_date) as последний_заказ,

CURRENT_DATE — MAX (order_date) as дней_без_обновления

FROM orders

Метрика: сколько дней прошло с последнего обновления.

Порог тревоги: если больше 7 дней — данные умерли.

В — Валидность

Вопрос: Соответствует ли значение правильному формату?

sql

SELECT *

FROM users

WHERE email NOT LIKE '%@%' — в email нет собачки

OR age NOT BETWEEN 0 AND 120 — возраст 200 лет

OR gender NOT IN («M», «F») — пол не М и не Ж

Метрика: доля правильных значений / все значения.

Порог тревоги: если меньше 98% — много ошибок.

У — Уникальность

Вопрос: Нет ли двух одинаковых ключей?

sql

SELECT order_id, COUNT (*) as количество_дублей

FROM orders

GROUP BY order_id

HAVING COUNT (*)> 1 — оставляем только дубликаты

Метрика: 1 — (количество дубликатов / общее количество строк).

Порог тревоги: если меньше 99% — дубликатов слишком много.

П — Полнота

Вопрос: Все ли данные на месте (нет пустых значений NULL)?

sql

SELECT

COUNT (*) as всего_строк,

COUNT (phone) as заполнено_телефонов,

(COUNT (*) — COUNT (phone)) * 100.0 / COUNT (*) as процент_пустот

FROM users

Метрика: количество заполненных клеток / общее количество строк.

Порог тревоги: если меньше 95% — слишком много пустот.

К — Консистентность (согласованность)

Вопрос: Не противоречат ли данные сами себе?

sql

SELECT *

FROM orders

WHERE status = «Доставлен» — статус «доставлен»

AND delivery_date IS NULL — но даты доставки нет

Метрика: количество противоречий / общее количество строк.

Порог тревоги: если больше 1% — серьёзные противоречия.

Д — Доступность

Вопрос: Может ли бизнес-пользователь получить данные?

Что проверяем:

— Есть ли у пользователя права на чтение таблицы?

— Открывается ли отчёт (дашборд) быстрее чем за 10 секунд?

— Не упал ли сервер с базой данных?

Метрики:

— Время выполнения запроса (должно быть <5 секунд)

— Доступность дашборда (должна быть> 99% времени)

Порог тревоги: если дашборд не открывался больше часа — проблема с доступностью.

Т — Точность (отдельно, требует внешнего эталона)

Вопрос: Соответствуют ли данные реальности?

sql

SELECT COUNT (*) as несовпадения

FROM crm_clients c

JOIN passport_data p ON c.client_id = p.client_id

WHERE c.age!= p.age — возраст в CRM не совпадает с паспортными данными

Проблема: вы не можете проверить точность, если у вас нет правильного источника (эталона). Им может быть:

— Бумажный документ

— Данные из государственного реестра

— Ручной пересчёт товаров на складе

Метрики качества данных (шпаргалка)

⚓ Якорная фраза

Сначала Integrity — потом Quality. Сначала фундамент — потом семь дверей.

А для запоминания измерений

Семь Врат Указывают Путь: Качество Достигается

Своевременность — Валидность — Уникальность — Полнота — Консистентность — плюс Доступность и Точность (отдельно).

Вопросы для самопроверки (после глав 1–2)

— Вы нашли ошибку в отчёте. Руководитель говорит: «Подумаешь, пара ошибок». Что вы ответите?

Ответ

«Чистота данных измеряется не в процентах, а в рублях и минутах простоя. Давайте посчитаем, во сколько обходится эта ошибка за год.»

— (Глава 1) Вы смотрите на таблицу. В поле «телефон» много пустых строк, в поле «email» — строки без @, а один заказ записан дважды. Как классифицировать эти три проблемы по НДУНФ?

Ответ

— Пустые строки в телефоне → Н (Неполнота, NULL)

— Email без @ → Н (Неверный формат) — да, та же буква, но другой тип

— Дубликат заказа → Д (Дубликаты)

— (Глава 1) Прежде чем чинить проблему, вы должны ответить на два вопроса. Какие?

Ответ

— Что случится, если мы это не починим? (боль)

— Как часто это случается? (частота)

Матрица «Боль × Частота»: чините то, что болит и часто встречается.

— (Глава 2) В чём разница между Integrity (целостностью) и Quality (качеством) данных? Приведите по одному примеру для каждого.

Ответ

Золотое правило

Сначала Integrity, потом Quality. Бесполезно чистить полноту телефона, если в базе данных можно хранить возраст -500.

Мы научились измерять качество данных по семи дверям. Но теория — это одно. А как на практике быстро оценить новую таблицу, когда вы не знаете, что означают её столбцы?

Для этого нужен рентген. Переходим к профилированию данных.

ГЛАВА 3. Рентген багажа в аэропорту (профилирование данных)

В предыдущей главе мы узнали семь измерений качества. Теперь представьте: вам дали новую таблицу. Вы не знаете, что означают столбцы. Но за 10 минут нужно сказать — «с данными всё в порядке» или «тут что-то гнилое». Это называется профилированием. Как рентген в аэропорту.

Метафора

Вы — инспектор в аэропорту. Перед вами чемодан. Вы не знаете, что внутри. Но за 30 секунд нужно решить: «Обычный багаж или требует досмотра?»

Вы просвечиваете его рентгеном. На экране:

— Плотные области (много однотипного — например, 100 одинаковых флаконов) → в данных это столбцы с малым количеством уникальных значений. Например, поле gender со значениями только «M» и «F». Нормально, если так и задумано. Но если поле order_id тоже имеет всего два уникальных значения — это подозрительно.

— Пустоты (ничего нет — как NULL в данных) → рентген сразу показывает пустые зоны. В данных вы видите столбцы, где 40%, 60% или 90% значений — NULL. Это не обязательно проблема, но это место, куда вы посмотрите в первую очередь.

— Странные формы (выбросы — например, что-то очень большое или очень маленькое) → в данных это значения, которые выбиваются из общего ряда. Возраст 999 лет. Сумма заказа -5000 рублей. Email без @. Рентген не говорит, что именно это за предмет, но он говорит: «Здесь что-то не так, проверь».

Профилирование данных — это тот же рентген. Вы ещё не знаете бизнес-смысла столбцов, но уже видите их статистическую структуру. Вы не знаете, что означает столбец status_code, но видите, что в нём 95% значений — «1», а остальные 5% — «2», «3» и «9». Это подозрительно. Вы не знаете, что такое order_amount, но видите, что есть строки с отрицательными значениями и одна строка на миллиард. Это подозрительно. Вы не знаете бизнес-контекста, но ваши глаза уже нашли проблемы.

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

Что такое профилирование данных

Профилирование — это быстрая диагностика таблицы без знания бизнес-контекста. Вы смотрите на статистику и находите подозрительные места за 5–10 минут.

Как применять семь измерений (СВУПК + Д) при рентгене

Вы не знаете бизнес-смысла столбцов, но уже можете сказать, где искать проблемы. Смотрите на столбец с датами — если максимальная дата — прошлый год, данные умерли. Смотрите на столбец с email — если есть строки без @, формат сломан. Смотрите на столбец с ценой — если есть отрицательные значения или миллиарды, это выбросы. Рентген не требует контекста, только внимательности.

Выберите инструмент по вкусу. Для быстрой проверки подойдёт SQL, для автоматической — Python, для маленьких таблиц — Excel.

Три инструмента для рентгена

1. SQL (если вы работаете с базами данных)

sql

SELECT

COUNT (*) as всего_строк,

COUNT (DISTINCT column) as уникальных_значений,

COUNT (column) as заполнено_не_NULL,

MIN (column) as минимум,

MAX (column) as максимум,

AVG (CAST (column AS FLOAT)) as среднее

FROM your_table

2. Python (если вы программист)

python

import pandas as pd

from ydata-profiling import ProfileReport

df = pd.read_csv (’your_data. csv’)

profile = ProfileReport (df, title=«Рентген багажа»)

profile.to_file("report.html»)

Это создаст HTML-отчёт со всей статистикой автоматически.

3. Ручной (Excel / Google Sheets) — для маленьких таблиц

— Выделите столбец → внизу Excel покажет количество значений, пустых клеток, уникальных значений

— Сортировка → посмотрите на минимальное и максимальное значение

— Фильтр → найдите странные значения

Не нужно использовать все три инструмента сразу. Если таблица маленькая (до 100 000 строк) — откройте Excel. Если вы знаете SQL — напишите один запрос. Если вы программист и работаете с данными каждый день — установите ydata-profiling, он сделает отчёт за вас. Инструмент подбирайте под размер данных и ваши навыки, не наоборот.

Чек-лист рентгена

Это ваш главный инструмент при знакомстве с новой таблицей. Распечатайте его или сохраните в закладки. Каждый раз, когда вам дают новую таблицу, проходите по буквам С-В-У-П-К-Д-Т за 5–10 минут. Вы будете удивлены, как часто «чистые» данные оказываются грязными после такой проверки.

Живой пример

Таблица orders (заказы). Рентген по семи измерениям:

В реальной таблице вы редко встретите все семь проблем сразу. Чаще всего будет 2–3. Не пытайтесь чинить всё. Найдите самое больное (матрица «Боль × Частота» из главы 1) и начните с него. В примере самая критичная проблема — дубликаты заказов (потеря денег) и NULL в customer_id (потеря клиентов). Даты в будущем и выбросы — подождут.

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