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

В статье расскажем, как инфраструктура выросла с 10 до 70 ПБ, к какой архитектуре мы пришли в итоге и как решали проблемы с нагрузкой на объектное хранилище.

Полная техническая версия этой статьи от нашего разработчика опубликована на Хабре. Здесь — облегчённая версия.

Платформа данных — это инфраструктура, которая принимает сырые данные, собранные из интернета (через команду сбора и их S3‑бакеты), обрабатывает её и передаёт командам обучения моделей.

Масштаб системы определяется объёмами GenAI: данные хранятся в S3-совместимом объектном хранилище, и их количество растёт в среднем на 5 ПБ в месяц. Чтобы переваривать такой поток, мы развернули вычислительный кластер из 10 000 ядер и 70 ТБ оперативной памяти.

Для работы с данными мы собрали следующий технологический стек:

С помощью этих инструментов мы выстроили конвейер, который превращает разрозненные файлы из сети в упорядоченные датасеты.

Процесс начинается с команды сбора. Инженеры загружают информацию из интернета и складывают её в S3-бакеты (облачные контейнеры для объектов). Затем мы забираем эти файлы и переносим в свои бакеты сырого слоя.

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

В хранилище поступают тексты, изображения, видео, PDF-документы и книги. Веб-контент приходит в формате WARC. Это стандарт архивации интернета, где записи содержат текстовые заголовки и блоки данных. Файлы нарезаются фрагментами по 1 ГБ, которые мы обрабатываем через PySpark и библиотеку warcio.

Однако просто настроить потоки данных оказалось недостаточно. Мы столкнулись с тем, что зоопарк форматов (WARC, Tar, Zip) усложнял жизнь инженерам. Чтобы навести порядок, нам потребовался фундаментальный архитектурный сдвиг.

Нам был нужен единый стандарт работы с данными, поэтому мы пришли к концепции Data Lakehouse. Она объединяет структурность классических хранилищ (Data Warehouse) и гибкость озёр данных (Data Lake).

Архитектура платформы состоит из четырёх уровней:

• Система хранения. Фундамент платформы — S3-совместимое объектное хранилище.
• Формат хранения. Мы выбрали Apache Parquet. Этот колоночный формат оптимизирован для аналитики: он эффективно сжимает данные и поддерживает параллельную обработку. Файлы внутри делятся на группы строк (row groups) — блоки по 128 МБ по умолчанию.
• Метаданные и версионирование. Ключевой компонент здесь — Apache Iceberg. Он хранит статистику файлов и поддерживает ACID-транзакции (атомарность, согласованность, изоляция, долговечность), гарантируя надёжность операций. Iceberg позволяет менять схему таблиц без перезаписи файлов, а подсчёт записей выполняется за константное время (по метаданным, без полного сканирования данных) благодаря встроенной статистике.
• Аналитические движки. На верхнем уровне работают Apache Spark для тяжёлой обработки и Trino для быстрых SQL-запросов.

В этой схеме S3 выступает центральным элементом: на нём лежат все слои файловых данных (raw/подготовленные и т. п.). Именно эта зависимость стала главным вызовом при масштабировании нагрузки.

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

На старте мы работали в режиме простого хранилища. Мы забирали то, что скачала команда сбора, и перекладывали в свой бакет, откуда данные забирали ML-инженеры. Система работала как обычный накопитель, но быстро перестала справляться. Узким местом стал S3: сервис не выдерживал интенсивности одновременной загрузки и выгрузки.

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

Параллельно настроили сбор статистики. Потоки разделили: «тяжёлые» бинарные файлы, например изображения JPEG, лежат в объектном хранилище, а их метаданные и характеристики — в базе данных gaussDB. Это аналог Greenplum, который облачный провайдер предоставляет как управляемый сервис. Сверху подключили BI-инструменты для визуализации метрик.

Data Lake с базой данных внутри для получения ACID-свойств. БД работала в ETL-процессе загрузки и при выгрузке данных для фильтрации.

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

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

Поскольку хранилище стало узким горлышком системы, с ростом активности пользователей мы начали получать ошибки 503 Service Unavailable. Этот код ответа означал, что сервис перегружен и не может обработать запрос.

Анализ показал, что мы достигли лимитов провайдера сразу по трём параметрам: ширине канала, количеству параллельных подключений и числу транзакций в секунду (TPS).

Мы решали эту проблему в два этапа:

Решение проблем с хранилищем и оптимизация процессов позволили нам выйти на стабильную загрузку более 5 ПБ данных в месяц. Система автоматически раскладывает файлы по слоям, обогащает их метаданными и проводит дополнительную обработку. При этом мы добились полной изоляции: операции загрузки и «тяжёлой» обработки больше не влияют на доступность данных, поэтому команды обучения могут выгружать выборки в любой момент.

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

Использование управляемых облачных сервисов позволило нам построить эту масштабную систему минимальными ресурсами. Первую версию хранилища создавала команда всего из трёх человек — и за два года эта инфраструктура выросла с 10 до 70 ПБ.