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

Question

[danSamara]

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

1. Ключевые особенности системы, которые усложняют выбор фреймворка, склоняя меня к написанию собственного велосипеда

1. Наличие "ядра" системы, которое позволяет динамически подключать/отключать пауков без перезапуска всего сервиса с возможностью мониторинга работы этих пауков. Или наличие API, на который можно будет "накрутить морду".
   
2. Разделение паука на "фетчер": парсинг списков и получение "сырых" (raw html) документов для парсинга с сохранением последних в БД и "парсер": преобразование "сырых" страниц в структурированные данные, с возможностью отдельного запуска "парсера". Одна из главных "фич". Требования к парсеру могут меняться и надо будет перепарсивать все документы сайта заново, коих может быть сотни тысяч. Разумеется без их повторного скачивания.
   
3. Централизованное хранилище "сырых" и распарсенных данных.
   
4. Распределённость - возможность запуска пауков на отдельных нодах. Так как это требование сильно усложняет предыдущее требование, можно его упростить - просто возможность использования прокси.
   
5. Расписание - запуск по времени (каждый час, сутки...) как пауков, так и конкретных тасков в этих пауках, в том числе указание на одноразовый парсинг. Пример: на сайте есть sitemap.xml, содержащий ссылки на другие sitemap: sitemap-2016.xml, sitemap-2017.xml, sitemap-2018.xml; очевидно, что для 2016 и 2017 достаточен один проход фетчера, в то время как 2018 надо периодически просматривать, раз в день, например.
   
6. Приоритеты - возможность указания приоритета для отдельного паука.
   
7. Кэширование - поддержка заголовков Cache-Control и ручного указания: не кэшировать / кэшировать на время / кэшировать по заголовку Cache-Control
   

2. Некритичные хотелки, которыми можно поступиться

1. Использование asyncio. Эта часть стандартной библиотеки Python уже вполне "устаканилась" и, на мой взгляд, потихоньку становится стандартом де факто для асинхронного программирования в Python.
   
2. Простой деплой паука - добавили нового паука на сервер, зашли в "админку" на сайте, включили. Смотрим результаты, смотрим логи. Понизили приоритет. Отключили.
   

3. Инструменты, которые я просмотрел на текущий момент
В принципе выбор не велик и укладывается в три основных:

1. PySpider
   Отличный инструмент, часто пользуюсь им, когда надо получить данные с какого-нибудь сайта. К сожалению некоторые особенности делают проблематичным его использование:
   • Непонятно как разделить на "фетчер" и "парсер", вернее как осуществить отдельный запуск только "парсера".
     
   • Нет встроенной поддержки прокси
     
   • Код пауков редактируется в веб-интерфейсе и не подразумевает использование из файла. Есть возможность запуска отдельного инстанса спайдера с файлом, но этот вариант не подходит - сотни инстансов PySpider убивает саму философию использования этого фрейворка. Да и непонятно как всё это удобно дебажить в IDE.
   
   
2. Grab, а точнее Grab:spider
   Очень интересный легковесный фреймворк, но похоже отсутствует:
   • Возможность централизованного управления пауками
     
   • Расписание запуска отдельных тасков
     
   • Возможность осуществить отдельный запуск только "парсера".
   
   
3. Scrapy
   Самый известный и распиаренный инструмент для написания пауков на Python. Вопросы к нему примерно схожи с вопросами по Grab:spider:
   • Расписание запуска отдельных тасков
     
   • Возможность осуществить отдельный запуск только "парсера".

Итого, что посоветуете: писать своё решение или попытаться использовать фреймворк?

Answer 1

[Dimonchik]

pyspider нравился интерфейсом очень давно, пока не распробовал все части scrapy

Comments

[danSamara]

Спасибо за ответ!
У pyspider своя ниша из которой его выбить тяжело - он великолепно подходит под "одноразовые" задачи - установил, три строки кода, из которых две - селекторы ссылок и через полчаса сайт уже в JSON. Но что-то кастомное лучше не им делать, конечно.

