Category Archives: hadoop

[メモ] FreeBSD10にhadoopインストール

Pocket

素の状態のFreeBSD 10にpkgngでhadoopをインストールしたときのメモ。

2014/7/4時点でのpkgにはhadoop-1.2.1が入ってる。

pkgのインストール

pkgの初回インストールに成功した試しがない。
pkgのpackageをダウンロードしてインストール。
具体的には、pkg-staticを取り出し、pkg-staticでpkgのpackageをインストール。

pkg update。

シェルとか、sudoとか、必要なものがあればインストールする。

hadoopのインストール

OpenJDKのための設定

hadoopについてくるOpenJDKのためにfstabに設定を加える。
OpenJDKインストール時のメッセージに沿って進める。

fstabに以下に行を追加。区切りはtab。

mount。
mountと叩いてmountされていることを確認。

以上。
続きはこちら

Hadoopフレンドリーなデータとは

Pocket

 

ログは1行1イベントに

何を言っとるんだお前はという感じであるが、つまりこういう事である。

通常、ログは1行が1イベントである。
たとえばapacheのログやらなにやら、みんなそうである。
少なくともUNIX系のシステムであれば、これは常識である。
しかし、この世の中、UNIX系の常識が通用しないログだって山ほどあるのである。

1イベントが複数行にわたるログがなぜいけないか。

たとえば以下の様な擬似ログを考えてみよう。

まったく関係のない話だが、以下のデータは手元にあるLIFEのノートから適当にでっち上げた。
冒頭にタイムスタンプがあり、イベントの内容が記される、典型的なログである。

しかしこれが、以下のように複数行にわたって記録(あるいは表示)される、こういうログを相手にすることだってあるのだ。

 

これは主に可読性を意識したせいであろうが、こういったログをHadoopで扱うのは難しい。

Hadoopのデータの扱い方

というのも、Hadoopは分散処理のためにログを分割するからだ(デフォルトでは64MBごと)。

しかもその分割は、単純にサイズのみで判断され、文脈は考慮されない。
上のログで言えば、Nobleの手前で切られてしまってログとして意味がなくなってしまうことだってある。

これを避けるには、Hadoopにファイルそのものではなくて、ファイルリストを与える手があるけれども、それではHadoopの長所を活かせない。
ファイルリストは綺麗に分割されるけど、ファイルの大きさはまちまちだから。

ログの整形

というわけで、こういったログを扱う前に、下準備として1行1イベントにまとめてしまおう。

まとめ自体もHadoopで処理してしまえば楽である。
Hadoopの象本Appendix Cに良い例があるのでこれを使う。
ここでfiles.txtは処理するログファイルをリストしたものとする。
また、concat.shは1行1イベントにまとめるスクリプトとする。

 

reduceは必要ないのでmapred.reduce.tasks=0。
重複して書き込んでほしくないのでmapred.map.tasks.speculative.execution=false。
タイムアウトは長めに。
mapが一回に処理するファイルはひとつにしたいので、-inputformat org.apache.hadoop.mapred.lib.NLineInputFormat 。

以上

hadoopのsafemodeとfsck

Pocket

 

Hadoopのnamenode兼datanodeが電源瞬断のせいで壊れてしもうた。
勉強用のHadoopなのでダメージはないのだが、せっかくなのでfsckなどを試した結果を記す。
hadoop-1.0.0。
OS側でもfsckはしておいた。

サマリ

  • HDFSにもfsckがある。
  • hadoop fsckでチェック、修正できる。
  • hadoop fsckと叩けば使い方の簡単な説明が表示される。
  • namenodeがsafemodeのためにHDFSが読み取り専用になっていることがある。
  • 読み取り専用ではfsckで修正できないので、safemodeから出る必要がある。

 

HDFSでのfsck

hadoop fsck <path>と指定すればよい。
CORRUPT!とのことで、壊れておりますなあ。

 

