[RU] Frontera: Kubernetes, Web UI, RabbitMQ, все это в рамках участия в GSoC 2017

Всем привет, я занимаюсь разработкой Frontera, первым в истории фреймворком для масштабного обхода интернета сделанным на Python-е, с открытым исходным кодом. С помощью Фронтеры можно легко сделать робота который сможет выкачивать контент со скоростью тысяч страниц в секунду, при этом следуя вашей стратегии обхода и используя обычную реляционную БД или KV-хранилище для хранения базы ссылок и очереди.

Разработка Фронтеры финансируется компанией Scrapinghub Ltd., имеет полностью открытый исходный код (находится на GitHub, BSD 3-clause лицензия) и модульную архитектуру. Мы стараемся чтобы и процесс разработки тоже был максимально прозрачным и открытым.

В этой статье я собираюсь рассказать о Google Summer of Code, проблемах с которыми мы столкнулись при разработке Фронтеры и эксплуатации роботов на ее основе.

В этом году Фронтера участвует в Google Summer of Code. Кратко, Google финансирует разработку проектов с открытым исходным кодом сделанную студентами за летние месяцы каникул. Выглядит это следующим образом: происходит подача и разбор заявок, затем мы начинаем разработку, формируем план работ и менторы работают со студентами по нему, проходят два контрольных этапа, по результатам которых работа студента оплачивается или он отчисляется из GSoC.

Если Вы студент, хочу Вам предложить участие в GSoC. В списке ниже проекты не для начинающих, а скорее для «среднячков», которые хотят научиться чему-то большему. Работа над Фронтера это прекрасный шанс научится разрабатывать и проектировать распределенные приложения для обработки больших объемов данных.

В этом году мы предлагаем для GSoC следующие идеи проектов:

  • Утилита для развертывания Frontera на Kubernetes кластере. При запуске задает несколько вопросов о параметре кластера, заворачивает все в докер образы и деплоит в развернутый Kubernetes кластер. Очень интересный проект, но и от вас будут требоваться как DevOps так и разработческие навыки.
  • Web интерфейс для Фронтера. Нужно будет модифицировать компоненты, так чтобы они начали отправлять статистику, а затем сделать веб приложение на основе Django (обсуждается) где и будут выводиться данные.
  • Реализовать шину данных на основе RabbitMQ. Поскольку Фронтера распределенная в ней есть шина данных через которую общаются все компоненты. Сейчас есть реализации для Apache Kafka и ZeroMQ. Мы хотим добавить к ним еще RabbitMQ.

Если Вам что-то кажется интересным, и Вы студент, то дайте нам знать на frontera@scrapinghub.com и подайте заявку через форму GSoC. Подача заявок начинается с 20 марта и продлится до 3 апреля. Полное расписание GSoC 2017 здесь.

Вашу идею мы тоже можем рассмотреть, достаточно написать в наш список рассылки.

Теперь об архитектуре и собственно проблемах с которыми мы столкнулись. Устройство распределенного робота на базе Фронтеры выглядит так:

Frontera distributed backends run mode architecture

На картинке изображена конфигурация с хранилищем Apache HBase и шиной данных Apache Kafka. Процесс запускается из воркера стратегии обхода (SW), который планирует URL-ы, с которых нужно начать обход. Эти URL-ы попадают «scoring log», топик кафки (выделенный канал сообщений), потребляются воркером БД и им же планируются в топик «new batches», откуда поступают в пауки на основе Scrapy. Паук Scrapy разрешает DNS имя, поддерживает пул открытых соединений, получает контент и посылает его в топик «spider log». Откуда контент потребляется снова воркером стратегии и в зависимости от логики закодированной в стратегии обхода он планирует новые URL-ы.

Если кому-то интересно, то вот видео моего доклада о том, как мы обходили испанский интернет с помощью Фронтеры.

На текущий момент мы столкнулись с тем, что людям которые пытаются развернуть робота у себя очень тяжело дается конфигурирование распределенных компонент. К сожалению, развертывание Фронтеры на кластере предполагает понимание ее архитектуры, чтение документации, правильную настройку шины данных (message bus) и хранилища под нее. Все это очень затратно по времени и отнюдь не для начинающих. Поэтому мы хотим автоматизировать развертывание на кластере. Мы выбрали Kubernetes и Docker для достижения этих целей. Большой плюс Kubernetes в том, что он поддерживается многими облачными провайдерами (AWS, Rackspace, GCE и др.) Т.е. с помощью него можно будет развернуть Фронтеру даже не имея настроенного Kubernetes кластера.

