Insight IT

Архитектура Pinterest

Иван Блинков — Wed, 15 Aug 2012 22:26:00 +0400

Pinterest - по непонятным для меня причинам популярная в определенных кругах социальная сеть, построенная вокруг произвольных картинок чаще всего не собственного производства. Как и Instagram проект довольно молодой, с очень похожей историей и стеком технологий. Тем не менее, Pinterest определенно заслуживает внимания как один из самых быстрорастущих по посещаемости вебсайтов за всю историю.

Платформа

Amazon AWS - хостинг и вспомогательные сервисы
nginx - вторичная балансировка нагрузки, отдача статики
Python - язык программирования
Django - фреймворк
MySQL - основная СУБД
memcached - кэширование объектов
Redis - кэширование коллекций объектов
Solr - поиск
Hadoop - анализ данных

Статистика

3 миллиона уникальных посетителей в день
18 миллионов уникальных посетителей в месяц
4-я по популярности социальная сеть в США после Facebook, Twitter и LinkedIn
Порядка 500 виртуальных машин в EC2
80 миллионов объектов в S3
410Тб пользовательских данных

Развитие

Март 2010

1 маленький виртуальный веб-сервер
1 маленький виртуальный сервер MySQL
Все это в Rackspace, 1 разработчик

Январь 2011

1 сервер nginx для балансировки нагрузки, 4 веб-сервера
2 сервера MySQL с master/slave репликацией
3 сервера для отложенного выполнения задач
1 сервер MongoDB
Переехали на Amazon EC2 + S3 + CloudFront

Осень 2011

2 сервера nginx, 16 веб-серверов, 2 сервера для API
5 функционально разделенных серверов MySQL с 9 read slave
Кластер из 4 узлов Cassandra
15 серверов Membase в 3 отдельных кластерах
8 серверов memcached
10 серверов Redis
7 серверов для отложенной обработки задач
4 сервера Elastic Search
3 кластера MongoDB
3 разработчика
Если кто-то может объяснить зачем им сдался такой зоопарк, кроме как потестировать разные варианты, можете взять с полки пирожок.

Зима 2011-2012

Заменили CloudFront на Akamai - вполне объяснимо, так как у Akamai намного лучше покрытие по миру, а качественный CDN для сайта с большим количеством изображений - чуть ли не залог успеха.
90 веб серверов и 50 серверов для API
66 + 66 MySQL серверов на m1.xlarge инстансах EC2
59 серверов Redis
51 серверов memcached
25+1 сервер для отложенной обработки задач на основе Redis
Кластеризованный Solr
6 разработчиков

Весна-лето 2012

Снова сменили CDN, на этот раз в пользу ранее неизвестного мне Edge Cast. Покрытие по всему миру довольно скромное, так что единственное логичное объяснение, которое мне приходит в голову - не потянули Akamai по деньгам.
135 веб серверов и 75 серверов для API
80 + 80 серверов MySQL
110 серверов Redis
60 серверов memcached
60 + 2 сервера для отложенной обработки задач на основе Redis
25 разработчиков

Выбор

Почему Amazon Ec2/S3?

Очень хорошая надежность, отчетность и поддержка
Хорошие дополнительные сервисы: кэш, базы данных, балансировка нагрузки, MapReduce и т.п.
Новые виртуальные машины готовы за считанные секунды

Почему MySQL?

Очень "зрелая", хорошо известная и любимая многими
Редки катастрофичные потери данных
Линейная зависимость времени отклика от частоты запросов
Хорошая поддержка сторонним ПО (XtraBackup, Innotop, Maatkit)
Надежное активное сообщество
Отличная поддержка от Percona
Бесплатна

Почему memcached?

Очень "зрелый", отличная производительность, хорошо известный и любимый многими
Никогда не ломается
Бесплатен

Почему Redis?

Много удобных структур данных
Поддержка персистентности и репликации
Также многим известен и нравится
Стабильно хорошая производительность и надежность
Также бесплатен

Архитектура

Сlustering vs Sharding

Большую часть презентации, на основе которой написана данная статья (ссылка, если не охота листать до секции источников информации), занимает раздел под названием "Clustering vs Sharding". В связи с путаницей в терминологии пришлось несколько раз перечитывать, чтобы понять к чему они клонят, сейчас попробую объяснить.
Вообще есть два фундаментальных способа распределить данные между несколькими серверами:
- Вертикально: разные таблицы (или просто логически разные типы данных) разносятся на разные сервера.
- Горизонтально: каждая таблица разбивается на некоторое количество частей и эти части разносятся на разные сервера по определенному алгоритму.
С первого взгляда казалось, что они пытаются вертикальное разбиение назвать sharding, а горизонтальное - clustering. Хотя вообще они почти синонимы и на русский я их обычно примерно одинаково перевожу.
По факту же оказалось, что под словом clustering они понимают все программные продукты для хранения данных, которые имеют встроенную поддержку работы в кластере. В частности они имеют ввиду Cassandra, Membase, HBase и Riak, которые прозрачно для пользователя горизонтально распределяют данные по кластеру.
За словом sharding в их терминологии стоит аналогичная схема собственной разработки, использующая огромное количество логических БД в MySQL, распределенных между меньшим количеством ~~физических серверов~~ виртуальных машин. Именно по этому пути и пошли в Pinterest, плюс очень похожий подход используется в Facebook.
От себя добавлю, что хоть при наличии должных ресурсов разработка собственной системы распределения данных и может быть целесообразной, в большинстве случаев на начальном этапе проще основываться на готовых решениях вроде перечисленных выше. К слову в opensource доступны и основанные на MySQL подобные решения:
- Vitess от Google / YouTube
- FlockDB от Twitter
В их проекте данная подсистема развивалась следующим образом:
- 1 БД + внешние ключи + join'ы →
- 1 БД + денормализация + кэш →
- 1 БД + master/slave + кэш →
- несколько функциональных разделенных БД + master/slave + кэш →
- вертикально и горизонтально разделенные БД (по идентификаторам) + по резервные БД (пассивный slave) + кэш
При использовании аналогичного решения остерегайтесь:
- Невозможности выполнять большинство запросов с join
- Отсутствия транзакций
- Дополнительных манипуляций для поддержания ограничений уникальности
- Необходимости тщательного планирования для изменений схемы
- Необходимости выполнения одного и того же запроса с последующей агрегацией для построения отчетов

Остальные моменты

Кэширование многоуровневое:
- Коллекции объектов хранятся в списках Redis
- Сами объекты - в memcached
- На уровне SQL запросы в основном примитивны и написаны вручную, так что часты попадания в кэш MySQL
- Кэш файловой системы - само собой
Еще пара фактов про кэширование в Pinterest:
- Кэш разбит также на несколько частей (шардов), для упрощения обслуживания и масштабирования
- В коде для кэширования используются Python'овские декораторы, на вид собственной разработки, хотя точно не уверен
Балансировка нагрузки осуществляется в первую очередь за счет Amazon ELB, что позволяет легко подключать/отключать новые сервера посредством API.
Так как большинство пользователей живут в США по ночам нагрузка сильно падает, что позволяет им по ночам отключать до 40% виртуальных машин. В пиковые часы EC2 обходится порядка 52$ в час, а по ночам - всего 15$.
Elastic Map Reduce, основанный на Hadoop, используется для анализа данных и стоит всего несколько сотен долларов в месяц
Текущие проблемы:
- Масштабирование команды
- Основанная на сервисах архитектура:
  - Ограничения соединений
  - Изоляция функционала
  - Изоляция доступа (безопасность)

Уроки от команды Pinterest

"Оно сломается. Все должно быть просто." - столько раз уже слышу это наставление, но ни разу не видел разработчиков, которые реально к нему прислушивались.
"Кластеризация - страшная штука." - конечно страшная, большая и сложная. Но кому сейчас легко?
"Продолжайте получать удовольствие." - с этим не могу не согласиться, без удовольствия работать совершенно невозможно в любой сфере.

Источники информации

Scaling Pinterest @ MySQL Meetup
- В презентации можно посмотреть примеры кода и SQL-запросов
- Если кто-то знает где можно посмотреть/послушать запись этого мероприятия - поделитесь ссылкой, пожалуйста
Pinterest Architecture Update
Вакансии в Pinterest

Архитектура Tumblr

Иван Блинков — Tue, 21 Feb 2012 16:29:00 +0400

Tumblr - одна из самых популярных в мире платформ для блоггинга, которая делает ставку на привлекательный внешний вид, юзабилити и дружелюбное сообщество. Хоть проект и не особо на слуху в России, цифры говорят сами за себя: 24й по посещаемости сайт в США с 15 миллиардами просмотров страниц в месяц. Хотите познакомиться с историей этого проекта, выросшего из простого стартапа?

Введение

Как и всем успешным стартапам, Tumblr удалось преодолеть опасную пропать между начинающим проектом и широко известной компанией. Поиск правильных людей, эволюция инфраструктуры, поддержка старых решений, паника по поводу значительного роста посещаемости от месяца к месяцу, при этом в команде только 4 технических специалиста - все это заставляло руководство Tumblr принимать тяжелые решения о том над чем стоит работать, а над чем - нет. Сейчас же технический персонал расширился до 20 человек и у них достаточно энергии для преодоления всех текущих проблем и разработки новых интересных технических решений.

Поначалу Tumblr был вполне типичным большим LAMP приложением. Сейчас же они двигаются в направлении модели распределенных сервисов, построенных вокруг существенно менее распространенных технологий. Основные усилия сейчас вкладываются в постепенный уход от PHP в пользу более "правильных" и "современных" решений, оформленных в виде сервисов. Параллельно с переходом к новым технологиям идут изменения и в команде проекта: от небольшой группы энтузиастов к полноценной команде разработчиков, имеющей четкую структуру и сферы ответственности, но тем не менее жаждущей реализовывать новый функционал и обустраивать совершенно новую инфраструктуру проекта.

Платформа

CentOS на серверах, Mac OS X для разработки
Apache - основной веб-сервер
PHP, Scala, Ruby - языки программирования
Finagle - асинхронный RPC сервер и клиент
MySQL, HBase - СУБД
memcached, Redis - кэширование
Varnish, nginx - отдача статики
HAProxy - балансировка нагрузки
kestrel, gearman - очередь задач
Thrift - сериализация
Kafka - распределенная шина сообщений
Hadoop - обработка статистики
ZooKeeper - хранение конфигурации и состояний системы
git - система контроля версий
Jenkins - непрерывное тестирование

Статистика

Около 500 миллионов просмотров страниц в день
Более 15 миллиардов просмотров страниц в месяц
Посещаемость растет примерно на 30% в месяц
Пиковые нагрузки порядка 40 тысяч запросов в секунду
Около 20 технических специалистов в команде
Каждый день создается около 50Гб новых постов и 2.7Тб обновлений списков последователей
Более 1Тб статистики обрабатывается в Hadoop ежедневно
Используется порядка 1000 серверов:
- 500 веб-серверов c Apache и PHP-приложением
- 200 серверов баз данных (существенная их часть - резервные)
  - 47 пулов
  - 30 партиций (шардов)
- 30 серверов memcached
- 25 серверов Redis
- 15 серверов Varnish
- 25 серверов HAProxy
- 8 серверов nginx
- 14 серверов для очередей задач

Типичное использование

