Традиционные системы контроля качества данных требуют больших усилий при контроле систем-источников. В Газпромбанке вместо контроля на источниках создали сервис валидации DQFirewall – своеобразный контрольно-пропускной пункт, куда подключаются системы со своим дата-сетом, проверяемым в синхронном режиме. О преимуществах, которые дает такой подход, рассказывает Екатерина Мельникова, начальник Центра технологий управления данными Газпромбанка. Более подробно узнать об этом проекте можно на конференции «Качество данных 2024», которая состоится 14 февраля.

- Какую бизнес-проблему решали, создавая сервис DQFirewall?

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

- Почему это важно для Газпромбанка?

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

- Как пытались решить задачу контроля качества данных ранее? Где были проблемы, что не получалось?

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

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

- В чем суть выбранного альтернативного подхода?

Если гора не идет к Магомету… значит, будем делать сами. У нас уже была отличная библиотека пост-контролей, мы ее поддерживаем и развиваем на постоянной основе. Мы решили попробовать сделать из этого сервис. Суть в следующем: все контроли и правила хранятся в нашей системе, фронт-офисной системе не надо об этом заботиться. Ей достаточно прислать вектор данных (например, новую клиентскую карточку) в нашу систему по API и обработать ответ, в котором детально расписано про каждый атрибут, соответствует он требованиям по качеству или нет.

- Чем такой подход проще?

Не хочу сказать, что этот подход проще. Он – другой. Но его плюсы очевидны: системе не нужно заботиться о том, чтобы реализовывать и актуализировать контроли на своей стороне. Есть и обратная сторона медали: это интеграция, вместо решения внутри системы, со всеми вытекающими последствиями. Главным преимуществом решения является кратное сокращение трудозатрат на внедрение контролей качества данных. Теперь они создаются и администрируются централизованно командой CDO, а на стороне команд развития автоматизированных систем остается только разработка и поддержка интеграции с API.

- Какие технологии применялись?

Еще на заре существования нашего подразделения мы твердо решили выбрать путь open source. С тех пор ничего в этой части не поменялось. Мы используем стек ПО с открытым исходным кодом там, где можно использовать готовые решения (Airflow, Grafana, Kafka и т.п.), а то, чего не хватает, мы разрабатываем внутренней командой сами.

- Какие сложности возникали в ходе проекта, как их решали?

Когда делаешь что-то совершенно новое, все вокруг становится сложным. Пожалуй, можно выделить подход к работе с пост-контролями. Действительно, у нас была отличная библиотека контролей, но в ней был существенный нюанс: каждый контроль однозначно относился к какой-то системе или витрине, без возможности его применения в других системах. А описательная часть, которая тиражируема, относится ко всем соответствующим сущностям или атрибутам – это просто табличка в Excel. Это совсем не то, что нужно для проверки данных, полученных по API в синхронном режиме. Была нужна генерация из абстрактных описаний в конкретную реализацию под соответствующую систему или витрину. Без каталога данных эта задача в целом не решаема. Но у нас как раз параллельно шел процесс внедрения каталога данных, так что мы смогли сделать эту генерацию. Пожалуй, это самое масштабное изменение. Теперь пост-контроль достаточно завести в библиотеке на абстрактном уровне, описать источник в метаданных (естественно, еще должно быть настроено подключение, получены сетевые проходы и т.п.), отдельно делать проверки уже не надо – они сгенерируются автоматически. Таким образом, тиражирование однотипных пост-контролей перестает быть проблемой, а становится штатным автоматизированным процессом.

- Каковы результаты, чего удалось добиться? И какими метриками это измеряется?

Уже сейчас можно однозначно утверждать, что изменение простого контроля требует примерно пять минут времени, вместо согласований бэклогов и участия в процессе доработок. Также многократно сократилось время на изменения пост-контролей – так как достаточно исправить в одном месте, а не для каждой системы по отдельности. Это же убрало риск рассинхронизации версии контролей в разных областях контроля. Так что, классический уже показатель time-to-market – самая подходящая для оценки метрика. Остальные эффекты, конечно, будем оценивать на длительном горизонте, которого у нас пока просто не было.

- Участвуя в Data Award 2023, Алексей Бондаренко рассказывал о проекте self-service Data Quality. Как связаны эти два проекта?

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

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

Я думаю, тут дело в том, что для реализации подобного проекта необходимо, чтобы в организации одновременно выполнялись несколько условий. Во-первых, наличие единого централизованного Офиса CDO, который обеспечит формирование и администрирование единой для всей организации библиотеки контролей. Во-вторых, зрелые процессы управления качеством данных, которые пригодны для алгоритмизации. Кроме того, необходима сильная команда разработки, способная создать подобное решение. Но самое главное – это стремление организации на всех уровнях (и, в первую очередь, на самом высоком) стать по-настоящему data-driven, и готовность высшего руководства инвестировать ресурсы и время в развитие системы управления данными.

- В каком направлении будет развиваться проект?

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