Answer 2

[iSergios]

Мне кажется, Вы не разобрались в теме, начните сначала.

Ключевые особенности системы, которые усложняют выбор фреймворка

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

Любой скраппинг-фреймворк, это удочка. Рыбака Вам самому писать. И не удочка должна решать, как часто и с какой периодичностью запускаться, где хранить наскрапленное и все остальное. Для целей скраппинга у Вас должен быть всего один вопрос: надо парсить JS или нет. Если нет - Ваш выбор BeautifulSoup, ибо очень быстрый. Если да - посмотрите в сторону Selenium.

Comments

[Roman K]

Вот bs советовать - это вообще позор.

[danSamara]

iSergios

Мне кажется, Вы не разобрались в теме, начните сначала

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

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

"Раздельный запуск фетчеров и парсеров" - единственное что отсутствует у всех. Остальное присутствует в приведённых фреймворках. Вы уверены, что сами "в теме"?

Если нет - Ваш выбор BeautifulSoup, ибо очень быстрый.

• BeautifulSoup, lxml и html5lib используют разные подходы к обработке документов. Делать однозначный выбор лучше-хуже по какому-то одному параметру (скорость, качество парсинга, удобство) неверно.
  
• По моим данным lxml быстрее BS. Вы можете обосновать своё утверждение?
  
• Мой выбор - lxml с обёрткой PyQuery - для большинства людей [которые будут писать пауков] это самый простой и быстрый подход.
  
• lxml поддерживает несколько парсеров, в частности есть lxml.html.soupparser
  

[Roman K]

danSamara, очевидно, человек не разбирается в теме, если рекомендует bs.

[danSamara]

Roman Kitaev, возможно, но его ответ прочитает много людей, поэтому ответил подробно.

Answer 3

[Дмитрий]

Scrappy

Из минусов :
* Сложность установки на системе Windows. Поэтому один раз нужно будет поставить . Задокументировать процесс установки.
* У меня были проблемы с кодировками, но это возможно у меня что-то с руками было. Обратите на это свое внимание

Из плюсов:
* Многим известен
* Структурирован
* Много информации по нему

Comments

[danSamara]

Спасибо за ответ!
Windows не использую, поэтому с этим проблем не будет.
А с кодировками были проблемы для какой версии Python - 2 или 3?

[Дмитрий]

danSamara, Я 3-ку использую.

[Prog]

Сложность установки на системе Windows

несколько раз на винду ставил, проблем вообще не было.

Answer 4

[Михаил Сисин]

Писать свой фреймворк с нуля, достаточно тяжелая задача. Сам участвовал в разработке 1 Perl фреймворка, 2-х на Python и одного на Ruby и еще одного на Go (все проприетарные) :) Однако дает возможность выстроить любую архитектуру под свои нужды. Это имеет смысл если объемы большие - сотни и тысячи парсеров и не устраивает архитектура существующих фреймворков.
Пункты 3 и 4 никак друг другу не противоречат, данные вы храните централизованно в базе. Задачи запускаете распределенно через систему управления задачами (воркеры запускающие парсеры, могут находиться на разных хостах). Прокси должны быть обязательно, вне зависимости от степени распределенности.
По поводу желания запускать только парсинг часть, не уверен что это возможно из коробки, но могу предложить обходной путь. Пишется 2 скрапера - один краулер, второй парсер, который парсит локальные страницы.

Answer 5

[Сергей]

Можно попробовать использовать Scrapy как фетчер а потом сырые страницы закидывать в какую-то очередь типа RabbitMQ или Kafka.
Scrapy хорош тем, что он очень модульный (по крайней мере был, когда я последний раз пользовался). Не нравится встроенный планировщик очередей - замени на свой. Не нравится как работает с заголовками / прокси / кешированием - добавляешь свой middleware.

Главная претензия в моём случае была однопоточность и сложность Twisted. Когда начали упираться в производительность переписали на Erlang просто. Но в целом опыт понравился.