Всем привет! На связи команда Центра разработки решений ALM‑стримов «ALM 2.0 Платформа» и «Динамическое моделирование баланса». В этой статье расскажем, как в нашей компании создаётся современная ALM‑система: на основе импортонезависимых решений, с расчётным ядром на Spark/Hadoop и интуитивно‑понятной интерфейсной частью на React/Java/Postgres. Ещё расскажем, как устроены витрины, где живёт логика и как запускаются пользовательские расчеты.

Что такое ALM и какую роль она играет в жизни банка

ALM (Asset and Liability Management) — это система управления активами и обязательствами банка. Её задача — спрогнозировать, как изменения процентных ставок, курсов валют, поведения клиентов и рыночной ситуации повлияют на финансовое состояние банка в будущем. ALM помогает:

• оценить будущие денежные потоки;

• рассчитать чувствительность к макроэкономическим шокам;

• спрогнозировать соблюдение нормативов ликвидности и достаточности капитала;

• принимать управленческие решения: от настройки структуры портфеля до формирования продуктовой стратегии.

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

• Что будет с нормативами ликвидности, если ставка вырастет?

• На сколько изменится финансовый результат, если мы понизим ставку по вкладам на 0,5%?

• Как изменится структура остатков на счетах при снижении доходности?

• Какие продуктовые решения помогут сохранить маржу в нестабильной среде?

Ответы на эти вопросы не помещаются в привычный Excel. За ними стоит мощная, высокопроизводительная платформа. И мы такую платформу построили и продолжаем работать над её развитием

Взгляд сверху: архитектура

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

С самого начала мы закладывали принцип импортонезависимости. Технологический стек целиком построен на отечественных решениях и надёжных open‑source инструментах, включённых в реестр Минцифры.

Вот как выглядит распределение по слоям:

Оба слоя работают в контейнерах под управлением Kubernetes. Все расчёты выполняются рядом с данными в Hadoop‑кластере — это существенно снижает накладные расходы и ускоряет выполнение задач. Пользователи же работают через удобный веб‑интерфейс или напрямую через API. Такой подход позволяет достигать высокой производительности и гибкости.

Поток данных сквозь всю платформу

Наша ALM‑платформа построена исходя из сквозной прозрачности и согласованности данных. Весь путь — от загрузки информации до расчёта и визуализации результатов — спроектирован как единый управляемый процесс. Такой подход даёт предсказуемость, возможность точечного контроля качества и минимизирует ручные действия. Рассмотрим поэтапно, как проходят данные сквозь систему.

1. Загрузка: ODS-слой

Каждую ночь данные из десятков источников — баз данных PostgreSQL и Oracle, core‑банков, внешних систем — поступают на ODS‑уровень нашего хранилища. Мы используем подход CDC (change data capture): изменения транслируются в Parquet‑файлы, которые кладутся в HDFS.

Здесь же выполняется оркестрирование (DAG»и Apache Airflow управляют загрузками) и проходят первые data‑quality‑проверки на полноту, уникальность и свежесть. Если проверка не пройдена, то DAG аварийно завершается и данные не попадают в последующие слои.

2. Преобразование: CDM и BDM

На этом этапе данные из ODS мы очищаем, нормализуем и приводим к единому формату. CDM содержит вычищенные записи по сделкам, справочникам и курсам, а BDM — это уже тематические витрины по направлениям «Кредиты», «Депозиты», «Деривативы» и т. д.

Инструменты: Spark SQL + Spark UDF. Здесь могут применяться бизнес‑правила (например, приведение условий сделок к единому виду) и элементы обогащения (сегменты клиентов, индикаторы поведения).

Всеми этими шагами тоже управляют DAG»и в Airflow, что позволяет прозрачно отслеживать прохождение данных и перезапускать цепочки при необходимости.

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

ALM‑витрина — это наш стратегический артефакт, снимок банковского портфеля на определённую дату, уже обогащённый всеми необходимыми атрибутами:

• скорректированные процентные ставки;

• кривые дисконтирования;

• поведенческие флаги (например, вероятность досрочного гашения);

• параметры моделей.

Формат хранения: Parquet с делением по датам. Каждая ALM‑витрина может весить десятки гигабайтов, но разбита на компактные блоки для параллельной обработки.

4. Сценарный запуск и расчёт

Пользователи нашей ALM‑платформы через удобный интерфейс создают нужные сценарии: задают параметры, выбирают шоки, указывают даты. Эти сценарии инициируют процесс:

• Camunda публикует команду в очередь Artemis MQ;

• сенсор в Airflow ловит сообщение, запускает DAG;

