Привет, сегодня я расскажу о том, как наша команда строила платформу обработки и хранения данных для обучения GenAI-моделей в Сбере, и как мы выросли до 70 ПБ сырых данных. Меня зовут Александр, я работаю в Сбере и два года занимался развитием этой платформы.

Что такое GenAI

GenAI — это генеративный искусственный интеллект, который способен создавать новый контент по определённому запросу. Яркими представителями GenAI являются большие языковые модели: нашумевший ChatGPT от OpenAI, китайский DeepSeek, а также российские GigaChat и YandexGPT. Также можно выделить модели для синтеза изображений, например, Kandinsky и Midjourney. Для нас, как инженеров по данным, важное, что эти модели потребляют петабайты данных (через триллионы токенов или миллиарды картинок), которые надо где-то хранить, как-то обрабатывать и отдавать пользователям.

Платформа данных

Что такое платформа данных на сегодня:

• В первую очередь данные. Прирост сырья примерно 5 ПБ в месяц в S3-совместимом хранилище. И темпы продолжают расти.

• Кластер вычислительных ресурсов: суммарно 10 000 ядер и 70 ТБ RAM.

• Инструменты для обработки данных: даём пользователям и сами используем Jupyter Notebook, в качестве аналитического движка используем Apache Spark для загрузки и обработки данных, и Trino в качестве движка для adhoc-аналитики.

• BI-инструменты поверх параметров данных (Metabase, Superset).

• Много разного open-source’а, например, оркестратор Apache Airflow, структурированный формат данных Apache Iceberg.

Принцип действия

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

Можно выделить два основных типа пользователей платформы:

• команды, которые отвечают за обучение GenAI-моделей;

• команда поиска и команда диалоговых агентов (вопросно-ответные системы).

Какие задачи мы решаем?

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

Что хранится в хранилище

Если сырые данные внутри хранилища разбить по типам или модальностям, то можно выделить текст, видео и изображения. А если смотреть на сырые данные с точки зрения форматов, то в хранилище лежат WARC-архивы, видео и много чего другого, например, документы и книги в PDF.

Пару слов про WARC: этот формат специально разработан для хранения разнородных типов данных. Он строковый, информация лежит в виде записей с набором текстовых заголовков и блока данных внутри одного файла. Файлы нарезаются фрагментами по 1 ГБ. Мы обрабатываем этот формат с помощью pyspark и специальных библиотек (например, warcio).

Форматы архивирования и упаковки данных, такие как WARC, Tar и Zip, создают неудобства для пользователей вследствие своей разнородности, поэтому нужен единый подход к работе с данными. Мы последовательно развивали нашу инфраструктуру обработки, и в итоге пришли к использованию архитектуры Data Lakehouse. Рассмотрим её структуру:

• Самый нижний слой представляет собой систему хранения сырых данных, для которой обычно выбирают решения наподобие объектного хранилища Amazon S3, либо распределённую файловую систему Hadoop Distributed File System (HDFS). В нашем случае это S3-совместимое хранилище.

• Следующий уровень предназначен для организации формата хранимых данных. Мы используем эффективный колоночный Apache Parquet, альтернативой которому является ORC (и не только). Оба формата оптимизированы для высокоскоростного анализа больших объёмов структурированных данных. Мы выбрали Parquet, потому что это, фактически, стандарт хранения данных. Он поддерживает кодирование, сжатие и параллельную обработку данных за счёт разделения файлов с данными на специальные row groups (по умолчанию 128 МБ).

• Слой, определяющий специфику архитектуры Data Lakehouse, представлен слоем метаданных и управления версиями таблиц. Здесь ключевым компонентом выступает Apache Iceberg — современный инструмент, заменяющий традиционный Hive Metastore и обеспечивающий поддержку транзакций, управление версиями и эффективную работу с большими наборами данных. В качестве альтернатив рассматривают Apache Hudi и Delta Lake от Databricks. Apache Iceberg содержит метаданные (например, статистику файлов, операция count(*) выполняется за константное время), поддерживает ACID-транзакции и изменение схемы данных без перезаписывания реальных данных в S3. На Хабре есть неплохие статьи, в которых глубоко рассмотрено внутреннее устройство Parquet и Iceberg.