壊れている場合の対処:消去か移動

壊れている場合には対処が二つ。
壊れているブロックを消すか、lost+foundに移すか。
消す場合には-delete, 移す場合には-moveを指定する。
以下は消した場合の例….なのだが、namenodeがsafemodeにいるので変更が出来ないとのこと。

 

safemodeとは

そもそもnameodeは通常の動作として、起動時には状態がsafemodeである。
safenodeのまま待機をしているうちに、datanodeが起動し、保管しているブロックの報告をnamenodeに行う。
namenodeは、充分なブロックの確認ができれば自動的にsafemodeを出る。
「充分なブロック」がどれくらいか、は設定できる。

safemodeのときは読み取り専用になり、複製や消去もできないが、手動でsafemodeに入ったり出たりすることができる。

以下、公式からの引用

Safe mode is entered automatically at Namenode startup, and leaves safe mode automatically when the configured minimum percentage of blocks satisfies the minimum replication condition. Safe mode can also be entered manually, but then it can only be turned off manually as well.
Safe mode maintenance command. Safe mode is a Namenode state in which it
1. does not accept changes to the name space (read-only)
2. does not replicate or delete blocks.

今回、問題の発生したnamenodeはdatanodeも兼ねている。
電源瞬断でブロックが壊れているからブロックの報告はできないし、そもそもnamenodeが保管しているメタデータも壊れている。
ボロボロである。
したがって、いつまで待ってもsafemodeから出るはずがない。
そこで手動でsafemodeを解除する。

safemodeの操作

safemodeの操作はhadoop dfsadmin -safemodeに続けて行う。
getで状態を得る。
enterでsafemodeに入る。
leaveでsafemodeから出る。
面白いのは、wait。
safemodeから出たらコマンド実行する、というもの。

以下、実際の例。
safe modeがONになっているので、OFFに。

改めてfsck / -delete
blockが2000個くらい消えた。ま、まあ勉強用だし(震え声)

HEALTYになったので、これでhadoopが使える状態に戻った。
以上。

Hadoopのインプット指定にワイルドカードが使える件について

Pocket

 

Hadoopへのインプットはふつう、ディレクトリかファイルの指定で行う。

しかし以下のような場合にどうするか。

  • 複数のディレクトリの下にあるファイルをhadoopに処理させたいとき。
  • 特定拡張子のファイルのみをhadoopに処理させたいとき。

実はワイルドカードが使えるので、それで解決。
以下、hadoop-1.0.0で確認。

ケース1:複数ディレクトリの下に処理対象ファイルがある場合。

 

以上のような状態でhadoopへのinputにtopを指定すると、hadoopはdir1をファイルとして処理しようとし、失敗する。
たとえばこのように。

このような場合には、top/*と指定してあげればよい。
たとえばこのように。

 

ケース2:特定のファイルのみ処理したい場合

たとえば以下のdir3で.txtのみを処理したい場合。

-input dir3/*.txtとすればよい。

 

ケース3:ケース1/2の複合ケース

 

 

合わせ技でtop/*/*.txtと指定すればよい。

No tags for this post.

[Hadoop] 擬似分散モードから完全分散モードへ(データノードの追加)

Pocket

Hadoopへのノードの追加

hadoopの長所は、処理量に応じて簡単にスケールできる点にある。
処理がおっつかなくなってきたら、データノードを追加するだけ。
擬似分散モードから完全分散モードへの移行は、データノードの追加と同じ。
もう少し詳しく言うと、最初の1台をnamenode/jobtrackerのままにして、datanode/tasktrackerを追加する。
※FreeBSDで、hadoop-1.0.0です。

背景

namenode, datanodeはHDFSのノード種別を表し、namenodeはファイルのメタデータを扱い、datanodeは実データを扱う。
namenodeはhadoopクラスタに原則1台。datanodeは1台以上必要。

