Хабр, привет! В этой статье расскажем, как команда банка ВТБ построила собственную аналитическую систему на базе открытых технологий и с использованием решений Arenadata. Мы рассмотрим архитектуру платформы, разберём её сильные и слабые стороны, а также заглянем «под капот» — покажем, как устроены процессы внутри банка и почему ВТБ решил идти своим путём, а не использовать готовые вендорские системы.

Казначейство и его вечная головная боль

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

• Как изменение ключевой ставки повлияет на будущий чистый процентный доход (ЧПД)?

• Сколько ликвидности банк удержит в стресс-сценарии?

Ответы невозможно получить один раз и «повесить в рамочку на стену» — портфель меняется ежеминутно, а регуляторные нормативы должны соблюдаться постоянно. Поэтому нужна система, которая умеет:

1. Собирать данные по всем сделкам и позициям.

2. Моделировать их поведение на горизонте от одного дня до пяти лет.

3. За минуты пересчитывать десятки метрик под десятком макросценариев.

4. Позволять казначеям «крутить ручки» и сразу видеть, что выйдет.

Почему зарубежные «коробки» не подошли нам

Когда-то банки полагались на Kamakura, Wolters Kluwer, Finastra и другие ALM-платформы. Мы в ВТБ тоже смотрели в эту сторону, пока не столкнулись с рядом непримиримых ограничений:

ALM (Asset Liability Management) — это устоявшееся международное обозначение процесса управления активами и пассивами банка. 

Добавьте сюда санкционные риски и отсутствие российских аналогов — и получится веский повод строить своё.

Какой ALM решили построить

Мы в банке выделили три ключевых принципа будущей платформы:

• Импортонезависимость. Вся база — от ОС Astra Linux до Arenadata Hadoop (ADH) и Kubernetes — доступна на российском рынке и отвечает требованиям ЦБ РФ.

• Расширяемость без копирования данных. Модели, расчёты и данные живут в одной среде, новые сценарии подключаются через Spark UDF или микросервис без «прокладки» ETL.

• Скорость и масштаб. 1 млн сделок × 13 сценариев должны считаться меньше 10 минут на кластере из commodity-нод, а при росте нагрузки мы сперва оптимизируем код, потом партиционируем данные и лишь затем докупаем железо. 

Именно этот набор требований и привёл нас к двухконтурной архитектуре: микросервисы для сценариев и фактор-анализа с одной стороны и мощная платформа данных на ADH с другой.

Стек:

• среда: Astra Linux;

• контейнерная платформа Kubernetes;

• backend: Java 21 + Spring Boot;

• frontend: микрофронтенды, ReactJS;

• возможность взаимодействия: асинхронное через Artemis, синхронное через REST API;

• оркестрация процессов: Camunda 7;

• СУБД: PostgreSQL.

Высокоуровневая архитектура

Два контура, одна экосистема

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

Такое разделение позволяет микросервисам оставаться «тонкими» (только бизнес-логика и UI), а тяжёлую математику и данные держать в кластерной среде, где им и место.

Сквозной поток данных

1. Ночные загрузки

• Из подготовленного PostgreSQL мы реплицируем сделки, справочники и параметры в Hive-таблицы.

• Оркестрация — Airflow: DAG’и формируют слои ODS, CDM, BDM и проверяют качество данных.

  2. Формирование ALM-витрин

• По расписанию или по событию Spark преобразует BDM-данные в ALM-витрины (Parquet + датовое партиционирование).

• Эти витрины уже содержат все необходимые расчётные признаки: скорректированные ставки, кривые дисконтирования, флаги поведенческих сегментов и т. д.

  3. Запуск расчёта денежных потоков

• Пользователь в UI задаёт сценарий, после Camunda публикует сообщение в Artemis MQ.

• Сенсор Airflow ловит сообщение и стартует DAG.

• Spark-кластер параллелит сделки (repartition подобраны так, чтобы медианный partition примерно составлял 100 MB) и за несколько минут считает cash-flow, NPV, EVE и прочие метрики.

  4. Доставка агрегированных результатов

• «Тонкие» агрегаты складываются в защищённое S3-совместимое хранилище.

• Микросервисы по HTTPS подтягивают CSV/XLSX-файлы, раскладывают их по PostgreSQL и отдают фронтам или BI-слою.

