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

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

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

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

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

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

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

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

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

Меня зовут Виктория Костерина, я тимлид команды. В этой статье мы вместе с моим коллегой, ML-инженером Богданом Тонанайским, рассказываем, как создавали систему автоматического сопоставления товаров между ассортиментом конкурентов и товарами «Магнита».

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

Всем привет! Меня зовут Михаил, я продуктовый аналитик в команде Foodtech мобильного приложения Магнит. В своей прошлой статье я рассказывал о применении алгоритмов PrefixSpan и Seq2Pat для анализа путей пользователей, и сегодня продолжу тему изучения передвижения пользователей внутри приложения. На этот раз речь пойдёт о методе, который позволяет оценить влияние каждого сегмента аудитории на изменение метрики всей пользовательской базы.

ClickHouse — одна из самых популярных систем для анализа данных. По информации TheirStack, этот инструмент использует более 3 700 компаний по всему миру. 

У ClickHouse быстрая аналитика, эффективное сжатие и отличное масштабирование. Но у системы есть и недостатки — ограниченная поддержка UPDATE и DELETE, а также сложная миграция.

Привет, Хабр! Меня зовут Михаил Филимонов, я руковожу разработкой хранилища данных в группе Магнит OMNI. В этой статье я расскажу о проблемах работы с ClickHouse, как их решать и какие инструменты для этого потребуются. 

Оптимизацию цен часто упрощают: учимся прогнозировать спрос, зная его при заданных ценах — оптимизируем цены, фиксируем прибыль.

И, казалось бы, данные о продажах в прошлом найти нетрудно, готовых фреймворков с алгоритмами оптимизации — десятки, осталось только немного «поиграть в kaggle», обучив хорошую модель для предсказания спроса и всё готово!

Но на практике всё намного сложнее. Почему модель, идеально прогнозирующая спрос, может предлагать цены, разоряющие бизнес? Может ли максимизация прибыли привести к потере покупателей в долгосрочной перспективе? Почему оптимизатор может считать, что яблоки должны продаваться по цене iPhone? В этой статье разберём эти и прочие «смертные грехи» ценообразования с помощью ML.

Всем привет! Меня зовут Елена Пилюгина, я ведущий разработчик отдела автоматизации бизнес процессов складской логистики в Magnit Tech.

В этой статье я расскажу про свой опыт покрытия тестами процессов в приложении на Spring Boot с Camunda 7. Покажу, как можно создать конструктор для тестирования процессов, варианты тестирования процессов в динамике и статике, поделюсь конкретными примерами кода, покажу преимущества BDD тестирования. Конечно, в рамках одной статьи невозможно охватить все технические аспекты, но я постараюсь показать выбранный мной подход к тестированию. Также буду рада, если заодно получится показать, что создание тестов может быть увлекательным и творческим процессом.

Привет, Хабр! Меня зовут Артём Гриппа, я руковожу направлением продуктов поддержки клиентских отзывов в Магнит OMNI. Сегодня хочу рассказать о том, как команды моего направления — клиентских отзывов и платформы опросов — вместе с нашими стейкхолдерами создали систему работы с клиентской обратной связью, которая влияет на бизнес-результаты. Не просто собирает красивые метрики для отчётов, а превращает каждый отзыв в конкретные действия и, что немаловажно, в дополнительную выручку. Причём речь идёт не о паре сотен отзывов, которые можно прочитать за чашкой кофе, а о полутора сотнях тысяч ежедневных комментариев, которые физически невозможно обработать без автоматизации.

В статье Создание собственной системы F&R в «Магните»: функциональный дизайн было рассказано о том, что компания «Магнит» столкнулась с ограничениями существующих решений класса Forecast & Replenishment, по производительности, гибкости и скорости реакции.

Так мы решили создать собственное решение.

Я Алексей Соболеков, ИТ-архитектор в Magnit Tech, расскажу о ключевых архитектурных принципах и решениях Magnit F&R. Будет полезно Архитекторам, Техлидам, CTO, и всем, кто проектирует архитектуру высоконагруженных облачных решений на базе Open Source технологий.

Я Евгений Прочан, в платформенной команде Magnit OMNI развиваю инфраструктуру DWH. Расскажу здесь, почему нам понадобилось перейти от батчинга к CDC и как мы это делали. Причин перехода было две: потребность бизнеса в расширении возможностей инфраструктуры и нестабильность нашего старого процесса репликации. 

Мы используем в основном базы данных PostgreSQL. Оттуда пакетами раз в час передаём данные в S3, ClickHouse и таблицы Iceberg. Наша потоковая нагрузка достигает примерно полутора терабайта данных, 6000 операций в секунду (около 1500 в самой нагруженной базе данных). 