Tumblr используется несколько по-другому, чем другие социальные сети:
- При более чем 50 миллионах постов в день, каждый из них попадает в среднем к нескольким сотням читателей. Это и не несколько пользователей с миллионами читателей (например, популярные личности в Twitter) и не миллиарды личных сообщений.
- Ориентированность на длинные публичные сообщения, полные интересной информацией и картинками/видео, заставляет пользователей проводить долгие часы каждый день за чтением Tumblr.
- Большинство активных пользователей подписывается на сотни других блоггеров, что практически гарантирует много страниц нового контента при каждом заходе на сайт. В других социальных сетях поток новых сообщений переполнен ненужным контентом и толком не читается.
- Как следствие, при сложившемся количестве пользователей, средней аудиторией каждого и высокой активностью написания постов, системе приходится обрабатывать и доставлять огромное количество информации.
Публичные блоги называют Tumblelog'ами, они не так динамичны и легко кэшируются.
Сложнее всего масштабировать Dashboard, страницу, где пользователи в реальном времени читают что нового у блоггеров, на которых они подписаны:
- Кэширование практически бесполезно, так как для активных пользователей запросы редко повторяются.
- Информация должна отображаться в реальном времени, быть целостной и не "задерживаться".
- Около 70% просмотров страниц приходится именно на Dashboard, почти все пользователи им пользуются.

Старая архитектура

Когда проект только начинался, Tumblr размещался в Rackspace и последние выдавали каждому блогу с собственным доменом A-запись. Когда они переросли Rackspace, они не смогли полноценно мигрировать в новый датацентр, в том числе из-за количества пользователей. Это было в 2007 году, но у них по-прежнему часть доменов ведут на Rackspace и перенаправляются в новый датацентр с помощью HAProxy и Varnish. Подобных "унаследованных" проблем у проекта очень много.
С технической точки зрения проект прошел по пути типичной эволюции LAMP:
- Исторически разработан на PHP, все началось с веб-сервера, сервера баз данных и начало потихоньку развиваться.
- Чтобы справляться с нагрузкой они начали использовать memcache, затем добавили кэширование целых страниц и статических файлов, потом поставили HAProxy перед кэшами, после чего сделали партиционирование на уровне MySQL, что сильно облегчило им жизнь.
- Они делали все, чтобы выжать максимум из каждого сервера.
- Было разработано два сервиса на C: генератор уникальных идентификаторов на основе HTTP и libevent, а также Staircar, использующий Redis для обеспечения уведомлений в реальном времени на Dashboard.
Dashboard использует подход "разбрасывать-собирать", так как из-за отсортировонности данных по времени традиционные схемы партиционирования работали не очень хорошо. По их прогнозам текущая реализация позволит им рости еще в течении полугода.

Новая архитектура

Приоритетным направлением стали технологии, основанные на JVM, по причине более быстрой разработки и доступности квалифицированных кадров. Мотивация несколько спорная, особенно если учесть, что речь идет в первую очередь о Scala, а не о Java.
Основная цель - вынести все из PHP приложения в отдельные сервисы, что сделает его лишь тонким клиентом к внутреннему API.
Почему выбор пал именно на Scala и Finagle?
- Многие разработчики имели опыт с Ruby и PHP, так что Scala был привлекательным (цитата, логики мало)
- Finagle был одним из основных факторов в пользу JVM: это библиотека, разработанная в Twitter, которая решает большинство распределенных задач вроде маршрутизации запросов и обнаружение/регистрацию сервисов - не пришлось реализовывать это все с нуля.
- В Scala не принято использовать общие состояния, что избавляет разработчиков от забот с потоками выполнения и блокировками.
- Им очень нравится Thrift в роли программного интерфейса из-за его высокой производительности (он кроссплатформенный и к JVM никак не относится)
- Нравится Netty, но не хочется связываться с Java, еще один аргумент в пользу Scala.
- Рассматривали Node.js, но отказались так как под JVM проще найти разработчиков, а также из-за отсутствия стандартов, "лучших практик" и большого количества качественно протестированного кода.
Старые внутренние сервисы также переписываются с C + libevent на Scala + Fingle.
Был создан общий каркас для построения внутренних сервисов:
- Много усилий было приложено для автоматизации управления распределенной системой.
- Создан аналог скаффолдинга - используется некий шаблон для создания каждого нового сервиса.
- Все сервисы выглядят одинаково с точки зрения системного администратора: получение статистики, мониторинг, запуск и остановка реализованы одинаково для всех сервисов.
- Созданы простые инструменты для сборки сервисов без вникания в детали используемых стандартных решений.
Используется 6 внутренних сервисов, над которыми работает отдельная команд. На запуск сервиса с нуля уходит около 2-3 недель.
Новые, нереляционные СУБД, такие как HBase и Redis, вводятся в эксплуатацию, но основным хранилищем по-прежнему остается сильно партиционированный MySQL.
HBase используется для сервиса сокращенных ссылок для постов, а также всех исторических данных и аналитики. HBase хорошо справляется с ситуациями, где необходимы миллионы операций записи в секунду, но он не достаточно стабилен, чтобы полностью заменить проверенное временем решение на MySQL в критичных для бизнеса задачах.
Партиционированный MySQL плохо справляется с отсортированными по времени данными, так как один из серверов всегда оказывается существенно более "горячим", чем остальными. Также сталкивались с значительными задержками в репликации из-за большого количества параллельных операций добавления данных.
Используется 25 серверов Redis с 8-32 процессами на каждом, что означает порядка 300-400 экземпляров Redis в сумме.
- Используется для уведомлений в реальном времени на Dashboard (о событиях вроде "кому-то понравился Ваш пост").
- Высокое соотношений операций записи к операциям чтения сделало MySQL не очень подходящим кандидатом.
- Уведомления не так критичны, их потеря допустима, что позволило отключить персистентность Redis.
- Был создан интерфейс между Redis и отложенными задачами в Finagle.
- Сервис коротких ссылок также использует Redis как кэш, а HBase для постоянного хранения.
- Вторичный индекс Dashboard также построен вокруг Redis.
- Redis также используется для хранения задач Gearman, для чего был написан memcache proxy на основе Finale.
- Постепенно отказываются от memcached в пользу Redis в роли основного кэша. Производительность у них сопоставима.
Внутренним сервисам необходим доступ к потоку всех событий в системе (создание, редактирование и удаление постов, нравится или не нравится и т.п.), для чего была созданна внутренняя шина сообщений (англ. firehose, пожарный шланг):
- Пробовали использовать в этой роли Scribe, но так как оно по сути свелось к пропусканию логов через grep в реальном времени - нагрузки оно не выдержало.
- Текущая реализация основана на Kafka, решению аналогичной задачи от LinkedIn на Scala.
- MySQL также не рассматривался из-за большой доли операций записи.
- Внутри сервисы используют HTTP потоки для чтения данных, хотя Thrift интерфейс также используется.
- Поток сообщений хранит события за последнюю неделю с возможностью указать момент времени с которого считывать данные при открытии соединения.
- Поддерживается абстракция "группы потребителей", которая позволяет группе клиентов вместе обрабатывать один поток данных вместе и независимо, то есть одно и то же сообщение не попадет дважды к клиентам из одной группы.
- ZooKeeper используется для периодического сохранения текущей позиции каждого клиента в потоке.
Новая архитектура Dashboard основана на принципе ячеек или ящиков входящих сообщений:
- Каждая "ячейка" отвечает за группу пользователей и читает новые события с шины сообщений, если один из её пользователей-подопечных подписан на автора только что опубликованного поста, то пост добавляется в "почтовый ящик" подписанного пользователя.
- Когда пользователь заходит в Dashboard его запрос попадает в его ячейку, которая возвращает ему нужную часть непрочитанных постов.
- Каждая ячейка состоит из трех групп серверов:
  - HBase для постоянного хранения копий постов и почтовых ящиков;
  - Redis для кэширование свежих данных;
  - Сервис, читающий данные из шины и предоставляющий доступ к ящикам посредством Thrift.
- В HBase используется две таблицы:
  - Отсортированный список идентификаторов постов для каждого пользователя в ячейке, именно в том виде, как они будут отображены в итоге.
  - Копии всех постов по идентификаторам, что позволяет выдать все данные для отрисовки Dashboard без обращений к серверам вне одной ячейки.
- Ячейки представляют собой независимые единицы, что позволяет легко масштабировать систему при росте числа пользователей.
- Платой за относительно безболезненность масштабирования является чрезвычайная избыточность данных: при том что ежедневно создается лишь 50Гб постов, суммарный объем данных в ячейках растет на 2.7Тб в день.
- Альтернативой было бы использование общего кластера со всеми постами, но тогда он бы стал единственной точкой отказа и потребовалось бы делать дополнительные удаленные запросы. Помимо этого выигрыш по объему был бы не велик - списки идентификаторов занимают значительно больше места, чем сами посты.
- Пользователи, которые подписаны или на которых подписаны миллионы других пользователей, обрабатываются отдельно - страницы с их постами генерируются не заранее (как описывалось выше), а при поступлении запроса - это позволяет не тратить впустую много ресурсов (этот подход называется выборочная материализация).
- Количество пользователей в одной ячейке позволяет управлять балансом между уровнем надежности и стоимостью содержания этой подсистемы.
- Параллельное чтение их шины сообщений оказывает серьезную нагрузку на сеть, в дальнейшем из ячеек можно будет составить иерархию: только часть будет читать напрямую из шины сообщений, а остальным сообщения будут ретранслироваться.
Tumblr географически по-прежнему находится в одном датацентре (если не считать незначительное присутствие в Rackspace), распределение по нескольким лишь в планах.

Развертывание

Начиналось как несколько rsync-скриптов для распространения PHP-приложения. Как только машин стало больше 200 такой подход стал занимать слишком много времени.
Следующий вариант был основан на Capistrano: были созданы три стадии процесса развертывания (разработка, тестирование, боевой). Неплохо справлялся с десятками серверов, но на сотнях также был слишком медленным, так как основывался на SSH.
Итоговый вариант основан на Func, решении от RedHat, позволившим заменить SSH на более легковесный протокол.

Разработка

Поначалу философия была такова, что каждый мог использовать любые технологии, которые считал уместным. Но довольно скоро пришлось стандартизировать стек технологий, чтобы было легче нанимать и вводить в работу новых сотрудников, а также для более оперативного решения технических проблем.
Каждый разработчик имеет одинаковую заранее настроенную рабочую станцию, которая обновляется посредством Puppet:
- Настроена публикация изменений, тестирование и развертывание новых версий.
- Разработчики используют vim и Textmate.
Новый PHP код систематически инспектируется другими разработчиками.
Внутренние сервисы подвергаются непрерывному тестированию посредством Jenkins.

Структура команд

Проект разбит на 6 команд:

Инфраструктура: все, что ниже 5 уровня по модели OSI - маршрутизация, TCP/IP, DNS, оборудование и.т.п.
Платформа: разработка основного приложения, партиционирование SQL, взаимодействие сервисов.
Надежность (SRE): сфокусирована на текущие потребности с точки зрения надежности и масштабируемости.
Сервисы: занимается более стратегической разработкой того, что понадобится через один-два месяца.
Эксплуатация: отвечает за обнаружение и реагирование на проблемы, плюс тонкая настройка.

Найм

На интервью они обычно избегают математики и головоломок, основной упор идет в основном именно на те вещи, которым придется заниматься кандидату.
Основной вопрос: будет ли он успешно решать поставленные задачи? Цель в том, чтобы найти отличных людей, а не в том, чтобы никого не брать.
Разработчиков обязательно просят привести пример своего кода, даже во время телефонных интервью.
Во время интервью кандидатов не ограничивают в наборе инструментов, можно даже гуглить.
Поиск людей с опытом в крупных проектах достаточно сложен, так как всего нескольких компаниях по всему миру решают подобные проблемы.

