Как парсить товары в Интернет-магазинах?

ДЛЯ СПЕЦИАЛИСТОВ ПО АНАЛИЗУ ДАННЫХ В СФЕРЕ ЭЛЕКТРОННОЙ КОММЕРЦИИ: УРОКИ, ИЗВЛЕЧЕННЫЕ ИЗ ПАРСИНГА 100 МИЛЛИАРДОВ СТРАНИЦ ИНТЕРНЕТ-МАГАЗИНОВ:

В наши дни парсинг воспринимается как относительно простая задача. Существуют многочисленные библиотеки/фреймворки с открытым исходным кодом, инструменты визуального парсинга и инструменты извлечения данных, которые делают процесс сбора данных с веб-сайтов очень легким. Однако, как только ваши запросы к парсингу растут до “промышленных” масштабов, то задачи, прежде казавшиеся простыми, внезапно усложняются. В этой серии статей мы поделимся с вами уроками, которые мы извлекли для себя в процессе исследования более чем 100 миллиардов страниц описаний товаров с 2010 года, подробно рассмотрим проблемы, с которыми вы столкнетесь при большом масштабе сбора данных о товарах из интернет-магазинов, и поделимся с вами некоторыми из лучших практик для решения этих трудностей. В этой статье, первой из данной серии, мы даем обзор основных проблем, с которыми вы, вероятно, столкнетесь при крупномасштабном сборе данных, и уроки, которые Scrapinghub извлек из парсинга 100 миллиардов страниц описаний продуктов.

Что важно при парсинге в больших масштабах?

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

Сложность #1 － неряшливые и постоянно меняющиеся форматы страниц веб-сайта

Да, мы говорим об очевидном, и эта проблема стара как мир, но факт в том, что неаккуратные и постоянно меняющиеся форматы веб-сайтов станут самой крупной неприятностью, с которой вы столкнетесь при извлечении данных в крупном масштабе. Не обязательно из-за сложности самой задачи, но скорее из-за времени и ресурсов, которые вы потратите на ее решение. Если вы уже потратили какое-то время на создание парсеров для магазинов электронной коммерции, то вы наверняка знаете, что в интернет-магазинах бушует “эпидемия” кривого кода. И речь идет не о банальной некорректности HTML или случайных проблемах кодирования символов. У нас за годы собрался уже целый “букет” － это и неадекватные коды ответов по HTTP, и битые Java-скрипты, и криво настроенный Ajax:

• Магазины, которые удаляют страницы, когда они снимают с продажи какие-то свои продукты и внезапно начинают возвращать коды ответа “200” на своем обработчике ошибок 404 после обновления веб-сайта.
• Неправильно сохранившиеся данные JSON, которые “ломают” javascript на некоторых страницах (например, ‘b0rk’d’), в результате чего вам нужно чистить эти данные с помощью регулярных выражений.
• Магазины, которые злоупотребляют AJAX-вызовами настолько, что вы можете получить информацию, которая вам нужна только после визуализации страницы (что приводит к замедлению работы парсинга), либо имитируя вызовы API (требуя больше усилий в области разработки).

Небрежный код, подобный этому, может сделать написание вашего парсера сплошным мучением, но, с другой стороны, инструменты визуального парсинга или автоматического извлечения данных там просто не сработают. При “промышленном” масштабе сбора данных вы будете не только продираться через сотни сайтов с “кривым” кодом, но также и иметь дело с постоянно развивающимися сайтами. Очень полезная установка － ожидать, что ваш целевой сайт будет вносить изменения, которые будут ломать ваш поисковый робот (до падения охвата или качества извлечения данных) каждые 2-3 месяца. Это может показаться не слишком большой проблемой, при масштабном сборе данных, эти инциденты действительно вносят свою лепту. Например, один из крупных проектов Scrapinghub по электронной коммерции имеет ~4,000 парсеров, нацеленных на 1000 интернет-магазинов, то есть может случиться и так, что 20-30 парсеров выйдут из строя за день. Если говорить про наш опыт XMLDATAFEED — то работает команда из 3-х программистов, чтобы обеспечить качественный парсинг более чем 250 Интернет-магазинов России. Вариации в макетах веб-сайтов между региональными и многоязычными, сплит-тестирование (A/B-тесты) и варианты упаковки/ценообразования также создают море проблем, которые регулярно “ломают” поисковых роботов.

Нет никакого простого решения

К сожалению, “волшебной таблетки”, которая одним махом решит все эти проблемы, не существует. Во многих случаях это просто вопрос выделения большего количества ресурсов для вашего проекта по мере масштабирования. Возвращаясь вновь к вышеописанному проекту, приведем пример, когда у проекта есть команда, в которой 18 штатных инженеров по парсингу и 3 выделенных инженера по тестированию. Все они были задействованы для того, чтобы стабильно обеспечить клиента надежными данными. С приходом опыта, так или иначе, ваша команда научится создавать все более надежных поисковых роботов, которые станут более “чуткими” и смогут работать с причудливыми завихрениями целевых веб-сайтов. Вместо того, чтобы иметь несколько поисковых ботов для всех возможных макетов целевого веб-сайта, рекомендуется иметь только одного поискового робота, который может иметь работать со всеми возможными правилами и схемами, используемыми различными макетами страниц. Чем более гибок и настраиваем ваш робот, тем лучше. Хотя при таком раскладе вам придется проектировать более сложных поисковых роботов (некоторые из наших парсеров － это тысячи строк кода), такой подход гарантирует, что вашего робота будет проще поддерживать и развивать.

