Как в РДТЕХ обеспечивают подготовку обязательной отчетности банка ТОП-5
Насколько растут объемы данных, кто делает их качественными, какие стандарты задает регулятор при совершенствовании системы отчетности, что ждет традиционные хранилища и системы обязательной отчетности – об этом и многом другом рассказал ведущий разработчик РДТЕХ Тагир Билалов.
– Когда в РДТЕХ начали работать над КХД в интересах финансового сектора?
– Больше двадцати лет назад рынку был предложен стандарт для финансовых хранилищ – Oracle Financial System Applications. Решение было универсальным, масштабируемым и кастомизированным и представляло собой общую концепцию плюс некоторое количество готовых метаданных – структур, слепков таблиц и т.д. На основе этого в 2007 году архитекторы РДТЕХ начали активно создавать проект DWH-КИХ. Одним из первых на рынке, на основании Меморандума о стратегическом сотрудничестве, был успешно реализован проект между банком ТОП-5 и Oracle с участием РДТЕХ.
Сегодня на различных фреймворках РДТЕХ системы под свои потребности дорабатывают наши сотрудники, коллеги и конкуренты – банки, интеграторы.
– Кто является собственником ИТ-продуктов?
– Долгое время исключительные права на код принадлежали РДТЕХ. Сейчас на рынке сложилась такая ситуация, что правообладателем решений является заказчик. Если сегодня к нам в отдел приходит новый разработчик, мы банально не можем познакомить его с документацией, потому что она хранится в контуре банка, и нужно разрешение на доступ.
– Что представляет из себя фреймворк обязательной отчетности, разработанный РДТЕХ в 2007 году?
– Была основная канва, а также справочники и настройки, способы управления формами. То есть пользователь при работе с системой сначала выбирал форму, потом задавал нужный отчетный период, у него появлялся список с подразделениями. Специалист мог менять статус, производить расчеты.
Одной из первых разработок стал модуль поддержки форм отчетности. Всю историю изменений – по версиям, сотрудникам, истории сопровождения – можно посмотреть в спецификациях пакетов программного кода.
В хранилище все время добавляются новые таблицы и сущности, данные по счетам, сделкам, клиентам, их связи в рамках филиальной сети. Требуется соответствие общероссийским классификаторам. Технически основная схема в базе данных – это справочники со всей историей изменений по самым важным банковским операционным вещам: клиенты, сделки, ценные бумаги, лицевые счета, агрегированные показатели в суммах, сгруппированные по разным периодам.
– Только ли из роста клиентской базы становится больше объем данных?
– Также по причине усложнения требований Центробанка к кредитным организациям. Регулятор не дает скучать. Два года назад была смена формата. Больше 20 лет Центробанк принимал отчетность в формате «Клико», с 2023 года все участники рынка переходят на программный продукт «Дельта». Это изменение потребовало нового кода.
– Как это отразилось в цифрах?
– Ежедневно внутренний пользователь, создающий только отчетность, генерирует 23 Гб в день, это порядка 700 Гб в месяц, хранящихся на диске. В среднем в день в систему отчетности дважды заходит 26 пользователей – сотрудников банка.
В целом объем базы данных каждый год растет примерно на 30%. За 11 лет моей работы в РДТЕХ модуль «Обязательная отчетность», например, содержащий порядка 70 форм, стал больше почти в 7 раз.
Каждый клиент и сделка имеют свою историю. Допустим, человек меняет букву в фамилии – например «е» на «ё», появляется новая запись с обновлёнными, изменёнными атрибутами. По каждому признаку также должен быть соответствующий исторический справочник. Есть разграничение по валютам клиентских счетов, кросс-курсам валют и так далее.
Сегодня число таблиц в хранилище, содержащих основные финансовые показатели банка – 119. Число исторических справочников сущностей в проекте сегодня – 232, локальных – то есть специфических атрибутов сущностей – 310.
– Насколько оперативно проводится разработка кода, и как это связано с ускорением расчетов в системе?
– Разработчику всегда интересно не только составить тот или иной отчет, но и сделать это максимально быстро. Некоторые формы считаются за доли секунды, другие – больше суток. Ряд оптимизаторов подключается не сразу, потому что они работают сразу на много фронтов. Определенное ускорение в расчетах дает секционирование по датам и филиалам банка.
– Каков объем хранилища?
– Порядка 300 терабайт. Кстати, упомянутая нами отчетность банка перед регулятором, Центробанком, составляет 15 терабайт. Разработчики думают об оптимизации хранения, в частности мы внедряем новый функционал, например, усовершенствовали импорт текстовых и Excel файлов в отчетность. Конечно, есть ряд сложностей, а именно с выдачей патчей, получением сопровождений от Oracle. В то же время, несмотря на миграцию банка с 11 версии на 19, в повседневной работе специалисты не используют новомодные фишки, ограничиваясь проверенным временем функционалом.
– Как же быть с ростом объемов данных?
– Есть серьезные исследования в области математической теории написания кода, где утверждается, что объемы в сопровождении старого кода не будут расти при определенных условиях. То есть с развитием систем, с их жизненным циклом поддержка и сопровождение старого кода со временем не задействует все ресурсы разработки. Но изменения могут быть продиктованы требованиями информационной безопасности.
– Участились ли случаи атак злоумышленников на ИБ-контур банка?
– Подобных инцидентов в практике поддержки и разработки хранилищ не происходило. Был случай, когда достаточно ценные данные были случайно удалены на промышленном сервере, но их оперативно удалось восстановить в том числе благодаря слаженной командной работе.
– Целесообразно ли для решения проблем внедрять в структуру КХД искусственный интеллект?
– ИИ в финансовой сфере активно развивается в приложениях для клиентов. Конечно, есть внутренние разработки по портации языковых моделей в банковскую сеть. Я видел в работе одну систему, которая позволяет без программирования, без написания кода, работать с базой данных по сути программированной мышкой. Но в целом банковский контур замкнут относительно всемирного интернета.
– Тем не менее в КХД поступают данные не лучшего качества.
– Данные на самом деле могут быть разной степени корректности. Но корпоративное хранилище многослойно. На самый первый слой попадают данные – файлы, таблицы, с ужасным качеством из разных источников. Часто это старые базы данных на старых версиях.
Для наполнения хранилища используются ETL-инструменты. ETL – это трехэтапный процесс интеграции данных, который извлекает, преобразует и загружает необработанные данные из источника в хранилище.
Проблемой оракловых проектов долгое время было то, что банально не существовало контроля типов и логических атрибутов. И «косяки» по качеству данных помогали доставать и разбирать старые «скелеты».
В то же время если делать качество данных стратегическим направлением, то мы можем прийти к ситуации, когда автоматические инструменты поддержания определенного уровня данных будут использовать слишком много ресурсов – аппаратных и человеческих.
– Насколько вы ощущаете проблему дефицита кадров при найме сотрудников?
– Факт, что молодежь сегодня не особо стремится изучать SQL и не будет неделями сидеть над кодом. Скорее им интереснее иметь дело с ChatGPT, разрабатывать на Python. Но в России достаточно большая армия разработчиков старой закалки, и на их программистский век задач хватит.
