Современный банк существует одновременно в двух временных режимах.

В первом живёт традиционная отчётность: закрытие дня, регуляторные формы, финансовые витрины, расчёт показателей, историческая аналитика. Здесь данные вполне могут поступать пакетами – раз в час, несколько раз в день или даже T-1 (актуальность «на вчера»).

Во втором времени существует клиент. Он только что совершил перевод и ожидает сразу увидеть новый баланс и историю операции. Новый продукт банка нужно предложить подходящему клиенту сейчас, а не завтра утром. Операция изменила состояние счёта – об этом должны узнать цифровые каналы, системы контроля, аналитики и другие потребители. Руководителю операционного подразделения важно видеть происходящее сегодня, а не состояние бизнеса на момент вчерашней загрузки хранилища.

Для реализации всех этих процессов, наряду с классическими ETL-процессами, в банковской архитектуре появляется всё больше EL-конвейеров, работающих в режиме, близком к реальному времени – Near Real-Time, NRT.

NRT не должен становиться самоцелью. Непрерывная доставка изменений стоит дороже пакетного обмена – она требует постоянно работающей инфраструктуры, контроля отставания, обработки сбоев, гарантии доставки, мониторинга изменений структуры источников и круглосуточной эксплуатации.


Поэтому прагматический принцип при построении архитектуры звучит так:

Для банков таких задач оказывается довольно много.

Со стороны клиента банк может выглядеть как одно приложение. Внутри – это большая экосистема информационных систем.

В центре обычно находится АБС – автоматизированная банковская система, или несколько систем класса Core Banking. Именно здесь живут счета, договоры, остатки, проводки, кредиты, депозиты и значительная часть финансовых операций.

Но рядом с АБС работают другие специализированные системы:

• карточный процессинг – выпуск и обслуживание карт, авторизация, карточные операции, клиринг

• платёжный контур / Payment Hub – внутренние, межбанковские, валютные и другие платеж

• CRM – клиентские отношения, продажи, обращения, кампании

• LOS (Loan Origination System, система кредитного конвейера / система выдачи кредитов) и кредитные системы – заявки, скоринг, принятие решения, выдача и обслуживание кредитов

• системы корпоративного банка – расчётно-кассовое обслуживание, корпоративные карты, гарантии, факторинг, cash management

• казначейство и ALM (Asset and Liability Management, управление активами и пассивами банка) – ликвидность, позиции, активы и обязательства, процентные и валютные риски

• брокерские и инвестиционные системы

• антифрод, AML и другие системы комплаенса и управления рисками

• MDM и справочные системы

• мобильный и веб-банк, контакт-центр, Open API и другие клиентские каналы

Современные банковские платформы именно поэтому строятся как набор взаимодействующих сервисов и доменов. Например, крупнейшие технологические компании для банковской отрасли предоставляют для Core Banking открытые API, а для асинхронной межсистемной интеграции – банковские события, возникающие при изменении состояния счетов, транзакций и других объектов.

Ни одна технология не должна пытаться обслужить все взаимодействия между этими системами.

Когда клиент нажимает в мобильном банке кнопку «Перевести деньги», это бизнес-команда. Она должна пройти через API и соответствующие банковские сервисы, где выполняются авторизация, проверка лимитов, бизнес-правила, расчёт комиссии и сама транзакция.

CDC здесь не нужен.

Бизнес-событие будет удобным механизмом, когда операция уже произошла и необходимо сообщить о ней другим прикладным системам: «платёж исполнен», «счёт открыт», «лимит изменён».
Когда необходимо собрать сложный объект из нескольких таблиц, выполнить расчёты, обогатить его справочниками или сформировать регуляторную витрину, естественным инструментом становится ETL/ELT.

Но есть ещё одна задача:

Как быстро и массово забрать из работающей АБС или другой высоконагруженной СУБД все произошедшие изменения и передать их в хранилище, Lakehouse, ODS или другой информационный контур?

И желательно сделать это так, чтобы сама АБС практически не получила дополнительной нагрузки.

