Microsoft Shopping Feed Pipeline

Задача

Blender Networks Inc. управляет крупным сайтом-агрегатором цен, вся монетизация которого строится исключительно на Microsoft Advertising Product Listing Ads (PLA). Предыдущее in-house-решение для фидов было нестабильным и требовало замены.

Сложность создавали гетерогенные сторонние источники: Connexity отдаёт zip-архивы JSON через API-индекс, Shopping24 (S24) предоставляет master-файл CSV плюс фрагментные обновления через FTP. Оба формата нужно было безошибочно преобразовать в строго определённую TSV-схему Microsoft Merchant Center. Любая ошибка формата, любой «item drop» = прямые потери выручки.

Дополнительная сложность: данные Connexity регулярно превышают 2 ГБ на publisher-аккаунт, маппированный output измеряется в десятках гигабайт, а общий ежедневный upload в Microsoft Merchant Center составляет около 200 ГБ. Наивная in-memory обработка не подходила, пайплайн должен был оставаться OOM-безопасным даже на скромном железе.

Решение

Три гетерогенных источника, один унифицированный пайплайн. Архитектура построена по строгой трёхэтапной модели, Ingest → Map → Upload, где каждая партнёрская сеть прячется за одним и тем же интерфейсом, но внутри использует свой собственный стек (см. диаграмму пайплайна ниже).

• Streaming-first ингест. Python-пайплайн с ijson парсит zip-архивы JSON элемент за элементом прямо из потока, вместо того чтобы десериализовать весь документ в RAM. Потребление памяти остаётся постоянным независимо от размера фида.
• Дедупликация на диске. Таблица SQLite с тонкой настройкой PRAGMA берёт на себя кросс-аккаунтную дедупликацию на диске. Multi-million-item фиды остаются чистыми, не разрывая heap, состояние дедупликации сохраняется даже при аварии для последующего анализа.
• Строгий маппинг под MS-спеку. Каждая запись из источника детерминированно маппируется на требуемую схему id/title/description/link/image_link/price/.... Логика валидации фильтрует непригодные brand-строки (чисто числовые, слишком длинные, со слишком многими словами), проверяет GTIN на допустимые длины (8/12/13/14) и согласованно выставляет identifier_exists, никаких больше предупреждений «Partial Identifier».
• 15-ГБ-чанкинг и chunk-aware загрузка. Outputs маппинга автоматически разбиваются по 15 ГБ на _0.txt, _1.txt, …, под лимит загрузки Microsoft. Аплоадер распознаёт эти чанки по pattern-matching и корректно нумерует их на удалённой стороне (TipDigest_US_0.txt, TipDigest_US_1.txt, …).
• Высокоскоростной SFTP через LFTP. Вместо Python-SFTP-библиотек (paramiko) используется системная LFTP-бинарка с увеличенным TCP-socket-buffer и стратегией реконнекта. На multi-GB-файлах значительно быстрее и стабильнее любой Python-реализации.
• Multi-account оркестрация. Несколько Connexity-publisher-ов и несколько Merchant-Center-аккаунтов (US/DE) обрабатываются параллельно; каждый аккаунт пишет в свой output-путь и корректно маршрутизируется через store-mapping.
• Resilient daily sync. Cron-lockfile защищает от перекрывающихся двойных прогонов. Стадии пайплайна можно отключать по отдельности (--skip-ingest, --skip-map, --skip-upload) для целевого re-run после частичных сбоев, не вытягивая повторно весь 2-ГБ-download.
• Проактивная обработка ошибок и диагностика. Гибридное логирование (Rich-консоль с emoji для людей + RotatingFileHandler для машины), per-stage execution-report, изоляция per-account. Один обрезанный JSON-поток не останавливает весь прогон, ошибки логируются локально, прогон продолжается с остальным.
• Модульная архитектура. Каждая партнёрская сеть живёт в своём модуле (ingest_*.py + mapper_*.py) за единым интерфейсом пайплайна. Третий источник (Kelkoo) был добавлен без вмешательства в Connexity или S24, доказательство, что абстракция держит.
• Acceptance criterion. Жёсткий критерий приёмки (5+ дней подряд безошибочной автоматизации) был пройден с первой попытки, благодаря чистым границам модулей и последовательному слою валидации.

Диаграмма показывает полный поток данных: от гетерогенных источников (zip-архивы JSON, REST-API, FTP-дампы) через OOM-безопасный слой ингеста, valdation-driven маппинг с 15-ГБ-чанкингом до chunk-aware LFTP-загрузки в Microsoft Merchant Center.

Результат

• 100 % соответствие фидов, никаких отклонений из-за ошибок формата.
• Zero errors в ежедневной синхронизации, критерий приёмки пройден с первой попытки.
• ROI защищён, никаких потерь выручки из-за ошибочных обновлений.
• OOM-безопасно при multi-GB фидах, пайплайн работает на скромном железе без давления на память.
• Модульная расширяемость, новые партнёрские сети интегрируются без вмешательства в ядро.