Качество данных в М.Видео-Эльдорадо
Привет, Хабр! С середины 2023 года у нас в компании было принято решение открыть новое направление в области управления данными — «Качество данных». Вот почти уже год мы активно в нем развиваемся и хотели бы поделиться накопленным опытом. Надеемся, что данный материал будет вам полезен.
Что такое качество данных, и платформа по управлению качеством данных?
Термин Data Quality (качество данных) относится к уровню точности, полноты, актуальности, согласованности и надежности данных. Это ключевой аспект успешного управления данными в любой организации.
Для осуществления централизованного контроля над качеством данных компании необходимо внедрить платформу DQ. Платформа по контролю качества данных (Data Quality Platform) представляет собой программное обеспечение или интегрированную систему, предназначенную для автоматизации процессов контроля, улучшения и управления качеством данных в организации. Она обеспечивает средства и функциональность для профилирования, анализа, очистки, стандартизации и мониторинга данных с целью обеспечения их высокого уровня качества.
Основные компоненты и возможности платформы по контролю качества данных включают:
Профилирование данных: автоматический анализ структуры и содержания данных для выявления потенциальных проблем и аномалий.
Очистка данных: автоматизированное исправление ошибок, удаление дубликатов, обработка недостающих значений и приведение данных к единому формату.
Стандартизация данных: приведение данных к единым стандартам и форматам, что повышает их согласованность и удобство использования.
Мониторинг качества данных: отслеживание и контроль качества данных с возможностью автоматического оповещения о возникающих проблемах.
Управление метаданными: создание и поддержка системы управления метаданными, описывающими характеристики и связи между данными.
Интеграция с другими системами: возможность интеграции с другими системами управления данными, базами данных и приложениями для обеспечения единого источника правды.
Отчетность и аналитика: генерация отчетов и аналитика по качеству данных, а также мониторинг производительности и эффективности процессов контроля качества данных.
Платформа по контролю качества данных помогает организациям обеспечить надежность, целостность и актуальность своих данных, что является важным фактором для принятия обоснованных решений и повышения эффективности бизнес-процессов.
Этапы развития инструментов по контролю качества данных в России
Развитие инструментов для обеспечения качества данных (Data Quality) в России прошло через несколько этапов, от начальных стадий осознания важности качества данных до использования современных технологий и методологий для их управления и улучшения качества. Вот основные этапы этого развития:
Начальный этап осознания проблемы: в это время компании в России только начали осознавать, что качество данных является критическим фактором для эффективного бизнеса. Однако на этом этапе инструменты и методики для управления качеством данных были еще не широко распространены. Рынок развивался стремительно и не было ресурсов/необходимости для создания единого инструмента мониторинга качества данных.
Этап разработки базовых инструментов. Начали появляться первые специализированные инструменты для управления качеством данных. Эти инструменты в основном предоставляли базовые функции, такие как проверка дубликатов, неполных данных и т.д. Однако их использование было еще довольно ограниченным и редко выходило за вендорские решения. Чаще все было децентрализовано и применялось для конкретного инструмента обособленно.
Расширение возможностей и внедрение решений. С кратным увеличением количества исходных систем-поставщиков данных и расширением внутренних хранилищ данных начали возникать вопросы о необходимости контроля над данными централизованно.
В последние годы с распространением Data Governance значительно увеличился интерес к проблеме качества данных. Внедрение интегрированных платформ для управления данными и обеспечения их качества стало более распространенным. Компании начали осознавать, что оперативный контроль данных является ключевым элементом успешной цифровой трансформации и оптимизации бизнес-процессов.
Настоящее время. С уходом иностранных вендоров компании в России столкнулись с необходимостью разработки собственных решений по контролю качества данных. Также предпосылкой к активной разработке платформ для мониторинга является внедрение Open Source технологий. С расширением инструментов сбора/трансформации/хранения данных все чаще встает вопрос о необходимости удобных инструментов контроля данных.
В целом, развитие инструментов для управления качеством данных в России отражает общие мировые тенденции, но также учитывает специфику отечественного бизнеса и законодательную базу. В будущем можно ожидать дальнейшего роста спроса на инструменты и решения, направленные на повышение качества данных и обеспечение их доверия.
О том, почему в компании возникла необходимость создания такого инструмента как DQ
Рост объема и разнообразие данных: с увеличением объема и разнообразия данных, с которыми работает компания, возникают новые вызовы в обеспечении их качества. Недостаточное качество данных может привести к ошибкам в анализе, принятии решений и повлиять на бизнес-процессы.
Увеличение зависимости от данных для принятия решений: в условиях увеличения конкурентной борьбы компании все больше опираются на данные для принятия стратегических решений. Поэтому качество данных становится ключевым фактором успеха.
Увеличение числа источников данных: с ростом числа источников данных, таких как социальные сети, датчики IoT, онлайн-платформы и т.д., возрастает сложность управления и обеспечения качества данных.
Потребности в аналитике и отчетности: компании все больше используют данные для анализа и создания отчетов. Некачественные данные могут привести к искаженным результатам анализа и неверным выводам.
Повышение эффективности и снижение издержек: использование инструмента по контролю качества данных может помочь компании оптимизировать бизнес-процессы, уменьшить ошибки и повысить эффективность использования ресурсов.
Если суммировать данные пункты, то в целом необходимость решения о внедрении платформы по контролю качества данных можно выразить в следующей последовательности:
Расширяется компания → множится количество источников данных → увеличивается количество бизнес-процессов → возрастает зависимость процесса принятия решений от поставляемых данных → возникает вопрос — «Как нам оперативно, а главное правильно определить, поставляются ли нам качественные данные?».
В целом именно это и являлось отправной точкой к созданию инструментов контроля качества данных.
Начало разработки. Описание процесса
Для начала разработки было решено рассмотреть текущий процесс AS IS и выявить в нем слабые стороны, которые может исправить внедрение инструмента по контролю качества данных.
Схема процесса управления качеством данных. Как было и, как стало
AS IS «Исправляем ошибки когда их обнаружим»
До начала разработки инструмента процесс обнаружения некорректных данных обладал следующими чертами:
· Реактивный
· Нет специальных инструментов
· Отсутствуют метрики, цели и ответственные
· Хаотичный, несистемный, незамкнутый
В целом процесс чаще всего начинался с пользователя, который обнаруживал некорректные данные уже на этапе принятия решений, либо (что еще хуже) постфактум. Далее создавался инцидент на группу поддержки данных, который затем уже отправлялся на разработчика (в случае если проблему не удавалось решить силами поддержки) или решался в течение определенного времени самой поддержкой. Сам процесс опирался на множественное взаимодействие с конечным пользователем, что увеличивало время исправления данных.
TO BE «Находим ошибки до того, как они попадут пользователю»
После внедрения единого централизованного инструмента по контролю качества данных планируется «замкнуть» процесс на инструменте DQ.
· Проактивный
· DQ инструментарий
· Определены метрики, цели и ответственные
· Упорядоченный, системный, замкнутый
Процесс будет начинаться задолго до возникновения инцидентов от пользователя с неправильными данными. Первым этапом будет добавляться правило проверки и запускаться в работу. После в рамках ежедневного мониторинга будет собираться статистика по активу и в случае отклонения на каждый из заинтересованных узлов будет отправлено оповещение, а на поддержку будет автоматически сгенерирован инцидент. Таким образом, пользователь или владелец актива будет оповещен о некорректных данных, а поддержка оперативно сможет устранить проблему.
Когда в общих чертах стало понятно, какие недостатки текущего процесса должен «закрывать» новый инструмент разработка сдвинулась на этап выбора подходящего инструмента.
Начало разработки. Выбор между вендорскими решениями и самостоятельной разработкой
При выборе из готовых решений к вниманию представлялись следующие факторы:
Продукт должен предоставлять все необходимые инструменты и функциональность для контроля качества данных (профилирование, очистка, стандартизация, мониторинг).
Возможность интеграции выбранного решения с другими системами и приложениями, которые уже используются в организации. Хорошая интеграция позволит обеспечить единство данных и процессов.
Решение должно быть гибким и масштабируемым, чтобы вместе с увеличением объема данных удовлетворять потребности в будущем.
Простота использования. Продукт должен быть интуитивно понятен пользователям, либо представлять четкие инструкции в процессе добавления новых проверок.
Доступность поддержки со стороны поставщика решения, регулярность обновлений и улучшений. Это важно для поддержания актуальности и эффективности решения в долгосрочной перспективе.
Стоимость продукта. Затраты на приобретение, внедрение и поддержку решения, не должны превышать планируемую выгоду от внедрения инструмента.
С учетом всех ключевых параметров при выборе вендорских решений был сделан вывод, что на данный момент на российском рынке нет поставщика, который предоставил бы готовое решение, удовлетворяющее всем вышеназванным пунктам.
Решено было выстраивать самостоятельно свою систему мониторинга качества данных, изначально соответствующую всем необходимым параметрам, даже если это и несет некоторые издержки, такие как необходимость формирования отдельной команды для развития и поддержки продукта и возможное увеличение сроков внедрение целевого решения из-за разработки с нуля.
Начало разработки. Выбор технологического стека и общая концепция
Для разработки собственного продукта предпочтение было сделано в пользу следующих решений с открытым кодом:
Общая архитектура нашего решения
PostgreSQL — это мощная и надежная реляционная база данных с открытым исходным кодом. В ней должна храниться все метаинформация с настройками правил проверок, логами работы системы и результатами работы проверок.
Apache Airflow — открытая платформа для управления и автоматизации рабочих процессов и потоков данных. Она обеспечивает возможность создания, планирования и мониторинга сложных рабочих процессов, поддерживает гибкую настройку и расширяемость, интеграцию с другими системами, а также предоставляет средства мониторинга и отчетности.
Данный инструмент выбран для реализации системы проверки также из-за того, что в нем есть используется Python как основной язык. Python отлично подходит для создания инструмента контроля качества данных благодаря своей простоте, богатой экосистеме библиотек для обработки данных, широкому применению в области анализа данных, кроссплатформенной поддержке и открытому исходному коду с активным сообществом разработчиков.
На старте проекта мы не предполагали делать у системы отдельного пользовательского интерфейса, и хотели использовать Excel и предоставить пользователям общую папку куда они смогут выгружать данные необходимые для создания проверок. Но эта идея быстра показала свою несостоятельность.
Очень сложно объяснить даже небольшому количеству пользователей как правильно сформировать файл, почти нереально сделать понятную систему информирования через почту о не верном формате файла. Поэтому мы решили сделать интерфейс сразу. В качестве framework«а был выбран Bootstrap.
Bootstrap — это открытый и бесплатный HTML-, CSS- и JS-фреймворк, который используют веб-разработчики для быстрой верстки адаптивных дизайнов сайтов и веб-приложений.
Он включает в себя CSS- и HTML-шаблоны оформления для веб-форм, меток, типографики, кнопок, блоков навигации и других компонентов веб-интерфейса.
Особенности Bootstrap:
· снижение количества времени на разработку;
· адаптивность и кроссбраузерность;
· лёгкость в использовании и открытость;
· понятность кода;
· единство стилей;
· шаблонность.
Используя bootstrap, мы многое делали на back. Конечно, сейчас мы понимаем, что это крайне неудобно, но для быстрого старта этого нам хватило.
С помощью python мы готовим данные, которые отправляем на html-страницу. И с помощью bootstrap мы просто представляем данные в нужном нам и красивом формате. То есть на разметку страниц мы не тратили времени вообще
Предполагалось, что основная задача интерфейса будет состоять, в том, чтобы вводить в базу данных основные мета данные. Поэтому и была выбрана, как казалось быстрая в реализации и понимании, связка python (back end) + flask + html страница с фреймворком bootstrap/js.
В процессе реализации интерфейс обрастал все новой функциональностью, что в свою очередь требует переноса на более функциональную библиотеку React.js или подобную.
Модель данных и сущностей.
Схема нашей БД DQ
Общая схема зависимости фреймворка отражена выше. Каждый блок в данном случае — отдельная таблица в базе данных, в которой хранятся определённые сведения о правиле, стрелки — различные методы по взаимодействию между ними. Основные таблицы — view и rule, в них содержится основная информация и настройки правила проверки качества данных.
При этом взаимодействие настроено так, что у одного правила может быть несколько представлений, что в свою очередь позволяет создавать один универсальный алгоритм проверки для множества объектов.
Что было реализовано в рамках нашего MVP?
На данный момент реализован фреймворк для контроля качества данных (DQ) по модели выше, который включает в себя следующие основные компоненты:
1. Базовые проверки DQ: фреймворк включает в себя набор базовых проверок качества данных, таких как проверка на полноту, уникальность, своевременность поступления данных и другие типичные аномалии. Отдельно стоит выделить созданные проверки так называемых «малых справочников». Данный вид проверки оповещает пользователей о каких-либо изменениях в выбранной таблице.
Это особенно актуально для небольших таблиц — справочников, на которых может быть завязана логика в витринах и отчетах. Также было решено реализовать отдельный механизм для правил с пользовательской логикой. При необходимости пользователь может сам задать SQL код для определенной базы и автоматизировать его выполнение в виде проверки. Уже введенные проверки помогают выявить основные проблемы с данными и обеспечить их целостность и актуальность.
Интерфейс заведения проверки данных по полноте
1. Механизм рассылок в мессенджеры и почту: фреймворк включает в себя механизм рассылки уведомлений о результатах проверок в мессенджеры (например, Telegram, Mattermost) и почтовые ящики. Это позволяет оперативно информировать заинтересованных пользователей о возможных проблемах с данными и принимать необходимые меры.
2. Механизм создания автоматических заявок для поддержки: фреймворк поддерживает автоматическое создание заявок для групп поддержки (в приложении Assyst). Это позволяет оперативно реагировать на возникающие проблемы и обеспечивать их быстрое устранение.
3. Пользовательский интерфейс: был разработан пользовательский интерфейс для взаимодействия с фреймворком, который позволяет управлять настройками и параметрами существующих проверок, а также заводить новые и просматривать результаты запусков проверок.
Отображение результатов проверок DQ в инструменте
Также стоит упомянуть про адаптивность инструмента при интеграции с новыми системами как для составления проверки, так и для визуализации данных. Примером такого сценария является легкая интеграция с BI-системами.
В рамках реализации модели был разработан механизм, позволяющий автоматически генерировать отчеты, демонстрирующие результаты выполнения проверки, используя SAP BusinessObjects RESTful Web Service SDK для SAP BO Web Intelligence. С помощью настроек в интерфейсе пользователь может получить готовый отчет с условным форматированием, содержащий информацию о результатах проверки.
Пример отчета в SAP BO автоматически сгенерированного DQ-инструментом
Фреймворк ведет себя достаточно гибко при добавлении новых SQL систем. При достаточном описании проверки разработчику необходимо только указать данные для подключения к новой системе. Остальное пользователь может добавить сам.
На данном этапе можно сказать, что инструмент покрывает большинство необходимых пользователю стандартных проверок для отслеживания качества данных. Но с ростом заинтересованности бизнеса в инструменте этот список будет только расширяться и одной из будущих целей в команде стоит увеличение гибкости инструмента для заведения дальнейших проверок.
Промежуточные успехи
На данный момент система все еще находится в состоянии разработки, но можно сказать, что уже есть видимая польза от внедрения данного инструмента. Из очевидных плюсов:
Выстроили процесс DQ. При создании и изменении Дата-активов заказчику предлагается создать проверки DQ.
Выявили некорректные процессы загрузки данных. Из интересного, некоторые давно созданные процессы были реализованы некорректно, т.е. пользователи всегда работали с частично неправильными данными. Внедрение проверок качества данных позволило вскрыть такие проблемы и оперативно их исправить.
Автоматизировали некоторые процессы, выполняемые ранее пользователями вручную. Яркий пример — поиск ошибок в заполнении габаритов товара в карточке материала. Процесс заполнения данной карточки осуществляется частично вручную, что несет за собой пользовательские ошибки. Контроль для отчетности также ранее осуществлялся либо вручную, либо методом исключения товаров с некорректными габаритами при принятии решений.
На основе габаритов товара определялся критичный процесс — оценка заполняемости транспортного средства, что при некорректных данных могло понести за собой большие финансовые издержки.
После внедрения проверки процесс выявления некорректных товаров стал автоматическим — пользователь больше не принимает в мониторинге участие, вместо него система в автономном режиме отлавливает некорректные данные и отправляет инцидент на группу поддержки со списком некорректных материалов для исправления.
Сократили стоимость. Стандартные проверки может создавать даже бизнес.
Снижено время вывода новых проверок в работу. Разработчики не тратят время на всю оснастку (сбор требований, заведение проверки, настройка оповещении и т.п.).
Знаем уровень качества данных. По шесть доменам мы выделили критичные элементы данных и измеряем уровень качества данных в них. Уровень качества доступен всем (пока только во внутреннем интерфейсе DQ).
Что планируется реализовать
Дальнейшее развитие фреймворка частично зависит от потребностей пользователей, но уже сейчас можно выделить следующие доработки, которые уже планируются к введению:
Внедрение новых типов проверок. Одна из них — проверка исторических данных на изменение. Данная проверка — одна из просьб от бизнес-пользователей и один из кейсов, когда до внедрения проверки пользователи сверяли данные вручную. Посыл правила — проверять, как изменяются исторические данные (старше 6 месяцев — 1 года). Скачкообразное изменение исторических данных негативно влияет на процесс планирования, что опять же может привести к некорректному принятию решений. В данном случае разрабатываемый инструмент DQ идеально подходит для автоматизации данной проверки
Создание механизма многоуровневых проверок. Для оптимизации поиска некорректных данных вплоть до строки во множестве случаев нам не обязательно построчно сверять объект с исходной системой, достаточно понимать, что данные расходятся в определенном разрезе. Но как в таком случае более детально указать поддержке, в каких именно записях возникла проблема? Для таких случаев планируется ввести механизм многоуровневых проверок.
Данная проверка будет функционировать следующим образом: вначале проверка верхнего уровня в определенном разрезе (например магазин, день) проверяет показатели (например оборот, количество записей в разрезе и т.д.) на определенный уровень отклонений, задаваемых пользователем.
После этого, в случае обнаружения критичного уровня отклонений система запускает детальную проверку, но не для всего объема данных, а для конкретных найденных разрезов, что ускоряет время работы проверки, если речь идет о большом количестве данных. В нашем случае предпосылкой к созданию такого формата правила послужила необходимость сверки транзакционных данных между системами. Таблицы, хранящие такие данные обычно содержат большое количество записей, и сверка всех записей между системами могла занять большое количество как времени, так и ресурсов.
Автоматическое исправление данных при ошибках загрузки. Планируется доработать инструмент так, что в случае обнаружения расхождений между системами автоматически перезапускалась необходимая загрузка. В случае, если после загрузки расхождения не исчезнут, то отправлять инцидент в поддержку для более детального анализа причины ошибки и исправления.
Так мы начали свой путь в мир Data Quality. Пока полет нормальный. А какой опыт у вас?
P.S. Данная статья была подготовлена совместно с нашими коллегами из компании Сапиенс Солюшенс, которые очень помогли нам при запуске этого нового для нас направления. Отдельно хочется поблагодарить Матвея Рассохина, выполнявшего роль старшего аналитика в проекте и также отвечавшего за подготовку данного материала.
