最初からHadoop

この記事では、初心者管理者向けにHadoopの正常性を構築、初期構成、およびテストする方法に関する実用的なガイダンスを提供します。 ソースから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ディストリビューションで仮想マシンイメージをダウンロードするための推奨事項から始まることがよくあります。 原則として、ディストリビューションは多くのコンポーネントを持つ複雑なエコシステムです。 初心者にとって、どこで何がどのように相互作用するかを理解するのは容易ではありません。 コンポーネントを一度に1つずつ検討する機会があるため、ゼロから始めて、エントリのしきい値をわずかに減らします。

-機能テストとベンチマーク。 製品の新しいバージョンのリリースと、ディストリビューションに表示される瞬間との間にわずかな遅れがあります。 新しく登場したバージョンの新機能をテストする必要がある場合、既製のディストリビューションを使用することはできません。 また、同じソフトウェアの2つのバージョンのパフォーマンスを比較することは困難です。これは、完成したディストリビューションでは、通常、1つのコンポーネントのバージョンを更新し、他のすべてをそのままにする方法がないためです。

-楽しみのためだけに。

なぜソースからコンパイルするのですか? 結局のところ、Hadoopバイナリアセンブリも利用可能です。

Hadoopコードの一部はC / C ++で記述されています。 開発チームがどのシステム上に構築するのかわかりませんが、Hadoopバイナリビルドに付属するCライブラリは、RHELでもDebian / Ubuntuでもないlibcのバージョンに依存しています。 Hadoop Cライブラリの非動作性は一般に重要ではありませんが、一部の機能はそれらがなければ機能しません。

公式のドキュメントにすでにあるすべてのものを再記述しなければならないのはなぜですか?

この記事は時間を節約することを目的としています。 公式ドキュメントにはクイックスタートの手順は含まれていません-実行してください。 何らかの理由で「バニラ」Hadoopを組み立てる必要があるが、試行錯誤でこれを行う時間がない場合は、アドレスにアクセスしました。

組立


louderaによると、ほとんどのクラスターはRHELおよび派生物(CentOS、Oracle Linux)で動作します。 7番目のバージョンは、リポジトリに必要なバージョンのprotobufライブラリがすでにあるため、最も適しています。 CentOS 6を使用する場合は、自分でprotobufをビルドする必要があります。

(記事を複雑にしないために)root権限でアセンブリおよびその他の実験を行います。

Hadoopコードの約95%はJavaで記述されています。 ビルドするには、Oracle JDKとMavenが必要です。

Oracleサイトから最新のJDKをダウンロードし、/ optに解凍します。 また、JAVA_HOME変数(Hadoopで使用)を追加し、/ opt / java / binをルートユーザーのPATHに追加します(便宜上)。

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 

Mavenをインストールします。 アセンブリ段階でのみ必要になります。 したがって、私たちはそれを自宅にインストールします(アセンブリの完了後、自宅に残っているすべてのファイルを削除できます)。

 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 

Hadoopコードの4〜5%は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 

システムの準備ができました。 / optでHadoopをダウンロード、ビルド、インストールします。

 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には約1000個のパラメーターがあります。 幸いなことに、Hadoopを起動してマスタリングの最初のステップを実行するには、約40で十分であり、残りはデフォルトで残ります。

始めましょう。 覚えているなら、Hadoopを/ opt / hadoopにインストールしました。 すべての構成ファイルは/ opt / hadoop / etc / hadoopにあります。 合計で、6つの構成ファイルを編集する必要があります。 以下のすべての設定をコマンドの形式で提供します。 この記事のためにHadoopをビルドしようとしている人は、コンソールにコマンドを簡単にコピーして貼り付けることができます。

まず、hadoop-env.shファイルとyarn-env.shファイルでJAVA_HOME環境変数を設定します。 そのため、すべてのコンポーネントに、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 

core-site.xmlファイルでHDFSのURLを構成します。 hdfs://プレフィックス、NameNodeが実行されているホスト名、およびポートで構成されます。 これが行われない場合、Hadoopは分散ファイルシステムを使用しませんが、コンピューター上のローカルファイルシステムで動作します(デフォルトURL:ファイル:///)。

 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つのノードのみで構成されているため、レプリカの数を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を実行し、FSを操作することが可能です。 しかし、次のセクションにこれを残しましょう。 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パラメーターは、R​​esourceManagerサービスが実行されているホストを指定します。

パラメーターyarn.nodemanager.resource.memory-mbおよびyarn.nodemanager.resource.cpu-vcoresはおそらく最も重要です。 その中で、各ノードがコンテナを実行するために使用できるメモリとCPUコアの量をクラスターに伝えます。

