Comments 45
А скажите, с помощью папетира получается хорошо прикидываться настоящим человеком с браузером? Ну там user agent правильный выдаётся и прочее?
Как человек не понаслышке знающий что такое парсинг в коммерческих целях, хочу сказать что автор пошёл по пути наибольшего сопротивления. Может если необходимо собрать небольшое количество страниц этот метод подходит, но когда это будут сотни тысяч или миллионы то вы сильно разочаруетесь. Во первых безголовые браузеры используются в большинстве случаев для тестирования, а не для парсинга, т.к. потребляют существенное количество ресурсов. Во вторых вас не банят либо по тому что там вообще это не предусмотрено, либо потому что вы ещё не слишком активны, поэтому использовать пул прокси все равно рано или поздно придётся.
Интересно. А на что намекаете? Что надо обычный браузер и через chromedriver управлять/использовать расширения? Или что расковырять апи, и прямымм запросами к данным по хардкору? Или ещё что-то?
Может в комментарии ошибка? Не наибольшего, а как раз наименьшего сопротивления? Современные страницы активно JS используют и построить парсер на базе headless выходит дешево по скорости реализации и последующего поддержвания, но дорого по скорости работы и потребляемым ресурсам.
algotrader2013 проще вообще без браузера. любой ЯП, провильные заголовки + прокси — это то, чего хватит в 99%
alekciy, Kubig всё правильно написано. если страница на JS, то проще json расковырять, чем браузеры городить
Не все сайты работают через получение JSON данных с бека по AJAX. При этом очень часто на эти endpoint ставят разного рода проверки которые требуют передачи разного рода токенов которые создаются в рантайме в процессе работы JS. И тут как раз связка webdriver + XPath с исполнением через headless дает очень быстрый результат в плане запуска парсинга. И не нужно ни какой json при это расковыривать. Но цена за короткое время запуска работы парсера — высокие накладные расходы в виде браузера. А уже потом, когда ясно, что нужна либо быстрая скорость обхода либо экономия ресурсов, уже потом можно и в json поковыряться. Вплоть до того, что исполнять JS источника в VM (SpiderMonkey/V8), получать токены и слать запросы уже через curl.
Ведь тут была разовая задача. И скорость выполнения и потребление ресурсов были небольшие. По сути это поднять один экземпляр браузера и в течении нескольких часов просмотреть все страницы за год. Даже при нескольких экземплярах браузера это не будет «атакой»
эмуляция работы реальных пользователя на UI без риска попасть в бан, как потенциальные DDOS атаки
Не вводите в заблуждение. Бан, UI и DDoS тут совершенно не связаны между собой. Бан можно получить при парсинге на любой клиенте (curl/guzzle/headless) и это зависит от схемы противодействия на ресурсе-источнике. Можно и при использовании клиента-парсера с UI попасть в бан если на источнике отслеживают движение мыши, а вы у себя этого не предусмотрели.
А DDoS предполагает парсинг с большого количества хостов. При этом в целом какой при этом клиент-парсер (GUI / CLI) не важно.
Так же не понятно, за счет чего повышается эффективность парсинга через Puppeteer при ограничении сетевых вызовов. В смысле, не грузить картинки? Но тогда стоило бы указать, каким образом это делается.
Но замечание дельное, как я понимаю смысл один и тот же. И с браузером и без браузера можно попасть в бан. Просто без браузера делать много потоков значительно проще и в разы менее ресурсозатратно, поэтому риск попасть в бан в разы повышается
Интересно как запустить puppeteer в 100500 потоков)
Несколько экземпляров же. И обвязочный код который по ним раскидывает задания. Этакий кластер.
За puppeteer не скажу. Я когда активно пилил парсеры его по сути небыло. Но вот на базе PhantomJS делал кластер и в принципе это не очень сложно. Просто через cli запускаешь пачку PhantomJS с прослушкой каждый на своем порту по webdriver протоколу. Проблема возникла ровно одна — он не мог слушать на заданном IP и запускался небезопасно, чем тут же пользовались взломщики. Поэтому вопрос решался на уровне iptables.
Что-то около 50, но то было ограничение по железу. Схема легко масштабирцуется на порядки. При расчете за исходные данные берем, что один инстанс ~500-700 Мб резидентной ОЗУ с пиком до 1Гб, потекщие инстансы тушим при 2Гб ОЗУ, время на полную обработку одного запроса на парсинг 5-60 секунд.
Да, что еще вспомнил. При запуске можно указать, какой прокси использовать. Поэтому в системе был автоматический перезапуск инстанса прокси которого забанили (управлять выбором используемой прокси по webdriver не удалось, поэтому фиксировалось статически в момент запуска).
Также как-то я сам просчитывал стоимость одного проекта с парсингом динамического контента в реальном времени. И выходило, что со стоимостью в $10/GB+ это тоже убивало всю экономику.
Может, разве что, если исключительно прямыми АПИ запросами кидать, то может быть выгодно, — хз
А чем хорош? Чем он так отличается/выделяется от прочих площадок продающих прокси?
Сейчас, вроде, уже есть провайдеры резидентных и мобильных прокси, но тоже хз, насколько с базой пользователей холы могут потягаться
Есть такие, называются — сюрприз — Люминати.
На самом деле, белый айпишник в чистом виде уже давно не панацея. Поэтому, кстати, те же Люминати дропнули ценник на резидентные прокси и теперь их любимая игрушка эмуляция браузеров. Резидентные прокси сейчас рулят для другого, типа как выяснить, насколько цена на амазоне для правильного пацана из Кремниевой долины отличается от цены для правильного пацана из Детройта. Ну или что там за рекламку нам покажет Фейсбук через веризон в Коннектикуте.
Люминаты раздают шаред-прокси по 50 центов за гигабайт. Дальше — умение их готовить. Современные WAFы это давно уже не "у вас подозрительный ASIN, давайте играть в рекапчу". То есть такое тоже есть, конечно, но от этого отходят, потому что тупо.
Ну можно колхозить на уровне Яндекс.Метрики и Гугл.Анаталитикс подобно этому: Как мы отфильтровали ботов и понизили показатель отказов с 90% до 42%. Срабатывает в любом проекте.
Есть. API называется. В последние годы, вижу, что многие стали лучше осознавать, что парсинг не остановить и это процесс который обходится для авторов парсера очень дешево. Сильно дешевле, чем оборонные меры. Поэтому приходилось слышать от коллег, что сайт источник задетектив бота подсовываем ему большую надпись "у нас есть API, оно тут!" и просьбу для получения данных использовать его. Но все истории пока про запад.
Как с помощью веб-скрапинг и Puppeteer проанализировать аукционы Christie’s, Sotheby’s и Phillips. Кейс от Lansoft