Блиц-разбор заблуждений вокруг импортозамещения банковских хранилищ данных

Ёмкое разоблачение популярных мифов про импортозамещение хранилищ данных в банках от эксперта Ассоциации российских банков, заместителя генерального директора компании «Интерсофт Лаб», Юлии Амириди.

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

Заблуждение: еще ни один банк не запустил ХД на разрешенной СУБД

На самом деле не менее 15 российских банков уже эксплуатируют хранилища данных (ХД) на разрешенных СУБД: оригинальной PоstgreSQL либо проприетарных Arenedata и PostgresPro. Доля портаций действующих ХД на независимые СУБД - 25%, остальные проекты – новые внедрения отечественных версий программных платформ для ХД. В частности, прикладные решения на ХД-платформе «Контур» (СУБД Postgres) от компании «Интерсофт Лаб» в промышленном режиме используют уже в трех российских банках для регуляторных целей, подготовки управленческой отчетности и аллокации расходов, еще несколько проектов находятся в стадии реализации.

Заблуждение: сначала надо решить вопрос с импортозамещением АБС, а потом думать про отечественное ХД

В действительности оптимального для всех банков порядка импортозамещения прикладного ПО не существует. Каждый должен выработать свои приоритеты с учетом бизнес-целей, требований законодательства, финансовых возможностей и кадровой обеспеченности. Например, проект внедрения регуляторного ХД лучше не откладывать. Чем раньше оно заработает, тем скорее защитит отчетные процессы от нестабильности во время перехода на отечественную версию АБС. Портацию ХД на разрешенную СУБД, наоборот, правильнее согласовать по срокам с замещением иностранных компонентов АБС. Это позволит минимизировать расходы на интеграцию. Исключение – банки, для которых на государственном уровне установлены сроки отказа от иностранного ПО. Решение о внедрении ХД для автоматизации новых прикладных задач должно учитывать их ценность для бизнеса. Может оказаться, что приобретаемая выгода превысит издержки на доработку механизмов интеграции после импортозамещения АБС. В любом случае, стоит начать с анализа разных вариантов.

Заблуждение: если внедрить ХД до портации АБС, потом придется второй раз платить за интеграцию

Это преувеличение. Процесс интеграции (иначе ETL) включает три этапа: извлечение данных из АБС (Extract), их преобразование в формат банковской модели данных (Transform) и загрузку в ХД (Load). По требованиям информационной безопасности Extract - подготовку в базе данных АБС представлений (витрин) для передачи данных в ХД - банки все чаще оставляют на своей стороне, а Transform и Load поручают исполнителю. Если структуры данных АБС в результате перевода на импортонезависимую версию изменятся, банку придется обновить свои запросы для извлечения данных. А на стороне исполнителя потребуется точечная доработка правил трансформации (маппингов) и тестирование загрузки данных в ХД. По составу работ видно, что в создании второго интеграционного решения нет необходимости. Понадобится частичная переделка на этапах Extract и Transform и проверка корректности сделанных изменений.

Заблуждение: Консолидация аналитического ландшафта на базе единого отечественного ХД – техническая задача ДИТ

Импортозамещение – удачный повод, чтобы оптимизировать разросшуюся аналитическую инфраструктуру банка на базе единого отечественного ХД. Главное, чтобы при этом у нового ХД-проекта не исчезли бизнес-основания и внутренние заказчики. Такая опасность существует, когда импортозамещение и консолидация сводятся к техническому объединению первичных данных на разрешенной ХД-платформе без четкого бизнес-императива, чтобы найти им применение позднее. Это путь в никуда. Потенциальные пользователи не примут самое современное и технологически независимое ХД, если оно не решает конкретных бизнес-проблем. Такое ХД превратится в бесполезный склад данных и не будет использоваться.

Заблуждение: приобретать для ХД проприетарные СУБД на базе PostgreSQL – переплачивать за шильдик

Такое утверждение не имеет оснований. Ключевые отличия отечественных СУБД из Реестра российского ПО от оригинальной PostgreSQL: дополнительные функции, повышенная производительность и масштабируемость, совместимость с разрешенными операционными системами, наличие сертификатов ФСТЭК («конфиденциально», персональные данные) и техническая поддержка от отечественных разработчиков. Но самое главное преимущество – полная технологическая независимость. В распоряжении правообладателей российских СУБД имеется исходный код PostgreSQL, а профессиональных компетенций инженеров достаточно, что развивать и сопровождать его, даже если проект утратит статус свободного или доступ к нему для российских пользователей будет закрыт. Приобретение отечественной СУБД – это не просто оплата добавленной функциональности, это защита инвестиций в ХД от косвенных санкционных рисков, присущих ПО с открытой лицензией.

Заблуждение: СУБД Postgres не подходит для ХД с большими (>200ТБ) объемами данных

Это не так. Для работы с большими объемами данных СУБД Postgres позволяет реализовывать распределенную архитектуру с использованием специальных расширений, например Citus для ванильной PostgreSQL или Shardman для коммерческой Postgres Pro. Однако, по опыту «Интерсофт Лаб» 200+ТБ для ХД в банке – явление редкое. Чаще всего, это следствие неэффективной реализации бизнес-логики и организации данных при создании ХД. В большинстве случаев оптимизация архитектуры и процедур обработки данных может существенно сократить размеры ХД и обеспечить приемлемую производительность на enterprise-редакции СУБД.

Заблуждение: ХД-проекты на импортонезависимом ПО неоправданно выросли в цене

Невозможно ответить за всех прикладных разработчиков, поставщиков оборудования, системного ПО и внедренческие команды. Но изменения в стоимости лицензий и услуг для ХД-проектов на платформе «Контур» 5.х (СУБД Postgres), которая включена в Реестр российского ПО, обоснованы и прозрачны. 5.х сменила предыдущую версию платформы, которая опиралась на иностранные технологические компоненты. Принципиальная разница версий, конечно, в независимой СУБД, хотя платформа 5.х имеет целый ряд других функциональных улучшений. Поскольку новая версия несет заказчику большую ценность, то стоимость лицензий на ее компоненты повысилась в соответствующем рынку и комфортном для заказчиков коридоре. Состав работ по внедрению ХД, их трудоемкость и стоимость после смены версии не изменились. Лишь для крупнейших банков в состав работ по проекту могут опционально войти тестирование и оптимизация производительности на СУБД Postgres.

Заблуждение: результаты и сроки построения ХД на отечественной СУБД невозможно прогнозировать – неизвестно какие проблемы возникнут

Зачем же рисковать? Убедиться в осуществимости ХД-проекта и реалистичности заявленных сроков поможет пилотное (тестовое) внедрение. Это давно и хорошо зарекомендовавшая себя практика. Выбранная для тестирования задача должна отражать специфику использования ХД в банке несколько ближайших лет, охватывать все этапы внедрения целевого решения и выполняться в срок до 6 месяцев. Деловая практика предусматривает особые условия для защиты интересов участников пилотного проекта. Обычно на этот период вендор предоставляет тестовые лицензии на ХД-платформу и СУБД, а заказчик обязуется оплачивать услуги исполнителя независимо от результатов. Окончательное решение о приобретении лицензий и заключении договора на внедрение принимается по итогам пилота. Тогда же с учетом полученного опыта и выявленных ограничений уточняется план-график реализации проекта.

Автор: Юлия Амириди, заместитель генерального директора компании «Интерсофт Лаб»

Источник: Global CIO