Javaビッグデータへの道～HDFS詳細解説(2)～技術詳細

HDFS (分散ファイル ストレージ システム) -- 技術的な詳細

目次

HDFS (分散ファイル ストレージ システム) -- 技術的な詳細

1. HDFS アーキテクチャ

2.ブロック

三、NameNode

4. コピー配置戦略

5. ラック認識戦略

6. データノード

7、SecondaryNameNode

---

1. HDFS アーキテクチャ

1. HDFS では、データを保存するときにデータがブロックに分割され、各ブロックはブロックと呼ばれます。
2. それ自体は分散型でスケーラブルで信頼性の高いファイル システムです
3. HDFS には、NameNode (ノードの管理とメタデータの記録に使用)、DataNode (データの保存に使用)、SecondaryNameNode の 3 つの主要プロセスが含まれています。これら 3 つのプロセスは通常、異なるホストに分散されているため、プロセスの名前を使用してノードを呼び出すのが一般的です。
4. HDFS は、データを自動的に 2 回バックアップします。これをレプリケーションと呼びます。指定しない場合、コピー数はデフォルトで 3 になります (追加の 2 コピーにオリジナルを加えて 3 コピーになります)。

 

2.ブロック

1. HDFS では、データはブロックに保存されます
2. デフォルトでは、Hadoop1.0 のブロックのサイズは 64M、Hadoop2.0 のブロックのサイズは 128M で、サイズは dfs.blocksize によって調整されます。
3. ファイルがブロック サイズより小さい場合、ファイル全体がブロックとして保存され、ブロック サイズはファイル サイズと一致します。
4. ダイシングの利点:
   1. ファイル ブロックは異なるノードに保存でき、非常に大きなファイルを保存できます。
   2. データのレプリケーションと迅速なバックアップに役立ちます (大きなファイルを分割し、ノードごとにコピーします)。
5. ブロックの異なるコピー (Block) は異なるノード上に存在する必要があり、異なるブロックのコピーは 1 つのノード上に存在することもできます。

三、NameNode

1. NameNode は HDFS のコア ノードであり、DataNode の管理とメタデータの保存に使用されます。
2. NameNode は、HDFS でメタデータ情報を維持します。
   1. ファイルストレージパス
   2. ファイルのアクセス許可
   3. ファイルサイズとブロックサイズの情報
   4. ブロックID
   5. BlockとDataNode（ノード）の関係情報
   6. 部数
   7. メタデータ形式のリファレンス: FileName レプリカ ブロック ID id2host。例: /test/a.log,3,{b1,b2},[{b1:[h0,h1,h3]},{b2:[h0,h2,h4]}]
3. 各メタデータのサイズは約 150B です
4. NameNode はメタデータをディスクだけでなくメモリにも保存します。
   1. メモリに保存する目的は、高速なクエリのためです。
   2. クラッシュリカバリのためにディスクに保存される

5. メタデータ情報は NameNode ノードのハードディスクに永続化され、永続ディレクトリのパスはcore-site.xml の dfs.tmp.dir 属性によって決定されます。このパラメータが設定されていない場合、デフォルトで /tmp に配置されます。

6. メタデータを保存するディレクトリ: dfs/name/current

7. 永続化ファイルには次のものが含まれます。
   1. fsimage: メタデータ イメージ ファイル。NameNode メタデータ情報を保存しても、メモリ内のデータはリアルタイムで同期されません。一般に、fsimage のメタデータはメモリ内のメタデータよりも遅れます。
   2. 編集: NameNode によって実行される操作を記録する操作ログ ファイル
8. NameNode が書き込み操作を受け取ると、最初にこのコマンドを編集に記録し、次にメモリ内のメタデータを変更します。変更が成功すると、クライアントに成功シグナルを返します。実際には fsimage には記録されません時間はかかりますが、更新する前に特定の条件を満たす必要があるため、fsimage はメモリ内のメタデータよりも遅れることがよくあります。この設計の目的は、操作の信頼性を確保することです。記録が成功している限り、この操作は確実に実行されます。 。
9. メモリ内のデータが増えていくと fsimage が更新されず、データの差分がどんどん増えてしまいます fsimage が更新されると、編集ファイル内の操作を 1 つずつ取り出して再実行しますfsimageで。この時点で、edits_inprogress は編集ファイルにロールされ、新しい操作を記録するために新しい edits_inprogress が生成されます。
10. fsimage はスクロール トリガー条件を更新および編集します。
    1. スペース: 編集ファイルが指定されたサイズ (デフォルトは 64M、このサイズは fs.checkpoint.size----core-site.xml で調整できます) に達すると、編集ファイルのスクロールがトリガーされます。
    2. 時間: 最後のスクロール間隔から指定した時間 (デフォルトは 3600 秒、この時間は fs.checkpoint.period -----core-site.xml で調整可能) が経過すると、編集ファイルのスクロールがトリガーされます。
    3. 再起動: ロールオーバーは、NameNode が再起動するとトリガーされます。
    4. 必須: 編集ファイルは、hadoop dfsadmin -rollEdits コマンドによって強制的にロールスルーされます。
