HDFSの概要
HDFSは、フォールトトレラント性が高く、スループットの高い分散ファイルシステムであり、安価なマシンへの展開に適しています。
HDFSの設計コンセプト
非常に大きなデータセットのサポート
HDFSで実行されているアプリケーションには、大きなデータセットがあります。HDFSの一般的なファイルサイズは、通常GバイトからTバイトの間です。したがって、HDFSは大容量のファイルストレージをサポートするように設計されており、クラスター内の数百のノードに拡張でき、大量のデータを保存できます。
たとえば、MySQLを使用して100億個のデータを特定のテーブルに保存していますか？マシンの構成の高さを確認してから、クエリの効率を検討します。分散ストレージを使用する場合、つまり、これらのデータはN台以上のマシンに保存され、各マシンはこの100億個のデータの一部のみを保存します。たとえば、マシンは500万個のデータを保存します。HDFSの位置付けは次のとおりです。この巨大なデータセットストレージ。
ハードウェアエラー
HDFSは、数百または数千のサーバーで構成され、各サーバーはファイルシステムデータの一部を格納します。これらのデータを保存しているマシンが故障する可能性は依然として非常に高く、たとえば、ディスクが損傷している、読み取りまたは書き込みができない、ネットワークに障害が発生しているなど、このマシンは正常に動作しません。
したがって、エラー検出と迅速かつ自動の回復がHDFSの主要なアーキテクチャ目標です。HDFSがクラスター内のマシンの問題を検出すると、障害から回復できます。
ストリーミングデータ処理
HDFSで実行されるアプリケーションは、通常作成する通常のアプリケーションとは異なります。HDFSがファイルシステムでデータを読み書きする場合、ストリームの概念に基づいています。いわゆるストリーム処理とは、ファイルをバッチで読み取ることです。低レイテンシのファイルの読み取りと書き込みではなく、高スループットのファイルの読み取りと書き込みを保証するために書き込みます。
HDFSは、オフラインバッチ処理シナリオ、特にデータ分析に使用される現在のオフラインデータウェアハウスで使用されます。現在のオフライン分析では、ソースシステムからHDFSにデータを今朝早く抽出し、処理にはこのデータバッチの処理が含まれます。 1つずつ計算するのではなく、バッチごとに。
簡略化されたデータ整合性モデル
同時に、ファイルの読み取りと書き込みをサポートし、多数の同時実行の競合に対処する必要があります。コードを書き込むときに、読み取りと書き込みのセットに追加される読み取り/書き込みロックについて考えてみてください。追加すると、さらに問題が発生します。HDFSのような大規模なデータセットの分散ストレージの場合、モデルを単純化する必要があります。ファイルの書き込みは1回のみで、その後は追加のみが可能で、以前のデータを簡単に変更することはできません。
したがって、その哲学は次のとおりです。データの読み取りと書き込みの同時実行性の競合が発生しないように、1回の書き込み、何度も準備、1回の書き込み、複数回の読み取り、およびデータの整合性を維持する方法。
このwrite-once、read-manyモデルは、HDFSのスループットを大幅に向上させることもできます。
モバイルコンピューティング、データを移動しないでください
データを読み取るとき、ローカルディスクから、またはネットワーク上の他のマシンからデータを読み取る方が速いでしょうか。データがマシンに近いほど、速度が速くなり、効率が高くなります。
したがって、複数のマシンに分散されたデータでは、分散コンピューティングの場合、クラスター内のネットワークを介してデータを転送するのではなく、コンピューティングタスクをこれらのデータに近づける必要があります。
マスタースレーブモードの分散アーキテクチャ
NameNode 和 DataNode
分散システムの古典的なアーキテクチャはマスタースレーブです。HDFSはこのマスタースレーブアーキテクチャを使用します。HDFSクラスターは1つのNameNodeと複数のDataNodeで構成されます。
NameNodeはプロセス、JVMプロセス、そしてシステムでもあります。NameNodeはこのマスターと考えることができます（大きなスチュワードとして理解できます）。通常のHDFSクラスターには、NameNodeは1つしかありません。ファイルシステムの名前空間とファイルへのクライアントアクセスの管理を担当します。
DataNodeもプロセスです。クラスター内の各マシンにはDataNodeプロセスがあり、主にマシンへのデータの保存を担当します。
ファイルシステムの名前空間
名前空間、理解する方法は？私たちのコンピュータのフォルダに関する限り、保存されるデータはこのディレクトリ-> fileメソッドにあり、ディレクトリは次のレベルのディレクトリである可能性があります。
たとえば、私のコンピュータの次のディレクトリ構造、/ documents / data Warehouse /このディレクトリには、ファイルデータウェアハウスの構築方法xxx.docとディレクトリ/ 12_dataがあり、ディレクトリ/ 12_dataには04_bigデータシステムの技術構造xxx.docがあります。
したがって、ファイルシステムの階層構造とファイルの間の対応する関係は、NameNodeに格納されているいわゆるファイルシステムナムスペースです。
ブロックファイルブロック
HDFSクラスターでは、大きなファイルは分割のためにN個の複数のブロックに分割され、異なるマシンに保存されます。たとえば、1Gの大きなファイルがある場合、HDFSはそれをたとえば128Mに分割し、次に8つのファイルブロックに分割してから、別のマシン、つまりDataNodeに配置します。DataNodeはストアを担当します。これらのファイルブロック。
NameNodeは、ファイルが分割されているファイルブロックの数と、各ファイルブロックが格納されているDataNodeを認識しているため、NameNodeはHDFSクラスターのマスタースチュワードです。
上記の大きなファイルを読みたい場合は、最初にNameNodeのマネージャーに、ファイルが対応するファイルブロックと、各ファイルブロックが配置されている場所を尋ねます。次に、NameNodeが、どのDataNodeがオンになっているかを通知します。対応するDataNodeに。
ファイルシステムのメタデータ永続性管理メカニズム
EditlogとFsImage
HDFSはNameNodeに保存されます。ファイルシステムのメタデータに対する変更操作の場合、NameNodeはEditsLogと呼ばれる操作ログに操作を1つずつ記録します。
たとえば、ファイルがHDFSで作成された場合、Namenodeはそれを示すためにEditlogにレコードを挿入します。同様に、ファイルのコピー係数を変更すると、Editlogにもレコードが挿入されます。Namenodeは、このEditlogをローカルオペレーティングシステムのファイルシステムに保存します。hdfsにディレクトリを作成し、hadoop fs -mkdir -p / usr / dir1、ディレクトリ階層を作成します
次に、データブロックからファイルへのマッピング、ファイル属性などを含むファイルシステムの編成構造全体が、FsImageというファイルに保存されます。このファイルは、Namenodeが配置されているローカルファイルシステムにも配置されます。
NameNodeがメタデータをFsImageファイルに保存する前に、一定期間メモリに保存されます。メタデータが変更されるたびにファイルが書き込まれると、パフォーマンスが非常に低下します。したがって、NameNodeはディスク上のEditlogファイルを時々読み取り、そのすべてをメモリ内のfsimageキャッシュに適用してから、fsimageをディスクに再度ダンプしてから、以前に適用したEditlogファイルを保存します。 。
チェックポイント操作
上記では、編集ログがディスクから読み取られてFsImageに適用され、FsImageがディスクに保存され、最後に編集ログが削除されます。この操作はチェックポイントと呼ばれます。チェックポイント間隔を自分で構成して開始できます。それはNameNodeにあります。そのとき、最初に編集ログとFsimageをディスクから読み取り、メモリにキャッシュされたデータを構築します。
dfs.namenode.checkpoint.period：这个参数配置几秒钟执行一次checkpoint
dfs.namenode.checkpoint.txns：这个参数配置当edits log里有多少条数据的时候，就执行一次checkpoint
复制代码
hadoop1.x時代のSecondaryNameNodeとBackupNode
SecondaryNameNode
Hadoop 1.xの時代、NameNodeが起動すると、FsImageがメモリに読み込まれ、EditsLogのログコンテンツがfsimgaeに復元され、メモリ内のメタデータが最新の状態に保たれ、最新のfsimageが書き込まれます。ディスクを作成し、最後にEditlogファイルをクリアします。
次に、クライアントはHDFSクラスターを継続的に運用しており、NameNodeのメタデータは継続的に変更されます。これらの変更は、メモリ内のFsImageキャッシュを直接変更するためのものであり、メタデータを変更するためのログファイルが編集ログに追加されます。ファイル。。
問題があります。メタデータの変更ログは常に編集ログファイルに追加されます。常に追加されると、どんどん大きくなります。次のNameNodeの再起動と編集ログのマージまで、使用できません。 fsimageを使用します。空です。編集ログが大きい場合、マージに時間がかかり、NameNodeの起動がますます遅くなる可能性があります。
したがって、1つの考え方は、編集ログとfsimageを定期的にマージすることです。マージ後、新しいfsimageをディスクに書き込み、同時に編集ログをクリアして、編集ログが大きくなりすぎないようにします。
したがって、hdfsにはセカンダリNameNodeとしての別の役割があり、別のマシンにデプロイされ、編集ログとfsimageをマージするために専用になり、実行されるたびに実行され、NameNodeに現在の編集ログを書き込まないように指示します。書き込む新しい編集ログ。次に、fsimageファイルをプルしてNameNodeのログをローカルに編集し、それらをメモリにマージし、マージが完了した後にNameNodeにプッシュします。
この操作はいわゆるチェックポイント操作であるため、編集ログが大きくなりすぎることはありません。
BackupNode
BackupNodeは、Hadoop 1.xで提供されるメカニズムでもあります。そのアイデアは、編集ログとfsimageをダウンロードするというチェックポイントのマージされたアイデアを最適化して置き換えることです。
バックアップノードのアイデアは、fsimageデータのコピーをnamenodeと同じメモリに保存すると同時に、NameNodeによって送信された編集ログデータストリームを受信し、それを独自のローカル編集ログに書き込むことです。編集ログデータストリームを取得した後。
同時に、編集ログはユーザーのメモリ内のfsimageに再生されるため、メモリ内のfsimageはネームノードメモリ内のfsimageと同じになります。
また、バックアップノードは定期的にチェックポイント操作を実行し、今回はメモリ内のfsimageを自身のディスクに書き込み、古いfsimageファイルを置き換えてから、編集ログをクリアします。
NameNodeは1つのバックアップノードにのみリンクできます。バックアップノードを使用する利点は、namenodeにそのような編集ログファイルを維持させる必要がなく、自分でディスクに書き込む必要がないことです。 fsimageを独自のメモリに保持し、毎回受信するだけです。メタデータを変更する操作が必要な場合は、メモリ内のfsimageに適用すると同時に、編集ログデータストリームをバックアップノードにプッシュします。
namenodeが再起動するたびに、-importCheckpointを使用してfsimageを他の場所から自分の場所にロードする必要があります。この-importCheckpointデータはバックアップノードから取得されます。
上記はHadoop1.xでのメタデータの管理です。Hadoop2.xはもうそれほど面白くありません。
Hadoop2.x時代のデュアルインスタンスHA高可用性メカニズム
Hadoop1.xメタデータ管理の欠陥
Hadoop 1.xの時代には、メタデータを管理するためにセカンダリNameNodeにリンクされたNameNodeは、メタデータの損失と高可用性の問題を引き起こします。
高可用性の問題。NameNodeに障害が発生するかダウンすると、クラスター全体が使用できなくなります。データ損失の問題。NamaNodeのディスクが損傷すると、ある程度のデータ損失が発生します。最後のチェックポイント以降の編集ログは失われます。
Hadoop 2.xでは、メタデータの損失と高可用性の問題が解決されています。
双NameNode
Hadoop 2.xクラスターは、アクティブ状態とスタンバイ状態の2つのNameNodeを開始します。アクティブ状態がマスターで、スタンバイ状態がスタンバイであることがわかります。すべてのクライアント操作はアクティブ状態のNameNodeに送信され、スタンバイ状態のNameNodeは、アクティブなNameNodeがメタデータを継続的に同期するためのホットスタンバイとして使用されます。
ジャーナルノード
スタンバイ状態のNameNodeは、NameNodeにメタデータを直接要求しません。また、編集ログを格納する仲介者であるJournal Nodeもあります。通常、Journal Nodeも、3から始まるクラスターです。
NameNodeにメタデータの変更があると、編集ログがジャーナルノードクラスター内のほとんどのノードに書き込まれます。たとえば、現在3つのジャーナルノードクラスターがあり、ほとんどのノードは3/2 + 1 = 2です。つまり、NameNodeが編集ログを2つのクラスターに書き込む場合、書き込みは成功したと見なされます。
その後、StandbyNameNodeは、JournalNode内の編集ログの変更を常に監視します。変更がある限り、新しい編集ログをローカルにプルしてから、それを独自のメモリに適用し、アクティブなNameNodeとの整合性を保ちます。
アクティブなNameNodeが電話を切ると、スタンバイのNameNodeはすぐにそれを認識し、ジャーナルノードからすべての編集ログを読み取り、メモリ内のfsimageも最新のデータであることを確認してから、アクティブなNameNodeに切り替えます。 NameNode。
このようにして、データ損失の問題が解決されます。一方のマシンがダウンし、もう一方のマシンがすぐにアクティブなネームノードに切り替えられて、外部にサービスを提供し続け、高可用性の問題も解決されます。
ZKFC（ZKFailoverController）
では、1つが失敗した後、2つのNameNodeが自動的に切り替わるにはどうすればよいでしょうか。
これは、ZKFailoverControllerプロセス（略してZKFC）に依存しています。各NameNodeにはZKFCプロセスがあり、2つのNameNodeのステータスを常に監視し、Zookeeperで2つのNameNodeのステータスを維持します。
アクティブなNameNodeがダウンしている場合、ZKFCのHealthMonitorがそれを監視し、ZKFCのFailoverControllerがNameNodeにダウンしていることを通知し、FailoverControllerが再選出するActiveStandbyElectorコンポーネントを見つけます。
ActiveStandbyElectorは、zkに基づいてスタンバイNameNodeをメインNameNodeとして再選出します。
次に、zkはスタンバイNameNode上のZKFCのActiveStandbyElectorコンポーネントに通知し、FailoverControllerにスタンバイ状態をアクティブ状態に切り替えるように通知し、FailoverControllerにNameNodeにアクティブなNameNodeに切り替えるように通知します。
このようにして、アクティブとスタンバイを切り替えることができ、HAが実現されます。
Hadoop 2.xHAデュアルインスタンスはメタデータをどのように管理しますか
Hadoop 1.xでは、バックアップノードは定期的にチェックポイント操作を実行し、今回はメモリ内のfsimageを自身のディスクに書き込み、古いfsimageファイルを置き換えてから、編集ログをクリアします。
Hadoop 2.xでは、スタンバイNameNodeは実際には1.xのバックアップノードに似ており、チェックポイント操作を定期的に実行します。
スタンバイNameNodeは、CheckpointerThreadと呼ばれるバックグラウンドスレッドを実行します。これはデフォルトで1時間に1回です。または、100万の編集ログがfsimageにマージされない場合、チェックポイント操作が実行されます。
メモリ内の最新のfsimageをディスクに書き込み、編集ログをクリアし、最後に最新のfsimageファイルをアクティブなNameNodeにプッシュして、アクティブなNameNodeの古いfsimageを置き換え、アクティブなNameNodeの古い編集ログファイルもクリアします。
大きなファイルデータの分散ストレージメカニズム
非常に大きなファイルをアップロードする必要がある場合、hdfsクライアントがアップロードコマンドを送信すると、NameNodeは最初にファイルのサイズに応じてファイルを複数のブロックに分割します。2.xのデフォルトは128 M、1.xです。 64M。
NameNodeは、各ブロックファイルがどのDataNodeに保存されるかを計画します。各DataNodeのデータ保存状況に応じて可能な限りデータを配布し、hdfsクライアントがファイルブロックを各DataNodeにアップロードします。DataNodeの後データを受信すると、これらのファイルブロックを異なるファイルディレクトリに保存します。これらのファイルブロックを保存するための特定の階層構造を確立し、フォルダの下に配置しません。
DataNodeが起動すると、ローカルファイルのデータディレクトリもスキャンし、保持しているファイルのファイルブロックリストをNameNodeに報告します。
コピーベースのフォールトトレランスメカニズム
ブロック分割に基づいて大きなファイルを保存するために、ストレージの問題は解決され、問題はありません。ただし、別の問題があります。過剰なリソース消費、ダウンタイム、再起動など、マシンがダウンした場合、このマシンに保存されているブロックにアクセスできません。元々、ファイルは10個のブロックに分割されていましたが、現在は1個です。障害があり、通常のブロックは9つしかないため、クライアントが読み取ると、データは不完全になります。
コピーメカニズム
したがって、フォールトトレランスのために上記のクラスター間のさまざまなマシン障害を解決する方法は、コピーメカニズムです。
HDFSにはレプリケーションファクターと呼ばれるパラメーターがあります。これは、各ブロックがコピーされて異なるマシンに配置されることを意味します。一方のマシンのダウンタイムは影響せず、もう一方のマシンはまったく同じバックアップを持ちます。
HDFSがファイルを書き込むとき、各ブロックにはデフォルトで3つのコピーがあります。NameNodeは最初に3つのDataNodeを選択します。各DataNodeはブロックを配置してクライアントに返します。次に、クライアントはブロックを最初のDataNodeに送信します。 DataNodeはこのブロックをローカルに書き込みます。このDataNodeはブロックを2番目のDataNodeにコピーします。2番目のDataNodeがローカルに書き込んだ後、ブロックを3番目のDataNodeにコピーします。
ラックの認識
HDFSクラスター内のマシン間の通信は通信です。マシンとマシンは異なるラックに存在する場合があります。同じラック上のマシン間のデータ転送は、異なるラック上のマシンよりも確実に高速です。
通常、ブロックにはデフォルトで3つのコピーがあり、NameNodeは1つのラックのマシンに2つのコピーを配置し、別のラックのマシンに1つのコピーを配置します。
同じラックでのデータ転送は非常に高速です。もう1つのポイントは、ラック上のすべてのマシンがダウンしている場合でも、他のラック上のマシンにこのブロックのコピーがあり、通常どおりサービスを提供できることです。
セーフモード
NameNodeが起動したばかりの場合、セーフモード、セーフモードと呼ばれるモードに入ります。このモードでは、hdfsクラスターはブロックレプリケーションを実行しません。
このとき、NameNodeは各DataNodeからハートビートとブロックのレポートを取得するのを待ってから、クラスター内の全体的なブロックの状況と、各ブロックのコピー数を確認します。ブロックの場合、デフォルトでは3つのコピーがあります。 3つのコピーがありますそれなら大丈夫です安全です
ブロックの特定の割合（80％）に十分な3つのコピーがある場合、namenodeはセーフモードを終了します。
NameNodeは、特定の比率に達していないため、常にセーフモードになっています。たとえば、ブロックの50％のみが3つのコピーを持っています。
このとき、特定のブロックのコピー数が不足していることが判明した場合（たとえば、コピーが2つしかない場合）、十分なコピーを複製するようにDataNodeに指示します。
連邦メカニズム
HDFS内のすべてのファイル、ディレクトリ、および構成情報はNameNodeに格納されます。HDFSクラスターに数万から数十万のユニットがある場合、データの量は非常に多く、メタデータのサイズは数百ギガバイトになる可能性があります。 。NameNodeでは明らかに実行可能ではありません。
この問題を解決するために、HDFSはフェデレーションメカニズムを開発しました。つまり、クラスター内に複数のNameNodeがあり、各NameNodeはメタデータの一部を格納します。メタデータがどのように上昇しても、NameNodeマシンは水平方向にスケーリングできます。問題を解決します。多くの企業がこの連邦メカニズムを使用しておらず、この規模を持っていないという状況があります。
フェデレーションメカニズムでは、アクティブな各NameNodeがメタデータの一部を格納し、スタンバイのNameNodeがアクティブな各NameNodeに接続されます。これにより、水平方向の拡張と高可用性の問題が解決されます。
複数のNameNodeがありますが、DataNodeのセットがあり、ブロックはDataNodeクラスターに格納されます。これは、各DataNodeがハートビートとブロックレポートをすべてのNameNodeに報告することを意味します。
hdfs-11.png
フォローしてください
**花火を味わいながら、世界はそれだけの価値があると信じてください。****
元のリンク：https：//juejin.cn/post/6915947365648039950
この記事がお役に立てば幸いです。私の公式アカウントをフォローし、キーワード[インタビュー]に返信して、Javaのコアナレッジポイントとインタビューギフトパッケージをまとめてください。共有する技術的な乾物の記事や関連資料がもっとあります。みんなが一緒に学び、進歩できるようにしましょう！
