Крупномасштабный e-commerce скрапинг

Скрапинг одной страницы товара, это туториал. Скрапинг нескольких миллионов таких страниц каждый день без остановки пайплайна, это системная проблема. Крупномасштабный e-commerce скрапинг лежит в основе мониторинга цен, отслеживания каталогов и ассортимента, бенчмаркинга конкурентов и сигналов спроса: того вида анализа, который требует целой полки, а не выборки. Переход от сотен страниц к миллионам не только добавляет работы, но и меняет то, что может сломаться и как нужно строить систему.

Данное руководство ограничено публичными данными: листингами товаров, ценами, наличием, рейтингами и количеством отзывов, которые любой может видеть без входа в систему. Оно не затрагивает аккаунты пользователей, корзины, заказы или персональные данные. Мы рассмотрим, зачем команды это делают, проблемы, которые возникают только при больших объёмах, и архитектуру, которая выдерживает нагрузку, с Crawlbase Crawling API, асинхронным Crawler и Smart AI Proxy в роли слоя масштабирования.

Зачем скрапить e-commerce в крупном масштабе

Одна страница товара говорит вам, как выглядит одна цена прямо сейчас. Ценность в масштабе создаётся через широту и историю: тысячи SKU, отслеживаемых у многих ритейлеров, с достаточно частыми выборками для наблюдения за движением. Именно это превращает сырые листинги в решения. Крупномасштабный e-commerce скрапинг движим четырьмя вариантами использования.

• Мониторинг цен. Отслеживайте цены конкурентов по каталогу с течением времени, чтобы корректировать цены, замечать акции и выявлять демпинг в день его появления, а не неделю спустя.
• Отслеживание каталогов и ассортимента. Определяйте, какие товары ритейлер предлагает, что в наличии и как описываются листинги, чтобы находить пробелы в собственном ассортименте и наблюдать, как конкуренты расширяются в новые категории.
• Бенчмаркинг конкурентов. Сравнивайте свои цены, рейтинги и темп роста отзывов с конкурентами по тем же SKU, чтобы видеть, где вы побеждаете, а где теряете позиции.
• Сигналы спроса. Количество отзывов, тренды рейтингов и оборот запасов, это публичные прокси того, что продаётся. Наблюдение за ними во многих магазинах выявляет растущие товары до того, как они появятся в ваших собственных данных о продажах.

Это та же форма задачи, что и в любой работе по e-commerce веб-скрапингу. Разница в масштабе, чисто в объёме, а именно там простые подходы разрушаются.

Что меняется при переходе от сотен к миллионам страниц

Скрипт, скрапящий несколько сотен страниц на вашем ноутбуке, не выживет при направлении на несколько миллионов. Перечисленные ниже проблемы незначительны при малых объёмах и становятся всей работой при крупном масштабе.

Объём и параллелизм

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

Антибот-защита

Крупные ритейлеры используют сложное обнаружение ботов. IP датацентров, повторяющиеся паттерны запросов и отсутствующие отпечатки браузеров оспариваются CAPTCHA или полностью блокируются. Чем больше страниц вы загружаете, тем больше трафика вы генерируете из данного источника, и тем быстрее вы срабатываете защиту. То, что работало для ста запросов, даёт вам блокировку на ста тысячах.

Ротация IP

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

Свежесть

Данные о ценах полезны только если они актуальны. Полный обход каталога, занимающий три дня, даёт цены трёхдневной давности, что для корректировки цен бесполезно. Свежесть вынуждает быстро обходить страницы по расписанию, что ещё больше увеличивает параллелизм и давление антибот-защиты.

Качество данных

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

Архитектура, справляющаяся с масштабом

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

• Обнаружение URL. Обходите категории и страницы поиска для формирования списка URL товаров. Это самостоятельный обход, являющийся входными данными для всего последующего.
• Загрузка. Загружайте каждый URL за ротирующимися IP с рендерингом при необходимости, повторными попытками при отказе и достаточным параллелизмом для достижения целевой свежести.
• Парсинг. Преобразуйте HTML в чистые строки: название, цена, валюта, наличие, рейтинг, количество отзывов. Либо с собственными селекторами, либо с авто-парсингом.
• Хранение и валидация. Записывайте строки в запрашиваемое хранилище, валидируйте при поступлении и помечайте аномалии, чтобы проблемы с качеством проявлялись немедленно.

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

Один запрос через Crawling API

Вот один синхронный запрос публичной страницы категории с последующим парсингом. Crawling API принимает ваш токен и целевой URL, маршрутизирует запрос через доверенный IP и возвращает HTML для извлечения данных.

const { CrawlingAPI } = require('crawlbase')
const cheerio = require('cheerio')

const api = new CrawlingAPI({ token: 'YOUR_CRAWLBASE_TOKEN' })

const categoryURL = 'https://example-store.com/c/laptops?page=1'

async function scrapeCategory(url) {
  const response = await api.get(url, { ajax_wait: true, page_wait: 3000 })
  const $ = cheerio.load(response.body)
  const products = []

  $('.product-card').each((i, el) => {
    products.push({
      name: $(el).find('.product-title').text().trim(),
      price: $(el).find('.price').text().trim(),
      inStock: $(el).find('.availability').text().trim(),
      rating: $(el).find('.rating').attr('data-value'),
    })
  })

  return products
}

scrapeCategory(categoryURL).then((rows) => console.log(rows))

Два параметра важны для современных магазинов. ajax_wait сообщает API дожидаться асинхронного контента, а page_wait выдерживает фиксированное количество миллисекунд, чтобы цены с поздним рендерингом появились до возврата HTML. Селекторы являются заглушками: проверьте целевую страницу в инструментах разработчика и сопоставьте каждое поле с реальным.

