Некоторые продуктовые процессы никогда не смогут быть вместе. Слишком много противоречий, слишком разный внутренний мир. Ты Венера, я Юпитер. Ты большой таргет стейт, я 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.

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

Я Алексей Соболеков, лид архитектуры F&R в Magnit Tech. Это мой личный взгляд на события, и в команде существуют разные их интерпретации.

В 2024 году команда F&R (подробности тут: Архитектура высоконагруженной платформы Magnit F&R) в MAGNIT TECH  столкнулась с нетривиальным вызовом: всего за один год необходимо было вырасти с 20 до 220 человек для формирования состава команд. Формально все выглядело благополучно - проект запущен, бюджет подтвержден, приоритет высокий. Но именно с этого момента в ИТ-команде разработки F&R начали накапливаться системные проблемы.

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

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

Привет!

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

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

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

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

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

Одна из важнейших задач поиска — релевантная выдача. Простых универсальных решений здесь нет, а улучшение поиска — долгосрочный процесс, где крупные задачи приходится разбивать на небольшие, последовательные шаги.

В этой статье делимся тем, как нам в «Магнит Маркете» удалось значительно улучшить качество поиска с помощью нетривиального подхода: ступенчатой классификации категории поискового запроса.

У нас было пять руководителей проекта, семь лет разработки, несколько почти законченных решений, меняющиеся цели, задачи и разнообразные системы всех цветов и размеров. Не то, чтобы это было нужно для успешной реализации, но раз уж начал пилить долгострой, то иди в своём увлечении до конца. Единственное, что меня пугало — это разработка серебряной пули, которая якобы исправит все проблемы. В ИТ нет ничего более иллюзорного, чем попытка разработать универсальную систему для решения всех проблем. И я знал, что мы скоро в это окунёмся.

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

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

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

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

Можно сосредоточить сотрудников на решении бизнес-задач и настоящей инженерной магии, если скинуть рутину на плечи ИИ. В прошлой статье мы рассказали об успешном опыте создания отдельного сервиса скоринга клиентов для персональных промоакций, и о том, как небольшой сервис быстро вырос в самостоятельный инструмент — платформу монетизации предложений от поставщиков MPS (Monetization Platform for Suppliers), — и позволил увеличить количество и качество промокампаний.

 С запуском платформы MPS мы автоматизировали большинство шагов по подготовке маркетинговых кампаний. И до настоящего времени узким местом в масштабировании промозапусков оставалась ручная отрисовка коллажей товарных позиций для персональных предложений в мобильном приложении.

Масштабировать количество дизайнеров вместе с маркетинговыми кампаниями — идея, достойная триллера, но не бизнеса. Рабочим решением стало создание сервиса автоматической генерации промоколлажей товарных позиций. И в этой статье мы поговорим о целях проекта и его технической реализации от постановки задачи до боевого использования в проде. Автоматизация отрисовки маркетинговых коллажей спасла наших дизайнеров от рутинного копипаста, улучшила бизнес-метрики и подарила клиентам такие промо, на которые хочется смотреть, а не закрывать глаза :)