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

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

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

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

Процесс сбора требований

Процесс сбора требований можно разделить на две части: 1) понимание потребностей бизнеса и 2) определение технических требований для удовлетворения этих потребностей.

Потребность бизнеса

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

• Хотите ли вы оптимизировать свою ценовую стратегию путем мониторинга цен конкурентов?
• Хотите ли вы отслеживать настроения в Интернете по отношению к конкретным компаниям?
• Хотите ли вы развивать свой бизнес, генерируя новые лиды для отдела продаж?
• И т.д.

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

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

Необходимо задать себе следующие вопросы:

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

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

Технические требования

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

В каждом проекте парсинга веб-данных есть четыре ключевые части:

1. Обнаружение данных
2. Извлечение данных
3. Масштаб извлечения
4. Вывод данных

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

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

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

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

Необходимо задать себе следующие вопросы:

• Знаете ли вы, какие сайты содержат подходящие данные для извлечения?
• Как парсер будет перемещаться к данным? Т.е. как парсер будет находить данные на сайте.
• Нужно ли входить в систему, чтобы получить доступ к нужным данным?
• Нужно ли вводить какие-либо данные для фильтрации данных на сайте перед извлечением?
• Нужно ли заходить на сайт из определенного места, чтобы увидеть нужные данные?

Задав себе эти вопросы, вы сможете реально определить рамки проекта.

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

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

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

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

Следует задать себе следующие вопросы:

• Какие поля данных я хочу извлечь?
• Нужно ли извлекать какие-либо изображения на странице?
• Нужно ли загружать какие-либо файлы (PDF, CSV и т.д.)?
• Нужно ли делать скриншот страницы?
• Нужно ли переформатировать данные в другой формат (например, убрать знаки валют из цен на товары)?
• Все ли необходимые данные доступны на одной веб-странице?

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

После завершения этого этапа можно оценить масштаб проекта...

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

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

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

При оценке масштабов проектов по парсингу веб-данных необходимо учитывать три основные переменные:

1. Количество сайтов
2. Количество записей, извлекаемых с каждого сайта
3. Частота выполнения операций по извлечению данных.

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

Количество извлекаемых записей

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

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

Частота извлечения данных

Последний фактор, который необходимо принять во внимание, - как часто вы хотите извлекать эти данные? Ежедневно, еженедельно, ежемесячно, однократно и т.д.?

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

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

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

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

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

Дельты и инкрементные просмотры

Еще один фактор, который необходимо учитывать при переходе от разового извлечения данных к регулярному проекту, - это то, как Вы собираетесь обрабатывать инкрементные запросы?

Здесь у вас есть несколько вариантов:

• Извлекать все имеющиеся данные при каждом посе