Почему тормозят большие отчёты: Ozon Tech разобрал архитектуру аналитических выгрузок
В кейсе Ozon Tech сравнили подходы к выдаче больших аналитических отчётов. Что учитывать при развитии собственной аналитики магазина.
Содержание статьи
28 сентября 2026 года Ozon Tech опубликовал технический разбор выдачи больших аналитических наборов через HTTP. Автор сравнил несколько вариантов хранения и подготовки данных на экспериментальном стенде. Для команды собственной аналитики магазина это полезный пример: ускорение отчёта начинается с понимания того, какие сведения пользователь запрашивает чаще всего и когда они становятся окончательными.
Почему одной аналитической базы бывает недостаточно
В статье объясняется различие между обработкой больших объёмов истории и обслуживанием множества одновременных запросов. Рассмотрены отдельное хранение часто запрашиваемого периода и кеширование готовых отчётов. Среди примеров есть детализация начислений продавцу за фиксированный период.
Опубликованные сравнения получены на локальном тестовом стенде. Автор прямо ограничивает их применимость к промышленной среде. Поэтому нельзя переносить его показатели скорости на кабинет Ozon или обещать магазину такое же ускорение после смены базы. Это архитектурный разбор, а не анонс новой производительности Seller API.
Сначала разделите задачи пользователей
Руководителю аналитики полезно выписать три вида обращений: короткую ежедневную сводку, подробную выгрузку выбранного периода и исследование всей истории. Эти задачи отличаются объёмом, частотой и допустимым ожиданием. Объединение их в одну кнопку с одинаковой обработкой скрывает причину задержек.
Проверьте фактические запросы своей команды: какие фильтры повторяются, кто запускает тяжёлые отчёты одновременно, насколько часто нужны старые периоды. Решение должно опираться на эти наблюдения. Отдельное быстрое хранилище не обязательно окупится там, где несколько сотрудников скачивают один небольшой файл раз в месяц.
Продумайте срок актуальности готового файла
Готовый отчёт можно использовать повторно только с понятным правилом обновления. В самом кейсе отдельно обсуждаются ситуации, когда файл нужно пересоздать либо его нет в кеше. Для магазина важно заранее решить, кто увидит исправленную версию и как она будет отличаться от ранее скачанной.
В своём проекте фиксируйте период, набор фильтров, время подготовки и версию данных. Если задним числом пришло уточнение начисления, один и тот же заголовок файла не должен скрывать разные итоги. Пользователю нужен понятный признак актуальности, иначе техническое ускорение создаст новый источник расхождений в управленческих таблицах.
Проверяйте всю цепочку, включая исключения
Приёмку проводите на объёме, похожем на рабочий: большой магазин и маленький, новый период и длинный архив, несколько одновременных запросов. Отдельно проверьте недоступность промежуточного хранилища и отсутствие готового файла. Это рекомендации редакции для собственной системы; нагружать чужую площадку без разрешения не требуется.
Итогом должен стать воспроизводимый порядок получения полного и актуального отчёта. Подключение внешнего источника остаётся отдельной задачей: для Ozon важны контроль ограничений частоты API и полнота чтения списков. Они не заменяют архитектуру внутренней выдачи аналитики, но защищают её исходные данные.
Материал отражает сведения на указанную дату. Правила и условия работы площадок могут измениться. Редакционные принципы