Эта статья послужит практическим руководством по сборке, начальной настройке и тестированию работоспособности Hadoop начинающим администраторам. Мы разберем, как собрать Hadoop из исходников, сконфигурировать, запустить и проверить, что все работает, как надо. В статье вы не найдете теоретической части. Если вы раньше не сталкивались с Hadoop, не знаете из каких частей он состоит и как они взаимодействуют, вот пара полезных ссылок на официальную документацию:
hadoop.apache.org/docs/r2.7.3/hadoop-project-dist/hadoop-hdfs/HdfsDesign.html
hadoop.apache.org/docs/r2.7.3/hadoop-yarn/hadoop-yarn-site/YARN.html
Почему просто не использовать готовый дистрибутив?
— Обучение. Похожие статьи часто начинаются с рекомендаций скачать образ виртуальной машины с дистрибутивом Cloudera или HortonWorks. Как правило, дистрибутив – сложная экосистема с уймой компонент. Новичку будет непросто разобраться, где что, и как это все взаимодействует. Начиная from scratch мы немного уменьшаем порог вхождения, так как имеем возможность рассматривать компоненты по одной.
— Функциональные тесты и бенчмарки. Есть небольшой лаг между выходом новой версии продукта, и моментом, когда она появляется в дистрибутиве. Если вам необходимо протестировать новые функции только что появившейся версии, Вы не сможете использовать готовый дистрибутив. Также будет сложно сравнить производительность двух версий одного и того же софта, так как в готовых дистрибутивах как правило отсутствует возможность обновить версию какого-либо одного компонента, оставив все остальное как есть.
— Just for fun.
Почему собираем из исходников? Ведь бинарные сборки Hadoop также доступны.
Часть кода Hadoop написана на C/C++. Не знаю, на какой системе делает сборки команда разработчиков, но С-библиотеки, поставляемые вместе с бинарными сборками Hadoop, зависят от версии libc, которой нет ни в RHEL, ни в Debian/Ubuntu. Неработоспособность С-библиотек Hadoop в общем случае не критично, но некоторые фичи без них работать не будут.
Зачем заново описывать все то, что и так есть в официальной документации?
Статья призвана сэкономить время. Официальная документация не содержит quickstart-инструкций – делай так и оно заработает. Если вам по той или иной причине необходимо собрать “ванильный” Hadoop, но нет времени на то, чтоб делать это методом проб и ошибок, вы зашли по адресу.
Сборка
Для сборки будем использовать CentOS 7. Если верить Сloudera, большинство кластеров работают именно на RHEL и производных (CentOS, Oracle Linux). 7-я версия подходит больше всего, так как в ее репозиториях уже есть библиотека protobuf нужной версии. Если Вы хотите использовать CentOS 6, будет необходимо собрать protobuf самостоятельно.
Сборку и прочие эксперименты будем проводить с привилегиями root (чтоб не усложнять статью).
Где-то 95% кода Hadoop написано на Java. Для сборки нам понадобятся Oracle JDK и Maven.
Загружаем последнюю версию JDK с сайта Oracle и разархивируем в /opt. Так же добавим переменную JAVA_HOME (используется Hadoop) и добавим /opt/java/bin в PATH для пользователя root (для удобства):
cd ~
wget --no-check-certificate --no-cookies --header "Cookie: oraclelicense=accept-securebackup-cookie" http://download.oracle.com/otn-pub/java/jdk/8u112-b15/jdk-8u112-linux-x64.tar.gz
tar xvf ~/jdk-8u112-linux-x64.tar.gz
mv ~/jdk1.8.0_112 /opt/java
echo "PATH="/opt/java/bin:$PATH"" >> ~/.bashrc
echo "export JAVA_HOME="/opt/java"" >> ~/.bashrc Устанавливаем Мaven. Он будет необходим только на этапе сборки. По-этому установим его в наш home (после окончания сборки все файлы, которые останутся в home, можно будет удалить).
cd ~
wget http://apache.rediris.es/maven/maven-3/3.3.9/binaries/apache-maven-3.3.9-bin.tar.gz
tar xvf ~/apache-maven-3.3.9-bin.tar.gz
mv ~/apache-maven-3.3.9 ~/maven
echo "PATH="/root/maven/bin:$PATH"" >> ~/.bashrc
source ~/.bashrc Где-то 4-5% кода Hadoop написано на C/C++. Установим компилятор и прочие пакеты необходимые для сборки:
yum -y install gcc gcc-c++ autoconf automake libtool cmakeТакже нам понадобятся некоторые сторонние библиотеки:
yum -y install zlib-devel openssl openssl-devel snappy snappy-devel bzip2 bzip2-devel protobuf protobuf-devel Система готова. Скачиваем, собираем и устанавливаем Hadoop в /opt:
cd ~
wget http://apache.rediris.es/hadoop/common/hadoop-2.7.3/hadoop-2.7.3-src.tar.gz
tar -xvf ~/hadoop-2.7.3-src.tar.gz
mv ~/hadoop-2.7.3-src ~/hadoop-src
cd ~/hadoop-src
mvn package -Pdist,native -DskipTests -Dtar
tar -C/opt -xvf ~/hadoop-src/hadoop-dist/target/hadoop-2.7.3.tar.gz
mv /opt/hadoop-* /opt/hadoop
echo "PATH="/opt/hadoop/bin:$PATH"" >> ~/.bashrc
source ~/.bashrc Первичная конфигурация
Hadoop насчитывает около тысячи параметров. К счастью, чтобы запустить Hadoop и сделать некоторые первые шаги в освоении достаточно около 40, оставив остальное по умолчанию.
Приступим. Если помните, мы установили Hadoop в /opt/hadoop. Все конфигурационные файлы находятся в /opt/hadoop/etc/hadoop. В общей сложности потребуется отредактировать 6 конфигурационных файлов. Все конфиги ниже привожу в виде команд. Для того, чтобы те, кто пытается собрать свой Hadoop по этой статье, могли просто копипастить команды в консоль.
Во-первых, установим переменную окружения JAVA_HOME в файлах hadoop-env.sh и yarn-env.sh. Так мы дадим всем компонентам знать, где установлена java, которую они должны использовать.
sed -i '1iJAVA_HOME=/opt/java' /opt/hadoop/etc/hadoop/hadoop-env.sh
sed -i '1iJAVA_HOME=/opt/java' /opt/hadoop/etc/hadoop/yarn-env.sh Сконфигурируем URL для HDFS в файле core-site.xml. Он состоит из префикса hdfs://, имени хоста, на котором запущен NameNode и порта. Если этого не сделать, Hadoop не будет использовать распределенную файловую систему, а будет работать с локальной ФС на вашем компьютере (URL по умолчанию: file:///).
cat << EOF > /opt/hadoop/etc/hadoop/core-site.xml
<configuration>
<property><name>fs.defaultFS</name><value>hdfs://localhost:8020</value></property>
</configuration>
EOF В файле hdfs-site.xml конфигурируем 4 параметра. Количество реплик устанавливаем в 1, так как наш “кластер” состоит всего из одной ноды. Также конфигурируем директории, где будут хранить данные NameNode, DataNode и SecondaryNameNode.
cat << EOF > /opt/hadoop/etc/hadoop/hdfs-site.xml
<configuration>
<property><name>dfs.replication</name><value>1</value></property>
<property><name>dfs.namenode.name.dir</name><value>/data/dfs/nn</value></property>
<property><name>dfs.datanode.data.dir</name><value>/data/dfs/dn</value></property>
<property><name>dfs.namenode.checkpoint.dir</name><value>/data/dfs/snn</value></property>
</configuration>
EOFМы закончили настройку HDFS. Можно было бы запустить NameNode и DataNode, и поработать с ФС. Но оставим это для следующего раздела. Перейдем к конфигурации YARN.
cat << EOF > /opt/hadoop/etc/hadoop/yarn-site.xml
<configuration>
<property><name>yarn.resourcemanager.hostname</name><value>localhost</value></property>
<property><name>yarn.nodemanager.resource.memory-mb</name><value>4096</value></property>
<property><name>yarn.nodemanager.resource.cpu-vcores</name><value>4</value></property>
<property><name>yarn.scheduler.maximum-allocation-mb</name><value>1024</value></property>
<property><name>yarn.scheduler.maximum-allocation-vcores</name><value>1</value></property>
<property><name>yarn.nodemanager.vmem-check-enabled</name><value>false</value></property>
<property><name>yarn.nodemanager.local-dirs</name><value>/data/yarn</value></property>
<property><name>yarn.nodemanager.log-dirs</name><value>/data/yarn/log</value></property>
<property><name>yarn.log-aggregation-enable</name><value>true</value></property>
<property><name>yarn.nodemanager.aux-services</name><value>mapreduce_shuffle</value></property>
<property><name>yarn.nodemanager.aux-services.mapreduce_shuffle.class</name><value>org.apache.hadoop.mapred.ShuffleHandler</value></property>
</configuration>
EOF Параметров довольно много. Пройдемся по ним по порядку.
Параметр yarn.resourcemanager.hostname указывает, на каком хосте запущен сервис ResourceManager.
Параметры yarn.nodemanager.resource.memory-mb и yarn.nodemanager.resource.cpu-vcores являются, пожалуй, самыми важными. В них мы сообщаем кластеру, сколько памяти и ядер CPU может использовать каждая нода в общей сложности для запуска контейнеров.
Параметры yarn.scheduler.maximum-allocation-mb и yarn.scheduler.maximum-allocation-vcores указывают, сколько памяти и ядер максимально может выделяться под отдельный контейнер. Нетрудно видеть, что с данной конфигурацией в нашем “кластере”, состоящим из одной ноды, могут одновременно быть запущены 4 контейнера (с 1GB памяти каждый).
Параметр yarn.nodemanager.vmem-check-enabled установленный в false, отключает проверку количества используемой виртуальной памяти. Как видно из предыдущего абзаца, каждому контейнеру доступно не так много памяти, и при такой конфигурации любое приложение наверняка привысит лимит доступной виртуальной памяти.
Параметр yarn.nodemanager.local-dirs указывает, где будут храниться временные данные контейнеров (jar с байткодом приложения, файлы конфигурации, временные данные, сгенерированные во время исполнения, …)
Параметр yarn.nodemanager.log-dirs указывает, где локально будут храниться логи каждого таска.
Параметр yarn.log-aggregation-enable указывает хранить логи в HDFS. После окончания исполнения приложения, его логи из yarn.nodemanager.log-dirs каждой ноды будут перемещены в HDFS (по умолчанию – в директорию /tmp/logs).
Параметры yarn.nodemanager.aux-services и yarn.nodemanager.aux-services.mapreduce_shuffle.class указывают сторонний shuffle-сервис для фреймворка MapReduce.
Вот пожалуй и все для YARN. Приведу также конфигурацию для MapReduce (один из возможных фреймворков распределенных вычислений). Хоть он в последнее время и потерял популярность в связи с появлением Spark, однако еще много где используется.
cat << EOF > /opt/hadoop/etc/hadoop/mapred-site.xml
<configuration>
<property><name>mapreduce.framework.name</name><value>yarn</value></property>
<property><name>mapreduce.jobhistory.address</name><value>localhost:10020</value></property>
<property><name>mapreduce.jobhistory.webapp.address</name><value>localhost:19888</value></property>
<property><name>mapreduce.job.reduce.slowstart.completedmaps</name><value>0.8</value></property>
<property><name>yarn.app.mapreduce.am.resource.cpu-vcores</name><value>1</value></property>
<property><name>yarn.app.mapreduce.am.resource.mb</name><value>1024</value></property>
<property><name>yarn.app.mapreduce.am.command-opts</name><value>-Djava.net.preferIPv4Stack=true -Xmx768m</value></property>
<property><name>mapreduce.map.cpu.vcores</name><value>1</value></property>
<property><name>mapreduce.map.memory.mb</name><value>1024</value></property>
<property><name>mapreduce.map.java.opts</name><value>-Djava.net.preferIPv4Stack=true -Xmx768m</value></property>
<property><name>mapreduce.reduce.cpu.vcores</name><value>1</value></property>
<property><name>mapreduce.reduce.memory.mb</name><value>1024</value></property>
<property><name>mapreduce.reduce.java.opts</name><value>-Djava.net.preferIPv4Stack=true -Xmx768m</value></property>
</configuration>
EOF Параметр mapreduce.framework.name указывает, что мы будем запускать задачи MapReduce в YARN (значение по умолчанию local используется только для отладки – все задачи запускаются в одной и той же jvm на одной и той же машине).
Параметры mapreduce.jobhistory.address и mapreduce.jobhistory.webapp.address указывают имя ноды, на которой будет запущен сервис JobHistory.
Параметр mapreduce.job.reduce.slowstart.completedmaps указывает запускать фазу reduce не ранее, чем выполнится 80% фазы map.
Остальные параметры задают максимально фозможные значения памяти и ядер CPU и jvm heap для мапперов, редьюсеров и application master-ов. Как видите, они не должны превышать соответствующим значениям для контейнеров YARN, которые мы определили в yarn-site.xml. Значения jvm heap как правило устанавливают в 75% от параметров *.memory.mb.
Пуск
Создадим директорию /data, в которой будут храниться данные HDFS, а так же временные файлы контейнеров YARN.
mkdir /dataОтформатируем HDFS
hadoop namenode -format И, наконец, запустим все сервисы нашего «кластера»
/opt/hadoop/sbin/hadoop-daemon.sh start namenode
/opt/hadoop/sbin/hadoop-daemon.sh start datanode
/opt/hadoop/sbin/yarn-daemon.sh start resourcemanager
/opt/hadoop/sbin/yarn-daemon.sh start nodemanager
/opt/hadoop/sbin/mr-jobhistory-daemon.sh start historyserver Если все прошло удачно (можно проверить сообщения об ошибках в логах в /opt/hadoop/logs), Hadoop развернут и готов к работе…
Проверка работоспособности
Посмотрим на структуру директорий hadoop
/opt/hadoop/
├── bin
├── etc
│ └── hadoop
├── include
├── lib
│ └── native
├── libexec
├── logs
├── sbin
└── share
├── doc
│ └── hadoop
└── hadoop
├── common
├── hdfs
├── httpfs
├── kms
├── mapreduce
├── tools
└── yarn Сам Hadoop (исполняемый java-байткод) находится в директории share и разбит на компоненты (hdfs, yarn, mapreduce, etc...). В директории lib находятся библиотеки, написанные на C. Назначение остальных директорий интуитивно понятно: bin – утилиты командной строки для работы с Hadoop, sbin – скрипты запуска, etc – конфиги, logs – логи. Нас в первую очередь будут интересовать две утилиты из директории bin: hdfs и yarn.
Если вы помните, мы уже отформатировали HDFS и запустили все необходимые процессы. Посмотрим, что у нас в HDFS:
hdfs dfs -ls -R /
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn/staging
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn/staging/history
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn/staging/history/done
drwxrwxrwt - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn/staging/history/done_intermediate Хотя мы явно не создавали эту структуру директорий, ее создал сервис JobHistory (последний запущеный демон: mr-jobhistory-daemon.sh start historyserver).
Посмотрим, что в директории /data
/data/
├── dfs
│ ├── dn
│ │ ├── current
│ │ │ ├── BP-1600342399-192.168.122.70-1483626613224
│ │ │ │ ├── current
│ │ │ │ │ ├── finalized
│ │ │ │ │ ├── rbw
│ │ │ │ │ └── VERSION
│ │ │ │ ├── scanner.cursor
│ │ │ │ └── tmp
│ │ │ └── VERSION
│ │ └── in_use.lock
│ └── nn
│ ├── current
│ │ ├── edits_inprogress_0000000000000000001
│ │ ├── fsimage_0000000000000000000
│ │ ├── fsimage_0000000000000000000.md5
│ │ ├── seen_txid
│ │ └── VERSION
│ └── in_use.lock
└── yarn
├── filecache
├── log
├── nmPrivate
└── usercache Как видите, в /data/dfs/nn NameNode создал файл fsimage и первый edit-файл. В /data/dfs/dn DataNode создал директорию для хранения блоков данных, но самих данных еще нет.
Скопируем какой-нибудь файл с локальной ФС в HDFS
hdfs dfs -put /var/log/messages /tmp/
hdfs dfs -ls /tmp/messages
-rw-r--r-- 1 root supergroup 375974 2017-01-05 09:33 /tmp/messagesСнова посмотрим на содержимое /data
/data/dfs/dn
├── current
│ ├── BP-1600342399-192.168.122.70-1483626613224
│ │ ├── current
│ │ │ ├── finalized
│ │ │ │ └── subdir0
│ │ │ │ └── subdir0
│ │ │ │ ├── blk_1073741825
│ │ │ │ └── blk_1073741825_1001.meta
│ │ │ ├── rbw
│ │ │ └── VERSION
│ │ ├── scanner.cursor
│ │ └── tmp
│ └── VERSION
└── in_use.lock Ура!!! Появился первый блок и его контрольная сумма.
Запустим какое-нибудь приложение, чтобы убедится, что YARN работает как надо. Например, pi из пакета hadoop-mapreduce-examples.jar:
yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar pi 3 100000
…
Job Finished in 37.837 seconds
Estimated value of Pi is 3.14168000000000000000 Если посмотреть на содержимое /data/yarn во время исполнения приложения, можно узнать много интересного о том, как исполняются приложения YARN:
/data/yarn/
├── filecache
├── log
│ └── application_1483628783579_0001
│ ├── container_1483628783579_0001_01_000001
│ │ ├── stderr
│ │ ├── stdout
│ │ └── syslog
│ ├── container_1483628783579_0001_01_000002
│ │ ├── stderr
│ │ ├── stdout
│ │ └── syslog
│ ├── container_1483628783579_0001_01_000003
│ │ ├── stderr
│ │ ├── stdout
│ │ └── syslog
│ └── container_1483628783579_0001_01_000004
│ ├── stderr
│ ├── stdout
│ └── syslog
├── nmPrivate
│ └── application_1483628783579_0001
│ ├── container_1483628783579_0001_01_000001
│ │ ├── container_1483628783579_0001_01_000001.pid
│ │ ├── container_1483628783579_0001_01_000001.tokens
│ │ └── launch_container.sh
│ ├── container_1483628783579_0001_01_000002
│ │ ├── container_1483628783579_0001_01_000002.pid
│ │ ├── container_1483628783579_0001_01_000002.tokens
│ │ └── launch_container.sh
│ ├── container_1483628783579_0001_01_000003
│ │ ├── container_1483628783579_0001_01_000003.pid
│ │ ├── container_1483628783579_0001_01_000003.tokens
│ │ └── launch_container.sh
│ └── container_1483628783579_0001_01_000004
│ ├── container_1483628783579_0001_01_000004.pid
│ ├── container_1483628783579_0001_01_000004.tokens
│ └── launch_container.sh
└── usercache
└── root
├── appcache
│ └── application_1483628783579_0001
│ ├── container_1483628783579_0001_01_000001
│ │ ├── container_tokens
│ │ ├── default_container_executor_session.sh
│ │ ├── default_container_executor.sh
│ │ ├── job.jar -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/11/job.jar
│ │ ├── jobSubmitDir
│ │ │ ├── job.split -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/12/job.split
│ │ │ └── job.splitmetainfo -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/10/job.splitmetainfo
│ │ ├── job.xml -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/13/job.xml
│ │ ├── launch_container.sh
│ │ └── tmp
│ │ └── Jetty_0_0_0_0_37883_mapreduce____.rposvq
│ │ └── webapp
│ │ └── webapps
│ │ └── mapreduce
│ ├── container_1483628783579_0001_01_000002
│ │ ├── container_tokens
│ │ ├── default_container_executor_session.sh
│ │ ├── default_container_executor.sh
│ │ ├── job.jar -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/11/job.jar
│ │ ├── job.xml
│ │ ├── launch_container.sh
│ │ └── tmp
│ ├── container_1483628783579_0001_01_000003
│ │ ├── container_tokens
│ │ ├── default_container_executor_session.sh
│ │ ├── default_container_executor.sh
│ │ ├── job.jar -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/11/job.jar
│ │ ├── job.xml
│ │ ├── launch_container.sh
│ │ └── tmp
│ ├── container_1483628783579_0001_01_000004
│ │ ├── container_tokens
│ │ ├── default_container_executor_session.sh
│ │ ├── default_container_executor.sh
│ │ ├── job.jar -> /data/yarn/usercache/root/appcache/application_1483628783579_0001/filecache/11/job.jar
│ │ ├── job.xml
│ │ ├── launch_container.sh
│ │ └── tmp
│ ├── filecache
│ │ ├── 10
│ │ │ └── job.splitmetainfo
│ │ ├── 11
│ │ │ └── job.jar
│ │ │ └── job.jar
│ │ ├── 12
│ │ │ └── job.split
│ │ └── 13
│ │ └── job.xml
│ └── work
└── filecache
42 directories, 50 files
В частности видим, что логи пишутся в /data/yarn/log (параметр yarn.nodemanager.log-dirs из yarn-site.xml).
По окончании работы приложения /data/yarn приходит в свой первозданный вид:
/data/yarn/
├── filecache
├── log
├── nmPrivate
└── usercache
└── root
├── appcache
└── filecacheЕсли мы снова взглянем на содержимое HDFS, увидим, что log aggregation работает (логи только что выполненного приложения были перемещены из локальной ФС /data/yarn/log в HDFS /tmp/logs).
Также увидим, что сервис JobHistory сохранил информацию о нашем приложении в /tmp/hadoop-yarn/staging/history/done
hdfs dfs -ls -R /
drwxrwx--- - root supergroup 0 2017-01-05 10:12 /tmp
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn
drwxrwx--- - root supergroup 0 2017-01-05 10:12 /tmp/hadoop-yarn/staging
drwxrwx--- - root supergroup 0 2017-01-05 10:07 /tmp/hadoop-yarn/staging/history
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017/01
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017/01/05
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017/01/05/000000
-rwxrwx--- 1 root supergroup 46338 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017/01/05/000000/job_1483628783579_0001-1483629144632-root-QuasiMonteCarlo-1483629179995-3-1-SUCCEEDED-default-1483629156270.jhist
-rwxrwx--- 1 root supergroup 117543 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done/2017/01/05/000000/job_1483628783579_0001_conf.xml
drwxrwxrwt - root supergroup 0 2017-01-05 10:12 /tmp/hadoop-yarn/staging/history/done_intermediate
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/history/done_intermediate/root
drwx------ - root supergroup 0 2017-01-05 10:12 /tmp/hadoop-yarn/staging/root
drwx------ - root supergroup 0 2017-01-05 10:13 /tmp/hadoop-yarn/staging/root/.staging
drwxrwxrwt - root supergroup 0 2017-01-05 10:12 /tmp/logs
drwxrwx--- - root supergroup 0 2017-01-05 10:12 /tmp/logs/root
drwxrwx--- - root supergroup 0 2017-01-05 10:12 /tmp/logs/root/logs
drwxrwx--- - root supergroup 0 2017-01-05 10:13 /tmp/logs/root/logs/application_1483628783579_0001
-rw-r----- 1 root supergroup 65829 2017-01-05 10:13 /tmp/logs/root/logs/application_1483628783579_0001/master.local_37940
drwxr-xr-x - root supergroup 0 2017-01-05 10:12 /user
drwxr-xr-x - root supergroup 0 2017-01-05 10:13 /user/rootТестирование в распределенном кластере
Возможно вы обратили внимание, что до сих пор я брал “кластер” в кавычки. Ведь у нас все работает на одной и той же машине. Исправим это досадное недоразумение. Протестируем наш Hadoop в настоящем распределенном кластере.
Прежде всего, подправим конфигурацию Hadoop. На данный момент имя хоста в конфигурации Hadoop указано как localhost. Если сейчас просто скопировать эту конфигурацию на другие ноды, каждая нода будет пытаться найти NameNode, ResourceManager и JobHistory сервисы на своем хосте. Поэтому определимся заранее с именем хоста с этими сервисами и внесем правки в конфиги.
В моем случае, все выше master-сервисы (NameNode, ResourceManager, JobHistory) будут выполняться на хосте master.local. Заменим localhost на master.local в конфигурации:
cd /opt/hadoop/etc/hadoop
sed -i 's/localhost/master.local/' core-site.xml hdfs-site.xml yarn-site.xml mapred-site.xmlТеперь я просто клонирую виртуальную машину, на которой я проводил сборку два раза, чтоб получить две slave-ноды. На slave-нодах нужно установить уникальное имя хоста (в моем случае это slave1.local и slave2.local). Также на всех трех нодах нашего кластера сконфигурируем /etc/hosts, чтоб каждая машина кластера могла обращаться к другим по имени хоста. В моем случае это выглядит так (одно и то же содержимое на всех трех машинах):
cat /etc/hosts
…
192.168.122.70 master.local
192.168.122.59 slave1.local
192.168.122.217 slave2.local Дополнительно на нодах slave1.local и slave2.local нужно очистить содержимое /data/dfs/dn
rm -rf /data/dfs/dn/*Все готово. На master.local запускаем все сервисы:
/opt/hadoop/sbin/hadoop-daemon.sh start namenode
/opt/hadoop/sbin/hadoop-daemon.sh start datanode
/opt/hadoop/sbin/yarn-daemon.sh start resourcemanager
/opt/hadoop/sbin/yarn-daemon.sh start nodemanager
/opt/hadoop/sbin/mr-jobhistory-daemon.sh start historyserver На slave1.local и slave2.local запускаем только DataNode и NodeManager:
/opt/hadoop/sbin/hadoop-daemon.sh start datanode
/opt/hadoop/sbin/yarn-daemon.sh start nodemanager Проверим, что наш кластер теперь состоит из трех нод.
Для HDFS посмотрим на вывод команды dfsadmin -report и убедимся, что все три машины включены в список Live datanodes:
hdfs dfsadmin -report
...
Live datanodes (3):
…
Name: 192.168.122.70:50010 (master.local)
...
Name: 192.168.122.59:50010 (slave1.local)
...
Name: 192.168.122.217:50010 (slave2.local) Или зайдем на веб страничку NameNode:
master.local:50070/dfshealth.html#tab-datanode
Для YARN посмотрим на вывод команды node -list:
yarn node -list -all
17/01/06 06:17:52 INFO client.RMProxy: Connecting to ResourceManager at master.local/192.168.122.70:8032
Total Nodes:3
Node-Id Node-State Node-Http-Address Number-of-Running-Containers
slave2.local:39694 RUNNING slave2.local:8042 0
slave1.local:36880 RUNNING slave1.local:8042 0
master.local:44373 RUNNING master.local:8042 0 Или зайдем на веб страничку ResourceManager
master.local:8088/cluster/nodes
Все ноды должны быть в списке со статусом RUNNING.
Напоследок убедимся, что запускаемые приложения MapReduce используют ресурсы на всех трех нодах. Запустим уже знакомое нам приложение Pi из hadoop-mapreduce-examples.jar:
yarn jar /opt/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar pi 30 1000Во время выполнения приложения еще раз посмотрим вывод yarn node -list -all:
...
Node-Id Node-State Node-Http-Address Number-of-Running-Containers
slave2.local:39694 RUNNING slave2.local:8042 4
slave1.local:36880 RUNNING slave1.local:8042 4
master.local:44373 RUNNING master.local:8042 4 Number-of-Running-Containers — 4 на каждой ноде.
Также мы можем зайти на master.local:8088/cluster/nodes и посмотреть, сколько ядер и памяти используется всеми приложениями в общей сложности на каждой ноде.
Заключение
Мы собрали Hadoop из исходного кода, установили, сконфигурировали и протестировали работоспособность на отдельной машине и в распределенном кластере. Если тема вам интересна, если есть желание подобным образом собрать другие сервисы из экосистемы Hadoop, оставлю ссылку на скрипт, который поддерживаю для собственных нужд:
github.com/hadoopfromscratch/hadoopfromscratch
С его помошью вы сможете установить zookeeper, spark, hive, hbase, cassandra, flume. Если найдете ошибки или неточности, пожалуйста напишите. Буду очень признателен.
Автор: facha
