Предположим, перед нами стоит такая задача: собирать информацию о рекламных объявлениях с различных сайтов в разных категориях. В дальнейшем эта информация будет использоваться для мониторинга и анализа рынка, оповещения о каких-то событиях на этом рынке. Похоже на создание мини- поисковой системы.
По сути дела, имеем 4 подсистемы:
1. Сервис запуска плагинов, собирающих и извлекающих информацию
2. Временное хранилище данных
3. Индекс данных
4. Приложения для работы с извлеченными данными, например, генератор отчетов
Рассмотрим последовательно каждую систему.
Представляет собой сервис, который по имеющемуся расписанию запускает из своей библиотеки плагины. В случае ошибки выполнения отдельного плагина, сервис производит определенные действия (запись в журнал, оповещение разработчика по e-mail, рестарт, отключение плагина и т.д.)
Вспомогательная система, обеспечивает хранение и доступ к скачиваемым из интернета страницам. Мы не можем использовать в явном виде базу данных SQL: данные загружаются из интернета сплошными потоками, их очень много и они появляются очень быстро, к тому же, к ним постоянно осуществляется доступ (чтение, изменение, удаление), также в несколько потоков и с высокой периодичностью. Была попытка использования NoSQL-баз данных, но они также не выдерживали нагрузки. В результате было сделано гибридное хранилище: информация о записях хранится в SQL-базе, а само HTML-содержимое в больших файлах. Периодически специальный плагин «вырезает» из этих файлов удаленные страницы.
Для быстрого доступа к данным необходим индекс. Предположим, мы собираемся просматривать количество объявлений в той или иной категории за выбранную дату. Делать подобную выборку из базы и временного хранилища каждый раз — очень дорого для ресурсов сервера. К тому же, какие-то данные будут избыточными. Поэтому строится индекс, куда заносится только ID объявлений и их категории для каждого дня.
Тут все понятно. Это приложения, с которыми работает конечный пользователь. Собранные данные, благодаря построенным индексам, можно теперь быстро и удобно просматривать. Это может быть веб-приложение, где пользователь выбирает шаблоны отчетов и критерии выборки и получает данные в виде таблиц или графиков. Может быть, это будут ежедневные письма менеджерам, отражающие категории объявлений, в которых наблюдается повышенная активность.
Представим получение данных в виде конвейера.
1. Набор веб-спайдеров, скачивающих с сайтов-источников страницы с результатами поиска. Это те страницы, до которых обычно не добирается поисковый бот (за исключением SEO-страниц, но количество объявлений в них скорее всего будет не полным и содержит лишь наиболее популярные категории). Для каждого сайта придется написать свой плагин со своей логикой запросов. Иногда это GET-запрос с параметрами в querystring, иногда придется слать POST или даже слать параметры через cookies. Для написания такого плагина поможет любой HTTP-анализатор, встроенный в браузер. Задача плагина, скачивающего результаты поиска — охватить все категории объявлений на сайте, посетить все его страницы и сохранить содержимое во временное хранилище. Во избежание зацикливаний при перемещении по пейджингу (paging — перемещение по страницам результата), рекомендуется сравнивать содержимое страницы с предыдущей.
2. Следующий этап конвейера — плагин, извлекающий с загруженных страниц ссылки на страницы с детальным описанием объявления (товара, услуги, в зависимости от специализации сайта). Тут можно попытаться анализировать все ссылки и выделять из них нужные или пойти простым путем и вводить для каждого сайта свое описание такой ссылки. Наиболее простой путь — это использовать свое XPath-выражение для извлечение ссылок с каждого сайта. Плагин извлекает ссылки, сохраняет их в базу и помечает страницы с результатами, как обработанные. Дополнительно плагин может проверить не является ли страница сообщением об ошибке или о том, что результате поиска не найдено результатов.
На случай, если у вас возник вопрос для чего нужно хранить страницы с результатами поиска, расскажу для чего это нужно. Бывают очень большие сайты, скачивание которых занимает длительное время, а плагины часто в результате ошибки вынуждены рестартовать. Ошибки будут, они могут быть связаны с работой сайта, производительностью вашего сервера, сетевые ошибки. В этом случае логично продолжить скачивание с того места, на котором плагин прервался. В случае, если что-то на сайте поменялось и ссылки на страницы с деталями не удается извлечь, достаточно будет только поменять XPath или алгоритм извлечения и перезапустить плагин. Он быстро обработает все хранящиеся страницы без повторного скачивания.
3. Далее идет снова «универсальный» плагин. Он получает список ссылок на страницы с деталями и скачивает их, сохраняя страницы во временном хранилище. Вообще все страницы (с результатами поиска и с деталями) имеют период устаревания, после которого они считаются недействительными и будут удалены. И обработка их производится от старых — к более новым. После обработки они маркируются как обработанные. Ссылки для скачивания, в случае неудачи, помечаются временем попытки скачивания, чтобы можно было попробовать повторную попытку позже. Причиной ошибки может быть временная недоступность сервера или прокси. Для скачивания с отдельных сайтов могут понадобиться прокси. Ну и не следует забывать о нагрузке на сервер сайта-источника данных, необходимо слать запросы не чаще 1 раза в секунду.
4. Имея страницы с деталями объявления, осталось только извлечь необходимую информацию из HTML. Для этого снова придется написать для каждого сайта свой плагин или придумать более интеллектуальный универсальный. В простейшем случае снова можно задействовать XPath для каждого поля документа. Для парсинга HTML подходит такая библиотека как HtmlAgilityPack. Извлеченную информацию нужно поместить в какой-то универсальный формат (например XML) и передать дальше по конвейеру.
5. Из набора xml-файлов со всеми данными можно распорядится ими в соответствии с поставленными задачами, например построить соответствующий индекс, который уже будут использовать конкретные приложения.
Я очень коротко ознакомил вас с реально-действующей системой, которая используется для разных вертикалей сайтов. На самом деле при создании этой системы, которая развивается уже 4 года, появлялось множество подводных камней. Если данная тема будет встречена уважаемым сообществом с интересом, то напишу на эту тему еще что-нибудь более подробно.
По сути дела, имеем 4 подсистемы:
1. Сервис запуска плагинов, собирающих и извлекающих информацию
2. Временное хранилище данных
3. Индекс данных
4. Приложения для работы с извлеченными данными, например, генератор отчетов
Рассмотрим последовательно каждую систему.
Краткий обзор подсистем
1. Сервис запуска плагинов
Представляет собой сервис, который по имеющемуся расписанию запускает из своей библиотеки плагины. В случае ошибки выполнения отдельного плагина, сервис производит определенные действия (запись в журнал, оповещение разработчика по e-mail, рестарт, отключение плагина и т.д.)
2. Временное хранилище данных
Вспомогательная система, обеспечивает хранение и доступ к скачиваемым из интернета страницам. Мы не можем использовать в явном виде базу данных SQL: данные загружаются из интернета сплошными потоками, их очень много и они появляются очень быстро, к тому же, к ним постоянно осуществляется доступ (чтение, изменение, удаление), также в несколько потоков и с высокой периодичностью. Была попытка использования NoSQL-баз данных, но они также не выдерживали нагрузки. В результате было сделано гибридное хранилище: информация о записях хранится в SQL-базе, а само HTML-содержимое в больших файлах. Периодически специальный плагин «вырезает» из этих файлов удаленные страницы.
3. Индекс данных
Для быстрого доступа к данным необходим индекс. Предположим, мы собираемся просматривать количество объявлений в той или иной категории за выбранную дату. Делать подобную выборку из базы и временного хранилища каждый раз — очень дорого для ресурсов сервера. К тому же, какие-то данные будут избыточными. Поэтому строится индекс, куда заносится только ID объявлений и их категории для каждого дня.
4. Приложения для работы с извлеченными данными
Тут все понятно. Это приложения, с которыми работает конечный пользователь. Собранные данные, благодаря построенным индексам, можно теперь быстро и удобно просматривать. Это может быть веб-приложение, где пользователь выбирает шаблоны отчетов и критерии выборки и получает данные в виде таблиц или графиков. Может быть, это будут ежедневные письма менеджерам, отражающие категории объявлений, в которых наблюдается повышенная активность.
Конвейер производства данных
Представим получение данных в виде конвейера.
1. Набор веб-спайдеров, скачивающих с сайтов-источников страницы с результатами поиска. Это те страницы, до которых обычно не добирается поисковый бот (за исключением SEO-страниц, но количество объявлений в них скорее всего будет не полным и содержит лишь наиболее популярные категории). Для каждого сайта придется написать свой плагин со своей логикой запросов. Иногда это GET-запрос с параметрами в querystring, иногда придется слать POST или даже слать параметры через cookies. Для написания такого плагина поможет любой HTTP-анализатор, встроенный в браузер. Задача плагина, скачивающего результаты поиска — охватить все категории объявлений на сайте, посетить все его страницы и сохранить содержимое во временное хранилище. Во избежание зацикливаний при перемещении по пейджингу (paging — перемещение по страницам результата), рекомендуется сравнивать содержимое страницы с предыдущей.
2. Следующий этап конвейера — плагин, извлекающий с загруженных страниц ссылки на страницы с детальным описанием объявления (товара, услуги, в зависимости от специализации сайта). Тут можно попытаться анализировать все ссылки и выделять из них нужные или пойти простым путем и вводить для каждого сайта свое описание такой ссылки. Наиболее простой путь — это использовать свое XPath-выражение для извлечение ссылок с каждого сайта. Плагин извлекает ссылки, сохраняет их в базу и помечает страницы с результатами, как обработанные. Дополнительно плагин может проверить не является ли страница сообщением об ошибке или о том, что результате поиска не найдено результатов.
На случай, если у вас возник вопрос для чего нужно хранить страницы с результатами поиска, расскажу для чего это нужно. Бывают очень большие сайты, скачивание которых занимает длительное время, а плагины часто в результате ошибки вынуждены рестартовать. Ошибки будут, они могут быть связаны с работой сайта, производительностью вашего сервера, сетевые ошибки. В этом случае логично продолжить скачивание с того места, на котором плагин прервался. В случае, если что-то на сайте поменялось и ссылки на страницы с деталями не удается извлечь, достаточно будет только поменять XPath или алгоритм извлечения и перезапустить плагин. Он быстро обработает все хранящиеся страницы без повторного скачивания.
3. Далее идет снова «универсальный» плагин. Он получает список ссылок на страницы с деталями и скачивает их, сохраняя страницы во временном хранилище. Вообще все страницы (с результатами поиска и с деталями) имеют период устаревания, после которого они считаются недействительными и будут удалены. И обработка их производится от старых — к более новым. После обработки они маркируются как обработанные. Ссылки для скачивания, в случае неудачи, помечаются временем попытки скачивания, чтобы можно было попробовать повторную попытку позже. Причиной ошибки может быть временная недоступность сервера или прокси. Для скачивания с отдельных сайтов могут понадобиться прокси. Ну и не следует забывать о нагрузке на сервер сайта-источника данных, необходимо слать запросы не чаще 1 раза в секунду.
4. Имея страницы с деталями объявления, осталось только извлечь необходимую информацию из HTML. Для этого снова придется написать для каждого сайта свой плагин или придумать более интеллектуальный универсальный. В простейшем случае снова можно задействовать XPath для каждого поля документа. Для парсинга HTML подходит такая библиотека как HtmlAgilityPack. Извлеченную информацию нужно поместить в какой-то универсальный формат (например XML) и передать дальше по конвейеру.
5. Из набора xml-файлов со всеми данными можно распорядится ими в соответствии с поставленными задачами, например построить соответствующий индекс, который уже будут использовать конкретные приложения.
Заключение
Я очень коротко ознакомил вас с реально-действующей системой, которая используется для разных вертикалей сайтов. На самом деле при создании этой системы, которая развивается уже 4 года, появлялось множество подводных камней. Если данная тема будет встречена уважаемым сообществом с интересом, то напишу на эту тему еще что-нибудь более подробно.
