@istinspring17 апр 2012 в 06:07

Использование Grab:Spider для парсинга сайтов

4 мин

19K

Python *

+31

Комментарии 17

@xa4a 17 апр 2012 в 06:16

Спасибо, интересно.

Так же интересно было бы сравнение с уже более опытными open-source альтернативами, вроде Scrapy, а так же мысли по поводу защиты сайта от подобного софта.

@itforge 17 апр 2012 в 06:22

Для того, чтобы сравнить, нужно для начала определиться по каким критериям сравнивать. Этакую матрицу критериев выработать. Я уже сам не знаю, что получится через год из Spider. Хочется верить, что сделаю поддержку работы Spider на кластере :) И ещё хочется допилить selenium. А ещё я там недавно вынес код работы с сетью в отдельный слой (в Spider, в Grab это давно уже) и теперь можно реально делать работу Spider на других сетевых библиотеках: twisted, gevent, pool тредов или процессов.

@istinspring 17 апр 2012 в 06:31

Я использовал Scrapy, потом как-то делал проект, большой (около миллиона страниц), там возникли трудности с которыми я не смог справиться, переписал на Grab:spider и все заработало и быстро сделалось. На мой взгляд Grab работает намного быстрее и проще для понимания.

В скрапи например была проблема в 0.13 версии, при парсинге если у тебя Twisted 11.01 (не помню точно) он вылетал через некоторое время с ошибкой, и советовали даунгрейдить версию на 11.00. Более того у них в группах постоянно всплывают темы, как увеличить скорость и как добавить прокси. Подозреваю что нормальной поддержки стэка проксей они не делают из-за своего стартапа который будет предоставлять всю эту инфраструктуру на облаке.

@seriyPS 17 апр 2012 в 21:02

Scrapy сам по себе крайне шустрый, мне удавалось полностью утилизировать процессор на нем (т.е. упирался не в IO и не в память, а именно уже в процессор!). Но его надо уметь готовить. Основная причина тормозов — синхронные вызовы. Если у вас присутствуют блокирующие операции в процессе работы (обращения к базе данных например), то тормоза гарантированы. Я для себя эту проблему решил прикручиванием асинхронного AMQP пайплайна и обработкой/сохранением результатов отдельными воркерами.
Для прокси есть нормальная работающая MiddleWare. чем не устраивает? Что такое стек прокси? Если подразумеваются прокси-листы, то это пишется за 10 минут…

@istinspring 18 апр 2012 в 01:19

хотелось бы взглянуть на MiddleWare для прокси.

я писал но у меня почему-то не работало, несколько я помню он как-то странно перемешивал хидеры которые я ставил в миддлварях.

USER_AGENTS_LIST = open(os.path.join(ROOT, 'user_agents.txt'), 'r').readlines()
PROXY_LIST = open(os.path.join(ROOT, 'proxy_list.txt'), 'r').readlines()

PROXY_USR_PWD_ENCODED = base64.b64encode('user:pass').strip()


class RandomUserAgentMiddleware(object):
    def process_request(self, request, spider):
        request.headers['User-Agent'] = random.choice(USER_AGENTS_LIST)


class RandomProxyMiddleware(object):
    def process_request(self, request, spider):
        request.meta['proxy'] = "http://%s" % random.choice(PROXY_LIST)
        request.headers['Proxy-Authorization'] = 'Basic ' + \
                                                 PROXY_USR_PWD_ENCODED


class RemoveRefererMiddleware(object):
    def process_request(self, request, spider):
        if 'Referer' in request.headers:
            del request.headers['Referer'] # or = 'http://google.com'

На Spider:grab все это делается намного проще. Можно ничего не передавать (тогда создасться новый объект grab), а можно в следующий таск передать клон объекта grab со всеми куками и хидерами.

@seriyPS 18 апр 2012 в 10:09

Чтобы отключить реферрер можно попробовать отключить middleware, который его выставляет по идее doc.scrapy.org/en/0.14/topics/spider-middleware.html#module-scrapy.contrib.spidermiddleware.referer

Для прокси у нас написано примерно так:

class HttpProxyMiddleware(object):
    def process_request(self, request, spider):
        request.meta['proxy'] = self._get_new_proxy()

    def _get_new_proxy(self):
        #... round-robin there ...
        return 'http://{0}:{1}/'.format(proxy['ip'], proxy['port'])

Но у нас не используется авторизация и используется round-robin вместо random. Т.е. практически как у вас.
Идея взята отсюда github.com/scrapy/scrapy/blob/master/scrapy/contrib/downloadermiddleware/httpproxy.py

@istinspring 18 апр 2012 в 01:22

Мы зачастую упираемся в возможности сервера на котором расположена цель. :)
Я думаю соберусь как-нибудь протестирую граб и скрапи на эталонном сайте.

@seriyPS 17 апр 2012 в 21:08

Лучший способ защиты — кривая верстка и невалидный HTML))) На самом деле — ограничение на число запросов. Но это не гарантирует защиту, а просто сильно усложняет работу (нужно увеличивать таймауты или прокси использовать).
Если нужно что-то посерьезнее — то куки, устанавливаемые обфусцированным JavaScript на клиенте. JS интерпретатор в паука встраивать занятие непростое (но тут и поисковики не смогут на сайт попасть).

@xa4a 17 апр 2012 в 06:28

Для того, чтобы сравнить, нужно для начала определиться по каким критериям сравнивать.

В Ваших интересах, как минимум, по тем критериям, по которым Grab выигрывает. Это может быть всё, что угодно с точки зрения пользователя: удобство API, документация, поддержка, фичи, активность разработки итд. Если бы я был потенциальным пользователем и был бы на стадии выбора фреймворка для своего проекта, то рассматривал бы разные альтернативы. Google первым результатом выдаёт scrapy, почему бы мне его не использовать?

@itforge 17 апр 2012 в 06:37

Первым и последним. Больше не с чем сравнивать :) Если кто-то накидает ещё ссылок на похожие проекты — буду благодарен. И правильно говорить о сравнении Grab:Spider и Scrapy. Ибо Grab это нечто другое — это API для синхронных сетевых запросов и обработки полученных ответов. Grab скорее надо сравнивать с urllib2, urllib3, requests, pycurl, mechanize.