Привет, Хабр! Меня зовут Иван Останин, я тимлид разработки в ВТБ. Направлением работы моей команды являются платформы данных. Сейчас совместно с командой из Холдинга T1 мы работаем над одним из проектов в части модернизации платформы данных банка. Сегодня я хочу поделиться с вами нашим опытом и инсайтами, которые мы получили в процессе этой масштабной и сложной задачи.

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

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

Банк ВТБ и его эквайринговая сеть

Банк ВТБ обладает одной из крупнейших эквайринговых сетей в России. Эта сеть включает огромное количество терминалов, которые позволяют миллионам клиентов ежедневно совершать покупки, обрабатывая около 3,5 миллионов транзакций в день. Эквайринг является сложным и высокотехнологичным бизнесом, требующим тщательной координации и управления множеством контрагентов, включая партнеров и мерчантов, между которыми необходимо обеспечивать своевременные взаимозачеты.

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

Предпосылки миграции

В последние годы банк ВТБ начал масштабную реорганизацию всего ИТ-ландшафта, что не могло не коснуться и платформы данных. В рамках этой реорганизации банк принял стратегическое решение заменить западные решения от компаний Teradata и Cloudera на отечественную платформу Arenadata DB. Это решение обусловлено несколькими ключевыми факторами:

Реорганизация ИТ-ландшафта

Банк ВТБ стремится создать более гибкую и эффективную ИТ-инфраструктуру, способную быстро адаптироваться к изменениям рыночных условий и требованиям законодательства. Это включает в себя переход на отечественные технологии, которые предлагают аналогичные или даже улучшенные возможности по сравнению с западными решениями, но при этом обеспечивают большую независимость и контроль над данными.

Преимущества отечественной платформы

Arenadata DB предоставляет современные технологии для обработки больших объемов данных, что делает ее привлекательной альтернативой для крупных банковских систем. Основные преимущества включают:

Высокую производительность и масштабируемость: Arenadata DB способна эффективно обрабатывать увеличивающиеся объемы данных, обеспечивая при этом высокую скорость выполнения запросов и аналитических задач;
Гибкость и адаптивность: платформа легко интегрируется с существующими системами и может быть настроена в соответствии с конкретными потребностями банка;
Снижение зависимости от иностранных технологий: использование отечественных решений снижает риски, связанные с возможными санкциями и ограничениями на использование западного ПО.

Необходимость миграции всех решений

На платформе данных банка ВТБ находится огромное количество решений, позволяющих проводить комплексный анализ данных. В связи с переходом на Arenadata DB все эти решения потребовалось мигрировать на новое хранилище, по сути разработав их заново. Витрина данных эквайринга стала первым решением, которое было запущено в промышленную эксплуатацию на новой платформе Arenadata DB. Успешная миграция и запуск витрины эквайринга на новой платформе продемонстрировали возможности Arenadata DB и заложили основу для дальнейших миграций других решений.

Как устроена платформа?

Общая архитектура платформы данных банка ВТБКликните на картинку, чтобы увеличить изображение — ***Общая архитектура платформы данных банка ВТБ***
*Кликните на картинку, чтобы увеличить изображение*

Основные компоненты этой инфраструктуры включают целевое единое хранилище (ЦЕХ) на базе Arenadata Greenplum и аналитическую платформу с озером данных (DAPP) на основе Hadoop. Эти компоненты обеспечивают обработку и хранение больших объемов данных, поступающих как из внутренних, так и из внешних источников.

Основные компоненты инфраструктуры

Целевое единое хранилище (ЦЕХ)
• Платформа: DWH на базе Arenadata DB;
• Функциональность: обеспечивает хранение и обработку структурированных данных. ЦЕХ включает в себя Raw DataVault (RDV) для получения сырых данных систем источников и единую модель (BDM) для обработанных унифицированных данных, а также базовые общие витрины (DM_COMMON).
Аналитическая платформа с озером данных (DAPP)
• Платформа: основана на Hadoop;
• Функциональность: поддерживает работу с внесистемными и внешними данными, репликами систем источников, оперативными и аналитическими витринами данных, а также песочницами и лабораториями для моделирования данных, т.е. здесь есть все данные для молниеносного анализа.

Дополнительные технологии и компоненты

