Почему парсинг сайта не всегда может быть полностью автоматическим

Author Автор: Роман Чернышов    Опубликовано: 9 апреля 2021

парсинг не полностью автоматическийДоброго времени друзья! Работая с проектами которые включают в себя парсинг(сбор, анализ) данных со сторонних источников, я очень часто встречаюсь с задачей которая звучит как: Реализовать полную автоматизацию процесса парсинга, без последующего вмешательства разработчика(оператора). Иными словами, один раз сделать и забыть, чтобы система работала автономно и не требовала внимания(времени, сил и денег). Задача звучит разумно, оно и понятно, что автоматизация и стабильность это залог успеха проекта, особенно если речь о бизнес процессах, которые влияют в том числе и на прибыль компании. Но, к сожалению это не всегда возможно, зачастую парсинг требует периодического подключение оператора(квалифицированного специалиста) на протяжении всей его работы. Поэтому перед разработкой парсера, необходимо оценивать не только стоимость его разработки, но и стоимость его дальнейшего обслуживания(сопровождения). Далее я расскажу почему и какие проблемы возникают в процессе парсинга, как их может устранит оператор, и чего это стоит.

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

Немного терминологии

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

Клиент — Приемник данных, принимающая сторона, то куда данные поступают от парсера. Например это может быть сайт, в базу данных которого поступают новости(статьи, изображения) из других источников.

Донор — Источник данных. То откуда парсер получает данные, путем сканирования всех его материалов, доступных для публичного просмотра. Например сайт интернет-магазин содержащий каталог товаров, новостной портал, различные справочники и т.д.

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

Какие проблемы возникают в процессе парсинга и как их решить?

Также, далее по каждому пункту, я дам оценку сложности(и критичности) проблемы по десятибалльной шкале и оценю необходимость привлечения оператора(разработчика) для решения возникшей проблемы. Буду оценивать как: низкая — можно решить самим, средняя — можно решить самим или парсер сможет продолжить работу но в ограниченном режиме, высокая — самим проблему не решить, парсер продолжить работу не сможет. Далее перейдем к рассмотрению самих проблем:

Блокировка парсера по IP/Mac/UsegAgent/Прочее на стороне донора

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

Решение: Использовать Proxy, Socks, с периодической сменой IP адресов, смена UserAgent, сокрытие MAC адреса. Сложность реализации — 3/10. Можно сделать автоматическое решение(но это усложнит парсер). Необходимость привлечения оператора — низкая.

Изменение формата данных

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

Решение: Перенастройка парсера на работу с новым форматом данных, может потребоваться создания новых масок Regxp, или новых фильтров обработки и проверки корректности данных, с учетом появившегося нового формата данных. Сложность реализации — 5/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Изменение структуры источника(донора)

Аналогично предыдущему пункту, но в данном случае меняются не данных, не их формат, а вообще вся структура донора(адреса страниц, степень вложенности категорий, размещение данных на странице, изменение HTMLкода страниц и т.д.), что более серьезно для парсера как правило приводит к его остановке.

Решение: Перенастройка парсера на работу с новой структурой донора, может потребоваться изменение логики работы парсера, структуры базы данных, может включать изменение формата данных. Сложность реализации — 7/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — высокая.

Выявление нового типа данных, который парсер не обучен обрабатывать

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

Решение: Добавление нового типа данных в алгоритм работы парсера или игнорирование нового типа данных. Сложность реализации — 2/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — низкая.

Некорректность данных, ошибки в данных или структуре

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

Решение: Добавление типа данных в алгоритм работы парсера с учетом найденных ошибок в данных или структуре. Сложность реализации — 7/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — высокая.

Ошибки в самом парсере

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

Решение: Постоянный мониторинг работы парсера, тестирование его работы в «боевом» режиме, внесение исправлений, доработок. Сложность реализации — 5/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Изменения производимые на стороне клиента

Бывает и такое, что сам клиент, который принимает данные от парсера, вносит какие-то изменения, либо в формат данных и их структуру, либо в способ хранения данных и т.д. Что может приводит также к остановке парсера.

Решение: Согласовывать список изменений с разработчиком парсера, в случае если изменения затрагивают область работы парсера, преждевременно оценивать возможность внесения доработок. Сложность реализации — 5/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Ошибки на стороне клиента

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

Решение: Постоянный мониторинг работы парсера, а также сервера и базы данных куда поступают полученные от него данные, проверка корректности работы с ними, своевременная корректировка, настройка, устранение возникающих ошибок. Сложность реализации — 3/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — низкая.

Конфликты с данными из других источников, а также с другими парсерами

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

Решение: Постоянный мониторинг работы парсера, базы данных, а также согласование работы парсера с другими парсерами, при изменении алгоритма работы одного с внесением изменений в общую базу данных, учитывать алгоритм другого. Сложность реализации — 4/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Прочие техничсекие сложности

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

Решение: Постоянный мониторинг работы парсера, устранение возникающих проблем. Сложность реализации — 6/10. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Заключение

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

Также если вам необходима услуга парсинга, вы можете всегда обращаться ко мне, буду рад поработать с вами!

Оставить комментарий

Автор блога
Чернышов Роман
Роман Чернышов
Веб-разработчик,
Full Stack
Senior, Architector
PHP, JavaScript, Node.JS, Python, HTML 5, CSS 3, MySQL, Bash, Linux Admin
Заказать работу
предложить оффер

Последние вопросы
Список вопросов
Последние комментарии
Меню

Archive

Мои проекты
Insurance CMS Love Crm CMS Совместные покупки Мой PHP Framework Хостинг для моих клиентов Лицензии на мой софт и поддержка