インタビュアーを吊るすというhdfsの原則

hdfsアーキテクチャ

意図されました

ファイル名、ファイルディレクトリ構造、ファイル属性（生成時間、コピー数、ファイル権限）などの
ファイルのメタデータ、および各ファイルのブロックリストとブロックが配置されているデータノードを格納します。①fsimage：メタデータミラーファイル。NameNodeメモリのメタデータ情報を一定期間保存します。
②編集：操作ログファイル。
③fstime：最後のチェックポイントの時間を節約します。データ
ノード
は、ファイルブロックデータとデータのチェックサムをファイルシステムに保存します。
セカンダリネームノード
は、hdfsのステータスを監視するために使用される補助デーモンであり、hdfsメタデータのスナップショットを定期的に取得します。

メタ情報の永続性

NameNodeにメタ情報を格納するファイルはfsimageです。システム操作中、メタ情報に対するすべての操作はメモリに保存され、別のファイル編集に保持されます。また、編集ファイルとfsimageファイルはSecondaryNameNodeによって定期的にマージされます（マージプロセスについては、SecondaryNameNodeで詳しく説明します）。

NameNodeの機能

NameNodeを実行すると、大量のメモリとI / Oリソースが消費されます。通常、NameNodeは、ユーザーデータを保存したり、MapReduceタスクを実行したりしません。
システムの設計を簡素化するために、HadoopにはNameNodeが1つしかないため、hadoopクラスターの単一の障害点の問題が発生します。したがって、
NameNodeノードの耐障害性は特に重要です。Hadoopは、それを解決するために次の2つのメカニズムを提供します。

Hadoopメタデータをローカルファイルシステムに書き込んでいる間、リモートでマウントされたネットワークファイルシステム（NFS）にリアルタイムで同期されます。
セカンダリNameNodeを実行します。その役割は、NameNodeと対話し、ログファイルを編集して
名前名ミラーリングを定期的にマージすることです。NameNodeに障害が発生すると、マージされた名前名ミラーリングコピーを通じて回復します。
SecondaryNameNodeによって保存された状態は、常にNameNodeの状態よりも遅れているため、この方法では必然的に一部のデータが失われることに注意してください（これについては後で詳しく説明します）。

SecondaryNameNode

SecondaryNameNodeはNameNodeのバックアップではないことに注意してください。前の紹介からわかるように、すべてのHDFSファイルのメタ情報はNameNodeのメモリに保存されます。NameNodeが起動すると、最初にfsimageがメモリにロードされます。システム操作中、NameNodeのすべての操作もメモリに保存されます。同時に、データの損失を防ぐために、これらの操作は引き続きローカル編集ファイルに保持されます。に。編集ファイルの目的は、システムの運用効率を向上させることです。NameNodeは、メモリ内のメタ情報を更新する前に、編集ファイルに操作を書き込みます。NameNodeの再起動中に、editsとfsimageが一緒にマージされますが、マージプロセスはHadoopの再起動の速度に影響します。SecondaryNameNodeはこの問題を解決するために生まれました。

SecondaryNameNodeの役割は、編集ファイルとfsimageファイルを定期的にマージすることです。マージ手順を見てみましょう。

マージする前に、NameNodeに、すべての操作を新しい編集ファイルに書き込み、edits.newという名前を付けるように指示します。
SecondaryNameNodeはfsimageを要求し、NameNodeから
ファイルを編集します。SecondaryNameNodeはfsimageをマージし、ファイルを新しいfsimageファイルに編集します。NameNodeは、マージされた新しいfsimageを
SecondaryNameNodeから取得し、古いものを置き換え、編集を最初のステップで作成されたedits.newファイルに置き換えます。更新されたfstimeファイルのチェックポイントを置き換え、最後にプロセス全体に関係するNameNodeの関連ファイルを要約します
。fsimage：最後のチェックポイント
編集のHDFSのメタ情報を保存します：最後のチェックポイント以降に発生したことを保存しますHDFSメタ情報ステータス変更情報
fstime：最後のチェックポイントのタイムスタンプが保存されます

hdfs読み取り操作

1.最初に、実際にはDistributedFileSystemのインスタンスであるFileSystemオブジェクトのopenメソッドを呼び出します。

2. DistributedFileSystemは、rpcを介してファイルの最初のブロックの場所を取得します。同じブロックは、繰り返しの数に応じて複数の場所を返します。これらの場所は、hadoopトポロジに従って並べ替えられ、クライアントに最も近い場所が最初にランク付けされます。

3.最初の2つのステップは、DFSInputStreamオブジェクトによってカプセル化されるFSDataInputStreamオブジェクトを返します。DFSInputStreamは、データノードと名前ノードのデータストリームを便利に管理できます。クライアントがreadメソッドを呼び出すと、DFSInputStreamはクライアントに最も近いデータノードを見つけて接続します。

4.データはデータノードからクライアントに継続的に流れます。

