Как парсить сайты с большими даннымиизвлечение масштабной аналитики

Одни из крупнейших и наиболее актуальных наборов данных на планете не продаются на рынках и не поставляются в виде файлов. Они находятся на виду на публичных веб-сайтах: миллионы товарных предложений, цены, меняющиеся каждый час, отзывы, поисковые рейтинги и социальные сигналы. Проблема никогда не в том, чтобы найти данные, а в том, чтобы собрать их в достаточном объёме, достаточно часто, чтобы они были полезны. Именно это и подразумевается под крупномасштабным веб-скрапингом больших данных: сбор веб-данных в таком объёме и с такой скоростью, когда человек, вручную просматривающий страницы, уже не является вариантом.

Это руководство объясняет, что считается крупным источником веб-данных, почему масштаб и рендеринг JavaScript, две проблемы, которые делают это сложным, где фактически находится бизнес-ценность и как управляемый краулер превращает «миллиарды страниц» из лозунга в рабочий процесс. В конце вы будете достаточно хорошо понимать движущиеся части, чтобы решить, стоит ли строить уровень сбора самостоятельно или передать объём сервису.

Что такое крупномасштабный веб-скрапинг?

Веб-скрапинг, это автоматизированное извлечение данных с веб-страниц. Крупномасштабный веб-скрапинг, та же идея, доведённая до масштаба, при котором меняются узкие места. Сбор нескольких сотен записей, это задача для скрипта: запросить страницу, распарсить HTML, сохранить поля. Сбор нескольких сотен миллионов записей с тысяч сайтов, это задача для инфраструктуры, где пропускная способность, блокировки, рендеринг страниц, повторные попытки и хранилище имеют гораздо большее значение, чем сам парсинг.

«Большие данные» здесь обычно описываются знакомыми тремя «V». Объём (Volume), это чистое количество страниц и записей, нередко в миллионах или миллиардах. Скорость (Velocity), это то, как быстро меняются данные и, следовательно, как часто их нужно пересобирать: ценовой поток бесполезен, если ему неделя. Разнообразие (Variety), это смесь форм, которые вы извлекаете, от аккуратных таблиц товаров до произвольных текстовых отзывов и вложенного JSON, скрытого в скриптах страницы. Настройка крупномасштабного скрапинга должна выдерживать все три одновременно, а не только одно из них.

Выигрыш в том, что веб-данные в масштабе становятся конкурентным активом. Необработанные записи превращаются в прогностические сигналы, на которые опираются ритейлеры, производители, страховщики, финансовые компании и сервисные предприятия, чтобы читать рыночные тенденции, находить возможности и принимать решения на основе данных, а не догадок. Данные общедоступны, а ценность реальна, именно поэтому столько усилий уходит на их качественный сбор.

Где живут большие данные: высокоценные веб-источники

Не каждый сайт стоит затраченных усилий. Источники, которые окупают крупномасштабный сбор, как правило, разделяют одну черту: много страниц, часто обновляемых, описывающих то, что бизнесу нужно отслеживать. Несколько из них встречаются снова и снова.

Маркетплейсы e-commerce

Маркетплейсы вроде Amazon и eBay, канонический источник больших данных. Они содержат миллиарды объявлений с ценами, описаниями, размерами, доступностью по регионам и отзывами, и большая часть этого постоянно меняется. Для команд e-commerce и ритейла это конкурентная разведка в необработанном виде: отслеживайте цены конкурентов в почти реальном времени, наблюдайте за движением запасов и изучайте отзывы на предмет того, что клиенты хвалят и на что жалуются. Эта обратная связь напрямую питает продуктовые исследования и ценовую стратегию. Те же данные помогают производителям совершенствовать свои продукты до их выхода на полку. Наш обзор скрапинга e-commerce охватывает поля данных, которые раскрывают эти сайты.

Результаты поисковых систем

Поисковые рейтинги сами по себе являются набором данных. Крупномасштабный парсинг поисковых результатов показывает вам, где вы занимаете позиции относительно конкурентов по ключевым словам, которые имеют значение, как составлена страница результатов и какие игроки выигрывают в видимости. Для SEO и маркетинговых команд это разница между угадыванием стратегии и её измерением. Отслеживание позиций по тысячам запросов во времени превращает расплывчатое ощущение «нам нужно лучше ранжироваться» в конкретную, отслеживаемую цель.