Вот это уже естественная область CDC - Change Data Capture.

Не спрашивать базу снова и снова

CDC экономит существенные ресурсы по сравнению с классическим ETL – не делает сравнения базы данных, не требует выполнения запросов с большим количеством диапазонов данных. Для базы данных АБС или другой высоконагруженной системы каждый дополнительный вид регулярных запросов чувствителен. Её вычислительные ресурсы нужны прежде всего клиентским операциям, платежам, проводкам и другим функциям самого банка.

Помимо низкой нагрузки на источник, система репликации должна быть универсальной – организовывать EL-конвейеры, поддерживать транзакции и гарантировать доставку с минимумом промежуточных этапов.

CDC экономит существенные ресурсы по сравнению с классическим ETL – не делает сравнения базы данных, не требует выполнения запросов с большим количеством диапазонов данных. Для базы данных АБС или другой высоконагруженной системы каждый дополнительный вид регулярных запросов чувствителен. Её вычислительные ресурсы нужны прежде всего клиентским операциям, платежам, проводкам и другим функциям самого банка.

Помимо низкой нагрузки на источник, система репликации должна быть универсальной – организовывать EL-конвейеры, поддерживать транзакции и гарантировать доставку с минимумом промежуточных этапов.

Для ряда задач ETL/ELT-процессы приоритетнее, чем непрерывная передача данных в отчётную СУБД. Традиционные конвейеры применяются в таких задачах, как:

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

Классический ETL имеет важные преимущества: можно собрать данные из разных источников, выполнить сложные соединения, рассчитать производные поля, проверить качество, обогатить справочниками и передать потребителю уже готовый бизнес-объект.

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

1. Оперативные копии данных для front-office
Мобильный банк, веб-банк, контакт-центр и другие клиентские системы постоянно запрашивают данные о счетах, продуктах, статусах операций и истории взаимодействия.

Пускать каждое такое чтение непосредственно в АБС не всегда разумно.

Одна из моделей: АБС – CDC – ODS / оперативная копия – API – Mobile / Web.

В такой архитектуре АБС продолжает выполнять транзакции, а информационные запросы обслуживает специализированный слой.

При этом команда «провести платёж» всё равно идёт по API в соответствующий банковский сервис. CDC не заменяет бизнес-интерфейс - он позволяет разгрузить его от массового чтения.


2. Оперативная аналитика
Традиционное корпоративное хранилище часто исторически строилось вокруг пакетной загрузки.

Однако часть банковской аналитики всё меньше согласна ждать T-1:

• текущие обороты

• статусы платежей

• активность каналов

• состояние кредитного конвейера

• операции корпоративных клиентов

• карточная активность

• операционные KPI

• выявление зависших процессов

В этом случае возможна схема: операционная СУБД – Датафлот – Greenplum или его форк – аналитика.

Датафлот поддерживает Greenplum и ряд его российских производных как источники и приёмники, а наполнение хранилищ и онлайн-аналитика входят в заявленные сценарии продукта.


3. Data Lakehouse и открытые форматы
У банка появляется всё больше потребителей, которым нужен общий слой актуальных данных вместо нескольких параллельных специализированных выгрузок: BI, Data Science, ML, риск, антифрод, Customer 360, ИИ.

Решение этой задачи возможно через современные решения Data Lakehouse с наполнением через EL-конвейеры: АБС / Cards / Payments / CRM → Датафлот → Data Lakehouse.

Это позволяет один раз вывести изменения из операционного контура, а затем использовать данные различными вычислительными механизмами.

Датафлот Репликация получил поддержку Apache Iceberg в качестве приёмника данных в дополнение к Apache Parquet.


4. Риск, антифрод и клиентская аналитика
Для многих аналитических сценариев важно соединить текущую и ретроспективную информацию о клиенте. Например, новая транзакция может дополняться историей операций, сегментом, используемыми продуктами, состоянием счетов и рассчитанными признаками.

Критическую онлайн-авторизацию операции CDC не заменяет - для неё нужны специализированные транзакционные и потоковые системы.