Пропустите селекторы с помощью Scraper API

Написание и поддержка селекторов для каждого ритейлера является отдельной статьёй затрат. Crawlbase Crawling API напрямую возвращает структурированный JSON для поддерживаемых e-commerce страниц, поэтому вы получаете название, цену, наличие и рейтинги как поля без самостоятельного парсинга HTML. В масштабе меньше пользовательских парсеров означает меньше вещей, которые молча ломаются при изменении разметки сайта.

Перейдите к асинхронному режиму с Crawler

Синхронные вызовы работают для тысяч страниц. Для миллионов блокировка на каждом запросе и ручное управление повторными попытками не масштабируются. Асинхронный Crawler меняет модель: вы отправляете ему URL, он обходит их в фоновом режиме с ротацией и повторными попытками, и доставляет каждый результат на контролируемый вами вебхук по мере завершения. Ваш код перестаёт ждать ответов и просто получает разобранные страницы.

const { CrawlingAPI } = require('crawlbase')

const api = new CrawlingAPI({ token: 'YOUR_CRAWLBASE_TOKEN' })

const urls = [
  'https://example-store.com/p/sku-1001',
  'https://example-store.com/p/sku-1002',
  'https://example-store.com/p/sku-1003',
]

async function queueAll(list) {
  for (const url of list) {
    await api.post(url, { callback: 'https://your-app.com/webhook' })
  }
}

queueAll(urls).then(() => console.log('Queued', urls.length, 'URLs'))

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

Когда нужен прокси, а не парсер

Некоторые команды уже имеют стек скрапинга и нуждаются только в слое разблокирования. Crawlbase Smart AI Proxy, это единственная конечная точка, стоящая перед вашим существующим HTTP-клиентом или безголовым браузером и маршрутизирующая трафик через ротирующийся резидентный пул, так что вы сохраняете код и получаете ротацию. Если вы хотите понять, как ротация работает под капотом, ротирующиеся резидентные прокси объясняют механику.

Поддержание высокого качества данных при больших объёмах

Чистые данные в масштабе, это процесс, а не парсер. Несколько привычек поддерживают надёжность крупного обхода.

• Валидируйте при записи. Отклоняйте или помечайте строки с отсутствующей ценой, непарсируемой валютой или пустым названием, чтобы плохие страницы не засоряли набор данных.
• Отслеживайте коэффициент извлечения. Если доля страниц, дающих полную запись, падает, сайт скорее всего изменил разметку. Настройте оповещение, а не обнаруживайте это в отчёте.
• Сделайте пайплайн идемпотентным. Ключируйте строки по URL плюс временной метке, чтобы повторные попытки и повторные запуски не создавали двойной счёт, это имеет значение с момента добавления повторных попыток.
• Выборочно проверяйте. Периодически сравнивайте горстку строк с живой страницей, чтобы убедиться, что цены и наличие по-прежнему соответствуют реальности.

Честная часть: ToS и robots

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

Несколько правил, которых стоит придерживаться. Собирайте только публичные данные: листинги, цены, наличие и рейтинги, которые любой может видеть без аккаунта. Уважайте robots.txt каждого сайта и заявленные ожидания по скорости, и поддерживайте объём запросов достаточно низким, чтобы не нагружать серверы. Никогда не собирайте персональные данные, ничего, связанного с индивидуальными аккаунтами пользователей, или ничего за логином. Если вы планируете коммерческое повторное использование данных, получите разрешение или официальное соглашение об использовании данных, а не предполагайте, что молчание является согласием. Для более широкой стратегии см. как скрапить сайты без блокировок.

Часто задаваемые вопросы

Что считается крупномасштабным e-commerce скрапингом?

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

Как избежать блокировки при скрапинге миллионов страниц товаров?

Распределяйте запросы по большому пулу ротирующихся резидентных IP, чтобы ни один адрес не превышал лимит скорости, держите скорость на каждый IP низкой и рендерите страницы, когда сайту нужен JavaScript. Crawling API и Smart AI Proxy обрабатывают ротацию и разблокирование на стороне сервера; если вы строите собственный стек, именно туда стоит инвестировать. Следите за кодами статусов и немедленно снижайте нагрузку, как только начинают появляться запросы с проверкой.

Использовать ли синхронный Crawling API или асинхронный Crawler?

Используйте синхронный Crawling API для интерактивных или небольших заданий, где вы хотите немедленного ответа. Используйте асинхронный Crawler для больших пакетов: вы отправляете URL, он обходит их в фоновом режиме с обработанными ротацией и повторными попытками, и отправляет каждый готовый результат на ваш вебхук. Для миллионов страниц по расписанию свежести асинхронная модель предотвращает блокировку кода на каждом запросе.

Как поддерживать свежесть собранных данных о ценах?

Обходите по расписанию достаточно часто для вашего случая, что для корректировки цен часто означает ежедневно или чаще. Свежесть увеличивает параллелизм и антибот-давление, поэтому сервис, обрабатывающий ротацию и повторные попытки, позволяет обходить весь каталог в нужном окне. Поставьте полный список URL в очередь Crawler и обрабатывайте результаты по мере их поступления, а не ждите последовательного выполнения.

Нужно ли писать парсеры для каждого ритейлера?

Не обязательно. Scraper API возвращает структурированный JSON для поддерживаемых e-commerce страниц, поэтому вы получаете название, цену, наличие и рейтинги как поля без написания селекторов. Для сайтов, которые он не охватывает, загрузите HTML с Crawling API и парсите с библиотекой вроде Cheerio. Меньше пользовательских парсеров означает меньше вещей, которые молча ломаются при обновлении разметки сайта.

Законно ли скрапить e-commerce сайты в масштабе?

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

FA

Farwa Anees

Технический писатель · Crawlbase

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