Подводим итоги

Автоматизация - ключ к успеху крупного проекта.
При партиционировании MySQL может масштабироваться, но лишь при преобладании операций чтения.
Redis с отключенной персистентностью легко может заменить memcached.
Scala достойно себя проявляет в роли языка программирования для внутренних сервисов, во многом благодаря обширной Java-экосистеме.
Внедряйте новые технологии постепенно, поначалу работать с HBase и Redis было очень болезненно, они были включены в основной стек технологий только после испытаний в некритичных сервисах и подпроектах, где цена ошибки не так велика.
Проект должен строиться вокруг навыков его команды, а не наоборот.
Нужно нанимать людей только если они вписываются в команду и в состоянии довести работу до результата.
При выборе технологического стека одну из ключевых ролей играет доступность соответствующих специалистов на кадровом рынке.
Читайте публикации и статьи в блогах. Ключевые аспекты архитектуры, включая "ячейки" и частичную материализацию были позаимствованы из внешних источников.
Поспрашивайте своих коллег, кто-то из них мог общаться с специалистами из Facebook, Twitter, Google или LinkedIn - если нет прямого доступа, всегда можно получить нужную информацию через одно-два "рукопожатия".

Статья написана на основе интервью Blake Matheny, директора по разработке платформы Tumblr.

Аналитика в реальном времени от Facebook

Иван Блинков — Thu, 24 Mar 2011 19:14:00 +0300

HBase в Facebook завоевывает все более и более крепкие позиции, в прошлый раз я рассказывал о применении HBase в роли системы хранения данных для их новой системы обмена сообщений. Вторым продуктом, который теперь полноценно использует данную технологию, является система сбора и обработки статистики в реальном времени под названием Insights. Социальные кнопки (см. слева от поста) стали одним из основных источников трафика для многих сайтов, новая система аналитики позволит владельцам сайтов и страниц лучше понимать как пользователи взаимодействуют и оптимизировать свои интернет-ресурсы, основываясь на данных в реальном времени. Итак, 20 миллиардов событий в день (200 тысяч в секунду) с задержкой не более 30 секунд, как же можно этого достичь?

Цели сервиса

Дать пользователям надежные счетчики в реальном времени по ряду метрик
Предоставлять анонимные данных - нельзя узнать кто конкретно были эти люди
Продемонстрировать ценность социальных плагинов и виджетов. Что они дают сайту или бизнесу?
Концепция воронки: сколько людей увидело плагин, сколько совершило действие, сколько было привлечено пользователей обратно на интернет-ресурс
Сделать данные более оперативными: сокращение частоты обновлений с 48 часов до 30 секунд

Задачи

Множество типов метрик, более 100: показы, лайки, просмотры и клики в новостной ленте, демография и.т.д.
Большой поток данных: 20 миллиардов событий в день
Неравномерное распределение данных: за большинство контента практически не голосуют, но некоторые материалы набирают просто невероятное количество лайков

Неудавшиеся попытки

MySQL

В каждой строке идентификатор и значение счетчика
Привело к очень высокой активности в СУБД
Статистика считается за каждые сутки, создание новых счетчиков в полночь приводило к большому скачку операций записи
Пришлось пробовать искать способы решать проблему распределения счетчиков, пробовали учитывать временные зоны пользователей
Пики операций записи неминуемо вели к блокировкам
Решение оказалось не очень хорошо подходящим для данной конкретной задачи

Счетчики в памяти

Казалось бы: если столкнулись с проблемами ввода-вывода - надо перенести все в память
Никаких проблем с масштабируемостью - счетчики находятся в памяти, обновление практически мгновенно, легко распределить по серверам
Но на практике оказалось, что при таком подходе теряется точность, видимо из-за неатомарности операций или других последствий столь прямолинейной реализации, подробностей нет
Погрешность даже в 1% посчитали неприемлемой и от данного варианта отказались

MapReduce

Предыдущий вариант реализации был создан с помощью Hadoop + Hive
Подход гибкий, легко справляется с большим входящим потоком информации и объемами данным
Основной минус: даже близко не в реальном времени, слишком комплексная система

Cassandra

Вариант с Cassandra рассматривался, но так и не был реализован
Причины были опубликованы достаточно сомнительные: высокие требования к доступности данных и производительности записи
По всем данным у Cassandra нет абсолютно никаких проблем ни с одним, ни с другим

Победитель: HBase + Scribe + Ptail + Puma

В целом система, на которой остановился выбор, выглядит следующим образом:

HBase хранит все данные на распределенном кластере
Используется система логов, новые данные дописываются в конец
Система обрабатывает события и записывает результат в хранилище
Пользовательский интерфейс забирает данные из хранилища и отображает пользователям

Как обрабатывается один запрос:

Пользователь жмет на кнопку Like
Браузер инициирует AJAX запрос к серверу Facebook
Запрос записывается в лог в HDFS с помощью Scribe
Ptail - внутренний инструмент для чтения данных из нескольких Scribe-логов, на выходе данные разделяются на три потока, которые отправляются в разные кластеры в разных датацентрах:
- Просмотры плагинов и виджетов
- Просмотры в новостной ленте
- Действия (плагины + новостная лента)
Puma - механизм для пакетной записи данных в HBase для снижения влияния "горячих" материалов:
- HBase может справиться с очень большим потоком операций записи, но популярные материалы могут заставить упереться во ввод-вывод даже её
- В среднем пакет запросов собирается в течении 1.5 секунд, хотелось бы больше - но из-за огромного количества URL очень быстро заканчивается оперативная память
Отображение данных пользователю:
- Сам код для отображения написан на PHP
- Работа с HBase осуществляется из Java
- Для взаимодействия по традиции используется Thrift
Система кэширования используется для ускорения отображения страниц:
- Чем более старые данные запрашиваются, тем реже они пересчитываются
- Многое зависит от типа запрашиваемой статистики
MapReduce:
- Данные передаются для дальнейшего анализа с помощью Hive
- Сами логи удаляются через какой-то период времени
- Помимо этого старая система анализа статистики все еще в действии, она используется для регулярных проверок результатов новой системы, а также в роли запасного плана, если что-то пойдет не так

О проекте

Продолжительность 5 месяцев
2 с половиной разработчика самой системы
2 разработчика пользовательского интерфейса
Всего было задействовано около 14 человек, включая менеджмент, дизайнера и системных администраторов

Направления развития

Списки популярных материалов: при текущем подходе их составление является сложной задачей
Отдельные пользовательские счетчики
Обобщение приложения для использования с другими сервисами, а не только с социальными плагинами
Распределение системы на несколько датацентров

Подводим итоги

У новых систем аналитики и сообщений много общего: большой поток входящих данных для записи, HBase и требование работы в реальном времени. Facebook делает ставку на HBase, Hadoop и HDFS, не смотря на громоздкость системы, когда другие предпочитают Cassandra из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным - покажет время.

Источники информации

Архитектура Twitter. Два года спустя.

Иван Блинков — Sat, 05 Mar 2011 20:47:00 +0300

В далеком 2008м я уже публиковал статью про архитектуру Twitter, но время летит стремительно и она уже абсолютно устарела. За это время аудитория Twitter росла просто фантастическими темпами и многое поменялось и с технической точки зрения. Интересно что новенького у одного из самых популярных социальных интернет-проектов?

Статистика

3 год, 2 месяца и 1 день потребовалось Twitter, чтобы набрать 1 миллиард твитов
На сегодняшний день, чтобы отправить миллиард твитов пользователям нужна всего одна неделя
752% рост аудитории за 2008 год
1358% рост аудитории за 2009 год (без учета API, по данным comScore)
175 миллионов зарегистрированных пользователей на сентябрь 2010 года
460 тысяч регистраций пользователей в день
9й сайт в мире по популярности (по данным Alexa, год назад был на 12 месте)
50 миллионов твитов в день год назад, 140 миллионов твитов в день месяц назад, 177 миллионов твитов в день на 11 марта 2011г.
Рекорд по количеству твитов за секунду 6939, установлен через минуту после того, как Новый Год 2011 наступил в Японии
600 миллионов поисков в день
Лишь 25% трафика приходится на веб сайт, остальное идет через API
Росто числа мобильных пользователей за последний год 182%
6 миллиардов запросов к API в день, около 70 тысяч в секунду
8, 29, 130, 350, 400 - это количество сотрудников Twitter на январь 2008, январь 2009, январь 2010, январь и март 2011, соответственно

Самая свежая статистика про Twitter.

Платформа

Сравните с аналогичным разделом предыдущей статьи о Twitter - увидите много новых лиц, подробнее ниже.

Оборудование

Сервера расположены в NTT America
Никаких облаков и виртуализации, существующие решения страдают слишком высокими задержками
Более тысячи серверов
Планируется переезд в собственный датацентр

Что такое твит?

Сообщение длиной до 140 символов + метаданные
Типичные запросы:
- по идентификатору
- по автору
- по @упоминаниям пользователей

Архитектура

Unicorn

Сервер приложений для Rails:

Развертывание новых версий кода без простоя
На 30% меньше расход вычислительных ресурсов и оперативной памяти, по сравнению с другими решениями
Перешли с mod_proxy_balancer на mod_proxy_pass

Rails

Используется в основном для генерации страниц, работа за сценой реализована на чистом Ruby или Scala.

Столкнулись со следующими проблемами:

Проблемы с кэшированием, особенно по части инвалидации
ActiveRecord генерирует не самые удачные SQL-запросы, что замедляло время отклика
Высокие задержки в очереди и при репликации

memcached

memcached не идеален. Twitter начал сталкиваться с Segmentation Fault в нем очень рано.
Большинство стратегий кэширования основываются на длинных TTL (более минуты).
Вытеснение данных делает его непригодным для важных конфигурационных данных (например флагов "темного режима", о котором пойдет речь ниже).
Разбивается на несколько пулов для улучшения производительности и снижения риска вытеснения.
Оптимизированная библиотека для доступа к memcached из Ruby на основе libmemcached + FNV hash, вместо чистого Ruby и md5.
Twitter является одним их наиболее активных проектов, участвующих в разработке libmemcached.

MySQL

Разбиение больших объемов данных является тяжелой задачей.
Задержки в репликации и вытеснение данных из кэша является причиной нарушения целостности данных с точки зрения конечного пользователя.
Блокировки создают борьбу за ресурсы для популярных данных.
Репликация однопоточна и происходит недостаточно быстро.
Данные социальных сетей плохо подходят для реляционных СУБД:
- NxN отношения, социальный граф и обход деревьев - не самые подходящие задачи для таких баз данных
- Проблемы с дисковой подсистемой (выбор файловой системы, noatime, алгоритм планирования)
- ACID практически не требуется
- Для очередей также практически непригодны
Twitter сталкивался с большими проблемами касательно таблиц пользователей и их статусов
Читать данные с мастера при Master/Slave репликации = медленная смерть

FlockDB

Масштабируемое хранилище для данных социального графа:

Разбиение данных через Gizzard
Множество серверов MySQL в качестве низлежащей системы хранения
В Twitter содержит 13 миллиардов ребер графа и обеспечивает 20 тысяч операций записи и 100 тысяч операций чтения в секунду
Грани хранятся и индексируются в обоих направлениях
Поддерживает распределенный подсчет количества строк
Open source!

Среднее время на выполнение операций:

Подсчет количества строк: 1мс
Временные запросы: 2мс
Запись: 1мс для журнала, 16мс для надежной записи
Обход дерева: 100 граней/мс