• Старый прямой экспорт в PostgreSQL из Hive постепенно выводится из эксплуатации.

Поведенческие и ML-модели: как «живёт» аналитика внутри расчёта

Для любой ALM-системы мало просто посчитать статический cash-flow; ключевая добавка — модели, которые объясняют, как клиенты реально ведут себя под действием ставок и сроков. Это досрочное гашение кредитов, пролонгация депозитов, перетоки средств с одного продукта на другой и т. д.

От лаборатории к продукции без «ручной переклейки»

Прототип возникает в Jupyter-ноутбуке поверх DR-кластера — туда с часовой задержкой реплицируются все нужные витрины. Аналитик пишет Python-код, проверяет метрики качества прямо на «почти боевых» данных и, как только схема стабилизировалась, отдаёт репозиторий в GitLab. Дальше pipeline «СФЕРЫ» собирает виртуальное окружение, прикладывает его к Spark-job и публикует в арт-репозиторий: теперь та же логика доступна как UDF, которую можно подмешать к любому DAG’у Airflow. Никакой двойной реализации — у команды банка один исходник и один артефакт.

Исполнение внутри Cash Flow Engine

Во время расчёта Spark-процесс грузит подготовленную ALM-витрину, а затем, в рамках той же сессии, импортирует нужные UDF’ы. Каждая сделка, попав в executor, «прогоняется» через модель: кредит получает вероятность досрочного гашения на каждом месячном шаге прогноза, депозит — вероятность пролонгации, карточный портфель — прогноз смерти или роста баланса. Всё это делается синхронно с основными расчётами денег, поэтому дополнительных проходов по данным не нужно.

ALM-витрины: как мы готовим «топливо» для расчётов

ALM-витрина — это снимок портфеля банка на конкретную дату, уже обогащённый всеми нужными полями и проверенный на целостность. Внутри неё:

• Миллионы сделок с детализацией до купона и календаря платежей.

• Маркет-параметры (кривые ставок, спреды ликвидности, FX-курсы).

• Флаги поведенческих сегментов и параметры ML-моделей (досрочное гашение, пролонгация и т. п.).

Чтобы не плодить десятки специфических таблиц под каждый расчёт, мы в ВТБ держим классическую «трёхслойку» прямо в Hive/HDFS.

Такой конвейер позволяет добавлять новые источники/атрибуты, не переписывая слой выше: достаточно прописать шаг в соответствующем DAG’е.

Оркестрация и доставка результатов

Вся «хореография» ALM-процессов строится вокруг связки Camunda + Airflow. Camunda описывает бизнес-процесс: пользователь задаёт сценарий, движок публикует команду в очередь Artemis, получает статусы и хранит историю. Airflow реагирует на эти команды сенсором, запускает DAG из трёх шагов — загрузка параметров, расчёт Spark-кластера и выгрузка агрегатов — и в завершении каждого шага возвращает результат обратно в очередь. 

После расчёта итоговые таблицы (обычно это десятки мегабайт CSV или XLSX) складываются в S3-совместимое внутреннее хранилище. Фронтовые сервисы забирают их по HTTPS и, при необходимости, публикуют в PostgreSQL, откуда данные сразу видит BI-слой. Сейчас команда банка мигрирует с Qlik Sense на PIX BI. Такой маршрут избавляет нас от двусторонней «тяжёлой» репликации: наружу выходят только агрегаты, а детальные данные никуда не покидают кластера ADH.

BI-слой: миграция с Qlik Sense на PIX BI

Финальный потребитель отчёта — не аналитик-разработчик, а казначей или риск-менеджер, которому нужна интерактивная расшифровка числа «в один клик». В старой архитектуре отчёты собирал Qlik Sense: витрины из ADH реплицировались в отдельную PostgreSQL, а Qlik строил на них модели ассоциаций. С переходом банка на российское ПО произошла миграция на PIX BI. С точки зрения данных почти ничего не изменилось: ALM-витрины по-прежнему готовятся в Spark, по-прежнему реплицируются в «читаемую» базу, а фронт-слой штампует визуализации. 

Тонкость в том, что для глубоких провалов, например «найди двадцать крупнейших сделок с остатком более миллиарда», PIX BI умеет обращаться прямо к Hive, минуя промежуточный слой. Такой прямой коннект покрывает менее пяти процентов запросов, но экономит время на репликацию и даёт аналитикам честный взгляд на «живой» Parquet-файл. Все остальные 95% отчётов работают из PostgreSQL, и пользователю нет разницы, на каком BI-движке они построены.

