часто появляется желание на постоянной основе парсить сайты с разными рынками .
Типовой сценарий — получить список предложений по рынку невижимости.
Пройти весь список и сохранить в БД каждый объект недвижимости и все что к нему относится — параметры квартиры, фотки, коменты и пр.
Чтобы в БД всегда была полная история рынка с момента запуска парсера.
Далее это предполагается анализировать в разных разрезах.
Раньше писал свой парсер, который обходил нужный сайт и парсил (xpath, css selectors) все, что требуется в БД,
но много времени уходит на его поддержку, подозреваю, что должно быть проще решение,
однако, многочасовое гугление не привело к готовому решению.
Уточню требования:
1. крутится в отдельном процессе, который стартует автоматом
2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин)
3. многопоточный
4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
Работать с API, даже если оно есть, часто не вариант.
Если единственный вариант писать свое, то на каком языке и с какими библиотеками это проще/надежнее?
Здравствуйте, Keith, Вы писали:
K> Уточню требования: K> 1. крутится в отдельном процессе, который стартует автоматом K> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин) K> 3. многопоточный
Посмотрите Selenium. Он чаще всего упоминается в контексте тестирования, но для вашей задачи тоже сгодится.
K> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
Мышкой вряд ли. Пример кода на Java (есть поддержка других языков) http://www.qaautomation.net/?p=263
B>Здравствуйте, Keith, Вы писали:
K>> Уточню требования: K>> 1. крутится в отдельном процессе, который стартует автоматом K>> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин) K>> 3. многопоточный B>Посмотрите Selenium. Он чаще всего упоминается в контексте тестирования, но для вашей задачи тоже сгодится.
Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером.
Проще UI-компонент "Web browser" в нативном приложении без отрисовки UI — там не будет такого расхода оперативки.
Подозреваю, что их и в пул можно будет засунуть.
Selenium Grid, на сколько я понимаю, тоже не решает проблемы в случае с 1 виртуалкой за $5 (2 уже перебор).
K>> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них) B>Мышкой вряд ли.
Почему? У Selenium IDE есть возможность записывать действия мыши и клавиатуры.
Работает хорошо, если контролы стандартные.
Видел успешные примеры с генерацией rss для новостных сайтов, у которых нет rss.
K> Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером.
Есть phantomjs, тоже процесс с браузером, но у браузера отвал башки (headless), потому полегче.
Здравствуйте, hi_octane, Вы писали:
K>> Selenium тяжеловесен — каждый поток выполнения создает отдельный процесс c браузером. _>Есть phantomjs, тоже процесс с браузером, но у браузера отвал башки (headless), потому полегче.
Здравствуйте, Keith, Вы писали:
K> Почему? У Selenium IDE есть возможность записывать действия мыши и клавиатуры.
Не знал, т.к. почти с ним не работал. Спасибо!
K>> Работать с API, даже если оно есть, часто не вариант. Ops>А работать мимо API — часто забанят. Не ты один такой умный.
Я уже этим занимался и менял хэдеры, делал запросы через прокси и ограничивал частоту запросов.
Браузер с javascript'ом никак не отличить от пользователя, если приложить немного усилий.
API часто нет вообще.
Здравствуйте, Keith, Вы писали: K>Добрый день, K> Работать с API, даже если оно есть, часто не вариант. K> Если единственный вариант писать свое, то на каком языке и с какими библиотеками это проще/надежнее? K>С уважением, K>Алексей.
У меня уже заказов 20 было на фрилансе, именно на такую тему Если речь идет про .NET, то использовал вот что:
— WebBrowser — рабочее решение из коробки. Хорошо работает в WinForms, немного кастрированно в WPF, но для парсинга хватит. Из недостатков — это обертка для IE7, со всеми вытекающими. Есть варианты в реестре прописать, что это IE8,9,10, но эффекта по функциональности это не прибавляло.
— CEFSharp — Chromium движок, не столько для парсинга пригодился, сколько для расширенных фич, которые WebBrowser не умеет. В моем случае это был стриминг видео и аудио по ссылке.
— Плагин для Internet Explorer (BHO) — тоже добротно работает, и если мы пишем плагин например под IE10, то будем иметь возможностей побольше чем у WebBrowser. Ну и такие сайты как Facebook например, его с удовольствием встречают, а вот WebBrowser — нет, ибо устарел.
— WatiN — по задумке должен быть там, где нужен Web Test Automation. Но можно приспособить для парсинга и бегания по сайту. Сам в продакшене не использовал
— HTML Agility Pack — просто парсер без js
Если речь идет про С++:
— То опять же BHO под Internet Explorer на нем заводится через COM
Если про Python, мопед не мой, но мне под заказ писали и там такие импорты:
import requests
import logging
import os
import time
import argparse
import pickle
import pprint
import traceback
import json
А еще есть UBot, в котором мышкой наклацать можно воркфлоу, но я бы не рекомендовал как универсальное решение.
Последний вариант
А на Upwork'e такие задачи стоят в районе 50-200$ в зависимости от сложности.
Здравствуйте, Keith, Вы писали:
K> Раньше писал свой парсер, который обходил нужный сайт и парсил (xpath, css selectors) все, что требуется в БД, K> но много времени уходит на его поддержку
Какая конкретно "поддержка"? Обновить XPath под новый дизайн?
K> подозреваю, что должно быть проще решение,
На основе чего появились такие подозрения?
K> однако, многочасовое гугление не привело к готовому решению.
Потому что подозрения — безосновательные, чисто "мне лень так делать".
K> Уточню требования: K> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин) K> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них)
Ха! Ну ты замахнулся на Шекспира.... От такого бы даже сам гугл не отказался, но увы — не может по причине нереальности задачи. Сам не чувствуешь, что сложность задачи граничит с глупостью? Мало того, что жабоскрипт, да ещё клики.
Если парсеру дают хотя бы статический HTML, который можно распарсить — уже счастье!
K>Какая конкретно "поддержка"? Обновить XPath под новый дизайн?
Если бы это была разовая процедура, то я бы согласился.
10 таких парсеров и уже будет ощутимо на поддержку уходить.
Я хочу тратить минимум времени.
K>> подозреваю, что должно быть проще решение, K>На основе чего появились такие подозрения?
На основе виденных мною инструментов схожей функциональности.
K>> однако, многочасовое гугление не привело к готовому решению. K> Потому что подозрения — безосновательные, чисто "мне лень так делать".
Конечно мне лень делать работу, которую можно не делать.
K>> Уточню требования: K>> 2. эмулирует современный браузер с javascript, включая ajax (так же, естественно, нужно эмулировать логин) K>> 4. легко и относительно надежно парсит содержимое (желательно вообще мышкой прокликать какие div'ы интересуют и какие части в них) K>Ха! Ну ты замахнулся на Шекспира....
Неужели так же красиво рифмую?
>От такого бы даже сам гугл не отказался, но увы — не может по причине нереальности задачи.
Вообще, я уже нашел мышко-кликательное решение — там xpath генерируется автоматом при выборе мышкой.
Однако я еще не все осмотрел из найденного, возможно, найду получше реализации...
>Сам не чувствуешь, что сложность задачи граничит с глупостью? Мало того, что жабоскрипт, да ещё клики.
Прошу прощения, Вы эксперт в этой области?
С удовольствием бы купил у вас часовую консультацию на эту тему за $200.
K>Если парсеру дают хотя бы статический HTML, который можно распарсить — уже счастье!
Видимо, я ошибся, поищите больше информации на эту тему, чтобы предметнее вести разговор.
L>У меня уже заказов 20 было на фрилансе, именно на такую тему Если речь идет про .NET, то использовал вот что: L>- WebBrowser — рабочее решение из коробки. Хорошо работает в WinForms, немного кастрированно в WPF, но для парсинга хватит. Из недостатков — это обертка для IE7, со всеми вытекающими. Есть варианты в реестре прописать, что это IE8,9,10, но эффекта по функциональности это не прибавляло. L>- WatiN — по задумке должен быть там, где нужен Web Test Automation. Но можно приспособить для парсинга и бегания по сайту. Сам в продакшене не использовал L>- HTML Agility Pack — просто парсер без js
Эти пункты так же использовал, но сейчас хочу уйти в сторону Linux-совместимого решения.
L>Если про Python, мопед не мой, но мне под заказ писали и там такие импорты:
Для питона есть BeautifulSoup + стандартный способ делать http-запросы.
Ну и Selenium так же есть.
L>А еще есть UBot, в котором мышкой наклацать можно воркфлоу, но я бы не рекомендовал как универсальное решение.
Это уже ближе к тому, что я хотел бы, только дорого.
А почему не рекомендуете?
Кроме того, что это зависимость от вендора.
L>А на Upwork'e такие задачи стоят в районе 50-200$ в зависимости от сложности.
И часто такие задачи попадаются? Конкуренция высокая?
jsdom выглядит как интересная замена phantomjs'у.
А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby?
>Плюс легендарная надежность и асинхронность node.js
Еще бы синхронность была, вообще цены не было )
А вообще, многие жалуются на утечки.
Здравствуйте, Keith, Вы писали:
K> А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby?
Нативный JS, скажем можно выполнить JS приехавший с сайта, поймать какой-нибудь промежуточный объект и извлечь из него данные.
K> Еще бы синхронность была, вообще цены не было )
Открой для себя async.js и забудь про синхронность как страшный сон.
K> А вообще, многие жалуются на утечки.
Нет там никаких утечек. У нас есть скрипты на ноде, у которых аптайм измеряется годами.
K>> А есть какие-нибудь преимущества у node в парсинге, которых нет, скажем, у java/python/ruby? P>Нативный JS, скажем можно выполнить JS приехавший с сайта, поймать какой-нибудь промежуточный объект и извлечь из него данные.
А чем это отличается от других платформ?
Там тоже можно сделать http-запрос и десериализовать json в объекты языка.
K>> Еще бы синхронность была, вообще цены не было ) P>Открой для себя async.js и забудь про синхронность как страшный сон.
Когда искал такое не нашел, спасибо.
Но все равно оборачивать каждый раз вызовы в синхронные неудобно, когда для UI в основном надо
блокировать интерфейс между действиями.
K>> А вообще, многие жалуются на утечки. P>Нет там никаких утечек. У нас есть скрипты на ноде, у которых аптайм измеряется годами.
Скрипты, наверерное, простые?
Но, вообще, это не важно.
Я готов его опробовать, если будет того стоить.
Здравствуйте, Keith, Вы писали:
K> А чем это отличается от других платформ? K> Там тоже можно сделать http-запрос и десериализовать json в объекты языка.
В других платформах ты не можешь запускать приехавший с сервера код.
K> Но все равно оборачивать каждый раз вызовы в синхронные неудобно, когда для UI в основном надо K> блокировать интерфейс между действиями.
Не нужно. Для UI нужно показать песочные часы, сделать запрос и повесить коллбек в котором спрятать песочный часы и показать результат. В асинхронном варианте это делается прощей чем в синхронном. Плюс асинхронной реализации в том что ты можешь показать песочные часы только в том месте индерфейса которое связано с запросом, а весь остальной может продолжать работать пераллельно.
K>> А чем это отличается от других платформ? K>> Там тоже можно сделать http-запрос и десериализовать json в объекты языка. P>В других платформах ты не можешь запускать приехавший с сервера код.
Согласен, в случае веб-приложения это удобно.
Но в контексте парсера, это не имеет значения.
K>> Но все равно оборачивать каждый раз вызовы в синхронные неудобно, когда для UI в основном надо K>> блокировать интерфейс между действиями. P>Не нужно. Для UI нужно показать песочные часы, сделать запрос и повесить коллбек в котором спрятать песочный часы и показать результат. P>В асинхронном варианте это делается прощей чем в синхронном.
Не согласен, сложнее оборачивать результат в дополнительную функцию + меняется контекст this.
Проще в синхронном виде:
P>Плюс асинхронной реализации в том что ты можешь показать песочные часы только в том месте индерфейса которое связано с запросом, а весь остальной может продолжать работать пераллельно.
При синхронном вызове тоже можно блокировать только часть, я не имел ввиду однопоточность.
S>Трогай за PhantomJS S>Полный эмулятор браузера вместе с жабаскриптом, который могёт работать сам, в консоли, совсем буз гуя.
А есть какое-нибудь преимущество node.js + phantomjs перед selenium'ом или
движком браузера на другой платформе (java, python, ruby)?
У Вас есть опыт разработки парсеров?
Здравствуйте, Keith, Вы писали:
K> А есть какое-нибудь преимущество node.js + phantomjs перед selenium'ом или K>движком браузера на другой платформе (java, python, ruby)? K> У Вас есть опыт разработки парсеров?
Да, еще когда wget'ом баловался на пару с грепом, седом и их братьями. Еще тогда начал опыт копить. А потом еще парсер-билдер jsona с камментами писалъ (ц)
Камрад, Фантом умеет рендерить сайт в картинку вообще. Причем правильно. Этим многое сказано.
Только я не могу понять при чем тут нодажс. фантомжс самостоятелен.
Q: Why is PhantomJS not written as Node.js module?
A: The short answer: “No one can serve two masters.”
A longer explanation is as follows.
As of now, it is technically very challenging to do so.
Every Node.js module is essentially “a slave” to the core of Node.js, i.e. “the master”. In its current state, PhantomJS (and its included WebKit) needs to have the full control (in a synchronous matter) over everything: event loop, network stack, and JavaScript execution.
If the intention is just about using PhantomJS right from a script running within Node.js, such a “loose binding” can be achieved by launching a PhantomJS process and interact with it.
S>Камрад, Фантом умеет рендерить сайт в картинку вообще. Причем правильно. Этим многое сказано.
Selenium это тоже умеет.
Как и движки браузеров.
S>If the intention is just about using PhantomJS right from a script running within Node.js, such a “loose binding” can be achieved by launching a PhantomJS process and interact with it.
Не знал.
Он случайно не однопоточен?
Можно несколько "браузеров" одновременно запустить в одном процессе PahntomJS?
Здравствуйте, Keith, Вы писали:
S>>Камрад, Фантом умеет рендерить сайт в картинку вообще. Причем правильно. Этим многое сказано.
K> Selenium это тоже умеет.
Это монстр какой то. И веб-драйвер и клиент и иде какието, вдобавок только под винды... Я не говорю что оно плохое, но по моему это пушка и воробьи...
K> Как и движки браузеров.
Мне было бы интересно почитать как попросить движок хрома отрендерить урл в картинку на безиксовой станции...
S>>If the intention is just about using PhantomJS right from a script running within Node.js, such a “loose binding” can be achieved by launching a PhantomJS process and interact with it.
K> Не знал. K> Он случайно не однопоточен? K> Можно несколько "браузеров" одновременно запустить в одном процессе PahntomJS?
Оно несколько по другому работает. Оно скарливает отрендереное скрипту на жабаскрипте, который ты передаеш параметром к фантому. http://phantomjs.org/quick-start.html
То бишь всё что тебе надо сделать полезного — пишешь в этом скрипте и его вместе с урлом скармливаешь параметрами командной строки фантома.
Здравствуйте, Keith, Вы писали:
L>>А еще есть UBot, в котором мышкой наклацать можно воркфлоу, но я бы не рекомендовал как универсальное решение. K> Это уже ближе к тому, что я хотел бы, только дорого. K> А почему не рекомендуете? K> Кроме того, что это зависимость от вендора.
Дело в том, что когда пишешь какой нибудь парсер, который бегает по сайтам — велика вероятность, что на одном из них он зависнет, появится капча, фреймы не догрузятся, миллион причин. Используя ЯП, вы сможете обойти эти нюансы закодировав например таймеры-ожидалки нужной вам инфы, а в случае долгого зависания — рестартануть прогу.
UBot в этом плане — ни разу ни flexible. Если что-то пойдет не так, обойти проблему даже используя местный скриптовый язык будет очень тяжело.
Впринципе, используя связку свое приложение + UBot, наверное можно добиться непробиваемости, путем запуска приложения там где UBot не справляется.
L>>А на Upwork'e такие задачи стоят в районе 50-200$ в зависимости от сложности. K> И часто такие задачи попадаются? Конкуренция высокая?
За последний год только 4 раза. И это я еще не искал, сами предложили. Задачи появляются постоянно, проблема насущная, есть догадка, что разработчики Ubot уже сидят на мешках с золотом. Смотрите например этот раздел. Ставлю на то, что на первой же странице будет что-то вроде Need a scrapper / Need a bot.
Здравствуйте, Keith, Вы писали:
K> А есть какое-нибудь преимущество node.js + phantomjs перед selenium'ом или K>движком браузера на другой платформе (java, python, ruby)?
Есть ровно два браузера на которые стоит обратить внимание: Chromium и Firefox. Всё остальное смело в топку. А полным эмулятором браузера... является сам браузер. Кэп же ж. Но это скорее к Шеридану.
Есть как минимум два типа страниц:
1. Которые "парсятся" с помощью обычного GET + какой-нибудь парсер html + выбираем. Т.е. никакой JS и движок тут не нужен.
2. Те которым нужен JS: Блок цен бывает зашифрован, бывает он догружается в другой фрейм. Вот это ключевой момент: если phantomjs хоть чуточку быстрее/экономичнее CEF — то возможно заморачиваться стоит с ним.
3. Страницы которые делают саморедиректы, куки и яваскрипт + фреймы опять же. (Ну это по сути продолжение (2)).
Selenium — отличный выбор, что бы начать и освоится в проблематике. Но в перспективе я бы смотрел на CEF. Selenium (по крайней мере при коннекте к Chromium — использует DevTools Protocol) — а его возможности хоть и широки, но ограничены.
Проблематика у этой задачи есть — страницы "не останавливаются" — поэтому сколько ждать — зачастую не известно. Ждать слишком много => слишком медленно. Ждать по таймауту в "аккурат" — ошибки полезут, ведь скорость ответа в реальности варьируется. А если использовать распределенные прокси то скорость и вовсе будет скакать, а страничка которая грузится за 2-3 секунды внезапно грузится 2 минуты. Вариантов решений масса, но это уже наверное работать надо над этим.
K> У Вас есть опыт разработки парсеров?
Если под парсером подразумевать извлечение информации из страниц — то у меня есть. Правда цены — это уже давно пройденный этап.
Я не вникал никогда слишком подробно в phantomjs, так что х.з. чего он там может/не может. Я бы взял максимально универсальный инструмент. Что касается биндингов к java/python/net/mono — то в основном пофигу абсолютно. Движок он на плюсах.
Лично на мой взгляд — CEF лучший выбор для тяжелых страниц. Безусловно максимально универсальным вариантом будет использовать content module из хрома, но — тогда прийдется написать приблизительно тоже самое, что делает CEF, поддерживать его, ну и будете этим заниматься несколько лет, а не задачей. Так что баланс тут нужен, и в CEF он неплохой (достаточно простое API что-бы начать, достаточно широкое что бы покрыть кучу возможностей, так же реально протолкнуть полезные изменения, особенно если есть тяма их самому реализовать).
K>> Selenium это тоже умеет. S>Это монстр какой то. И веб-драйвер и клиент и иде какието, вдобавок только под винды... Я не говорю что оно плохое, но по моему это пушка и воробьи...
Это стандарт отрасли автоматизированного веб-тестирования.
Оно далеко не только под винды.
Драйвер с браузером без UI тоже есть.
Да промышленное, но это не только минус, но и плюс.
K>> Как и движки браузеров. S>Мне было бы интересно почитать как попросить движок хрома отрендерить урл в картинку на безиксовой станции...
Хороший аргумент, но в картинку для парсинга не нужно, делать логику повер графики — это уже экстрим.
S>Оно несколько по другому работает. Оно скарливает отрендереное скрипту на жабаскрипте, который ты передаеш параметром к фантому. http://phantomjs.org/quick-start.html S>То бишь всё что тебе надо сделать полезного — пишешь в этом скрипте и его вместе с урлом скармливаешь параметрами командной строки фантома.
Я правильно понял, что он в отдельном процессе крутиться?
Ему можно одновременно скармливать несколько страниц?
Здравствуйте, Keith, Вы писали:
S>>Оно несколько по другому работает. Оно скарливает отрендереное скрипту на жабаскрипте, который ты передаеш параметром к фантому. http://phantomjs.org/quick-start.html S>>То бишь всё что тебе надо сделать полезного — пишешь в этом скрипте и его вместе с урлом скармливаешь параметрами командной строки фантома.
K> Я правильно понял, что он в отдельном процессе крутиться? K> Ему можно одновременно скармливать несколько страниц?
Нет конечно. Ты в одной вкладке браузера несколько страниц откроешь?
Ничто не мешает запустить несколько процессов. Они запустятся, отработают и остановятся. А так как это просто командная строка, то тут для автоматизации руки развязаны абсолютно.
Здравствуйте, Keith, Вы писали:
S>>Мне было бы интересно почитать как попросить движок хрома отрендерить урл в картинку на безиксовой станции... K> Хороший аргумент, но в картинку для парсинга не нужно, делать логику повер графики — это уже экстрим.
Аргумент на самом деле так себе — что будет стоять на сервере который парсит страницы — абсолютно пофигу, ему работу делать надо. Ну а windowless/headless browsing в CEF тоже есть, но это не значит, что нет зависимостей на X или что-то ещё — они в минимальном объеме необходимы.
F> Есть как минимум два типа страниц:
Рискну расширить классификацию:
1. http запросы + html парсеры (HTMLAgilityPack, BeautifulSoup) + xpath
2. headless движок конкретного браузера (jsdom, phantom) + xpath / css selectors
3. полноценные движок конкретного браузера + xpath / css selectors
4. selenium + кросс-браузерный selenium api / xpath / css selectors
F> Проблематика у этой задачи есть — страницы "не останавливаются" — поэтому сколько ждать — зачастую не известно. Ждать слишком много => слишком медленно. Ждать по таймауту в "аккурат" — ошибки полезут, ведь скорость ответа в реальности варьируется.
Можно же ждать до появления нужного элемента?
F> А если использовать распределенные прокси то скорость и вовсе будет скакать, а страничка которая грузится за 2-3 секунды внезапно грузится 2 минуты. Вариантов решений масса, но это уже наверное работать надо над этим.
1 thread = 1 workflow = 1 proxy
(под workflow подразумеваю некий объем работы: зайти на страницу, вычленить данные, зайти еще на пару страниц, если требуется).
Таким образом можно спокойно параллелить workflow.
Если, конечно, это не крупный комерческий сайт на котором есть эвристики пользовательсного поведения, но это уже за рамками моих требований.
K>> У Вас есть опыт разработки парсеров? F> Если под парсером подразумевать извлечение информации из страниц — то у меня есть. Правда цены — это уже давно пройденный этап.
Что значит пройденный этап? Сейчас это стоит дешево или что?
S>Нет конечно. Ты в одной вкладке браузера несколько страниц откроешь? S>Ничто не мешает запустить несколько процессов. Они запустятся, отработают и остановятся. А так как это просто командная строка, то тут для автоматизации руки развязаны абсолютно.
Но он все-таки в отдельном процессе крутится?
И в нем можно параллельно открывать страницы (как вкладки в браузере)?
S>>>Мне было бы интересно почитать как попросить движок хрома отрендерить урл в картинку на безиксовой станции... K>> Хороший аргумент, но в картинку для парсинга не нужно, делать логику повер графики — это уже экстрим. F> Аргумент на самом деле так себе — что будет стоять на сервере который парсит страницы — абсолютно пофигу, ему работу делать надо. Ну а windowless/headless browsing в CEF тоже есть, но это не значит, что нет зависимостей на X или что-то ещё — они в минимальном объеме необходимы.
Умение рендерить интересно само по себе, учитывая, что он headless, но для парсеров пофиг.
Здравствуйте, Keith, Вы писали:
F>> Есть как минимум два типа страниц: K> Рискну расширить классификацию: K>1. http запросы + html парсеры (HTMLAgilityPack, BeautifulSoup) + xpath K>2. headless движок конкретного браузера (jsdom, phantom) + xpath / css selectors K>3. полноценные движок конкретного браузера + xpath / css selectors K>4. selenium + кросс-браузерный selenium api / xpath / css selectors
Да, спасибо. Единственно, что в первом варианте никто не мешает использовать css selectors.
Я имел ввиду, что мне неочевидны выгоды jsdom и phantom перед полноценными движками (я их не тестировал). Селениум это тоже что и (3), но со своим готовым API к использованию. У него есть ограничения — я в своём браузере немного меняю JS "world", что бы отслеживать некоторые события, — на данный момент через devtools protocol (selenium) такого сделать невозможно. В принципе мне не встречалось сильно упоротых страниц, но опять же я на фантоме их и не гонял, но упоротые — встречались. Но браузер их прожевывает.
Кроме того phantom — это QT+WebKit. Лучше ли оно chromium-based браузера — х.з. GUI приложения которые используют QT+WebKit — ужасны.
F>> Проблематика у этой задачи есть — страницы "не останавливаются" — поэтому сколько ждать — зачастую не известно. Ждать слишком много => слишком медленно. Ждать по таймауту в "аккурат" — ошибки полезут, ведь скорость ответа в реальности варьируется. K> Можно же ждать до появления нужного элемента?
Это один из основных вариантов, но у него есть несколько недостатков:
1. Что если элемент никогда не появится? И почему он не появился? (какая-то ошибка загрузки, при том, это ведь и XHR может быть, и тупо фрейм, а может и банальный редизайн) — соответственно нужен достаточный таймаут. Соотв. достаточность надо как-то определить.
2. Частота поллинга напрямую влияет на потребляемый CPU.
3. Частота поллинга влияет насколько быстро мы завершим сессию. Тут стоит пояснить, что на фоне 2-х минут загрузки страниц — можно пару секунд и подождать, однако общая скорость настолько низкая (даже в случае если потреблять контент с localhost), что имеет броться за всё подряд. Бесуловно тут нужно найти свой баланс, и свой путь.
В противовес — если знать чего ждать — то можно дождаться и забрать. Но это скорее всего специальные правила для сайта. Опять же ожидание может тоже свестись (а может и нет) к поллингу.
F>> А если использовать распределенные прокси то скорость и вовсе будет скакать, а страничка которая грузится за 2-3 секунды внезапно грузится 2 минуты. Вариантов решений масса, но это уже наверное работать надо над этим. K> 1 thread = 1 workflow = 1 proxy
Под прокси я понимал распределенные прокси по всему миру. Сервисы есть, в них обычно есть сессии, которые свяжут сессию с единственным узлом прокси.
K> (под workflow подразумеваю некий объем работы: зайти на страницу, вычленить данные, зайти еще на пару страниц, если требуется).
Я тоже так его понимаю, и его же называю сессией (выше вроде назвал?).
K> Таким образом можно спокойно параллелить workflow. K> Если, конечно, это не крупный комерческий сайт на котором есть эвристики пользовательсного поведения, но это уже за рамками моих требований.
(Об 1 thread): Безусловно параллелить можно без проблем. Просто полновесные браузеры требуют немало ресурсов: CEF-based потребует 1 процесс на сайт + около 20 потоков в рендерере ну и 200-500Мб на каждый процесс, в зависимости от сложности сайта. Кроме того chromium-based браузер управляется самим процессом браузером — и в нём тоже есть несколько потоков — соответственно их возможностей должно хватать для всех "табов" — поэтому в зависимости от железа в реале можно расчитывать на 10-40 одновременных сессий обслуживаемых одним браузером (100 — не проблема поднять — но ускорения не выходит как не крути).
F>> Если под парсером подразумевать извлечение информации из страниц — то у меня есть. Правда цены — это уже давно пройденный этап. K> Что значит пройденный этап? Сейчас это стоит дешево или что?
Ах, вовсе нет. Я имел ввиду, что я сейчас занимаюсь не ценами (хотя это тоже было), — и куча проблем повсплывала которых с ценами на было вообще. Ну, например — вышеописанный поллинг — совсем не подходит.
Здравствуйте, Keith, Вы писали:
K> Умение рендерить интересно само по себе, учитывая, что он headless, но для парсеров пофиг.
Аппетит приходит во время еды. Сначала — пофиг. Потом — скриншоты. Потом и до видео дойдете.
Здравствуйте, Keith, Вы писали:
K> Но он все-таки в отдельном процессе крутится? K> И в нем можно параллельно открывать страницы (как вкладки в браузере)?
"Одна вкладка" — один процесс.
Друг, ну установи уже и потрогай со всех сторон. Или тебе пообсуждать нравится?
K>> Но он все-таки в отдельном процессе крутится? K>> И в нем можно параллельно открывать страницы (как вкладки в браузере)?
S>"Одна вкладка" — один процесс. S>Друг, ну установи уже и потрогай со всех сторон. Или тебе пообсуждать нравится?
Потрогать = 1-2 часа.
Написать вопрос = 1-2 минуты.
В любом случае — спасибо, за советы!
K>>1. http запросы + html парсеры (HTMLAgilityPack, BeautifulSoup) + xpath F> Да, спасибо. Единственно, что в первом варианте никто не мешает использовать css selectors.
Мне казалось, что там десериализация в xml и css там нет. Это не так?
F> Кроме того phantom — это QT+WebKit.
Странно, зачем ему QT, если он headless?
F> Это один из основных вариантов, но у него есть несколько недостатков: F> 1. Что если элемент никогда не появится? И почему он не появился? (какая-то ошибка загрузки, при том, это ведь и XHR может быть, и тупо фрейм, а может и банальный редизайн) — соответственно нужен достаточный таймаут. Соотв. достаточность надо как-то определить.
Ну время таймаута — это на мой взгляд не проблема, учитывая, что это будет в виде исключения происходить, а не при каждом запросе.
F> В противовес — если знать чего ждать — то можно дождаться и забрать. Но это скорее всего специальные правила для сайта. Опять же ожидание может тоже свестись (а может и нет) к поллингу.
Я подразумеваю, что знаю какие элементы мне нужны, т.к. планирую доставать из них данные.
Если что не так за 10 сек, то можно рефрешнуть страницу, это не должно ни на что повлиять и должно быть исключением.
F>>> А если использовать распределенные прокси то скорость и вовсе будет скакать, а страничка которая грузится за 2-3 секунды внезапно грузится 2 минуты. Вариантов решений масса, но это уже наверное работать надо над этим. K>> 1 thread = 1 workflow = 1 proxy F> Под прокси я понимал распределенные прокси по всему миру. Сервисы есть, в них обычно есть сессии, которые свяжут сессию с единственным узлом прокси.
А можно пример такого сервиса?
Я знаю только те, что прокси пачками продают.
K>> (под workflow подразумеваю некий объем работы: зайти на страницу, вычленить данные, зайти еще на пару страниц, если требуется). F> Я тоже так его понимаю, и его же называю сессией (выше вроде назвал?).
Я представляю себе это так:
1. получаение очередного workflow из очереди
2. получение очередного proxy из пула
3. запуск workflow на proxy
Т.е. сессии не будут похожи на человеческие, когда один IP заходит на страницу списка элементов, и начинает этот список поочередно обходить.
А будут рваными — под одним ip получили список, потом каждый элемент обрабатывается под своим IP.
Со стороны будет выглядеть как много пользователей, которые делают мало не очень связанных запросов.
F> (Об 1 thread): Безусловно параллелить можно без проблем. Просто полновесные браузеры требуют немало ресурсов: CEF-based потребует 1 процесс на сайт + около 20 потоков в рендерере ну и 200-500Мб на каждый процесс, в зависимости от сложности сайта.
Да, до фига получаеся. Скромная виртуалка не потянет.
Буду склоняться в сторону облегченных вариантов, а не полновесного браузера.
По крайней мере, для экстракции текстовых данных.
F> Кроме того chromium-based браузер управляется самим процессом браузером — и в нём тоже есть несколько потоков — соответственно их возможностей должно хватать для всех "табов" — поэтому в зависимости от железа в реале можно расчитывать на 10-40 одновременных сессий обслуживаемых одним браузером (100 — не проблема поднять — но ускорения не выходит как не крути).
Разве отдельный "таб" — это не отдельный процесс?
F>>> Если под парсером подразумевать извлечение информации из страниц — то у меня есть. Правда цены — это уже давно пройденный этап. K>> Что значит пройденный этап? Сейчас это стоит дешево или что? F> Ах, вовсе нет. Я имел ввиду, что я сейчас занимаюсь не ценами (хотя это тоже было), — и куча проблем повсплывала которых с ценами на было вообще. Ну, например — вышеописанный поллинг — совсем не подходит.
Не до конца понял про цены.
Делали парсеры, которые извлекали цены из целевых сайтов?
А сейчас какую информацию извлекаете?
И на счет поллинга не до конца уверен, что правильно понял — это периодические запросы на сайт с целью получить обновления страницы?
Здравствуйте, Keith, Вы писали:
K>>>1. http запросы + html парсеры (HTMLAgilityPack, BeautifulSoup) + xpath F>> Да, спасибо. Единственно, что в первом варианте никто не мешает использовать css selectors. K> Мне казалось, что там десериализация в xml и css там нет. Это не так?
Никто не мешает взять CsQuery или AngleSharp и парсить HTML ими, ну и выбирать элементы с помощью css селекторов. Кроме того немного буквоедства: "десериализация в xml" — парсер (десериализация) строит DOM из HTML/XML. Какой query engine прикрутить поверх их, в принципе не так уж важно.
F>> Кроме того phantom — это QT+WebKit. K> Странно, зачем ему QT, если он headless?
QT — это ж не только про UI. Просто любой голый WebKit нужно хорошо попилить, прежде чем он сможет "нормально" загружать произвольные страницы. Поэтому я и отношусь к ним довольно скептически.
F>> 1. Что если элемент никогда не появится? И почему он не появился? (какая-то ошибка загрузки, при том, это ведь и XHR может быть, и тупо фрейм, а может и банальный редизайн) — соответственно нужен достаточный таймаут. Соотв. достаточность надо как-то определить. K> Ну время таймаута — это на мой взгляд не проблема, учитывая, что это будет в виде исключения происходить, а не при каждом запросе.
(*) Я в основном указываю на тот факт, что эту ситуацию нужно каким-либо образом обрабатывать. Желательно автоматом. Иначе легко может получится что рабочие процессы ничего полезного не будут делать часами/днями, в зависимости от шедюлера заданий. Каким именно образом и какова частота этих исключений — зависит исключительно от количества сайтов которые парсим * количество страниц на каждом из сайтов.
F>> Под прокси я понимал распределенные прокси по всему миру. Сервисы есть, в них обычно есть сессии, которые свяжут сессию с единственным узлом прокси. K> А можно пример такого сервиса? K> Я знаю только те, что прокси пачками продают.
Поищи в гугле business proxy network или что-то в этом роде, вылетело из головы название... дурацкое какое-то. Сейчас точно глянуть не могу. Таких точно было несколько, но суть не в том, что они пачками их выдают, а они дают доступ к своей сети прокси. И помню что фри триал был.
K> Т.е. сессии не будут похожи на человеческие, когда один IP заходит на страницу списка элементов, и начинает этот список поочередно обходить. K> А будут рваными — под одним ip получили список, потом каждый элемент обрабатывается под своим IP. K> Со стороны будет выглядеть как много пользователей, которые делают мало не очень связанных запросов.
В идеале — нужно эмитировать работу пользователей, каждый со своими куками. Иначе постоянные заходы пользователей без куков будут постоянно вызывать проблемы (навроде дурацких JS-based редиректов, которые вдобавок ограничены по времени с нижней стороы), т.е. например 3 секунды задержки минимум — значит 3 секунды. А это потеря времени и ненужный траффик. Но по началу — на это можно забить.
K> Да, до фига получаеся. Скромная виртуалка не потянет. K> Буду склоняться в сторону облегченных вариантов, а не полновесного браузера. K> По крайней мере, для экстракции текстовых данных.
Я сразу сказал — кому JS не нужен — работать надо по старинке. Да даже кому и нужен JS, но тот же AngleSharp вроде умеет при необходимости и JS исполнять. Но я обращу внимания — тут нет WebKit. Наличие WebKit убивает идею легковесности сам по себе. А кому нужны полновесные... вот я тут и не уверен стоит ли заморачиваться с фантомом — проще полновес взять.
F>> Кроме того chromium-based браузер управляется самим процессом браузером — и в нём тоже есть несколько потоков — соответственно их возможностей должно хватать для всех "табов" — поэтому в зависимости от железа в реале можно расчитывать на 10-40 одновременных сессий обслуживаемых одним браузером (100 — не проблема поднять — но ускорения не выходит как не крути). K> Разве отдельный "таб" — это не отдельный процесс?
Таб — отдельный процесс (рендерер). Но он управляется главным процессом (браузером). Для любых видов браузеров я бы не рекомендовал его, тащить этот "главный" процесс к себе в рабочий процесс / шедюлер — при крешах браузера — это спасет. А браузеры тоже крешаются, хоть и не часто. Рендереры — чаще, но это как бы штатно. И тоже на самом деле не часто.
K> Не до конца понял про цены. K> Делали парсеры, которые извлекали цены из целевых сайтов? K> А сейчас какую информацию извлекаете?
Делали и делаем. А насчет сейчас — подробности разглашать не могу, сорри.
K> И на счет поллинга не до конца уверен, что правильно понял — это периодические запросы на сайт с целью получить обновления страницы?
Под поллингом я имел ввиду (*), т.е. опрос пока нужный элемент не появится. Что касается периодических запросов на сайт — то это и так понятно, но мы это не обсуждали.
Спасибо!