Подробнее про эволюцию систем хранения данных в Twitter в презентации Nick Kallen.

Cassandra

Распределенная система хранения данных, ориентированная на работу в реальном времени:

Изначально разработана в Facebook
Очень высокая производительность на запись
Из слабых сторон: высокая задержка при случайном доступе
Децентрализованная, способна переносить сбои оборудования
Гибкая схема данных
~~Планируется полный переход на нее по следующему алгоритму:~~
- ~~Все твиты пишутся и в Cassandra и в MySQL~~
- ~~Динамически часть операций чтения переводится на Cassandra~~
- ~~Анализируется реакция системы, что сломалось~~
- ~~Полностью отключаем чтение из Cassandra, чиним неисправности~~
- ~~Начинаем сначала~~
Обновление: стратегия по поводу использования Cassandra изменилась, попытки использовать её в роли основного хранилища для твитов прекратились, но она продолжает использоваться для аналитики и географической информации.

Подробнее почему Twitter пришел к решению использовать Cassandra можно прочитать в отдельной презентации.

Помимо всего прочего Cassandra ~~планируется использовать~~ используется для аналитики в реальном времени.

Scribe

Пользователи Twitter генерируют огромное количество данных, около 15-25 Гб в минуту, более 12 Тб в день, и эта цифра удваивается несколько раз в год.

Изначально для сбора логов использовали syslog-ng, но он очень быстро перестал справляться с нагрузкой.

Решение нашлось очень просто: Facebook столкнулся с аналогичной проблемой и разработал проект Scribe, который был опубликован в opensource.

По сути это фреймворк для сбора и агрегации логов, основанный на Thrift. Вы пишете текст для логов и указываете категорию, остальное он берет на себя.

Работает локально, надежен даже в случае потери сетевого соединения, каждый узел знает только на какой сервер передавать логи, что позволяет создавать масштабируемую иерархию для сбора логов.

Поддерживаются различные системы для записи в данным, в том числе обычные файлы и HDFS (о ней ниже).

Этот продукт полностью решил проблему Twitter со сбором логов, используется около 30 различных категорий. В процессе использования была создана и опубликована масса доработок. Активно сотрудничают с командой Facebook в развитии проекта.

Hadoop

Как Вы обычно сохраняете 12Тб новых данных, поступающих каждый день?

Если считать, что средняя скорость записи современного жесткого диска составляет 80Мбайт в секунду, запись 12Тб данных заняла бы почти 48 часов.

На одном даже очень большом сервере данную задачу не решить, логичным решением задачи стало использование кластера для хранения и анализа таких объемов данных.

Использование кластерной файловой системы добавляет сложности, но позволяет меньше заботиться о деталях.

Hadoop Distributed File System (HDFS) предоставляет возможность автоматической репликации и помогает справляться со сбоями оборудования.

MapReduce framework позволяет обрабатывать огромные объемы данных, анализируя пары ключ-значение.

Типичные вычислительные задачи, которые решаются с помощью Hadoop в Twitter:

Вычисление связей дружбы в социальном графе (grep и awk не справились бы, self join в MySQL на таблицах с миллиардами строк - тоже)
Подсчет статистики (количество пользователей и твитов, например подсчет количества твитов занимает 5 минут при 12 миллиардах записей)
Подсчет PageRank между пользователями для вычисления репутации.

В твиттер используется бесплатный дистрибутив от Cloudera, версия Hadoop 0.20.1, данные храняться в сжатом по алгоритму LZO виде, библиотеки для работы с данными опубликованы под названием elephant-bird.

Pig

Для того чтобы анализировать данные с помощью MapReduce обычно необходимо разрабатывать код на Java, что далеко не все умеют делать, да и трудоемко это.

Pig представляет собой высокоуровневый язык, позволяющий трансформировать огромные наборы данных шаг за шагом.

Немного напоминает SQL, но намного проще. Это позволяет писать в 20 раз меньше кода, чем при анализе данных с помощью обычных MapReduce работ. Большая часть работы по анализу данных в Twitter осуществляется с помощью Pig.

Данные

Полу-структурированные данные:

логи Apache, RoR, MySQL, A/B тестирования, процесса регистрации
поисковые запросы

Структурированные данные:

Твиты
Пользователи
Блок-листы
Номера телефонов
Любимые твиты
Сохраненные поиски
Ретвиты
Авторизации
Подписки
Сторонние клиенты
География

Запутанные данные:

Социальный граф

Что же они делают с этим всем?

Подсчет математического ожидания, минимума, максимума и дисперсии следующих показателей:
- Количество запросов за сутки
- Средняя задержка, 95% задержка
- Распределение кодов HTTP-ответов (по часам)
- Количество поисков осуществляется каждый день
- Количество уникальных запросов и пользователей
- Географическое распределение запросов и пользователей
Подсчет вероятности, ковариации, влияния:
- Как отличается использование через мобильные устройства?
- Как влияет использование клиентов сторонних разработчиков?
- Когортный анализ
- Проблемы с сайтом (киты и роботы, подробнее ниже)
- Какие функциональные возможности цепляют пользователей?
- Какие функциональные возможности чаще используются популярными пользователями?
- Корректировка и предложение поисковых запросов
- A/B тестирование
Предсказания, анализ графов, естественные языки:
- Анализ пользователей по их твитам, твитов, на которые они подписаны, твитам их фоловеров
- Какая структура графа ведет к успешным популярным сетям
- Пользовательская репутация
- Анализ эмоциональной окраски
- Какие особенности заставляют людей ретвитнуть твит?
- Что влияет на глубину дерева ретвитов ?
- Долгосрочное обнаружение дубликатов
- Машинное обучение
- Обнаружения языка

Подробнее про обработку данных в презентации Kevin Weil.

HBase

Twitter начинают строить настоящие сервисы на основе Hadoop, например поиск людей:

HBase используется как изменяемая прослойка над HDFS
Данные экспортируются из HBase c помощью периодической MapReduce работы:
- На этапе Map используются также данные из FlockDB и нескольких внутренних сервисов
- Собственная схема разбиения данных
- Данные подтягиваются через высокопроизводительный, горизонтально масштабируемый сервис на Scala (подробнее о построении распределенных сервисов на Scala)

На основе HBase разрабатываются и другие продукты внутри Twitter.

Основными её достоинствами являются гибкость и легкая интеграция с Hadoop и Pig.

По сравнению с Cassandra:

"Их происхождение объясняет их сильные и слабые стороны"
HBase построен на основе системы по пакетной обработке данных, высокие задержки, работает далеко не в реальном времени
Cassandra построена с нуля для работы с низкими задержками
HBase легко использовать при анализе данных как источник или место сохранения результатов, Cassandra для этого подходит меньше, но они работают над этим
HBase на данный момент единственную точку отказа в виде мастер-узла
В твиттере HBase используется для аналитики, анализа и создания наборов данных, а Cassandra - для онлайн систем

Loony

Централизованная система управления оборудованием.

Реализована с использованием:

Python
Django
MySQL
Paraminko (реализация протокола SSH на Python, разработана и опубликована в opensource в Twitter)

Интегрирована с LDAP, анализирует входящую почту от датацентра и автоматически вносит изменения в базу.

Murder

Система развертывания кода и ПО, основанная на протоколе BitTorrent.

Благодаря своей P2P природе позволяет обновить более тысячи серверов за 30-60 секунд.

Kestrel

Распределенная очередь, работающая по протоколу memcache:

set - поставить в очередь
get - взять из очереди

Особенности:

Отсутствие строгого порядка выполнения заданий
Отсутствие общего состояния между серверами
Разработана на Scala

Daemon'ы

Каждый твит обрабатывается с помощью daemon'ов.

В unicorn обрабатываются только HTTP запросы, вся работа за сценой реализована в виде отдельных daemon'ов.

Раньше использовалось много разных демонов, по одному на каждую задачу (Rails), но перешли к меньшему их количеству, способному решать несколько задач одновременно.

Как они справляются с такими темпами роста?

Рецепт прост, но эффективен, подходит практически для любого интернет-проекта:

обнаружить самое слабое место в системе;
принять меры по его устранению;
перейти к следующему самому слабому месту.

На словах звучит и правда примитивно, но на практике нужно предпринять ряд мер, чтобы такой подход был бы реализуем:

Автоматический сбор метрик (причем в агрегированном виде)
Построение графиков (RRD, Ganglia)
Сбор и анализ логов
Все данные должны получаться с минимальной задержкой, как можно более близко к реальному времени
Анализ:
- Из данных необходимо получать информацию
- Следить за динамикой показателей: стало лучше или хуже?
- Особенно при развертывании новых версий кода
- Планирование использования ресурсов намного проще, чем решение экстренных ситуаций, когда они на исходу

Примерами агрегированных метрик в Twitter являются "киты" и "роботы", вернее их количество в единицу времени.

Что такое "робот"?

Ошибка внутри Rails (HTTP 500)
Непойманное исключение
Проблема в коде или нулевой результат

Что такое "кит"?

HTTP ошибка 502 или 503
В твиттер используется фиксированный таймаут в 5 секунд (лучше кому-то показать ошибку, чем захлебнуться в запросах)
Убитый слишком длинный запрос к базе данных (mkill)

Значительное превышение нормального количества китов или роботов в минуту является поводом для беспокойством.

Реализован этот механизм простым bash-скриптом, который просматривает агрегированные логи за последние 60 секунд, подсчитывает количество китов/роботов и рассылает уведомления, если значение оказалось выше порогового значения. Подробнее про работу команды оперативного реагирования в презентации John Adams.

"Темный режим"

Для экстренных ситуаций в Twitter предусмотрен так называемый "темный режим", который представляет собой набор механизмов для отключения тяжелых по вычислительным ресурсам или вводу-выводу функциональных частей сайта. Что-то вроде стоп-крана для сайта.

Имеется около 60 выключателей, в том числе и полный режим "только для чтения".

Все изменения в настройках этого режима фиксируются в логах и сообщаются руководству, чтобы никто не баловался.

Подводим итоги

Не бросайте систему на самотек, начинайте собирать метрики и их визуализировать как можно раньше
Заранее планируйте рост требуемых ресурсов и свои действия в случае экстренных ситуаций
Кэшируйте по максимуму все, что возможно
Все инженерные решения не вечны, ни одно из решений не идеально, но многие будут нормально работать в течение какого-то периода времени
Заранее начинайте задумываться о плане масштабирования
Не полагайтесь полностью на memcached и базу данных - они могут Вас подвести в самый неподходящий момент
Все данные для запросов в реальном времени должны находиться в памяти, диски в основном для записи
Убивайте медленные запросы (mkill) прежде, чем они убьют всю систему
Некоторые задачи могут решаться путем предварительного подсчета и анализа, но далеко не все
Приближайте вычисления к данным по возможности
Используйте не mongrel, а unicorn для RoR

Спасибо за внимание, жду Вас снова! Буду рад, если Вы подпишитесь на меня в Twitter, с удовольствием пообщаюсь со всеми читателями :)

Новое поколение MapReduce в Apache Hadoop

Иван Блинков — Sat, 19 Feb 2011 21:23:00 +0300

В большом бизнесе использование нескольких больших кластеров с финансовой точки зрения более эффективно, чем много маленьких. Чем больше машин в кластере, тем большими наборами данных он может оперировать, больше задач могут выполняться одновременно. Реализация MapReduce в Apache Hadoop столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce, в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предистория

