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