Иногда бизнес-логика выглядит просто: «соберём все данные за период и посчитаем итоговый результат». На практике этот период может оказаться не часом и даже не днём, а несколькими сутками. В одном из моих проектов требовалось построить агрегаты на основе данных, которые могли поступать в течение пяти дней.

В литературе мы встретили концепцию временных окон (Time Windows). По описанию это выглядело именно тем инструментом, который должен решить задачу: определить период ожидания, дождаться всех необходимых данных и получить итоговый агрегат.

Однако при работе с реальными потоками оказалось, что основная сложность заключается вовсе не в выборе размера окна. Главный вопрос оказался другим: существует ли вообще момент, после которого агрегат можно считать завершённым и больше никогда не изменять?

Привет! Меня зовут Михаил Измайлов, я лид по аналитике данных в команде лояльности MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

Дашбордами в современных технологических компаниях уже никого не удивить, однако хорошо структурированную, актуальную и стабильную систему BI-отчетов можно встретить далеко не всегда. 

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

Артефакт нашей сборки — не бинарник, а код вместе с терабайтами рассчитанных таблиц. Рассказываем, как из штатных фич Airflow, Spark и Delta Lake у нас собрался настоящий CI/CD для данных и моделей — с релизами, стейджем и откатами. И почему кнопку «выкатить в прод» жмёт дежурный data scientist, а не инженер данных.

Всем привет. Меня зовут Василий Гуров, я занимаюсь задачами оптимизации в ML Research Lab MAGNIT TECH. В этом материале разберу два промышленных кейса из крупного ритейла – планирование смен сотрудников магазинов и сглаживание нагрузки на распределительные центры.

На поверхности это разные задачи. В первой нужно построить график работы сотрудников по ролям и временным интервалам. Во втором кейсе стоит задача перераспределения логистических потоков так, чтобы снизить пики нагрузки на распределительные центры (РЦ). Но инженерная проблема у них оказалась общей. Прямая time-indexed постановка быстро раздувала модель до сотен тысяч и миллионов бинарных переменных, давала нестабильные рекомендации и плохо укладывалась в SLA.

В этой статье я покажу, как мы решали эту проблему на практике с помощью простого приёма, который должен одним из первых рассматриваться при решении таких объёмных задач. Ключевым оказалось не выбрать самый мощный солвер или алгоритм, а взглянуть на задачу с другой стороны – изменить саму единицу решения. Вместо выбора на уровне слотов, мы стали заранее генерировать валидные кандидаты смен и дальше решали задачу выбора из этих кандидатов. В планировании графиков сотрудников таким кандидатом стала допустимая смена, в сглаживании нагрузки на РЦ – допустимый перенос потока.

Как мы провели проект через четыре «эпохи» — от ручных запусков на Windows‑планировщике до Spark + k8s на масштабе сети

Привет, Хабр! Меня зовут Имиль Валиуллин, я тимлид команды разработки платформы OSA. В предыдущих статьях цикла On Shelf Availability (OSA) уже разбирали с разных сторон: что такое OSA как продукт, как устроен алгоритм детекции аномалий и весь конвейер генерации сигналов — эвристики, ML‑модели, фильтры, обратная связь, A/B и оценка эффекта (ссылки на предыдущие статьи: 1, 2, 3). В этой статье мы раскрываем следующий слой — инженерный. Потому что всё перечисленное было бы невозможно без большой работы под капотом: данных, транспорта, оркестрации, SLA, мониторинга, качества данных, обратной связи, API и доставки сигналов в торговые точки. Многие забывают, что даже самая крутая ML‑модель — это только верхушка айсберга. Результат появляется только тогда, когда под ней есть надёжный фундамент: чистые данные, стабильный транспорт и бесперебойная доставка. Как говорится, garbage in — garbage out, и наоборот: качественный фундамент позволяет получить качественный результат.

Главная мысль, которую мы хотим донести: алгоритмы сами по себе не создают эффект. Эффект появляется только тогда, когда вокруг них построена инженерная система, которая каждый день стабильно считает, доставляет, проверяет и масштабирует результат. 

Показать это мы хотим через эволюцию продукта — от legacy и ручных запусков до промышленной платформы, работающей на масштабе сети. С точки зрения пользователя это всё тот же продукт — сигналы на торговых точках (ТТ), помощь сотрудникам магазина, рост доступности товара. Но под капотом OSA прошёл несколько серьёзных инженерных перерождений, которые мы для удобства назвали «эпохами»: каменный век, бронзовый, железный и индустриальная эпоха. 

Некоторые продуктовые процессы никогда не смогут быть вместе. Слишком много противоречий, слишком разный внутренний мир. Ты Венера, я Юпитер. Ты большой таргет стейт, я mvp-дривен. Но постойте… Разве реальная любовь в жизни случается только с теми, у кого много общего? 

