Парсер Гугл Карт: Реальное решение для парсинга отзывов — многопоточный скрипт!

По работе я периодически сталкиваюсь с тривиальными задачами — скачать весь Фейсбук и сделать его копию… Или — спарсить все отзывы с Гугл карт — бюджет 100 долларов! Ну вы поняли, я думаю. Масштабные задачи, которые нужно решать в условиях ограниченного бюджета — это вызов, ну и опыт, конечно же. С Фейсбуком я конечно перегнул, но с Гугл картами вполне себе правдивая история.

Задача прилетела в условиях тотальнейшей экономии бюджетных средст, так что платные АПИ не рассматривались в принципе, как класс, но парсить отзывы с Гугл карт нужно. Думали, думали и наконец придумали такую машину.

Парсер отзывов с Гугл Карт — решение для бедных экономных

Google Maps — это по сути гигантская база POI: от уличных кофеен до офисов корпораций. В карточках лежат названия, адреса, контакты, рейтинги и, главное, массив отзывов. Для маркетинга, SEO и аналитики это золотая жила: на таких данных строят лид-ген, конкурентный разбор и даже рыночные исследования. А вот для разработчиков парсеров это нередко источник боли: либо дорого, либо сложно, либо и то и другое сразу. Либо у заказчика нету денег.

У Google, конечно, есть официальный путь — Places API. Всё легально, но за деньги и с квотами по частоте. На больших объёмах бюджет стремительно тает, а лимиты упираются в потолок. Поэтому бизнесы часто идет альтернативной тропой: снимают отзывы (спойлер — так делал и я) и прочие поля напрямую из веб-версии карт, обходя официальный API.

Мой маршрут был классическим. Сначала попытался уложиться в API, посчитал юнит-экономику — не сходится. Перестроил подход: вместо оплаты лимитов — прокси + многопоточный парсер. По факту из расходов остались только прокси: стандартная цена примерно $5/ГБ. Если брать объёмом 30 ГБ, цена падает до $3/ГБ — заметно приятнее, е=можно поискать еще дешевле, но уже могут начаться вопросы к качеству.

Теперь по метрикам: я выгрузил 53 000 строк, съелось около 3 ГБ трафика — те же $15. В среднем одна точка обходится примерно в 58 КБ. Значит, пакет на 30 ГБ потянет порядка 530 000 строк. На мой взгляд, это существенно выгоднее, чем идти через официальный API. Да, времени будет тратится в разы больше, но экономия то налицо!

Для масштаба: два пути к данным и их цена — сравниваем подходы при парсинге отзывов с Гугл Карт напрямую через АПИ и моим способом

Вариант 1: Google Places API — парсинг Гугл Карт через официальное АПИ

Официальный канал к структуре по POI внутри экосистемы Google. Из коробки — поиск по ключевым словам/координатам и JSON-выдача с именем, адресом, телефоном, сайтом, рейтингом, отзывами и пр. По деньгам: в Google Cloud раньше был бесплатный кредит в $200, но при активной загрузке его хватало ненадолго (сейчас же они включили бесплатные квоты, там порядка 10000 запросов, что крайне немного и если парсить отзывы с Гугл карт в бесплатном режиме, большие объемы растянутся на недели). Когда бесплатную квоту выгребли — включается тарификация: усреднённо ~$32 за 1000 вызовов (стоимость плавает по типу запроса и объёмам; первые 100k — примерно те же $32/1000, затем немного дешевле). Если выгружать 50 000 объектов без учёта бесплатной квоты — около $1600.

Даже если проблема не в деньгах (кого я обманываю), появляется второй барьер — квоты по частоте и объёмам. Их нужно уважать и подстраивать под них пайплайн.

Вариант 2: Прямой парсинг Google Maps через инструменты иммитации

