Привет, Хабр! Меня зовут Яна и я работаю Data Quality в департаменте развития аналитики "Цепочки поставок и поддерживающие функции" X5 Tech. В этой статье мы с моей коллегой Наташей, менеджером по качеству данных, решили рассказать о мониторинге качества данных большинства отчётов нашей команды.

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

На сегодняшний день многие компании уже осознали важность качества данных и внедрили систему их мониторинга. Продуктовый ритейл – не исключение. Кстати, мы описывали в общих чертах, как у нас в компании устроено DQ, в этой статье. 

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

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

Ближе к делу – чем занимается наша команда

Команда направления аналитики "Цепочки поставок" отвечает за сбор данных, аналитику, разработку и визуализацию отчётности для бизнес-заказчиков. Особенность крупного продуктового ритейла заключается в огромном объёме разнообразных данных, которые генерируются большим количеством различных систем. 

Например, есть структурированная разноуровневая информация о продажах и малоструктурированные данные с отзывами покупателей. Таким образом, в результате разработки финальной витрины из нескольких систем, могут появиться аномальные данные. Поэтому важно подключать специалиста DQ –  регулярный мониторинг отчёта показывает качество данных в нужных разрезах до того, как он будет использоваться бизнес-заказчиком. 

Что и как мы проверяем на примере проекта Service Level

Немного о проекте: Service Level был одной из самых масштабных задач для нашей команды в текущем сезоне – эта отчётность показывает уровень сервиса на данных о заказах и поставках. SL обладает высоким приоритетом для компании и имеет сотни пользователей. 

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

Проверка актуальности может выявить проблемы позднего старта обновления данных, отсутствие доступа к свежим данным или некорректную синхронизацию данных из разных систем-источников. Проверка полноты покажет, насколько объём конечного объекта соответствует ожидаемому и поможет выявить отсутствие критических данных из какого-либо источника. Дубли укажут на двойную загрузку или проблему синхронизации данных. Базовые проверки нужны всегда! Они способствуют быстрому отслеживанию стандартных проблем и оперативному реагированию на них.

Для Service Level мы не только настроили базовые проверки, но ещё на этапе тестирования реализовали мониторинг логов объектов-источников. Что это дало? Во-первых, ежедневное отслеживание времени готовности показывает полную картину того, насколько рано мы можем предоставить пользователям отчёт. Во-вторых, учитывая критичность проекта, была необходима аналитика стабильности источников.  

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

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

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

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

Наконец, наступил черёд мониторинга финальной витрины проекта – а именно, реализации логических проверок. С помощью такого мониторинга можно увидеть не только технические, но и смысловые аномалии. Логические проверки прорабатываются с использованием экспертизы бизнес-заказчика, менеджера по качеству данных и аналитика. Тем самым мы вовлекаем в процесс мониторинга ключевые заинтересованные стороны и обеспечиваем комплексный взгляд на качество данных. Задача DQ-специалиста на этом этапе – превратить знания коллег, работающих с конкретными показателями, в правила для проверок.

Кроме общего мониторинга, важно отслеживать время готовности объекта – отчёт должен строго попадать в SLA, обеспечивая оперативными данными пользователей всех регионов. Добившись ожидаемого времени готовности таблиц, мы перешли к оптимизации разработки, и только за последние несколько месяцев конечный объект стал собираться быстрее на 3 часа!

Но и на этом проверки не завершились. Так как данные очень востребованы для различных корпоративных задач, объекты нужны не только в GreenPlum, где осуществляется основная часть разработки, но также в ClickHouse и Hive. Было решено сделать ежедневную базовую сверку объёма таблиц – она показывает корректность перемещения данных между системами.

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

Так, настроив все описанные проверки, мы смогли отловить несколько критичных проблем, ускорить время готовности витрин, а также в целом улучшить данные отчёта – это помогло сделать проект ещё более востребованным и качественным.

Что ещё нужно учитывать при мониторинге качества данных?

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

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

Также зафиксированный материал упрощает процесс сопровождения текущих проверок и разработки будущих. Некоторые решения можно переиспользовать или оперативно адаптировать под новый проект. 

Подытожим

Мониторинг качества данных является неотъемлемой частью эффективной работы любой компании. Здорово, когда есть специалисты DQ для реализации всех необходимых проверок, но это необязательное условие. Исследуйте свои данные, задавайтесь вопросами об их смысле, подключайте коллег к анализу и настраивайте мониторинг с помощью любых аналитических инструментов, используемых в вашей компании. 

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

Качественные данные = качественные отчёты = успешное развитие!