Социальные платформы и публичные профили

Публичные социальные данные (профили, публикации, хэштеги и сигналы вовлечённости) помогают компаниям понимать демографию и интересы на интересующих их рынках. Бренды и лидеры мнений могут оцениваться по оставленному ими публичному следу, а агрегированные сигналы раскрывают, какой контент набирает популярность, а какой угасает. Это также источник, требующий наибольшей осторожности: данные профилей описывают людей, поэтому они подпадают под законодательство о конфиденциальности и условия платформ в той мере, в какой цена товара не подпадает. Собирайте агрегированные публичные сигналы; не создавайте профили отдельных людей.

Сайты недвижимости, туризма и другие агрегаторы объявлений

Любая вертикаль, построенная на объявлениях, является кандидатом для работы с большими данными. Порталы недвижимости раскрывают объекты, цены и местоположения, которые агентства используют для поиска перспективных клиентов и сопоставимых продаж. Туристические и сервисы бронирования предоставляют тарифы и доступность, меняющиеся каждую минуту. Паттерн последователен: большое количество страниц, частые изменения и структурированные записи под страницей, которые стоит отслеживать во времени.

Почему масштаб меняет задачу

Сбор одной страницы и сбор ста миллионов страниц, это не одна и та же задача с большим числом. Три проблемы появляются только при объёме, и именно они отделяют скрипт, написанный за выходные, от производственной системы.

Первая, блокировки. Несколько запросов с одной машины похоже на человека. Десятки тысяч запросов с одного IP-адреса выглядят как бот, и сайты реагируют блокировкой IP, ограничением частоты запросов и CAPTCHA. При масштабировании вам нужен большой, ротирующий пул IP-адресов и паттерны запросов, которые не срабатывают эти защиты, иначе ваш сбор останавливается после первых нескольких тысяч страниц. Наш гид о том, как парсить сайты без блокировок, подробнее рассматривает применяемые техники.

Вторая, параллельность и пропускная способность. Чтобы загрузить миллионы страниц за день, вы не можете запрашивать их одну за другой; вам нужно много одновременных запросов с очередями, повторными попытками при сбоях и противодавлением, чтобы медленный сайт не останавливал весь процесс. Управление таким масштабированием надёжно, это реальная инженерная задача, и именно здесь большинство самодельных парсеров ломается по мере роста.

Третья, хранилище и структура. Большой запуск производит поток необработанного HTML и распарсенных записей, которые должны оказаться где-то поддающемся запросам. Без плана того, куда идут данные и какую форму они принимают, вы заканчиваете с кучей файлов, которые никто не может проанализировать. Объединение сбора с пунктом назначения, будь то хранилище данных или облачное хранилище, является частью проекта с самого начала; смотрите наши заметки о хранении спарсенных данных в облаке.

Почему рендеринг важен при масштабировании

Другая проблема, которая незаметно подкрадывается при больших коллекциях, JavaScript. Многие современные сайты, всё, созданное на React, Angular, Vue или аналогичных фреймворках, отправляют почти пустой HTML-шаблон, а затем строят видимую страницу в браузере, запуская скрипты и загружая данные после. Простой HTTP-запрос к такой странице возвращает шаблон, а не контент. Цены, объявления и отзывы, за которыми вы пришли, попросту отсутствуют в ответе.

Для сбора с таких сайтов вам нужно рендерить страницу так, как это делает браузер: выполнить JavaScript, дождаться загрузки контента, а затем прочитать готовый HTML. Сделать это для одной страницы несложно с помощью headless-браузера. Сделать это для миллионов страниц дорого, потому что каждая отрендеренная страница потребляет значительно больше вычислительных ресурсов и памяти, чем простой запрос. При масштабировании решение о том, каким страницам действительно нужен рендеринг, а какие можно получить обычным запросом, становится реальным рычагом снижения затрат. Наш гид по обходу сайтов на JavaScript подробно охватывает механику.

Как управляемый краулер справляется с объёмом

