Привет! Я Андрей, руковожу группой обработки и хранения ассортимента в Маркете. Через нашу платформу проходят все товары, которые продавцы приносят на Маркет: от одной карточки, заполненной руками, до Excel-файла на миллион позиций.
Нам одинаково интересны и продуктовые задачи в кабинете продавца, и инфраструктурные задачи на хранение миллиардов оферов, поэтому у нас можно поработать и с тем и с другим. Ищу человека, которому нравится разбираться в данных и который не боится больших чисел.
Яндекс Маркет — маркетплейс, где десятки тысяч продавцов размещают свои товары. Прежде чем покупатель увидит товар в поиске или на карточке, товарное предложение продавца должно попасть в систему, пройти проверки и стать доступным всем сервисам Маркета. За эту часть отвечает наша платформа ассортимента: она принимает товары от продавцов, хранит их и отдаёт всем, кому они нужны.
Наша группа занимается обработкой и хранением ассортимента. Продавцы загружают товары разными способами: через API, вручную через карточку товара в личном кабинете и Excel-файлами. Мы принимаем все эти потоки, храним товарные предложения и отдаём данные о них в личный кабинет продавца — почти на каждую его страницу. Сейчас в системе больше 2 миллиардов товарных предложений.
Задачи у нас двух видов, и обычно один человек занимается и теми, и другими. Продуктовые — это всё, что видит продавец: каталог товаров, загрузка и выгрузка Excel-файлов, действия над товарами. Инфраструктурные — хранение оферов, полнотекстовый поиск, перевод сервисов на общую платформу исполнения запросов и вынос состояния в отдельное хранилище.
Каталог товаров в кабинете продавца
Каталог — основной инструмент продавца для работы с ассортиментом. Товары попадают в него
разными путями: через API, из Excel-файла или через карточку товара в кабинете. В каталоге их можно смотреть, фильтровать и выполнять массовые действия, например удалять или архивировать.
Вы будете развивать бэкенд каталога: добавлять новые фильтры и действия, следить за тем, чтобы выборка по миллионам товаров одного продавца оставалась быстрой, и договариваться о контрактах с фронтендом кабинета.
Хранение и поиск более 2 миллиардов товарных предложений
Мы храним оферы в динамических таблицах распределённой платформы данных YT, а полнотекстовый поиск по ним реализуем на отдельном поисковом сервисе. При таких объёмах привычные решения перестают работать, и почти каждая задача превращается в вопрос про схему данных, шардирование и стоимость запроса.
Данные в системе не лежат мёртвым грузом: мы принимаем поток обновлений оферов, и здесь счёт идёт уже на сотни тысяч запросов в секунду. То есть у нас две очень разные нагрузки — чтение из кабинета продавца и поток обновлений на запись. Схема хранения должна выдерживать обе нагрузки. Вы будете развивать схему хранения, ускорять чтение и запись, улучшать качество и скорость поиска по ассортименту.
Генерация и обработка Excel-файлов с товарами
Для многих продавцов Excel — основной способ работы с ассортиментом: они скачивают шаблон,
заполняют его и загружают обратно. В одном файле может быть до миллиона товаров, поэтому
задача не сводится к тому, чтобы «прочитать таблицу»: нужно уметь обрабатывать такие объёмы, не съедая всю память, валидировать данные и понятно сообщать продавцу, что именно он заполнил не так.
Вы будете развивать генерацию шаблонов и разбор загруженных файлов: добавлять новые колонки и правила валидации, поддерживать подсказки и выпадающие списки прямо в таблице, ускорять обработку больших файлов.
Передача данных о товарных предложениях в личный кабинет
Данные об оферах нужны почти на каждой странице кабинета продавца, поэтому наш сервис — один из самых нагруженных в Маркете. Сейчас это от 60 до 500 запросов в секунду, и каждый из них влияет на то, как быстро откроется страница у продавца.
Вы будете заниматься этим сервисом: расширять API под новые сценарии кабинета, держать латентность в рамках, разбираться с нагрузкой и кешированием.
Переход на общую платформу исполнения запросов и stateless-архитектуру
Мы переводим сервисы на внутреннюю платформу оркестрации запросов. Вместо того чтобы каждый сервис сам ходил по соседям, обход описывается декларативным графом: платформа сама делает сетевые запросы, распараллеливает независимые вызовы, занимается балансировкой и service discovery, даёт единообразные логи, трейсы и мониторинги. Сервисы при этом упрощаются — в них остаётся бизнес-логика, а данные приходят на вход.
Параллельно мы выносим состояние в отдельное хранилище с реляционной моделью поверх YT, чтобы все сервисы, кроме самого хранилища, стали stateless. Это большая архитектурная работа на живой системе под нагрузкой, и её нельзя делать с остановкой сервиса — только постепенно и незаметно для продавцов.
Больше о бэкенде в Яндексе — в канале Yandex for Backend
Как мы пишем и релизим код
Процесс код-ревью у нас простой: чтобы влить изменения, достаточно одобрения одного коллеги. К мелочам не придираемся — скорость доставки фич до продавцов для нас важнее споров о форматировании.
У нас больше 20 сервисов, и на каждом настроен автоматический релиз: прогон тестов, выкладка в тестинг, престейбл и продакшен — с проверкой мониторингов между этапами. Катать релизы руками не нужно.