Текущая реализация Hadoop MapReduce устаревает на глазах. Основываясь на текущих тенденциях в размерах кластеров и нагрузок на них, JobTracker требует кардинальных доработок, чтобы исправить его дефекты в области масштабируемости, потребления памяти, многопоточности, надежности и производительности. С точки зрения работы с Hadoop при каждом обновлении кластера (даже если это просто багфикс), абсолютно все компоненты кластера, так и приложений, которые на нем работают, должны быть обновлены одновременно. Это так же очень неудобно, так как каждый раз необходимо тестировать все приложения на совместимость с новой версией.

Требования

Прежде чем кардинально что-то менять в Hadoop mapreduce, необходимо понять какие же основные требования предъявляются к вычислительным кластерам на практике. Наиболее значительными требованиями к Hadoop следующего поколения являются:

Надежность
Доступность
Масштабируемость - кластеры из как минимум 10 тысяч машин, 200 тысяч вычислительных ядер и даже больше
Обратная и прямая совместимость - возможность быть уверенным, что приложение будет работать на новой версии так же, как оно работало на старой
Контроль над обновлениями
Предсказуемые задержки
Эффективное использование ресурсов

Среди менее значительных требований:

Поддержка альтернативных парадигм разработки (помимо MapReduce)
Поддержка сервисов с коротким жизненным циклом

Если учесть перечисленные выше требования, то становится очевидно, что инфраструктура обработки данных в Hadoop должна быть кардинальным образом изменена. В сообществе Hadoop люди в целом приходят к общему мнению, что текущая архитектура MapReduce не способна решить текущие задачи, которые перед ней ставится, и что требуется кардинальный рефакторинг кодовой базы.

MapReduce следующего поколения

Фундаментальной идеей смены архитектуры является разделение двух основных функций JobTracker'а на два отдельных части:

управление ресурсами;
планирования и мониторинга задач.

В итоге появляется несколько новых ролей:

ResourceManager управляет глобальным распределением вычислительных ресурсов между приложениями;
ApplicationMaster управляет планированием и координацией внутри приложения;
NodeManager управляет процессами в рамках одной машины.

ApplicationMaster представляет собой библиотеку, с помощью которой можно получить у ResourceManager квоту на вычислительные ресурсы и работать с NodeManager(ами) для выполнения и мониторинга задач.

ResourceManager поддерживает иерархическим очереди приложений, которым может гарантированно выделяться некоторый процент ресурсов кластера. Его функционал ограничивается планированием, никакого мониторинга и отслеживания задач не происходит, а также нет никаких гарантий перезапуска задач, провалившихся из-за проблем с оборудованием или кодом. Планирование основывается на требованиях, которые выставляет приложение с помощью ряда запросов ресурсов (среди них: запросы на вычислительные ресурсы, память, дисковое пространство, сетевой доступ и т.п.). Обратите внимание, что это значительное изменение по сравнению с текущей моделью слотов фиксированного размера, которая является одной из основных причин неэффективного использования ресурсов кластера на данный момент.

NodeManager - это агент, который работает на каждой машине и несет ответственность за запуск контейнеров приложений, мониторинг используемых ими ресурсов (плюс отчет планировщику).

По одному ApplicationMaster запускается для каждого приложения, они ответственны за запрос необходимых ресурсов у планировщика, запуск задач, отслеживание статусов, мониторинг прогресса и обработку сбоев.

Архитектура

Улучшения по сравнению с текущей реализацией MapReduce

Масштабируемость

Разделение управления ресурсами и прикладными задачами позволяет горизонтально расширять кластер более просто и эффективно. JobTracker проводит значительную часть времени пытаясь управлять жизненным циклом каждого приложения, что часто может приводить к различным происшествиям - переход к отдельному менеджеру для каждого приложения является значительным шагом вперед.

Масштабируемость особенно важна в свете текущих трендов в оборудовании - на данный момент Hadoop может быть развернут на кластере из 4000 машин. Но 4000 средних машин 2009го года (т.е. по 8 ядер, 16Гб памяти, 4Тб дискового пространства) только вдвое менее ресурсоемки, чем 4000 машин 2011го года (16 ядер, 48гб памяти, 24Тб дискового пространства). Помимо этого с точки зрения операционных издержек было выгоднее работать в еще больших кластере от 6000 машин и выше.

Доступность

ResourceManager использует Apache ZooKeeper для обработки сбоев. Когда ResourceManager перестает работать, аналогичный процесс может быстро запуститься на другой машине благодаря тому, что состояние кластера было сохранено в ZooKeeper. При таком сценарии все запланированные и выполняющиеся приложения максимум лишь перезапустятся.
ApplicationMaster - поддерживается создание точек восстановления на уровне приложений. ApplicationMaster может восстановить работу из состояния, сохраненного в HDFS, в случае сбоя.

Совместимость протокола

Это позволит различным версиям клиентов и серверов Hadoop общаться между собой. Помимо решения многих существующих проблем с обновлением, в будующих релизах появится возможность последовательного обновления кода без простоя системы в целом - очень большое достижения с точки зрения системного администрирования.

Инновационность и гибкость

Основным плюсом предложенной архитектуры является тот факт, что MapReduce по сути становится просто пользовательской библиотекой. Вычислительная же система (ResourceManager и NodeManager) становятся полностью независимыми от специфики MapReduce.

Клиенты получат возможность одновременного использования разных версий MapReduce в одном и том же кластере. Это становится тривиальным, так как отдельная копия ApplicationMaster'а запускается для каждого приложения. Это дает гибкость в исправлении багов, улучшений и новых возможностей, так как полное обновление кластер перестает быть обязательной процедурой. Это позволяет клиентам обновлять их приложения до новых версий MapReduce вне зависимости от обновлений кластера.

Эффективность использования вычислительных ресурсов

ResourceManager использует общую концепцию для управления ресурсами и планирования по отношению к каждому конкретному приложению. Каждая машина в кластере на концептуальном уровне рассматривается просто как набор ресурсов: память, процессор, ввод-вывод и др. Все машины взаимозаменяемы и приложение может быть назначено на любую из них, основываясь на доступных и запрашиваемых ресурсах. При этом приложения работают в контейнерах, изолированно от других приложений, что дает сильную поддержку многозадачности.

Таким образом эта схема избавляет от текущего механизма map и reduce слотов в Hadoop, который негативно влияет на эффективную утилизацию вычислительных ресурсов.

Поддержка других парадигм программирования помимо MapReduce

В предложенной архитектуре используется общий механизм вычислений, не привязанный конкретно к MapReduce, что позволит использовать и другие парадигмы. Имеется возможность реализовать собственный ApplicationMaster, способный запрашивать ресурсы у ResourceManager и использовать их в соответствии с задачей, при этом сохраняются общие принципы изоляции и гарантированного наличия полученных ресурсов. Среди потенциально поддерживаемых парадигм можно назвать MapReduce, MPI, Мaster-Worker, итеративные модели. Все они могут одновременно работать на одном и том же кластере. Это особенно актуально для приложений (например К-средний или Page Rank), где другие подходы более чем на порядок эффективнее MapReduce.

Выводы

Apache Hadoop, и в частности Hadoop MapReduce - очень успешный opensource проект по обработке больших объемов данных. Предложенный Yahoo путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

Осталось дело за малым - собственно реализовать задуманное! :)

Источник информации

Подписаться на RSS можно здесь.

Еще раз про HBase

Иван Блинков — Wed, 27 Aug 2008 19:29:00 +0400

Некоторое время назад Neuronus в одном из комментариев к посту "Hadoop возвращается" не согласился с моим кратким определением HBase как "нереляционная база данных" (позаимствованным, собственно говоря, откуда-то с официального портала продукта). Этот факт подтолкнул меня попытаться найти более корректное определение в англоязычных источниках информации, получилось вполне успешно. Хочется прочитать более детально что к чему? Вперед! Если Вам уже приходилось иметь дело с этой системой,возможно Вы уже поняли, что самым сложным этапом работы является просто-напросто осознавание того, чем она на самом деле является. Обычно приходится мысленно отказаться от всех привычек, доставшихся при работе с традиционный RDBMS, и начинать постигать базовые принципы организации хранения данных с нуля.

Стоит напомнить, что проект позиционируется как opensource реализация BigTable от Google. Да, проекты реализованы разными людьми на разных языках программирования, но общие идеи и принципы функционирования у них сильно пересекаются. Наиболее значимой общей характеристикой у них является очень схожие модели данных (о чем упоминается в вики HBase), а в свою очередь в документации BigTable она описывается очень четко и определенно, точно определяя чем эти продукты по сути являются:

A Bigtable is a sparse, distributed, persistent multidimensional sorted map.

Предлагаю по аналогии со статьей в вики, послужившей основой для данного поста, разбить это определение на отдельные слова и последовательно пройтись по ним, попутно составляя в голове полную картину.

map

За этим термином нет четкого устоявшегося обозначения в русском языке (да и в английском тоже все далеко не так однозначно), математики обычно называют это отображением одного множества в другое, в то время как если Вы знакомы с программированием, то Вам наверняка больше знакомы будут более знакомы такие обозначения, как ассоциативный массив (PHP), словарь (Python), хэш (Ruby) или объект (JavaScript).

По сути же имеется ввиду просто набор однозначно соответствующих пар ключ-значение, в роли которых выступают массивы байт. Во все той же статейке в вики все очень наглядно демонстрируется примерами в нотации JSON, позволю себе тоже приводить аналогичные примеры. В JSON наш map выглядел бы следующим образом:

{
  "qqqq" : "some",
  "abc" : "sample",
  "zz" : "JSON",
  "123" : "map",
  "mnbvcxz" : "looks like this"
}

persistent

Это прилагательное обозначает всего лишь "постоянный", то есть в данном контексте оно говорит только о том, что данная система не зависит от использующих ее приложений, а также хранится на устройствах постоянного хранения данных, а не в оперативной памяти.

distributed

Распределенность этих систем можно рассматривать с двух точек зрения:

Как HBase, так и BigTable сами по себе могут функционировать на большом количестве серверов, которые можно разделить на две большие категории: master и slave. Slave сервера собственно выполняют всю работу с данными, а master - лишь только координируют их действия и управляют процессом в целом. Этот факт обеспечивают высокую степень устойчивости к сбоям (в HBase правда количество master-серверов ограничено одним, что представляет собой единственную точку, сбой в которой приведет к отказу всей системы, но это лишь временная проблема, которую наверняка устранят в следующих версиях), а также существенно облегчает масштабируемость всей системы так как добавление дополнительных серверов (а значит и увеличение производительности и вместительности системы) достаточно тривиально, безболезненно и не мешает общему ее функционированию.
Помимо этого каждая из этих систем обычно использует для хранения данных кластерную файловую систему (HBase - HDFS, а BigTable - GFS), которые тоже по своей природе являются распределенными и функционируют по схожему принципу, обеспечивая дополнительную сохранность данных, реплицируя их в нескольких экземплярах на нескольких серверах (обычно трех).

sorted

HBase и BigTable не строят никакие индексы для ускорения процесса извлечения данных, единственное используемое в них правило заключается в следующем: каждый slave-сервер в системе отвечает за определенный диапазон ключей (от и до определенных его значений), и держит все записи в строгом лексикографическом порядке по ключам (заметьте: сортировку значений никто не гарантирует!). Продолжая пример с JSON это выглядело бы примерно вот так:

{
  "123" : "map",
  "abc" : "sample",
  "mnbvcxz" : "looks like this",
  "qqqq" : "some",
  "zz" : "JSON"
}