jobtracker, tasktrackerはMapReduceでのノード種別を表し、jobtrackerは作業の分担を、tasktrackerは作業の実施を行う。
jobtrackerはhadoopクラスタに原則1台。tasktrackerは1台以上必要。

hadoopクラスタに参加しているノードは、4つの役割のいずれかを担う。複数の役割をこなすのも可。
ただしdatanodeとtasktrackerは必ずセット。
イメージを示す。

hadoopmode

 

設定ファイル

再掲になるが。

どのノードがnamenodeかを指定するのは、core-site.xml 。
どのノードがjobtrackerかを指定するのは、mapred-site.xml 。
どのノードがdatanode/tasktrackerかを指定するのは、slaves 。

擬似分散モードでは、以上3つのファイルに1ノードしか書かれていなかった。

ノードを追加するなら、slavesにdatanode/tasktrackerを追記すればよい。
擬似分散モードの状態からjobtrackerを分離するには、mapred-site.xmlを書き換えればよい。
擬似分散モードの状態からnamenodeを分離するには、core-site.xmlを書き換えればよいけど、HDFS上にすでにファイルを置いている状態でそんなことするとファイルが吹き飛ぶので止めよう。

そしてこれら設定ファイルは、クラスタ内のノードで同じものを使う。

作業の流れ。

datanode/tasktrackerを追加してみる。

擬似分散モードを仮想マシンで動かしている場合には、それをまるまるコピーしてしまえばよい。
私の場合は、ESXi上でHadoop環境を作ったので、それをコピーし、別マシンのESXiに移し替えた。
もちろんホスト名は別のものにする。

ESXiなどを挟まない場合にはもう一度セットアップ。
ほんとに面倒くさいので、chefやらpuppetなどを使うことになるでしょう。

なお、ESXiは使わない方がパフォーマンスは良い。これは当たり前。

追加ノードの注意点

便宜上、擬似分散モードを動かしたノードをoriginal、追加するノードをaddとする。
addを追加するときの注意点は以下の通り。

/etc/hostsの設定。

original, addの/etc/hostsには、original, addの名前解決ができるようにしておくこと。

時刻同期

original, addで時刻を合わせておくこと。

slavesへの追記

original, addそれぞれでslavesにaddと追記しておく。

SSHログインの確認

originalからaddへsshログインできることを確認しておく。
datanode/jobtrackerの制御はsshでされるため。

replication数の変更

HDFS上でデータのコピーをどれだけ作成するかの設定。
擬似分散ではreplicationを1にしていた。
せっかくなのでこれを2に変更する。
デフォルトは3。
datanodeをさらに増やしたなら、ここの上限をとりあえず3として増やそう。

ノード追加の反映

ノードの追加が初めてならstop-all.shで止めて、start-all.shでまるまる再起動するのがいいでしょう。

当然ながら、hadoop上で何かしらの作業が動いていたらやり直しになってしまう。
通常は、namenodeでhadoop dfsadmin -refreshNodesを実行。
さらにhadoop dfsadmin -reportで確認する。

 

上記の例で言えば、192.168.200.100が追加したdatanode。
使用量がまだ8MBしかないことが分かるだろうか。
replication数を2にしたので、ゆくゆくは192.168.200.1と同じ程度の使用量になるはず。
しばらく放置が必要。
(いま気がついたけど、”Under replicated blocks”、つまり所定のreplicationに満たないblockの数が5…)

擬似分散→擬似分散+1の効果

効果は劇的。
もともと2時間半かかっていたものが1時間半に短縮できた。
下記はtimeの結果。上が擬似分散、下が擬似分散+1。

ああもっとdatanode増やしたい。

関連エントリ

[FreeBSD] Hadoopのportsからのインストール
[FreeBSD] portsのHadoopで分散(x-distributed)モードを動かす準備
[Hadoop]Hadoop 擬似分散(Psuedo-distributed)モードの設定
[Hadoop]擬似分散モードで実験

