Архитектура решения: Проектирование хорошо оптимизированного решения для веб-парсинга

Составные части веб-парсинга

Существует несколько основных компонентов, которые необходимо иметь в каждом проекте по веб-парсингу, если вы хотите надежно извлекать высококачественные данные из Интернета в больших масштабах:

• Услуги парсинга сайтов
• Хостинг парсинга
• Управление прокси-серверами
• Мониторинг и контроль качества данных
• Обслуживание парсинга

Однако в зависимости от требований проекта может потребоваться использование и других технологий для получения необходимых данных:

• Безголовый браузер
• Интеллектуальные парсеры
• Постобработка данных

Объем ресурсов, необходимых для разработки и сопровождения проекта, будет определяться типом и частотой использования необходимых данных, а также сложностью проекта.

Проектирование веб-парсинга

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

Мониторинг продуктов

В первом примере мы рассмотрим один из наиболее распространенных вариантов использования веб-парсинга - мониторинг продукции. Здесь мы рассмотрим один из типичных примеров:

Требования к проекту: Заказчик хотел извлекать продукты с определенных страниц товаров на сайте Amazon.com. Заказчик должен был предоставить пакет поисковых запросов, а парсеры должны были найти эти ключевые слова и извлечь все продукты, связанные с ними (~500 ключевых слов в день).

• URL-адрес продукта
• Название продукта
• Производитель/издатель
• Категория
• URL-адреса изображений
• Описание
• Описание продукта
• Информация о продукте
• ASIN
• Рейтинг
• До 20 однозвездочных рецензий
• До 20 пятизвездочных отзывов
• Канонический URL
• Заголовок
• Изображение статьи (верхнее изображение)
• Текст
• Медиа-адреса
• Авторы
• Дата публикации
• Резюме

Полученные данные будут использованы в инструменте анализа продукции, предназначенном для потребительских брендов, которые хотят отслеживать свою продукцию и продукцию своих конкурентов.

Юридическая оценка: Как правило, извлечение данных о товарах не вызывает особых юридических проблем при условии, что парсеру (1) не приходится выполнять поиск за логином (что часто бывает не так), (2) выполняется только поиск фактической информации или информации, не защищенной авторским правом, и (3) клиент не хочет воссоздавать весь магазин целевого сайта, что может поставить под вопрос права на базу данных. В данном случае проект практически не имел юридических проблем.

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

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

Результат: В настоящее время разработанные парсеры ежедневно извлекают с сайта ~500 000 товаров, которые клиент вводит непосредственно в свое приложение для мониторинга товаров.

Мониторинг СМИ

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

Требования к проекту: Заказчик хотел разработать приложение-агрегатор новостей, которое будет собирать новостной контент для конкретных отраслей и интересов. Заказчик предоставил первоначальный список из 300 новостных сайтов, которые он хотел просмотреть, однако по мере роста компании это число могло увеличиться. Заказчику требовалось извлечь каждую статью в определенных категориях со всех целевых сайтов, перебирая их каждые 15 минут или каждый час в зависимости от времени суток. Клиенту требовалось извлечь из каждой статьи следующие данные:

• Канонический URL
• Заголовок
• Изображение статьи (верхнее изображение)
• Текст
• Медиа-адреса
• Авторы
• Дата публикации
• Резюме

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

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

Как правило, разработка надежного и масштабируемого парсера для одного сайта занимает у опытного парсера 1-2 дня. Приблизительный расчет быстро покажет, что разработка 300+ парсеров вручную будет очень дорогостоящим проектом, если на каждый парсер потребуется 1 рабочий день.

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

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

В рамках данного проекта потребовалась и профессиональная разработка ПО для обеспечения масштабируемости системы.

Результат: успешно реализован этот проект для клиента, который теперь может извлекать 100-200 тыс. статей в день с целевых сайтов для приложения по агрегации новостей.

Заключение 

Вот так выглядит четырехэтапный процесс для разработки решений для проектов веб-парсинга.