Этим фактом можно активно пользоваться при планировании использовании системы, например если в качестве ключей планируется использовать доменные именные имена, то имеет смысл использовать их в "развернутом" виде, например: "com.example.www" вместо "www.example.com". Это почти наверняка обеспечит попадание всех поддоменов одного и того же домена на один slave-сервер, а также группировку доменов по зонам.

multidimensional

До сих пор ключ интерпретировался нами как нечто единое и неделимое, но на самом деле в данной ситуации это далеко не так. На самом деле пространство имен HBase и BigTable имеет несколько пространств, по аналогии с трехмерным материальным пространством, где есть ширина, высота и глубина. Если мы попытаемся представить это с помощью JSON, то это будет выглядеть как набор вложенных простых map'ов:

{
  "table-1":
  {
     "column-family-1":
     {
        "column-1":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-2": "value-2",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        },
        "column-2":
        {
           "row-1":
           {
              "timestamp-1": "value-1",
              "timestamp-3": "value-3"
           },
           "row-2":
           {
              "timestamp-1": "value-4",
              "timestamp-2": "value-5",
              "timestamp-3": "value-6"
           }
        }
     "column-family-2":
     {
        "column-1":
        {
           // ...
        },
        "":
        {
           "row-1": "some-value"
        }
        // ...
     }
     }
  }
}

Как можно увидеть из примера, таких пространств используется пять:

таблицы;
наборы столбцов;
столбцы;
строки;
время;

Таким образом, каждое значение в хранилище данных однозначно соответствует ключу, состоящему из пяти компонентов, например в примере значению "value-5" соответствует ключ, состоящий из:

table-1;
column-family-1;
column-1;
row-2;
timestamp-2;

Принцип очень похож на используемый в более привычных базах данных, с той лишь разницей, что добавляется еще и время (которое обычно представляется в виде целочисленного значения, обозначающего количество секунд с начала эпохи). Изначально оно задумывалось для предоставления возможности отследить историю изменения данных, но этому дополнительному измерению можно найти и массу нестандартных применений, например используя его как самый обыкновенный стек.

Хочется обратить внимание, что ассортимент наборов столбцов (column family) указывается при создании таблиц, и изменения в них должны производиться с помощью специального запроса, в то время как сами столбцы являются динамическими и для его создания достаточно лишь добавить в него данные.

sparse

Развивая мысль предыдущего абзаца, можно понять, что наличие значения столбца в каждой строке вовсе не обязательно, оно запросто может и отсутствовать вовсе. Таким образом каждая строка может содержать произвольное количество значений для столбцов в рамках одной column family, ровно как может и не содержать их вовсе. Несуществующие данные не хранятся в виде какого-либо NULL-значения, они просто отсутствуют. Запрос на несуществующие данные просто вернет пустой результат. Если же взглянуть с другой стороны, то тот же самый факт можно представить и как возможность наличия пробелов в списке ключей строк.

И напоследок...

хочется сказать, что все это лишь дело терминологии, ровно то же самое можно подразумевать и под краткой фразой "нереляционная база данных", не смотря на то, что она существенно менее точна и полноценна. В данном контексте самое главное лишь чтобы люди просто понимали друг друга. Надеюсь после прочтения этого поста в вашем сознании сложилась четкая картина этого продукта и предоставляемых им возможностей, которая Вам пригодится как для "общего развития", так и для потенциального практического применения этого продукта. Если остались неясные моменты - смело оставляйте комментарии. Традиционная подписка на RSS - приветствуется :)

Hadoop возвращается

Иван Блинков — Sun, 17 Aug 2008 23:15:00 +0400

Если Вы являетесь постоянным читателем моего блога, то вполне вероятно, что Вы помните мой старый пост об этом замечательном проекте от Apache Foundation. С тех пор он развивался невероятными темпами и очень многое успело измениться, об этом я и хотел бы сегодня поделиться своими впечатлениями. В дополнение к этому планируется небольшая инструкция по развертыванию Hadoop на кластере из большого количества машин, который послужит неплохим развитием темы, начатой в посте "Hadoop для разработчика".

Что нового?

Для начала вкратце напомню что их себя представляет данный продукт, всего в нем три компонента:

HDFS: кластерная файловая система.
MapReduce framework: программная основа для построения приложений, работающих по одноименной модели.
HBase: нереляционная база данных.

Повторно повторяться смысла не вижу, все уже давно разложено по полочкам. Так что сразу перейдем к глобальным изменениям в проекте, произошедшим с написания вышеупомянутого поста, то есть с февраля. Сразу хочу сказать, что подробно пересказывать release notes у меня нет никакого желания, если Вам интересны все подробности о каждом bugfix'е или изменении в API, то имеет смысл почитать их в оригинале.

Наиболее значительным событием в развитии Apache Hadoop было, пожалуй, отделение HBase в отдельный проект. Какие же это повлекло последствия? С точки зрения простого смертного наиболее заметен тот факт, что HBase пропал из основного архива или репозитория Hadoop и его теперь нужно качать отдельно :) На самом же деле такое обособление лишь ускорило ее развитие, совсем недавно HBase отпраздновала свой релиз версии 0.2.0, включающий в себя массу нововведений и исправленных проблем, например язык запросов HQL был полностью заменен на jirb/jython shell, а также было добавлено кэширование данных в памяти. Помимо этого сильно изменилось API, очень рекомендую заглянуть в javadoc проекта, если Вас это интересует.

На уровне файловой системы наиболее значительным изменением стало добавление еще одного типа узлов - Secondary NameNode. Это нововведение является первым шагом на пути к устранению узких мест в системе (так называемых single points of failure). Название этого типа узлов говорит само за себя: они подстраховывают основной NameNode на случай непредвиденных сбоев. Они создают резервную копию образа метаданных файловой системы и лога транзакций (то есть всех операций с файлами и директориями в HDFS) и периодически ее обновляют. Полноценного автоматического восстановления системы они в случае сбоя на сервере с NameNode они на данный момент не обеспечивают, но сохранность данных на случай, скажем, разрушившегося RAID обеспечить могут.

MapReduce framework тоже несомненно развивается и дорабатывается, но каких-либо особо выдающихся изменений в нем не произошло: появляются дополнительные возможности, исправляются ошибки, снимаются те или иные ограничения. В общем все идет своим чередом.

Поднимаем кластер

ВНИМАНИЕ!

Перед продолжением чтения этого раздела, настоятельно рекомендуется прочитать статью о запуске псевдо-кластера из одного компьютера.

Для начала нам понадобится некоторое количество компьютеров (хотя если у Вас серьезные намерения, то лучше все же гордо называть их серверами, а для "побаловаться" сойдут и обычные рабочие станции с Linux). Конкретное количество на самом деле роли не играет, продолжать можно как с 2 серверами, так и с 20 тысячами (по крайней мере теоретически). Хотя пару рекомендаций все же могу дать: при использовании в "боевых" условиях стоит стараться избегать физического совмещения мастер-узлов компонентов системы (NameNode, JobTracker, HMaster) с "рядовыми" серверами, таким образом желательно начинать с, как минимум, 5-7 серверов.

Удостоверившись, что на всем оборудовании установлен какой-нибудь дистрибутив Linux или Unix (любители особо поизвращаться могут попытать счастья с "окнами" в совокупности с Cygwin) и 5 или 6 версия JRE/JDK (желательно от Sun), можно приступать к настройке каждого узла по тому же принципу, что и для псевдо-кластера (да-да, предупреждение в начале раздела было написано не для мебели). Кстати не забудьте, что HBasе теперь нужно скачивать отдельно. О небольших присутствующих особенностях я расскажу чуть позже, а пока дам маленький совет, который позволит несколько облегчить это непростое дело.

Вручную выполнять одни и те же операции на паре десятков/сотен/тысяч серверов мало того что долго, но и чрезвычайно утомительно. Уже на втором-третьем сервере начнет появляться желание каким-либо образом автоматизировать процесс установки. Конечно же можно воспользоваться специализированным программным обеспечением, скажем gexec, но есть и более простой способ: существенно упростить жизнь может простой скрипт на bash в 5 строчек:

#!/bin/bash
for x in `cat ~/nodes`
do
ssh hadoop@$x $1
done

В файле ~/nodes должен располагаться список IP-адресов всех серверов, тогда получив первым параметром произвольную консольную команду скрипт выполнит ее на каждом сервере. С его помощью можно существенно сократить время, требуемое на выполнение всех необходимых действий для запуска кластера.

После небольшого лирического отступления вернемся собственно к Hadoop. Как Вы уже, надеюсь, знаете, система использует ssh для управления всеми компонентами системы, причем очень желателен беспарольный доступ между всеми узлами. Для этого необходимо собрать в один файл все публичные ключи ~/.ssh/id_rsa.pub на каждом из узлов (по одному на строчку) и разместить его под именем ~/.ssh/authorized_keys тоже на каждом из узлов. Кстати для упоминавшегося выше скрипта беспарольный доступ тоже очень желателен.

Следующим этапом нужно подготовить конфигурационные файлы, они должны быть идентичными на всех узлах, так что заполнив их все на одном из узлов нужно скопировать их по всем остальным серверам (очень удобно делать это с помощью rsync). Теперь пройдемся по необходимым изменениям в каждом из них:

hadoop-site.xml

<property>
  <name>fs.default.name</name>
  <value>hdfs://namenode:54310</value>
  <description>
    The name of the default file system.  A URI whose
    scheme and authority determine the FileSystem implementation.  The
    uri's scheme determines the config property (fs.SCHEME.impl) naming
    the FileSystem implementation class.  The uri's authority is used to
    determine the host, port, etc. for a filesystem.
  </description>
</property>
<property>
  <name>mapred.job.tracker</name>
  <value>jobtracker:54311</value>
  <description>
    The host and port that the MapReduce job tracker runs
    at.  If "local", then jobs are run in-process as a single map
    and reduce task.
  </description>
</property>

Каждый сервер должен знать где расположен NameNode, по-этому он явно указывается в полном пути к файловой системе, практически аналогичная ситуация и с JobTracker. Вместо namenode и jobtracker необходимо указать их IP-адреса или доменные имена (или в крайнем случае - имя в /etc/hosts)

masters

Вопреки логике, здесь указывается список всех SecondaryNameNode. Одного-двух серверов здесь будет вполне достаточно, самое главное не указывать здесь адрес основного NameNode, лучше всего подойдет какой-нибудь другой мастер-сервер, может быть дополненный одним из обычных узлов кластера. Выделять под это отдельный сервер смысла не много, так как нагрузка на них минимальна.

slaves

Список всех рядовых серверов, по одному на строку (опять же: IP или доменное имя). На них будут запущенны DataNode и TaskTracker.

hbase-site.xml

<property>
  <name>hbase.master</name>
  <value>localhost:60000</value>
  <description>
    the host and port that the HBase master runs at
  </description>
</property>

Первое изменение достаточно очевидно: HRegionServer должны знать где находится HMaster, о чем им и сообщает первое свойство (заменяем hmaster на соответствующий адрес). А вот второе свойство является следствием "обособления" HBase от Hadoop, о котором шла речь ранее. Теперь имеется возможность использовать их отдельно (с локальной файловой системой вместо HDFS), а так как появился выбор файловой системы - ее адрес необходимо указывать полностью. В данном случае указан адрес HDFS (такой же как в hadoop-site.xml).

regionservers

Вполне очевидный конфигурационный файл, по аналогии со slaves, заполняется списком адресов для запуска HRegionServer. Часто совпадает с упомянутым slaves, обычно достаточно просто скопировать.

Запуск

