はじめに
HDFS にファイルをアップロードできましたが、ターミナルは実際にどこへ送ったのでしょうか？ 小売業者の毎日のファイルは、ノートパソコン、現在のサーバー、共有ストレージのどこにでも存在し得ます。間違ったコピーを読むと、計算そのものは正しくても、対象のデータが違ってしまいます。さらに多くのファイルを管理する前に、コマンドが使う保存領域を見分ける必要があります。
Hadoop では役割が分かれています。Hadoop Common は共通のライブラリとユーティリティを提供します。HDFS はファイルを保存します。MapReduce はバッチ処理のタスクを定義し、実行します。YARN は、MapReduce ジョブなどのアプリケーションにリソースを割り当てます。これらの名前は少しずつ使っていきます。今回は計算やサービスのインストールをせずに、ストレージと設定を調べます。
この実験の目標は3つです。既定のファイルシステムを調べること、同じパス表記でも異なるファイルを指すことを確かめること、そして稼働中の HDFS サービスを特定することです。最後に、自分の環境から得た観察結果をまとめます。必要なデータは前の実験とは独立して準備されています。ターミナルを使用し、プログラミングは必要ありません。
設定された接続先を調べる
このステップでは、既定のファイルシステムと、設定されている MapReduce の実行方式を調べます。
ターミナルで実行するのはクライアントコマンドです。クライアントはサービスに作業を依頼します。サービスは、このマシンにも別のマシンにも置くことができます。設定により、クライアントの短いコマンドが正しい接続先に結び付けられます。まず、ローカルの作業ディレクトリに移動します。
cd /home/labex/project
hdfs getconf は Hadoop の設定を読み取るコマンドです。-confKey オプションでは、名前を指定して1つの設定を取得します。fs.defaultFS は、Hadoop のファイルシステムのパスにスキームを明示しなかった場合に使う、既定のファイルシステムを表します。
hdfs getconf -confKey fs.defaultFS
次の値が表示されるはずです。
hdfs://localhost:9000
これはURIで、リソースへのアクセス方法を含むアドレスです。ここでは、hdfs が HDFS を選び、localhost がこのマシン、9000 がサービスの接続ポートを表します。ポートは、サービスが使うネットワークの接続口を識別します。自分でそのポートを開く必要はありません。
確認した値を保存します。最初の実験と同じように、> はコマンドの出力をローカルファイルに書き込み、既存の内容を置き換えます。
hdfs getconf -confKey fs.defaultFS > /home/labex/project/output/default-filesystem.txt
Hadoop の設定ファイルは XML 形式で、各プロパティには name と value があります。今は1つのプロパティだけ読めれば十分です。grep は一致する文字列を含む行を選び、-A 1 は一致した行の直後の1行も表示します。
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml
関係する2行は次のとおりです。
<name>mapreduce.framework.name</name>
<value>yarn</value>
yarn は、MapReduce アプリケーションがリソース管理に YARN を使う設定になっていることを示します。この設定だけでは、アプリケーションが実行中であることは証明できません。この実験では HDFS が起動しています。計算用のサービスは、ジョブの投入を学ぶときに使います。
期待される値を自分で入力するのではなく、設定の行をそのまま証拠として保存します。
grep -A 1 '<name>mapreduce.framework.name</name>' /etc/labex-bigdata/hadoop/mapred-site.xml > /home/labex/project/output/execution-setting.txt
小さな一時的な表であれば、ローカルファイルシステムだけで十分かもしれません。Hadoop ジョブで共有するアーカイブなら、HDFS の保存先が重要です。どのファイルも自動的に Hadoop にアップロードするのではなく、必要性からツールを選びましょう。
2つのファイルシステムで同じパスを読み取る
このステップでは、同じパス表記で準備された2つのファイルを読み、各コマンドがどのファイルシステムを選ぶかを確かめます。
今回の比較のために、セットアップでは各ファイルシステムの /home/labex/project/data/location.txt に、内容の異なるファイルを配置してあります。ローカルファイルシステムと HDFS は別々のディレクトリツリーを持つため、これが可能です。このコースで通常使う HDFS の作業場所は /user/labex です。今回は違いを分かりやすくするため、同じパスを使っています。
file:/// URI は、ローカルファイルシステムを明示的に選びます。3つのスラッシュは、スキームの区切りと絶対パスを組み合わせたものです。次のコマンドを実行する前に、ローカル版と共有版のどちらが読まれるかを予想してください。
hdfs dfs -cat file:///home/labex/project/data/location.txt
期待される出力は次のとおりです。
Local store: draft product file
Hadoop クライアントを使っていても、URI によってローカルファイルが選ばれました。今度は、ステップ1で確認したサービスのアドレスを使い、HDFS を明示的に選びます。
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt
期待される出力は次のとおりです。
HDFS store: shared product file
最後に、スキームとサービスのアドレスを省略します。ステップ1の既定値によって、どちらが選ばれるか予想してください。
hdfs dfs -cat /home/labex/project/data/location.txt
共有されている HDFS 版が表示されます。絶対パスは、ファイルシステム内の場所を決めます。それだけでファイルシステムを選ぶわけではありません。通常の Linux の cat /home/labex/project/data/location.txt であれば、引き続きローカル版を読みます。
3つの結果を個別に保存し、予想と実際の結果を比較できるようにします。
hdfs dfs -cat file:///home/labex/project/data/location.txt > /home/labex/project/output/local-result.txt
hdfs dfs -cat hdfs://localhost:9000/home/labex/project/data/location.txt > /home/labex/project/output/hdfs-result.txt
hdfs dfs -cat /home/labex/project/data/location.txt > /home/labex/project/output/default-result.txt
HDFS を指定した結果と既定の結果は一致するはずです。ファイルが同じなら何も表示しない diff を使って確かめます。
diff /home/labex/project/output/hdfs-result.txt /home/labex/project/output/default-result.txt
この実験から、トラブルシューティングでパスだけを見ると誤解しやすい理由が分かります。パスと、そのパスが属するファイルシステムの両方を確認しましょう。
ストレージサービスを特定する
このステップでは、ファイル操作を NameNode と DataNode の役割に結び付け、環境の観察結果をまとめます。
HDFS は、ファイルの名前や場所の情報と、ファイルのデータを分けて管理します。NameNode はディレクトリツリーを管理し、どの DataNode がファイルのブロックを保持しているかを把握します。DataNode はブロックを保存し、ファイルの内容を提供します。図書館の目録と本棚を思い浮かべてください。目録は本の場所を探す手助けをし、本棚には本のページが置かれています。
HDFS クライアント → NameNode：ファイルのデータの場所を問い合わせる
HDFS クライアント ↔ DataNode：ファイルのデータを転送する
ブロックは、HDFS が管理する、ファイルの一部分です。後でブロックとその複製を直接調べます。今は、この2つの役割を担うサービスが稼働していることを確かめましょう。systemctl is-active は、指定した各サービスの状態を OS に問い合わせます。このコマンドは状態を調べるだけです。
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode
各サービスに対応する active が2行表示されるはずです。この結果を保存します。
systemctl is-active labex-hdfs-namenode labex-hdfs-datanode > /home/labex/project/output/storage-services.txt
HDFS から見たストレージノードの情報も取得できます。dfsadmin -report は、読み取り専用の管理レポートです。次のコマンドでは、このレポートを読むためだけに sudo -u hdfs を使い、準備済みの hdfs サービス用ユーザーとして実行します。通常のファイル操作は、自分の labex ユーザーで行ってください。
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Live datanodes (1) と、Decommission Status が Normal のノードを探してください。容量、使用量、ホストの識別情報、タイムスタンプは変わるので、ほかの学習者の VM と一致する必要はありません。稼働中のノードは NameNode と通信しています。Normal は、そのノードがサービスから取り外される状態ではないことを示します。
レポートを保存します。
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report > /home/labex/project/output/storage-report.txt
これは単一ノードの疑似分散モードです。別々の Hadoop サービスのプロセスが、1台のマシンで動いています。ローカルモードでは、プログラムは HDFS サービスなしでローカルファイルを扱えます。複数のマシンからなるクラスターでは、サービスとストレージが複数のホストに分かれます。ここで DataNode が1つ見えるだけでは、マシン全体の故障に耐えられることは実証できません。
後でジョブを投入すると、YARN の ResourceManager がリソースを割り当て、NodeManager が各ワーカーマシンの作業を管理します。今回のストレージの観察には、実行中のジョブは必要ありません。
保存した観察結果を連結し、小さなレポートを作成します。cat は複数のローカル入力パスを順に受け取り、> はそれらを結合した内容を保存します。
cat /home/labex/project/output/default-filesystem.txt /home/labex/project/output/execution-setting.txt /home/labex/project/output/storage-services.txt /home/labex/project/output/storage-report.txt > /home/labex/project/output/environment-report.txt
読み返してみましょう。
cat /home/labex/project/output/environment-report.txt
ファイルシステムの URI、yarn の設定、2つのサービス状態、稼働中のノード数を探してください。これで、実行したコマンドと実際の環境を結び付ける証拠がそろいました。次は、正しいファイルシステムでファイルのライフサイクルを管理します。
まとめ
設定されたファイルシステムと実行方式を調べ、ローカル、明示的な HDFS、既定のパスを使って、データをどこから読んでいるかを確かめました。その結果を、NameNode のメタデータ管理と DataNode の保存の役割に結び付け、1台のマシンによる学習環境の限界も理解しました。
次は、入力を意図どおりに管理します。コピー、アーカイブ、エクスポート、サイズの確認を行い、指定した一時ファイルだけを削除します。