No tags for this post.

[hadoop] hadoop streamingでファイルを分割させないためには。

Pocket

※hadoop-1.0.0です。

hadoop streamingで困ること。

作業データ(たとえばログ)を与えると、Hadoopはまず分割をする。
分割されたものはinput splits, あるいは単にsplitsと呼ばれる。
splitsのサイズはデフォルトで64MBytesだ。
Hadoop(JobTracker)は作業ノード(TaskTracker)にsplitsを割り当てる。
作業ノードはsplitsに対してmapタスクを行う。

なお、作業ノードの割り当てにあたっては、splitsの物理的な場所との近さも考慮される。
要するにsplitsの実データが置かれている作業ノードが選ばれる。

これは素晴らしい仕組みなのだが、困ることもある。
例えば以下のような場合。

 

  • ファイルの冒頭にあるヘッダが処理に必要な場合。
    →分割されると、ヘッダのないsplitsが出来てしまう。
  • ログ上の2点間の時間差分を知りたい場合。
    →2点の間で分割されると計算できない。

回避策

下記の通り。

How do I process files, one per map?

つまり、hadoopへの入力に、いきなり「ファイルの内容」を送り込むのではなく、「ファイルのリスト」を渡す。
ファイルのリストだから、いくら分割してもファイル自体は分割されない。
なるほど。

 

回避策とはいっても。

しかし、この場合mapper側に工夫が必要になる。

通常であれば、標準入力からファイルの中身がドバドバやってくる。
PythonだろうとRubyだろうとstdinをforループで読むだけ。
楽ちん。

ところがこの回避策だと、ファイルリストが入力されるわけだから、ファイルを開くことから始めなければならない。
そしてファイルを開くには、mapperスクリプト内で「hadoop dfs -cat <ファイル>」しないといけない
(ファイルがHDFSにあるとして)。

それも面倒だし、加えて、無駄な通信が発生する可能性がある点も懸念。

先述の通り、Hadoopは作業の振り分けにあたって、実データに近い作業ノードを選ぶ。
しかしファイル「リスト」を渡すということは、ファイル「リスト」と作業ノードの近さは考慮してくれるものの、リストに書かれたファイルと作業ノードの近さは考慮外になるということ。

つまり、作業ノードと実際のデータのある場所が一致するとは限らない。
一致しなければ、作業ノードはデータを別ノードからダウンロードしなければならない。

ノード間通信はコスト高なのでなるべく避けよう、というHadoopの思想にはそぐわない。

mapperの例

しかし選択肢はないので進める。
以下はpythonでファイルリストを受けた場合の処理例。
作業データはHDFS上にあるので、subprocessで「hadoop dfs -cat <ファイル>」する。

 

大したことではないけれど、下記のように必ずテストしてからhdoopに投入すること。

hadoopは自前mapper, reducerが失敗しても、エラー内容を教えてはくれないので(たぶん)。

注意点

HDFS上にファイルを置いている場合、絶対パスで指定すること。
相対パスではダメだった。
また、HDFSでは「/user/hadoop/input」のように、「user」であって「usr」でないことに注意。

作業データがローカルディスクにあるなら、hadoop dfs -getとか。
しかしそうするとすべての作業ノードがローカルディスクにアクセスしてくることになる。
それは避けたいので、HDFS上に置いた方がよいでしょう。

No tags for this post.

[Hadoop] $HADOOP_HOME is deprecatedの対処

Pocket

“$HADOOP_HOME is deprecated”が鬱陶しい。

※本記事ではhadoop 1.00を使ってます。

hadoopを実行すると”$HADOOP_HOME is deprecated”と表示されることがある。
HADOOP_HOMEはもう使われなくなり、代わりにHADOOP_PREFIXにするよう推奨されている。

これを抑制するには、以下二つのうち、いずれかをすればよい。