• Верхний слой занят аналитическими движками: мы предпочли Apache Spark, зарекомендовавший себя эффективный инструмент для масштабируемого анализа и преобразования данных.

Такая архитектура сочетает преимущества классического подхода Data Warehouse с гибкостью модели Data Lake, обеспечивая надёжное хранение и быструю обработку больших объёмов разнородных данных.

Эволюция платформы данных

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

Сначала мы занимались только лишь хранением, коллеги в шутку называли нас «флешкой» для данных: мы забирали то, что скачала команда краулинга, перекладывали к себе в бакет из их временного хранилища, а далее команды обучения GenAI моделей забирали то, что им было необходимо. Система не справлялась с потоком: узким местом стал S3, который в некоторых сценариях не выдерживал темпов загрузки и выгрузки данных.

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

Также мы настроили сбор статистики после загрузки, разделили потоки бинарных данных и их параметров (например, jpeg‑картинки и параметры каждой из них), вынесли слой параметров данных в gaussDB (аналог Greenplum, которые поставляется как managed‑сервис от облачного вендора), сделали витрины и подключили BI‑инструменты (Metabase и Superset).

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

В результате пришли к обновленной схеме, на которой синим выделены новые компоненты.

Какие точки роста мы обнаружили:

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

• Высокая нормализация в детальном слое: много «узких» таблиц в S3 и в базе стало трудно поддерживать, а гибкость высокой нормализации оказалась избыточна.

• Отсутствие воронки загрузки: дедупликация съедала часть информации.

• Hive Metastore и поддержка Data Lake: стало трудно менять схему данных (особенно «словили» проблемы c видео).

Во второй версии мы учли все эти особенности:

• Данные стали хранить в виде отдельных файлов, а внутри таблиц оставили только ссылки на S3.

• Таблицы в детальном слое сделали широкими и забыли Data Vault как страшный сон.

• Внедрили Apache Iceberg и убрали базу из процессов загрузки. Получили гибкое изменение схемы и дополнительные фичи вроде Storage Partition Join, который позволяет строить витрины без shuffle-операций.

Используемые технологии

Ядром платформы является аналитический движок Apache Spark, с помощью которого загружаются данные. Платформа находится в облаке, поэтому Kubernetes — наше всё для управления ресурсами. В качестве оркестратора использован Apache Airflow, основной язык программирования — Python, ядро архитектуры — Apache Iceberg и Parquet.

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

В первую очередь мы оптимизировали код. Забавно, что значимое улучшение дала настройка количества параллельных подключений при get-запросах к S3: уменьшение параллельности в каждой отдельной операции практически не привело к снижению пропускной способности системы, при этом стабильность выросла на порядок.

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

В результате доля ошибок недоступности снизилась более чем в 100 раз.

Результаты

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

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

• Переход от мультибакетной архитектуры к мультитенантной, например, для выделения отдельной инфраструктуры под модальность.

• Мультиплатформенность. Намеренно не называл определённых вендоров и платформы, потому что концептуально стремимся строить платформо-независимую архитектуру.

• Тренд развития таких платформ в трансформации в Daas (Data as a Service), где главной задачей становится не просто предоставлять сырые данные, но и предлагать уже очищенные, обогащенные и готовые к использованию датасеты по ad-hoc запросу в режиме реального времени.

• Создание ИИ-платформы: расширение набора инструментов для работы с данными, использование разметки, а также развитие поиска внутри хранилища, причём как по загруженным данным, так и по метаданным из интернета (планируем сделать прокси внутри платформы, чтобы не ходить вовне для поиска интересных нам внешних данных).

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

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