Цели сервиса

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

Используемая в Cassandra логика целостности данных оказалась не достаточно строгой для использования в этом продукте. В Facebook широко используется MySQL, но производительность существенно снижается с ростом массива данных и увеличением размеров индексов. Возможно они взялись бы за разработку нового решения для этой задачи, но их выбор пал на HBase.

HBase представляет собой горизонтально масштабируемую систему хранения таблиц, поддерживающую высокую частоту обновления строк в массивных наборах данных. Звучит как то что надо, для построения новой системы сообщений в Facebook. В основе модели данных HBase лежит концепция BigTable от Google, которая хорошо подходит для поиска строк по идентификаторам, фильтрации и сканированию наборов строк. Из слабых сторон можно назвать отсутствию поддержки сложных запросов, но этот факт компенсируется широким спектром инструментов по аналитике, в том числе и Hive, разработанном в самом Facebook для работы с их многопетабайтным хранилищем данных. Помимо прочего HBase основана на Apache Hadoop и HDFS, с которыми Facebook и так активно работает для анализа данных.

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

• Небольшой нестабильный набор временных данных
• Постоянно растущий архив информации, который очень редко используется

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

HBase:

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

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

Для сбора сообщений из различных источников используется собственный сервер приложений.

Поиск новых пользователей основан на ZooKeeper.

Продукт тесно с другими сервисами Facebook для:

• Проверка адресов электронной почты
• Определения отношений дружбы
• Настроек приватности
• Решений о транспорте для отправки сообщения (e-mail, SMS, внутреннее сообщение)

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

Хочется добавить пару слов от себя: я имел довольно приличный опыт работы с HBase в (уже) далеком 2008 году, на тот момент HBase был самым нестабильным из всех проектов, составляющих экосистему Hadoop. На бумаге HBase и правда выглядит идеальным решением для многих задач, но малейший сбой в метаданных делал всю базу данных неработоспособной, а таковое случалось достаточно часто, обычно по вине HDFS. В том проекте было убито массу времени на попытки «нормализовать» работу связки Hadoop+HBase, но в итоге от последней пришлось отказаться. Очень рад, что этот проект развивается такими семимильными шагами, задумка у проекта изначально была и правда очень стоящая. HBase буквально за пару лет стал пригоден для production использования, да еще и на таком масштабе.  Пройдет еще год-другой, кардинально изменится архитектура Hadoop в лучшую сторону, и HBase наверняка станет лучшей из распределенных систем хранения структурированных данных, доступных на рынке. Если, конечно, Google к тому времени не успеет опубликовать в opensource её прародителя, BigTable

А Вы как относитесь к HBase? Использовали ли на практике? Какие впечатления?

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

• Facebook’s New Real-Time Messaging System: HBase To Store 135+ Billion Messages A Month
• The Underlying Technology of Messages
• See The Messages That Matter
• Facebook Messaging — HBase Comes of Agо

В далеком 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, с удовольствием пообщаюсь со всеми читателями

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