Comments 49
Привет ребят. Постараюсь немного помочь, я сам когда-то решал подобную задачу. Хотя и не для объявлений, а для скачивания данных с сайта избиркома, ради статистического исследования результатов выборов. Проблема была в том, что УИКов(участковых избирательных комиссий) в России чуть меньше 100 тысяч, и на каждую из них уходит по меньшей мере 3 http-запроса. Вот и посчитайте, сколько всё это будет работать, если каждый запрос занимает 2 секунды (и это ещё хорошо !). А сайт пускает только два запроса с одного ip-адреса.
Во-первых я пошел немного другим путём, чем вы. Не стал покупать прокси. Дело в том, что в сети полно сайтов, публикующих списки свободных прокси. У них есть API, разумеется платный. Но есть и html-странички. Разумеется защищенные, распарсить их надо ещё суметь. Зато это даёт ТЫСЯЧИ и ДЕСЯТКИ ТЫСЯЧ прокси. На халяву. Против ваших 150 за деньги.
Во-вторых не понял, зачем вам сервера ??? Всё прекрасно работает на локальной машине. Наверно вы начинали с php, и оно замылило вам глаза. Я начинал с экспериментов на питоне, а боевой код писал на java. Весь сайт избиркома в итоге качался в базу данных sqlite за 3 часа. Можно было бы и быстрее, но начинал слегка подтормаживать ноутбук.
В третьих по организации кода. Код ОБЯЗАТЕЛЬНО (!!!) должен быть модульным. С выделенным модулем парсинга. Который получает выкачанный html и выдирает из него нужную информацию, которую куда-то в свою очередь отправляет (в базу данных например). Дело в том что ад любого парсера - это изменения в верстке. И должна быть заранее предусмотрена возможность достаточно безболезненно эту проблему решать, затрагивая как можно меньше кода. Кроме того должна быть предусмотрена возможность раздельной работы на разных компьютерах, со слиянием полученных баз данных в одну. У меня это тоже было предусмотрено, хотя и не использовалось. Этим решается проблема масштабирования.
Вот примерно так. Надеюсь был вам полезен. Ну и наконец можете почитать пару моих живых статей (в формате ipynb) на эту тему https://github.com/Karabass-Barabass/FreeProxy/tree/master . Они несколько не окончены и в конце там какое-то количество мусора. Но читать это не мешает. Хотел опубликовать на хабре, да не решился. Ибо тема довольно скользкая.
Спасибо, обязательно ознакомлюсь.
Если вы хотите продуктовый подход - одна машина явно не подойдёт, тем более личный ноут. Вы видимо не понимаете нагрузку и сложность парсинга в принципе.
Давным давно все бесплатные прокси попадают в бан у нормальных систем борьбы с парсингом. Тут главное же безотказность и скорость работы. Мы можем парсить около 100 тысяч сообщений в день, при этом нагрузка очень большая, чаще всего на cpu. В лоб уже давно никто не парсит, обычным запросом с какого-нибудь php. Все через браузер, имитацию работы настоящего юзера и т.д.
Не понял, чем с точки зрения сервера браузер отличается от какого-то левого скрипта ??? Если скрипт отправляет разумные заголовки, имитирующие браузер, выполняет тестовые задания на джаваскрипте, и т.п, отличить его от браузера невозможно. А ресурсов он занимает несравненно меньше чем тот же хром. Насчет того что все бесплатные прокси давно уже в бане - не знаю. Надо смотреть. Однако на первый взгляд сомнительно. Ибо бесплатные прокси много где используются. И их бан может резко ограничить трафик на сайт. Однако ещё раз, надо смотреть. Ну и с производительностью - 100 тысяч, это смешно. Мой парсер сайта избиркома парсил 300 тысяч часа за три. На обычном ноутбуке, даже не сильно навороченном.
P.S. Если хотите, могу поискать тот свой код на java. Правда писалось это в 18-м году под президентские выборы, причем писалось второпях и довольно грязно. Но работало отлично.
Под капотом у системы распознавания как раз много алгоритмов, которые понимают бот ты или человек. Нужна имитация настоящего поведения. Не запросы. Просто попробуйте спарсить для примера озон (только ради науки) и посмотрите список возникающих проблем.
Я и не говорю что всё просто ! Но уверен, что всё решаемо. Разумеется гляну на озон, спасибо за интересную наводку !
Чаще всего, данные на странице формируются через JavaScript. Простыми запросами вы эти данные не увидите, - только через браузер.
Не думаю чтобы это представляло собой совсем уж неразрешимую проблему. Есть node.js. Прикрутить к нему нечто, имитирующее работу библиотеки dom, задача хоть и большая, но думаю вполне решаемая. Впрочем с джаваскриптом я сталкивался лишь однажды. Да и то не с dom, а с небольшим арифметическим примером, который надо было выполнить. Что легко делалось с помощью node.js
Я и не говорил, что это большая проблема )
Все зависит от технологий, которые вы используете. Можно даже и не имитировать поведение пользователя как такового. Брать хеш реального пользователя с его браузером и скармливать его голому селениуму.
Есть node.js. Прикрутить к нему нечто, имитирующее работу библиотеки dom, задача хоть и большая, но думаю вполне решаемая.
Но зачем это делать, когда есть уже куча готовых инструментов с готовыми примерами, туториалами, документацией? Если для поупражняться для себя, то нормально, но если брать случай из статьи, то в разы надежнее и дешевле взять готовые либы, которых сейчас много и которые будут поддерживаться.
На ноде вам для начала придётся написать DOM – хотя бы для того, чтобы получить со страницы скрипты, которые надо выполнять. А потом будете натыкаться на несоответствия с поведением браузера и писать костыли для их обхода. В то время как есть headless браузеры – которые ведут себя, как браузеры, просто не рендерят картинку.
Собираю продавцов на Озон. Конечно, данные собираю через браузер, но не через открытие страницы товара. Нужные данные идут по API через GET. Просто открываю эти ссылки в браузере. Проблем нет.
Самое интересное и не рассказали: что вы делали когда Selenium закончился?
Как боролись с Cloudflare и прочей рекапчей? Сталкивались ли с банами по принадлежности подсети к датацентру? А по геолокации? Что делали с данными вроде телефона продавца, которые отображаются только для залогиненных пользователей? Что парсите, html или какое-то представление DOM? Чем парсите, lxml, суп или что-то еще? Как парсите, CSS-селекторы, xpath, регулярки?
Спасибо за наводку, обязательно дополню статью.
А как может Selenium закончиться? Используем фермы с распределением по серверам. Для примера https://www.selenium.dev/documentation/grid/getting_started/
Я тоже немного не понял как он может закончиться)
Selenium заканчивается когда защита начинает его детектировать и отказывается пропускать дальше. Начиная с проверки navigator.webdriver и далее кто на что горазд.
Речь скорее всего о том, что Selenium стал детектиться на том сайте, который парсит автор вопроса. Или вообще современный антибот поставили, который на одном Selenium не объедешь.
Немного дополнил статью
Как боролись с Cloudflare
Нет универсальных решений. Cloudflare - это 100500 настроек.
Что делали с данными вроде телефона продавца, которые отображаются только для залогиненных пользователей?
Если про упомянутый автором Авито, то это не так. Нужно просто кликнуть "Показать телефон", логин не нужен.
Как парсите, CSS-селекторы, xpath, регулярки?
Конкретно на Авито все данные лежат в json в переменной initialData. На блюдечке с голубой каемочкой.
Вы по факту вступили в гонку вооружений с теми сайтами, которые пытались парсить. Гонка вооружений - это всегда беспредельное пожирание денег, времени и т.д. Гонка вооружений стала одним из факторов развала СССР. У вас точно нет для этой гонки такого количества ресурсов, как у тех, кого вы парсите. Либо у вас/заказчика такая гонка попросту не окупится
Да вы правы, мы будем постоянно не успевать за новыми средствами защиты. Как борьба с мельницами.
Очень дискуссионное заявление. Арсенал защиты от парсинга крайне мал.
Я как-то хотел накачать материалов с e-hentai. Там, чтобы качать самому беспрепятственно, надо донатить или самому что-то заливать. Я написал парсер. В итоге меня начали банить по IP. Я начал раздумывать о том, как мне 100% обойти их защиту. В итоге пришёл к тому, что ради этого мне придётся арендовать несколько виртуалок и распределять по ним все запросы по скачиванию отдельных картинок, а потом все их вместе собирать как-то обратно в сеты. В общем, я понял, что оно того не стоит. Арсенал, быть может, и мал, но его хватает
Посмотрите в сторону открытого проекта
https://github.com/KurtBestor/Hitomi-Downloader
ваш сайт там тоже есть
Вопрос в цене данных. Для дешёвой порнухи - оно того не стоит, но есть много более ценной информации, когда - стоит.
Проблема не в арсенале а в постоянных изменениях в "API" по любой причине которые потом при парсинге отваливаются, ведь самому сайту плевать что там у парсеров
Достаточно слегка менять структуру странички, чтобы коэффициент затрат времени был 10 к 1 не в пользу парсера.
потратить 2-3 дня, сделать с пяток шаблонов, стили, id поставить переменными и выбирать рандомный шаблон при отдаче клиенту. В таком случае - если ты только сел парсить сайт - быстренько сойдешь с ума и плюнешь на это дело, ибо закономерностей не видно.
А уж специализированные средства... (
SSR сайтов совсем не много и данные получать очень просто. Посмотрите мои парсеры - там так много второстепенной информации как раз потому, что отфильтровать лишнее сложно и просто выкатываю весь доступный джейсон.
А в случае SSR структура меняется довольно редко и если не стрелять себе регулярками по ногам, то селекторы работают вполне надёжно.
пришлось поднять RabbitMQ для разграничения по очередям запросов. Отдельно для каждой площадки, для каждой категории недвижимости. Это было очень сложная задача
Для названных вами объемов может подойти Firebase RTDB. Для каждой категории писать очередь в свой /тред, читать первый по sort by timestamp. Вряд ли дороже аренды сервера, а выглядит проще некуда.
Rbbitmq поднимается в 2 команды из докера, и почти не требует настроек и администрации для такой маленькой задачи
И при этом решает огромный пласт проблем при парсинге
Сам занимаюсь парсингом Wildberries, 100млн+ товаров в день, примерно 10к товаров с секунду
И со всем этим простой rabbotmq с persistent очередями справляется
2023 год. Продуктовая команда разработчиков ВДРУГ узнала, что парсинг сайтов - это сложно. Ясно-понятно.
Если сайт, который нужно парсить, хоть как-то минимально развивается/улучшается, то и парсер тоже надо будет постоянно дописывать/изменять. Даже если нет защиты от парсинга. Это бесконечный процесс.
В демо-версии в списке агентств я насчитал 40 агентств, это у вас столько клиентов?
Если посчитать по тарифам, то затраты 50 к на сервер окупаются?
И насколько пользуются спросом другие функции системы? Воронки, сделки и прочее.
Сам давно занимаюсь автоматизацией агентств недвижимости и сложилось впечатление, что риэлторам плевать на автоматизацию и прочие ништяки, им главное дозвониться до клиента быстрее конкурента, а дальше включать харизму.
Если представить эту задачу как этап собеседования в виде system design в крупную IT-компанию, то асинхронная архитектура, распределение задач по воркерам и учёт URL были бы ожидаемы для миддл разработчика. В течение 45-минутного собеса.
Adspower антик позволяет управлять браузером через puppeteer, при этом каждый раз создавать браузер с уникальным фингерпринтом. Для тестов там даже бесплатного тарифа за глаза хватит.
С опытом "простых" задач будет асе меньше, а "сложных" все больше. И желание браться за подобное будет отбито напрочь.
Мы в свое время, еще до gpt-бума, пошли через ml и конкретно nlp. Проще натренировать нейронку на извлечение данных и понимание сути спарсенного, чем постоянно гнаться за различными переделками каталогов у множества ресурсов.
Как пример - электротехническая и кабельная продукция. Один и тот же кабель может называться абсолютно по-разному у разных поставщиков, хотя по характеристикам схож.
Нейронка это понимает и складирует куда надо сама. После реализовали даже вывод в 1С поставщиков для их категорийных менеджеров, чтобы им было удобнее сравнивать себя с конкурентами и подаваться в тендеры.
Таким образом, часть задачи решаема просто иным путем.
Но на счет банов, прокси и прочего - проблемы схожие, хотя сложности обходяться, как выше в комментариях указали.
Задача на 15 минут. Как она может вылиться в год разработки