Сложность 2 －масштабируемая архитектура

Следующей задачей является создание инфраструктуры обхода контента, которая будет масштабироваться по мере увеличения количества запросов в день без снижения производительности. При крупномасштабном сборе данных простой парсер, который находит и собирает данные последовательно, просто не будет вырезать их. Как правило, последовательный поисковый робот будет делать запросы в цикле, один за другим, при этом каждый запрос занимает 2-3 секунды. Этот подход хорош, если вам требуется выполнить до 40 000 запросов в день (запрос каждые 2 секунды равен 43 200 запросам в день). Однако, преодолев этот лимит, вам уже понадобится строить такую архитектуру поискового робота, которая позволит обрабатывать миллионы запросов в день без снижения производительности. Поскольку эта тема требует отдельной статьи, мы опубликуем специальный материал, в котором обсудим, как проектировать и создавать свою собственную архитектуру поискового робота с высокой пропускной способностью. Тем не менее, в оставшейся части этого раздела мы обсудим некоторые принципы и лучшие практики сбора данных такого высокого уровня. Как мы уже обсуждали, скорость является ключевым фактором, когда дело доходит до крупномасштабного сбора данных. Вам нужно убедиться, что вы можете найти и пропарсить все необходимые страницы продукта за отведенное время (часто за один день). Для этого вам необходимо сделать следующее:

Отделите обнаружение описания продукта от его извлечения

Чтобы собрать данные об описаниях продуктов в “промышленном” масштабе, нужно отделить роботов для обнаружения данных от роботов для извлечения данных. Цель парсера, который обнаруживает товар, заключается в переходе к целевой категории продукта (“полке” интернет-магазина) и сохранении URL-адреса продукта в этой категории краулера, собирающего данные. Как только робот, отвечающий за обнаружение, добавляет в очередь URL продукта, робот извлечения данных начинает парсинг со страницы продукта. Это может быть достигнуто при помощи специального ограничителя краулеров, такого как Frontera, ограничителя для краулера, разработанного Scrapinghub в виде ПО с открытым кодом. В то время как Frontera изначально была разработана для использования совместно с Scrapy, она может быть использована с любым другим фреймворком для парсинга или с автономным проектом по парсингу. В отдельном руководстве мы рассказываем, как использовать Frontera для крупномасштабного парсинга (на английском).

Выделите больше ресурсов на извлечение описаний продуктов

Поскольку каждая продуктовая категория (“полка”) может содержать от 10 до 100 продуктов, а извлечение данных о продукте является более ресурсоемким, чем извлечение URL-адреса продукта, то роботы для обнаружения описаний обычно работают быстрее, чем роботы извлечения данных из описаний. Когда это так, вам нужно иметь по несколько роботов извлечения для каждого робота обнаружения. Хорошей практикой является создание отдельного робота сбора данных для каждого набора из 100 000 страниц.

Сложность 3 － поддержание пропускной способности

Крупномасштабный парсинг можно сравнить с “Формула-1”, где ваша цель состоит в том, чтобы убрать каждый лишний грамм веса из автомобиля и выжать последние “лошадиные силы” из двигателя в пользу скорости. То же самое верно для сбора большого количества данных из Интернета. При извлечении больших объемов данных вы всегда ищете способы, как минимизировать время цикла и увеличить производительность поискового робота при существующем ресурсе парка серверов. И все это в надежде, что вы сможете сэкономить пару миллисекунд с каждого запроса. Для этого ваша команда должна будет развить глубокое понимание структуры парсинга, управления прокси-серверами и всеми вычислительными мощностями, чтобы вы могли тонко настроить все процессы для оптимальной производительности. Вам также нужно будет сосредоточиться на следующих аспектах:

Эффективность краулинга

При парсинге в “промышленном” масштабе вы всегда должны быть сосредоточены исключительно на точном извлечении данных, которые вам нужны, за как можно меньшее число запросов. Любые дополнительные запросы или извлечение данных замедляют темп обработки конкретного веб-сайта при парсинге. Помните об этих советах при проектировании ваших поисковых роботов.

• Используйте только “непродвинутые” браузеры, такие как Splash или Puppeteer, чтобы отображать javascript в лишь только в крайнем случае. Визуализация javascript с помощью “тупого” браузера во время парсинга очень ресурсоемка и сильно влияет на скорость, с которой можно выполнять исследование.
• Если вы можете получить данные, которые вам нужны, со страницы общей категории продукта (например, название, цена, рейтинг, и т.д.) без запроса каждой страницы описаний, не запрашивайте отдельные страницы.
• Не запрашивайте и не извлекайте изображения, если только в этом действительно нет необходимости.