Лид кластера геймификации приложения «Магнит», народный продакт-старовер Магнит Плюс (входит в бизнес-группу MAGNIT OMNI) Евгений Коврижин написал дискуссионную статью про внедрение процесса growth hacking в бигтехе. Только собственный 17-летний продуктовый опыт и никакого AI. Кто оставит комментарий, тот молодец.

MAGNIT TECH — это технологическое ядро крупнейшей розничной сети страны. Более 5 000 инженеров, аналитиков и продуктовых команд разрабатывают, поддерживают и масштабируют свыше 260 ИТ-продуктов и проектов, а также 800 информационных систем — от алгоритмов прогнозирования спроса в 33 000 магазинах до касс самообслуживания с собственным ПО. 

Мы ИТ-компания, создающая собственные продукты с высоким уровнем инженерной сложности, без зависимости от вендоров и системных интеграторов. В этой статье — честный рассказ о том, над чем мы работаем прямо сейчас и куда движемся в 2026 году.

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

Но со временем появляются новые вопросы. Команде становится недостаточно просто посчитать количество записей или получить текущее состояние объекта. Хочется понять, что происходило в системе: какие события привели к изменению состояния, какие действия выполнялись, где возникла проблема и на каком этапе произошёл сбой.

В этот момент становится понятно, что обычные источники данных не всегда подходят для аналитики. PostgreSQL должен обслуживать основную нагрузку приложения, а Kafka отлично решает задачи доставки событий, но не является удобным инструментом для сложного анализа.

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

Привет, Хабр! Я Миша Онянов, Python-разработчик и платформенный инженер в крупнейшем проекте MAGNIT TECH – F&R. Из статьи вы узнаете, как с помощью механизма Cluster Policies в Apache Airflow вынести требования к DAG’ам в исполняемый код:

- Поговорим о том, когда и зачем нужен отдельный слой Policies.

- Посмотрим на примеры требований в больших data-инженерных проектах и способ их реализации с помощью политик.

- Покажу нашу архитектуру, примеры кода и способы внедрения.

- Сделаем выводы из моих ошибок, допущенных при разработке и внедрении.

- В конце посмотрим, в каких ещё системах используется аналогичный механизм.

Материал будет полезен всем, кто собирается внедрять или уже работает с Apache Airflow ✌️🥸

Привет! Меня зовут Дмитрий Михеев, я ведущий разработчик в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

В своих сервисах для межсервисных коммуникаций помимо gRPC-запросов мы используем брокер сообщений Kafka. Если описывать его в двух словах, Kafka — это распределённый журнал событий (event log), через который сервисы обмениваются данными в реальном времени.

Не буду подробно останавливаться на устройстве Kafka — это хорошо описано в документации. В этой статье хочу подсветить один неочевидный момент, который может привести к проблемам при работе с consumer’ами — повторную обработку сообщений (retry).

Привет, Хабр! Меня зовут Дмитрий Кравчук, я занимаюсь всем, что связано с данными в блоке AI&ML MAGNIT TECH. Расскажу про фундамент прибыльных проектов, которыми мы занимаемся в департаменте. Эта начало цикла статей о наших достижениях за 5 лет и планах на будущее.

В 2020 году мы выбирали формат для больших ML-хранилищ: Delta Lake, Iceberg или Hudi. В итоге остановились на Delta Lake. За 5 лет вокруг него у нас выросла полноценная платформа данных для ML-нагрузок: Spark, Kubernetes, S3, YDB, Airflow, Flink, OpenMetadata, Trino, StarRocks и собственные фреймворки.

Я не буду пересказывать документацию Delta Lake, а расскажу, как это работает у нас в промышленном контуре: доставка данных, слои хранения, оркестрация, хранилище метаданных, lineage, data quality, observability и governance, а также доступ к данным.

Отдельно расскажу, в чём Delta Lake оказался силён, а где пришлось достраивать инфраструктуру: объектное хранилище вместо блочного, координировать коммиты для приближения к ACID, обеспечивать потоковую загрузку, оптимизировать хранение и эксплуатировать большие таблицы.

Материал будет полезен инженерам данных, ML-инженерам, Data scientist’ам, системным аналитикам, MLOps/DataOps/DevOps и всем, кто создаёт промышленную платформу данных под реальные нагрузки.

Привет! Меня зовут Ксюша, я продуктовый дизайнер в MAGNIT TECH, и уже больше года работаю над карьерными сайтами. Я присоединилась к продуктовой команде, в которой были продакт-менеджер, продуктовый аналитик, исследователь и разработчики, но не хватало меня –  дизайнера :)