パラメーターyarn.scheduler.maximum-allocation-mbおよびyarn.scheduler.maximum-allocation-vcoresは、個別のコンテナーに割り当てることができるメモリーとコアの量を示します。 1つのノードで構成される「クラスター」のこの構成では、4つのコンテナーを同時に起動できます(それぞれ1 GBのメモリ)。

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パラメーターは、MapReduceフレームワークのサードパーティシャッフルサービスを指定します。

おそらく、YARNのすべてです。 また、MapReduce(可能な分散コンピューティングフレームワークの1つ)の構成も示します。 Sparkの出現により最近人気を失いましたが、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パラメーターは、YARNでMapReduceタスクを実行することを指定します(デフォルト値localはデバッグにのみ使用されます-すべてのタスクは同じマシンの同じjvmで実行されます)。

パラメーターmapreduce.jobhistory.addressおよびmapreduce.jobhistory.webapp.addressは、JobHistoryサービスが起動されるノードの名前を示します。

mapreduce.job.reduce.slowstart.completedmapsパラメーターは、マップフェーズの80%が完了する前にリデュースフェーズを開始するように指示します。

残りのパラメーターは、マッパー、リデューサー、およびアプリケーションマスターのメモリとCPUコアおよびjvmヒープの可能な最大値を指定します。 ご覧のとおり、これらはyarn-site.xmlで定義したYARNコンテナーの対応する値を超えてはなりません。 JVMヒープ値は通常、* .memory.mbパラメーターの75%に設定されます。

開始する


HDFSデータを保存する/ dataディレクトリと、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バイトコード)は共有ディレクトリにあり、コンポーネント(hdfs、yarn、mapreduceなど)に分割されています。 libディレクトリには、Cで記述されたライブラリが含まれています。

他のディレクトリの目的は直感的です:bin-Hadoopを操作するためのコマンドラインユーティリティ、sbin-起動スクリプトなど-構成、ログ-ログ。 私たちは主に、binディレクトリにある2つのユーティリティ、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ファイルと最初の編集ファイルを作成しました。 / data / dfs / dnに、DataNodeはデータブロックを保存するためのディレクトリを作成しましたが、データ自体はまだ存在していません。

ローカルFSから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/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が正常に機能することを確認するために、アプリケーションを実行してみましょう。 たとえば、hadoop-mapreduce-examples.jarパッケージのpi:

 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-site.xmlのパラメーターyarn.nodemanager.log-dirs)に書き込まれていることがわかります。

アプリケーション/データ/ヤーンの最後に元の形式があります:

 /data/yarn/ ├── filecache ├── log ├── nmPrivate └── usercache └── root ├── appcache └── filecache 

HDFSの内容をもう一度見ると、ログの集計が機能していることがわかります(新しく実行されたアプリケーションのログはローカルFS / 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サービスを見つけようとします。 したがって、これらのサービスでホスト名を事前に決定し、構成を変更します。

私の場合、上記のすべてのマスターサービス(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 

ここで、2回構築する仮想マシンのクローンを作成して、2つのスレーブノードを取得します。 スレーブノードでは、一意のホスト名を設定する必要があります(私の場合は、slave1.localおよびslave2.localです)。 また、クラスターの3つのノードすべてで、/ etc / hostsを構成し、クラスター内の各マシンがホスト名で他のマシンにアクセスできるようにします。 私の場合、これは次のようになります(3台のマシンすべてで同じコンテンツ):

 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 

クラスターが3つのノードで構成されていることを確認しましょう。

HDFSの場合、dfsadmin -reportコマンドの出力を見て、3つのマシンすべてがLiveデータノードリストに含まれていることを確認します。

 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 Webページに移動します。

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 Webページに移動します

master.local :8088 /クラスター/ノード


すべてのノードは、ステータスがRUNNINGのリストに含まれている必要があります。

最後に、実行中のMapReduceアプリケーションが3つのノードすべてでリソースを使用することを確認します。 hadoop-mapreduce-examples.jarから使い慣れたPiアプリケーションを実行します。

 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 

実行コンテナの数-各ノードに4つ。

master.local :8088 / cluster / nodesに移動して、各ノードですべてのアプリケーションが合計で使用するコアとメモリの数を確認することもできます。



おわりに


ソースコードからHadoopをコンパイルし、別のマシンおよび分散クラスターで機能をインストール、構成、およびテストしました。 トピックに興味がある場合、同様の方法でHadoopエコシステムから他のサービスを収集する場合は、自分のニーズに対応するスクリプトへのリンクを残します。

github.com/hadoopfromscratch/hadoopfromscratch

それを使用して、zookeeper、spark、hive、hbase、cassandra、flumeをインストールできます。 エラーや不正確な点を見つけたら、書いてください。 本当にありがたいです。

Source: https://habr.com/ru/post/J319048/


All Articles