Альтернатива: имитируем пользователя, открываем страницы карт и вытягиваем нужные сущности напрямую. Плюсы: нет API-ключа, нет оплаты за каждый запрос, удобнее для разовых задач и MVP. Часто доступны поля, которых нет в Places API: дополнительные фото, ссылки на профили, большие массивы отзывов. Минусы весомые: исключим то, что это противоречит условиям использования Google Maps (даже если данные публичные), есть еще неприятности в виде самого Гугла, он же активно защищается: капчи, временные блокировки по IP, внезапные изменения разметки, ломающее селекторы.

Зато финансовая сторона приятнее: фактически платим только за прокси. Мой парсер в 10 потоков собрал ~50 000 отзывов за несколько часов, израсходовав ~3 ГБ трафика прокси ($15).

Откуда взялся мой парсер Google Maps (Google Map Scraper)

Как я писал выше — запрос на быстрые данные и бюджет, который не сходится с Places API, привели к написанию собственного инструмента. Сегодня он закрывает задачу; если Google поменяет верстку, потребуется подправить логику — обычно это небольшие доработки (революций в UI в последнее время не было).

Исходники лежат у меня на GitHub: Google-Map-Scraper. Ниже — как всё устроено.

Архитектура парсера Гугл Карт — как парсинг отзывов устроен изнутри

Парсер состоит из трёх основных скриптов и входного CSV:

• Входной файл places.csv — поля: place_id, name (опционально category, categories, polygon_name, place_url). Это артефакты моего пайплайна — при желании можно почистить структуру, но придётся синхронно поправить код.

Ключевое — place_id (уникальный ID в Google). Ссылка формируется через ?q=place_id:<ID>.
Где взять place_id? Дёшево — на Apify; можно и через Google API (будет платно, но совсем не $1600 за 50k точек). И да, я уже реализовал второй парсер по сбору ссылок — но в паблике его еще нет, пока не дошли руки до этого, но в ближайшее время залью на Гитхаб, так что если нужен, подписывайтесь (какая пошлятина).

• Главный файл — main_reviews.py:
  • грузит места и прокси;
  • считает реальное число воркеров: min(threads, len(proxies));
  • закрепляет прокси «один поток — один прокси»;
  • распределяет задачи по шагам;
  • запускает ThreadPoolExecutor.

Каждый поток вызывает process_one → scrape_place_reviews(place, proxy) из scrape_reviews.py, делая до MAX_RETRIES_PER_PLACE попыток.

• Сердце парсинга scrape_reviews.py:
  • стартует Playwright с заданным прокси;
  • проходит баннер согласия, открывает вкладку «Отзывы»;
  • ставит сортировку «По новизне», при необходимости включает автоперевод;
  • находит реальный контейнер скролла;
  • скроллит с паузами, разворачивает «Показать ещё»;
  • вытягивает карточки (автор, рейтинг, дата, текст, фото, флаг Local Guide, сырой JSON);
  • отдаёт список строк.

Запись результатов делает main_reviews.py под глобальным lock в output_reviews.csv. В финале — аккуратное закрытие page/context/browser и сводка.

Что пришлось «дошлифовать» в процессе написания парсера отзывов Гугл Карт

Метод проб и ошибок доводит инструмент до «неубиваемого» состояния. Однако, это не означает что учтено все, естественно можно раскопать кучу огрехов. Из значимого:

• Прокси в Playwright: поддержка http/https/socks5/socks5h + user:pass@host:port. Разбор через parse_proxy_for_playwright() и передача в browser_type.launch(headless=..., proxy=...). Проблемы с Socks всплыли сразу — починил в первых версиях.
• Экономия трафика без сломанного UI: роутинг по request.resource_type — отсекаем media/font/manifest/ads/analytics, но не режем stylesheet и image, чтобы не развалить макет. До стабильного поведения карты дошёл не сразу: без стилей/изображений верстка дёргается и ломает скролл.
• Анти-попап и consent:
  • handle_google_consent() нажимает Reject/Accept на разных локалях;
  • принудительно глушу window.open, лишние вкладки закрываю, если домен не google.*.
    Это появилось, когда включил прокси и мультипоток: всплывали окна согласия и открывались «левые» страницы (часто TripAdvisor из встроенной выдачи).