”$HADOOP_HOME is deprecated”を抑制するには。

  1. HADOOP_HOMEをHADOOP_PREFIXに置き換える。あるいは。
  2. HADOOP_HOME_WARN_SUPPRESS=YESと宣言する。

hadoopのバージョンアップをするつもりがないなら、②が楽でしょうかね。
具体的には、hadoopを使うユーザの.profileあたりで宣言しておけばOK。

エラーメッセージの原因

なお、HADOOP関連のスクリプトを当該メッセージでgrepすると、hadoop-config.shに以下の記載がある。

hadoop-config.sh

つまりHADOOP_HOMEに何か設定されていれば、メッセージを表示する。
しかし、HADOOP_HOME_WARN_SUPPRESSに何か設定されていれば、そのメッセージを抑制する、というわけ。
上記ではHADOOP_HOME_WARN_SUPPRESS=”YES”にしているが、実際のところ中身はなんだってよい。

No tags for this post.

[Hadoop] Hadoop Streaming / mapperとreducerにPythonを使ってみる。

Pocket

 

HadoopはJavaで作られている。
だからHadoopに何か操作をさせたい場合には、通常、Javaで記述する必要がある。
しかしHadoopにはHadoop Streamingという仕組みがあり、早い話UNIXのStandard Stream要するに標準入出力を扱うことができる。

すなわち、UNIXの標準入出力の流儀に則ってさえいれば、お好きな言語で操作ができる。
Javaがまったく合わない私としては、Hadoop Streamはとてもありがたい。
これがなければHadoopに手を付ける気にはならなかった。

Hadoop Streamに必要なもの。

mapperとreducerを、好きな言語で書くだけ。
べつにmapperだけでもよいけど。
私はPython。

Hadoop streamにおけるmapperとreducerの概要。

mapperは何らかの入力を得て、キーと値(key, value)を出力する。
reducerはmapperからのkey, valueを受けて、keyごとにvalueを処理する。

なお、mapperの出力がreducerに渡されるとき、Hadoopがkeyごとにソートしてくれる。
この点はreducerの処理を簡単にする。詳細は後述。

試しにやってみること。

LAN向けのApacheのアクセス状況をカウントしてみる。
IPアドレスごとのアクセス回数だ。
ログは以下のようなもの。
アクセス元はすべてIPアドレスで記録されている。

 

処理の流れ

1.mapperは、アクセスログからIPアドレスを抜き出す。
そして「<IPアドレス><タブ>1」を出力する。
これは、たとえば「192.168.1.1」から「1」回アクセスがあったよ、という意味。

2.hadoopがIPアドレスをキーにソート。

3.reducerは、IPアドレスごとに回数をカウントし、
「<IPアドレス><タブ><集計回数>」を出力する。

mapper.py

IPアドレスは、Apacheログにおいて、スペースを区切りにした第一フィールドに記載される。
だから一行ずつログを読んで、行頭のIPアドレスを抜き出し、その都度「<IPアドレス><タブ>1」を出力する。
「if “newsyslog” not in line:」は、システムメッセージ行を読み飛ばすため。

実行権限も忘れずにつける。

実験。意図したとおり動いていますね。

 

reducer.py

mapper.pyからの出力は、ソートされてreducer.pyに入力される。
上記のmapper.py出力例は、以下のようにソートされる。

だからreducerとしては、第一フィールドを上から読んでいって、keyが変化したら、そこまでのカウント数を出力する。
そしてそのkeyの事は、さっぱり忘れて次のkeyのカウントに移ることができる。
もしソートがなされていないならば、入力の終わりまですべてのkeyを保持しなければならない。Hadoopに感謝である。

実行権限を付ける。

 

実験。間にsortを入れること。
問題なし。

 

Hadoopで動かしてみよう。

まずカウント対象となるログをHDFSにコピーする。

実行。

