Выбирать open-source краулер проще, если разделить систему на четыре роли: общий сбор, автоматизацию браузера, планирование и очереди, а также парсинг и хранение. Здесь разобраны задачи каждого слоя, типичные ошибки интеграции и четыре практических критерия.
Поиск краулеров на GitHub может выдать сотни или даже тысячи репозиториев. Многие выбирают проект по количеству звёзд и начинают с самого популярного.
Популярность и соответствие вашей задаче — разные вещи. Даже очень известный проект создаст лишние трудности, если его назначение не совпадает с вашим сценарием. Проще начинать с разделения обязанностей: система сбора данных, которая должна стабильно работать долгое время, обычно состоит из нескольких компонентов с разными функциями. Когда понятно, что делает каждый из них, сравнивать конкретные реализации намного легче.
Общие фреймворки для crawling: для страниц со стабильной структурой
Такие фреймворки отвечают за планирование запросов, параллельную загрузку и конвейеры данных. На вход подаётся набор URL, на выходе получаются структурированные результаты. Зрелая экосистема и middleware позволяют добавлять собственную логику и поддерживать длительные задачи очень большого масштаба.
Самостоятельно они не справятся со страницами, где содержимое появляется только после выполнения JavaScript. В таком случае исходный ответ представляет собой лишь пустую оболочку, поэтому нужен дополнительный движок рендеринга. Этот подход хорошо подходит для стабильных целей: страниц списков, карточек и открытых API.
Автоматизация браузера: для рендеринга и взаимодействия
Страницы, которым нужен настоящий рендеринг, авторизованная сессия или несколько кликов до появления содержимого, следует отдавать автоматизации браузера. Такие инструменты работают с разными движками, имеют зрелые механизмы ожидания и позволяют напрямую перехватывать запросы и ответы страницы.
Цена — значительно большее потребление ресурсов, чем при обычных HTTP-запросах. Предел параллелизма в основном определяется локальной памятью и CPU. Кроме того, автоматизация оставляет обнаруживаемые признаки, и сайты со строгими проверками могут их распознавать.
Планирование и очереди: нужны при росте числа задач
Если целей мало, достаточно простого цикла. Когда задач становятся тысячи и требуется управлять частотой и повторами, нужен отдельный слой планирования: как ставить задачи в очередь, сколько выполнять параллельно, сколько ждать перед повтором после ошибки и какие задачи прекращать. Если поместить всю эту логику внутрь crawler framework, код быстро станет трудно поддерживать.
Типичная ошибка при самостоятельной сборке такого слоя — использовать очередь только в памяти процесса. После перезапуска процесса все ожидающие задачи исчезнут. Как минимум очередь должна быть постоянной и позволять проверять состояние.
Парсинг и хранение: определяют, можно ли сразу использовать данные
Получаем мы HTML, а нужны конкретные поля. Слой парсинга должен управлять правилами извлечения, проверять поля, удалять дубликаты и записывать данные в хранилище. Для сайтов, которые часто меняют структуру, можно рассмотреть адаптивное извлечение: оно ищет данные по признакам страницы, а не по жёстко заданным селекторам, что снижает объём обслуживания.
На стороне хранения важна идемпотентность. Повторные попытки — нормальная ситуация, поэтому записи нужно дедуплицировать по уникальному идентификатору; иначе дубли будут загрязнять последующий анализ.
Проблемы, которые часто возникают после объединения компонентов
По отдельности каждый компонент несложен. Проблемы обычно появляются на стыках.
- Слой планирования повторяет задачу, а слой парсинга не выполняет дедупликацию, и появляются повторяющиеся строки
- В браузерном слое нет ограничения параллелизма, локальные ресурсы исчерпываются и падает вся партия задач
- Правила парсинга жёстко записаны в коде, поэтому после изменения сайта требуется выпуск новой версии
- Компоненты используют разные идентификаторы для одной задачи, состояния не совпадают и продолжение с точки остановки становится невозможным
Четыре критерия оценки
После определения нужной категории используйте эти четыре критерия для отбора конкретных проектов.
При оценке активности поддержки смотрите на частоту коммитов и скорость ответов на issues за последние месяцы, а не на общее число звёзд. Проект, который перестали поддерживать, может сразу перестать работать после изменения целевого сайта.
Документация и примеры определяют стоимость освоения. Если документация расплывчатая или показывает только самые простые случаи, время обучения часто оказывается больше ожидаемого.
Для оценки расширяемости проверьте доступные точки подключения: можно ли сменить прокси, подключить собственный движок рендеринга или заменить хранилище. Если такие точки предусмотрены, дальнейшие изменения часто можно делать без правки исходного кода.
Риски лицензирования и соответствия требованиям легко упустить. Перед коммерческим использованием проверьте тип лицензии и избегайте лицензий, не совместимых с предполагаемым использованием. Также оценивайте объём сбора, частоту запросов и условия целевого сайта; это отдельные вопросы, не связанные с техническим качеством фреймворка.
Слой окружения — это отдельный уровень
Фреймворк решает, как собирать данные, но не вопросы идентичности и масштаба. Если задачи требуют входа в аккаунт, разделения по регионам или параллельной работы нескольких аккаунтов, запуск всего в одной браузерной среде создаёт две проблемы: сессии влияют друг на друга из-за пересечения cookie и локального хранилища, а целевой сайт может воспринимать независимые задачи как одну группу обращений.
Зрелый подход — сделать браузерные среды независимым слоем ресурсов. Задачи получают среду из пула и освобождают её после использования. В такой архитектуре PurpleMark занимает именно этот слой и предоставляет ресурсы среды, которые можно создавать пакетно, привязывать к независимым сетевым выходам и проверять по состоянию.
Границы соответствия требованиям
Соблюдайте правила robots и условия использования целевого сайта, не собирайте персональную информацию, не обходите технические меры защиты и ограничивайте частоту запросов так, чтобы не мешать нормальной работе сервиса. Выбор проекта решает вопрос эффективности; эти оценки определяют, допустимо ли вообще выполнять такой сбор.