5.最初のブロックのデータが読み取られると、最初のブロックへのデータノード接続が閉じられ、次のブロックが読み取られます。これらの操作はクライアントに対して透過的であり、クライアントの視点は単に連続ストリームを読み取ることです。

6.ブロックの最初のバッチが読み取られた場合、DFSInputStreamはnamenodeに移動してブロックのバッチの場所を取得し、読み取りを続行します。すべてのブロックが読み取られた場合、この時点ですべてのストリームが閉じられます。
データの読み取り時にDFSInputStreamとデータノード間の通信が異常である場合、読み取られているブロックの2番目に近い種類のデータノードを試行し、エラーのあるデータノードを記録し、残りのブロックを読み取るときにデータノードを直接スキップします。 。DFSInputStreamは、ブロックデータのチェックサムもチェックします。不良ブロックが見つかった場合は、最初にnamenodeノードに報告され、次にDFSInputStreamが他のデータノード上のブロックのイメージを読み取ります。

クライアントがデータノードに直接接続してデータを取得し、ネームノードが各ブロックに最適なデータノードを提供するように設計されています。ネームノードはブロックロケーション要求のみを処理します。この情報はネームノードのメモリにロードされます。HDFSはデータノードクラスタを介して大量のデータに耐えることができます。同時クライアントアクセス。

hdfs書き込み操作

1.クライアントは、DistributedFileSystemのcreateメソッドを呼び出して新しいファイルを作成します。

2. DistributedFileSystemは、RPCを介してnamenodeを呼び出し、ブロックに関連付けられていない新しいファイルを作成します。作成前に、namenodeは、ファイルが存在するかどうか、クライアントにファイルを作成する権限があるかどうかなど、さまざまなチェックを行います。検証に合格すると、namenodeは新しいファイルを記録します。それ以外の場合は、IO例外をスローします。

3.最初の2つの手順の後、FSDataOutputStreamのオブジェクトが返されます。ファイルを読み取る場合と同様に、FSDataOutputStreamはDFSOutputStreamにカプセル化されます。DFSOutputStreamは、namenodeとdatanodeを調整できます。クライアントはDFSOutputStreamへのデータの書き込みを開始し、DFSOutputStreamはデータを小さなパケットにカットしてから、データキューに配置します。

4. DataStreamerは、データキューを処理して受け入れます。最初に、namenodeの新しいブロックがストレージに最適なデータノードを尋ねます（たとえば、繰り返し回数が3の場合、3つの最適なデータノードを見つけます）。パイプライン。DataStreamerはキュー内のパケットをパイプラインの最初のデータノードに出力し、最初のデータノードはパケットを2番目のデータノードに出力します。

5. DFSOutputStreamには、ack queneと呼ばれるカウンター列もあります。これもパケットで構成され、データノードが応答を受信するのを待機します。パイプライン内のすべてのデータノードが受信したことを示すと、akcqueneは対応するパケットパケットを移動します。取り除く。
書き込みプロセス中にデータノードでエラーが発生した場合、次の手順が実行されます。

1. パイプラインは閉じられています;
   2）パケットの損失を防ぐために、ack quene内のパケットはdata queneに同期されます;
   3）エラーの原因となったデータノード上の現在書き込まれているが未完了のブロックを削除します;
   4）ブロックの残りの部分残りの2つの通常のデータ
   ノードに書き込まれます。5）Namenodeは、このブロックのコピーを作成するために別のデータノードを見つけます。もちろん、これらの操作はクライアントには認識されません。

6.クライアントがデータの書き込みを終了したら、closeメソッドを呼び出して書き込みストリームを閉じます。

7. DataStreamerは、残りのすべてのパッケージをパイプラインにフラッシュし、ackメッセージを待ちます。最後のackを受信した後、DataNodeにファイルを完了としてマークするよう通知します。

注：クライアントが書き込み操作を実行すると、書き込まれたブロックが表示されます。書き込み中のブロックはクライアントに表示されません。syncメソッドを呼び出すことによってのみ、クライアントはファイルの書き込み操作が完了したことを確認できます。クライアントがcloseメソッドを呼び出すと、デフォルトでsyncメソッドが呼び出されます。手動で呼び出す必要があるかどうかは、プログラムのニーズに応じたデータの堅牢性とスループット率の間のトレードオフによって異なります。

hdfsファイルの削除

hdfsファイルの削除プロセスには、通常、次の手順が必要です。

1. NameNodeは、ファイルの削除の開始時に、削除されたファイルの名前を/ trashディレクトリに変更するだけです。名前の変更操作はメタ情報の変更にすぎないため、プロセス全体が非常に高速です。/ trash内のファイルは一定期間（設定可能、デフォルトは6時間）保持されます。この期間中、ファイルは簡単に復元できます。復元は/ trashからファイルを削除するだけで済みます。
2. 指定された時刻になると、NameNodeは名前名からファイルを削除します
3. 削除されたファイルブロックにマークを付けてスペースを解放すると、HDFSファイルシステムの表示スペースが増加します

