hadoop
mapper数の調べ方
nodetool
◼️インストール
流し読みしただけ
近いうちに私も試したい。
qiita.com
◼️ログに関して
どうもログがややこしい。
整理できない。
container-log4j.propertiesの記載あり
しかしながらよくわからない。この前に何を見ればいいかわからない。
それなりに見てここをみるとhadoopに関することはもう前提として記載されているのでhadoopがわからない人には全く理解できない。
CDH4 LogPath and LogLevel Configurations | 外道父の匠
やはりslaveサーバ用
ログ保存パス
なぜか2つに記載されている
デーモンのログ2つある?
/etc/hadoop/conf/hadoop-env.sh
export HADOOP_ROOT_LOGGER="WARN,RFA"
/etc/hadoop/conf/yarn-env.sh
export YARN_ROOT_LOGGER="WARN,RFA"
propeties設定をxmlに変換
ログレベル
ノードでは log4j.properties の hadoop.root.logger ではなくこちらを使うようですが・・・
→これもいきなりすぎ、わからん。
Map, Reduce, ApplicationMaster と、いわゆるContainerのログを保存できます。
次にApplicationMasterのログを抑制します。この設定は新規ファイルを利用するようになっていて発見に苦労しました。ジョブ実行時にSLAVEサーバでプロセスを表示させるとApplicationMasterはこのような感じになっていて、container-log4j.properties を見るようになっていることがわかります。
↓
ありがたい記載であるが、いきなりすぎる。
設定が hdfs/yarn, env.sh, site.xml, log4j と散らばっていて、保存先もローカルファイル, HDFSとある。
◼️よく出てくるApplicationMasterとは?
ApplicationMaster
ApplicationMasterのログを抑制します。
container-log4j.propertiesをみる。
・ApplicationMasterとは?
www.ibm.com
YARNが当たり前のようにでる。
クラスター・マネージャーではなく、ResourceManager
短時間存続する専用の JobTracker は、ApplicationMaster
TaskTracker ではなく、NodeManager
MapReduce ジョブではなく、分散アプリケーション
※
クラスター・マネージャーの唯一の役割は、クラスター内のライブ・ノードと使用可能なリソースを追跡して、タスクに割り当てることです。
クラスターに対して実行依頼されたジョブごとに、短時間だけ存続する専用の JobTracker が開始されます。
面白いことに、短時間存続する JobTracker は、スレーブ・ノード上で実行される TaskTracker によって開始されます。
従って、ジョブのライフサイクルの調整は、クラスター内で使用可能なすべてのマシンに分散されます。この動作により、さらに多くのジョブを並列に実行できるため、スケーラビリティーが劇的に向上することになります。
JobTracker が常に数千の TaskTracker、数百のジョブ、そして何万もの map タスクと reduce タスクを追跡しなければならない大規模なクラスターとなると、さらに深刻化します。
↓解決案
単一の JobTracker を使用するのではなく、クラスター・マネージャーを導入します。
上記の※
YARNは上記の解決としてApache Hadoop 2.0にて出てきた。
ApplicationMaster とそのアプリケーションに属するタスクは、NodeManager が制御するリソース・コンテナー内で実行されます。
NodeManager は、TaskTracker をより汎用的かつ効率的にしたバージョンです。NodeManager は一定数の map スロットと reduce スロットを使用するのではなく、動的に作成される多数のリソース・コンテナーを使用します。
コンテナーのサイズは、そこに含めるリソース (メモリー、CPU、ディスク、ネットワーク I/O など) の量によって決まります。→具体例は?
ResourceManager、NodeManager、およびコンテナーは、アプリケーションやタスクのタイプを問いません。
コンテナーが当然のようになっている。
興味深いことに、ApplicationMaster はコンテナー内であらゆるタイプのタスクを実行することができます。例えば、MapReduce ApplicationMaster はコンテナーに map タスクまたは reduce タスクの開始を要求する一方、Giraph ApplicationMaster はコンテナーに Giraph タスクの実行を要求します。特定のタスクを実行するカスタム ApplicationMaster を実装して、ビッグ・データの世界を変える、まったく新しい分散アプリケーション・フレームワークを生み出すことができます。ぜひ、YARN をベースに分散アプリケーションを簡単に作成できるようにすることを目的とした Apache Twill について読んでください。 →いきなり言葉の組み合わせが次々出てくる。ビッグデータの世界を変えるとかいきなりすぎないか。
つまりよく出てくるYARNは
YARN は、完全に作成し直された Hadoop クラスターのアーキテクチャーであり、一般商品化されたマシンのクラスターに分散アプリケーションを実装して実行する方法に大改革をもたらすアーキテクチャーとなりそうです。
(ログに関しての記載) 単純化されたユーザー・ログ管理およびアクセス。アプリケーションによって生成されたログは、(MRv1 でのように) 個々のスレーブ・ノード上に残されませんが、HDFS などの中央ストレージに移動されます。そのため、後でログをデバッグや履歴分析のために使用して、パフォーマンス上の問題を見つけることができます。
上記のサイトを確認し、下記サイトを確認すると驚くほどわかりやすい。
分散処理技術「Hadoop」とは:NTTデータのHadoopソリューション
YARNでは、Hadoopクラスタ内のリソースを管理するマスタノードとしてResourceManager、処理ノードを管理するスレーブノードとしてNodeManagerで構成されています。 アプリケーションを管理するノードApplicationMasterは、リソース状況を確認しつつ処理を実行するContainer(コンテナ)の確保をResourceManagerに要求します。 ResourceManagerは、NodeManagerからのリソース利用状況をもとに、どのノードでContainerを起動するか情報を回答します。 この回答を従い、ApplicationMasterは処理ノードでコンテナ起動を要求してアプリケーションを実行します。
◼️Mapper数と繋がるか
Mapper数はネットにない。