膨大な数の低コストサーバー上に構築されたGoogleアプリケーションおよびコンピューティングインフラストラクチャの詳細は、固有の絶え間ない障害により、独自のプライベート分散ファイルシステムGoogle File System（GFS）の開発につながりました。 このシステムは、ストリーミングモードでデータにアクセスする際の障害からの自動回復、高い耐障害性、高いスループットを目的としています。 システムは、大量のデータを処理するように設計されており、格納されたファイルのサイズが大きいことを意味するため、GFSは対応する操作に最適化されています。 特に、実装を簡素化して効率を向上させるために、GFSは標準のPOSIXインターフェイスを実装しません。
GFSの対応は、Hadoop分散ファイルシステムを備えたオープンソースのHadoopプロジェクトでした。 このプロジェクトは、Yahoo（18人）によって積極的にサポートおよび開発されています。 これらのシステムで使用される用語の比較分析を行い、それらの対応を確立し、HDFSについて詳しく説明します。
| HDFS | Gfs | |
| メインサーバー | Namenode | マスター |
| スレーブサーバー | DataNodeサーバー | チャンクサーバー |
| 追加およびスナップショット操作 | - | + |
| メインサーバーの障害後の自動回復 | - | + |
| 実装言語 | Java | C ++ |
HDFSは、Hadoopプロジェクトで使用される分散ファイルシステムです。 HDFSクラスターは、主に、NameNodeサーバーと、データを直接保存するDataNodeサーバーで構成されます。 NameNodeサーバーは、ファイルシステムのネームスペースとデータへのクライアントアクセスを制御します。 NameNodeサーバーをオフロードするために、クライアントとDataNodeサーバー間でのみデータ転送が実行されます。
セカンダリNameNode：
メインNameNodeサーバーは、ファイルシステムメタデータの変更に関連するすべてのトランザクションをEditLogというログファイルにキャプチャします。 メインNameNodeサーバーが起動すると、HDFSイメージ（FsImageファイルにある）を読み取り、EditLogに蓄積されたすべての変更を適用します。 次に、変更が適用された新しいイメージが記録され、システムはクリーンなログファイルで作業を開始します。 NameNodeサーバーは、最初の起動時にこの作業を1回実行することに注意してください。 その後、このような操作はセカンダリNameNodeサーバーに割り当てられます。 FsImageとEditLogは最終的にメインサーバーに保存されます。
複製メカニズム：
NameNodeサーバーがDataNodeサーバーの1つの障害（ハートビートメッセージがないこと）を検出すると、データ複製メカニズムが開始します。
-新しいレプリカ用の新しいDataNodeサーバーの選択
-DataNodeサーバー間でのデータ配置のバランス
レプリカが破損した場合、または各ブロックに固有のレプリカの数が増えた場合にも、同様のアクションが実行されます。
レプリカ配置戦略：
データは、固定サイズの一連のブロックとして保存されます。 デフォルトでは、ブロック（複製）のコピーは複数のサーバーに保存されます（3つ）。 それらの配置は次のとおりです。
-最初のレプリカはローカルノードにあります
-同じラック内の別のノード上の2番目のレプリカ
-別のラックの任意のノード上の3番目のレプリカ
-他のレプリカはランダムに配置されます
データを読み取るとき、クライアントはレプリカを持つ最も近いDataNodeサーバーを選択します。
データの整合性：
ファイルシステムに実装された脆弱なデータ整合性モデルは、レプリカIDを保証しません。 したがって、HDFSはデータ整合性チェックをクライアントに移行します。 ファイルを作成するときに、クライアントは512バイトごとにチェックサムを計算し、その後DataNodeサーバーに保存します。 ファイルを読み取るとき、クライアントはデータとチェックサムにアクセスします。 また、矛盾がある場合は、別のレプリカにアピールします。
データ記録：
「HDFSにデータを書き込むとき、高いスループットを達成するためのアプローチが使用されます。 アプリケーションはストリーミングモードで記録し、HDFSクライアントは記録されたデータを一時ローカルファイルにキャッシュします。 ファイル内の1つのHDFSブロックにデータが蓄積されると、クライアントは新しいファイルを登録するNameNodeサーバーに接続し、ブロックを選択して、ブロックレプリカを保存するためのデータノードサーバーのリストをクライアントに返します。 クライアントは、ブロックデータを一時ファイルからリストの最初のDataNodeサーバーに転送し始めます。 DataNodeサーバーはデータをディスクに保存し、リスト内の次のDataNodeサーバーに送信します。 したがって、データはパイプライン化され、必要な数のサーバーに複製されます。 記録の最後に、クライアントはNameNodeサーバーに通知します。NameNodeサーバーは、ファイルを作成するトランザクションを記録し、その後システムで使用可能になります。
データ削除：
データの安全性のため（操作がロールバックされる場合）、特定の手法に従ってファイルシステムで削除が行われます。 最初に、ファイルはこのために特別に指定された/ trashディレクトリに移動され、一定の時間が経過すると物理的に削除されます。
-HDFS名前空間からファイルを削除する
-データブロックのリリース
現在の欠点：
-障害が発生した場合のメインサーバーの自動起動の欠如（この機能はGFSに実装されています）
-追加操作（バージョン0.19.0で想定）とスナップショットの不足（これらの機能はGFSでも実装されています）
Apache Foundation Webサイトのプロジェクトwikiで、HDFSの今後のバージョンで何が起こるかを読むことができます。 Hadoopを使用している人々の追加情報と意見は、このテクノロジーを積極的に使用している企業のブログ（ Yahoo 、 A9 、 Facebook 、 Last.fm 、 Laboratory）にあります。
ソース：
-Dhruba B. Hadoop分散ファイルシステム、2007年
-トムW. Apache Hadoopのツアー
-Sanjay Ghemawat、Howard Gobioff、およびShun-Tak Leung Googleファイルシステム
-スホロスロフO.V. 分散ストレージおよび大規模データアレイの処理のための新技術
この記事は入門書であり、その目的は、読者に関連する開発の雰囲気を啓発することです。 肯定的なフィードバックおよび/または読者の関心がある場合、いくつかの追加の関連記事を準備します。
- Windows OSでのHadoop Core + Hbaseのインストール（+ REST APIを使用してHbaseとの対話を実装するphpクラス）
- 記事の翻訳：「MapReduce：大規模クラスターでのデータ処理の簡素化」