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

Автор: Роман Чернышов    Опубликовано: 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. Автоматически данную проблему не решить. Необходимость привлечения оператора — средняя.

Заключение

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

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

PHP, Бизнес, Система     автоматизация парсинга, парсинг, сложности при парсинге