Сложность 4 － защита от парсинга

Если вы проводите крупномасштабный парсинг интернет-магазинов, то вы гарантированно столкнетесь с веб-сайтами, применяющим меры по борьбе с парсерами. Для большинства небольших веб-сайтов меры по борьбе с парсерами будут довольно простыми (например, запрет IP-адресов, делающих избыточные запросы). Однако, крупные сайты электронной коммерции, таких как Amazon, и т. д. используют более хитрые ловушки против ботов, такие как Distil Networks, Incapsula или Akamai, которые значительно затрудняют сбор данных. Прокси-сервера Имея это в виду, первое и самое важное требование для любого масштабного парсинг-проекта заключается в использовании прокси серверов для парсинга. При масштабировании вам понадобится большой список прокси-серверов, и вам нужно будет реализовать необходимую ротацию IP-адресов, регулирование запросов, управление сеансами и логику черного списка, чтобы предотвратить блокировку ваших прокси-серверов. В том случае, если у вас нет желания или возможности привлечь полноценную команду для управления прокси, вы должны передать эту часть проекта на аутсорсинг. Существует огромное количество прокси-сервисов, которые предоставляют различные варианты обслуживания. Можно обратиться к поставщику прокси-серверов, который может предоставить единую конечную точку для настройки прокси-серверов и скрыть все сложности управления прокси-серверами. Масштабный парсинг и так является достаточно ресурсоемкой задачей, так что, наверное, не стоит заниматься изобретением колеса, пытаясь разрабатывать и поддерживать собственную внутреннюю инфраструктуру управления прокси-сервером. Такой подход используют большинство крупных компаний электронной коммерции. Ряд крупнейших в мире компаний электронной коммерции используют Crawlera －умный загрузчик, разработанный Scrapinghub, который полностью делегирует управление прокси. Когда ваши поисковые роботы делают 20 миллионов запросов в день, гораздо разумнее сосредоточиться на анализе данных, а не на управлении прокси.

Помимо прокси

К сожалению, одной работой с прокси не ограничивается ваша подготовка против контрмер, которые используют крупные сайты электронной коммерции. Все больше и больше веб-сайтов используют сложные приспособления класса “антибот”, которые отслеживают поведение поисковых роботов, обнаруживая, что это не настоящий посетитель. Мало того что эти меры против ботов делают парсинг интернет-магазинов более трудным, попытки их обхода могут значительно снизить производительность поисковых роботов, если не вывести их вообще из строя. Большая часть этих приспособлений использует javascript, чтобы определить, исходит ли запрос от робота или от человека (проверки движка Javascript, перечисление шрифтов, WebGL и Canvas и т. д.). Однако, как упоминалось ранее, при масштабном сборе данных мы стремимся ограничить использование скриптовых безголовых браузеров, таких как Splash или Puppeteer, которые отображают любой javascript на странице, поскольку это очень ресурсоемко и замедляет скорость, с которой вы можете обработать веб-сайт. Это означает, что для обеспечения необходимой пропускной способности ваших поисковых роботов для получения ежедневных данных о продукте, вам часто нужно кропотливо преодолевать контрмеры против ботов, используемые на сайте, и разрабатывать своего робота так, чтобы противодействовать им без использования “неинтеллектуального” браузера.

Сложность 5 － качество данных

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

• Ошибки валидации данных －каждый элемент данных имеет определенный тип данных и значения, соответствующие согласованному шаблону. Наши алгоритмы проверки данных будут помечать для команды QA любые элементы данных, которые не соответствуют ожидаемым для этого типа данных, с этого момента данные проверяются вручную и отмечаются как проверенные или как ошибка.
• Ошибки изменения описания －при сборе одних и тех же данных о продукте с нескольких версий одного и того же веб-сайта (разные языки, регионы и т. д.) возможно, что переменные и предположительно фиксированные значения － такие, как вес или размеры продукта － могут различаться. Это может быть в том числе и результатом мер против ботов, используемых веб-сайтами, когда они выдают одному или нескольким вашим роботам фальсифицированную информацию. Опять же, вам нужно иметь алгоритмы для идентификации и маркировки любых нестыковок, таких как эта.
• Несоответствия в объеме －другой ключевой сценарий мониторинга, который обнаруживает аномальные изменения в количестве возвращаемых записей. Это может означать, что были внесены изменения на веб-сайт или что ваш поисковый робот получает фальсифицированную информацию.
• Изменения сайта －структурные изменения, происходящие с целевыми веб-сайтами, являются основной причиной сбоя поисковых роботов. Это довольно тщательно контролируется специальной системой мониторинга. Инструмент часто проверяет целевой сайт, чтобы убедиться, что с момента предыдущего сбора данных ничего не изменилось. Если изменения найдены, он отправляет уведомления.

Подводя итоги парсинга Интернет- магазинов

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