Данные со встроенным качеством

В рамках управления данными компании уделяют все больше внимания показателю их качества (Data Quality, DQ), который становится неотъемлемым атрибутом данных. Набирающий популярность подход Data Quality by Design предлагает встраивать процедуры и инструменты качества данных в бизнес-процессы организации еще на этапе проектирования ее процессов сбора и обработки данных. Какого рода инструменты DQ и как нужно встраивать в бизнес-процессы, чтобы получить ощутимую пользу для бизнеса? И как в общих чертах должна выглядеть практическая реализация мониторинга качества данных? На эти вопросы мы попросили ответить экспертов, планирующих участвовать в конференции «Качество данных — 2026».

Контроль — от источников до дашбордов

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

«В целом у нас в стране пока достаточно низкая культура DQ, многие только начинают осознавать эту проблематику. В этом случае начинать нужно максимально прагматично, иначе затраты могут превысить стоимость самих данных и затрат на их подготовку», — подчеркивает Дмитрий Дорофеев, главный конструктор платформы Luxms BI. Первым делом стоит обратить внимание на инструменты для базовых замеров — проверки на полноту, соответствие формату, допустимые диапазоны. Именно первые введенные проверки часто дают наилучшее соотношение затрат и пользы, и часто эти возможности уже есть в используемых ETL-инструментах. Кроме того, обязательно нужна визуальная часть — дашборд качества данных. Без нее любые проверки превращаются в набор технических логов, которые никто не читает, поэтому разумный подход — дать пользователям удобное и понятное представление результатов.

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

Кирилл Евдокимов, директор по продуктам Data Ocean Governance EMM и DQ компании Data Sapience, разделяет инструменты DQ на три «линии защиты». Первая из них — валидация на входе, и задача этих решений — предотвратить создание проблемных данных. В большинстве случаев она реализуется непосредственно в системах с интерфейсами ввода, однако важно понимать, что не всегда возможно и экономически эффективно проверять именно в этой точке. Бизнес-ценность этой линии заключается в сокращении операционных затрат на исправление ошибок.

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

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

Павел Толчеев: «Инструменты DQ нужно встраивать точечно — в те процессы, где ошибка обходится дороже всего»

Павел Толчеев, директор по технологиям и данным российской платформы B2B- и B2G-торговли В2В-РТС, рекомендует встраивать инструменты контроля качества точечно — в те процессы, где ошибка обходится дороже всего.

И поясняет: «Есть несколько ключевых категорий инструментов, каждая из них должна занимать свое место в архитектуре и бизнес-процессах. Первая категория — инструменты профилирования и обнаружения: они автоматически анализируют структуру, содержание и качество данных, выявляют аномалии и нетипичные значения. Их имеет смысл встраивать на входе новых источников данных и в процессы инвентаризации, чтобы снизить риск построения отчетности и аналитики на некачественной основе и сэкономить время аналитиков. Вторая категория — инструменты валидации и проверки правил: они проверяют данные на соответствие формату, диапазонам, связям между полями и бизнес-требованиям. Их стоит встраивать в точки ввода данных, процессы загрузки и преобразования, а также в критические бизнес-функции, например, финансового закрытия периода. Эффект здесь мгновенный — потери предотвращаются на самом раннем этапе, ошибки не распространяются далее. Третья категория — инструменты очистки и стандартизации, автоматически исправляющие типовые ошибки и приводящие данные к единому формату. Их место — обработка входящих потоков, процессы управления НСИ и бизнес-системы (CRM, ERP и пр.). Сюда же относятся сервисы нормализации справочников. Благодаря этим инструментам повышается качество клиентской аналитики, точность моделей, уменьшаются затраты на хранение и обработку записей. Четвертая категория — инструменты мониторинга качества данных и оповещения об отклонениях. Их важно встраивать на выходе критических отчетов, в систему управления инцидентами и интегрировать с привычными каналами коммуникации сотрудников. Главная их ценность в том, что проблемы фиксируются раньше, чем о них узнают бизнес-пользователи или клиенты. Наконец, пятая категория — каталоги данных и витрины с рейтингами доверия: каждому набору данных присваивается оценка на основе показателей качества и полноты описания. Такие инструменты особенно важны для принятия качественных решений и при разработке новых продуктовых и аналитических сервисов: пользователь сразу видит, насколько можно доверять конкретным данным и кто за них отвечает.

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

Георгий Нанеишвили: «Если бы в компаниях была развита культура работы с данными, то проблем с некорректными отчетами можно было бы избежать»

«К сожалению, качество данных становится видно лишь тогда, когда их “извлекают на свет” — строят дашборды для принятия решений. Тут-то и всплывает очень неприглядная картина: справочники “разъехались”, продано отрицательное количество товара, не целое число устройств и т.п. Если бы в компаниях была развита культура работы с данными, подобных проблем можно было избежать», — считает Георгий Нанеишвили, руководитель отдела по работе с клиентами и развитию бизнеса компании DATAREON. Дело не в конкретных инструментах, а в необходимости в целом повышать уровень культуры работы с данными: выстраивать центры компетенции, вести бизнес-глоссарий терминов и KPI. На основании бизнес-глоссария уже выстраиваются каталоги данных, которые затем дополняются требованиями к данным: точности, полноте, непротиворечивости, согласованности, достоверности, уникальности и актуальности. Сформировав эти требования, можно внедрять их внутрь процессов — на уровень проверки введенных, хранимых или передаваемых между системами данных, хотя есть и отдельные коробочные инструменты с преднастроенными проверками.

