#web-scraping #web-crawler #workflow #raw-data
#очистка веб-страниц #веб-сканер #рабочий процесс #необработанные данные
Вопрос:
В прошлом я реализовал несколько проектов очистки веб-страниц — от малого до среднего размера (около 100 000 очищенных страниц). Обычно моей отправной точкой является индексная страница, которая ссылается на несколько страниц с деталями, которые я хочу очистить. В итоге большую часть времени мои проекты работали. Но я всегда чувствую, что мог бы улучшить рабочий процесс (особенно в отношении проблемы сокращения трафика, который я вызываю на очищенных веб-сайтах [и связан с этой темой: риск быть забаненным: D]).
Вот почему мне было интересно узнать о ваших (наилучших практических) подходах к дизайну веб-скребка (для проектов малого и среднего размера).
Обычно я создаю свои проекты очистки веб-страниц таким образом:
- Я определяю отправную точку, которая содержит URL-адреса, из которых я хочу получить данные. Начальная точка имеет довольно предсказуемую структуру, которая упрощает очистку
- Я бросаю взгляд на конечные точки, которые я хочу очистить, и выясняю некоторые функции для очистки и обработки данных
- Я собираю все URL-адреса (конечные точки) Я хочу очистить от своей начальной точки и сохранить их в списке (иногда отправной точкой являются несколько страниц… например, если отображаются результаты поиска, а на одной странице отображается только 20 результатов … но структура этих страниц почти идентична)
- Я начинаю сканирование url_list и очищаю интересующие меня данные.
- Чтобы очистить данные, я запускаю некоторые функции для структурирования и сохранения данных в нужном мне формате
- После того, как я успешно очистил данные, я помечаю URL-адрес как «очищенный» (если я столкнусь с ошибками, тайм-аутами или чем-то подобным, мне не нужно начинать с начала, но можно продолжить с того места, где процесс остановился)
- Я объединяю все данные, которые мне нужны, и завершаю проект
Теперь мне интересно, было бы неплохо изменить этот рабочий процесс и прекратить извлечение / обработку данных во время обхода. Вместо этого я бы собрал необработанные данные / веб-сайт, пометил URL как просмотренный и продолжил сканирование. Когда все веб-сайты загружены (или — если это более крупный проект — между большими задачами) Я бы запустил функции для обработки и хранения необработанных данных.
Преимущества этого подхода будут:
- если я столкнусь с ошибками, основанными на неожиданной структуре, мне не придется заново очищать все страницы раньше. Мне нужно было бы только изменить свой код и запустить его на сохраненных необработанных данных (что минимизировало бы трафик, который я вызываю)
- поскольку веб-сайты продолжают меняться, у меня был бы пул воспроизводимых данных
Минусы были бы:
- особенно, если проекты растут в размерах, этот подход может потребовать слишком много места
Ответ №1:
Трудно сказать, не зная вашей цели, но я думаю, что это хорошая идея для отладки.
Например, если единственной целью вашего скребка является запись цены на какой-либо продукт, но ваш скребок внезапно не может получить эти данные, тогда да — было бы разумно отключить скребок.
Но, допустим, целью является не только цена, но и различные атрибуты на странице, и скребок просто не может уловить один атрибут из-за чего-то вроде изменения веб-сайта. Если бы это было так, и очистка других атрибутов данных все еще имела значение, я бы продолжил очистку, но зарегистрировал ошибку. Другим соображением может быть частота отказов. Очистка веб-страниц очень сложна — иногда веб-страницы загружаются по-разному или неполно, а иногда веб-сайты меняются. Является ли скребок неисправным на 100%? Или, может быть, это просто сбой в 5% случаев?
Сохранение дампа html при ошибке, безусловно, поможет отладить проблемы, такие как сбой xpath и тому подобное. Вы могли бы минимизировать объем занимаемого пространства за счет более тщательной обработки ошибок. Например, сохраните файл, содержащий дамп html, если он еще не существует, Для этой конкретной ошибки, например, xpath не возвращает значение или несоответствие типов и т. Д.
Re: получение запрета. Я бы рекомендовал использовать фреймворк очистки. Например, в python есть Scrapy, который обрабатывает поток запросов. Кроме того, существуют прокси-сервисы, позволяющие избежать запрета. По крайней мере, в США очистка веб-страниц явно считается законной. Все компании учитывают трафик очистки веб-страниц. Вы не собираетесь прерывать работу службы с помощью 100 тыс. Подумайте о миллионах операций очистки в день, которые Walmart делает на Amazon, и наоборот.
Комментарии:
1. спасибо за ваши идеи… особенно интересно звучит часть обработки ошибок. До сих пор часть обработки ошибок была ограничена целыми страницами, но не элементами на веб-страницах 🙂