ETL Фреймворк: Apache Airflow используется для оркестрации и автоматизации ETL-процессов, что позволяет эффективно управлять загрузкой, трансформацией и выгрузкой данных;
Доступ к данным: Dremio предоставляет возможности для быстрого и гибкого доступа к данным, хранящимся в DWH;
Бизнес-глоссарий и справочники: инструменты Informatica используются для создания и поддержания бизнес-глоссариев и справочников данных;
BI Инструменты: Self-service BI (Pix BI) и Pixel-perfect BI (Форсайт) обеспечивают пользователям возможности для создания отчетов и проведения аналитики;
Интеграция с потребителями: платформа поддерживает взаимодействие с налоговыми и центральными банками, клиентским скорингом, БКИ, процессами моделирования, расчетами бизнес-планов и премий, взаимодействием с госорганами, а также AML и антифрод процессами.

Архитектура витрины данных

Архитектура эквайринга Кликните на картинку, чтобы увеличить изображение — ***Архитектура эквайринга***
*Кликните на картинку, чтобы увеличить изображение*

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

Основные источники данных

✔️ Карточный процессинг — это ключевой источник данных, который включает информацию о карточных транзакциях, устройствах эквайринга (терминалах), клиентах, счетах и проводках. Данные учетной системы сначала загружаются в оперативный склад данных (ODS), затем в ядро хранилища и после используются в формировании витрины.

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

✔️ Файлы международных платежных систем — этот источник представляет собой большие файлы данных (до 10 ГБ), которые поступают через сервис транспортировки файлов. Для загрузки таких крупных файлов используется специальная утилита GPFDIST, обеспечивающая параллельную обработку и загрузку сегментов данных.

Ядро хранилища поддерживает как бизнес-версионность, достигаемую через реализацию исторических (SCD2) и фактовых таблиц, так и техническую версионность. Каждой загружаемой порции данных хранилище присваивается уникальный version_id, что позволяет отслеживать и управлять изменениями данных на более детальном уровне.

Ядро ЦЕХа состоит из нескольких слоев:
— слой Raw Data Vault обеспечивает сохранение сырых данных в их первоначальном виде;
— слой Integrated Data Layer отвечает за унификацию данных в единую модель;
— слой Business Data Mart предоставляет актуальные представления данных в удобном, для конечных потребителей, виде — в основном отображает актуальный срез данных с точки зрения технических версий.

Витрина данных организована по структуре, которая включает рабочую область, слой дельт, технические таблицы и презентационный слой. Эти компоненты обеспечивают целостность, актуальность и доступность данных для анализа и отчетности. Рабочая область используется для подготовки данных и фиксирования шагов трансформации, слой дельт хранит сформированные дельты данных последнего прогона ETL, технические таблицы хранят все дельты изменений данных для управления версиями, а презентационный слой предоставляет данные в удобном виде для конечных пользователей.

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

Теперь давайте поговорим о разработке потоков

Компоненты фреймворка ЦЕХКликните на картинку, чтобы увеличить изображение — ***Компоненты фреймворка ЦЕХ***
*Кликните на картинку, чтобы увеличить изображение*

Вместе с Apache Airflow для разработки и оркестрации потоков данных в хранилище используется ETL фреймворк, включающий несколько ключевых компонентов. Эти компоненты обеспечивают надежное управление данными, мониторинг процессов и поддержку транзакционности.

Apache Airflow:

Описание: Apache Airflow — это платформа для программного управления рабочими процессами, которая используется для оркестрации и управления расписанием потоков данных.
Функции: Airflow позволяет создавать рабочие процессы (DAGs), управлять зависимостями между задачами, планировать их выполнение и отслеживать их статус.

Менеджер дельт (Delta Manager):

Описание: этот компонент отвечает за установку изменений в целевые таблицы и репликацию данных с промышленного сервера на резервный.
Назначение: управление изменениями данных и их репликация для обеспечения надежности.

Провайдер ресурсов (Resource Provider):

Описание: выполняет роль реестра ресурсов, отслеживая состояние всех данных и предоставляя метрики актуальности и качества данных.
Назначение: управление состоянием и метаданными ресурсов.

Генератор последовательностей (Sequence Generator):

Описание: используется для генерации уникальных суррогатных ключей (RK), обеспечивая уникальность идентификаторов данных.
Назначение: обеспечение уникальности ключей и управление версиями данных.

Менеджер транзакций (Transaction Manager):