• Spark‑кластер запускает задачу с расчётом: разбивает сделки на партиции, применяет сценарные параметры, рассчитывает бизнес‑метрики (денежные потоки, NPV, EVE, и т. д).

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

5. Доставка и просмотр результатов

После завершения расчёта результаты сохраняются в S3-совместимое внутреннее хранилище, а затем перекладываются в БД PostgreSQL в виде итоговых отчётов. Эти данные проходят обработку и становятся доступны для интерфейса и BI‑слоя. Мы сознательно не переносим в PostgreSQL тяжёлые сырые данные, только агрегаты, сжатые и подготовленные для финального использования.

Пользователь может увидеть результат двумя способами:

• Через интерфейс ALM — в виде таблиц, выгрузок, визуализаций по ключевым метрикам. Интерфейс построен на React и оптимизирован под сценарии «посмотреть, сравнить, скачать».

• Через BI‑инструменты, и у нас их два:

  • PIX BI — используется для анализа витрин и тяжёлых отчётов, где нужна глубина и производительность. В отдельных сценариях (например, deep dive) подключается напрямую к Hive и работает с живыми Parquet‑файлами.

  • Apache Superset — применяем для визуализации небольших агрегированных отчётов, построенных поверх PostgreSQL. Удобен для компактных дашбордов и оперативного контроля.

Важно: в BI‑слой попадают только агрегаты, а все детальные сделочные данные остаются внутри Hadoop‑кластера. Это позволяет снизить нагрузку, обеспечить безопасность и соблюсти требования по контролю доступа.

Как встраиваются аналитические и поведенческие модели

В любой ALM‑системе важно не только «пересчитать» текущие данные, но и учесть поведение клиентов в разных сценариях. Досрочное гашение кредитов, пролонгация вкладов, перетоки между продуктами — всё это влияет на результат не меньше, чем ставка ЦБ.

В нашей ALM‑платформе поведенческие и аналитические модели встроены прямо в процесс расчёта. Они не живут отдельно, не вызываются из стороннего сервиса, а работают как Spark UDF внутри одной сессии: синхронно с основными расчётами.

Как выглядит жизненный цикл модели:

1. Разработка. Аналитик поднимает Jupyter‑ноутбук в DR‑кластере, подключается к витринам, пишет код на Python. Здесь же проверяют метрики качества, проводят A/B‑сравнения.

2. Подключение к Spark. После стабилизации логики модель попадает в репозиторий. Далее наш конвейер (CI/CD) упаковывает её в артефакт: окружение + зависимости + функция расчёта → всё это становится Spark‑совместимым UDF.

3. Интеграция в расчёт. При запуске сценария Spark подтягивает нужные UDF прямо в рамках своей сессии и применяет их на уровне executors. Каждая сделка проходит через модель:

   • кредит — получает вероятность досрочного погашения по месяцам;

   • вклад — вероятность пролонгации;

   • счёт — прогноз удержания средств.

Почему это важно:

• Единый код: нет дублирования между экспериментами и продуктивом.

• Нет «ручной переклейки»: один репозиторий — один артефакт.

• Масштабируемость: модели обрабатываются параллельно вместе с основной Spark‑задачей.

• Гибкость: в любой момент можно подключить или отключить модель параметром в конфигурации сценария.

Таким образом, мы не просто считаем денежные потоки, а строим реалистичные сценарии с учётом поведения клиентов — это даёт более точные прогнозы и полезные выводы для бизнеса.

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

ALM‑сценарии — это не «раз в сутки посчитать отчётик». Это параллельные расчёты по миллионам сделок, десяткам метрик и сценариев, где важна не только точность, но и скорость. Ведь расчёт, который длится два часа, просто не даёт бизнесу вовремя принять решение.

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

Что есть сейчас

Наш Hadoop‑кластер на текущий момент содержит:

• 10 узлов, каждый с несколькими десятками vCPU;

• 1000+ ядер в сумме;

• около 6 ТБ оперативной памяти.

На таких ресурсах мы спокойно рассчитываем:

• 13 параллельных сценариев;

• по 1 млн сделок в каждом;

• за менее чем 10 минут (в среднем — 7–8 мин).

Как мы масштабируемся — в правильном порядке

Мы придерживаемся принципа: сначала оптимизируй, потом масштабируй. Вот типовой порядок действий:

1. Профилируем Spark‑задачи. Используем Spark UI, YARN, Prometheus. Ищем тяжёлые места: лишние shuffle, collect, пересортировки, неоптимальные join. Иногда помогает простая замена Python UDF на Pandas UDF или векторизация.

2. Перенастраиваем структуру хранения. ALM‑витрины переформатируются с таргетом на партиции ~100 МБ. Это даёт оптимальный размер для одного executor»а: не слишком мелко (чтобы не увеличивать накладные расходы) и не слишком крупно (чтобы не страдало распараллеливание).

