На чем сделать одновременный JS-парсинг большого количества WEB-страниц?

Question

[forklive]

Добрый день!
Предположим - есть много открытых веб страниц, контент на которых меняется динамически и очень часто. Может раз в секунду. Много - это несколько тысяч.
Задача - сделать парсинг этих страниц.
Почему именно парсинг с помощью JS ?
Т.к. контент формируется скриптами. Т.е. если тупо посылать GET-запросы - то во первых IP будет быстро забанен. И во вторых - не факт что вернется то что нужно.
Поэтому можно сделать для каждого типа страниц свой JS скрипт, который будет запускаться на каждой странице например - раз в секунду, и выводить JSON массив с необходимой информацией в программу-обертку, которая будет в свою очередь складывать данные в базу.
Проблема в том, что для того, чтобы просто открыть эти несколько тысяч страниц в браузере - нужно несколько сотен компьютеров.

Гугл дал мне некоторые наводки:

Понятно что, для выполнения такой задачи придется арендовать несколько серверов, и на каждом сервере должно быть максимальное количество оперативы (например 64 ГБ), и процессор помощнее, т.к. на каждой странице нужно будет раз в секунду выполнять JS-скрипт.

Есть ли какие то средства, которые могут открывать ВЕБ-страницы, держать их в памяти, выполнять на этих страницах JS скрипты, получать данные из консоли, но при этом быть не такими ресурсоемкими, как обычный браузер?

Парсинг страниц QT+JS

SCRAPY

Node.js

В какую сторону копать?

Comments

[rustler2000]

А что в JS уже квантовую телепортацию открыли?

[sim3x]

Причем скраппи на питоне к жс?
Причем qt к js?

Парсинг каждого сайта решается своими способами

[forklive]

rustler2000, не совсем понял что имеется в виду?

[rustler2000]

forklive, имеется ввиду, что "магические скрипты" буду гнать REST и скорее всего твои IP будут забанены (или если повезет ограничены в траффиге\rps) и без квантовой телепортации данные без "засвета" не получить.

Answer 1

[Stalker_RED]

чтобы просто открыть эти несколько тысяч страниц в браузере - нужно несколько сотен компьютеров.

10 вкладок на компьютер, серьезно?

Посмотрите phantomjs и selenium.

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

Answer 2

[Evgen]

Весь "динамически генерирующийся контент каждую секунду" не что иное, как те тупые гет (возможно пост) запросы, которые вы не хотите использовать. Т.е. сайт написан так, что страница каждую секунду отправляет запрос определённого формата (используя правильные заголовки и параметры) на сервис. Самое эффективное, как раз так для быстродействия - это подделывать эти запросы, и считывать ответы. Чтобы вас не банили меняйте IP и заголовки (например User Agent, Cookie).

Для запросов можно использовать scrapy (поддерживается многопоточность).

Если всё-же хотите прям эмулировать весь браузер пробуйте headless chrome и selenium.

P.S. Если дадите глянуть страничку - скажу какая технология более пригодна.

Comments

[drDemon]

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

Answer 3

[forklive]

Спасибо за ответы!
>P.S. Если дадите глянуть страничку - скажу какая технология более пригодна.
Это все сайты букмекерских контор, которые заблокированы в РФ.
К примеру - https://www.betfair.com/sport/inplay, ну и там выбираете любое событие.
Да, большинство из них посылают ГЕТ-ПОСТ запросы, и ответ приходит либо в виде JSON-а, либо просто в виде HTML-а.
И да - разбираться очень тяжело - какое поле к чему относиться. К примеру - при первоначальной загрузке приходит таблица, в которой у каждой ячейки свой ID.
И потом, в динамических запросах приходят пары - "ID ячейки - значение ячейки".
И у каждой из 50-100 контор какой то свой алгоритм со своими особенностями.
К примеру - посмотрел ты в Хроме какой запрос посылает страница - посылаешь его в другой вкладке - а сервер уже возвращает какую то ошибку. Т.е. сервер уже понимает что это какой то левый запрос. И вот нужно разбираться что не так...
Поэтому, дабы достичь какой то универсальности, кмк - лучше писать JS-скрипты. Страница браузера (или эмулятора браузера) будет сама посылать все нужные запросы, и остается только забирать из консоли JSON массив, в котором ты уже не запутаешься.
Ну это ход моих мыслей...

>10 вкладок на компьютер, серьезно?
Может и не 10. Но учтите, что в каждой вкладке каждую секунду выполняется скрипт, и потом происходит распарсинг JSON-а. Мои эксперименты показали что даже при 20 таких открытых страницах создается существенная нагрузка.

Answer 4

[Михаил Сисин]

У меня коллега писал парсер для беттинга (под заказ), 2000 запросов должны были быть обработаны каждые 10 секунд (включая собственно забор данных, парсинг и запись в базу). Могу сказать что с Python у него не получилось уложиться, поэтому был использован Go.

Comments

[forklive]

Go - это хорошо. Но я пока не дошел до этого этапа (2000 запросов). Я пока пытаюсь решить именно вопрос с парсингом данных с множества разных одновременно открытых страниц. И пытаюсь придумать какое то универсальное решение, дабы не разбираться в JSON-е каждого из сайтов, и в схеме работы. И сейчас мне нужно ответить на вопрос: парсинг в headless браузере - будет хорошим решением? Поэтому - если бы Вы сказали как Ваш коллега именно парсил - это было бы полезно.
Спасибо.

[Михаил Сисин]

Хедлесс браузер много прожорливей решения написанного с использованием инструментов без запуска JS. Вы не хотите разбираться с JSON и работой каждого сайта, но вам все равно придется разбираться с версткой каждого сайта и под каждый писать отдельную логику. Поэтому технически тут нет разницы, с моей точки зрения, в сложности что парсить json или html. Я бы не использовал headless browser :) но это мое личное мнение.
А коллега мой парсил на Go, без headless :)

[forklive]

С течением времени я понимаю, что истина где то "посередине".
К примеру открываем какую либо страницу события в какой нибудь конторе.
На ней много коэффициентов на разные рынки.
Смотрим JSON который приходит с сервера.
Видим там примерно такие пары: 199969 - 1,5, 199970 - 3,4 и т.д.
И нигде не написано что 199969 - это коэффициент на победу первой команды.
Это можно определить только визуально.
Причем на другой странице другого события ID рынка на ту же П1 будет другим.
И как тут быть?
Причем рынки могут добавляться, могут убираться, могут приостанавливаться.
Возможно есть смысл сделать комбинированное решение: периодически запрашивать страницу браузером, чтобы определять ID-шники рынков. А основную часть запросов делать обычными GET-ми.

[Михаил Сисин]

forklive, если в JSON приезжает не все что нужно, то забираем HTML один раз, затем забираем только JSON через определенные промежутки времени. Я так понимаю, события не меняются на самой странице? А если меняются значит либо они как то еще приезжают на страницу, либо сама страница рефрешится. В зависимости от того как работает конкретный сайт, вы пишете логику парсера.
Насчет другой страницы с другими коэффициентами. Если страница на том же сайте, то логика у вас будет такой же, только другая точка входа (по сути парсер будет такой же как для первой страницы, без лишнего кодинга). Если на разных, то тут в любом случае описывать логику, поскольку разметка наверняка будет разной.