Zenn
🦝

第３章　HDFSの分散ファイルシステム-3

に公開
Big data
Hadoop
tech

本章では、HDFSにおけるメタデータ管理の仕組み、ならびにSecondary NameNodeによるチェックポイント処理の役割について説明する。

第４節　HDFSメタデータの管理仕組み

4.1　メタデータ管理の概説

メタデータは、HDFSに格納されたデータの様々な属性を記録するものです。例えば、データのサイズ、作成時刻、格納ディレクトリなど情報であり、言わば「スナップ写真」、或いは「管理目録」のような役割を果たす。
　
　データの更新する際には、メタデータ参照することで情報を素早く取得し、更新操作を実行することができる。もちろん、メタデータはデータ自身じゃなく、データとそのバックアップが全ての節点（DataNode）に失われてしまった場合、データの回復はできない。

Fsimage鏡像ファイル：スナップショット（snapshot）形式で保持されたメタデータ。起動時にこれを読み込む。ディスク上に保持されるため、電源が落ちてもデータが失われることはない。
　
　ビッグデータを管理するFsimageファイルは、非常に大きなサイズになることがある。そのため、毎回更新記録をFsimageに反映する処理が遅くなっている。この問題を解決するため、メタデータの記録量と書込み速度のバランスを取る手法として、Editsログを導入されている。更新操作を個別に記録し、効率的に処理する。

Edits編集ログ：ファイルシステムへの変更履歴、全ての更新操作（新規、削除、改修など）を記録するログ。その更新操作は先ずEditsファイルに書き込まれ、この書き込み処理はメモリ上で行う。 一定の量に蓄積されると、Editsの内容をFsimageに統合される。
　
　ディスク上のFsimageファイルと、メモリ上のEditsログを組み合わせることで、完全なメタデータが構成される。

第５節　NNと2NN

メタデータの管理は、NameNodeとSecondaryNameNode2つの節点によって共同で行う。

NameNode：メタデータを保存するところ、クライアントからの要求を処理する。
SecondaryNameNode：NameNodeを補助し、FsimageとEditsを統合する役割を担当する。
　
　本節では、メタデータの処理に関連するNameNode(NN)やSecondaryNameNode(2NN)の動作の仕組みや、メタデータの構造について紹介する。

5.1　メタデータ管理の流れ


NameNode(NN)部分：

  1. 初めてHadoopを起動する際には、初期化を行い、Fsimageファイルを新規作成する必要がある。それ以外の場合は通常通り起動し、NameNodeは最新のFsimageファイルを読み込む。
  2. クライアントから要求を受信する。
  3. NameNodeが変更操作のみを記録する。変更操作は先ずEditsファイルに追記される。ある程度記録が蓄積されると、編集中だったedits_inprogress_001ファイルがedits_001という名前で保存され、編集が終了した状態になる。そして、新たedits_inprogress_002ファイルを作成され、以後の更新記録はこのファイルに書き込まれる。このような一連の流れが、1回の完全の更新処理のサイクルとなる。

Secondary NameNode(2NN)部分：

  1. Secondary NameNodeはNameNodeに対して、更新ログの統合作業が必要かどうかを問い合わせる信号を送信する。
  2. 統合の許可が返された場合、2NNは改めてリクエストを送信する。その統合可否の条件は設定できる。
  3. リクエストを受信したNameNodeは、最新のEditsのログを2NNに転送する。
  4. 編集中のedits_inprogress_002は対象外です。複数のedits_001あるならすべて転送される。
  5. 2NNは、最新の2つのedits_001とFsimageをメモリに書き込んで統合し、新しいFsimage.chkpointファイルを生成する。
  6. 生成したFsimage.chkpointファイルをNameNodeに転送する。
  7. NameNodeは受け取ったFsimage.chkpoint名称を変更して元のFsimageファイルを上書きする。
  8. 今はedits_inprogress_002を除いてFsimageは最新記録になる。
    　
    　上記のようなSecondary NameNodeによるログ統合の一連の処理はCheckPointと呼ばれる。NameNodeのメタデータに関する更新処理は、大部分Secondary NameNodeによって支持する。

5.2　FsimageとEdits

NameNodeサーバー../hadoop-2.9.2/data/tmp/dfs/name/current目録にFsimageとEditsメタデータがある。

  • 末尾番号は225のfsimage_00~0225ファイルと、そのに対尾するedits_00~0223-00~0225のようなEditsログは、1セットの統合済みメタデータです。225までのEditsログは既に統合された。それ以降のEditsログはまだ処理しない。
  • edits_inprogress_00~0256というファイル名は、記録中のまだFsimageに統合されない。
  • Editsログは必ずしも1ファイルずつ統合されるわけではない。複数のEditsログファイル(243〜255)を合わせて一括にEditsに書き込むことも見える。
  • seen_txidファイルには、まだ処理されないEditsファイルの結尾数番号(256)を記録する。Hadoop起動する際、この値を元にどこまで統合が済んでいるかを確認する。
  • VERSIONには、クラスタに関するバージョン情報などの基本情報が保存されている。
    　
    　次VERSIONファイルの内容を紹介する。