hadoopにhadoop-streaming-1.0.0.jarを与え、input、outputのほかに、mapperとreducerも指定する。
-mapper -reducerとしてローカルファイルシステムでのパスを与える。
同時に、-fileでそれぞれのスクリプトを指定すると、スクリプトファイルをリモートのノードへ送ってくれる。

コマンドはすごく長くなる。
エスケープシーケンスを使って適宜改行し、見やすくしてタイプミスを防ぐ。

実際のログ

 

結果の確認

hadoop dfs -catなどで。

以上

 

No tags for this post.

[Hadoop]擬似分散モードで実験

Pocket

 

擬似分散モードで実験してみる。
Hadoopには、単語を数えるデモが付いてくるのでこれを使う。

カウント対象テキストの準備

以下のようなファイルを作る。

 

ファイルのHDFSへの格納

上で作ったファイルをHDFSに置く。
こういったファイル操作は、hadoopコマンドにdfsを付けて、-putとか-lsとか叩く。
hadoop dfsとやれば使用できるコマンドの一覧が表示される。-catとか-rmとかも使える。ディレクトリの削除は-rmr。

下記の例では、カレントディレクトリにあるinputディレクトリを、HDFSのinputディレクトリに-putでコピーしている。
inputディレクトリには、先に作ったtest.txtが入っている。

送り先には絶対パスを付けなくても自動的に/usr/hadoopの下になっていることが分かる。
すなわち、~/sandboxにいるときに、送り元、送り先双方にinputを指定すると、ローカルの~/hadoop/sandbox/inputが、HDFS上の/usr/hadoop/inputにコピーされる。

 

wordcountの実行

hadoop-examples-1.0.0.jarにwordcountと続け、カウント対象のファイルが置かれるディレクトリ、カウント結果のファイルが置かれるディレクトリを指定する。
下記の例では先にコピーしたinputを、結果をoutputとして指定する。
outputはこの時点では無くてOK。
「outputがすでにあるよ」と言われたら中身を確認してからhadoop dfs -rmr outputなどとして消す。

hadoopの実行は何かとコマンドが長くなりがちなので、\を使って見やすく複数行にしたほうがよいでしょう。

仮想環境上とはいえ7分てどういうこと。

結果の確認

結果は。指定したディレクトリ、outputに格納される。
outputの中身を見ると、処理の成功したことを示す_SUCCESSというファイルに、結果の書き込まれるpart-r-00000が格納されている。
hadoop dfs -catで中身を確認すると、各単語の数がリストされている。

これだけのために7分とは。
実マシン、かつもっともっと大きなログで試してみたいところ。

 

関連エントリ

[FreeBSD] Hadoopのportsからのインストール
[FreeBSD] portsのHadoopで分散(x-distributed)モードを動かす準備
[Hadoop]Hadoop 擬似分散(Psuedo-distributed)モードの設定
[Hadoop] 擬似分散モードから完全分散モードへ(データノードの追加)


No tags for this post.

[Hadoop]Hadoop 擬似分散(Psuedo-distributed)モードの設定

Pocket

 

Standaloneモードでは、複数のホストを使った処理は行わない。デーモンも動かさない。

しかしHadoopは分散処理をしてナンボである。
分散処理をする場合には、複数のホストでいくつかのデーモンを動作させる必要がある。
それはまあ当然。

ただ、いきなり複数ホストを使うのはハードルが高い。
そこで、「Hadoopは複数ホストで動いているつもりだけど実際は1台のホストで動いている」モードで設定の確認をする。
これが擬似分散(Psuedo-distributed)モード。

擬似分散モードに必要な各設定の意味

擬似分散(Psuedo-distributed)モードの動作には以下、四つの設定が必要。
完全分散(Full distributed)モードでも変わらないんだけどね。

  1. HDFSのメタデータを格納するnamenodeの設定
  2. データをいくつ複製(replication)するかの設定(デフォルトで3)
  3. タスク分散を受け持つJobTrackerの設定
  4. 実データを格納し、タスクを実行するdatanodeかつTaskTrackerの設定

