How we crawl 70M of web pages daily: design evolution and fails.

I present a solution development we've made for one of our customers who required content acquisition on scale to build their own search engine.

Transcript

1. Как мы качаем 60 миллионов документов 
 в день из Веба: эволюция архитектуры, fail’ы Alexander Sibiryakov, Scrapinghub Ltd. 8-9 Ноября 2018
2. Постановка
3. Поисковый движок • Для заказчика • Мы доставляем только веб страницы (!), • Поиск по компаниям US и UK для продаж, • Цель - найти компании, выдача - список компаний, • [heat pump], [cable production], [baking soda].
4. Список компаний • Полнотекстовый поиск: • главные страницы • «о компании» • продуктовые • новостные • контактные • Метаданные: доход, численность сотрудников, регион, и др.
5. Бизнес кейс • Вы производите печи для булочек и ищете: • Компании торгующие хлебопекарными изделиями в UK • Печи бюджетные, поэтому средние компании: с доходом не выше X GBP и не более 100 человек • Много, фильтр: получили инвестиции или был куплены (событийные триггеры)
6. Требования от клиента • 14M вебсайтов/мес • 100 страниц с сайта • Цель 1.4 миллиардов страниц в месяц: • ~47M/день или 2M/час или 35K/минуту. • 700 страниц в секунду.
7. Требования к решению • На лету обнаруживать ссылки • Отсутствие затыков в разных частях системы • Следование robots.txt, запросы с задержками (бан) • Минимум железа • 100% загрузка сетевого канала • Хранить контент минимум времени (дешевле и легальнее, GDPR)
8. Требования к решению • Rendering пока не нужно, возможно потом. • Изображения, CSS, JS и т.д. не требуются.
9. Как это реализовать?
10. Необходимый минимум 1. Сетевой уровень: DNS, подключение, запрос/ ответ 2. Parsing: HTML, извлекать ссылки 3. Dupe-фильтр: хранилище и проверка ссылок 4. Очередь: набор запросов на прокачку
11. Глоссарий bot (робот) - вся система целиком, spider - скачивающий и парсирующий процесс spider feed - поток запросов на прокачку spider log - результаты прокачки: документы, ссылки seed - URL с которого начинается обход
12. Совсем примитивно • 1 Python процесс • 1 поток • очередь в памяти • по-хостовые счётчики в памяти • это Scrapy!
13. • Обход долгий, процесс может упасть, • 1 процесс это максимум 20 RPS, • ссылки или очередь >> RAM Масштабировать
14. N x Scrapy -> 1 x Redis • Распределенный • dupe-фильтр: Redis sets (SADD, SLEN) • очередь: Redis sorted set по ключу (ZADD, ZREM*) SPOF Redis ops Как дальше масштабировать? См. https://github.com/rmax/scrapy-redis
15. Чего мы все-таки хотим? • Все части робота масштабируются: • хранилище: • ссылочная база (dupe-фильтр) • очередь • spider процессы • процессы обнаружения и планирования
16. Чего мы все-таки хотим? • Отказоустойчивость: • Хранилище с репликами • Мин. потери данных при падении • spider, • обнаружения/планирования • Независимость процессов.
17. Apache Kafka • Шина данных • Гибко шардируется и реплицируется • Удобное разбиение по данным: Partitioner’s Log - топик Kafka
18. V.1 Apache Kafka-only • Простаивающие spider’ы → неэффективное планирование, • Локальный dupe-фильтр → неконсистентность. Spiders + Discovery Spider log Spider Feed
19. Неэффективная укладка ссылок в логе Kafka time A B C 1-2% CPU, <1RPS host A host B host C Spider
20. Эффективная укладка time A B C 100% CPU, 20 RPS
21. Spiders + Discovery Spider log Spider Feed V.1 Apache Kafka-only Priority Queue
22. Priority queue • Хранилище • scoring log - лог со ссылками, который нужно запланировать, • enqueuing и dequeuing workers, • dequeuing w. создает порции из мно-ва хостов, • 500 запросов. / 30 сек, • бесконечный цикл.
23. V.2 Added Priority Queue Снова неэффективная укладка :( Spiders + Discovery Spider log Spider Feed Priority Queue enqueue worker dequeuing worker Scoring log
24. Discovery and dequeuing N<<M Запросы покидают очередь слишком быстро! N RPS M RPS СОГЛАСОВАННОСТЬ Priority Queue Spiders / Discovery
25. V.3 Согласованная priority queue lag = end_off - fetcher_off lag < 1000 ? new batch : idle Priority Queue Spiders / Discovery Spider feed Scoring log Enqueuing worker Dequeuing worker Spider offset updates offset
26. • Большая часть очереди в хранилище, а не в топике Кафки • гарантия приоритизации и разнообразия хостов. теперь 100% CPU, 20 RPS Очередь работает как надо
27. ОК, очередь масштабируется, что дальше?
28. Проблемы внутри spider’а проверка дубликатов V.1-3, dupe-фильтр в памяти Download Parse HTML Extract links Scheduling Priority Queue reqs Dupe-фильтр не переживёт перезапуск процесса
29. Обнаружение ссылок A0 t spiders A0 A0 A1 A2 A0 A2 A4 A5 A1 A0 A8 A2 A4 1 2 3 A5 A8 A1 A7 A2 A3 A1 A6 A5 • Seed • Прокачка seed • Парсинг, обнаружение, • Цикл на 2, 3 • Ещё цикл Масштаб: Сайты x кол-во spider’ов
30. • Spider-процессов несколько. • Хосты между процессами перемешиваются. • Часть дубликатов все равно проходит фильтр. Нужна надежная обработка дубликатов
31. Как? • Централизованное хранилище - ОК. • Spider’ы ходящие в хранилище - плохо, сильно усложняется связность, • Задержки на синхронных вызовах → замедление скачивания.
32. Решение • Отдельный компонент, • Воркер дубликатов, • Spider log > worker > scoring log, • состояния ссылок во внешнем хранилище.
33. Как быть вежливым? • Делать задержку • Нужно состояние по хостам • Один хост с нескольких процессов? • Как сделать доступным, для всех процессов? • Не надо • Нужно качать каждый хост, не более чем с одного процесса
34. Решение A B C t spiders A1 B1 C1 A1 B3 C2 D0 D2 F4 G8 H2 I4 1 2 3 D E F G H I D1 E1 F1 G1 H1 I1 • Назначить хосты на Spider- процессы жёстко • не сможем масштабировать без ре-балансировки • да, но все остальное сильно сложнее
35. Распределение хостов A,E,I A,B C,D E,F G,H I,J B,F,H C,D,G ,J Spiders Dup. workers
36. Strategy worker • Расширим функционал Dupe worker’а • Мотивация? • NEW, CRAWLED, QUEUED, ERRORED • по-доменные метаданные • планировать когда угодно и что угодно • СТРАТЕГИЯ ОБХОДА - модульность
37. Финальная версия Spiders … Spider log Strategy workers Scoring log Link states Priority Queue enqueue worker Spider Feed dequeuing worker offsets monitoring
38. Выбор хранилища • Все процессы одно-поточные, общих данных нет 
 → требования к ACID низкие, • Данных много, миллиарды ссылок, миллионы URL в очереди, Тб → шардирование, • Access patterns: • GET по ключу, • GET/PUT пачку.
39. Выбор хранилища • Очередь: RPS малый, данных немного (URLы), • Состояния ссылок: RPS высокий, но большое пересечение → возможность брать из кэша, • В один момент времени мы работаем с небольшой частью данных, • Хорошая масштабируемость, • Стоимость потери данных велика → репликация.
40. with Cloudera Manager
41. Тестирование в бою
42. DDoS of Amazon DNS • В начале обхода, много запросов, • Таймауты на все запросы. • Установка своего рекурсивного DNS с кешем, • BIND или unbound, • unbound позволяет манипуляции с кешом.
43. Замедление очереди через два-три часа • Очередь работает → удаленные строки, • Scan начинает тормозить, • Нужно чаще регенерировать таблицу, • majorCompaction → 30 мин.
44. Высокий IOPS в HBase RS • Одна ссылка - одна строка в HBase, • Проверка состояний пачками, • 1 стр. → до 10^4 ссылок → random seeks. • Блоки + сортировка ключей • нужен новый дизайн ключа:
45. Лучше, но высокий CPU • И все равно SW узкое место, • RPS к кластеру доходил до 200K, • Локальный кэш ссылок в памяти SW: • нет ключа в памяти → в HBase, • LRU, 3M ссылок. •
46. Китайский gambling
48. Китайский gambling • Автоматически генерируемые сайты, • Пролинковка с доменами третьего и выше уровня, • Ссылок много, • Не работает лимит на hostname. • Проверка состояний снова перегружена!
49. Решение • Везде используем домен 2-го уровня, • Библиотека publicsuffix: • my.name.co.uk → name.co.uk • www.vasily.com → vasily.com • Не ходим в HBase если превышен лимит по домену. • https://publicsuffix.org/ (Mozilla Foundation)
50. Самый большой деплоймент • Mesos: • 77 vCores • 350 Gb RAM HBase: • 7 x 12C, 128Gb Kafka: • 7 x 12C, 128Gb, 10x5.4T HDD ~250 cores total
51. В production уже 1.5 года
52. Основные находки • Для прокачки нужно и дозировать ссылки от разных хостов. • Не допускать обработку одного хоста с нескольких машин: дубликаты, бесконтрольный RPS. • Продумывать назначение хостов на начальном этапе. • При проверке ссылок кэш, страницы с одного сайта имеют похожие ссылки.
53. Основные находки • Как ключ использовать домен 2-го уровня, publicsuffix. • Таблицу с очередью постоянно регенерировать, • На Python можно построить робота для обхода: https://github.com/scrapinghub/frontera
54. Спасибо! Вопросы. alex@sibiryakov.eu