Архитектура краулера вертикального поиска Долинин Михаил Rambler 2010
Поисковая система: обзор WEB Crawler Краулер - компонент поисковой системы, ответственный за сбор и первичную обработку данных, из которых формируются индексы поисковой машины. Index Builder Search Engine Indexes | Найти
Вертикальный поиск • Интерес представляют лишь сайты определённой тематики. • Лишь часть страниц этих сайтов содержит интересующие данные. • Объект обработки системы не HTML-данные, а документы с предопределённым набором свойств. • Свойства необходимо самостоятельно извлекать из HTML-страниц. • Все необходимые исходные параметры хранятся в наборе конфигурационных файлов. HTML. . . <h 1>Avatar</h 1> <b>2010</b> <p class=‘director’> Cameron</p>. . . Document TITLE: Avatar YEAR: 2010 DIRECTOR: Cameron
Особенностикраулера Компоненты задачи при больших объёмах • Минимизация входящего трафика – желательно качать как можно меньше и как можно реже • Минимизация объема выдачи – нужно выдавать лишь ту информацию, которая приводит к изменениям в индексах • Масштабируемость процесса – Разделение процесса на подзадачи – Связность модулей должна быть минимальна. – Изменения системы для обработки новых сайтов, новых типов данных должны быть локализованы и минимальны – Алгоритмы должны позволять распараллеливание по данным.
Fetcher: получение данных из Web • Качать только то, что необходимо для построения индексов • Не DDOSить сайты – Качать в один поток – Делать паузы между запросами – Не превышать лимит запросов в единицу времени • «Слушаться» robots. txt WEB GET 200 - OK URL Fetcher Cookies Robots. txt etc URL Unparsed Content (HTML) Last-Modified
Scheduler: расписание запросов • Качать можно одновременно с нескольких сайтов. • Расписание запросов – циклическая очередь с приоритетами • На входе – очередь заданий, на выходе – очередь результатов WEB Fetcher 1 … Fetcher N url 1 content 1 url 2 content 2 url 3 content 3 url 3 Scheduler Site Configs Parser
Parser - извлечение свойств документа Parser: обработка скачанного контента • Извлечение интересующих параметров и выдача их на вход построителю индексов. – В случае, если документ скачан повторно, необходимо определить, следует ли его передавать в построитель индексов. Parser URL Unparsed Content (HTML) URL Set of Reg. Exps Param 1: Value 1 … Param. N: Value. N Check. Sum Site Config Index Builder
Parser: извлечение ссылок • Извлечение из полученного HTML ссылок на другие страницы – – Интересны лишь некоторые ссылки – какие именно, задаются конфигами Полученные ссылки сортируются и сохраняются в списке вместе с адресом самого документа Parser Sorted url list URL Unparsed Content (HTML) url 1 Set of Reg. Exps url 2 … URL … url M Site Config
Формат списка • Каждый элемент списка содержит следующую информацию: – – URL Checksum (CRC 32 от извлеченных параметров) Время последнего скачивания Промежуток времени до следующего скачивания Сhecksum Fetch Time Для новых урлов, только что извлечённых из HTML: Checksum = 0 Fetch Time = 0 Refetch Delay = default из конфига Refetch Delay … Cписок может содержать также произвольные дополнительные данные, зависящие от специфики контента (Last-Modified, etc)
Очередь списков • Все сформированные списки заносятся в очередь – • Элементом очереди является не сам список, а имя файла, в котором он хранится Извлекает списки из очереди следующий модуль – Url Merger Url lists queue Documents queue url 1 content 1 url 2 content 2 url 3 List 1 List 2 Parser List 3 content 3 List 2 List 1 url 1 … … List 3 … url M url N url 1 url K
URL Merger: слияние списков • Списки попарно извлекаются из очереди и объединяются в один список с помощью алгоритма сортировки слиянием. Полученный список: — содержит только уникальные урлы — возвращается в очередь • Процесс продолжается до тех пор, пока не останется один список, содержащий все данные Url lists queue List 1 Merger List 1 List 2 … List 2 List N List. N+1 = List 1 + List 2 List N+1
Url Merger: нюансы алгоритма • Слияния списков можно производить параллельно: • Создаём несколько процессов-мержеров • Эффективнее сначала объединить все мелкие списки, затем более крупные и т. д: • • Очередь с приоритетами Приоритет списка = количество элементов в нём • Парсер создаёт списки практически непрерывно, а процесс слияния более эффективен, если производить его, когда накопится достаточно много мелких списков. QP = QF * K где: QP – суммарное количество элементов в необработанных списках QF – количество элементов в очереди на закачку K – константа
Url Merger: адаптированный алгоритм • Управление выносится в отдельный процесс – Collector • Итоговый список, содержащий все урлы, выносится из очереди и подаётся на вход модулю Updater Merger 1 Fetcher Queue Length … Merger M Collector Url list priority queue List 1 Updater … List N Result Url List
Updater: отправка на скачивание • Итоговый список периодически просматривается и часть урлов отправляются в очередь на закачку: – Все новые – На повторную закачку, т. е. те, у которых наступил момент Fetch_date + refetch_delay Result Url List Updater url 1 url 2 url 3 Fetcher queue set Site 1 url queue Time to (re)fetch? Site 2 url queue … Site. M url queue … url N Scheduler
Seeder: инициализация процесса • Функционирование описанной кольцевой схемы поддерживается самостоятельно, и требуется лишь однократно её запустить. – При необходимости можно делать это периодически • Seeder - процесс, «сеящий зерно» , т. е. записывающий исходные урлы в изначально пустую очередь на скачивание – Количество таких точек входа может быть любым Fetch queue set Seeder Site 1 url queue Site 2 url queue … Site. M url queue Site configs Site 1 entry url Site 2 entry url Site. M entry url
Crawler: общая схема WEB Fetcher 1 … Fetcher. N Scheduler Seeder Updater Collector Merger 1 Site configs Index Builder Parser Result list … URL Lists Merger. M
Re-fetch: обновление документов WEB Indexes URL Params • • ? Web-данные обновляются - индексы устаревают Как определить частоту обновлений? URL HTML
Re-fetch: обновление документов #2 • В идеале краулер должен скачивать страницу и обновлять индекс тогда и только тогда, когда источник изменился – В общем случае это невозможно – нас не оповещают • Исходный период обновления страниц подбирается вручную для каждого сайта-источника и сохраняется в соответствующем конфиге. • Cтраницы ведут очень индивидуально: некоторые не меняются годами, другие обновляются каждую минуту. – Поэтому равномерное скачивание всех страниц с одинаковой периодичностью нерационально – Универсального значения периода не существует – Как правило, страницы часто обновляются вскоре после создания, а со временем обновления становятся реже
Re-fetch: обновление документов #3 URL • Сhecksum Fetch Time + Refetch Delay … Для всех документов сайта значение Refetch Delay устанавливается в соответсвии с конфигом: – Документ повторно скачивается, как только наступает момент Fetch Time + Refetch Delay • Далее, используя новые данные, можно попробовать адаптировать параметры, чтобы оптимизировать работу: – Если данные источника изменились – лучше сократить промежуток до следующего запроса. – Если изменений нет – срок до следующей попытки можно увеличить.
Checksum: выявление изменений • Как определить, изменился ли документ? – Last-Modified пригоден только для статического контента. • Полагаем, что документ изменился, если изменился хотя бы один из его параметров, значимых для нас • Чтобы не хранить все значения свойств, создаём их отпечаток и сохраняем до следующего скачивания. – Если изменился отпечаток – изменился документ – необходимо обновлять индекс Сhecksum ( = СRC 32 URL Param 1: Value 1 … Param. N: Value. N )
Определение периода повторного скачивания Сhecksum URL Fetch Time Refetch Delay … • Модуль Parser, обрабатывая документ, каждый раз рассчитывает новый Check. Sum и сравнивает с предыдущим. • Если они не совпали – скачали эффективно: • Подаём документ на вход Index Builder • Уменьшаем срок до следующей выкачки: Refetch Delay /= K • Если совпали – скачали вхолостую: • Индексы не обновляем • Увеличиваем срок до следующей выкачки: Refetch Delay *= K K = 2
Поиск по видео: cоставные документы • Для формирования документа поиска по видео ресурсам необходимо два компонента: – Страница HTML для извлечения параметров документа – Собственно видеофайл (FLV, 3 GP, AVI) для генерации GIF-превью, поиска дубликатов и др. URL HTML params Checksum • Video content Last-Modified В таком случае скачивание документа происходит в два этапа.
Поиск по видео: алгоритм #1 Fetcher Queue URL Fetcher HTML Parser URL params После выяснения урла видео-контента Документ снова отправляется в очередь на выкачку Video. URL
Поиск по видео: алгоритм #2 Fetcher Queue URL params Video. URL Fetcher params Video. URL Video content Parser Для более быстрого получения «полноценных» документов здесь можно реализовать очередь с приоритетами Index Builder
Технические детали текущей реализации Seeder: запуск процесса • Язык реализации – Perl • Каждый логический модуль работает в отдельном процессе – Возможно разнесение процессов по разным хостам – Возможна реализация параллельности по данным • Процессы взаимодействуют 3 способами (с помощью IO: : KQueue): – Пайпы – Сокеты – Файловые очереди • Monitor – процесс, являющийся родителем для всех вышеописанных процессов, и выполняющий следующие функции: – Запуск и остановка модулей – Периодическая проверка их жизнеспособности (kill 0) и восстановление логической целостности при сбоях – Сбор статистики
Спасибо за внимание ?
Дополнительно: реализация файловой очереди • Алгоритм схож с алгоритмом реализации очереди с помощью двух стеков: • Очередь представляет собой два изначально пустых файла – IN и OUT • Операция PUSH добавляет элемент в конец файла IN • Операция PULL извлекает текущий элемент из файла OUT, двигаясь от его начала к концу • Если достигнут конец файла OUT, то всё содержимое файла IN переносится в OUT Записываем IN OUT Элемент А Элемент B Элемент C Переносим Элемент C Считываем сверху вниз
Скачать презентацию Архитектура краулера вертикального поиска Долинин Михаил Rambler 2010
d125a2f8438eb36ac0318e6e0382fa6d.ppt