11. DataNode は、RPC ハートビート メカニズムを通じて NameNode に登録および管理します --- DataNode は定期的に (3 秒ごとに) ハートビート情報を NameNode に送信します。
12. ハートビート情報:
    1. 現在の DataNode のブロック情報
    2. 現在のデータノードのステータス (サービス前、サービス、廃止前、廃止中 (ノードは廃止ステータスを送信できません。最初の 3 つは送信できます))
13. NameNode が 10 分以内に DataNode からハートビートを受信しない場合、DataNode が失われたとみなして、このノード上のデータ (他のノード上のコピー) を他のノードにバックアップして、コピー数を確保します。クラスター全体
14. NameNodeの再起動後、fsimageファイルの更新/編集ファイルのロールを行い、fsimageファイルの内容をメモリにロードし、DataNodeのハートビートを待ちますが、指定時間内にハートビートを受信しない場合は、ハートビートが発生したものとみなされます。データノードが失われたため、対処する必要があります。処理中、ハートビートに達すると、ネームノードはデータノードのデータを検証し、データノード内のデータがメタデータ レコードと一致しているかどうかを検証します。検証が失敗した場合は、データの復元を試みてください。復旧後に再度確認させていただきます。検証が成功した場合はサービスが外部に提供され、そうでない場合は読み取りサービスのみが外部に提供されます。---------この処理をセーフモード（セーフモード）といいます。
15. セーフ モードでは、HDFS クラスターは読み取りサービスのみを外部に提供します。
16. レプリカの数がノードの数を超えてはいけないというセキュリティ モードの検証の問題もあります。
17. クラスターが適切な時間内にセーフ モードを自動的に終了しない場合、データ損失が発生している可能性があり、このデータは回復できません。
18. セーフ モードを強制終了する: hadoop dsfadmin -safemode Leave
19. 参考文献

4. コピー配置戦略

1. 最初のコピー:
   1. クラスター内にアップロードされた場合、最初のコピーをアップロードした人がその人に属します。
   2. クラスターの外にアップロードされた場合、最初のコピーは比較的アイドル状態のノードに配置されます。
2. 2 番目のコピー:
   1. Hadoop2.7 より前: 2 番目のコピーは、最初のコピーとは異なるラック内のノードに配置されます (ラック全体のダウンを防ぐため)。
   2. Hadoop2.7 の開始: 2 番目のコピーは最初のコピーと同じラックに配置されます (ラック内の高速伝送) ノード
3. 3 番目のコピー:
   1. Hadoop2.7 以前: 3 番目のコピーは 2 番目のコピーと同じラックに配置されます (ラック内の高速伝送) ノード
   2. Hadoop2.7 の開始: 3 番目のコピーは 2 番目のコピーとは別のラックのノードに配置されます (ラック全体のダウンを防ぐため)
4. さらにコピー:
   1. 誰が誰を怠けているのか

5. ラック認識戦略

1. いわゆるラックは物理ラックではなく論理ラックであり、本質的にはマッピングです。
2. 異なる物理ラックのノードを同じ論理ラックにマッピングできます。
3. 実際のプロセスでは、同じ物理ラックのノードは同じ論理ラックにマッピングされます。

6. データノード

1. ストレージブロック
2. DataNode が NameNode にハートビートを送信する
3. ブロックを保存するパスも hadoop.tmp.dir プロパティによって変更されます

7、SecondaryNameNode

1. SecondaryNameNode は NameNode のバックアップではありません。このノードの役割は、NameNode が編集ファイルのロールオーバーを完了できるように支援することです。
2. 完全分散では、SecondaryNameNode が表示されると、編集ファイルのスクロールは SecondaryNameNode 上で実行されます。SecondaryNameNode がない場合、編集ファイルのスクロールは NameNode 自体によって完了します。
3. HDFS クラスターでは、SecondaryNameNode の役割を NameNode に置き換えることができるため、NameNode+SecondaryNameNode 構造またはデュアル NameNode 構造のみを採用できますが、コア ノードとして NameNode が 1 つだけの場合は、単一障害点となるため、SecondaryNameNode は実際のプロセスで破棄されることがよくあります。 デュアル NameNode 構造を使用して NameNode HA (高可用性) を形成します。