Привет, Хабр! Меня зовут Максим Солопин, в Росбанке я работаю архитектором корпоративного хранилища данных. В этом посте я расскажу о том, как мы переезжали из data lake, куда ежедневно сваливались все сырые данные, в удобную систему на основе Greenplum. А по дороге немного затрону развитие моделей корпоративных хранилищ данных.
К началу проекта в банке было целых 3 КХД, 5 песочниц, 7 BI серверов и 0 golden source, на основе которых несколько лет развивался data lake. Загрузки там дублировались, и чтобы избежать этого, мы решили брать сырые данные из Hadoop.
Но это лишь принесло новые проблемы. Данные грузились медленно, подтягивались не из всех источников в банке (сейчас их более 50). Самописный фреймворк загрузки был сырым, нужен был мониторинг, поддержка и, соответственно, огромное количество ресурсов на это всё и также на разработку.
Затем в начала 2021 года мы решили создать свой первый Golden Source на основе Greenplum. Работала над миграцией наша core-команда, развивающая ритейл-песочницу банка. Greenplum мы выбрали по нескольким причинам: масштабируемость, скорость, умеренная стоимость, совместимость с Hadoop, возможность подключить максимально разнообразные источники в рамках универсальной модели данных.
С моделей данных я и начну подробный рассказ.
Как устроены корпоративные хранилища данных
Классическим подходом к хранению данных в компании считается концепция Data Warehouse (DWH), история которой началась в далеком 1990 году, когда американский ученый Билл Инмон опубликовал книгу «Building the Data Warehouse». Инмон выделял четыре ключевых свойства DWH:
Subject-oriented – все элементы данных в базе, относящиеся к одному и тому же реальному событию или объекту, связаны друг с другом; при этом хранилище данных содержит информацию о конкретном предмете, таком как продукт, клиент, продажи и т.д.
Time-variant – изменения данных в базе отслеживаются и записываются, чтобы можно было создавать отчеты по изменениям с течением времени.
Non-volatile – данные в базе никогда не перезаписываются и не удаляются; после фиксации они становятся статическими, доступными только для чтения и в таком виде сохраняются для будущих отчетов;
Integrated – база содержит данные из большинства или всех операционных приложений организации, и эти данные согласованы.
Несколько иного подхода придерживался оппонент Инмона Ральф Кимбалл и корпорация Microsoft. Они акцентировали внимание на витринах данных, то есть на срезах хранилища данных, представляющих собой массив тематической, узконаправленной информации. Для покупателей такой подход был более привлекательным — продавать витрины с быстрыми и эффектными отчетами легче, чем погружать в сложные процессы создания хранилища.
Создание DWH было более долгим, затратным, и в подходе Инмона витрины появлялись лишь на финальной стадии. Но и подход группы Кимбалла менялся со временем.
DWH работают по методу ETL – Extract, Transform и Load. Это означает, что данные подготавливаются и загружаются в хранилище на регулярной основе, скажем, раз в месяц. Загрузка занимает много времени, и часто на это время хранилище приходится закрывать для использования, что плохо.
Корпоративные хранилища со временем эволюционировали, что привело к появлению концепции Data Lake. Озера данных используют подход ELT – Extract, Load и Transform. Сырые данные сразу же загружаются в хранилище, а затем в фоновом режиме преобразуются и продвигаются от слоя к слою вплоть до последнего слоя витрин данных.
Преимущества Data Lake в том, что здесь нет тяжеловесного этапа подготовки данных и хранилище не нужно закрывать на время обновления. Для финтеха постоянная доступность является критически важной. Кроме того, специалисты по данным и машинному обучению могут использовать данные сразу по мере поступления.
Модель данных в Росбанке
Наша модель данных, основанная на методологии Билла Инмона, была уже обкатана. У нас были выделены основные сущности, такие как клиенты, счета, договора, проводки, балансы и т.д.
Каждая таблица может иметь таблицу-расширение. Например, для таблицы договора расширением может быть таблица-расширение её кредитного договора. В нее уже попадают атрибуты, которые не вписались в таблицу договора. Также у любой таблицы может быть таблица %_property. В нее выносят атрибуты, по которым, например, нужна историчность или не хочется создавать таблицу-расширение, поскольку таких атрибутов мало.
Так организованы потоки данных в нашем хранилище. Поясню некоторые элементы:
STG — слой, содержащий сырые ext-таблицы. Отдельного ELT-потока в GP нет, таблицы только подключаются к Hadoop.
ODS — слой для накопления истории из слоя STG по нужным атрибутам. Используется редко, так как историю сырых данных мы не копим.
DDS — содержит детальные данные по основным сущностям.
EM — содержит витрины с агрегированными показателями базовых сущностей: клиентский портфель, портфель HR, кредитные и депозитные портфели и т.д.
DM — витрины с рассчитанными агрегатами, сложными расчетами атрибутов. Этот слой содержит общие витрины для всех департаментов. Только на его основе далее формируются отчеты. Также есть отдельные DM-слои под конкретные бизнес направления.
DICT – слой справочников.
Справочники могут загружаться вручную, могут наполняться из файлов, могут затягиваться из систем-источников: с MDS, через API и т. д.
Расскажу немного о параллельной работе над двумя хранилищами. Для работы над новым хранилищем мы задействовали команду старого, и ребятам приходилось одновременно поддерживать оба. Бизнес всегда на первом месте, поэтому приоритеты часто менялись, и на новое хранилище временами не хватало рук. Разработку на старом хранилище мы не заморозили, и в итоге у нас несколько расходилась логика с новым; пришлось потратить много ресурсов, чтобы его доделать.
Помогло нам то, что мы позволили активно развивать хранилище любым другим командам разработчиков. Для этого все они должны придерживаться нашей установленной модели данных и стандартов проектирования. И в команде должен быть хотя бы один лидер, который будет эти стандарты валидировать, обучать людей, отвечать на вопросы по архитектуре модели. Несколько раз в неделю эти лидеры собираются на архитектурные митапы, где обсуждают возникающие проблемы и вопросы, задаются новые правила, стандарты и т. д.
Таким образом мы исключили проблемы с большим бэклогом на одной команде.
Оркестрация загрузок
Оркестрация потоков идет в airflow, и для нас это был новый инструмент. Все загрузки Hadoop, которые шли раньше в cron, мы перевели в airflow. Для этого был сделан генератор дагов, который автоматически формирует задачи по загрузке таблиц из источников.
Затем мы сделали такой же генератор для запуска sql-функций на GP. Там зависимости не такие линейные, и выглядит в airflow это уже не так красиво:
Сейчас идет пилот по переходу на Gitlab + Gitlab CI, и в ближайшее время мы перейдем на автоматизацию процесса поставок кода. Пока же весь код в БД попадает только через Bitbucket, в ручном режиме после апрува пулл-реквеста.
Загрузчик реплик в БД
В начале статьи я упоминал наш фреймворк для загрузки данных. Расскажу о нем отдельно. Универсальный загрузчик создает реплики таблиц из БД систем-источников (DB2, Oracle, MSSQL, PostgeSQL, Pervasive), а также актуализирует реплики на указанную дату. Загрузчик обеспечивает накопление истории изменений таблиц в Hadoop в структуре Slow Changing Dimension type 2 (маркировка версий записей полями DT_FROM, DT_TO), причем на неограниченную глубину.
Список входной информации загрузчика выглядит так:
batch-версия — read-only таблицы в системах-источниках, подключение через JDBC);
CDC-версия — файлы данных в виде changelog, полученных в результате работы CDC (в формате JSON, Parquet или ORC);
файлы конфигурации и метаданные (описание таблицы).
А это выходная информация:
таблица-реплика в Hive с возможностью хранения истории изменений;
журналы работы в YARN и в базе метаданных.
Загрузчик поддерживает автоматическую репликацию DDL — изменение структуры таблицы в Hive после изменения DDL на источнике. Для batch-загрузки доступна проверка на дубликаты по ключу с отбрасыванием дублей в reject-таблицу. Для CDC-загрузки возможно игнорирование полных дубликатов во входных данных (если был выполнен CDC-refresh без удаления старых файлов), а также операций Update/Delete по несуществующим ключам.
Загрузчик пока что имеет некоторые ограничения, связанные с загрузкой колонок таблиц, совместимостью и функциональностью для репликации DDL.
Итоги
Миграция первой песочницы прошла успешно. Сейчас на основе новых данных у нас ежедневно рассылается мотивация сотрудникам. К середине года будет завершена полная миграция и параллельно другие команды начинают миграцию остальных хранилищ банка.
Главный урок, который мы получили во время проекта: мы сами должны понимать, что хотим, сами выстраивать нужную архитектуру и модель, а не полагаться на вендоров. И у нас должны быть ресурсы, которые всё это поддерживают.