Представьте: у вас есть приложение с 20 пользовательсĸими ролями. Каждая роль видит интерфейс по-своему — разные элементы, состояния, возможности. И вам нужно поддерживать аĸтуальность всех этих вариантов.

Звучит ĸаĸ nightmare? Таĸ и было.

Всем привет! Меня зовут Макаров Иван, я руководитель программы Tech for Tech проектов в Magnit Tech. Последние 1,5 года мы реализуем масштабный технологический проект по выносу наиболее критичных информационных систем из единой платформы-монолита на выделенную инфраструктуру. Проект интересен своим масштабом и сложностью, и сегодня я расскажу, как мы справились с высоким уровнем неопределенности, скрытыми зависимостями, требованиями бизнеса и другими трудностями.

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

Меня зовут Артем Москальков, я — ведущий инженер данных в Магнит OMNI. В статье я расскажу о том, как мы оптимизировали производительность кластера в ClickHouse.

Частые мелкие вставки данных через Kafka Sink-коннектор серьёзно замедляли работу ClickHouse из-за огромного числа отдельных запросов. Путём настройки параметров потребителя Kafka и включения объединения партиций удалось сгруппировать записи в крупные блоки, что резко снизило нагрузку на базу и многократно увеличило её пропускную способность.

Меня зовут Михаил, я работаю в Magnit Tech и занимаюсь внедрением 1C платформы на операционную систему Linux. В этой статье я расскажу, как реализовать создание резервных копий бакетов S3-совместимого объектного хранилища MinIO.

(Сразу дам спойлер: нам удалось это сделать с наименьшими затратами места на диске с использованием инкрементальных бэкапов).

Всем привет! Меня зовут Костя, и в этой статье я продолжу рассказ моей коллеги Анастасии из команды доступности Magnit Tech о том, как можно искать проблемные товары на полках магазинов, опираясь лишь на данные по дневным продажам и остаткам товара в магазине.

В этой статье я расскажу о другом, альтернативном алгоритме, который детектирует ощутимую долю проблемных позиций наравне с тем, о котором рассказывала моя коллега. Этот алгоритм также прост для понимания и интерпретации бизнесом. Его внедрение и эксплуатация требуют минимальных затрат: вычислительные ресурсы, сопровождение и адаптация под разные форматы магазинов обходятся недорого. Кроме того, он может служить эффективным первым шагом перед внедрением более сложных и ресурсоемких ML-алгоритмов. В отличие от нейросетевых подходов к поиску аномалий, которые требуют тщательной настройки (или даже разработки) оптимальной архитектуры сети, настроить этот алгоритм значительно проще.

23 апреля на OMNI Infrastructure Meetup эксперты из Авито, Магнит OMNI, Лаборатории Касперского и Cloud.ru обсудили, как создавать системы, устойчивые к любым сбоям. Рассказываем о самых важных инсайтах.

В московском офисе Магнита и онлайн собрались DevOps-инженеры, платформенные специалисты и разработчики, чтобы разобрать реальные кейсы повышения отказоустойчивости. Гибридный формат позволил присоединиться участникам из разных городов — дискуссия получилась по-настоящему живой.

Делимся видео и презентациями докладов.

Всем привет! Меня зовут Юлия, и уже 6 лет я занимаюсь тестированием. За свою карьеру я успела принять участие в разных проектах компаний от стартапов до гигантов индустрии, тестировала бэк, фронт, мобилки, веб и даже устройства интернета вещей, успела дорасти до тимлида и начать осваивать автоматизацию.
В этой статье я поделюсь своим опытом QA-инженера и расскажу о самых распространенных ошибках, которые могут убить ИТ-продукт на корню. Я собрала примеры из реальной жизни, чтобы показать, как даже самые мелкие недочеты могут обернуться огромными проблемами.

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

Коллеги, всем привет! На связи команда Magnit Tech, меня зовут Михаил, я продуктовый аналитик в команде Foodtech мобильного приложения Магнит. В этой статье мы обсудим, как понять каким образом ваши пользователи доходят до выполнения целевых действий и как выявить в этом пользовательском пути негативные паттерны. А чтобы процесс обсчета пользовательских путей не занимал у вас десятки часов, мы научимся применять для решения этой задачи алгоритмы PrefixSpan и Seq2Pat.

Привет! Я Александр Букин, дизайн-лид направления Фудтех в Магнит OMNI, объединяющем сервис доставкивертикаль «Магнит Фудтех», маркетплейс «Магнит Маркет» и программу лояльности «Магнит Плюс».

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