1と3と4にそれぞれlocalhostを指定する(なおこれを別ホストにすればFull distributedモードに)。
2では1を指定する。
デフォルトのままだと、複製を3つ作ろうとする。ひいてはホストが3つ必要になってしまう。
擬似分散モードでは自ホストしか使わないわけだから1を指定するというわけ。

namenode, replication, JobTrackerの設定

以下、三つのファイルを変更する。
前章の1,2,3に対応する。

  • core-site.xml(namenode設定)
  • hdfs-site.xml(replication設定)
  • mapred-site.xml(JobTracker設定)

FreeBSDでportsから入れたなら/usr/local/etc/hadoopにある。

core-site.xml

hdfs-site.xml

mapred-site.xml

 

datanode, TaskTrackerの設定

/usr/local/etc/hadoopの下にmasters, slavesというファイルを作る。
ここでsecondary namenode, datanode, TaskTrackerを指定する。

secondary namenodeとは、namenodeのデータをバックアップするノード。
datanode、TaskTrackerとは、HDFSの実データが置かれ、JobTrackerから指定されたタスクをこなすノード。

mastersというファイルには、secondary namenodeを書く。
slavesというファイルには、datanodeかつTaskTrackerとなるホストを書く。

擬似分散モードでは、secondary namenodeの指定は不要。
mastersという空ファイルだけ作っておけばよい。
slavesには、localhostと書いておく。

 

HDFSのフォーマット

初回に限り、HDFSのフォーマットが必要である。
HDFSにはメタデータを保存するnamenodeと、実データの保存されるdatanodeがある。

ここでの「HDFSのフォーマット」とは、実際のところnamenodeの初期化を意味する。

なので、datanodeはこのフォーマットとは無関係。不要。
しかもdatanodeを追加したり削除したときだって、namenodeでの設定変更、フォーマットは不要。

拍子抜けするくらいである。
だが。裏を返すとnamenodeが壊れればすべてのデータが死亡することを意味する。
実運用の際には、secondaly namenodeを立てるなどして事故に備えることになる。

しかし今は擬似分散モードなので気軽に進める。
HDFSのフォーマットは以下のようにして行う。
※フォーマットは、実際にHadoopを使うユーザで行うこと。FreeBSDでportsから入れた場合は注意

 

HDFSの場所

上記のログにもある通り、デフォルトでは/tmpの下に作られる。
厳密に言えば、/tmp/hadoop-${user.name} に作られる。
namenodeでも、datanodeでも同じ。

/tmpディレクトリだと、システムが消したりするので実運用では場所を変えたほうがよい。

これらの場所は、hdfs-site.xmlで制御できる。
hadoop.tmp.dirがprefixなので、これを変えればよい。
あるいは、dfs.name.dir(namenode向け)、dfs.data.dir(datanode向け)で明示してもよい。

Hadoopの起動

start-all.shで起動させる。

HADOOP_HOMEについて文句をつけられている。スクリプトを見れば分かるが、これは無視してよい。この点については別途。
namenode, datanode, jobtracker, tasktrackerの4つを起動しようと試みていることが分かる。

さて実際に起動しているか。jpsで確認。動いていますな。

 

そしてこれらのプロセスは、ポート待ち受けをする。調べてみる。

50030はJobTrackerの、50070はnamenodeの管理Web用ポート、8020はnamenodeの、8021はdatanodeのポート。

namenodeに対し、ブラウザで前二者のポートにアクセスするとステータスが分かる。

実際に動かすのは今度。
関連エントリ

[FreeBSD] Hadoopのportsからのインストール
[FreeBSD] portsのHadoopで分散(x-distributed)モードを動かす準備
[Hadoop]擬似分散モードで実験
[Hadoop] 擬似分散モードから完全分散モードへ(データノードの追加)

No tags for this post.