hdfsファイルの回復

Linuxシステムのリサイクルビン設計と同様に、HDFSはユーザーごとにリサイクルビンディレクトリ（/user/username/.Trash/）を作成し、シェルを介してユーザーが削除したすべてのファイル/ディレクトリは、システムリサイクルビンに1つあります。期間、つまり、システムリサイクルビン内のファイル/ディレクトリが一定期間後にユーザーから応答されない場合、HDFSはファイル/ディレクトリを自動的に完全に削除し、ユーザーはファイル/ディレクトリを見つけることができなくなります。 。HDFS内の特定の実装は、NameNodeでバックグラウンドスレッドEmptierを開始することです。このスレッドは、システムリサイクルビンの下のすべてのファイル/ディレクトリを具体的に管理および監視します。ライフサイクルを超えたファイル/ディレクトリの場合、このスレッドはそれらを自動的に削除します。それらですが、この管理の粒度は非常に大きいです。さらに、ユーザーは手動でリサイクルビンを空にすることもできます。リサイクルビンを空にする操作は、共通のファイルディレクトリを削除するのと同じですが、HDFSは、ファイルディレクトリがリサイクルビンであるかどうかを自動的に検出します。そうである場合、HDFSはもちろんそれを再度配置しません。ユーザーのゴミ箱に

上記の紹介によると、ユーザーはコマンドライン、つまりHDFSのシェルコマンドを使用してファイルを削除しますが、ファイルはHDFSからすぐには削除されません。代わりに、HDFSはファイルの名前を変更し、操作ユーザーのリサイクルビンディレクトリ（hdfsが操作ユーザー名である/user/hdfs/.Trash/Currentなど）に転送します。ユーザーが現在削除しているファイル/ディレクトリがユーザーのリサイクルビンにすでに存在する場合、HDFSは現在削除されているファイル/ディレクトリの名前を変更します。命名規則は非常に単純で、その後に削除されたファイル/ディレクトリの名前が続きます。番号（重複する名前がないことがわかるまで1から）。

ファイルがまだ/user/hdfs/.Trash/Currentディレクトリにある場合は、ファイルをすばやく復元できます。ファイルが/user/hdfs/.Trash/Currentに保存される時間は構成可能です。この時間を超えると、Namenodeは名前名からファイルを削除します。ファイルを削除すると、そのファイルに関連付けられているデータブロックも解放されます。ユーザーがファイルを削除してからHDFSのアイドル状態が増加するまで、待機時間の遅延があることに注意してください。

削除されたファイルがまだ/user/hdfs/.Trash/Currentディレクトリにある場合、ユーザーがファイルを復元したい場合は、/ user / hdfs / .Trash / Currentディレクトリを検索および参照して、ファイルを取得できます。/user/hdfs/.Trash/Currentディレクトリは、削除されたファイルの最新のコピーのみを保存します。/user/dfs/.Trash/Currentディレクトリは、他のファイルディレクトリと同じですが、HDFSはこのディレクトリに特別なポリシーを適用して、ファイルを自動的に削除します。現在のデフォルトポリシーは、6時間以上保持されているファイルを削除することです。この戦略は、将来、構成可能なインターフェイスとして定義されます。

さらに、NameNodeはバックグラウンドスレッド（デフォルトはorg.apache.Hadoop.fs.TrashPolicyDefault.Emptier、またはfs.trash.classnameを介してTrashPolicyクラスを指定できます）を使用して、ユーザーのリサイクルビン内のすべてのファイル/ディレクトリを定期的に空にします。ユーザーのリサイクルビンは、間隔分ごとに空になります。具体的な操作手順は、最初にユーザーリサイクルビンディレクトリ/user/username/.Trashの下のyyMMddHHmmの形式ですべてのディレクトリをチェックし、次に寿命が間隔を超えるディレクトリを削除し、最後に削除されたファイル/ディレクトリが現在保存されているリサイクルビンディレクトリを保存することです。 user / username / .Trash / currentは/user/username/.Trash/yyMMddHHmmに名前が変更されました。
このリサイクルスレッド（Emptier）の実現から、コマンドを使用してユーザーが削除したファイルは、最大でリサイクルビンに入れることができることがわかります。途中で2 *間隔の分を保存します。少なくとも間隔の分を保存できます。この有効期限が過ぎると、ユーザーが削除したファイルは復元されません。

構成

デフォルトで閉じられているHadoopリサイクルビンのゴミ箱

1. conf / core-site.xmlを変更し、追加します

    <property>  
      <name>fs.trash.interval</name>  
      <value>1440</value>  
      <description>Number of minutes between trash checkpoints.  
      If zero, the trash feature is disabled.  
      </description>  
    </property>  

デフォルトは0です。単位分。ここで設定したのは
、データrmを削除してから1日（60 * 24）後、データは現在のフォルダーの下の.Trashディレクトリに移動されます。