О чем статья?

В статье Архитектура высоконагруженной платформы Magnit F&R было рассказано о ключевых архитектурных принципах и решениях.

Сегодня хочу поделиться практическим опытом: как в Magnit Tech изменилась концепция Data Lakehouse, где она блестяще сработала — и где подвела.

Я, Алексей Соболеков, лид архитектуры F&R.

И это история о том, как красивая теория сталкивается с физикой доступа к данным.

Классические F&R системы

Большинство современных систем класса Forecast and Replenishment (F&R), использующих машинное обучение (Machine Learning), состоят из стандартных подсистем:

• Интеграция: стандартные ELT-процессы для загрузки, очистки и структурирования данных из внешних систем.

• Прогнозирование: расчёты с применением Data Science и ML для формирования прогнозов спроса.

• Пополнение: ETL/ELT-конвейер, где данные и параметры трансформируются в рекомендации к заказу по сложной бизнес-логике.

• UI: BI-подсистемы для просмотра, анализа и корректировки многомерных данных.

У большинства вендоров каждая подсистема имеет свою базу данных и общается с остальными через API. Такую архитектуру можно назвать «классической». Она проверена временем, но не масштабом.

Для «Магнита» такая архитектура не подошла из-за низкой производительности. Масштаб задачи иллюстрируют требования к пропускной способности.

Требования к мощности Magnit F&R

Каждую ночь система рассчитывает 180 миллиона связок «Товар–Локация–День».

• Ежедневный прирост исходных данных — 1 ТБ

• Система генерирует до 30 ТБ расчётных данных

• Общий объём хранилища — 10 ПБ

Инфраструктура должна обеспечивать пропускную способность порядка 30 ГБ/с, чтобы уложиться в 7-часовое ночное окно для перерасчётов.

«Коробочные» F&R-решения с классической архитектурой и выделенными БД такой производительности обеспечить не могут. 

Почему Data Lakehouse?

Нам была критически важна минимизация избыточности и дублирования данных между модулями. Наше хранилище должно было быть:

• Единым для больших данных прогнозирования и транзакционных данных пополнения.

• Масштабируемым для обеспечения производительности.

• Экономически эффективным в облачной инфраструктуре.

Взглянем на классическую схему эволюции хранилищ данных

Концепция Data Lakehouse объединяет гибкость Data Lake и управляемость Data Warehouse, что казалось идеальным решением наших задач.

Был проведен тщательный анализ технологий, соответствующих концепции Data Lakehouse по ключевым критериям:

• полностью развернуто в облачной инфраструктуре,

• базируется только на Open Source технологиях (нет привязки ни к одному из производителей),

• масштабируется горизонтально,

• поддерживает ANSI SQL и ACID,

• поддержка версионности данных,

• эффективно обрабатывает данные и в пакетном, и в интерактивном режимах.

В результате остановились на стеке: S3 + Apache Iceberg + Trino + PostgreSQL.

Теоретически всё выглядело безупречно:

• S3 + Parquet: масштабируемость и низкая стоимость хранения.

• Apache Iceberg: ACID, версионирование и упрощённое управление большими таблицами.

• Trino — единый SQL-движок, который позволяет UI обращаться напрямую ко всем данным.

• PostgreSQL — для параметров и небольших CRUD-операций.

Ожидалось, что этого хватит, чтобы обойтись без выделенной БД для витрин UI и даст возможность строить аналитические отчёты и пользовательские интерфейсы непосредственно на данных в Lakehouse.

Меньше ETL — меньше сложностей, дублирования, выше производительность и ниже стоимость. Всё казалось логичным и технологически элегантным. Но, как это часто бывает, реальность внесла свои коррективы.

Что пошло не так?

Первые тесты были многообещающими. Trino стабильно работал с Iceberg, SQL-запросы выполнялись и горизонтально масштабировались. Немного смущал неидеальный отклик, но планировалось оптимизировать его позже с помощью витрин и кеширования через Alluxio.

