Как «Магнит» сократил расчёт прогноза с десяти до четырёх часов
Коротко
- По данным Magnit Tech, с апреля 2024 по январь 2026 расчётное окно платформы прогнозирования и пополнения сократилось с десяти до четырёх часов.
- Речь об ускорении вычислений: более точный прогноз или рост продаж эти данные не доказывают.
- Разбираем, что из этого полезно российскому интернет-магазину, которому нужно успеть сформировать заказ поставщику. Источник кейса.
Начните со времени отправки заказа
Прогноз должен быть готов до того, как магазин отправит заказ поставщику. Поэтому наш главный вопрос к этому кейсу: сколько времени остаётся между готовностью исходных данных и крайним сроком заказа? Название модели само по себе на него не отвечает.
Учебный расчёт редакции, не данные «Магнита». Предположим, данные готовы в 23:00, заказ надо отправить к 06:00, а проверку и передачу заказа мы для простоты пока не учитываем. При расчёте длительностью 10 часов результат будет готов в 09:00: опоздание на 3 часа. При длительности 4 часа — в 03:00: запас 3 часа. Изменились только затраты времени, не качество модели.
Формула для своего магазина: запас времени = срок отправки заказа − время готовности данных − длительность расчёта − проверка и передача результата.
- Определите, сколько времени проходит от готовности данных до срока заказа.
- Вычтите длительность расчёта, проверки и передачи результата.
- При отрицательном запасе найдите задержку. При положительном — сравните запас со временем повторного запуска после сбоя.
Это расчёт времени, не окупаемости проекта.
Что именно ускорили в «Магните»
В корпоративном описании речь о федеральной розничной сети: контур прогнозирования масштабировали на все действующие 46 распределительных центров к январю 2026. Расчёты должны завершаться до начала следующего операционного дня. Для этого периода компания сообщает следующие результаты. Описание F&R.
| Показатель | Что сообщает компания | Чего из этого не следует |
|---|---|---|
| Расчётное окно | С 10 до 4 часов, апрель 2024 — январь 2026. Источник | Ошибка прогноза уменьшилась в той же пропорции |
| Потребление ресурсов | Снизилось в 4 раза; состав ресурсов и методику сравнения автор не раскрывает. Источник | Общая стоимость владения сократилась вчетверо |
| Облачные расходы | Минус 25% в сопоставимом контуре в отдельной FinOps-работе: Kubernetes, бэкапы, режимы потребления облака. Источник | Все эти деньги сэкономлены именно ускорением прогноза |
В этой таблице время — длительность вычислительного окна, ресурсы — отдельное заявление автора, деньги — результат отдельной инфраструктурной работы. Складывать их в общий «эффект ИИ» нельзя. Описание результатов.
Как прогноз связан с пополнением
Ниже — наша упрощённая последовательность по описанию компании, не схема конкретных соединений в её системе. Автор перечисляет технологии по блокам, но не раскрывает полный путь каждой записи. Архитектура F&R.
- Источники → платформа данных. Данные поступают из корпоративных систем; компания перечисляет потоковую и пакетную обработку и озеро данных. В стеке платформы данных названы SparkSQL и другие инструменты. Источник.
- Подготовленные данные → прогноз спроса. В ML-части описаны градиентный бустинг, модели Кростона для редких продаж и собственные библиотеки. Источник.
- Прогноз → расчёт пополнения. В блоке пополнения перечислены Java, Apache Ignite, Kafka, Spark, Trino и Apache Iceberg. Это список компонентов блока, а не доказательство, что любой расчёт последовательно проходит через каждый из них. Источник.
- Пополнение → поставка. По описанию F&R поддерживает процессы от заказа поставщику до поставки на полку. Источник.
Разбирая этот проект, проверяйте готовность заказа к сроку. Сокращение часов расчёта не используйте как довод в пользу другого проекта. За объяснением рекомендаций покупателю — в словарь.
Какие оптимизации стоит обсудить с аналитиком
Компания связывает ускорение с рефакторингом Spark-задач, настройкой партиционирования и shuffle, обновлением Spark, Java и Ignite, настройкой Ignite-кластера и динамическим распределением ресурсов. Она не публикует вклад каждого изменения по отдельности. Перечень работ.
Проверьте перемещение данных между задачами. В документации Spark shuffle описан как перераспределение данных между разделами, которое требует обмена между исполнителями и может быть дорогим. Поэтому полезный вопрос к вашему расчёту — где тратится время на перенос и перегруппировку данных, а не только на саму модель. Это направление диагностики, не готовый рецепт настроек. Документация Spark.
Не копируйте размер кластера по названию технологии. Ignite распределяет данные по разделам и узлам; выбор ключей и размещения данных влияет на работу распределённой системы. Наш вывод: прежде чем добавлять узлы, выясните, как данные вашей задачи распределены и где они обрабатываются. Сам факт использования Ignite у крупной сети не обосновывает его установку в небольшом магазине. Источник кейса. Документация Ignite.
Отделите настройку вычислений от организации разработки. «Магнит» также описывает отказ от единой платформы в пользу модульных блоков с независимыми релизами: прежний подход связывал команды общим релизным циклом. Это урок о зависимости команд, а не измеренный вклад модульности в сокращение часов. Описание решения.
Когда небольшому магазину такой стек не нужен
Наша рекомендация — не начинать со Spark и Ignite, если текущий расчёт уже укладывается в доступное время с запасом на проверку и перезапуск. В учебном примере выше улучшение оправдано опозданием; в вашем магазине такой проблемы может не быть.
Сначала попросите аналитика разложить время на ожидание выгрузки, подготовку данных, вычисление прогноза, расчёт заказа и передачу результата. Если прогноз готов вовремя, а заказ задерживает ручное согласование, этот кейс не даёт оснований покупать вычислительный кластер. Если задержка именно в обработке, сопоставьте наблюдения с описанными у Spark затратами на shuffle и у Ignite распределением данных. Spark, Ignite.
Для сети с большим числом расчётных задач и команд полезны вопросы о распределении данных и независимых релизах. Небольшому интернет-магазину без такой нагрузки полезнее взять из кейса правило готовности заказа к сроку. Универсального порога по числу товаров или обороту эти источники не дают — мы его не придумываем. Кейс, Spark, Ignite.
Откуда кейс и чего в нём не хватает
Источник результатов — корпоративный техблог Magnit Tech на Хабре. Статья рассказывает о собственных проектах и заканчивается приглашением в команду: у автора есть интерес показать инженерную сложность и привлекательность работодателя. Это публичный рассказ участника проекта, не независимый аудит. Оригинальная статья.
Цена разработки и эксплуатации F&R в рублях не раскрыта. Временные затраты видны по этапам: начало разработки в апреле 2024, масштабирование прогнозирования к январю 2026; функциональное развитие на этом не завершилось. Неудачным исходным решением, по рассказу компании, стала единая платформа с зависимыми релизами. Эти сведения не позволяют рассчитать срок окупаемости для другого бизнеса. Этапы и ограничения.
В описании ускорения нет сопоставимой ошибки прогноза до и после, денежных затрат проекта и протокола замера ресурсов. Поэтому подтверждённое источником обещание узкое: компания сообщает о сокращении времени расчёта. Остальные результаты требуют отдельных данных. Сопоставимость нагрузки и оборудования для исходного и итогового окна автор также не устанавливает. Публичное описание.
Как мы проверяли
Мы сверили публичный рассказ компании с документацией Spark о shuffle и Ignite о распределении данных. Дата проверки указана под заголовком; использованы публичные страницы документации с адресом latest, версии установленного в «Магните» ПО не названы. Тариф здесь неприменим: это разбор внутренней системы по документам, не испытание покупаемого сервиса. Стоимость разработки и эксплуатации в источнике не раскрыта. Описание проекта. Критерии разбора: границы метрик, последовательность от данных к заказу, условия переноса на небольшой магазин. Доступа к системе, исходным данным, логам и счетам компании у нас нет; независимого воспроизведения результата не проводили. Расчёт времени выше — наше упражнение на явно заданных вымышленных входах, не испытание сервисов.
Источники
Все ссылки открыты и сверены 16.10.2026.
- Magnit Tech: корпоративное описание F&R и других проектов. Источник заявленных результатов и этапов внедрения.
- Apache Spark: Shuffle operations. Объяснение вычислительных затрат.
- Apache Ignite: Data Partitioning. Принципы распределения данных, не описание конфигурации «Магнита».