Python фреймворк для парсинга

Pomp — метафреймворк для парсинга сайтов

В первую очередь как инструмент для сбора данных, применяемый в моем хобби проекте, который не давил бы своей мощью, сложностью и наследием. И да, кто же будет сознательно начинать что-то новое на python2.x?

В итоге появилось идея сделать простой фреймворк для современной экосистемы python3.x, но такой же элегантный как Scrapy.

Под катом обзорная статья о Pomp в стиле FAQ.

Зачем вообще фреймворки для парсинга сайтов нужны?

И действительно, ведь на простой связке requests + lxml можно сделать очень многое. В действительности же фреймворки задают правила и нужные абстракции, и берут много рутины на себя.

Почему Pomp позиционируется как «метафреймворк»?

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

В этом и слабость и одновременно сила Pomp. Данный фреймворк позиционируется как «фреймворк для фреймворков», другими словами дает все что нужно для того что бы сделать свой фреймворк и начать продуктивно «клепать» веб пауков.

• нужные абстракции(интерфейсы) и архитектуру схожую со Scrapy;
• не навязывает выбор методов для работы с сетью и разбора добытого контента;
• может работать как синхронно так и асинхронно;
• конкурентная добыча и разбор контента (concurrent.futures);
• не требует «проекта», настроек и прочих ограничений.

• запуск на python2.x, python3.x и pypy (можно даже на google app engine запуститься)
• можно использовать любимые библиотеки для работы c сетью и для разбора контента;
• ввести свою очередь задач;
• разработать cвой кластер пауков;
• более простая прозрачная интеграция с headless браузерами (см пример интеграции с phatnomjs).

Когда следует применять Pomp, а когда нет?

В случае когда вам требуется обработать N источников, с общей моделью данных и с периодическим обновлением данных — это и есть идеальный случай применения Pomp.

Если вам необходимо обработать 1-2 источника и забыть, то быстрее и понятнее все сделать на requests+lxml, и вовсе не использовать специальные фреймворки.

Pomp vs Scrapy/Grab/etc?

Попытаться сравнить можно только в разрезе конкретной задачи.

И что лучше сказать сложно, но для меня это вопрос решенный, так как я используя Pomp могу собрать любой сложности систему. С другими же фреймворками зачастую придется бороться с их «рамками» и даже забивать гвозди микроскопом, к примеру использовать Scrapy для работы с headless browsers, оставляя неудел всю мощь Twisted.

Архитектура

Основные блоки:
— очередь запросов (задач);
— «транспорт» (на диаграмме как BaseDownloader);
— middlewares для пре- и пост-обработки запросов;
— pipelines для последовательной обработки/фильтрации/сохранения добытых данных;
— crawler для разбора контента и генерации следующих запросов;
— engine, который связывает все части.

Простейший пример

Поиск на странице http://python.org/news предложений со словом python простейшим regexp.

import re from pomp.core.base import BaseCrawler from pomp.contrib.item import Item, Field from pomp.contrib.urllibtools import UrllibHttpRequest python_sentence_re = re.compile('[\w\s]python[\s\w]', re.I | re.M) class MyItem(Item): sentence = Field() class MyCrawler(BaseCrawler): """Extract all sentences with `python` word""" ENTRY_REQUESTS = UrllibHttpRequest('http://python.org/news') # entry point def extract_items(self, response): for i in python_sentence_re.findall(response.body.decode('utf-8')): item = MyItem(sentence=i.strip()) print(item) yield item if __name__ == '__main__': from pomp.core.engine import Pomp from pomp.contrib.urllibtools import UrllibDownloader pomp = Pomp( downloader=UrllibDownloader(), ) pomp.pump(MyCrawler())

Пример создания «кластера» для разбора craigslist.org

В примере используется:
— Redis для организации централизованной очереди задач;
— Apache Kafka для агрегации добытых данных;
— Django на postgres для хранения и отображения данных;
— grafana c kamon dashboards для отображения метрик работы кластера kamon-io/docker-grafana-graphite
— docker-compose что бы запустить весь этот зоопарк на одной машине.

Исходный код и инструкции по запуску смотрите здесь — estin/pomp-craigslist-example.

А так же видео без звука, где большая часть времени ушла на развертывание окружения. На видео можно найти некоторые ошибки в сборе метрик о размере очереди задач.

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

Дальнейшие планы

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

Источник

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

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

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

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

1. PySpider
   Отличный инструмент, часто пользуюсь им, когда надо получить данные с какого-нибудь сайта. К сожалению некоторые особенности делают проблематичным его использование:
   • Непонятно как разделить на «фетчер» и «парсер», вернее как осуществить отдельный запуск только «парсера».
   • Нет встроенной поддержки прокси
   • Код пауков редактируется в веб-интерфейсе и не подразумевает использование из файла. Есть возможность запуска отдельного инстанса спайдера с файлом, но этот вариант не подходит — сотни инстансов PySpider убивает саму философию использования этого фрейворка. Да и непонятно как всё это удобно дебажить в IDE.

2. Grab, а точнее Grab:spider
   Очень интересный легковесный фреймворк, но похоже отсутствует:
   • Возможность централизованного управления пауками
   • Расписание запуска отдельных тасков
   • Возможность осуществить отдельный запуск только «парсера».

3. Scrapy
   Самый известный и распиаренный инструмент для написания пауков на Python. Вопросы к нему примерно схожи с вопросами по Grab:spider:
   • Расписание запуска отдельных тасков
   • Возможность осуществить отдельный запуск только «парсера».

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

Источник