В мире данных и аналитики, где каждый день генерируются огромные объемы информации, создание единой платформы для работы с данными становится неотъемлемой частью успешной стратегии бизнеса. Мы команда РСХБ.Цифра, в которой я, Кристина Проскурина, руковожу управлением бизнес-анализа данных, а Алексей Кошевой, руководитель отдела развития витрин данных «РСХБ-Интех», руководит разработкой аналитической отчетности и платформы по исследованию данных. В этой статье мы расскажем, как наша команда разработала единую песочницу для аналитиков, которая объединила все инструменты и ресурсы в одном месте, обеспечивая эффективность, удобство и возможность совместной работы.
Почему мы вообще решили создать песочницу? У нас в банке раньше было много разрозненных песочниц — у каждого самостоятельного бизнес-подразделения был свой сервер, а иногда и два-три сервера, в которых создавались пользовательские витрины данных. Одни и те же данные загружались несколько раз в разные песочницы. Главная книга — это хороший пример, она нужна всем. Главную книгу из хранилища данных каждое подразделение грузило в свою песочницу, таким образом мы получали копию 10 Главных Книг в разных песочницах. Песочницы были на поддержке, при этом полного понимания, какие данные хранятся в разных песочницах не было.
Важно и то, что песочницы еще были на разных СУБД — Oracle, MS SQL. Но у нас были указания Минцифры и большие планы по импортозамещению, поэтому мы решили сделать единую песочницу данных на импортозамещенном ПО.
Мы стали выбирать решение, которое помогло бы справиться с нашей задачей. Либо Postgres, либо GreenPlum от Arenadata. Мы остановили выбор на GreenPlum. Перед нами стоял план в достаточно короткие сроки мигрировать более 10000 витрин, а также переписать пользовательские процедуры загрузки и обработки данных. При этом по локальным песочницам отсутствовала какая-либо документация.
Сейчас у нас есть свой собственный ETL фреймворк, который написан на базе airflow и python. Отдельный кластер Greenplum, на котором выделено 100 ТБ, но мы будем выделять больше ресурсов, так как понимаем наш рост в данных. На данный момент это 300 пользователей, но ожидаем, что это не предел. В планах до конца 2025 года завершить миграцию пользовательских песочниц, половина работы уже сделана.
Перед тем как приступить к работе, мы сформулировали понятие системных и несистемных данных. Это помогло нам в дальнейшем. У нас многие пользователи хотели грузить данные из систем источников без ограничения. Мы определили все, что пользователям необходимо из корпоративного и централизованного хранилища данных (у нас два хранилища), данные из Озера данных и других небольших источников мы называем системными источниками. Данные из них грузим и контролируем мы. Все, что пользователь использует для себя (выгрузки, файлы, csv), он может грузить самостоятельно.
Итак, что было сделано? Мы разделили GreenPlum на отдельные выделенные области (схемы для каждого бизнес-подразделения), в которых бизнес может создавать витрины, загружать данные из локальных файлов, писать процедуры. Мы выделили схему, область GL, в которой хранится и обновляется информация из систем источников, таких, как два хранилища и Озеро.
Как мы влились в аналитический контур РСХБ в целом? DRP-песочница заняла место рядом с Озером данных и хранилищем. Сейчас мы загружаем в DRP базовый слой и почти весь бизнес-слой хранилища данных, из Озера забираем точечно витрины для определенных задач. В планах интеграция с ODS слоем КХД.
С внедрением DRP у пользователей иногда возникают задачи по визуализации данных и построении дашбордов и отчетов самостоятельно. Для этого у нас есть интеграция с BI платформой Visiology. За нее отвечает отдельная команда, которая всегда готова проконсультировать, как создать свой дашборд или отчет. Для построения моделей данных и исследования данных, у нас есть интеграция с платформой искусственного интеллекта ( RAISA). Она доступна любым бизнес-пользователям внутри компании.
Какие сложности у нас возникли при миграции в песочницу?
Самая большая проблема — у нас отсутствовала какая-либо документация по всем песочницам, которые разрабатывал бизнес за несколько лет. За время работы над песочницами сменилась не одна команда. Информации о том, что было сделано и для чего это было сделано, не было в формализованном виде.
Часть проблем были связаны с большим количеством объектов для миграции — как витрин, так и процедур обработки данных. Мы столкнулись с желанием бизнеса переносить все так, как было. Коллег можем понять, но GP обязывал применять другие подходы. Кроме того, пришлось бороться с желанием бизнеса самостоятельно загружать абсолютно любые данные самостоятельно.
Первая проблема, которую мы решали, — это сбор бизнес-требований для организации работ. Когда мы стали подходить к этой задаче, мы поняли, что разбить стримы только по бизнес-подразделению не получится. Где-то были небольшие песочницы, которые мы смогли просто разбить по бизнес-подразделениям. В некоторых бизнес-подразделениях песочницы были настолько сложные и массивные по данным и процессам, что нам пришлось делить их по функциональным областям и приоритетам. И даже сейчас в одной из песочниц мы видим только середину айсберга. Где-то мы собирали требования по подразделениям, где-то отталкивались от функциональных областей. Это позволило нам сформировать бизнес-требования, план, по которому мы сейчас идем.
Самый частый запрос от бизнеса звучал так: «Перенесите мне все централизованное хранилище данных», а это большое количество объектов. Мы старались конкретизировать этот список до конкретных таблиц, и в итоге после некоторого количества смогли прийти к компромиссу. Мы сделали зеркало корпоративного хранилища данных и перенесли часть объектов из старого хранилища. На данный момент у бизнеса есть возможность использовать их в работе.
Как интегрироваться с источниками? Мы рассматривали разные варианты интеграции — Python, Spark, PXF, ФормИТ. Собственно c ETL- инструментами у нас возникли некоторые трудности, особенно при первичной реализации фреймворка загрузки данных, когда совместно с архитекторами бизнес сильно настаивал на определенном нейминге использования спецсимволов в метатаблицах. Коллеги использовали доллар. Во время использования доллара при загрузке экранировались данные, из-за этого загрузки падали. Пришлось дописать на Python обработчик для gpload. По итогу тестов скорость загрузки данных нас не устроила.
Начали думать над Spark. Spark потребовал от нас большое количество серверов для того, чтобы развернуть систему. Остановились на PXF, и сейчас PXF работает достаточно хорошо: загружает более 2500 объектов. Плюс для тех систем, в которых невозможно было подключиться к PXF (например для серверов на старых виндовых машинах, где TLS сейчас первый, а PXF с ним работать не умеет), используем Python plus NFS.
Разработка движка загрузки шла в два этапа. Был разработан первый движок на основании первоначальных техтребований. Требования росли по мере появления функциональности, в какой-то момент приняли решение полностью его переписать. Он был достаточно неповоротливым с малым количеством функциональности, умел только загружать данные и выделять инкремент.
Одна из больших проблем, которая у нас возникла при первоначальном внедрении, — это ролевая модель. Ролевую модель необходимо было разбивать на несколько частей. Первая — это непосредственный доступ данных на стороне GreenPlum. C этим справились достаточно легко. GreenPlum очень функционален в этом плане, можно гибко настроить любой доступ. Но тут возникла проблема разграничения по функциональным областям, она решалась исключительно путем переговоров.
С Airflow была более тяжелая ситуация. Сейчас AirFlow выступает в роли оркестратора, он разделен на несколько нод. Основная функция — загрузка данных и обработка всего фреймворка, а для того, чтобы разделить пользовательские даги, мы обратились к платформе RAISA, потому что это готовое решение. Платформа RAISA в своем окружении имеет свой собственный Airflow для пользователей. Поэтому мы решили все пользовательские источники передать в RAISA — и теперь пользователи могут с ними работать самостоятельно. Все системные у нас.
Другая проблема — могла возникнуть неконтролируемая нагрузка на GreenPlum. Мы настроили работу так, чтобы коллеги из бизнеса сами не могли загружать данные. Мы ввели квотирование пространства на пользовательские схемы. У тех бизнес-подразделений, которые на текущих песочницах работают с большими объемами данных до 30 ТБ, мы выделили те же объемы. Остальным объемы ограничили значительно.
Какие результаты?
Сейчас у нас полностью работоспособная система. Основные работы по движку завершили. Используем свой собственный движок для загрузки системных данных, для пользовательских данных используем движок от платформы RAISA. Мигрируем данные из текущих песочниц. Ежедневно обновляем 2500 + объектов. Организуем новые интеграции.
Ровно полгода занял процесс от разработки до внедрения с учетом DevOps. В июне 2024 года мы решили, что будем переписывать движок. В декабре у нас в расписание встали на загрузку первые 200 объектов. По движку основные работы завершены.
По загрузке несистемных данных мы сделали отдельное решение на базе платформы ИИ. Первые бизнес-подразделения начали его использовать для небольших объёмов. Смотрим сейчас в тестировании большие CSV, которые по 10 гб занимают и больше.
Переносим песочницы. Архивные прогрузки практически везде уже закончились. 2,5 тысячи объектов из трех систем-источников обновляются в течение 1 часа и 40 минут.
Главные итоги — созданы единое место исследования и анализа данных, а также подготовка ad-hoc запросов. Все объекты, загруженные в систему, описаны в бизнес-глоссарии и актуализированы на Confluence.
Мы практически полностью ушли от маленьких песочниц, которые было сложно сопровождать. Сейчас каждый бизнес может удобно использовать данные, которые раньше приходилось запрашивать у коллег в виде файлов или загружать из исходных систем. Добавление новых объектов из системных источников происходит практически по письму. Бизнес сам может открывать доступ к этим данным. Это единственная система, которую нужно сопровождать и развивать.
Один из ключевых моментов успеха проекта — состав команды. В проекте приняли участие product-owner, технический product-owner, руководитель проекта, бизнес-аналитик, системный аналитик и несколько разработчиков.
