Искусство парсинга веб-страниц — ЧАСТЬ 1
Table Of Content
Введение:
Информация является ключом к пониманию отраслей, управлению компаниями и предоставлению контроля каждому потребителю. С появлением эпохи данных возросла необходимость в извлечении, проверке и анализе данных.
Цель:
С таким большим вниманием к добыче данных (в частности, к способности анализировать информацию и в процессе генерировать новую информацию), некоторые методы извлечения данных остались в тени.
В этой серии рассматриваются некоторые концептуальные инструкции по извлечению данных из веб-страниц с помощью парсеров. Также упоминаются некоторые современные библиотеки и языки программирования, используемые в индустрии.
Эта статья является общим введением в то, что такое парсер веб-страниц, когда он полезен и как он работает.
Что такое парсинг веб-страниц?
Определение: Википедия определяет парсинг веб-страниц как извлечение данных с веб-сайтов.
Когда это полезно?
Парсинг веб-страниц может использоваться в качестве способа использования уже существующего сервиса. Вокруг извлеченной информации с веб-сайта можно создать API. Это особенно полезно, если нет доступного общедоступного API или если API не содержит необходимой информации.
Как это работает?
Сначала давайте попытаемся понять, как браузер видит веб-страницу. Веб-страница, состоящая из HTML, CSS и JS, отправляется с веб-сервера на клиентскую сторону через интернет или какую-либо сеть. Браузер клиента расшифровывает код страницы и отображает его соответствующим образом. Это самая основа базовой веб-страницы.
Теперь давайте разберем методы, с помощью которых части веб-страницы отображаются. Мы рассмотрим 2 основных метода: серверная и клиентская отрисовка веб-страницы.
Серверный рендеринг (SSR):
Браузер получает готовый HTML веб-страницы. Веб-страница уже отрендерена; все данные, зависящие от API, собираются бэкэндом и преобразуются в HTML к моменту достижения браузера пользователем. Затем браузер отображает страницу.
Клиентский рендеринг (CSR):
Браузер получает HTML с ссылками на JavaScript, который затем выполняется браузером для отображения веб-страницы; это делает браузер клиента ответственным за сборку HTML и любых других данных веб-страницы. Затем браузер отображает страницу.
Эти основные методы могут быть объединены для различных частей страницы; например, основная структура веб-сайта может быть SSR, но иметь элементы CSR для динамического контента и т. д.
Например, предположим, что есть некоторые данные из внешнего API, которые требуются для отрисовки определенной части веб-сайта.
Основная структура веб-страницы может быть SSR или CSR.
- Предположим, что динамическая информация может быть CSR. Запрос на получение информации затем будет исходить из браузера клиента. Как только браузер получает данные, он преобразует их в HTML и отображает их.
- Предположим, что динамическая информация является CSR. Запрос на получение информации затем будет исходить от сервера бэкэнда, ответственного за генерацию веб-страницы. Данные затем обрабатываются и преобразуются в HTML, а затем передаются клиенту.
Типы парсеров:
Большинство парсеров можно разделить на 2 основные подгруппы в зависимости от метода, с помощью которого информация на веб-странице отображается.
В будущем я расскажу о некоторых примерах этих различных парсеров и предоставлю пошаговое руководство по выбору и созданию парсера с использованием конкретных языков и библиотек.
Долгосрочная масштабируемость и поддерживаемость:
В целом можно сказать, что парсеры не надежны для долгосрочного использования. Парсеры функционируют на основе внешних правил, определенных для конкретного веб-сайта или веб-сервера, поэтому если правила изменятся, функция перестанет работать должным образом. Любые изменения, начиная от простых имен селекторов HTML, запросов к URL API, требований к телу HTTP могут привести к сбою функции.
Кроме того, существуют различные проблемы, связанные с самими парсерами:
- Активация DDOS-атаки: Если парсер делает слишком много запросов к серверу слишком быстро, IP-адрес может быть заблокирован или ограничен по скорости
- Потребление ресурсов производительности: Некоторые методы извлечения данных с помощью парсеров потребляют большое количество аппаратных ресурсов. Без умеренности система, основанная на данных парсера в реальном времени, может легко замедлиться
- Требования к заголовку Origin: Некоторые серверы могут добавлять HTTP-заголовки, требующие определенного источника для доступа к запросу.
Некоторые способы решения этих проблем:
- Хранение и кэширование информации: Извлеченная информация должна храниться в базе данных для обеспечения долгосрочной надежности. Информацию можно затем обновлять.
- Вокруг парсера и/или базы данных, содержащей извлеченные данные, можно создать внутренний API.
- Очередь задач для базового обхода: Очередь задач может использоваться для обеспечения наиболее эффективного извлечения информации
- Тестирование баланса нагрузки: Определение масштаба и скорости, с которыми данные могут быть устойчиво извлечены
- Прокси и VPN: Дополнительная интеграция VPN и прокси может преодолеть ограничения по скорости и IP
Оставайтесь на связи для следующих частей этой серии в будущем...
Интересуетесь узнать больше о том, чем я занимаюсь? Посмотрите некоторые из моих проектов на github или свяжитесь со мной в linkedin.