CC BY
22
УДК 004.652.6
DATA VAULT В КАЧЕСТВЕ АРХИТЕКТУРЫ ХРАНИЛИЩА ДАННЫХ БАНКОВСКОЙ ОРГАНИЗАЦИИ
© 2022 М. И. Попов1, Ф. Б. Лазарев2
1 студент, направление подготовки Информационная безопасность e-mail: maximtoreno228@yandex. ru
2кандидат технических наук, доцент кафедры информационной безопасности
e-mail: severus99@icloud.com
МИРЭА - Российский технологический университет
При построении архитектуры хранилища данных важно учитывать возможности для дальнейшего роста и масштабирования. С учетом особенностей работы банковских организаций Data Vault является эффективным методом проектирования хранилищ данных и решает важнейшую проблему любого крупного банка - дальнейшую масштабируемость и возможность добавления новых систем источников.
Ключевые слова: хранилища данных, хаб, линк.
DATA VAULT AS A DATA STORAGE ARCHITECTURE OF A BANKING
ORGANIZATION
© 2022 M. I. Popov 1, F. B. Lazarev2
1Student, training area Information security e-mail: maximtoreno228@yandex.ru 2 Candidate of Technical Sciences, Associate Professor of the Department of Information Security e-mail: severus99@icloud.com
MIREA - Russian Technological University
When building a data warehouse architecture, it is important to consider opportunities for further growth and scaling. Taking into account the peculiarities of banking organizations, Data Vault is an effective method of designing data warehouses and solves the most important problem of any large bank - further scalability and the possibility of adding new source systems.
Keywords: data warehouses, hub, link.
Банки являются одной из самых динамически развивающихся и перспективных отраслей экономики любой страны. При этом технологический прогресс и развитие интернет-сервисов привели к трансформации финансового бизнеса, выдвинув на передний план такие характеристики, как удобство предоставления услуг для каждого отдельного пользователя, надежность банковских приложений и их масштабируемость.
Возможность для дальнейшей модификации является одной из самых важных характеристик банковского хранилища данных. Этот факт связан со спецификой работы любой организации, которая включает в себя взаимодействие с несколькими системами-источниками. Так, например, различные подразделения банка могут
использовать отличные программные продукты, будь то пакетные решения или корпоративные разработки организации. При этом рынок пакетных решений предлагает большое количество готовых и адаптированных под те или иные особенности конкретной индустрии факторов. Ярким примером этого является Центр финансовых технологий - российская группа компаний, предоставляющая готовое программное обеспечение для большинства крупных банков и организаций сферы телекоммуникаций.
Масштабирование может происходить как внутри самого банка, так и за счет поглощения других финансовых организаций. Примером подобного развития событий является вхождение «Рокетбанка» в состав «Киви банка» в 2017 г.. Однако полного объединения сервисов этих организаций по итогу не произошло, а «Рокетбанк» спустя некоторое время был закрыт.
Нередки случаи объединения нескольких информационных систем дочерних организаций в одну общую - с соответствующим изменением хранилища данных компании. Так произошло с ПАО «ВТБ», одним из крупнейших банков России, который объявил об обновлении своей IT-инфраструктуры после слияния с «Банком Москвы» и «ВТБ24». Новое хранилище (в компании его название ЦЕХ - Целевое единое хранилище) будет объединять в себе данные из систем-источников всех дочерних организаций, используя при этом импортозамещающие программные продукты и платформы.
При построении архитектуры хранилища данных важно учитывать возможности для дальнейшего роста и масштабирования, так как даже первоначально малый, семейный бизнес может перерасти в архитектурно значимый проект для всего государства. В таком случае будет актуальным использование структуры Data Vault.
Data Vault (или же «Свод данных») - подход к проектированию баз данных, сформулированный впервые в 1990-ых гг., а позднее модифицированный и представленный Дэном Лидстедтом в 2000-х. Он заключается в существовании трёх основных классов сущностей (стереотипов) базы данных: хаба, сателлита хаба и линка.
Хаб является таблицей, представляющей одну конкретную бизнес-сущность. Так, например, для банковского хранилища будут актуальны следующие примеры: хаб лицевого счета клиента, клиента, отделения банка, сотрудника организации и т.д.
При этом количество атрибутов (строк в таблице) хаба сильно ограничено и включает в себя лишь технические значения, такие как первичный ключ (суррогатное значение, сформированное непосредственно при добавлении в хранилище), ключ записи в системе-источнике, признак валидности записи и др.
Все же основные описательные атрибуты сущности содержатся в сателлитах -таблицах, связанных с хабом по первичному ключу и хранящих всю подробную информацию по бизнес-сущности, записанной в хабе. Например, в сателлит хаба клиента будет вынесена такая информация, как его ФИО, дата рождения, гражданство, номер паспорта, признак банкротства, принадлежность к тем или иным льготным категориям, и многие другие данные, необходимые для работы с данным клиентом.
Важно помнить, что данные динамичны и постоянно актуализируются. В том числе и персональные данных клиентов - любой гражданин может сменить личный номер мобильного телефона, адрес электронной почты или даже фамилию и номер паспорта. При этом все кредитные организации (и банки в том числе) обязаны хранить важные отчетные документы и данные в течение установленных нормативных сроков (при этом не менее пяти лет). В таком случае удаление или замена строк в базе данных недопустимы: сателлиты обязаны быть историчными (то есть каждая строка имеет свой срок действия и на каждый определенный момент времени для каждого ключа хаба имеется только одна действующая запись в сателлите).
Попов М. И., Лазарев Ф. Б. Data Vault в качестве архитектуры хранилища данных банковской организации
Для обозначения связей одних сущностей с другими используется промежуточная таблица связей, или линк, где прописываются ключи связанных между собой сущностей. На рисунке 1 мы видим связь клиента с его счетом при помощи
таблицы связей.
Рис. 1. Связь клиента и его лицевого счет при помощи таблицы связей
У хаба может быть как один, так и несколько сателлитов, ведь информация по той или иной бизнес-сущности может быть получена из различных систем-источников банка. Это необходимо, так как один и тот же клиент может быть пользователем различных банковских продуктов: дебетовые и кредитные карты, программы рассрочки или же ипотечное кредитование.
При построении модели Data Vault необходимо придерживаться следующих правил:
• ключи хабов не могут мигрировать в другие хабы, чтобы не нарушать гибкость и расширяемость техники моделирования Data Vault;
• первичные ключи хаба никогда не меняются;
• хабы связываются только с помощью ссылок;
• ссылка должна связывать не менее двух хабов и может связываться с другими ссылками;
• ключи хаба всегда мигрируют в ссылки и дочерний сателлит с контекстными данными;
• сателлит может быть связан с хабами и с ссылками;
• сателлит всегда содержит временную метку даты загрузки (Start Date ) ;
• если хаб имеет 2 или более сателлита, для удобства операций объединения (join) можно создать point-in-time таблицу;
• данные распределяются по структуре сателлитов на основе типа информации и темпах ее изменения.
На рисунке 2 мы видим пример построения модели Data Vault согласно правилам выше.
Рис. 2. Пример построения модели Data Vault
Вышеописанный подход к проектированию хранилища данных имеет существенное преимущество - возможность простого последующего расширения (например, создание сателлитов из новых систем-источников для хабов). Также нельзя не отметить относительную простоту разработки ETL-процессов под данную архитектуру.
При этом подход также не лишен и недостатков: Data Vault не может быть единственным слоем хранилища данных, так как с помощью него сложно реализуемы конкретные отчеты и запросы по тем или иным показателям организации (например, с целью предоставления финансовой отчетности). Таким образом, архитектура подразумевает обязательное наличие пользовательских витрин (таблиц или представлений, спроектированных для предоставления конечных показателей по той или иной области работы банка на конкретный период). Так, Data Vault может быть частью «Ядра» хранилища, тогда как конечный бизнес-пользователь работает с уже приведенными к нужному формату слоями, построенными «над» Data Vault.
Подводя итог выше сказанному, можно уверенно сказать, что с учетом особенностей работы банковских организаций Data Vault является эффективным методом проектирования хранилищ данных и решает важнейшую проблему любого крупного банка - дальнейшую масштабируемость и возможность добавления новых систем источников, что, в свою очередь, является важным критерием с учетом перехода на импортозамещающие программные продукты.
Библиографический список
1. Вайн, Саймон. Оптимизация ресурсов современного банка / Саймон Вайн. - 2 издание, переработанное и дополненное. - Москва : Альпина Паблишер, 2020. -192 с.
2. Вайгенд, Андреас. Big data. Вся технология в одной книге / Андреас Вайгенд ; [перевод с английского С. Богданова]. - Москва : Эксмо, Бомбора, 2018. -380 с.
3. Паклин, Н. Бизнес-аналитика: от данных к знаниям [Текст] : учебное пособие / Н. Паклин, В. Орешков. - Москва [и др.] : Питер, 2013. - 701 с.
4. Солянов, К. Методика проектирования банковского хранилища данных на основе конфигурируемой многокомпонентной модели данных / К. Солянов //
Попов М. И., Лазарев Ф. Б. Data Vault в качестве архитектуры хранилища данных банковской организации
Инновации и инвестиции. - 2019. - №9.
5. Туманов, В. Е. Проектирование реляционных хранилищ данных / В. Е. Туманов, С. В. Маклаков. - Москва : Диалог-МИФИ, 2007. - 333 с.
