Для получения дополнительных галантерейных товаров, пожалуйста, обратите внимание на публичный аккаунт WeChat «AI Frontline» (ID: ai-front)
Компания Scrapinghub, основанная в 2010 году, является ведущей компанией по обработке данных, разработавшей Scrapy, самую мощную и популярную на сегодняшний день инфраструктуру веб-скрейпинга. В настоящее время Scrapinghub сканирует 8 миллиардов веб-страниц в месяц (3 миллиарда из которых являются страницами продуктов) для многих крупнейших мировых компаний электронной коммерции.
В отличие от стандартных приложений для сканирования, сбор данных о продуктах электронной коммерции в масштабе представляет собой уникальный набор проблем, которые усложняют сканирование веб-страниц.
Эти проблемы можно разделить на две категории: скорость и качество данных.
Поскольку время часто является ограничивающим фактором, крупномасштабное сканирование требует, чтобы программа-обходчик сканировал очень быстро, не ставя под угрозу качество данных. Это чрезвычайное требование к скорости делает сканирование больших объемов данных о продуктах чрезвычайно сложным.
Очевидно, что беспорядочный код и меняющиеся веб-форматы являются самыми большими проблемами при сборе данных в больших масштабах. Не обязательно из-за сложности задачи, а из-за времени и ресурсов, которые вы собираетесь на нее потратить.
Если вы когда-либо занимались обходом интернет-магазина, вы знаете, что беспорядочный код заполняет страницы интернет-магазина. Есть много других проблем, кроме проблем с форматированием HTML или случайных проблем с кодировкой символов. На протяжении многих лет у нас возникали всевозможные проблемы — неправильное использование кодов ответов HTTP, плохие сценарии JavaScript или неправильное использование Ajax:
Интернет-магазин удалил соответствующую страницу продукта, когда перестал продавать определенные товары, но после обновления сайта обработчик ошибки 404 вернул код ответа 200.
Данные JSON неправильно экранированы, в результате чего код JavaScript на некоторых страницах не работает должным образом (например, «b0rk'd»), и вам приходится использовать регулярные выражения для очистки данных.
Злоупотреблять Ajax, чтобы вы могли получать нужную информацию только после рендеринга страницы (что приводит к замедлению сканирования) или имитации вызовов API (что приводит к дополнительным усилиям по разработке).
Эти запутанные коды являются не только проблемой при разработке поискового робота, но также влияют на визуальные или автоматические инструменты поискового робота.
При крупномасштабном сканировании, помимо работы с этими запутанными кодами, он также сталкивается с проблемами, связанными с постоянными изменениями веб-сайта. Как правило, целевой веб-сайт обычно изменяется каждые 2-3 месяца, и у вашего поискового робота возникают проблемы (вызывающие снижение охвата или качества сканирования).
Это может показаться не таким уж большим делом, но при скрейпинге в масштабе эти проблемы складываются в большие неприятности. Крупный проект электронной коммерции в Scrapinghub использует около 4000 сканеров для сканирования примерно 1000 сайтов электронной коммерции, а это означает, что они сталкиваются с 20-30 сбоями сканеров в день.
Изменения в макетах страниц, A/B-тестировании, наборах продуктов и ценах для различных региональных и многоязычных сайтов также создают дополнительные проблемы для поисковых роботов.
Нет простого решения
Панацеи от этих проблем нет. Во многих случаях при масштабировании к проекту добавляется больше ресурсов. Возьмем приведенный выше проект в качестве примера. Команда этого проекта состоит из 18 штатных инженеров по поиску и 3 штатных инженеров по контролю качества, чтобы гарантировать, что данные могут непрерывно предоставляться клиентам.
Однако, исходя из опыта, вашей команде все еще нужно научиться разрабатывать более мощные поисковые роботы, которые могут обнаруживать и обрабатывать все виды странных веб-форматов.
Лучше разработать только один сканер, который может обрабатывать разные макеты страниц, чем разрабатывать несколько сканеров для разных макетов страниц.Чем выше возможности настройки сканера, тем лучше.
Хотя это усложняет поисковые роботы (некоторые из наших поисковых роботов состоят из тысяч строк кода), их также проще поддерживать.
Большинству компаний необходимо сканировать данные о продуктах каждый день, и не стоит ждать несколько дней, пока команда инженеров исправит сканеры. Когда это происходит, Scrapinghub использует инструменты извлечения данных на основе машинного обучения. Этот инструмент извлечения на основе ML автоматически определяет целевые поля (название продукта, цена, тип валюты, изображение, SKU и т. д.) на целевом веб-сайте и возвращает желаемые результаты.
Вторая задача — создать масштабируемую инфраструктуру поискового робота, которая может масштабироваться по мере увеличения количества запросов без ущерба для производительности.
При масштабном сканировании данных о продуктах простого веб-сканера, который может сканировать данные только последовательно, недостаточно. Как правило, сериализованные сканеры делают запросы один за другим в цикле, каждый из которых занимает 2–3 секунды.
Если ваш сканер делает менее 40 000 запросов в день (один запрос каждые 2 секунды эквивалентен 43 200 запросам в день), то этого метода достаточно. Однако после этого вам необходимо переключиться на архитектуру сканера, которая может сканировать миллионы веб-страниц в день без снижения производительности.
Скорость сканирования — это ключ к сбору данных о продуктах в масштабе. Вы хотите быть уверены, что сможете найти и просканировать все необходимые страницы продукта в течение заданного периода времени (обычно за день). Для этого вам необходимо сделать следующее:
Позволяет разделить обнаружение продукта и захват продукта
Чтобы собирать данные о продуктах в масштабе, сканеры обнаружения продуктов должны быть отделены от сканеров продуктов.
Искатель для обнаружения продуктов в первую очередь отвечает за переход к целевой категории продуктов (или «полке») и сохранение URL-адреса продукта в этой категории для сканера извлечения продуктов. После того, как искатель обнаружения продуктов добавит URL-адрес продукта в очередь, искатель продуктов просматривает целевые данные со страницы этого продукта.
Для этого Scrapinghub разработал Frontera (https://github.com/scrapinghub/frontera) и открыл исходный код, и, хотя Frontera изначально был разработан для использования со Scrapy, его также можно использовать с другими средами сканирования или автономными проектами. В этой статье (https://blog.scrapinghub.com/2015/04/22/frontera-the-brain-behind-the-crawls/) мы рассказали, как использовать Frontera для масштабного сканирования HackerNews.
Выделите больше ресурсов для сканирования продукта
Каждая категория продуктов может содержать от 10 до 100 продуктов, а сканирование данных о продуктах требует больше ресурсов, чем сканирование URL-адресов продуктов, поэтому сканеры обнаружения продуктов обычно работают быстрее, чем сканеры продуктов. Таким образом, вам нужно иметь несколько поисковых роботов для каждого поискового сканера. Как правило, для каждых 100 000 веб-страниц требуется отдельный сканер.
Ползание по массе можно сравнить с автомобилем Формулы-1, где ваша конечная цель состоит в том, чтобы убрать из автомобиля каждый ненужный грамм веса и выжать из двигателя все лошадиные силы во имя скорости. То же самое касается крупномасштабного парсинга веб-страниц.
При сканировании больших объемов данных вы всегда ищете способы минимизировать время цикла запроса и максимизировать производительность сканера, чтобы сократить время запроса на несколько миллисекунд.
Вашей команде необходимо глубокое понимание используемых структур сканеров, прокси-серверов и оборудования, чтобы настроить их для достижения оптимальной производительности. Кроме того, необходимо обратить внимание на:
Эффективность сканирования
При крупномасштабном сканировании следует как можно больше сканировать только необходимые данные. Дополнительные запросы или очистка данных могут замедлить сканирование сайта. При проектировании краулера помните следующее:
Используйте безголовые браузеры (такие как Splash или Puppeteer) для анализа JavaScript только в случае крайней необходимости, потому что анализ JavaScript с помощью безголовых браузеров довольно ресурсоемок и серьезно повлияет на скорость сканирования.
Если вы можете получить необходимые данные со страницы продукта (например, название продукта, цена, рейтинг и т. д.), не запрашивая каждую страницу продукта, не запрашивайте страницу продукта.
Не запрашивайте и не захватывайте изображения, если вам это действительно не нужно.
Если вы просматриваете сайты электронной коммерции в больших масштабах, вы обязательно столкнетесь с сайтами, которые используют меры по борьбе с ботами.
Большинство небольших веб-сайтов используют базовые меры защиты от ботов (например, блокировку часто посещаемых IP-адресов). А крупные сайты электронной коммерции, такие как Amazon, используют сложные средства защиты от ботов, такие как Distil Networks, Incapsula или Akamai, что затрудняет сбор данных.
играет роль
Поэтому при сканировании крупномасштабных данных о продуктах в первую очередь необходимо рассмотреть возможность использования прокси. Вам нужно много прокси, и вам нужно реализовать ротацию IP-адресов, регулирование запросов, управление сеансами и логику черного списка, чтобы предотвратить блокировку прокси.
Если у вас нет или вы не хотите содержать большую команду для управления прокси-сервером, вам следует передать эту часть процесса очистки на аутсорсинг. Сейчас существует большое количество прокси-сервисов, и они предлагают разный уровень обслуживания.
Мы рекомендуем работать с поставщиком прокси, который может предоставить единую конечную точку для настройки прокси и скрыть сложность управления прокси. Масштабное сканирование очень ресурсоемко, поэтому вам не следует самостоятельно изобретать велосипед, например, разрабатывать и поддерживать собственную внутреннюю инфраструктуру управления прокси.
вне агентства
Однако простого использования прокси-службы недостаточно, чтобы гарантировать, что вы сможете обойти меры защиты от ботов на крупных сайтах электронной коммерции, и все больше и больше сайтов используют сложные меры защиты от ботов для мониторинга ваших поисковых роботов.
Эти меры по борьбе с ботами не только затрудняют сканирование сайтов электронной коммерции, но и, если их не принять должным образом, могут серьезно повлиять на производительность сканера.
В большом проценте этих мер по борьбе с ботами используется JavaScript, чтобы определить, исходит ли запрос от поискового робота или человека (проверка механизма JavaScript, перечисление шрифтов, WebGL, Canvas и т. д.).
Однако, как упоминалось ранее, при крупномасштабном сканировании старайтесь ограничить использование безголовых браузеров (таких как Splash или Puppeteer) для анализа JavaScript, поскольку они очень ресурсоемки и могут снизить скорость сканирования страниц.
Таким образом, чтобы обеспечить пропускную способность ваших поисковых роботов для ежедневного предоставления необходимых данных о продукте, вам обычно необходимо тщательно перепроектировать меры по борьбе с ботами вашего веб-сайта, позволяя вашим поисковым роботам делать все без использования автономного браузера.
С точки зрения специалиста по обработке и анализу данных, самым важным фактором для проекта сканера является качество получаемых данных, а крупномасштабное сканирование только делает акцент на качестве данных еще более важным.
Извлечение миллионов точек данных в день делает невозможным ручную проверку чистоты и целостности всех данных. Грязные или неполные данные могут легко попасть в ваши источники данных и нарушить ваши усилия по анализу данных.
Вопросы качества данных особенно важно учитывать при сканировании нескольких версий одного и того же веб-сайта (разные языки, регионы и т. д.) или разных веб-сайтов одного и того же продукта.
На этапе проектирования сканера требуется строгий процесс контроля качества, а код сканера должен пройти тщательную проверку и тестирование, чтобы гарантировать, что необходимые данные могут быть извлечены наиболее надежным способом. Лучший способ обеспечить высокое качество данных — разработать автоматизированную систему контроля качества.
В рамках проекта очистки данных спланируйте и разработайте систему мониторинга, которая будет предупреждать вас при обнаружении несоответствий или ошибок в данных. В Scrapinghub мы разрабатываем алгоритмы машинного обучения для обнаружения:
Ошибки проверки данных — каждый элемент данных имеет определенный тип данных, и их значения следуют согласованному шаблону. Наши алгоритмы проверки данных могут помечать элементы данных, которые не соответствуют ожидаемому типу данных, а группа обеспечения качества вручную проверяет данные и выдает предупреждение или помечает их как ошибку.
Ошибки отклонения продукта. При извлечении одних и тех же данных о продукте из нескольких версий одного и того же веб-сайта (разные языки, регионы и т. д.) некоторые переменные (например, вес или размеры продукта) могут иметь разные значения. Это может быть поддельная информация, предоставленная поисковым роботам средствами защиты сайта от ботов. Опять же, вам нужно иметь алгоритмы для идентификации и маркировки таких данных.
Несоответствия объемов данных. Еще одним важным действием по мониторингу является обнаружение аномально возвращенных объемов данных. Если есть исключение, это может быть связано с тем, что веб-сайт изменился или веб-сайт предоставил ложную информацию вашему сканеру.
Изменения веб-сайта. Структурные изменения целевого веб-сайта являются основной причиной сбоев поисковых роботов. За этим следит наша специальная система мониторинга, которая часто проверяет целевой веб-сайт, чтобы убедиться, что с момента последнего сканирования ничего не изменилось. Он отправит уведомление, если есть изменения.
В этой статье описывается уникальный набор проблем, возникающих при масштабном сканировании данных о продуктах. Для тех, кто интересуется крупномасштабным парсингом веб-страниц, см. статью Корпоративный парсинг веб-страниц: руководство по парсингу веб-страниц в масштабе (https://info.scrapinghub.com/enterprise-web-scraping-scraping-at-scale)).
Английский оригинал:
https://blog.scrapinghub.com/web-scraping-at-scale-lessons-learned-scraping-100-billion-products-pages