Как парсить большие объёмы данных без блокировокоставайтесь незаблокированными при масштабировании

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

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

Почему сайты блокируют крупные скрейпы

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

Сайты также публикуют свои предпочтения в файле robots.txt, который описывает, что автоматизированным клиентам следует и чего не следует касаться и насколько агрессивно. Помимо этого они развёртывают активные защиты: лимиты скорости на адрес, CAPTCHA, стены авторизации, браузерное снятие отпечатков и ссылки-ловушки, скрытые от человеческих глаз, но видимые в HTML, так что любой клиент, перешедший по ним, выдаёт себя как бот. Ни одна из этих защит не направлена против людей. Они направлены именно против поведения, которое производит ненастроенный скрейпер. Избежание блокировок, таким образом, в основном сводится к тому, чтобы не выглядеть как то, что эти системы созданы ловить. Разделы ниже описывают техники, которые до этого доводят.

Ротируйте IP-адреса

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

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

Задавайте темп запросов и соблюдайте лимиты скорости

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

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

Отправляйте реалистичные заголовки

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

Подбор заголовков, которые отправляет настоящий браузер, и варьирование user agent по пулу реальных, а не повторное использование одной строки для каждого запроса, помогает каждому запросу вписаться. Заголовки должны быть также внутренне согласованными: Accept-Language и user agent, противоречащие друг другу, сами по себе являются признаком. Цель состоит в том, чтобы каждый запрос был неотличим от того, что произвёл бы браузер человека, и не было ничего в самом запросе, что выделяло бы его.

Рендерите страницы, которым нужен JavaScript

Растущая доля веба не доставляет свой контент в исходном HTML. Одностраничные приложения и динамические сайты загружают скелет, затем получают и рендерят реальные данные с помощью JavaScript в браузере. Обычный HTTP-запрос к одной из таких страниц возвращает почти ничего полезного, потому что нужный вам контент никогда не существовал в необработанном ответе.

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

Повторяйте только неудавшиеся запросы

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

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

Платите только за успешные запросы

У крупномасштабного парсинга есть экономическая сторона, которую легко не заметить до прихода счёта. Если вы запускаете собственный пул прокси и ферму браузеров, вы платите за каждый отправленный запрос, включая те, что заблокированы, истекли по тайм-ауту или вернулись пустыми. В задании на миллион запросов с ненулевым уровнем сбоев эта трата, реальные деньги, потраченные на данные, которых вы так и не получили.

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

Как управляемый API для парсинга справляется с задачей

Каждая из вышеперечисленных техник проста сама по себе. Сложность состоит в одновременном и надёжном запуске всех них для миллионов запросов с сохранением их работоспособности по мере того, как целевые сайты меняют свои защиты. Именно этот пробел заполняет управляемый API для парсинга. Вместо того чтобы самостоятельно собирать и поддерживать пул прокси, слой ротации заголовков, ферму headless-браузеров, очередь повторных попыток и решатель CAPTCHA, вы отправляете URL на единый эндпоинт и получаете обратно чистые данные.

Под капотом API ротирует IP-адреса по большому пулу, задаёт темп и формирует запросы так, чтобы они выглядели человекоподобно, отправляет реалистичные заголовки, рендерит страницы с тяжёлым JavaScript в настоящем браузерном движке при необходимости, решает или обходит CAPTCHA и повторяет переходящие сбои, и всё это до возврата ответа. Для заданий, слишком больших для синхронного выполнения, асинхронный режим позволяет отправлять URL пакетами и получать результаты через обратный вызов по мере их завершения, не удерживая открытых миллионов соединений. В результате антибанная работа становится чьей-то чужой проблемой, а вы тратите время на данные, а не на водопровод. Для более широкого представления о запуске заданий такого размера см. наше руководство по крупномасштабному веб-скрейпингу и лучшие практики масштабирования проектов по парсингу.

Ответственный парсинг

Избежание блокировок, техническая проблема, но она находится внутри этической. Парсите только публичные данные и проверяйте условия использования сайта и его robots.txt перед запуском крупного задания. Поддерживайте разумную частоту запросов, чтобы не ухудшать сервис для людей, для которых он фактически создан: обход, достаточно тяжёлый, чтобы нагрузить сайт, одновременно груб и контрпродуктивен. Когда собираемые вами данные включают что-либо персональное, относитесь к таким регуляторным актам, как GDPR и CCPA, как к жёстким требованиям, а не послесловию: собирайте только то, что нужно, агрегируйте там, где можете, и не стройте профили физических лиц. Ответственный парсинг и незаблокированный парсинг направлены в одну сторону, потому что поведение, сохраняющее соответствие требованиям, обычно то же самое поведение, которое не даёт вам выглядеть как абьюзивный бот.

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

Почему сайты банят скрейперы, если данные публичны?

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

Какая одна техника наиболее важна для избежания блокировки?

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

С какой скоростью я могу парсить без блокировки?

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

Всегда ли мне нужен headless-браузер для парсинга в масштабе?

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

Что означает «платить только за успешные запросы»?

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

Чем API для парсинга помогает по сравнению с созданием собственного скрейпера?

Управляемый API выполняет ротацию, ограничение темпа, управление заголовками, рендеринг JavaScript, обработку CAPTCHA и повторные попытки за единым эндпоинтом, поэтому вы отправляете URL и получаете чистые данные обратно, не создавая и не поддерживая каждый из этих уровней самостоятельно. Он также адаптируется по мере того, как целевые сайты меняют свои защиты, что является постоянной работой на самодельной установке. Для очень крупных заданий асинхронный режим позволяет отправлять URL пакетами и собирать результаты через обратный вызов, а не удерживать открытыми миллионы соединений.