Веб-краулингтехники и фреймворки

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

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

Что такое веб-краулинг?

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

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

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

Основные техники веб-краулинга

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

Обход в ширину vs обход в глубину

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

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

Фронтир URL и дедупликация

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

Сопутствующая проблема, дедупликация. Одна и та же страница достижима через множество URL, параметров отслеживания и цепочек редиректов, поэтому без шага дедупликации краулер скачивает один и тот же контент снова и снова и может зациклиться навсегда. Стандартное решение, нормализовать каждый URL (привести хост к нижнему регистру, убрать стандартные порты, удалить фрагменты и известные параметры отслеживания) и проверить его по набору уже увиденных URL. Для очень крупных краулингов этот набор часто представлен памятеэффективной структурой, такой как фильтр Блума, которая отвечает на вопрос «видел ли я этот URL?», используя долю памяти по сравнению с полным списком.

Вежливость и ограничение скорости

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

Хорошая вежливость сочетает несколько привычек. Ограничивайте параллельность на домен, а не глобально, чтобы ни один сайт не был переполнен. Соблюдайте любую задержку обхода (Crawl-delay), которую рекламирует сайт, и снижайте интенсивность при ошибках или медленных ответах, поскольку испытывающий затруднения сервер нужно нагружать меньше, а не больше. Помимо вежливости, это практично: мягкий, корректно идентифицированный трафик гораздо реже задевает ограничения скорости, чем агрессивный краулинг, поэтому вежливость и надёжность указывают в одном направлении.

Соблюдение robots.txt

Большинство сайтов публикуют файл robots.txt в корне, указывающий, какие пути краулеры могут и не могут посещать и к каким агентам применяются правила. Хорошо настроенный краулер получает и разбирает этот файл перед обходом хоста, а затем пропускает любые запрещённые пути. Файл также может рекламировать задержку обхода Crawl-delay и указывать на карту сайта, готовый список URL, которые сайт хочет видеть обойдёнными.

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

Обработка JavaScript-рендеринга

Растущая доля веба строит свой контент в браузере. HTML, возвращаемый обычным HTTP-запросом, почти пуст до запуска клиентского JavaScript и внедрения реального контента. Краулер, читающий только начальный ответ, увидит почти ничего на таких страницах. Чтобы их обходить, нужно рендерить страницу так, как это делает браузер, то есть запускать headless-браузер, управляемый Puppeteer, Playwright или Selenium, который выполняет скрипты и возвращает полностью построенный DOM.

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

Распределённый краулинг

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

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

Инкрементный и фокусированный краулинг

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

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

Фреймворки для веб-краулинга

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

Scrapy

Scrapy, наиболее популярный фреймворк для краулинга в экосистеме Python и обычная отправная точка для кастомных краулеров. Он даёт весь конвейер: асинхронный движок, параллельно получающий множество страниц, планировщик запросов, управляющий фронтиром, автоматическое следование ссылкам, повторные попытки и встроенный экспорт структурированных данных в JSON, CSV или XML. Вы пишете пауков, определяющих начальную точку и разбор каждой страницы, а Scrapy обрабатывает параллельность и очереди под капотом. Это правильный выбор для регулярных краулингов тысяч и миллионов страниц, где нужна структура и контроль. Vanilla Scrapy не выполняет JavaScript, хотя интегрируется с браузерными инструментами, когда цель требует рендеринга.

Apache Nutch

Apache Nutch, зрелый краулер с открытым исходным кодом, созданный для веб-масштабного краулинга и тесной интеграции с поисковым миром. Он работает поверх Apache Hadoop, так что его краулинг по своей природе распределён по кластеру, и подключается к бэкендам индексации, таким как Apache Solr или Elasticsearch. Nutch построен вокруг классического цикла краулинга поисковых систем (генерация списка для получения, получение, разбор, обновление базы данных краулинга) и расширяем через систему плагинов для протоколов, парсеров и фильтров. Он тяжелее в эксплуатации, чем Scrapy, и нацелен на команды, обходящие очень большие части веба, которым нужен проверенный конвейер на базе Hadoop.

Heritrix

Heritrix, краулер, созданный Internet Archive и используемый для захвата страниц для Wayback Machine. Он предназначен для тщательных, архивного качества краулингов и записывает результаты в стандартном формате WARC, сохраняя полные данные запросов и ответов для долгосрочного архивирования. Heritrix высоко настраиваем в части правил охвата, вежливости и того, что захватывать, и по умолчанию строго соблюдает robots.txt. Обращайтесь к нему, когда цель, точное, полное сохранение страниц, например при создании веб-архива, а не извлечение нескольких полей для анализа.

StormCrawler

StormCrawler, набор ресурсов для создания низколатентных, масштабируемых веб-краулеров на Apache Storm. Поскольку Storm, система потоковой обработки, StormCrawler краулит непрерывно, а не пакетами, что подходит для задач, требующих свежих данных на постоянной основе, например для новостных краулингов и мониторинга. Он модульный, написан на Java и позволяет собирать топологию краулинга из компонентов для получения, разбора и индексации. Он занимает нишу, схожую с Nutch, но предпочитает непрерывный, реального времени краулинг в противовес пакетной модели Nutch.

Управляемый краулинг с Crawlbase

Описанные выше фреймворки дают логику краулинга, но оставляют сетевые проблемы вам: ротирующиеся IP, JavaScript-рендеринг, решение или обход CAPTCHA и повторные попытки при заблокированных запросах. Управляемый сервис краулинга поглощает этот слой. С Crawlbase вы отправляете URL и получаете обратно отрендеренный HTML, с ротацией прокси и анти-блок обработкой на стороне сервера, а асинхронный Crawler ставит в очередь большие партии и доставляет результаты по callback. Он не заменяет вашу стратегию краулинга, выбор начальных URL, обход и парсинг остаются за вами, но устраняет инфраструктуру, которую сложнее всего поддерживать в масштабе.

Фреймворки в сравнении

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

Ни одна строка не является ответом на каждый краулинг. Scrapy покрывает большинство кастомных задач, Nutch и StormCrawler обрабатывают веб-масштабные и непрерывные краулинги, Heritrix специализируется на архивировании, а управляемый API берёт на себя ротацию и рендеринг, которые ни один из фреймворков с открытым исходным кодом не решает из коробки.

Ответственный краулинг

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

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

В чём разница между веб-краулингом и веб-скрейпингом?

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

Должен ли краулер использовать обход в ширину или в глубину?

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

Что такое URL-фронтир?

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

Как краулеры избегают повторного скачивания одной страницы?

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

Обязаны ли веб-краулеры соблюдать robots.txt?

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

Какой фреймворк для веб-краулинга мне использовать?

Зависит от задачи. Scrapy подходит для большинства кастомных краулингов тысяч и миллионов страниц. Apache Nutch и StormCrawler нацелены на веб-масштабный и непрерывный краулинг. Heritrix создан для архивного, полного захвата. Если сложная часть, оставаться разблокированным, а не логика краулинга, управляемый crawling API берёт на себя ротацию, рендеринг и повторные попытки, так что вы можете сосредоточиться на обходе и парсинге.

BA

Bilal Ahmed

Инженер-программист · Crawlbase

Инженер-программист, написавший некоторые из самых читаемых материалов в блоге Crawlbase о веб-скрейпинге, прокси и инструментах для работы с данными.