Frontera: распределенный робот для обхода интернета в больших объемах - Александр Сибиряков, Scrapinghub
0 likes502 views
Документ описывает распределенный робот Frontera, предназначенный для обхода испанского интернета и сбора статистики о веб-узлах. В нем рассматриваются архитектурные решения, такие как использование Scrapy, Apache Kafka и HBase, а также описываются проблемы, связанные с обработкой большого объема данных. В заключение предоставлены планы на будущее и возможности для соавторства в проекте.
Frontera: распределенный робот для обхода интернета в больших объемах - Александр Сибиряков, Scrapinghub
- 1. Frontera: распределенный робот для обхода интернета в больших объемах Александр Сибиряков, 18 сентября 2015 sibiryakov@scrapinghub.com
- 2. • Родился в Екатеринбурге, РФ • 5 лет в Яндексе, отдел качества поиска: социальный и вопросно-ответный поиск, сниппеты. • 2 года в антивирусе Avast!, исследовательский отдел: автоматическое разрешение ложных срабатываний, предсказывание зловредных скачиваний. Здравствуйте, участники! 2
- 3. Задача • Обойти испанский интернет, для сбора статистики о узлах, их числе и размерах. • Ограничиться зоной .es. • Широкий обход (Breadth-first): в первую очередь страницы на расстоянии 1-го перехода, затем 2-х и т.д. • Условие остановки: отсутствие узлов с менее, чем 100 скачанными страницами. • Минимальные финансовые затраты. 3
- 4. Испанский интернет (.es) в 2012 • Доменных имен зарегистрировано - 1,56М (39% годовой прирост) • Веб-серверов в зоне - 283,4K (33,1%) • Хостов - 4,2M (21%) • Испанских сайтов в каталоге DMOZ - 22043 * - отчет OECD Communications Outlook 2013 4
- 5. Решение • Scrapy* - для сетевых операций. • Apache Kafka - шина данных (смещения, разделы). • Apache HBase - хранилище (случайный доступ, линейное сканирование, масштабируемость). • Twisted.Internet - библиотека с асинхронными примитивами для воркеров. • Snappy - алгоритм компрессии для IO задач. * - сетевые операции внутри Scrapy реализованы асинхронно, также на основе Twisted.Internet 5
- 6. Архитектура Kafka топик SW DB Воркеры стратегии обхода Воркеры хранилища 6
- 7. 1. Проблема больших и малых хостов • При обнаружении большого числа ссылок с хоста, и использовании простых моделей приоритизации часто происходит заполнение порции URL-ами с одного хоста. • Мы внедрили дополнительную по- хостовую (опционально по-IP) очередь, и дозирующий алгоритм: URL-ы c больших хостов кэшируются в памяти. 7
- 8. 3. DDoS DNS службы Amazon AWS • Breadth-first стратегия предполагает перво- очередной обход с ранее неизвестных хостов, генерируя тем самым огромное число DNS запросов. • Рекурсивный DNS сервер на каждом качающем хосте, с upstream на Verizon и OpenDNS. • Мы использовали dnsmasq. 8
- 9. 4. Настройка thread pool’а в Scrapy для разрешения по имени хоста • В Scrapy для получения IP адреса используется thread pool. • Если ip адреса нет в кэше, отправляется запрос на DNS сервер в отдельном треде, который блокируется. • Scrapy выдавал многочисленные ошибки связанные с таймаутом разрешения DNS имени. • Добавили в Scrapy возможность настраивать размер thread pool’a и таймауты. 9
- 10. 5. Перегружены регион-серверы HBase при проверке состояний • Когда робот делает обход, из каждой страницы извлекается несколько сотен ссылок. • Эти ссылки перед тем, как добавить в приоритетную очередь нужно проверить на их наличие там (чтобы избежать повторного скачивания). • На малых объемах SSD диски справлялись, после увеличения таблиц и переезда на HDD время исполнения запросов существенно увеличилось. • Хост-локальная хэш функция для генерации ключей в HBase. • Настройка HBase block cache, так чтобы один блок вмещал средний хост целиком. 10
- 11. 6. Интенсивный трафик от воркеров к сервисам • Скорость потока при коммуникации с Kafka и HBase доходила 1Gbit/s. • В HBase перешли на компактный протокол Thrift. • В Kafka начали использовать компрессию сообщений Snappy. 11
- 12. 7. Дальнейшие оптимизации запросов и трафика к HBase • Львиная доля запросов и трафика приходилась на проверку состояний. • В то же время требовалась консистентность. • Был создан локальный кэш на стороне воркера стратегии. • Для сохранения консистентности, поток от Scrapy-пауков к воркеру стратегии был разделен, так чтобы набор хостов на воркерах не пересекался. 12
- 13. Кэш состояний • Все операции пакетные: • в случае отсутствия в кэше, делается запрос в HBase, • каждые ~4 тыс. документов сохранение в HBase. • При увеличении до 3 млн(~1Гб) элементов, делается очистка с предварительным сохранением. • Напрашивается алгоритм Least-Recently-Used (LRU)
- 14. Очередь Spider’а • В ячейке массив из: - fingerprint, - Crc32(hostname), - URL, - score • Извлекается top N. • Архитектура уязвима к большим хостам. • Частично с этим можно бороться скоринг-моделью, учитывающей число документов найденных на хосте. 14
- 15. 8. Проблема больших и малых хостов (возвращение!) • По мере обхода мы нашли несколько действительно крупных хостов (>20M страниц) • Ввиду особенностей архитектуры самой очереди в HBase, на всех ее разделах в топе скопились страницы с нескольких крупных хостов. • Мы написали два MapReduce Job’а: • для перемешивания очереди, • для планирования не более 100 документов с хоста 15
- 16. • Один процесс Scrapy позволяет выкачивать со скоростью 1200 стр./мин. с около 100 веб-сайтов параллельно. • Соотношение пауков к воркерам 4:1 (без передачи контента) • 1 Гб памяти для каждого SW (кэш состояний, настраиваемый). • Пример: • 12 пауков ~ 14.4K страниц/мин., • 3 SW и 3 DB воркера, • Всего 18 ядер CPU необходимо. Аппаратные требования 16
- 17. • Apache HBase, • Apache Kafka, • Python 2.7+, • Scrapy 0.24+, • DNS Service. Программные требования CDH (100% Open source Hadoop дистрибутив) 17
- 18. Обслуживание Cloudera Hadoop на Amazon EC2 • Очень чувствительна к свободному месту на корневом разделе: логи, parcel-ы, и БД Cloudera Manager. • Можно отселить через символические ссылки на EBS раздел. • EBS должен быть около 30Гб, базовых IOPS достаточно. • Начальная конфигурация 3 x m3.xlarge (4 CPU, 15Gb, 2x40 SSD). • После недели работы, кончилось место, и мы начали переносить DataNod’ы на d2.xlarge (4 CPU, 30.5Gb, 3x2Tb HDD).
- 19. Обход испанского (.es) интернета • fnac.es, rakuten.es, adidas.es, equiposdefutbol2014.es, druni.es, docentesconeducacion.es - самые большие веб-узлы • 68.7K доменов найдено (~600 ожидаем), • 46.5M обойдено страниц, • 1.5 месяца, • 22 узла с более чем 50M страниц 19
- 20. • Онлайн архитектура: планирование новой порции, обновление состояний в хранилище. • Абстракция хранилища: напишите свой бэкенд (sqlalchemy, HBase есть в коробке). • Абстракция разрешения канонических URL: каждый документ имеет несколько URL, какой использовать? • Экосистема Scrapy: хорошая документация, большое сообщество, простота адаптации под Ваши нужды. Основные возможности 20
- 21. • Apache Kafka как шина данных: разделение топика и механизм смещений. • Абстракция стратегии обхода: цель обхода, приоритизация URL, и модель ранжирования закодированы в отдельном модуле. • Вежливость на уровне архитектуры: к каждому хосту обращается максимум один процесс. • Python: воркеры, модули загрузки. Основные возможности 21
- 22. Ссылки • Distributed Frontera. https://github.com/ scrapinghub/distributed-frontera • Frontera. https://github.com/scrapinghub/frontera • Документация: • http://distributed-frontera.readthedocs.org/ • http://frontera.readthedocs.org/ 22
- 23. Планы на будущее • Версия для одной машины, без зависимостей от HBase и Kafka. Коммуникация через сокеты или named pipes. • Стратегия переобхода в составе фреймворка. • Решения для слежения за изменениями на страницах веб-сайта (watchdog). • PageRank или HITS стратегия. • Собственные HTML и URL парсеры. • Интеграция в сервисы Scrapinghub’а. • Тестирование на больших объемах. 23
- 24. Будьте соавтором! • Distributed Frontera это первая в истории попытка реализовать производительный робот на Python’е. • Действительно тяжелая вычислительная задача (CPU, сеть, диски). • Сделано в Scrapinghub, где работают авторы Scrapy. • В планах Apache Software Foundation. 24