Цели сервиса

• Дать пользователям надежные счетчики в реальном времени по ряду метрик
• Предоставлять анонимные данных — нельзя узнать кто конкретно были эти люди
• Продемонстрировать ценность социальных плагинов и виджетов. Что они дают сайту или бизнесу?
• Концепция воронки: сколько людей увидело плагин, сколько совершило действие, сколько было привлечено пользователей обратно на интернет-ресурс
• Сделать данные более оперативными: сокращение частоты обновлений с 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 из-за её простой схемы масштабирования, поддержку нескольких датацентров и легкость в использовании. Какой путь окажется выигрышным — покажет время.

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

• Facebook’s New Realtime Analytics System: HBase To Process 20 Billion Events Per Day
• Building Realtime Insights (видео)

В далеком 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.

Платформа

• Apache + mod_proxy
• Unicorn
• Ruby + Ruby on Rails
• Scala
• Flock
• memcached
• Kestrel
• MySQL
• Cassandra
• Scribe
• Hadoop, HBase и Pig

Сравните с аналогичным разделом предыдущей статьи о 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 столкнулась с потолком масштабируемости на уровне около 4000 машин в кластере. Разрабатывается следующее поколение Apaсhe Hadoop MapReduce,  в котором появится общий планировщик ресурсов и отдельный мастер для каждой отдельной задач, управляющий выполнением программного кода. Так как простой оборудования по техническим причинам обходится дорого на таком масштабе, высокий уровень доступности проектируется с самого начала, ровно как и безопасность и многозадачность, необходимые для поддержки одновременного использования большого кластера многими пользователями. Новая архитектура также будет более инновационной, гибкой и эффективной с точки зрения использования вычислительных ресурсов.

Предыстория

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

Требования

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

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

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

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

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

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

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

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

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 путь его переработки направлен на исправление недостатков архитектуры текущей реализации, при этом повышая доступность, эффективность использования ресурсов и предоставляя поддержку других парадигм распределенных вычислений.

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

Источник информации: http://developer.yahoo.com/blogs/hadoop/posts/2011/02/mapreduce-nextgen/

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

Стоит напомнить, что проект позиционируется как 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 — приветствуется

Что нового?

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

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

  fs.default.name
  hdfs://namenode:54310
  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.


  mapred.job.tracker
  jobtracker:54311
  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.
  

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

masters

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

slaves

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

hbase-site.xml

     hbase.master
     hmaster:60000
     The host and port that the HBase master runs at
   

     hbase.rootdir
     hdfs://namenode/hbase
     location of HBase instance in dfs
   

Первое изменение достаточно очевидно: 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 стал еще более работоспособным, по сравнению с его февральским состоянием. Сообщество использующих его разработчиков растет с каждым днем, а все ошибки и проблемы исправляются очень и очень оперативно, многие коммерческие проекты могут позавидовать таким темпам развития. Хоть до по-настоящему стабильного релиза еще далеко, данный продукт уже сейчас очень активно используется в достаточно большом количестве крупных интернет-проектов.

На закуску небольшой бонус в виде моей небольшой вводной презентации об Apache Hadoop, правда слегка устаревшей (была подготовлена 1 июня 2008г.):

Apache Hadoop