Описание: управляет процессом изменений данных, открывая транзакцию и фиксируя все изменения.
Назначение: обеспечение целостности данных при их обновлении.

Дополнительные функции и возможности

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

Постоянное улучшение и развитие

Фреймворк постоянно улучшается и дорабатывается. За его развитие отвечает отдельная команда высококвалифицированных разработчиков, которые работают над добавлением новых функций и улучшением существующих. В планах также есть создание удобного пользовательского интерфейса (UI), который позволит разрабатывать сложную логику без особых усилий.

Устройство потоков

Типовой DAGКликните на картинку, чтобы увеличить изображение — ***Типовой DAG***
*Кликните на картинку, чтобы увеличить изображение*

Концептуально потоки загрузки данных состоят из двух типов DAG:

Управляющий поток:
• Описание: этот поток содержит логику проверок для принятия решений о запуске рабочих DAG.
• Функции: осуществление контроля и управления процессами запуска рабочих DAG.
Рабочие DAG:
• Описание: эти потоки содержат логику загрузки данных.
• Функции: реализация конкретных задач по захвату, трансформации и загрузке данных.

Пример рабочего потока

На рисунке представлен пример рабочего потока, который загружает данные в объект tref_agreement_registry. Этот поток состоит из стандартных шагов, реализующих логику ETL с учетом фреймворка.

prepare_variable:
• Описание: возвращает переменные/статусы в определенный namespace.
• Функция: подготовка необходимых переменных для выполнения последующих задач.
check_dag_running:
• Описание: проверка запуска DAG.
• Функция: убедиться, что данный DAG не выполняется повторно.
get_load_id:
• Описание: генерация уникального ID запуска.
• Функция: обеспечение уникальности каждого запуска для отслеживания и управления.
group_dm и grt_load:
• Описание: группы Task’ов.
• Функция: логическая группировка задач для удобства управления.
sql_proc_dm_pik_fd_dtrb_tref_agreement_registry:
• Описание: запуск функции захватов и трансформации данных.
• Функция: выполнение SQL процедур для обработки данных.
open_trans:
• Описание: создание транзакции в менеджере транзакций, возвращает ID.
• Функция: начало транзакции для обеспечения целостности данных.
block_res:
• Описание: блокировка таргет ресурса в ЦЕХ провайдере.
• Функция: защита целевого ресурса от параллельных изменений.
load_dlt_t_tref_agreement_registry:
• Описание: расчет дельты.
• Функция: определение изменений в данных для дальнейшей обработки.
upd_res_t_tref_agreement_registry:
• Описание: обновление статуса ресурса в ЦЕХ провайдере.
• Функция: актуализации информации о состоянии ресурса.
commit:
• Описание: сохранение изменений в менеджере транзакций.
• Функция: завершение транзакции и подтверждение изменений.
commit_check_delta:
• Описание: проверка наката изменений в дельта менеджере.
• Функция: убедиться в успешности применения всех изменений.

Процесс разработки ETL потоков данных можно условно разбить на следующие шаги:

Получение постановки с логикой сбора данных и прототипа нового объекта;
Создание объектов в DEV базе данных и генерация аксессоров. Аксессор — функция, предназначенная для получения данных в определенном виде, например, актуальный срез технической версионности;
Разработка шагов ETL, включая захваты данных и трансформации, с последующей отладкой. Этот этап включает создание SQL-скриптов, но при этом может быть и Python;
Регистрация ресурсов в ЦЕХ провайдере. Это необходимо для отслеживания состояния и управления метаданными;
Заполнение YAML шаблона с указанием метаданных, входных и рассчитываемых параметров, а также последовательности шагов. Создается YAML файл, в котором указываются все метаданные, входные и рассчитываемые параметры, а также последовательность шагов ETL процесса;
Валидация и построение DAG через builder. YAML файл валидируется и на его основе генерится DAG с помощью builder. Это позволяет быстро получить DAG без написания кода;
Перенос кода в ИФТ с использованием инструментов CI/CD. Код переносится в среду ИФТ с использованием инструментов непрерывной интеграции и доставки (CI/CD), таких, как Bitbucket и TeamCity;
Тестирование с данными и возможные исправления. Выполняется тестирование кода на тестовых данных. В процессе тестирования выявляются и исправляются возможные технические ошибки;
Проводится тестирование в среде PREPROD, чтобы убедиться в корректной работе системы в условиях, максимально приближенных к боевым. Здесь же проводятся приемо-сдаточные испытания (ПСИ);
Подготавливается окончательная поставка, которая включает все необходимые файлы и инструкции для установки разработанного решения в боевой среде;
После установки в боевую среду также проводится дополнительное тестирование. Это необходимо, так как объем данных имеет значительное влияние на работу витрин, и в реальных условиях, могут появиться новые дефекты. После этого этапа проводится подтверждение приемки заказчиком, чтобы удостовериться в удовлетворительном функционировании системы.

