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

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

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

Процесс технического анализа

Процесс технического анализа сосредоточен на четырех ключевых составляющих процесса разработки веб-парсинга:<\/p>\r\n\r\n

\r\n\t
• Обнаружение данных<\/li>\r\n\t
• Извлечение данных<\/li>\r\n\t
• Масштаб извлечения<\/li>\r\n\t
• Вывод данных<\/li>\r\n<\/ul>\r\n\r\n

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

  \r\n\r\n

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

  \r\n\r\n

  Шаг 1: обнаружение данных

  \r\n\r\n

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

  \r\n\r\n

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

  \r\n\r\n

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

  \r\n\r\n
  \r\n\t
  • вы не знаете, на каких сайтах содержатся нужные вам данные; или<\/li>\r\n\t
  • вы не можете отфильтровать данные на целевых сайтах, чтобы извлечь только нужные данные.<\/li>\r\n<\/ul>\r\n\r\n

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

    \r\n\r\n

    В таких случаях мы можем изучить возможность получения необходимых данных, используя ряд имеющихся в нашем распоряжении подходов:

    \r\n\r\n
    \r\n\t
    • Агрегаторы данных - благодаря нашему богатому опыту извлечения данных из Интернета мы иногда можем совместно с клиентом определить существующие сайты, которые агрегируют данные из Интернета и которые, если их соскобить, могут удовлетворить его потребности в данных. Это идеальное решение, если клиент знает, какие данные он хочет извлечь, но не имеет четкого представления о том, какие сайты содержат требуемые данные.
    \r\n\t
    • Широкий поиск <\/strong>- в некоторых случаях Zyte может сконфигурировать поиск в определенном регионе Интернета (например, в домене страны) для поиска нужных клиенту данных. Такое решение может быть полезным для определенных типов данных (корпоративных или персональных), однако, поскольку в этом случае используется универсальный краулер для извлечения данных, точность извлечения данных будет гораздо ниже, чем при использовании краулеров, разработанных на заказ. Мы часто рекомендуем это решение только в том случае, если требования к качеству данных невысоки.
    \r\n\t
    • Искусственный интеллект <\/strong>- если у клиента есть список из 100 с лишним сайтов, с которых он хотел бы получить данные, но у него нет бюджета на разработку собственных пауков для каждого из них, мы часто рекомендуем ему рассмотреть возможность использования технологии извлечения данных с помощью искусственного интеллекта, например Zyte Automatic Extraction API. Это решение позволяет извлекать данные с известных сайтов без необходимости разработки собственного кода для каждого сайта, что значительно снижает стоимость проекта. В настоящее время Zyte Automatic Extraction API доступен только для извлечения данных о товарах и статьях, однако в ближайшие месяцы планируется добавить покрытие для других типов данных.
    \r\n<\/ul>\r\n\r\n

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

    \r\n\r\n

    <\/p>\r\n\r\n

    Шаг 2: извлечение данных

    \r\n\r\n

    Следующим шагом является проверка технической осуществимости этапа извлечения данных.

    \r\n\r\n

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

    \r\n\r\n
    \r\n\t
    • JavaScript\/AJAX - поскольку современные веб-сайты все чаще используют JavaScript и AJAX для динамического отображения данных на веб-страницах, может возникнуть необходимость использования безголового браузера для отображения этих данных для краулеров или разработки пользовательского кода для выполнения частей JavaScript без использования безголового браузера. Архитектор решения выполнит серию тестов, чтобы определить, отображаются ли целевые данные с помощью JavaScript или AJAX.
    \r\n\t
    • Количество шагов, необходимых для извлечения данных <\/strong>- в некоторых случаях все целевые данные не доступны на одной странице, а для их получения краулеру требуется выполнить несколько запросов. В таких случаях архитектор решения определяет количество запросов, которое необходимо выполнить, что определяет объем инфраструктуры, необходимой для реализации проекта.
    \r\n\t
    • Сложность итерации по записям <\/strong>- некоторые сайты имеют более сложную пагинацию (бесконечная прокрутка страниц и т.д.) или структуру форматирования, что может потребовать использования безголового браузера или сложной логики переползания. Архитектор решения определит тип пагинации и логику переползания, необходимые для доступа ко всем имеющимся записям.
    \r\n\t
    • Валидация данных <\/strong>- ключевым компонентом любого проекта веб-парсинга является поддержание высокого качества и охвата данных. Поэтому еще до начала проекта наш архитектор оценит сложность обеспечения высокого качества и охвата данных по мере масштабирования проекта.
    \r\n\t
    • Сложность обслуживания<\/strong> - архитектор решения не только оценивает сложность извлечения целевых данных для текущего веб-сайта, но и изучает историю сайта и тенденции в данной отрасли, чтобы определить вероятность внесения изменений в сайт, которые нарушат работу краулеров.
    \r\n<\/ul>\r\n\r\n

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

    \r\n\r\n

    Шаг 3: масштаб извлечения

    \r\n\r\n

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

    \r\n\r\n

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

    \r\n\r\n
    \r\n\t
    • Тестовые пропарсивания <\/a>- наш архитектор решения обычно проводит серию тестовых пропарсиваний, чтобы выяснить, нет ли узких мест в отношении максимальной скорости парсинга. Это часто бывает актуально для небольших сайтов или когда проект требует сжатых сроков для завершения извлечения данных, но есть риск перегрузить серверы сайта.
    \r\n\t
    • Антибот-контрмеры -<\/strong> наш архитектор решения прогонит целевые сайты через наши внутренние аналитические инструменты, чтобы выявить наличие антибот-контрмер, captchas или CDN, которые повысят сложность проекта и ограничат возможность извлечения данных в требуемом масштабе или с требуемой частотой. Наличие этих технологий может повысить риски запретов или проблем с надежностью.
    \r\n<\/ul>\r\n\r\n

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

    \r\n\r\n

    Шаг 4: Доставка данных

    \r\n\r\n

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

    \r\n\r\n

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

    \r\n\r\n

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

    \r\n\r\n

    Итак, вот они, четыре шага к проведению анализа технической осуществимости проекта веб-парсинга. <\/p>\r\n