Удостоверившись, что с конфигурационными файлами все нормально и что они на всех серверах совпадают, можно приступать собственно к запуску. Этот процесс практически полностью совпадает с запуском на одном узле, хотя обычно проще желать это тоже простеньким скриптом примерно такого вида:

#!/bin/bash
ssh hadoop@namenode ~/hadoop/bin/start-dfs.sh
ssh hadoop@jobtracker ~/hadoop/bin/start-mapred.sh
ssh hadoop@hmaster ~/hbase/bin/start-hbase.sh

Если мы нигде не ошиблись и все сделано правильно, то кластер благополучно запустится, что легко проследить выполнив на каждом узле команду jps и проверив соответствие запущенных компонентов запланированному (читай: указанному в конфигурационных файлах).

В целом процесс достаточно прост и не занимает много времени, если Вы все же столкнулись с какими-либо проблемами в процессе - обращайтесь, вполне возможно, что я смогу помочь. Удостовериться, что все нормально можно абсолютно так же, как и для псевдо-кластера - с помощью MapReduce задач, идущих в комплекте с Hadoop. Выглядеть это может, например, вот так:

$ ~/hadoop/bin/hadoop jar hadoop-*-examples.jar pi 4 10000

По-хорошему надо было бы написать подобную инструкцию сразу после первой, но почему-то как-то не сложилось...

Заключение

На данный момент Hadoop стал еще более работоспособным, по сравнению с его февральским состоянием. Сообщество использующих его разработчиков растет с каждым днем, а все ошибки и проблемы исправляются очень и очень оперативно, многие коммерческие проекты могут позавидовать таким темпам развития. Хоть до по-настоящему стабильного релиза еще далеко, данный продукт уже сейчас очень активно используется в достаточно большом количестве крупных интернет-проектов.

Если Вы еще не успели подписаться на RSS - сейчас самое время!

Hypertable

Иван Блинков — Sat, 05 Apr 2008 20:27:00 +0400

Hypertable является еще одним opensource проектом, направленным на воспроизведение функционала BigTable от Google. Поставленная перед проектом цель заключается в реализации системы хранения данных на базе распределенной файловой системы, позволяющей перейти на новый уровень производительности при работе с гигантскими объемами данных.

Принцип работы Hypertable прост до безобразия:

Hypertable хранит данные в табличном формате, сортируя записи по основному ключу;
для хранимых данных не используются какие-либо типы данных, любая ячейка интерпретируется как байтовая строка;
масштабируемость достигается путем разбиения таблиц на смежные интервалы строк и хранения их на разных физических машинах;
в системе используется два типа серверов:

Master Server

– как и во многих других подобных системах мастер-сервер выполняет обязанности скорее административного характера: он управляет работой Range серверов, работает с метаданными (которые хранятся просто в отдельной таблице, наравне с остальными).

Range Server

– их задача стоит в собственно в хранении диапазонов строк из различных таблиц. Каждый сервер может хранить несколько несмежных диапазонов строк, если диапазон превышает по объему определенный лимит (по-умолчанию - 200 MB), то он разбивается на пополам и одна половина обычно перемещяется на другой сервер. Если же на одном из серверов подходит к концу дисковое пространство, то под руководством мастер-сервера часть диапазонов с него перераспределяется на менее загруженные Range серверы.
Еще одним компонентом системы является Hyperspace, этот сервер предоставляет указатель на основную таблицу с метаданными, а также пространство имен. Помимо этого этот сервис выступает в роли lock-механизма для клиентов системы.

В качестве основы для этой системы может использоваться как входящая в состав Hadoop файловая система HDFS, так и KosmosFS, о которой я недавно рассказывал. Это позволяет Hypertable выступать в роли конкурента для HBase в рамках проекта Hadoop.

HBase и Hypertable выполняют достаточно похожие функции и преследуют практически одни и те же цели, но есть некоторые ньюансы. Одним из глобальных различий в этих системах является языки программирования, с использованием которого они реализованы. HBase написана на Java, в то время как разработчики Hypertable предпочли C++. Это повлекло за собой массу различий в инкапсулированной реализации различных операций.

Для доступа к данным каждая из систем использует язык HQL, только в одном случае аббревиатура расшифровывается как HBase Query Language, а в другом - Hypertable Query Language (как эгоистично :) ). По сути и то и другое является сильно упрощенным диалектом SQL, что позволяет сократить знакомство с синтаксисом HQL до пары минут при достаточном знании классического SQL. Хотелось бы отметить, что вся простота в сравнении с классическим SQL и реляционными СУБД вполне обоснована: обе системы хранения данных предназначены для использования в совокупности с MapReduce программами, что делает их просто хранилищем данных, а не средством их обработки.

После небольшого лирического отступления в виде сравнения с HBase хотелось бы все же вернуться к теме нашего разговора, а именно к организации хранения данных в Hypertable. Данные хранятся в виде пар ключ:значение, причем храняться все версии строк с указанием времени, когда они были созданы. Таким образом легко проследить за процессом изменения данных во времени, а также узнать какие именно операции проводились над ними в прошлом. Стандартный механизм работы с версиями данных может быть переопределен на хранения лишь фиксированного количества версий строки, позволяя использовать удаление устаревших записей для освобождения дополнительного дискового пространства.

Для более эффективной работы с обновлением случайных ячеек таблиц используется кэширование. Поступающие данные собираются в оперативной памяти и при достижении определенного лимита сжимаются и записываются на диск.

Для более эффективной работы с распределенной файловой системой используется механизм под названием Access Groups. Суть заключается в объединении колонок таблиц в группы, в которых они чаще всего используется вместе. Такие группы данных по возможности храняться вместе на физических носителях. Если запрос включает в себя только данные из колонок одной группы доступа, то с дисков считывается только эти колонки, в противном случае приходиться работать со всей строкой целиком. Такой подход позволяет существенно оптимизировать работу операций ввода/вывода.

Проект еще находится в стадии разработки и до стабильного релиза ему еще далеко, но тем не менее он уже вполне может себя показать в качестве конкурента как для других систем подобного класса, так и для более стандартных реляционных баз данных. Основными недостающими моментами в этой системе в данной системе является отсутствие некоторого порой необходимого функционала в HQL, а такжы некоторые проблемы с отказоустойчивостью, вызванные единственностью в рамках системы Master и Hyperspace серверов.

Файлы в космосе

Иван Блинков — Sun, 30 Mar 2008 23:06:00 +0400

...или Kosmos Distributed File System

Сегодня речь пойдет об еще одной распределенной файловой системе - KosmosFS. У русских людей название этого проекта определенно вызывает ассоциации с космосом, но изначально все же свою лепту в него внес изначальный разработчик - Kosmix. По большому счету KFS мало чем выделяется из множества своих конкурентов, по своей структуре она состоит из сервера метаданных и серверов блоков, доступ к системе производится средствами клиентской библиотеки, предоставляющей соответствующий API. Список возможностей файловой системы также вполне стандартен:

Инкрементальная масштабируемость. При добавлении дополнительных узлов в кластер, система сама адаптируется для вовлечения их в полноценную работу.
Стабильный доступ. Реплицируемость данных (по-умолчанию в трех экземплярах) позволяет гарантировать доступность данных вне зависимости от сбоев в работе отдельных узлов.
Балансировка блоков данных. Периодически сервер метаданных перераспределяет данные с целью более оптимального использования дискового пространства.
Целостность данных. Для обеспечения целостности данных вычисляются и сравниваются контрольные суммы блоков данных.
Кэширование. Для увеличения производительности используется кэширования на уровне клиентской библиотеки.
Прозрачная работа с недоступными узлами. Клиентская библиотека прозрачно для приложения переключается на альтернативный сервер с данными, если обнаруживает что один из них недоступен.
Поддержка языков программирования: C++, Java, Python.
Скрипты. С системой предоставляется набор скриптов для развертывания, запуска и остановки узлов.

Но написать этот пост меня подтолкнул вовсе не этот список. В комментариях к одной из предыдущих моих записей читатели подняли тему о целесообразности использования Java для реализации HDFS в частности и Hadoop в целом. В качестве альтернативы был предложен C++ (только на словах конечно же), аргументируя это тем, что такая реализация была бы эффективнее. KFS же как раз и является той самой альтернативой HDFS, написанной на C++. KFS тесно интегрируется с Hadoop с помощью его интерфейсов для файловой системы. Это позволяет Hadoop-приложениям незаметно работать с KFS точно так же, как если бы на ее месте была бы HDFS. Код для интеграции с Hadoop был выпущен в виде патча к Hadoop-JIRA-1963, а начиная с Hadoop версии 0.15 этот код входит в стандартный дистрибутив, ровно как и детальная инструкция по интеграции.

Hadoop для разработчика

Иван Блинков — Tue, 26 Feb 2008 00:15:00 +0300

Для разработки приложений, работающих с использованием Hadoop, или же алгоритмов для MapReduce framework'а совсем не нужен полномасштабный кластер. На самом же деле для запуска всей системы, описанной мной в одном из предыдущих постов, вполне достаточно одного компьютера и буквально минут 15 свободного времени, как потратить их для решения этой задачи я Вам и поведаю. Рассказывать я буду на примере своего Gentoo Linux, но большая часть этого повествования будет справедлива и для других unix-like операционных систем.

Подготовка

Перед тем, как приступить собственно говоря к установке Hadoop, необходимо выполнить два элементарных действия, необходимых для правильного функционирования системы:

открыть доступ одному из пользователей по ssh к этому же компьютеру без пароля, можно например создать отдельного пользователя для этого hadoop:
```
$$ useradd -m -n hadoop
```
Далее действия выполняем от его имени:
```
$$ su hadoop
```
Генерируем RSA-ключ для обеспечения аутентификации в условиях отсутствия возможности использовать пароль:
```
$$ hadoop@localhost ~ $ ssh-keygen -t rsa -P ""
Generating public/private rsa key pair.
Enter file in which to save the key (/home/hadoop/.ssh/id_rsa):
Your identification has been saved in /home/hadoop/.ssh/id_rsa.
Your public key has been saved in /home/hadoop/.ssh/id_rsa.pub.
The key fingerprint is:
7b:5c:cf:79:6b:93:d6:d6:8d:41:e3:a6:9d:04:f9:85 hadoop@localhost
```
И добавляем его в список авторизованных ключей:
```
$$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
```
Этого должно быть более чем достаточно, проверить работоспособность соединения можно просто написав:
```
$$ ssh localhost
```
Не забываем предварительно инициализировать sshd:
```
$$ /etc/init.d/sshd start
```
Помимо этого необходимо убедиться в наличии установленной JVM версии 1.5.0 или выше, а также узнать директорию, где она располагается, вариантов сделать это множество, я нашел ее просто заглянув в самое логичное место - /usr/lib, но при желании никто не может Вам помешать воспользоваться услугами, например, slocate. Найденную директорию с JVM лучше запомнить или записать куда-нибудь, для меня она оказалась: /usr/lib/jvm/sun-jdk-1.6

Установка

Установка начинается с получения копии исходного кода системы, способов для этого существует несколько. Я перепробовал практически все, самую адекватную версию мне удалось получить из SVN. Для ее получения необходимо выполнить следующую команду:

$ svn checkout http://svn.apache.org/repos/asf/hadoop/core/branches/branch-0.16 ~

branch-0.16 - последняя доступная версия на данный момент, для определения ее номера достаточно заглянуть по тому же адресу браузером. Предполагается, что Hadoop будет располагаться прямо в /home/hadoop, но запросто можно использовать и другую директорию.