«Эффективное внедрение DQ требует инструментов с открытыми API, поддержкой профилирования, валидации, мониторинга и автоматической очистки данных», — уверена Светлана Кузнецова, руководитель направления бизнес-автоматизации в компании SimbirSoft. Среди проверенных решений — инструменты для декларативного определения и валидации ожиданий к данным, инструменты для измерения и мониторинга качества данных в реальном времени, инструменты для профилирования, сопоставления и стандартизации, инструменты для автоматического обнаружения инцидентов качества. Их целесообразно встраивать непосредственно в этапы сбора, трансформации и потребления данных — от источников до дашбордов.

Мария Русина: «Стратегия загрузки данных в зависимости от их метрик качества позволит минимизировать бизнес-риски там, где наличие некорректных данных критичнее их отсутствия»

Мария Русина, руководитель центра компетенций Data Governance & Data Quality «ДАР» (ГК «Корус Консалтинг»), рекомендует применять инструменты мониторинга качества данных как можно ближе к точке возникновения данных. Такой подход обеспечивает выявление ошибок в данных на ранних этапах и сокращает время и трудоемкость анализа причины возникновения ошибки. Кроме того, это позволяет применить различные стратегии к использованию данных — например, блокировку дальнейшей загрузки при превышении порогового значения допустимых ошибок или запрет на загрузку только записей с критичными ошибками. Использование стратегии загрузки данных в зависимости от их метрик качества позволит минимизировать бизнес-риски в случаях, где некорректные данные критичнее их отсутствия. При этом важно учитывать текущий архитектурный ландшафт: например, применение средств мониторинга качества данных на транзакционных базах данных может привести к нарушению требований скорости и доступности транзакций.

«Инструменты должны быть встроены в те части системы, где данные создаются, трансформируются и используются. При этом важно понимать, что проверка на каждом уровне имеют свою специфику», — согласна с коллегами Екатерина Каннуникова, директор по продуктам направления дата-сервисов VK Tech. На уровне источников данных используются такие инструменты контроля, как валидация ввода, корректность справочников, референсные данные. В потоках обработки (ETL/ELT) применяются тесты на пустые значения и дубли, проверки SLA загрузки, мониторинг объемов. На уровне слоев хранения (ODS/DDS/DM) в хранилище — применяются бизнес-правила качества, контроль согласованности слоев, метрики качества данных.

Герман Ганус: «Инструменты DQ нужно встраивать туда, где данные создаются и используются, чтобы обеспечить качество “у истоков”»

Герман Ганус, руководитель направления внешних проектов разметки данных в Yandex Crowd Solutions, также является сторонником обеспечения качества данных «у истоков», встраивая инструменты DQ непосредственно в те этапы и процессы, где данные создаются и используются. Например, для ML-продуктов основным инструментом являются платформы разметки данных и участники процесса. Рекомендуется повышать экспертизу использования платформ разметки и их штатных методов DQ, а также создавать процессы разметки по принципу HITL (Human-in-the-Loop), где LLM и модели автоматизируют рутину, а эксперты-разметчики контролируют качество. Это повышает и экономическую эффективность, и итоговое качество данных для моделей.

Для BI и аналитики, в свою очередь, фундаментом является качественный сбор и продуманная архитектура хранения (хранилища, озера данных и Lakehouse). Без этого поддерживать качество на последующих этапах сложно. Поэтому ключевыми принципами должны стать открытость данных (использование сотрудниками из разных отделов, выявляет ошибки и создает синергию), а также прозрачность и документация — каждый этап обработки данных должен быть документирован. Например, данные, созданные с помощью LLM, должны быть промаркированы, чтобы пользователь понимал потенциальную недостоверность. Такой подход минимизирует риски, основанные на «сырых» данных, и повышает ценность данных для создания продуктов и принятия решений.

Мониторинг на практике

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

Кирилл Евдокимов: «Для управления инцидентами DQ можно использовать, например, ITSM-решения»

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

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

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

«Архитектурно это очень похоже на систему мониторинга ИТ-инфраструктуры: есть точки замера, хранилище результатов, дашборды и система оповещений, а также люди, которые на все это реагируют», — говорит Дорофеев. Но одной технологии недостаточно: важно, чтобы вместе с ней появилась и простая методология — какие именно проверки нужны, какие пороги допустимы, что считается инцидентом, кто за него отвечает. Существуют десятки и сотни возможных метрик качества, но здесь важно не увлечься. На практике для начала достаточно четырех-пяти базовых метрик, которые закрывают 80% критичных проблем. Начинать можно и с двух; главное — начать, и чтобы проверка работала постоянно, а результаты были понятны и приводили к действиям, а не ограничивались отчетами.

Игорь Моисеев: «Архитектура строится на единой платформе с системой метаданных, где результаты проверок собираются в универсальную витрину»

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

Светлана Кузнецова: «Инциденты DQ должны обрабатываться в рамках единой системы Data Governance»

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

Екатерина Каннуникова: «Важно понимать, что проверка на каждом уровне имеют свою специфику»

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

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

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