Именно здесь самостоятельное создание всего перестаёт иметь смысл для большинства команд. Управляемый сервис для обхода существует, чтобы взять на себя именно три проблемы, описанные выше (блокировки, пропускная способность и рендеринг), чтобы ваш код работал только с данными. Crawling API Crawlbase обрабатывает ротацию IP и решение CAPTCHA через единый эндпоинт, при запросе рендерит JavaScript-страницы и возвращает страницу, чтобы вы могли распарсить нужные поля. Вы указываете на URL и получаете обратно рабочий HTML, без необходимости запускать ферму браузеров или поддерживать пул прокси самостоятельно.

Для настоящего объёма больших данных синхронная модель «запрос-ожидание» слишком медленна: вы не хотите держать соединение открытым для каждой из миллиона страниц. Именно здесь подходит асинхронный краулер. Вместо ожидания каждого ответа вы помещаете URL в очередь, и сервис обходит их в фоне, а затем доставляет каждую готовую страницу на эндпоинт обратного вызова вашего сервера по мере завершения. Ваш сервер становится простым слушателем, который получает страницы и сохраняет или парсит их. Это разделение и позволяет установке загружать миллионы страниц в день без того, чтобы ваш код следил за каждым запросом.

Форма обратного вызова намеренно проста. Вы создаёте эндпоинт, регистрируете его в краулере и получаете каждую обойденную страницу по мере её поступления:

const http = require('http');

function handleRequest(request, response) {
  if (request.method !== 'POST') return response.end();
  const url = request.headers.url;
  let body = '';
  request.on('data', (chunk) => (body += chunk));
  request.on('end', () => {
    // body is the page HTML, ready to parse and store
    console.log(url, body.length);
    response.end();
  });
}

http.createServer(handleRequest).listen(80);

Краулер делает POST каждой готовой страницы на этот эндпоинт, передавая исходный URL в заголовке, чтобы вы знали, какую страницу получили. Какой бы язык ни использовал ваш стек, паттерн один и тот же: небольшой слушатель, принимающий страницы и отправляющий их в ваш процесс парсинга и хранения. Продакшн-версия добавляет обработку ошибок, проверку кодов статуса и логирование, но основа остаётся такой простой. Для более полного описания асинхронной модели смотрите наш гид по асинхронному Crawler и наш обзор извлечения данных с помощью Crawlbase Crawler.

От необработанных страниц к используемым данным

Сбор страниц, лишь половина работы. Большой запуск оставляет вас с необработанным HTML или извлечёнными полями, которые всё ещё должны стать чистым, доступным для запросов набором данных, прежде чем кто-то сможет его проанализировать. Два шага превращают поток в нечто полезное.

Первый, парсинг в структуру. Страницы созданы для человеческих глаз, поэтому одно и то же поле (цена, рейтинг, название) появляется в разной разметке на каждом сайте. Вы сопоставляете каждый источник с согласованным набором полей, чтобы товар с одного маркетплейса совпадал с товаром с другого. Инструмент, автоматически парсящий распространённые типы страниц, например Crawling API, снимает большую часть этой работы, возвращая готовые поля вместо необработанного HTML для поддерживаемых сайтов.

Второй, размещение данных там, где к ним можно делать запросы и объединять их. Для анализа в масштабе это обычно означает базу данных или хранилище, где записи из многих запусков накапливаются и питают дашборды, модели и отчёты. Наш гид о скрапинге в SQL для хранения и анализа данных показывает, как этот пункт назначения связывает весь конвейер вместе, а построение масштабируемого конвейера веб-данных охватывает оркестрацию вокруг него.

Кто использует крупномасштабный веб-скрапинг?

Короткий ответ, большинство компаний, ориентированных на данные, в большем количестве отраслей, чем люди ожидают. E-commerce и ритейл отслеживают цены конкурентов и отзывы для формирования собственной стратегии. Производители изучают обратную связь о продуктах и сигналы спроса, чтобы формировать то, что они создают. Страховщики и финансовые компании превращают исторические и рыночные данные в модели рисков и ценообразования. Компании по недвижимости сканируют объявления для поиска перспективных клиентов и сопоставимых продаж. Маркетинговые и SEO-команды измеряют поисковую видимость относительно конкурентов. Общая нить в том, что каждый из них рассматривает веб-данные как сырьё для принятия решений, и в том масштабе, которого требуют эти решения, ручной сбор попросту не является вариантом.

Ответственный скрапинг

