Insight IT

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 серверов.

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-ленту.