В Газпромбанке запущена система мониторинга качества данных, созданная на инструментах open source. Выбор подхода «сделай сам» обеспечил независимость от поставщика и полное соответствие продукта потребностям банка. Более того, удачный опыт импортозамещения в этом и ряде других проектов стал поводом для формирования отдельной программы, в рамках которой планируется замещение всех критически важных элементов ландшафта. О реализации проекта рассказал Алексей Бондаренко, начальник службы управления корпоративными данными Газпромбанка и номинант на премию Data Award 2023.
- Каковы основные этапы становления в Газпромбанке функции управления данными?
Функция управления данными активно начала развиваться с начала 2020 года. Важнейшей задачей на первом этапе стало определение целей, организационной структуры и основных подходов к управлению данными. Для нашей команды создание системы управления данными стало greenfield проектом: необходимо было «с нуля» создавать организационную структуру Офиса CDO, нормативную базу, процессы, нанимать и обучать персонал, определять цели и приоритетные направления работ совместно с бизнесом и ИТ. В течение первого полугодия мы полностью сформировали комплекс базовых процессов, регламентов и ролевую модель для реализации федеративной системы управления данными, а также собрали костяк Офиса CDO. Очень важным фактором успеха стало вовлечение высшего руководства банка в нашу работу: нам удалось не только привлечь внимание к проблемам управления данными, но и сформировать комитет по управлению данными, в который вошло несколько зампредов «Газпромбанка». Благодаря этому мы смогли обеспечить четкое целеполагание, оперативную обратную связь и вовлечь в работы по управлению данными широкий круг заинтересованных подразделений.
- Когда и почему потребовалась перестройка созданного ландшафта?
Следующим вызовом стало отсутствие необходимого для выполнения задач инструментария. Не умаляя важность таких артефактов, как глоссарий данных или корпоративная модель данных, все же должен заметить, что наиболее критически важным аспектом является работа по обеспечению пользователей качественными данными. Для реализации этой задачи ключевыми направлениями работ у нас стали управление качеством данных, управление метаданными и управление НСИ. И если в части управления метаданными и НСИ у нас уже были продукты от IBM и ЛАНИТ, пригодные к использованию, то в части управления качеством данных у нас не было ничего.
- Почему выбран именно подход «сделай сам» и стек решений open source?
Мы оказались перед сложным выбором. Вся практика рынка очевидно толкала нас на наиболее простой и понятный путь – приобретение готового решения Informatica, Oracle или IBM. Плюсы такого выбора очевидны: не нужно тратить силы на проведение исследовательской работы, вероятность провала стремится к нулю, а решения действительно хорошо зарекомендовали себя на рынке.
Однако есть, пусть и не столь очевидные, но весомые минусы: постоянные расходы на лицензии и поддержку, зависимость от поставщика, необходимость подстраивать процессы под продукт. В середине 2020 года никто, конечно, не ожидал реализации такого жесткого санкционного сценария в 2022 году, но все же было понимание того, что усугублять свою технологическую зависимость от западных поставщиков нецелесообразно. Поэтому мы приняли рискованное, но, как показала практика, абсолютно верное решение – разрабатывать продукт для управления качеством данных самостоятельно. Честно скажу, не все сразу поверили в успех этого предприятия, поэтому пилотный проект пришлось реализовывать в условиях жестких финансовых и ресурсных ограничений.
Тем не менее, мы справились. За полгода был реализован пилот в периметре одной из бизнес-линий – система мониторинга качества данных, обрабатываемых в Hadoop. Нам удалось создать весь необходимый базовый функционал продукта, продемонстрировать руководству его работу. Так наш проект получил «зеленый свет».
- Какими силами проводились работы, сколько времени они заняли?
После успешного завершения пилота было принято решение о запуске проекта по созданию АС МКАД (Мониторинг качества данных), который был начат в мае 2021 года. В проекте участвовали пять человек со стороны Офиса CDO и столько же со стороны нашего подрядчика, а также частично наши коллеги из ИТ и ИБ. Общая продолжительность проекта, включая формирование команды, оформление всех необходимых документов, разработку, тестирование и ввод в промышленную эксплуатацию продукта, составила 18 месяцев.
- Что было сделано в рамках проекта по управлению качеством данных?
В ходе проекта нами была внедрена система мониторинга качества всех основных данных банка: клиентов, сделок, счетов, проводок и так далее. В грубом приближении можно выделить три категории таких проверок.
Во-первых, это форматно-логические контроли, которые проверяют корректность заполнения отдельных атрибутов, либо группы связанных атрибутов, по их наличию, актуальности, типу данных, формату заполнения, соответствию принципам разумности и т.п. Такие проверки позволяют выявить ошибки в данных, обусловленные различными факторами (например, ошибками ввода или автоматизированной обработки данных) и оперативно на них отреагировать.
Во-вторых, это статистические проверки, которые отслеживают отклонение от доверительных интервалов количественных показателей качества данных – количество открытых или закрытых счетов за анализируемый период, количество выданных карт, суммарные лимиты портфелей и т.п. Такие проверки отлично выявляют проблемы на тракте данных. Выход того или иного показателя за пределы доверительного интервала может говорить, например, о сбое в загрузке данных из какого-то источника или о возникновении массовой ошибки. Получая сигнал о нетипичной динамике показателей, мы можем оперативно провести анализ и выяснить, является ли отклонение следствием сбоя (скажем, задублированная загрузка клиентов) или какого-то объективного изменения (например, резкий рост числа новых клиентов в результате успешной рекламной компании).
Кроме того, существуют комплексные проверки. К ним относятся сложные проверки, агрегирующие большое число данных: например, балансовые сверки, сверки объемов выдач, проверка наличия связей счет-сделка-клиент и т.п. Эти проверки необходимы для корректного формирования отчетности и принятия управленческих решений.
АС МКАД позволяет реализовать полный цикл управления всеми тремя категориями проверок: их создание, запуск и эксплуатацию, исполнение, редактирование и вывод из эксплуатации в архив. При этом простые проверки могут создаваться как путем написания кода, так и с использованием конструктора в пользовательском интерфейсе.
Также система рассчитывает метрики и индикаторы качества данных, необходимые для анализа качества данных и оценки эффективности мер по его повышению. Кроме того, она обеспечивает оперативное реагирование на выявленные проблемы в автоматизированном режиме. Если в ранних версиях дата-стюардам приходилось осуществлять постоянный мониторинг дашбордов, то сейчас в случае выявления проблем с качеством данных система автоматически формирует и направляет уведомления ответственным дата-стюардам, а также регистрирует инцидент качества данных в Jira.
Таким образом, нам удалось создать собственную платформу мониторинга качества данных, основанную на технологиях PostgreSQL, Python, nginx, Apache Airflow, Grafana.
Внедрение системы позволило решить одновременно несколько исключительно важных задач. Мы полностью устранили зависимость от иностранного ПО в части мониторинга и реагирования на инциденты качества данных. Нам удалось снизить время реакции на инциденты качества данных и повысить надежность процесса управления качеством данных, при этом существенно расширив периметр контролируемых данных. Наконец, мы значительно уменьшили трудоемкость и продолжительность внедрения проверок качества данных и радикально сократили затраты дата-стюардов на мониторинг качества данных.
- С какими проблемами пришлось столкнуться? Что было самым сложным?
Как и в любом проекте по внедрению «с нуля» нового решения, нам пришлось столкнуться как с организационными, так и с техническими проблемами. Организационные проблемы рассматривать не будем, так как они специфичны для каждой отдельно взятой компании. Что же касается технических проблем, то главным образом нам пришлось решать проблемы совместимости различных компонентов системы. Также существенные усилия потребовались для выполнения требований информационной безопасности и отказоустойчивости, особенно в части открытых платформ nginx и PostgreSQL. Однако, как человек, обладающий большим опытом внедрения коробочного ПО, скажу: результат стоил этих усилий. Лучше помучиться при разработке и получить именно то решение, которое тебе надо, чем пройти внедрение гладко и жить с половиной необходимого функционала.
- Что собой представляет созданное рабочее место дата-стюарда?
Рабочее место дата-стюарда – это основной рабочий интерфейс системы, позволяющий осуществлять управление жизненным циклом проверок качества данных, изучать отчеты о результатах исполнения проверок, просматривать дашборды, на которые выводятся результаты исполнения проверок, рассчитанные метрики и индикаторы качества данных, а также осуществлять drill-down до конкретных объектов и ошибок в данных. Таким образом, рабочее место дата-стюарда позволяет решать все задачи по мониторингу качества данных, а также ряд задач по анализу выявленных проблем и созданию простых проверок качества данных.
- Кто является пользователем конструктора проверок качества данных? Насколько важно использование режима no-code?
В настоящее время пользователями конструктора проверок являются сотрудники Офиса CDO, но мы планируем тиражирование функционала на бизнес-пользователей для реализации концепции self-service Data Quality (DQ). Это будет сделано после выполнения технических мер по ограничению допустимой нагрузки и дополнительных мер защиты от некорректных действий пользователей.
Для нас использование no-code не является принципиальным. Любая проверка может быть создана в системе написанием кода вместо использования конструктора.
Смысл внедрения конструктора в том, что он позволяет существенно снизить «порог вхождения» для специалистов. Теперь совершенно необязательно уметь программировать на SQL, чтобы создать проверку качества данных. Это расширяет круг потенциальных пользователей и позволяет привлекать к созданию проверок аналитиков и методологов, не имеющих навыков программирования. Кроме того, за счет этого удается практически исключить риски создания некорректных запросов, способных «повесить» базу данных. Поскольку конструктор сам генерирует код по заданным правилам, мы гарантированно не получим в запросе более сотни джойнов. Именно два этих фактора позволяют нам говорить о тиражировании функционала для бизнеса.
Вместе с тем, всегда остается часть очень сложных проверок, создание которых возможно исключительно путем написания кода.
- Как измеряется качество данных? Каких успехов в области качества удалось достичь?
Вопрос измерения качества данных – а особенно динамики изменения качества данных – был одним из важных методологических вопросов, который поставило перед нами руководство. Нами была разработана универсальная методика измерения качества данных, которая позволяет измерить как в момент времени, так и в динамике качество данных по отдельным атрибутам в разрезе характеристик качества данных (полноты, актуальности, точности, разумности и т.д.). Также методика, реализованная в системе, позволяет проводить интегральные измерения качества данных – например, измерение качества данных в разрезе предметных областей, бизнес-линий и т.д. Для каждого такого интегрального показателя мы устанавливаем целевые значения и отслеживаем динамику его изменения.
Проводимые нами измерения показывают существенный рост качества данных по приоритетным направлениям в течение последнего года. Не вдаваясь в детали бизнеса, могу сказать, что за последний год нами было исправлено более 7 млн объектов (клиентов, сделок, проводок и т.д.). Это примерно на 70% выше показателей предыдущего года. По ряду предметных областей, например, в части клиентских данных, нам удалось добиться кратного снижения количества ошибок в данных. И хотя непосредственно исправление данных не выполняется в системе МКАД, она играет ключевую роль в выявлении и анализе исправляемых впоследствии ошибок.
- Каких бизнес-результатов удалось достичь?
Своевременное выявление и устранение инцидентов качества данных позволяет избежать прерывания обслуживания клиентов, принятия некорректных управленческих решений и получения штрафов от регуляторов, вызванных ошибками в отчетности. Совокупный экономический эффект только от снижения рисков штрафов, вызванных проблемами с качеством данных, в 2022 году оценен нами более чем в 800 млн руб.
- Что оказывает большее негативное влияние на бизнес: штрафы регулятора или некорректные управленческие решения? То есть где потенциально кроется наибольший эффект от качества данных?
Это довольно сложный вопрос, поскольку, в отличие от штрафов регулятора, достоверно оценить в деньгах последствия некорректных управленческих решений не представляется возможным. Благодаря нашей системе мы в любой момент времени знаем, какой потенциальный максимальный размер штрафов мы можем получить от того или иного регулирующего органа за нарушения качества данных в предоставляемой отчетности. Эти штрафы описаны в законодательстве, и мы маркируем выявленные проблемы соответствующим образом. Это позволяет нам всегда иметь актуальный расчет возможных потерь с учетом вероятности их получения, а не только накопленную информацию о фактически уплаченных штрафах. Данное знание позволяет нам аргументировать целесообразность выполнения работ и, соответственно, затрат, направленных на устранение выявленных проблем. Например, мы можем сказать, что необходимо затратить на доработку процесса 10 млн, что снизит размер возможного штрафа на 100 млн. Имея на руках конкретные цифры, всегда проще договориться с бизнесом, чем просто апеллируя к чувству прекрасного.
На мой субъективный взгляд, последствия некорректных управленческих решений, вызванных некачественными данными, могут быть гораздо более разрушительными, чем штрафы, но, к сожалению, пока мы не научились их правильно оцифровывать. Как правило, такие последствия наступают не сразу, и далеко не всегда можно однозначно понять, что именно их вызвало. История дает нам множество примеров, когда некорректная информация, используемая для принятия решений, приводила не просто к убыткам, а к краху корпораций и крушению империй. В политике, промышленности или медицине ошибки в исходных данных могут убивать. В случае банков, к счастью, страдают только организации, а не люди.
- Какие смежные направления охватил проект? Что вообще планируется импортозамещать?
Успешное решение задачи импортозамещения в нашем проекте и ряде других проектов банка открыло для нас потрясающее окно возможностей. Сформирована отдельная программа, в рамках которой планируется импортозамещение всех критически важных элементов ландшафта. Естественно, управление данными, как одна из ключевых функций, не осталось в стороне. В ближайшее время мы планируем провести работы по реализации на технологиях Open Stack и российском ПО каталога данных, Data Firewall, системы применения моделей и еще целого ряда решений, касающихся Data Governance. Не хочу сейчас раскрывать все наши планы, но в ближайшие 2-3 года мы рассчитываем добиться по-настоящему впечатляющих результатов в этой области. Соответствующие решения уже приняты на самом высоком уровне, и я уверен, что мы сможем с гордостью представить результаты нашей работы.
- В каком направлении будет развиваться проект?
АС МКАД будет развиваться как экстенсивно – увеличивая периметр контролируемых данных, так и интенсивно – путем наращивания функционала, повышения скорости реакции и дальнейшей автоматизации рутинных операций. В настоящее время мы выработали концепцию под условным названием МКАД++, которая должна превратить нашу систему мониторинга в платформу управления качеством данных. Мы планируем создание единого DQ API, которое позволит проверять корректность данных на этапе их создания, а также расширить возможности контроля качества данных на всех этапах их обработки, интегрировав проверки в ETL-процессы. Далее на основе МКАД появится система self-service DQ, которая даст возможность бизнес-пользователям самостоятельно создавать и запускать необходимые проверки качества данных. Такое решение очень востребовано со стороны аналитических подразделений и дата-сайентистов.
Также мы планируем провести НИОКР в части нашего конструктора проверок на предмет автоматического создания проверок для разных баз данных без участия оператора. Но это пока выглядит, как что-то из области научной фантастики, поэтому расскажем подробности, когда решение заработает.
