はじめに
小売業者のファイルには名前とディレクトリがありますが、マシンはその内容もどこかに保存する必要があります。1つの大きなファイルを複数のストレージノードにどう分けるのでしょうか？ HDFS が複製を保持するときは何をコピーするのでしょうか？ また、ほとんど空のブロックでも、ブロック全体に相当するディスク領域を予約するのでしょうか？
ファイルの整理と保管はすでに学びました。この実験では、パスの下にある仕組みを調べます。HDFS のブロックは、HDFS が追跡し、保存するファイルの一部分です。NameNode はファイルとブロックの場所に関するメタデータを保持し、DataNode はブロックのデータを保持します。レプリカ（複製）とはブロックの保存用コピーであり、新しい売上記録や、ユーザーに見える別のファイルではありません。
意図的に小さく、かつ使用可能なブロックサイズを指定して、準備済みの2ファイルをアップロードします。ブロック数を予想し、実際の保存場所を確認しましょう。この環境では DataNode は1つで、レプリケーション係数は1です。実際の観察はできますが、複数マシンによる復旧を実演するものではありません。データとサービスは独立して準備済みです。ターミナルを使い、プログラミングは必要ありません。
ファイルサイズとブロックを結び付ける
このステップでは、既知のブロックサイズでファイルをアップロードし、そのメタデータを調べます。
ファイルシステムのパスは論理的なファイルを指します。HDFS はその内容をブロックに分けることで、大きなクラスターでは各部分を別の DataNode に保存できるようにします。設定されたブロックサイズは、1ブロックに入るデータの最大サイズであり、すべてのブロックが満杯になるという意味ではありません。
プロジェクトディレクトリから始めます。
cd /home/labex/project
ローカルの wc -c はバイト数を数えます。最初の準備済みファイルに対して実行します。
wc -c /home/labex/project/data/products-a.txt
結果は 1572864 で始まり、ちょうど 1.5 MiB です。MiB は 1,048,576 バイトを表します。このファイルは、保存の実験に複雑な業務ルールが入らないよう、単純な商品ラベルを繰り返しています。
自分用の HDFS ディレクトリを作成します。
hdfs dfs -mkdir -p /user/labex/block-study
この実演では、-Ddfs.blocksize=1048576 により、続くアップロードでクライアントのブロックサイズ設定を上書きします。-D はこのコマンドの設定プロパティを指定するもので、共有の設定ファイルは編集しません。1 MiB はこのイメージの最小ブロックサイズの制限を満たし、実験を小さく保てます。
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-a.txt /user/labex/block-study/products-a.txt
配置を予想してみましょう。1.5 MiB のファイルを 1 MiB のブロックで保存すると、満杯のブロック1つと半分まで入ったブロック1つで、2つのブロックが必要です。
HDFS の -stat は、選択したメタデータを表示します。引用符内の書式で、%b はファイルのバイト数、%o はブロックサイズ、%r はレプリケーション係数です。
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt
期待される値は次のとおりです。
bytes=1572864 blocksize=1048576 replication=1
ファイルの長さは引き続き 1.5 MiB です。レプリケーション係数1は、各ブロックの保存コピーが1つという意味であり、ファイル全体が1ブロックという意味ではありません。実際のメタデータを保存します。
hdfs dfs -stat 'bytes=%b blocksize=%o replication=%r' /user/labex/block-study/products-a.txt > /home/labex/project/output/file-a-metadata.txt
アップロードが完了してファイルがすでにある場合は、再度アップロードする前に内容を確認してください。-put が保存先の存在を通知したというだけで削除してはいけません。
保存場所を調べて変化を予想する
このステップでは、最初のファイルの実際のブロックを確認し、より大きいファイルで予想を確かめます。
hdfs fsck はファイルの保存状態を調べるコマンドです。以下は読み取り専用の確認です。-files はファイルの詳細、-blocks はブロック情報、-locations は各ブロックを保持する DataNode を表示に含めます。これらのオプションは、ファイルの修復や削除を行いません。
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations
ファイルの長さを示す行、各ブロックの項目、集計の Total blocks (validated) 欄を探してください。ブロックは2つあるはずです。1つは 1,048,576 バイト、もう1つは 524,288 バイトです。ブロック識別子、アドレス、タイムスタンプは変わります。最後のファイルシステムの健全性のまとめは HEALTHY になるはずです。
確認結果を保存します。
hdfs fsck /user/labex/block-study/products-a.txt -files -blocks -locations > /home/labex/project/output/file-a-blocks.txt
健全という結果は、この確認で必要なブロックと複製が見つかったことを示します。1台のマシンに各ブロック1つのコピーがある構成では、そのマシンが失われてもファイルが残るという意味ではありません。
次に、2つ目のローカルファイルのサイズを調べます。
wc -c /home/labex/project/data/products-b.txt
長さは 2621440 バイト、つまり 2.5 MiB です。アップロードの前に、同じ 1 MiB のブロックサイズで、ブロックの数とサイズを予想してください。変わるのはファイルの長さだけです。
hdfs dfs -Ddfs.blocksize=1048576 -put /home/labex/project/data/products-b.txt /user/labex/block-study/products-b.txt
結果を調べます。
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations
満杯のブロック2つと 524,288 バイトのブロック1つの、計3つが見つかるはずです。この実験では、すべての場所が同じ DataNode を指します。観察結果を保存します。
hdfs fsck /user/labex/block-study/products-b.txt -files -blocks -locations > /home/labex/project/output/file-b-blocks.txt
大きなクラスターでは、ブロックの保存先が複数のマシンに分かれることがあります。NameNode はクライアントに場所のメタデータを提供しますが、ファイル内容のすべてのバイトが通過する中央の通り道ではありません。
容量、複製、データの経路を読み解く
このステップでは、観察したブロックを、ファイルサイズと実際のストレージノードのレポートに結び付けます。
ブロックサイズの設定が 1 MiB でも、半分までしか入っていない最後のブロックが、データ用に 1 MiB 全体を予約するわけではありません。-h なしの -du を使い、正確なバイト数を表示します。
hdfs dfs -du /user/labex/block-study
各ファイルの最初の2列は、次のようになるはずです。
1572864 1572864 .../products-a.txt
2621440 2621440 .../products-b.txt
1列目は論理的なファイルの長さで、2列目は複製を考慮した値です。ここではレプリケーション係数が1なので一致します。これらは HDFS のファイルデータの値であり、ファイルシステムの全メタデータや VM 全体のディスク使用量を示すものではありません。行を保存します。
hdfs dfs -du /user/labex/block-study > /home/labex/project/output/block-report.txt
環境を調べる実験で紹介した、読み取り専用の管理コマンドで、実際のストレージノードのレポートを確認します。
sudo -u hdfs /usr/local/bin/hdfs dfsadmin -report
Live datanodes (1) を探してください。レプリケーション係数を3にしても、マシンが3台できるわけではありません。この実験では、用意できない複製をブロックが待つ状態にせず、係数を1に保ちます。
観察結果とデータの経路を結び付けて考えましょう。
書き込み：クライアントが NameNode にファイル作成を依頼し、DataNode にブロックデータを送る。
読み取り：クライアントが NameNode に場所を問い合わせ、DataNode からブロックデータを読む。
大きなクラスターに複数の複製があると、クライアントは利用可能なコピーを使えます。また、処理フレームワークは、できるだけデータの近くで作業を実行しようとします。この考え方をデータ局所性と呼びます。-cp で作った別名のコピーは、2つ目の論理的なファイルです。一方、レプリカは1つの論理的なファイル内のブロックの保存用コピーです。それぞれ解決する問題が異なります。
予想の練習で変えたのはファイルサイズであり、レプリケーション係数ではありません。ファイル A は2ブロック、ファイル B は3ブロックで、どちらも各ブロックのコピーは1つです。次は、ファイルが存在し、健全でも、あるユーザーには読めない理由となるアクセス権限を学びます。
まとめ
1.5 MiB と 2.5 MiB のファイルが、1 MiB のブロック2つと3つに分かれることを予想し、観察しました。実際のブロックの場所を調べ、論理的なファイルの長さ、複製の保存領域、別名のファイルを区別しました。
また、これらの結果を NameNode のメタデータと DataNode の転送に結び付けました。単一ノードの環境で各役割を確認できましたが、複数マシンによる容量の拡張や耐障害性は、今後さらに学ぶ内容です。