• Фото из отзывов: как дополнение — собираю URL фотографий, склеивая в одну строку.

Остальное — рутинный разбор карточек и скроллинг.

Многопоточность парсера — важная составляющая парсинга Гугл Карт, иначе на большом объеме это все бесполезно

Почему параллель важен? Одна локация может скроллиться десятки секунд (иногда минуты). Параллель ускоряет сбор во много раз.

Модель простая: 1 поток = 1 уникальный прокси.
10 потоков → подготовьте 10 прокси. Если прокси меньше — число воркеров автоматически урежется до их количества.

Рекомендации из практики:

• стартуйте с --threads 3..5 и таким же количеством прокси;
• без прокси не поднимайте выше 2–3 потоков — быстро упрётесь в капчи/пустые выдачи;
• следите за памятью: Chromium в Playwright прожорлив, ~300–600 МБ на поток — реальный ориентир; выше 10 потоков ловил OOM в браузере. Но я обратил внимание, что парсеру вообще неважно, сколько у вас памяти — есть 16 Гб — жрет 16, есть 32 Гб — это ему тоже надо, жрет все.

Прокси: какие и почему

Поддерживаемые форматы:
http://, https://, socks5://, socks5h:// (включая user:pass@host:port).
Socks5h резолвит DNS на стороне прокси — полезно при геоблоках/утечках DNS.

Зачем обязательно прокси? Потому что Google режет аномальный трафик с одного IP: капчи, пустые выдачи, редиректы на проверки. Ротация адресов распределяет нагрузку и делает поведение «похожим на толпу пользователей».

Резидентные vs датацентр: для карт — фактически безальтернативно резидентные. Капч меньше, поведение естественнее, хотя и дороже по трафику. Датацентр-IP часто банятся быстрее — теряете целые сессии.

Подготовка:

• прогоните несколько прокси заранее, отберите стабильные;
• распределите по потокам; при 10 прокси и 5 потоках можно чередовать, чтобы у потока было 2 адреса в ротации.

Файл proxies.txt понимает, например:

socks5h://user:pass@br.r-resi.net:1080
http://user:pass@fr.r-resi.net:8080
socks5://user:pass@de.mobile-resi.io:1080

Без прокси инструмент годится разве что на пару сотен записей. Для регулярных больших сборов прокси — маст-хэв.

Реальная экономика парсинга Гугл карт

• Прокси (резидентные): обычно помегабайтная тарификация. На большой прогон отзывов хватает 1–5 ГБ → ~$3–$25 (в диапазоне 50k–500k записей, грубо).
• Решатели капчи (опционально): $1–$10 за прогон; с нормальными прокси часто не нужно.

Итог — несколько десятков долларов за крупные выгрузки (вместо сотен/тысяч при API). Единственная скрытая статья — ваше время.

Как не словить бан при парсинге отзывов с Гугл Карт

• жёсткое правило: 1 поток = 1 прокси;
• имитируйте «человечность»: не занижайте SCROLL_PAUSE_MS;
• гео прокси ≈ гео данных (RU → RU, EU → EU);
• не отключайте изображения/стили — карта «сыпется», селекторы плавают;
• включайте DEBUG_SELECTORS и смотрите логи — сразу видно, где «встала» лента;
• планируйте лимиты и чекпоинты — не пытайтесь охватить всё сразу.

Парсинг Google Maps — нетривиальная, но вполне решаемая инженерная задача. Она отлично иллюстрирует динамический DOM, антибот-механику и организацию мультипоточных пайплайнов. Нужен ли вам свой парсер — зависит от целей: мне он уже многократно окупился и продолжает работать стабильно.