Но постоянное NRT-наполнение аналитического слоя позволяет гораздо быстрее обновлять признаки, Customer 360, модели поведения, витрины риска и данные для расследований.


5. Аудит и полная история изменений
Обычная таблица отражает текущее значение, но для расследований, контроля и аудита важно знать, как это значение изменялось в прошлом.

Например: лимит 100 тыс. → 300 тыс. → 500 тыс.

или последовательность изменения статуса договора: договор создан → активирован → заблокирован → закрыт.

Датафлот поддерживает режим аудита и позволяет сохранять сведения об изменениях данных.


6. Один источник – несколько назначений
Изменение в АБС может одновременно понадобиться:

• в ODS – для оперативного чтения

• в Greenplum – для аналитики

• в Iceberg / Lakehouse – для общего слоя данных

• в Audit/SCD – для истории изменений

Датафлот позволяет передавать одинаковые данные нескольким приёмникам для различных архитектур назначения могут использоваться отдельные проекты репликации.

На первый взгляд CDC выглядит просто: взять журнал транзакций, разобрать его, и передать в получатель.

Но есть несколько вопросов, на которые требуется получит чёткий ответ:

• Что произойдёт, если канал оборвётся после передачи части операций?
• Какие записи уже применены?
• Какие нужно повторить?
• Как не получить дубль?
• Можно ли применить UPDATE раньше связанного INSERT?
• Что делать с незакоммиченной транзакцией?
• Что произойдёт, если разработчик приложения добавил колонку в исходную таблицу?

Поэтому промышленная репликация – это не только парсер журнала. И они детально реализованы в Датафлот Репликации.

1. Транзакционная согласованность

Датафлот передаёт только зафиксированные транзакции и поддерживает транзакционную целостность данных.

Для банка это принципиально. Нельзя получить в аналитическом или оперативном контуре половину логически связанной транзакции только потому, что отдельные строки технически успели измениться.

2. Гарантированная доставка и восстановление после сбоя
Датафлот использует механизм контрольных точек: система фиксирует, какие данные уже были обработаны парсером и какие изменения загрузчик применил в приёмнике с подтверждённым COMMIT. Это используется для восстановления после сбоя и предотвращения потерь или неконтролируемого дублирования операций.

Именно это отличает промышленный конвейер от простого механизма «прочитать изменения и отправить дальше».

3. DDL-изменения
Операционная система развивается.

Появляются таблицы, добавляются или удаляются колонки, меняется структура данных.

Если NRT-конвейер не знает об изменении схемы, он может остановиться именно в тот момент, когда исходное приложение штатно обновилось.

Датафлот поддерживает захват и репликацию ряда DDL-операций конкретный набор зависит от типа приёмника. Пользовательское руководство, например, описывает репликацию создания и удаления таблиц и настройку типов отслеживаемых DDL-изменений.

4. Первоначальная загрузка плюс CDC
До начала CDC необходимо создать исходное состояние приёмника. Это важно с точки зрения построения конвейера данных, включая исторические данные.

Датафлот включает сервис первоначальной синхронизации, после которой автоматически переходит к онлайн-репликации.

5. Гетерогенность
Банковская инфраструктура редко однородна.

В ней одновременно могут использоваться Oracle, PostgreSQL и его российские варианты, MS SQL Server, DB2, Greenplum и его форки, Hadoop, Kafka, объектные хранилища и аналитические СУБД.

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

Датафлот поддерживает широкий набор реляционных источников и приёмников, MPP-системы, Hadoop-платформы и другие типы хранилищ.

6. Администрирование, а не программирование каждого потока
Промышленная интеграция – это эксплуатация.

Проект нужно создать, настроить сопоставление данных, запустить, наблюдать отставание, диагностировать ошибки и восстанавливать работу.

Датафлот предоставляет единый графический интерфейс настройки и мониторинга доставка в приёмники может настраиваться без самостоятельной разработки внешних коннекторов.

Для крупного банка это важно не меньше скорости: десятки критичных потоков должны оставаться управляемыми через годы после их создания.