Задать вопрос
@danSamara
python

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

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

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:
    • Расписание запуска отдельных тасков
    • Возможность осуществить отдельный запуск только "парсера".


Итого, что посоветуете: писать своё решение или попытаться использовать фреймворк?
  • Вопрос задан
  • 5552 просмотра
Комментировать
Подписаться 24 Простой Комментировать
Пригласить эксперта
Ответы на вопрос 5
dimonchik2013
@dimonchik2013
non progredi est regredi
pyspider нравился интерфейсом очень давно, пока не распробовал все части scrapy
Ответ написан
1 комментарий
1 комментарий
@iSergios
Python-разработчик
Мне кажется, Вы не разобрались в теме, начните сначала.
Ключевые особенности системы, которые усложняют выбор фреймворка

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

Любой скраппинг-фреймворк, это удочка. Рыбака Вам самому писать. И не удочка должна решать, как часто и с какой периодичностью запускаться, где хранить наскрапленное и все остальное. Для целей скраппинга у Вас должен быть всего один вопрос: надо парсить JS или нет. Если нет - Ваш выбор BeautifulSoup, ибо очень быстрый. Если да - посмотрите в сторону Selenium.
Ответ написан
4 комментария
4 комментария
EvilsInterrupt
@EvilsInterrupt
System programming, Reversing Engineering, C++
Scrappy

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

Из плюсов:
* Многим известен
* Структурирован
* Много информации по нему
Ответ написан
3 комментария
3 комментария
JabbaHotep
@JabbaHotep
Пытаюсь минимизировать ручную работу
Писать свой фреймворк с нуля, достаточно тяжелая задача. Сам участвовал в разработке 1 Perl фреймворка, 2-х на Python и одного на Ruby и еще одного на Go (все проприетарные) :) Однако дает возможность выстроить любую архитектуру под свои нужды. Это имеет смысл если объемы большие - сотни и тысячи парсеров и не устраивает архитектура существующих фреймворков.
Пункты 3 и 4 никак друг другу не противоречат, данные вы храните централизованно в базе. Задачи запускаете распределенно через систему управления задачами (воркеры запускающие парсеры, могут находиться на разных хостах). Прокси должны быть обязательно, вне зависимости от степени распределенности.
По поводу желания запускать только парсинг часть, не уверен что это возможно из коробки, но могу предложить обходной путь. Пишется 2 скрапера - один краулер, второй парсер, который парсит локальные страницы.
Ответ написан
Комментировать
Комментировать
seriyPS
@seriyPS
Можно попробовать использовать Scrapy как фетчер а потом сырые страницы закидывать в какую-то очередь типа RabbitMQ или Kafka.
Scrapy хорош тем, что он очень модульный (по крайней мере был, когда я последний раз пользовался). Не нравится встроенный планировщик очередей - замени на свой. Не нравится как работает с заголовками / прокси / кешированием - добавляешь свой middleware.

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

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы
Вакансии с Хабр Карьеры
Team Lead (С++, Python)
TopAssistant • Москва
от 400 000 ₽
Python developer
Bell Integrator
До 350 000 ₽
Python developer
Greenway Global • Новосибирск
от 150 000 ₽
Ещё вакансии
Заказы с Хабр Фриланса
Доработать телеграм бота
19 апр. 2024, в 03:52
1000 руб./за проект
Написать код на python
19 апр. 2024, в 03:01
1000 руб./за проект
Настройка сервера
18 апр. 2024, в 21:56
2000 руб./за проект
Ещё заказы