3. Только потом — увеличиваем ресурсы. Если оба шага не дали результата, мы добавляем узлы через ADCM (Arenadata Cluster Manager). Это делается за часы, но важно: это не первая реакция, а осознанный шаг.

Что даёт такой подход?

• Прозрачный контроль затрат: мы не живём «впрок» и не держим idle‑ядра.

• Повышение квалификации команды: инженеры действительно понимают, как работает Spark, а не просто «дёргают бегунки».

• Гибкость: при необходимости можем увеличить SLA до 20 сценариев или 10 млн сделок, не переписывая код.

CI/CD и наблюдаемость: автоматизация от кода до эксплуатации

Чтобы ALM‑платформа действительно работала как система, а не как набор скриптов, нам важно было выстроить не только расчёты, но и инфраструктурный конвейер: от идеи — до стабильной эксплуатации. В этом нам помогает связка «Платформа СФЕРА» + Prometheus + Grafana.

Конвейер без ручной магии

Все артефакты — будь то Spark‑скрипты, DAG»и Airflow, микросервисы Spring Boot или модели в виде UDF — живут в корпоративном репозитории. Каждый merge‑request запускает стандартный конвейер «Платформы СФЕРА»:

1. Сборка и тестирование. Конвейер поднимает тестовую среду (namespace в Kubernetes), прогоняет модульные и интеграционные тесты. Если код ломает совместимость или падает на данных, то MR не пройдёт проверку.

2. Упаковка и выкладка. Успешно собранный артефакт (будь то JAR, .py‑файл, контейнер или zipped DAG) публикуется в арт‑репозиторий и автоматически развёртывается в stage‑окружение.

3. Релиз. После прохождения smoke‑тестов инженер просто нажимает «Approve», и артефакт уходит в production. Ручных шагов минимум. Всё версионируется и журналируется, можно откатить в один клик.

Этот процесс одинаков как для Spark‑расчётов, так и для интерфейсов. Особенно удобно, когда расчёт зависит от изменений в модели или схеме витрины — всё собирается и катится в одном конвейере.

Мониторинг: всё под контролем

Prometheus собирает метрики со всех ключевых компонентов системы:

• загрузка Spark/YARN‑очередей;

• статус Kubernetes‑подов (фронты, микросервисы);

• объём HDFS и S3-хранилищ;

• количество DAG'ов в очереди и в процессе выполнения;

• среднее время расчёта по каждому сценарию.

Все данные визуализируются в Grafana: на одном дашборде можно увидеть полный путь: от запуска сценария пользователем до публикации результата. Особенно полезны графики по:

• длительности Spark job'ов;

• потреблению процессоров и памяти по DAG»ам;

• задержке на каждом этапе конвейера.

Оповещения построены не по «жёстким порогам» («CPU > 90%»), а по отклонениям от нормы: если сценарий X обычно считается 5 минут, а сейчас длится 12 — это повод разбираться.

Что это даёт?

• разработчикам — уверенность, что код не сломает прод: всё автоматизировано;

• инженерам — прозрачность статуса системы и удобство отладки;

• бизнесу — SLA‑предсказуемость: мы точно знаем, что расчёт будет готов вовремя.

Что в итоге: гибкая, быстрая, наша

Создание ALM‑платформы в нашей компании — это не просто импортозамещение ради галочки. Это осознанный шаг в сторону гибкости, прозрачности и контроля над развитием.

Что мы получили на выходе:

• скорость: расчёт десятков сценариев по миллионам сделок укладывается в минуты, а не часы;

• масштабируемость: мы умеем расти как вширь (по объёму данных), так и вглубь (по сложности моделей и расчётов);

• импортонезависимость: стек построен на отечественных и open‑source решениях;

• гибкость: любую метрику, модель или отчёт можно внедрить за считанные дни:

• инфраструктура как код: единые конвейеры CI/CD, централизованный мониторинг, стабильные выкладки.

А ещё, создавая такую платформу, мы одновременно прокачали и нашу команду:

• инженеры углубились в микросервисную архитектуру, работу с API, интерфейсом, сценарным оркестрированием;

• data‑инженеры и аналитики стали уверенно работать со Spark, Hadoop, Airflow, Hive, UDF, оптимизацией DAG'ов;

• а вместе с этим — усвоили банковскую предметку, начиная от ALM‑концепций и заканчивая стресс‑сценариями и регуляторными нормативами.

У нас получилась не просто система расчётов, а живая технологическая ALM‑платформа, за которой стоит сильная, слаженная команда, уверенно работающая на стыке бизнеса, математики и продвинутого data‑инжиниринга.