Hadoop分散ファイルシステム（HDFS）は、コモディティハードウェア上で動作するように設計された分散ファイルシステムです。既存の分散ファイルシステムと多くの類似点があります。しかし、他の分散ファイルシステムとの違いは無視できません。HDFSは非常に耐障害性が高く、低コストのハードウェアに展開するように設計されています。HDFSはアプリケーションデータへの高スループットアクセスを提供し、大規模なデータセットを持つアプリケーションに適しています。HDFSは、ファイルシステムデータへのストリーミングアクセスを可能にするために、いくつかのPOSIX要件を緩和しています。HDFSはもともとApache Nutch Web検索エンジンプロジェクトのインフラストラクチャとして構築されました。HDFSはApache Hadoop Coreプロジェクトの一部です。プロジェクトのURLはhttps://hadoop.dokyumento.jp/です。
ハードウェア障害は例外ではなく、むしろ標準です。HDFSインスタンスは、数百または数千のサーバーマシンで構成され、それぞれがファイルシステムデータの一部を保存します。膨大な数のコンポーネントが存在し、各コンポーネントが故障する可能性があるという事実は、HDFSの一部のコンポーネントが常に機能していないことを意味します。したがって、障害の検出と迅速で自動的な回復は、HDFSの中核となるアーキテクチャ目標です。
HDFS上で実行されるアプリケーションは、データセットへのストリーミングアクセスを必要とします。一般的なファイルシステムで通常実行される汎用アプリケーションではありません。HDFSは、ユーザーによる対話型使用よりもバッチ処理の方が適しています。重点は、データアクセスの低レイテンシではなく、データアクセスの高スループットです。POSIXは、HDFSを対象とするアプリケーションには不要な多くの厳しい要件を課しています。データスループットレートを向上させるために、いくつかの重要な領域におけるPOSIXセマンティクスが変更されています。
HDFS上で実行されるアプリケーションは、大規模なデータセットを持っています。HDFSの典型的なファイルサイズはギガバイトからテラバイトです。そのため、HDFSは大規模ファイルをサポートするように調整されています。単一クラスタで数百ノードにスケールし、高い集約データ帯域幅を提供する必要があります。単一インスタンスで数千万のファイルをサポートする必要があります。
HDFSアプリケーションは、ファイルに対してライトワンスリードマニーアクセスモデルを必要とします。ファイルが作成、書き込み、閉じられた後は、追加と切り詰めを除いて変更する必要はありません。ファイルの末尾へのコンテンツの追加はサポートされていますが、任意の場所で更新することはできません。この前提により、データコヒーレンシの問題が簡素化され、高スループットデータアクセスが可能になります。MapReduceアプリケーションやWebクローラーアプリケーションはこのモデルに完全に適合します。
アプリケーションによって要求された計算は、それが動作するデータの近くに実行される場合、はるかに効率的です。これは、データセットのサイズが非常に大きい場合に特に当てはまります。これにより、ネットワークの輻輳が最小限に抑えられ、システム全体のスループットが向上します。アプリケーションが実行されている場所にデータを移動するのではなく、計算をデータが存在する場所に移動する方が良い場合が多いという前提に基づいています。HDFSは、アプリケーションがデータが存在する場所に移動するためのインターフェースを提供します。
HDFSは、あるプラットフォームから別のプラットフォームに簡単に移植できるように設計されています。これにより、HDFSが幅広いアプリケーションのプラットフォームとして広く採用されることが容易になります。
HDFSはマスター/スレーブアーキテクチャを採用しています。HDFSクラスタは、単一のNameNode（ファイルシステム名前空間を管理し、クライアントによるファイルへのアクセスを制御するマスターサーバー）と、多数のDataNode（通常、クラスタ内のノードごとに1つ、それらが実行されているノードに接続されたストレージを管理する）で構成されています。HDFSはファイルシステム名前空間を公開し、ユーザーデータがファイルに保存されることを許可します。内部的には、ファイルは1つ以上のブロックに分割され、これらのブロックはDataNodeのセットに保存されます。NameNodeは、ファイルやディレクトリの開閉、名前変更などのファイルシステム名前空間操作を実行します。また、ブロックとDataNodeのマッピングも決定します。DataNodeは、ファイルシステムのクライアントからの読み取りと書き込みの要求を処理する役割を担います。また、NameNodeからの指示に基づいて、ブロックの作成、削除、レプリケーションも行います。
NameNodeとDataNodeは、コモディティマシン上で動作するように設計されたソフトウェアです。これらのマシンは通常、GNU/Linuxオペレーティングシステム（OS）を実行します。HDFSはJava言語を使用して構築されています。Javaをサポートするマシンであれば、NameNodeまたはDataNodeソフトウェアを実行できます。非常に移植性の高いJava言語の使用は、HDFSを幅広いマシンに展開できることを意味します。一般的な展開では、NameNodeソフトウェアのみを実行する専用マシンが使用されます。クラスタ内の他の各マシンは、DataNodeソフトウェアの1つのインスタンスを実行します。アーキテクチャは、同じマシン上で複数のDataNodeを実行することを妨げませんが、実際の展開ではめったにありません。
クラスタ内の単一のNameNodeの存在により、システムのアーキテクチャが大幅に簡素化されます。NameNodeは、すべてのHDFSメタデータの仲裁者およびリポジトリです。システムは、ユーザーデータがNameNodeを通過しないように設計されています。
HDFSは従来の階層型ファイル構成をサポートしています。ユーザーまたはアプリケーションは、ディレクトリを作成し、これらのディレクトリ内にファイルを保存できます。ファイルシステム名前空間の階層は、他のほとんどの既存のファイルシステムと同様です。ファイルの作成と削除、ファイルのディレクトリ間の移動、ファイルの名前変更などが可能です。HDFSはユーザークォータとアクセス権限をサポートしています。HDFSはハードリンクまたはソフトリンクをサポートしていません。ただし、HDFSアーキテクチャはこれらの機能の実装を妨げるものではありません。
HDFSはファイルシステムの命名規則に従いますが、一部のパスと名前（例：/.reservedと.snapshot）は予約されています。透過的暗号化やスナップショットなどの機能は、予約済みのパスを使用します。
NameNodeはファイルシステム名前空間を維持します。ファイルシステム名前空間またはそのプロパティへの変更は、NameNodeによって記録されます。アプリケーションは、HDFSによって維持されるべきファイルのレプリカ数を指定できます。ファイルのコピー数は、そのファイルのレプリケーションファクターと呼ばれます。この情報はNameNodeによって保存されます。
HDFS は、大規模クラスタ内のマシン間で非常に大きなファイルを信頼して保存するように設計されています。各ファイルはブロックのシーケンスとして保存されます。ファイルのブロックはフォールトトレランスのためにレプリケートされます。ブロックサイズとレプリケーションファクターはファイルごとに設定可能です。
最後のブロックを除くファイル内のすべてのブロックは同じサイズですが、可変長ブロックのサポートが追加されてから、ユーザーは最後のブロックを設定されたブロックサイズまで埋めずに新しいブロックを開始できるようになりました（append および hsync を使用）。
アプリケーションは、ファイルのレプリカ数を指定できます。レプリケーションファクターはファイル作成時に指定でき、後で変更することもできます。HDFS のファイルは（追加と切り詰めを除いて）ライトワンスであり、いつでも厳密に1つのライターしか持てません。
NameNode は、ブロックのレプリケーションに関するすべての決定を行います。定期的に、クラスタ内の各 DataNode から Heartbeat と Blockreport を受信します。Heartbeat の受信は、DataNode が正常に機能していることを意味します。Blockreport には、DataNode 上のすべてのブロックのリストが含まれています。
レプリカの配置は、HDFS の信頼性とパフォーマンスにとって重要です。レプリカ配置の最適化は、HDFS を他のほとんどの分散ファイルシステムと差別化しています。これは、多くのチューニングと経験が必要な機能です。ラック対応レプリカ配置ポリシーの目的は、データの信頼性、可用性、およびネットワーク帯域幅の利用率を向上させることです。現在のレプリカ配置ポリシーの実装は、この方向への最初の取り組みです。このポリシーを実装する短期的な目標は、本番システムで検証し、その動作についてさらに学び、より高度なポリシーをテストおよび研究するための基盤を構築することです。
大規模な HDFS インスタンスは、多くのラックにまたがるコンピュータークラスタ上で実行されます。異なるラック内の2つのノード間の通信は、スイッチを経由する必要があります。ほとんどの場合、同じラック内のマシン間のネットワーク帯域幅は、異なるラック内のマシン間のネットワーク帯域幅よりも大きくなります。
NameNode は、Hadoop ラック認識で概説されているプロセスを通じて、各 DataNode が属するラック ID を決定します。シンプルだが最適ではないポリシーは、レプリカを固有のラックに配置することです。これにより、ラック全体が故障した場合でもデータの損失を防ぎ、データ読み取り時に複数のラックの帯域幅を使用できます。このポリシーはクラスタ内のレプリカを均等に分散するため、コンポーネント障害時の負荷分散が容易になります。ただし、このポリシーは、書き込みには複数のラックにブロックを転送する必要があるため、書き込みコストが増加します。
レプリケーションファクターが3である一般的な場合、HDFS の配置ポリシーは、ライターがデータノード上にある場合はローカルマシンに1つのレプリカを配置し、それ以外の場合はライターと同じラック内のランダムなデータノードに1つのレプリカを配置し、別のレプリカを異なる（リモート）ラック内のノードに配置し、最後のレプリカを同じリモートラック内の別のノードに配置することです。このポリシーはラック間の書き込みトラフィックを削減するため、一般的に書き込みパフォーマンスが向上します。ラック障害の可能性はノード障害の可能性よりもはるかに低いため、このポリシーはデータの信頼性と可用性の保証に影響を与えません。ただし、ブロックが3つの固有ラックではなく2つの固有ラックに配置されるため、データ読み取り時に使用される合計ネットワーク帯域幅は削減されません。このポリシーでは、ブロックのレプリカはラック全体に均等に分散されません。2つのレプリカは1つのラックの異なるノードにあり、残りのレプリカは他のラックの1つのノードにあります。このポリシーは、データの信頼性や読み取りパフォーマンスを損なうことなく、書き込みパフォーマンスを向上させます。
レプリケーションファクターが3より大きい場合、4番目以降のレプリカの配置は、ラックごとのレプリカ数が上限（基本的に(replicas - 1) / racks + 2）以下になるように維持しながら、ランダムに決定されます。
NameNode は DataNode が同じブロックの複数のレプリカを持つことを許可しないため、作成されるレプリカの最大数は、その時点での DataNode の総数になります。
ストレージタイプとストレージポリシーのサポートが HDFS に追加された後、NameNode は上記のラック認識に加えて、レプリカ配置にポリシーを考慮します。NameNode は最初にラック認識に基づいてノードを選択し、次に候補ノードがファイルに関連付けられたポリシーによって要求されるストレージを持っていることを確認します。候補ノードにストレージタイプがない場合、NameNode は別のノードを探します。最初のパスでレプリカを配置するのに十分なノードが見つからない場合、NameNode は2番目のパスでフォールバックストレージタイプを持つノードを探します。
ここに記載されている現在のデフォルトのレプリカ配置ポリシーは、開発中です。
グローバルな帯域幅消費と読み取りレイテンシを最小限に抑えるために、HDFS は、リーダーに最も近いレプリカから読み取り要求を満たそうとします。リーダーノードと同じラックにレプリカが存在する場合は、そのレプリカが読み取り要求を満たすために優先されます。HDFS クラスタが複数のデータセンターにまたがる場合は、リモートレプリカよりもローカルデータセンターに常駐するレプリカが優先されます。
上記のように、レプリケーションファクターが3の場合、HDFS の配置ポリシーは、ライターがデータノード上にある場合はローカルマシンに1つのレプリカを配置し、それ以外の場合はライターと同じラック内のランダムなデータノードに1つのレプリカを配置し、別のレプリカを異なる（リモート）ラック内のノードに配置し、最後のレプリカを同じリモートラック内の別のノードに配置することです。レプリケーションファクターが3より大きい場合、4番目以降のレプリカの配置は、ラックごとのレプリカ数が上限（基本的に(replicas - 1) / racks + 2）以下になるように維持しながら、ランダムに決定されます。これに加えて、HDFS は4つの異なるプラグ可能なブロック配置ポリシーをサポートしています。ユーザーは、インフラストラクチャとユースケースに基づいてポリシーを選択できます。デフォルトでは、HDFS はBlockPlacementPolicyDefaultをサポートしています。
起動時に、NameNode はセーフモードと呼ばれる特別な状態に入ります。NameNode がセーフモード状態にあるときは、データブロックのレプリケーションは行われません。NameNode は、DataNode から Heartbeat と Blockreport メッセージを受信します。Blockreport には、DataNode がホストしているデータブロックのリストが含まれています。各ブロックには、指定された最小レプリカ数があります。そのデータブロックの最小レプリカ数が NameNode にチェックインしたときに、ブロックは安全にレプリケートされたと見なされます。安全にレプリケートされたデータブロックの構成可能な割合が NameNode にチェックインした後（さらに30秒後）、NameNode はセーフモード状態を終了します。その後、指定されたレプリカ数よりも少ないデータブロック（存在する場合）のリストを決定します。次に、NameNode はこれらのブロックを他の DataNode にレプリケートします。
HDFS 名前空間は NameNode によって保存されます。NameNode は、EditLog と呼ばれるトランザクションログを使用して、ファイルシステムメタデータに対して発生するすべての変更を永続的に記録します。たとえば、HDFS に新しいファイルを作成すると、NameNode はこれを示すレコードを EditLog に挿入します。同様に、ファイルのレプリケーションファクターを変更すると、新しいレコードが EditLog に挿入されます。NameNode は、ローカルホストOSファイルシステム内のファイルを使用してEditLogを保存します。ブロックとファイルのマッピング、ファイルシステムのプロパティを含むファイルシステム名前空間全体は、FsImage と呼ばれるファイルに保存されます。FsImage も NameNode のローカルファイルシステム内のファイルとして保存されます。
NameNode は、ファイルシステム名前空間全体とファイルBlockmapのイメージをメモリに保持します。NameNode が起動するか、構成可能なしきい値によってチェックポイントがトリガーされると、ディスクから FsImage と EditLog を読み取り、EditLog からのすべてのトランザクションを FsImage のメモリ内表現に適用し、この新しいバージョンをディスク上の新しい FsImage にフラッシュアウトします。その後、そのトランザクションが永続的な FsImage に適用されたため、古い EditLog を切り捨てることができます。このプロセスはチェックポイントと呼ばれます。チェックポイントの目的は、ファイルシステムメタデータのスナップショットを取得して FsImage に保存することにより、HDFS がファイルシステムメタデータの一貫したビューを持っていることを確認することです。FsImage を読み取ることは効率的ですが、FsImage に対して直接増分編集を行うことは効率的ではありません。各編集ごとに FsImage を変更する代わりに、編集を Editlog に永続化します。チェックポイント中に、Editlog の変更が FsImage に適用されます。チェックポイントは、秒単位で表される特定の時間間隔（dfs.namenode.checkpoint.period）、または特定数のファイルシステムトランザクションが蓄積された後（dfs.namenode.checkpoint.txns）にトリガーできます。これらのプロパティの両方が設定されている場合、最初に到達したしきい値によってチェックポイントがトリガーされます。
DataNode は、ローカルファイルシステム内のファイルに HDFS データを保存します。DataNode は HDFS ファイルに関する知識を持ちません。ローカルファイルシステム内の個別のファイルに HDFS データの各ブロックを保存します。DataNode は、すべてのファイルを同じディレクトリに作成しません。代わりに、ディレクトリごとの最適なファイル数を決定するヒューリスティックを使用して、適切にサブディレクトリを作成します。すべてのローカルファイルを同じディレクトリに作成することは最適ではありません。ローカルファイルシステムが単一ディレクトリ内の膨大な数のファイルを効率的にサポートできない可能性があるためです。DataNode が起動すると、ローカルファイルシステムをスキャンし、これらのローカルファイルそれぞれに対応するすべての HDFS データブロックのリストを生成し、このレポートを NameNode に送信します。レポートは *Blockreport* と呼ばれます。
すべての HDFS 通信プロトコルは、TCP/IP プロトコルの上に重ねられています。クライアントは、NameNode マシン上の設定可能な TCP ポートに接続を確立します。NameNode と ClientProtocol を使用して通信します。DataNode は、DataNode プロトコルを使用して NameNode と通信します。リモートプロシージャコール（RPC）抽象化は、クライアントプロトコルとデータノードプロトコルの両方をラップします。設計上、NameNode は RPC を開始しません。代わりに、DataNode またはクライアントによって発行された RPC 要求にのみ応答します。
HDFS の主要な目的は、障害が発生した場合でもデータを確実に保存することです。3つの一般的な障害の種類は、NameNode 障害、DataNode 障害、およびネットワークパーティションです。
各 DataNode は、定期的に NameNode に Heartbeat メッセージを送信します。ネットワークパーティションにより、DataNode のサブセットが NameNode との接続を失う可能性があります。NameNode は、Heartbeat メッセージがないことでこの状態を検出します。NameNode は、最近の Heartbeat がない DataNode を死んでいるとマークし、新しい IO 要求を転送しません。死んでいる DataNode に登録されていたデータは、HDFS では使用できなくなります。DataNode の死により、一部のブロックのレプリケーションファクターが指定値を下回る可能性があります。NameNode は、レプリケートする必要があるブロックを常に追跡し、必要に応じてレプリケーションを開始します。再レプリケーションの必要性は、多くの理由で発生する可能性があります。DataNode が使用できなくなる、レプリカが破損する、DataNode のハードディスクが故障する、またはファイルのレプリケーションファクターが増加するなどです。
DataNodeを無効とマークするタイムアウトは、DataNodeの状態の変動によって引き起こされるレプリケーションストームを回避するために、保守的に長く設定されています（デフォルトでは10分以上）。パフォーマンス重視のワークロードでは、設定によってDataNodeを古いものとしてマークする間隔を短くし、読み書き時の古いノードを回避できます。
HDFSアーキテクチャはデータ再バランススキームと互換性があります。あるDataNodeの空き容量が特定のしきい値を下回ると、スキームは自動的にデータをあるDataNodeから別のDataNodeに移動することがあります。特定のファイルに対する需要が突然高まった場合、スキームは動的に追加のレプリカを作成し、クラスタ内の他のデータを再バランスすることがあります。これらの種類のデータ再バランススキームはまだ実装されていません。
DataNodeからフェッチされたデータブロックが破損して到着する可能性があります。この破損は、ストレージデバイスの障害、ネットワーク障害、またはバグのあるソフトウェアによって発生する可能性があります。HDFSクライアントソフトウェアは、HDFSファイルの内容に対するチェックサムチェックを実装しています。クライアントがHDFSファイルを作成すると、ファイルの各ブロックのチェックサムを計算し、これらのチェックサムを同じHDFS名前空間内の別の隠しファイルに格納します。クライアントがファイルの内容を取得すると、各DataNodeから受信したデータが関連するチェックサムファイルに格納されているチェックサムと一致することを検証します。一致しない場合、クライアントは、そのブロックのレプリカを持つ別のDataNodeからそのブロックを取得することを選択できます。
FsImageとEditLogはHDFSの中心的なデータ構造です。これらのファイルが破損すると、HDFSインスタンスが機能しなくなる可能性があります。このため、NameNodeは、FsImageとEditLogの複数の複製の維持をサポートするように設定できます。FsImageまたはEditLogのいずれかの更新は、各FsImageとEditLogが同期的に更新される原因となります。FsImageとEditLogの複数の複製のこの同期更新は、NameNodeがサポートできる名前空間トランザクション毎秒の速度を低下させる可能性があります。ただし、HDFSアプリケーションは非常にデータ集約的であるものの、メタデータ集約的ではないため、この低下は許容範囲内です。NameNodeが再起動すると、使用する最新の整合性のあるFsImageとEditLogを選択します。
障害に対する耐性を高めるもう1つの方法は、NFS上の共有ストレージまたは分散編集ログ（ジャーナルと呼ばれる）を使用して、複数のNameNodeを使用した高可用性を有効にすることです。後者が推奨されるアプローチです。
スナップショットは、特定の時点でのデータのコピーを保存することをサポートしています。スナップショット機能の1つの用途は、破損したHDFSインスタンスを以前に正常だった時点にロールバックすることです。
HDFSは非常に大きなファイルをサポートするように設計されています。HDFSと互換性のあるアプリケーションは、大規模なデータセットを扱うアプリケーションです。これらのアプリケーションはデータを一度だけ書き込みますが、1回以上読み込み、これらの読み込みがストリーミング速度で満たされる必要があります。HDFSは、ファイルに対して書き込み一回読み込み多数のセマンティクスをサポートします。HDFSによって使用される典型的なブロックサイズは128MBです。したがって、HDFSファイルは128MBのチャンクに分割され、可能であれば、各チャンクは異なるDataNodeに存在します。
クライアントがレプリケーション係数が3のHDFSファイルにデータを書込んでいる場合、NameNodeはレプリケーションターゲット選択アルゴリズムを使用してDataNodeのリストを取得します。このリストには、そのブロックのレプリカをホストするDataNodeが含まれています。次に、クライアントは最初のDataNodeに書き込みます。最初のDataNodeはデータの部分を受け取り始め、各部分をローカルリポジトリに書き込み、その部分をリスト内の2番目のDataNodeに転送します。2番目のDataNodeは、順番にデータブロックの各部分を受け取り、その部分をリポジトリに書き込み、その部分を3番目のDataNodeにフラッシュします。最後に、3番目のDataNodeはデータをローカルリポジトリに書き込みます。したがって、DataNodeはパイプライン内の前のDataNodeからデータを受信し、同時にパイプライン内の次のDataNodeにデータを送信できます。このように、データは1つのDataNodeから次のDataNodeにパイプライン化されます。
HDFSは、さまざまな方法でアプリケーションからアクセスできます。ネイティブに、HDFSはアプリケーションで使用するためのFileSystem Java APIを提供します。このJava APIのC言語ラッパーとREST APIも利用可能です。さらに、HTTPブラウザを使用してHDFSインスタンスのファイルを参照することもできます。NFSゲートウェイを使用することにより、HDFSをクライアントのローカルファイルシステムの一部としてマウントできます。
HDFSは、ユーザーデータをファイルとディレクトリの形式で編成することを許可します。ユーザーがHDFSのデータと対話できるようにする、FSシェルと呼ばれるコマンドラインインターフェースを提供します。このコマンドセットの構文は、ユーザーがすでに慣れている他のシェル（bash、cshなど）に似ています。いくつかのサンプルのアクション/コマンドのペアを以下に示します。
| アクション | コマンド |
|---|---|
/foodirという名前のディレクトリを作成する |
bin/hadoop dfs -mkdir /foodir |
/foodirという名前のディレクトリを削除する |
bin/hadoop fs -rm -R /foodir |
/foodir/myfile.txtという名前のファイルの内容を表示する |
bin/hadoop dfs -cat /foodir/myfile.txt |
FSシェルは、スクリプト言語を使用して保存されたデータと対話する必要があるアプリケーションを対象としています。
DFSAdminコマンドセットは、HDFSクラスタの管理に使用されます。これらは、HDFS管理者のみが使用するコマンドです。いくつかのサンプルのアクション/コマンドのペアを以下に示します。
| アクション | コマンド |
|---|---|
| クラスタをセーフモードにする | bin/hdfs dfsadmin -safemode enter |
| DataNodeのリストを生成する | bin/hdfs dfsadmin -report |
| DataNodeを再委託または廃止する | bin/hdfs dfsadmin -refreshNodes |
一般的なHDFSインストールでは、Webサーバーを設定して、設定可能なTCPポートを介してHDFS名前空間を公開します。これにより、ユーザーはHDFS名前空間をナビゲートし、Webブラウザを使用してファイルの内容を表示できます。
FSシェルによって削除されたファイルは、トラッシュ設定が有効になっている場合、HDFSからすぐに削除されません。代わりに、HDFSはそれをトラッシュディレクトリ（各ユーザーには/user/の下に独自のトラッシュディレクトリがあります）に移動します。ファイルは、トラッシュに残っている限り、すぐに復元できます。
最近削除されたファイルは現在のトラッシュディレクトリ（/user/）に移動され、設定可能な間隔で、HDFSは現在のトラッシュディレクトリのファイルのチェックポイント（/user/の下）を作成し、期限切れの古いチェックポイントを削除します。トラッシュのチェックポイントについて詳しくは、FSシェルのexpungeコマンドを参照してください。
トラッシュでの有効期限が切れると、NameNodeはHDFS名前空間からファイルを削除します。ファイルの削除により、ファイルに関連付けられたブロックが解放されます。ユーザーによってファイルが削除される時間と、HDFSの空き容量の対応する増加の時間との間に、かなりの時間遅延がある可能性があることに注意してください。
以下は、FSシェルによってHDFSからファイルがどのように削除されるかを示す例です。deleteディレクトリの下に2つのファイル（test1とtest2）を作成しました。
$ hadoop fs -mkdir -p delete/test1 $ hadoop fs -mkdir -p delete/test2 $ hadoop fs -ls delete/ Found 2 items drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 delete/test1 drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:40 delete/test2
test1ファイルを削除します。以下のコメントは、ファイルがトラッシュディレクトリに移動されたことを示しています。
$ hadoop fs -rm -r delete/test1 Moved: hdfs://127.0.0.1:8020/user/hadoop/delete/test1 to trash at: hdfs://127.0.0.1:8020/user/hadoop/.Trash/Current
今度は、skipTrashオプションを使用してファイルを削除します。これは、ファイルをトラッシュに送らず、HDFSから完全に削除します。
$ hadoop fs -rm -r -skipTrash delete/test2 Deleted delete/test2
これで、トラッシュディレクトリにはtest1ファイルのみが含まれていることがわかります。
$ hadoop fs -ls .Trash/Current/user/hadoop/delete/ Found 1 items\ drwxr-xr-x - hadoop hadoop 0 2015-05-08 12:39 .Trash/Current/user/hadoop/delete/test1
したがって、test1ファイルはトラッシュに移動され、test2ファイルは完全に削除されます。
ファイルのレプリケーション係数を減らすと、NameNodeは削除できる過剰なレプリカを選択します。次のハートビートでこの情報がDataNodeに転送されます。その後、DataNodeは対応するブロックを削除し、対応する空き容量がクラスタに表示されます。繰り返しますが、setReplication API呼び出しの完了とクラスタ内の空き容量の表示との間には、時間遅延がある可能性があります。
Hadoop JavaDoc API。
HDFSソースコード：https://hadoop.dokyumento.jp/version_control.html