Производительность и масштаб: железо — последний аргумент

Кластер сегодня — это десять узлов, чуть больше тысячи ядер и около шести терабайт памяти. На таких ресурсах тринадцать параллельных сценариев по миллиону сделок укладываются в SLA «менее десяти минут». Если объём растёт, команда придерживается строгой последовательности. Сначала профилируется Spark-код: убираются лишние shuffle-операции, тяжёлые Python-UDF переписываются с использованием Pandas UDF или векторизуются. Затем пересобирается партиционирование витрин, чтобы медианный размер блока оставался примерно 100 Мб. Лишь в третью очередь, если оба шага не дали желаемого эффекта, через Arenadata Cluster Manager (ADCM) добавляются новые узлы.

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

CI/CD и наблюдаемость: «СФЕРА», Prometheus и Grafana

Все артефакты — Spark-скрипты, Airflow DAG’и, микросервисы Spring Boot — живут в корпоративном GitLab, а конвейер «СФЕРА» гоняет их одинаковым способом. Каждый merge-request поднимает тестовую среду, прогоняет юнит- и интеграционные тесты, собирает контейнеры и выкатывает их сначала в stage, затем в production. Продуктивный деплой не предполагает ручных команд; максимум, что делает инженер, — нажимает кнопку approve.

В продакшене метрики собирает Prometheus. Он знает о загрузке YARN-очередей, объёме HDFS, здоровье Kubernetes-подов и количестве активных DAG’ов. Grafana визуализирует эти данные на дашбордах, где видно, как конкретный сценарий «садится» на ядра, сколько памяти потребляет и в какой момент начинается выгрузка результатов. Алерты настроены не по «красным-зелёным» меткам, а по отклонению от обычного поведения; поэтому дежурный инженер получает уведомление только тогда, когда есть риск сорвать SLA, а не при каждом пике нагрузки.

Как ВТБ адаптировал решения на базе Arenadata Hadoop к требованиям ЦБ РФ

Переезд на полностью открытый стек начался с того, что Банк России предписывает хранить персональные данные и расчётные показатели только на площадках, полностью контролируемых банком. Поэтому первым делом мы в банке отказались от проприетарных ОС и СУБД: продуктивные кластеры работают на Astra Linux, контейнерная среда — Kubernetes, реляционный слой — PostgreSQL, а «тяжёлые» данные живут в Arenadata Hadoop (HDFS + Hive + Spark). Такой набор входит в единый реестр отечественного ПО, поддерживается российскими вендорами и не требует согласований при обновлениях.

Фокус внимания регулятора — неизменяемость и трассируемость финансовых данных. Добивались этого тем, что слои ODS/CDM/BDM в Hive «append-only»: любая правка создаёт новую партицию с меткой времени, а прежняя версия остаётся нетронутой, а Spark-сессия при запуске берёт точный снимок по указателю в метаданных DAG’а. В итоге аудитор видит, какие файлы участвовали в конкретном отчёте, и может воспроизвести расчёт вплоть до байта.

Итоги

Отказавшись от монолитной лицензии и сделав ставку на open source, ВТБ получил два значимых бонуса. Во-первых, время пересчёта любых сценариев радикально сократилось с часов до минут: теперь данные не приходится перегонять между хранилищами, а расчёты ведутся непосредственно в той среде, где хранятся витрины. Во-вторых, вывод новых метрик и моделей на продуктив теперь занимает недели, а не кварталы, как было раньше: любая новая модель или расчёт становится просто дополнительным компонентом, который запускается через стандартный CI/CD-процесс, без дорогостоящих контрактов с внешними подрядчиками.

Но главное даже не это — такой подход позволяет развивать одновременно и экспертизу в микросервисах, и глубокие навыки работы с Hadoop-экосистемой (HDFS, Spark, Airflow и Hive). Эти технологии становятся стандартом не только в российском финтехе, но и на глобальном рынке аналитических платформ. Развиваясь в этих двух направлениях, вы инвестируете в своё профессиональное будущее, формируете уникальный профиль и создаёте основу для карьерного роста на годы вперёд.