Сергей Дегтев Книга о качестве данных

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

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

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

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

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

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

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

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

Метафора

Представьте, что 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 года. А у вас хранится только текущая цена. Ваш чистый справочник бесполезен».

Вывод:

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

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

Ситуация

Цена ошибки

Почему произошло

Два одинаковых заказа ? отгрузка двух холодильников

?60 000 ?

Дубликат в таблице заказов

Дата рождения клиента 01.01.1900 ? кредитный скоринг сломался

Потерян клиент на 2 млн ?

Невалидная (неправильная) дата - заглушка вместо пустого значения

В отчёте продажи за октябрь = 0 ? менеджеры уволились

Хаос в управлении

Процесс переноса данных не загрузил информацию 3 дня

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

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

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

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

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

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

Уровень

Что попало на вход

Что получили на выходе

Во сколько обошлось

Смешно

В поле «возраст» ввели 999

Аналитик полдня искал «клиента-вампира»

4 часа рабочего времени

Больно

Дубликат заказа из-за двойного нажатия кнопки

Отгрузили два холодильника вместо одного

60 000 ?

Смертельно

В обучающую выборку ML-модели попали неправильные метки

Модель предсказывает кредитный рейтинг со смещением

Потерянный клиент на 2 млн ? + репутационные риски

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

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

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

Вместо

Делайте

«Мы потом почистим»

«Мы не пустим грязь на вход» - валидация на границе системы

«Ну подумаешь, пара ошибок»

Посчитайте, во сколько обходится «пара ошибок» за год

«Модель сама разберётся»

Модель не разберётся. Она выучит ваши ошибки и будет их воспроизводить

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

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

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

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

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

Задача

Достаточно

Слишком много

Массовая рассылка

95% email-адресов правильные

Проверять каждый email по телефонному звонку

Медицинская диагностика

99.99% точность

Любая ошибка - риск жизни

Внутренний отчёт (дашборд)

90% полноты

Чистить данные неделями

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

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

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

Термин

Расшифровка

Простыми словами

NULL

Пустое значение (нет данных)

В клетке таблицы ничего нет

ETL

Extract, Transform, Load (Извлечение, Преобразование, Загрузка)

Процесс, который перекладывает данные из одной базы в другую

BI

Business Intelligence

(Бизнес-аналитика)

Программа для рисования графиков и отчётов по данным

CHECK

Ограничение-проверка в базе данных

Правило «возраст не может быть больше 120»

Дашборд

Dashboard (приборная панель)

Экран с графиками и цифрами для управления бизнесом

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

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

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

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

Метафора

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

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

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

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

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

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

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

Почему данные врут? Три корневые причины (далее - ЧПУ)

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

Буква

Причина

Пример

Доля проблем

Ч

Человек

Опечатка в номере карты, ручной ввод

~30%

П

Процесс

Программа переноса данных (ETL) сломалась, соединение таблиц размножило строки, обновление не пришло

~40%

У

Устройство

В базе данных нет правила-проверки (CHECK), нет запрета на пустые значения (NOT NULL), плохо спроектирована схема

~30%

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

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

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

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

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

Буква

Тип

Пример

Как выглядит в таблице

Н

Неполнота

Нет номера телефона

NULL (пустое значение) или пустая строка

Д

Дубликаты

Один заказ записан дважды

Две строки с одинаковым номером заказа (order_id = 123)

У

Устарелость

Цена товара не обновлена

price = 100, а сегодня цена 120

Н

Неверный формат

Дата записана как текст

'2023-13-40' (13-го месяца не бывает)

Ф

Физическая ошибка

Буква в числовом поле

amount = '1 000' (пробел внутри числа)

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

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

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

Дубликаты - «одно и то же дважды». Бьёт по карману (две отгрузки, два начисления).

Устарелость - «данные есть, но они старые». Коварная: ошибку видно не сразу.

Неверный формат - «данные есть, но их нельзя прочитать». Ломает интеграции.

Физическая ошибка - «данные есть, но они сломаны». Редко, но больно.

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

Конец ознакомительного фрагмента.

Текст предоставлен ООО «Литрес».

Прочитайте эту книгу целиком, купив полную легальную версию на Литрес.

Безопасно оплатить книгу можно банковской картой Visa, MasterCard, Maestro, со счета мобильного телефона, с платежного терминала, в салоне МТС или Связной, через PayPal, WebMoney, Яндекс.Деньги, QIWI Кошелек, бонусными картами или другим удобным Вам способом.