Другая проблема в том, что Фронтера она как система водоснабжения ядерной электростанции. В ней есть потребители и производители для них очень важно контролировать такие характеристики, как скорость потока и производительность, в разных местах системы. Здесь следует напомнить, что Frontera это онлайн система. Классические роботы (Apache Nutch), напротив, работают в пакетном режиме: сначала порция планируется, затем скачивается, затем парсится и снова планируется. Одновременный парсинг и планирование не предусмотрены в таких системах. Таким образом, у нас встает проблема синхронизации скорости работы разных компонент. Довольно тяжело спроектировать робота, который обходит страницы с постоянной производительностью с большим количеством потоков, при этом сохраняет их в хранилище и планирует новые. Разнится скорость ответа веб-серверов, размер и количество страниц на сайте, количество ссылок, все это делает невозможным точную подгонку компонент по производительности. В качестве решения этой проблемы мы хотим сделать веб-интерфейс на базе Django. Он будет отображать основные параметры и если получится подсказывать какие нужно принять меры оператору робота.

Я уже упоминал о модульной архитектуре. Как и любой проект с открытым кодом мы стремимся к разнообразию технологий, которые мы поддерживаем. Поэтому сейчас у нас в Pull Request’ах готовится поддержка распределенного Redis, было уже две попытки сделать поддержку Apache Cassandra, ну и мы бы хотели поддержку RabbitMQ в качестве шины данных.

Конечно же, есть еще и проблемы производительности. На данный момент в Scrapinghub в пилотном режиме работает сервис по массивному скачиванию страниц на основе Фронтеры. Клиент нам предоставляет набор доменов, к которым он бы хотел получить контент, а мы их скачиваем и помещаем в S3 хранилище. Оплата за скачанный объем. В таких условиях мы стараемся качать как можно больше страниц в единицу времени. При попытке масштабировать Фронтеру до 60 спайдеров мы с толкнулись с тем, что HBase (через Thrift интерфейс) деградирует при записи в него всех найденных ссылок. Эти данные мы называем ссылочной базой, а нужна она для того, чтобы знать когда и что мы скачали, какой ответ получили и т.п. На кластере из 7 регион серверов у нас кол-во запросов доходит до 40-50K в секунду и при таких объемах время ответа сильно увеличивается. Производительность записи сильно падает. Решать такую проблему можно разными способами: например сохранять в отдельный быстрый лог, а позже его пакетными методами записывать в HBase, или же обращаться в HBase напрямую минуя Thrift, через собственный Java клиент.

Также мы постоянно работаем над улучшением надежности. Слишком большой скачанный документ или внезапные сетевые проблемы не должны приводить к остановке компонент. Тем не менее это иногда случается. Для диагностики таких случаев мы сделали обработчик сигнала ОС SIGUSR1, который сохраняет в лог текущий стек процесса. Несколько раз нам это очень сильно помогло разобраться в чем была проблема.

Мы планируем и дальше улучшать Фронтеру, и надеемся что сообщество активных разработчиков будет расти.

Visualization: performance of learning of different algortithms on synthetic data sets

Performance of learning of different algortithms on synthetic data sets

Performance of learning of different algortithms on synthetic data sets

Long time no see, if anyone is reading this blog. Few days ago, I found very interesting visualization of how different ML algorithms are performing on synthetic data sets. The study conatins Bayes, KNN, regression, rule- and tree-based, SVM models. No wonder, that SVM with well-tuned RBF kernel gamma and cost parameters is performing very good, the same for tree-based models.

Поездка по Австрии [russian]

С 13 по 19 апреля я с семьей (родителями и женой) ездил в путешествие по Австрии. Для недельной поездки на машине мы выбрали большой маршрут – в целом, чуть больше 2000 км. В результате мы объехали всю Австрию с запада на восток с заездом на юг.
Карта Continue reading

Similarity metrics

Posted originally by Sam Chapman, University of Sheffield, Department of Computer Science, NLP Group, United Kingdom. Right now, page isn’t available and I’m publishing it here.

Continue reading