Чтобы находить ценные решения, мы решили раз в спринт устраивать мозговые штурмы. Мы приходили на встречи с разными вопросами и данными: интервью с кандидатами, отчеты аналитика, отзывы пользователей, обратная связь от эйчаров и видение продуктовой команды. Благодаря совместной работе каждую встречу удавалось собрать список гипотез – расскажу, как мы с ними работали.

Привет, Хабр! Меня зовут Сергей Чекменев, я тимлид ML-команды развития массового промо и монетизации центра развития ML-решений клиентской персонализации в MAGNIT TECH. В этой статье расскажу про наш MVP-проект PromoPersona – сервис автоматической генерации персонализированных промо-коллажей: что именно мы построили с технической точки зрения, как интегрировали модель FLUX.2 и почему именно ее,  и какие инженерные задачи пришлось решить.

Привет! Меня зовут Ильсаф, я инженер данных в MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов. В этой статье я собрал свои практические наблюдения по работе Kafka Connect и Debezium с PostgreSQL: от настройки репликации до мониторинга и бэкфиллинга.

Привет, Хабр! Меня зовут Ян Пиле, руковожу в MAGNIT TECH направлением развития алгоритмов доступности товаров. Задача моей команды: сделать так, чтобы в магазине, куда вы зашли за своим любимым майонезом, он с большей вероятностью оказался на полке. А если не оказался — чтобы сотруднику магазина как можно быстрее прилетело задание: «проверь, почему именно этой позиции сейчас нет, и, если возможно, верни её обратно».

Мы уже дважды писали про OSA (On-Shelf Availability — уровень доступности товара на полке). В статье «Как OSA превращает пустые полки в полные корзины?» рассказывали про продуктовый контекст: зачем эта история нужна бизнесу и почему «товар числится в системе» и «товар реально лежит на полке» — это два совершенно разных утверждения. А в статье «Когда 0 в продажах — аномалия? CUSUM для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.

 33 000 магазинов, 46 РЦ сети «Магнит», 17 млрд прогнозов на 90 дней, 8 ПБ данных и ни одного готового решения, которое можно было бы просто взять с рынка. В 2024 году мы начали с нуля собирать собственную F&R-платформу (Forecast and Replenishment) для «Магнита» — систему прогнозирования спроса и пополнения.

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

Всем привет! Меня зовут Саша, я тимлид в DWH MAGNIT OMNI — бизнес-группе ритейлера «Магнит», которая отвечает за развитие омниканального опыта для клиентов.

Недавно ребята из Datalens проводили вебинар в честь выпуска Public API, в котором я принял участие. Эта статья — развернутая версия моего доклада об интеграции Datalens с OpenMetadata.

Корпоративный мир ушёл далеко вперёд. Если 10 лет назад сотрудники выходили на работу, чтобы создавать продукты «с нуля», то сегодня конъюнктура изменилась. IT-ландшафт крупных компаний перенасыщен решениями на любой вкус. На смену классическому проектному управлению, ориентированному на создание чего-то нового, пришло управление продуктами, где гибкие методологии работают на развитие и стабилизацию уже существующих систем.

Но любой продукт когда-то был просто идеей. Поэтому давайте договоримся о терминах: в этой статье проект — это нулевая ступень, фундамент, с которого начинается жизненный путь любого продукта. Расскажу об этом подробнее на примере из личной практики.

Привет!

Меня зовут Дмитрий Клопов. Я продакт-менеджер: отвечаю со стороны продукта за B2B-стрим в агрегаторе доставки готовой еды «Магнит Рестораны», входящего в состав бизнес-группы Магнит OMNI. 

В рамках своего стрима я регулярно сталкиваюсь с необходимостью квартального планирования в условиях большого количества заказчиков — 15–20 человек — и ограниченного капаситета команды разработки. У каждого заказчика свои приоритеты, ожидания и аргументы, и при этом все они конкурируют за один и тот же ресурс команды.

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

Я работаю дата-сайентистом 5 лет и до сих пор испытываю боль, когда нужно сделать MVP по временным рядам. Начиная с того, как построить несколько графиков одновременно без «слипшихся» меток по осям, заканчивая поиском подходящего метода очистки ряда от аномалий. И всё это венчает цикл по каждому ряду с бесконечным жонглированием данными между numpy, pandas, sklearn, yet_another_library.

Если вы DS, и тоже, как и я, устали от вот этого всего, добро пожаловать под кат. Я покажу, как написать production-ready код для прогноза 200+ временных рядов от EDA до результата. Разберем на практике, как бороться с аномалиями, ловить смены тренда и в итоге – получить масштабируемое решение, а не очередной «велосипед».