Масштаб делает ответственную практику более важной, а не менее. Собирайте только публичные данные, соблюдайте условия использования и robots.txt каждого сайта, поддерживайте разумную частоту запросов, чтобы не ухудшать сервис для других; ротация и темп управляемого краулера здесь помогают, но ответственность всё равно на вас. Когда данные описывают людей, например социальные профили, обращайтесь с ними как с персональными данными: агрегируйте их, не создавайте профили отдельных людей и следуйте правилам конфиденциальности, таким как GDPR и CCPA. Публичность и масштаб не означают вседозволенность, и встраивание этих ограничений с самого начала ставит крупный проект с данными на правильную сторону как закона, так и добросовестности.

Часто задаваемые вопросы

Что такое крупномасштабный веб-скрапинг?

Крупномасштабный веб-скрапинг, это автоматизированный сбор веб-данных в масштабе, при котором пропускная способность, блокировки, рендеринг и хранилище имеют большее значение, чем сам парсинг. Вместо нескольких сотен записей вы собираете миллионы или миллиарды с множества сайтов, нередко пересобирая их часто, поскольку данные быстро меняются. Это меньше задача для скрипта и больше инфраструктурная задача, именно поэтому команды обращаются к управляемым краулерам и асинхронному сбору, а не к одномашинному скрипту.

Какие веб-сайты являются лучшими источниками больших данных?

Наиболее ценные источники, сайты с множеством страниц, частыми обновлениями и структурированными записями: маркетплейсы e-commerce, такие как Amazon и eBay, для цен, объявлений и отзывов; поисковые системы для данных рейтингов и видимости; публичные социальные платформы для демографических сигналов и сигналов вовлечённости; и вертикали с обилием объявлений, такие как недвижимость и туризм. Общая черта, большой объём и постоянные изменения, что делает крупномасштабный повторяющийся сбор целесообразным.

Почему масштаб сложнее, чем парсинг одной страницы?

При больших объёмах появляются три проблемы, с которыми небольшой скрипт никогда не сталкивается. Сайты блокируют высокую частоту запросов через блокировку IP и CAPTCHA, поэтому нужны ротация и паттерны, имитирующие человека. Необходимо много одновременных запросов с очередями и повторными попытками для обработки миллионов страниц в день. А вывод должен где-то оседать в доступном для запросов виде, поэтому хранилище и структура становятся частью проекта. Парсинг (задача небольшого парсера), по сравнению с этим простая часть.

Нужно ли мне рендерить JavaScript для скрапинга больших данных?

Только для сайтов, которые строят свой контент в браузере. Страницы, созданные на таких фреймворках, как React или Angular, часто отправляют пустой шаблон и загружают реальные данные после, поэтому простой HTTP-запрос упускает их, и вы должны рендерить страницу как браузер. Рендеринг значительно дороже простого запроса, поэтому при масштабировании вы проверяете каждый сайт и рендерите только те страницы, которые в этом нуждаются, запрашивая остальные обычным способом для экономии.

Как управляемый краулер справляется с миллионами страниц?

Управляемый краулер обрабатывает ротацию IP, решение CAPTCHA и опциональный рендеринг JavaScript через единый эндпоинт, поэтому ваш код никогда не касается прокси или браузеров. Для объёма он использует асинхронную модель: вы помещаете URL в очередь, и сервис обходит их в фоне, доставляя каждую готовую страницу на эндпоинт коллбэка вашего сервера по мере завершения. Это разделение позволяет загружать миллионы страниц в день без необходимости держать соединение открытым для каждой из них.

Легален ли крупномасштабный веб-скрапинг?

Сбор публичных данных в целом допустим, но законность зависит от того, что вы собираете и каким образом. Соблюдайте условия использования и robots.txt каждого сайта, поддерживайте разумную частоту запросов и придерживайтесь публичной информации. Когда данные описывают людей, например социальные профили, они становятся персональными данными, подпадающими под нормативные акты, такие как GDPR и CCPA, поэтому агрегируйте их и избегайте профилирования отдельных людей. Безопасная позиция: публичные данные, разумная частота и соблюдение конфиденциальности встроены с самого начала.

FQ

Farah Qadeer

Специалист по визуализации контента · Crawlbase

Специалист по визуализации контента в Crawlbase, превращает сложные темы прокси и веб-скрейпинга в понятные визуализации и пошаговые руководства.