Преимущества нового подхода для реализации витрины

Изначально реализация загрузки данных эквайринга в ядро планировалась силами специально выделенной команды, которая бы занималась исключительно формированием ядра данных. После завершения этих работ наша команда приступила бы к созданию витрины. Однако, после детального анализа сроков и ресурсов, мы пришли к выводу, что более эффективным будет выделение эквайринга в отдельный «минидомен» и разработка всего продукта (ядро + витрина) силами одной команды.

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

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

Ускорение разработки: благодаря единому владению процессом от начала до конца, мы смогли быстрее реагировать на изменения и адаптировать наши решения. Это также способствовало сокращению времени на отладку и тестирование.

Разработка больших хранилищ, как запуск ракет

Разработка ядра

Разработка загрузки ядра хранилища включала в себя несколько ключевых этапов: проектирование и согласование модели данных для эквайринга, разработку потоков загрузки для слоев RDV, IDL и аксессоров BDM.

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

В течение четырех месяцев наша команда интенсивно работала над созданием около 50 потоков данных. Каждый из этих потоков был тщательно спроектирован и реализован для обеспечения надежной и эффективной загрузки данных.

На момент проведения финального ПСИ в части ядра, работы по развертыванию промышленного кластера еще не были завершены. Это обстоятельство вынудило нас отложить работы по отладке потоков на более поздние сроки и приступить к разработке витрины данных.

Как это часто бывает в космических миссиях, на пути к финальному ПСИ возникли неожиданные трудности. Работы по развертыванию промышленного кластера еще не были завершены. Из-за затянувшихся сроков развертывания промышленного кластера мы начали терять необходимую для витрины глубину истории источников. Чтобы не допустить потери важных данных нам пришлось переливать их из Legacy хранилища. Этот шаг был необходим для обеспечения полноты данных и их корректного анализа в новой витрине.

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

Разработка витрины

Разработка витрины включает несколько ключевых шагов:

Анализ требований и проектирование:
На момент начала работ по витрине весь анализ требований по витрине был уже завершен, здесь ключевую роль сыграл тот фактор, что команда тщательно проработала требования на этапе реализации детальных слоев.
Создание ETL-процессов:
Следующим этапом было создание ETL-процессов для загрузки данных в витрину. Мы использовали подходы разработки, которые уже испробовали для слоев RDV и IDL.
Отладка и тестирование:
Из-за отсутствия промышленного кластера нам пришлось подготавливать данные источников на среде препрод за отдельно взятый отчетный период. Туда же мы перенесли данные эталонов и выполнили подробную сверку по каждому атрибуту витрины. Когда данные сошлись с эталоном в ноль, мы поняли, что весь наш код, включая код ядра, полностью готов.

Новые испытания и успех

Разработка витрины, включая тестирование и отладку, заняла всего три месяца. Мы уже были готовы праздновать победу, когда неожиданно выяснилось, что проблем у продакшн-среды оказалось больше, чем мы ожидали.

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

Чтобы преодолеть эти трудности, нам потребовалась новая навигация и новые тактические решения:

Формирование рабочей группы: мы создали своего рода кризисный штаб, куда вошли команды сопровождения, разработки фреймворка, разработчики витрины и бизнес-заказчика. Это позволило оперативно решать возникающие проблемы и координировать усилия всех участников процесса.
Разработка мастер-потоков: мы разработали мастер-потоки, которые позволяли выполнять скоординированную загрузку консистентных данных. Это решение значительно снизило влияние человеческого фактора и повысило надежность загрузок.
Система проверок загрузки источников: мы создали систему проверок загрузки источников, которая впоследствии стала основой для контроля качества данных витрины. Это позволило оперативно выявлять и устранять проблемы с загрузкой данных, обеспечивая высокую степень консистентности и достоверности данных.

Заключение

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

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

Первая ракета в космосе или Миграция витрины эквайринг на Arenadata DB