Проблемы начались с приходом реальных пользователей. Интерактивный интерфейс требовал мгновенного отклика — десятки коротких запросов к одной таблице, фильтрация, графика, сортировки, корректировки.

И здесь Trino показал свою обратную сторону. Среднее время отклика для пользовательских запросов выросло с 2–3 до 20–30 секунд, а иногда и больше.

Причина крылась в самой природе Lakehouse:

• В Iceberg нет индексов. Обращение к большим таблицам (500 млн. строк) занимало секунды.

• Trino при каждом запросе обращается к метаданным Iceberg и в S3. Задержки в миллисекунды накапливались и превращались в секунды.

• Кэширование результатов не спасало при высоком разнообразии запросов.

Для пакетных расчётов в модулях Прогноза и Пополнения — это терпимо. Для конечных пользователей, работающих с UI — фатально. Наши нефункциональные требования предписывали среднее время отклика UI не более 1 секунды. Архитектура Lakehouse не могла уложиться даже в 3 секунды.

Как решили проблему?

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

В качестве кандидата для сравнения выбрали ClickHouse — по следующим критериям:

• горизонтальное масштабирование и высокая устойчивость под нагрузкой;

• выдающаяся скорость выборки и агрегации данных;

• подтверждённый опыт промышленного использования в системах с сотнями одновременных пользователей.

Цель нагрузочного тестирования — смоделировать реальную работу UI, где десятки пользователей одновременно выполняют SQL-запросы к витрине плана пополнения, объемом 500 млн. строк, со случайными параметрами фильтрации и джойнами справочников.

Результаты говорят сами за себя:

• Trino при 60–120 пользователях показывал задержку >10 секунд, а при 150 — >25 секунд. Кэширование через Alluxio ускоряло повторные идентичные запросы до 1 секунды, но не помогало при уникальных.

• ClickHouse удерживал время отклика менее 0.05 секунды вплоть до сотен пользователей и начинал замедляться лишь при тысячах.

Разница — на три порядка. Для интерактивного интерфейса — это разница между «работает» и «не работает».

Добавили в архитектуру слой витрин UI на ClickHouse и разработали ETL на Spark для их предрасчёта. Так система эволюционировала от чистого Lakehouse к гибридной модели Data Lake + OLAP.

Что изменилось после добавления ClickHouse

UI стал моментально отзывчивым. Время отображения страниц сократилось с десятков секунд до долей секунды. Пользователи сразу ощутили разницу.

Trino остался «источником истины» и основным источником данных для расчётов, а ClickHouse взял на себя оперативную аналитику и быстрые выборки.

Выводы

Эта история не о том, что связка S3/Iceberg/Trino плоха, а ClickHouse хорош. Она о том, что любой инструмент нужно выбирать под конкретную задачу, а не под тренд.

Data Lakehouse — хорошо подходит для:

• Консолидации и хранения огромных объёмов данных.

• Сквозных ML-пайплайнов.

• Пакетной обработки и ETL.

Но он не предназначен для сценариев, где требуется:

• Скорость реакции интерфейса в миллисекундах.

• Множество коротких запросов с произвольной фильтрацией к большим таблицам.

Внедрение ClickHouse потребовало не только технических, но и организационных изменений. Мы расширили использование паттерна CQRS, выделив отдельный слой для быстрых пользовательских запросов, и добавили дополнительный ETL-процесс для подготовки данных. Потоки пришлось переработать: ClickHouse отлично справляется с аналитическими выборками, но не любит сложные JOIN-ы на лету.

Зато мы перестали бороться с физикой доступа к данным в S3 и фактически объединили лучшее из двух миров — надёжное хранилище Lakehouse и молниеносные витрины ClickHouse.

Сегодня в Magnit F&R связка S3/Iceberg/Trino остаётся основой для хранения и пакетной обработки, а ClickHouse — для интерактивных пользовательских сценариев.

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