Сразу же стоит скомпилировать различные дополнительные компоненты системы, особенно это актуально из-за HBase, но и помимо него соберется много чего интересного, например plug-in для отличной IDE под названием Eclipse или Hadoop On Demand. Задача также элементарна:

$ cd ~ && ant clean jar compile-contrib

Настройка

Конфигурационные файлы можно редактировать в произвольном порядке, самое главное ничего не забыть :)

conf/hadoop-env.sh

export JAVA_HOME=/usr/lib/jvm/sun-jdk-1.6

Единственная обязательная переменная окружения - JAVA_HOME, здесь как раз пригодится заранее найденный путь до JVM, все остальное - по желанию.

conf/hadoop-site.xml

<property>
  <name>hadoop.tmp.dir</name>
  <value>/home/hadoop/data/${user.name}</value>
  <description>A base for other temporary directories.</description>
</property>
<property>
  <name>fs.default.name</name>
  <value>hdfs://localhost:54310</value>
  <description>The name of the default file system.  A URI whose
  scheme and authority determine the FileSystem implementation.  The
  uri's scheme determines the config property (fs.SCHEME.impl) naming
  the FileSystem implementation class.  The uri's authority is used to
  determine the host, port, etc. for a filesystem.</description>
</property>
<property>
  <name>mapred.job.tracker</name>
  <value>localhost:54311</value>
  <description>The host and port that the MapReduce job tracker runs
  at.  If "local", then jobs are run in-process as a single map
  and reduce task.
  </description>
</property>
<property>
  <name>dfs.replication</name>
  <value>1</value>
  <description>Default block replication.
  The actual number of replications can be specified when the file is created.
  The default is used if replication is not specified in create time.
  </description>
</property>

Этот конфигурации файл является одним из ключевых, таким образом он выглядит для конфигурации, состоящей из одного компьютера (позаимствован из англоязычного мануала на ту же тему).

src/contrib/hbase/conf/hbase-site.xml

<property>
  <name>hbase.master</name>
  <value>localhost:60000</value>
  <description>The host and port that the HBase master runs at</description>
</property>
<property>
  <name>hbase.rootdir</name>
  <value>/hbase</value>
  <description>location of HBase instance in dfs</description>
</property>

Как не сложно заметить, этот файл необходим для функционирования HBase, по-моему все просто и очевидно, <description> говорят сами за себя.

Запуск

Начать стоит с ознакомления с кратким описанием доступных команд Hadoop, сделать это можно просто набрав ~/bin/hadoop:

Usage: hadoop [--config confdir] COMMAND
where COMMAND is one of:
  namenode -format     format the DFS filesystem
  secondarynamenode    run the DFS secondary namenode
  namenode             run the DFS namenode
  datanode             run a DFS datanode
  dfsadmin             run a DFS admin client
  fsck                 run a DFS filesystem checking utility
  fs                   run a generic filesystem user client
  balancer             run a cluster balancing utility
  jobtracker           run the MapReduce job Tracker node
  pipes                run a Pipes job
  tasktracker          run a MapReduce task Tracker node
  job                  manipulate MapReduce jobs
  version              print the version
  jar             run a jar file
  distcp   copy file or directories recursively
  daemonlog            get/set the log level for each daemon
 or
  CLASSNAME            run the class named CLASSNAME
Most commands print help when invoked w/o parameters.

Первым делом необходимо отформатировать Namenode:

$ ~/bin/hadoop namenode -format

И дело останется лишь за малым, запустить на выполнение пару bash-скриптов, которые без вашего дальнейшего участия инициализируют всю систему, включая HBase:

$ ~/bin/hadoop/start-all.sh && ~/src/contrib/hbase/bin/start-hbase.sh

Как только они закончат все необходимые действия, у Вас появится возможность удостовериться, что все в порядке. Самым простым способом является запуск клиента Hbase Shell:

$ ~/bin/src/contrib/hbase/bin/hbase shell

Если в ответ Вы получили соответствующее приглашение клиента, значит все было сделано верно!

Вот собственно говоря и все, псевдо-кластер функционирует, доступ к HBase имеется, можно приступать к разработке :)

P.S.: Остановка системы производится по тому же принципу скриптами stop-all.sh и stop-hbase.sh.

Hadoop

Иван Блинков — Fri, 22 Feb 2008 22:41:00 +0300

Hadoop представляет собой платформу для построения приложений, способных обрабатывать огромные объемы данных. Система основывается на распределенном подходе к вычислениям и хранению информации, основными ее особенностями являются:

Масштабируемость: с помощью Hadoop возможно надежное хранение и обработка огромных объемов данных, которые могут измеряться петабайтами;
Экономичность: информация и вычисления распределяются по кластеру, построенному на самом обыкновенном оборудовании. Такой кластер может состоять из тысяч узлов;
Эффективность: распределение данных позволяет выполнять их обработку параллельно на множестве компьютеров, что существенно ускоряет этот процесс;
Надежность: при хранении данных возможно предоставление избыточности, благодаря хранению нескольких копий. Такой подход позволяет гарантировать отсутствие потерь информации в случае сбоев в работе системы;
Кроссплатформенность: так как основным языком программирования, используемым в этой системе является Java, развернуть ее можно на базе любой операционной системы, имеющей JVM.

HDFS

В основе всей системы лежит распределенная файловая система под незамысловатым названием Hadoop Distributed File System. Представляет она собой вполне стандартную распределенную файловую систему, но все же она обладает рядом особенностей:

Устойчивость к сбоям, разработчики рассматривали сбои в оборудовании скорее как норму, чем как исключение;
Приспособленность к развертке на самом обыкновенном ненадежном оборудовании;
Предоставление высокоскоростного потокового доступа ко всем данным;
Настроена для работы с большими файлами и наборами файлов;
Простая модель работы с данными: один раз записали - много раз прочли;
Следование принципу: переместить вычисления проще, чем переместить данные;

Архитектура HDFS

Проще всего ее демонстрирует схема, позаимствованная с официального сайта проекта и переведенная мной на руский:

Действующие лица:

Namenode: Этот компонент системы осуществляет всю работу с метаданными. Он должен быть запущен только на одном компьютере в кластере. Именно он управляет размещением информации и доступом ко всем данным, расположенным на ресурсах кластера. Сами данные проходят с остальных машин кластера к клиенту мимо него.
Datanode: На всех остальных компьютерах системы работает именно этот компонент. Он располагает сами блоки данных в локальной файловой системе для последующей передачи или обработки их по запросу клиента. Группы узлов данных принято называть Rack, они используются, например, в схемах репликации данных.
Клиент: Просто приложение или пользователь, работающий с файловой системой. В его роли может выступать практически что угодно.

Пространство имен HDFS имеет классическую иерархическую структуру: пользователи и приложения имеют возможность создавать директории и файлы. Файлы хранятся в виде блоков данных произвольной (но одинаковой, за исключением последнего; по-умолчанию 64 mb) длины, размещенных на Datanode'ах. Для обеспечения отказоустойчивости блоки хранятся в нескольких экземплярах на разных узлах, имеется возможность настройки количества копий и алгоритма их распределения по системе. Удаление файлов происходит не сразу, а через какое-то время после соответствующего запроса, так как после получения запроса файл перемещается в директорию /trash и хранится там определенный период времени на случай если пользователь или приложение передумают о своем решении. В этом случае информацию можно будет восстановить, в противном случае - физически удалить.

Для обнаружения возникновения каких-либо неисправностей, Datanode периодически отправляют Namenode'у сигналы о своей работоспособности. При прекращении получения таких сигналов от одного из узлов Namenode помечает его как "мертвый", и прекращает какой-либо с ним взаимодействие до возвращения его работоспособности. Данные, хранившиеся на "умершем" узле реплицируются дополнительный раз из оставшихся "в живых" копий и система продолжает свое функционирование как ни в чем не бывало.

Все коммуникации между компонентами файловой системы проходят по специальным протоколам, основывающимся на стандартном TCP/IP. Клиенты работают с Namenode с помощью так называемого ClientProtocol, а передача данных происходит по DatanodeProtocol, оба они обернуты в Remote Procedure Call (RPC).

Система предоставляет несколько интерфейсов, среди которых командная оболочка DFSShell, набор ПО для администрирования DFSAdmin, а также простой, но эффективный веб-интерфейс. Помимо этого существуют несколько API для языков программирования: Java API, C pipeline, WebDAV и так далее.

MapReduce

Помимо файловой системы, Hadoop включает в себя framework для проведения масштабных вычислений, обрабатывающих огромные объемы данных. Каждое такое вычисление называется Job (задание) и состоит оно, как видно из названия, из двух этапов:

Map: Целью этого этапа является представление произвольных данных (на практике чаще всего просто пары ключ-значение) в виде промежуточных пар ключ-значение. Результаты сортируются и групируются по ключу и передаются на следующий этап.
Reduce: Полученные после map значения используются для финального вычисления требуемых данных. Практические любые данные могут быть получены таким образом, все зависит от требований и функционала приложения.

Задания выполняются, подобно файловой системе, на всех машинах в кластере (чаще всего одних и тех же). Одна из них выполняет роль управления работой остальных - JobTracker, остальные же ее бесприкословно слушаются - TaskTracker. В задачи JobTracker'а входит составление расписания выполняемых работ, наблюдение за ходом выполнения, и перераспределение в случае возникновения сбоев.

В общем случае каждое приложение, работающее с этим framework'ом, предоставляет методы для осуществления этапов map и reduce, а также указывает расположения входных и выходных данных. После получения этих данных JobTracker распределяет задание между остальными машинами и предоставляет клиенту полную информацию о ходе работ.

Помимо основных вычислений могут выполняться вспомогательные процессы, такие как составление отчетов о ходе работы, кэширование, сортировка и так далее.

HBase

В рамках Hadoop доступна еще и система хранения данных, которую правда сложно назвать СУБД в традиционном смысле этого слова. Чаще проводят аналогии с проприетарной системой этого же плана от Google - BigTable.

HBase представляет собой распределенную систему хранения больших объемов данных. Подобно реляционным СУБД данные хранятся в виде таблиц, состоящих из строк и столбцов. И даже для доступа к ним предоставляется язык запросов HQL (как ни странно - Hadoop Query Language), отдаленно напоминающий более распространенный SQL. Помимо этого предоставляется итерирующмй интерфейс для сканирования наборов строк.

Одной из основных особенностей хранения данных в HBase является возможность наличия нескольких значений, соответствующих одной комбинации таблица-строка-столбец, для их различения используется информация о времени добавления записи. На концептуальном уровне таблицы обычно представляют как набор строк, но физически же они хранятся по столбцам, достаточно важный факт, который стоит учитывать при разработки схемы хранения данных. Пустые ячейки не отображаются каким-либо образом физически в хранимых данных, они просто отсутствуют. Существуют конечно и другие нюансы, но я постарался упомянуть лишь основные.

HQL очень прост по своей сути, если Вы уже знаете SQL, то для изучения его Вам понадобится лишь просмотреть по диагонали коротенький вывод команды help;, занимающий всего пару экранов в консоли. Все те же SELECT, INSERT, UPDATE, DROP и так далее, лишь со слегка измененным синтаксисом.

Помимо обычно командной оболочки HBase Shell, для работы с HBase также предоставлено несколько API для различных языков программирования:

Заключение

Hadoop является отличным решением для построения высоконагруженных приложений, которое уже активно используется множеством интернет-проектов. В последующих постах на эту тему я постараюсь описать процесс развертывания этой системы и написания приложений, работающих по принципу MapReduce. Не пропустить момент их публикации Вам может помочь подписка на RSS-ленту.