Тимлид 10 лет в одной системе и перестал спрашивать «почему сборка занимает два часа?». А джун на третьей неделе задал именно этот вопрос — и за месяц мы переделали пайплайн. Теперь сборка занимает минуты вместо часов.

И нам не просто повезло. Мы поняли, как построить систему: 30 минут в неделю, джун показывает тимлиду одну новую технологию. Не лекцию — живой терминал. Не «джун умнее» — другая точка обзора.

В статье: формат сессии 5+15+5+5, шаблон сессии, чек-лист тимлида-ученика, четыре приёма, которые отличают работающую систему от формальной, три истории с сессий (локальный AI для код-ревью, OpenTelemetry + Grafana, оптимизация CI/CD), антипаттерны, риски и планировщик на Python, который можно скопировать и использовать уже завтра.

Перед каждым ML-разработчиком, после обучения прекрасной модели, которая поднимет бизнесу метрики, а тебе годовую премию, возникает вопрос: а как ее задеплоить в сервисе, чтоб она начала работать?

А ты пошел отдыхать.

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

Меня зовут Микаэл Новиков, я главный разработчик в команде ML-платформы MAGNIT TECH. Расскажу, как мы в проекте F&R не смогли оставить data quality без внимания, отобразили результаты проверок в OpenMetadata и попутно наступили на несколько грабель интеграции open source-решения.

Одной из сильных сторон Kafka Streams является возможность хранить состояние приложения локально. По умолчанию в качестве локального хранилища используется RocksDB — встроенная key-value база данных, расположенная на диске.

Но есть одна особенность, о которой редко задумываются в начале проекта. State Store отлично умеет хранить данные, но совершенно не знает, когда их пора удалить. Если приложение однажды записало объект в Store, он останется там до тех пор, пока приложение самостоятельно его не удалит. Никакого встроенного TTL для обычного State Store в Kafka Streams нет. На небольших объёмах это практически незаметно.

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

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

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

В литературе мы встретили концепцию временных окон (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 для поиска проблем в ритейле» мы подробно разбирали один из рабочих алгоритмов команды. В этот раз я хочу пройтись по всему стеку детекции целиком — от самых простых правил до А/Б-тестов, в которых приходится бороться с зависимыми наблюдениями.