cat VERSION


  • edits_inprogressとseen_txidを除いて、NameNodeとファイル結構は大体同じです。

  • 他の普通の節点がメタデータがない。

5.3　FsimageとEdits内容の分析

FsimageおよびEditsがすべて序列化される形式で保存されており、通常のテキストエディタでは内容を直接確認できない。Hadoop公式はこれを反序列化してXML形式で可視化する方法を提供している。
　
　公式URL：Apache Hadoop 2.9.2 – Offline Image Viewer Guide

Fsimage

oivコマンドを使用することでFsimageファイルをXML形式に変換できる。

oiv：Offline Image Viewer View a Hadoop fsimage INPUTFILE using the specified PROCESSOR,saving the results in OUTPUTFILE.

cd /opt/bigdata/servers/hadoop-2.9.2/data/tmp/dfs/name/current

#Hadoopサービス停止状態でも実行でき
hdfs oiv -p XML -i fsimage_0000000000000000253 -o /root/fsimageTest.xml



#ローカルにダウンロード
sz fsimageTest.xml

　
　Notepad++にXMLツールがあれば、XMLファイルを整形して表示する（Ctrl+Alt+Shift+B）。

　
　代替として、Linuxサーバー上で xmlstarlet ツールを利用し、XMLの検査・整形が可能です。

sudo yum install xmlstarlet

もしインストール失敗したら、Centos7のyumの鏡像（mirror）ダウンロードアドレスが失効になったかもしれない。/etc/yum.repos.d/CentOS-Base.repoこのファイルを新しい鏡像アドレスに変更し、依頼を改めてダウンロードしていい。
　
　解決の方法：緊急対応！CentOS 7 サポート終了後のyumエラー解消法 #ShellScript - Qiita」

#既存依頼を消除
sudo yum clean all

#依頼をダウンロード
sudo yum makecache

次、xmlファイルを整形する。

xmlstarlet fo fsimageTest.xml > fsioutput.xml


cat fsioutput.xml

  • <txid>:seen_txid と一致するID値
  • <INodeSection>:メタデータ
  • <inode>:1つのファイルやディレクトリの状態
  • <id>：<inode>の一意な識別子
  • <type>：<inode>のタイプ、DIRECTORYまたはFILEなど。
  • <name>：HDFSにその対象の位置。
  • <mtime>：最終更新時刻（ミリ秒）
  • <permission>：所有者とアクセス権限
    　
    　<inode>のtypeはFILE類の場合、<block>タブが付属し、hsfsTest.txtファイルに対応のブロック情報を持つ。ただ、ブロックの物理的な格納場所が記録されない。クラスタ起動時に、安全モード（safemode）に入り、各DataNodeが自身のブロック情報をNameNodeへ報告する。一定の間隔でブロック情報をNameNodeに送信し、正確な配置が把握される。


　
　<INodeDirectorySection>はファイトとフォルダのディレクトリ構造（親子関係）を表す。<parent> と複数の <child> タグの数字は<inode>のidに対応する。

Edits

もっと分かりやすく説明するために、例を挙げて紹介する。

#フォルダを作成
hdfs dfs -mkdir /EditsTest

#ファイルを導入
hdfs dfs -put /root/wordCountTest.txt /EditsTest

　
　oevコマンドを使ってEditsファイルをXML形式に変換できる。

oev：Offline edits viewer Parse a Hadoop edits log file INPUT_FILE and save results in OUTPUT_FILE

cd /opt/bigdata/servers/hadoop-2.9.2/data/tmp/dfs/name/current

hdfs oev -p XML -i edits_inprogress_0000000000000000289 -o /root/edits.xml


cat edits.xml

　
　2回の更新操作は、赤枠のように示されている。1つ目の<OPCODE>タブにはOP_MKDIRが書かれ、mkdirコマンドに対応してフォルダの作成操作を表す。2つ目にOP_ADDはファイルのアップロードを意味し、それぞれ異なる更新タイプに応じて適切なコードが記録されている。

第６節　checkpoint周期

checkpointの周期は変更可変です。公式ではhdfs-default.xmlにある。dfs.namenode.checkpoint.period引数で設定できると説明されている。しかし実際は、hdfs-default.xmlファイルが存在せず、これはあくまでデフォルト値の定義をまとめた仮想的なファイル名として使われる。本当に役立つのはhdfs-site.xmlファイルです。

　
　以下は、チェックポイントに関する3種類の設定例です。

<!-- 一時的な間隔でのチェックポイント設定（秒単位） -->
<property>
	<name>dfs.namenode.checkpoint.period</name>
	<value>3600</value>
</property>
<!-- 100万件に達したらチェックポイント信号を送信 -->
<property>
	<name>dfs.namenode.checkpoint.txns</name>
	<value>1000000</value>
</property>
<!-- 1分ごとに変更操作の有無を確認 -->
<property>
	<name>dfs.namenode.checkpoint.check.period</name>
	<value>60</value>
</property>

Discussion