Открытая платформа управления качеством данных

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

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

Начало

В 2020 году в «Газпромбанке» был развернут офис CDO (Chief Data Officer — «директор по данным»), одна из главных задач которого — обеспечение качества данных. Казалось бы, трудностей быть не должно — на рынке предлагалось множество различных решений от именитых и не очень поставщиков, Сеть изобиловала информацией, а на многочисленных конференциях наперебой рапортовалось об успешных внедрениях того или иного продукта. Но высокая стоимость лицензий, дорогостоящая поддержка, зависимость от экспертизы поставщика, отсутствие гибкости и адаптивности — вот далеко не полный перечень того, чем приходится платить за выбор коробочного решения. В результате возникла идея создания собственной платформы управления качеством данных на базе стека Open Source, что, как показали последующие события, оказалось весьма прозорливым решением.

Такая платформа должна удовлетворять следующим требованиям:

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

Культура и автоматизация работы с данными

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

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

Для контроля качества данных были выделены простые и сложные проверки. Первые могут создаваться массово и автоматически с минимальными трудозатратами, например: проверка ссылочной целостности; проверка заполнения атрибутов; проверка на допустимые значения атрибутов. Для полного покрытия проверками критических атрибутов консолидированных данных требуются тысячи простых проверок, поэтому здесь важны скорость и простота их создания. Сейчас такие проверки создаются с помощью веб-интерфейса, в конструкторе (рис. 1). Перед тем как проверка будет установлена на регламент, выполняется его автоматическая предварительная валидация — проверяется SQL-синтаксис, наличие объектов, над которыми выполняется запрос, и наличие прав доступа к ним.

Рис. 1. Конструктор простой проверки

Сложные проверки, предполагающие выполнение сложных алгоритмов, невозможно сгенерировать в исполняемый код из метаданных либо создать с помощью конструктора запросов (например, отчет о сходимости балансов) — алгоритм содержит тысячи строк кода и его приходится программировать на процедурных языках, таких как PL/SQL. Сложная проверка создается в виде отдельного ETL-процесса, который запускается в рамках регламентного потока задач. Как правило, речь идет о выстроенной в ETL-инструменте последовательности объемных SQL-запросов.

Рис. 2. Конструктор проверки — задание параметров рассылки и интеграции с Jira

Все проверки имеют параметры настройки, позволяющие управлять их жизненным циклом (рис. 2), например: статус проверки (черновик/эксплуатация/архив); владелец проверки и ответственный за мониторинг дата-стюард проверки; длина доверительного интервала — количество дней, в течение которых рассчитывается доверительный интервал отклонения; порог рассылки почтовых уведомлений — метрика, превышение которой инициирует рассылку почтового уведомления; список адресатов рассылки; условие автоматического заведения обращения в Jira. Сейчас в системе реализовано больше 30 типов параметров управления жизненным циклом сложных проверок.

Все проверки качества данных в системе запускаются и рассчитываются автоматически в соответствии с индивидуальными настройками.

Рис. 3. Пример рассылки о завершении проверок витрины клиентской сегментации

Важным инструментом выстраивания процессов управления качеством данных является своевременное уведомление ответственных сотрудников о выявленных проблемах (рис. 3). Для этого имеется два типа автоматических рассылок: уведомления о статусе исполнения проверок качества данных и детальные отчеты о результатах конкретных проверок. Первые сообщают, что проверка (или их группа) успешно выполнена либо возникла аварийная ситуация во время расчета и требуется вмешательство администратора. В случае успешного завершения уведомление содержит агрегированные результаты проверок, а в случае неудачи — детализацию причины.

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

Визуализация

Рис. 4. Пример сводной витрины метрик качества

С учетом ориентации на стек Open Source, для реализации витрин данных была выбрана система визуализации Grafana, которая уже использовалась в организации — на ее основе были сделаны удобные для дата-стюардов и потребителей данных отчеты (рис. 4): интегральные тепловые карты и светофоры; графики, отображающие динамику изменения метрик качества данных с доверительными интервалами; фильтры для отбора отдельных филиалов, автоматизированных систем, таблиц и атрибутов. С их помощью можно обеспечить возможность углубленного анализа до уровня конкретных ошибок в данных.

Архитектура

Рис. 5. Архитектура системы мониторинга качества данных

Первым, с чем надо было определиться при проектировании, была базовая единая платформа данных, которую реализовали на базе Hadoop и Cloudera Data Hub (рис. 5), однако решение в целом изолировано от непосредственно фабрики данных и может работать в равной мере и с другими источниками данных. Регламентные расчеты и процессы управления качеством данных были сделаны на основе единого набора промышленных ETL-инструментов — сейчас ключевым является Apache Airflow.

Каждый элемент процесса контроля — это часть общего регламентного процесса сбора и подготовки данных. Все результаты расчета проверок материализуются — сохраняются в таблицы (в противовес «без материализации», рассчитываются «на лету» в виде представлений или процедур) и сохраняются в общем детальном слое проверок, а также передаются в СУБД PostgreSQL для визуализации в Grafana.

Системную поддержку (СУБД, Linux-серверы, системы виртуализации, сетевое взаимодействие) централизованно обеспечивают профильные ИТ-подразделения банка. Прикладную часть системы обеспечения качества поддерживают три разработчика и один аналитик, попутно решающие и другие задачи. Координация работ происходит либо через менеджера системы, либо через архитектора.

Подводные камни

При переходе с версии Postgres Pro 13 на версию 14, в которой был реализован современный 256-битный алгоритм хеширования SHA256, оказалось, что имевшийся на тот момент не очень современный ETL-инструмент SAS DI (сейчас заменен на Airflow) работал только с MD5 — 128-битным алгоритмом, поэтому возникли трудности в поиске и настройке соответствующих драйверов.

Возникли также проблемы с веб-сервером и почтовым прокси-сервером nGinx, работающим на Unix-подобных ОС, — для выполнения всех требований информационной безопасности пришлось делать специализованную сборку. Кроме этого для дополнительных библиотек Python потребовалось тщательно подбирать подходящую версию для интеграции с Jira — развертывание в кластерной конфигурации продукта Apache Airflow оказалось довольно трудоемко.

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

***

На базе стека Open Source удалось за год разработать и внедрить самодостаточный продукт, позволивший решить ключевые задачи управления качеством данных. Наличие пользовательского конструктора проверок, средств визуализации и рассылки уведомлений, а также интеграции (ETL) с любыми системами, работающими в контуре организации, позволяет оперативно выстраивать процессы контроля основных показателей и интегрировать их в бизнес-процессы. У бизнес-пользователей появился инструмент постоянного мониторинга качества данных, а в банке внедрены процессы управления качеством. Ежедневно выявляются и обрабатываются инциденты, связанные с обеспечением качества данных.

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

Екатерина Мельникова (ekaterina.a.melnikova@gazprombank.ru) – управляющий директор службы управления корпоративными данными; Алексей Бондаренко – начальник службы управления корпоративными данными, «Газпромбанк» (Москва). Статья подготовлена на основе материалов выступления на конференции «Качество данных 2023».