Обеспечение качества данных — это сегодня не вопрос технологий, а прямой вопрос минимизации операционных рисков, угрожающих бизнесу. Ошибки в стратегических отчетах и дашбордах, противоречивые показатели и просроченные выгрузки — основные причины, почему не работают дата-продукты. Им просто перестают верить, хотя 85% руководителей понимают, что данные — основа успеха бизнеса, но при этом около 40% данных непригодны к использованию. В итоге бизнес теряет 25–35% прибыли по всем бизнес-целям. Корень проблем — отсутствие системного подхода к управлению данными, которые искажаются на всех этапах их жизненного цикла: несогласованные изменения в схемах, размытая ответственность за показатели, конфликт методологий, когда одна и та же метрика считается по-разному.

Как выстроить процессы так, чтобы разработка не расходилась с управлением данными, и чем это поможет в борьбе за их качество?

Почему не работают традиционные подходы?

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

Чаще всего компании сталкиваются с тремя проблемами.

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

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

ИТ-команды и бизнес-подразделения не взаимодействуют в рамках единого стандарта качества данных. Часто в компаниях не зафиксированы базовые договоренности: что означает та или иная метрика, кто за нее отвечает, как согласовывать изменения в схемах и пр. В итоге зона ответственности размыта. Если что-то идет не так, пользователи не знают, к кому идти, — тогда проблема зависает, а доверие к данным падает.

Как повысить качество дата-продукта

За последние десять лет сложилось два подхода к развитию дата-платформ. Первый — автоматизация процессов разработки дата-продуктов (CI/CD, фреймворки кодогенерации). Второй — развитие процессов и инструментов управления данными (бизнес-глоссарий и дата-каталог). Однако по отдельности эти подходы не работают. Автоматизация без управления дает скорость, но создает хаос в метриках, а управление без автоматизации наводит порядок в данных, но тормозит разработку. Однако можно совместить оба подхода.

DataOps переносит практики DevOps в область данных, но если DevOps акцентируется на скорости поставки кода, то DataOps на качестве данных на всех этапах их жизненного цикла. Обе методологии базируются на автоматизации разработки, тестирования и проверки качества данных.

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

Типичная картина — финансовый директор замечает, что в новой витрине выручка за прошлый квартал отличается от отчета в ERP на 12%. Оказывается, разработчик проверял код на тестовых строках, а в реальных данных были аномалии. Формально разработчик все сделал правильно, однако бизнес будет пользоваться не кодом, а данными.

В подходе DataOps каждое изменение кода инициирует цепочку автоматических тестов: проверка синтаксиса и зависимостей, юнит-тесты разработчика, чек соответствия дата-контрактам. Если хотя бы один тест не выполнен, код бизнесу не попадет. Ошибки при разработке выявляются превентивно, а не постфактум в течение нескольких дней.

В стек технологий DataOps входит несколько ключевых компонентов:

  • библиотека трансформации данных (например, dbt) обеспечивает кодогенерацию для трансформации данных между слоями хранилища, построение связей между объектами и использование макросов для автоматизации;
  • Apache Airflow используется для оркестрации процессов: контроля зависимостей между моделями, запуска расчетов по расписанию или событию, мониторинга выполнения задач;
  • GitLab выступает единой точкой разработки: хранение кода, сборка образов, проведение тестов, развертывание на среды.

Внедрение DataOps снижает количество ошибок, сокращает время вывода на рынок новых дата-продуктов и повышает доверие бизнеса к данным. У разработчиков освобождаются ресурсы для решения бизнес-задач вместо ручного исправления ошибок — экономия ресурсов может достигать 45%. Мало того, установка и настройка компонентов дата-продукта требуют лишь один человеко-день вместо 10 на каждую инициативу; загрузка данных и формирование детального слоя — один человеко-день вместо 10; формирование витрин данных — 100 человеко-дней вместо 140; приемосдаточные испытания и отладка — один человеко-день вместо 30. При этом с ростом количества инициатив и внедрения новых компонентов в дата-продукт эффект усиливается.

Data Governance: бизнес-глоссарий — основа взаимодействия

Единая методология и процессы работы с данными фиксируются в бизнес-глоссарии — структурированном хранилище терминов и процессов согласования метрик и объектов глоссария. Глоссарий работает в связке с дата-каталогом, в котором регистрируются все данные организации: источники, витрины, отчеты, ML-модели. Каждый объект связывается с бизнес-терминами глоссария, что позволяет сформировать полную картину от бизнес-определения до технической реализации. Пользователь может начать с термина, увидеть реализующие его показатели, используемые источники данных, выполняемые преобразования. Например, руководитель отслеживает количество активных клиентов за месяц и в каталоге данных видит определение термина; связанные метрики (Retention Rate, LTV и Churn Rate); ответственного за показатель; источники (таблица заказов в CRM и данные о транзакциях из 1С) и итоговые показатели (количество активных клиентов на определенную дату и их доля в общей базе).

Бизнес-глоссарий фиксирует договоренности о межкомандном взаимодействии — согласованную методику расчета показателя уже не получится произвольно изменить, а только через регламентированный процесс: предложение, обсуждение с заинтересованными сторонами, утверждение и внесение изменений.

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

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

Максимальный эффект достигается, когда DataOps и Data Governance работают как единая система (см. рис.). Связующим элементом между ними становятся дата-контракты.

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

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

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

Введение, согласование договоренностей, их закрепление в дата-контрактах происходят в дата-каталоге. А связь дата-контракта с CI/CD-процессами обеспечивается за счет его выгрузки в машиночитаемый формат — open data-contract specification.

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

Структура дата-контракта включает cхему данных, определяющую перечень полей, их типы и ограничения; правила поставки и SLA, устанавливающие периодичность обновления, допустимые задержки и критерии сбоя поставки; контроль качества поставки, описывающий автоматические проверки, допустимые значения полей и бизнес-правила; согласующие и информируемые команды, определяющие ответственных лиц и порядок уведомлений.

Процесс работы с дата-контрактом выглядит следующим образом. Поставщик данных формирует условия поставки (описание структуры, методики расчета, правила контроля качества). Потребитель согласует условия с возможностью внесения замечаний. Затем контракт фиксируется в виде YAML-файла и интегрируется в процессы разработки.

При каждом изменении кода выполняется автоматическая проверка соответствия дата-контракту. Изменение типа поля или удаление обязательного атрибута прерывает CI/CD-процесс с ошибкой. Несоответствие данных заявленной схеме блокирует загрузку. Система исключает непреднамеренное нарушение работы промышленной системы.

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

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

***

Применение Data Governance и DataOps позволяет компаниям быстрее запускать дата-продукты и минимизировать время на разборы расхождений в отчетах. Данные становятся проверяемыми и доверенными, перестав быть предметом обсуждения, а бизнес может теперь опираться на них при принятии решений.

Павел Егоров (pv.egorov@jet.su) — руководитель направления Big Data, компания «Инфосистемы Джет» (Москва). Статья подготовлена на основе материалов выступления на Форуме «Управление данными 2025».