Веб парсер - Средства разработки

Здравствуйте, 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> И на счет поллинга не до конца уверен, что правильно понял — это периодические запросы на сайт с целью получить обновления страницы?
Под поллингом я имел ввиду (*), т.е. опрос пока нужный элемент не появится. Что касается периодических запросов на сайт — то это и так понятно, но мы это не обсуждали.

	От:	Sheridan
	Дата:	19.12.16 19:58
	Оценка:

	От:	Keith
	Дата:	19.12.16 20:57
	Оценка:

	От:	Sheridan
	Дата:	19.12.16 21:22
	Оценка:

	От:	licedey
	Дата:	19.12.16 22:14
	Оценка:	4 (1)

	От:	fddima
	Дата:	20.12.16 13:42
	Оценка:	6 (1)