• はじめに Introduction
• 前提と目的 Assumptions and Goals
  • ハードウェア障害 Hardware Failure
  • ストリーミングデータアクセス Streaming Data Access
  • 大規模データ集合 Large Data Sets
  • シンプルで一貫性のあるモデル Simple Coherency Model
  • “データの移動よりも、計算の移動のほうが効率的” “Moving Computation is Cheaper than Moving Data”
  • 異なるハードウェア、ソフトウェアプラットフォーム間での可搬性 Portability Across Heterogeneous Hardware and Software Platforms
• 名前ノードとデータノード Namenode and Datanodes
• ファイルシステムの名前空間 The File System Namespace
• データレプリケーション Data Replication
  • レプリカの配置：初期化ステップ Replica Placement: The First Baby Steps
  • レプリカの選定 Replica Selection
  • セーフモード SafeMode
• ファイルシステムのメタデータの永続性 The Persistence of File System Metadata
• コミュニケーションプロトコル The Communication Protocols
• 頑健性 Robustness
  • データディスク障害、ハートビート、再レプリケーション Data Disk Failure, Heartbeats and Re-Replication
  • クラスターの再バランシング Cluster Rebalancing
  • データの無欠性 Data Integrity
  • メタデータディスク障害 Metadata Disk Failure
  • スナップショット Snapshots
• データ管理 Data Organization
  • データブロック Data Blocks
  • ファイル作成段階 Staging
  • レプリケーションのパイプライン Replication Pipelining
• 利便性 Accessibility
  • DFSShell DFSShell
  • DFSAdmin DFSAdmin
  • ブラウザインターフェイス Browser Interface
• 領域の再利用 Space Reclamation
  • ファイル削除と復元 File Deletes and Undeletes
  • レプリケーション因子の縮小化 Decrease Replication Factor
• 参考文献 References

Hadoop分散ファイルシステム（HDFS）は一般的なハードウェア上で動作するように設計された分散ファイルシステムである。 HDFSは既に存在する分散ファイルシステムと多くの類似点をもつ。 しかし、他の分散ファイルシステムとの違いが重要である。 HDFSは高度なフォールトトレラント性をもち、低コストなハードウェア上で利用できるように設計されている。 HDFSはアプリケーションデータへのアクセスにおいて高いスループットを提供し、また、大きな容量のデータを扱うアプリケーションに適している。 HDFSはファイルシステム上のデータへのストリーミングアクセスが可能であり、ストリーミングアクセスに関するいくつかのPOSIXの要求定義を緩和して準拠している。 もともとHDFSは、Apache Nutch ウェブ検索エンジンプロジェクトの基幹システムとして構築された。 現在、HDFSはApache Hadoopプロジェクトの一部であり、Apache Luceneプロジェクトの一部である。 プロジェクトのURLは以下：http://projects.apache.org/projects/hadoop.html。

The Hadoop Distributed File System (HDFS) is a distributed file system designed to run on commodity hardware. It has many similarities with existing distributed file systems. However, the differences from other distributed file systems are significant. HDFS is highly fault-tolerant and is designed to be deployed on low-cost hardware. HDFS provides high throughput access to application data and is suitable for applications that have large data sets. HDFS relaxes a few POSIX requirements to enable streaming access to file system data. HDFS was originally built as infrastructure for the Apache Nutch web search engine project. HDFS is part of the Apache Hadoop project, which is part of the Apache Lucene project. The project URL is http://projects.apache.org/projects/hadoop.html.

ハードウェア障害 Hardware Failure

ハードウェア障害は、例外というより標準である。 HDFSのインスタンスは数百、もしくは数千のサーバーから構成され、各サーバーはファイルシステム上でのデータ蓄積の一部を担う。 非常に巨大な構成要素が存在するという事実と、各構成要素において故障が発生する非自明な確率は0ではないということは、HDFSのいくつかの構成要素は常に機能していないということを意味する。 従って、故障の検知と、速やかで自動的なそれら故障からの復旧が、HDFSの設計上のゴールの核となる。

Hardware failure is the norm rather than the exception. An HDFS instance may consist of hundreds or thousands of server machines, each storing part of the file system’s data. The fact that there are a huge number of components and that each component has a non-trivial probability of failure means that some component of HDFS is always non-functional. Therefore, detection of faults and quick, automatic recovery from them is a core architectural goal of HDFS.

ストリーミングデータアクセス Streaming Data Access

HDFS上で実行されるアプリケーションにはデータ群へストリーミングアクセスが必要とされる。 そのようなアプリケーションは、汎用的なファイルシステム上で典型的に実行される汎用的なアプリケーションではない。 HDFSは、ユーザーとの対話的な利用というより、バッチ処理に適したように設計されている。 強調しておくべきことは、データーアクセスの低い待ち時間より、データーアクセスの高いスループットに関してである。 POSIXは、HDFSの対象となるアプリケーションが必要としない、多くの厳しい要求定義を課している。 いくつかの重要な領域におけるPOSIXの規定は、データのスループット速度とのトレードオフの関係になっている。

Applications that run on HDFS need streaming access to their data sets. They are not general purpose applications that typically run on general purpose file systems. HDFS is designed more for batch processing rather than interactive use by users. The emphasis is on high throughput of data access rather than low latency of data access. POSIX imposes many hard requirements that are not needed for applications that are targeted for HDFS. POSIX semantics in a few key areas has been traded to increase data throughput rates.

大規模データ集合 Large Data Sets

HDFS上で実行されるアプリケーションは、大規模なデータ集合をもつ。 HDFS上の典型的なファイルはギガバイトからテラバイトのサイズをもつ。 従って、HDFSは巨大ファイルのサポートへ注力する必要がある。 HDFSは、高いデータ集積の帯域幅と、１つのクラスタ内にて数百のノードへの段階的な拡大とを提供する。 また、一つのインスタンスにおいて数千万ファイルをサポートする。

Applications that run on HDFS have large data sets. A typical file in HDFS is gigabytes to terabytes in size. Thus, HDFS is tuned to support large files. It should provide high aggregate data bandwidth and scale to hundreds of nodes in a single cluster. It should support tens of millions of files in a single instance.

シンプルで一貫性のあるモデル Simple Coherency Model

HDFSのアプリケーションは、ファイルに対してwrite-once-read-many（WORM、単一書き込み-複数読み込み、ライトワンス）を必要としている。 作成され、書き込まれ、閉じられたあるファイルは変更を必要としない。 この仮定は、データの一貫性に関する問題を単純化し、データアクセスの高速化を可能にする。 MapReduceアプリケーション、もしくはWEBクローラーアプリケーションは完全にこのモデルに一致する。 今後の課題として、ファイルへの追加書き込みをサポートする計画がある。

HDFS applications need a write-once-read-many access model for files. A file once created, written, and closed need not be changed. This assumption simplifies data coherency issues and enables high throughput data access. A MapReduce application or a web crawler application fits perfectly with this model. There is a plan to support appending-writes to files in the future.

“データの移動よりも、計算の移動のほうが効率的” “Moving Computation is Cheaper than Moving Data”

アプリケーションから要求された計算は、その計算が行われるデータの近傍にて実行される場合、より効率的である。 データ集合のサイズが巨大である場合、特にこの命題は真となる。 これは、ネットワークの混雑を縮小させ、システム全体スループットを増大させるからである。 この仮定は、アプリケーションが実行されている場所へデータを移動させるよりも、データが所在する場所へ計算を移動させる方がよいということである。 HDFSは、アプリケーションに対して、そのアプリケーション自身を、データが所在する場所の近くへ移動するインターフェースを提供する。

A computation requested by an application is much more efficient if it is executed near the data it operates on. This is especially true when the size of the data set is huge. This minimizes network congestion and increases the overall throughput of the system. The assumption is that it is often better to migrate the computation closer to where the data is located rather than moving the data to where the application is running. HDFS provides interfaces for applications to move themselves closer to where the data is located.

異なるハードウェア、ソフトウェアプラットフォーム間での可搬性 Portability Across Heterogeneous Hardware and Software Platforms

HDFSは、あるプラットフォームから他のプラットフォームへ容易に移行できるように設計されている。 このような可搬性は、膨大なアプリケーション群を選択する際のプラットフォームとして、HDFSが広範囲に採用されることを促進する。

HDFS has been designed to be easily portable from one platform to another. This facilitates widespread adoption of HDFS as a platform of choice for a large set of applications.

HDFS はマスター／スレーブアーキテクチャを採用している。 一つのHDFSクラスターは、１個の名前ノードをもち、そのノードはマスターサーバーとして、ファイルシステムの名前空間を管理し、また、クライアントによるファイルアクセスを調整する。 さらに、クラスターには多数のデータノードが存在し（通常クラスター内ではノード１個に対して１つのデータノードとなる）、それらデータノードはデータノードが実行されているノードに対して割り振られたストレージを管理する。 HDFS はファイルシステムの名前空間を提供し、ファイルにユーザーデータを保存できるようにする。 内部的には、ファイルは１個以上のブロックに分割され、それら複数のブロックはデータノード集合の一つに保管される。 名前ノードは、ファイルシステムの名前空間に対する命令、例えば、ファイルを開く、閉じる、ファイル名やディレクトリ名の変更といった命令を実行する。 また、名前ノードはデータノードに対するブロックのマッピングも決定する。 データノードは、ファイルシステムのクライアントから読み込み要求と書き込み要求に対して責任をもつ。 また、データノードはブロックの作成、検出、そして名前ノードから命令に対する応答を行う。

HDFS has a master/slave architecture. An HDFS cluster consists of a single Namenode, a master server that manages the file system namespace and regulates access to files by clients. In addition, there are a number of Datanodes, usually one per node in the cluster, which manage storage attached to the nodes that they run on. HDFS exposes a file system namespace and allows user data to be stored in files. Internally, a file is split into one or more blocks and these blocks are stored in a set of Datanodes. The Namenode executes file system namespace operations like opening, closing, and renaming files and directories. It also determines the mapping of blocks to Datanodes. The Datanodes are responsible for serving read and write requests from the file system’s clients. The Datanodes also perform block creation, deletion, and replication upon instruction from the Namenode.

名前ノードとデータノードは一般的なマシン上で実行できるようにデザインされたソフトウェアである。 典型的なそれらのマシンでは、GNU/Linux オペレーティングシステム(OS)が動作している。 HDFSはJava言語を用いて構築されている; Javaをサポートするマシンならば名前ノードとデータノードのソフトウェアを実行することが可能である。 非常に高い可搬性をもつJava言語をもちいることにより、非常に広範囲マシン上にてHDFSの開発が可能となる。 典型的な開発においては、名前ノードのソフトウェアだけが実行されているマシンにて行われる。 クラスターに所属する他のマシンは、データノードソフトウェアの１つのインスタンスを実行する。 HDFSでは、同じマシン上で実行されている並列なデータノードの実行を妨げないように設計されているが、実際の開発においてこのようなケースは稀である。

The Namenode and Datanode are pieces of software designed to run on commodity machines. These machines typically run a GNU/Linux operating system (OS). HDFS is built using the Java language; any machine that supports Java can run the Namenode or the Datanode software. Usage of the highly portable Java language means that HDFS can be deployed on a wide range of machines. A typical deployment has a dedicated machine that runs only the Namenode software. Each of the other machines in the cluster runs one instance of the Datanode software. The architecture does not preclude running multiple Datanodes on the same machine but in a real deployment that is rarely the case.

クラスターに名前ノードがたった一つ存在するということは、システムの設計を非常に簡潔にする。 名前ノードは仲裁者であり、HDFSのメタデータの全てを保持している。 システムは、ユーザーのデータが名前ノードを決して通過しないように設計されている。

The existence of a single Namenode in a cluster greatly simplifies the architecture of the system. The Namenode is the arbitrator and repository for all HDFS metadata. The system is designed in such a way that user data never flows through the Namenode.

HDFSは従来の階層的なファイル構成をサポートする。 ユーザー、もしくはアプリケーションは、ディレクトリ内にディレクトリを作成する、もしくは、ファイルを保存することができる。 ファイルシステムの名前空間階層は多くの既存のファイルシステムと類似している; すなわち、ファイルの削除と作成、あるディレクトリから他のディレクトリへのファイルの移動、ファイル名の変更が可能である。 現在のところ、HDFSにはユーザーの使用量の制限、もしくは、アクセス制限は実装されていない。 また、HDFSはハードリンクとソフトリンクもサポートしていない。 しかし、HDFSのアーキテクチャはそれらの機能の実装を妨げるものではない。

HDFS supports a traditional hierarchical file organization. A user or an application can create directories and store files inside these directories. The file system namespace hierarchy is similar to most other existing file systems; one can create and remove files, move a file from one directory to another, or rename a file. HDFS does not yet implement user quotas or access permissions. HDFS does not support hard links or soft links. However, the HDFS architecture does not preclude implementing these features.

名前ノードはファイルシステムの名前空間を維持する。 ファイルシステムの名前空間や属性に対する変更の全てが名前ノードに記録される。 HDFSにより保持されるファイルのレプリカ（複製）の個数は、アプリケーションにより指定することが可能である。 ファイルのコピーの個数は、ファイルのレプリケーション因子と呼ばれる。 レプリケーション因子の情報は名前ノードに保存されている。

The Namenode maintains the file system namespace. Any change to the file system namespace or its properties is recorded by the Namenode. An application can specify the number of replicas of a file that should be maintained by HDFS. The number of copies of a file is called the replication factor of that file. This information is stored by the Namenode.

HDFSは、巨大なクラスター内の複数のマシンにまたがって、非常に巨大なファイルを信頼性を高く保ちながら保存するように設計されている。 HDFSは各ファイルをブロックのシーケンスとして保存する; ファイルに対する全てのブロックは、最終ブロックを除いて、同一のサイズである。 ファイルのブロックはフォールトトレラントを実現するためにレプリケーションされる。 ブロックサイズとレプリケーション要素はファイル毎に設定可能である。 アプリケーションはファイルのレプリカの個数を指定可能である。 レプリケーション要素はファイル作成時に指定することができ、また、作成後に変更も可能である。 HDFSにおけるファイルは単一書き込みであり、任意の時刻において一つの書き込みしか起こらないことに注意。

HDFS is designed to reliably store very large files across machines in a large cluster. It stores each file as a sequence of blocks; all blocks in a file except the last block are the same size. The blocks of a file are replicated for fault tolerance. The block size and replication factor are configurable per file. An application can specify the number of replicas of a file. The replication factor can be specified at file creation time and can be changed later. Files in HDFS are write-once and have strictly one writer at any time.

名前ノードがブロックのレプリケーションに関する決定の全てを行う。 名前ノードはクラスター内の各データノードからハートビートとブロックレポートを定期的に受け取る。 ハートビートを受けとることは、データノードが正しく動作していることを意味する。 ブロックレポートはデータノード上の全てのブロックをリストを含んでいある。

The Namenode makes all decisions regarding replication of blocks. It periodically receives a Heartbeat and a Blockreport from each of the Datanodes in the cluster. Receipt of a Heartbeat implies that the Datanode is functioning properly. A Blockreport contains a list of all blocks on a Datanode.

レプリカの配置：初期ステップ Replica Placement: The First Baby Steps

レプリカの配置は、HDFSの信頼性とパフォーマンスにとって重要である。 レプリカの配置における最適化は、HDFSと他の多くの分散ファイルシステムとを異なるものにしている。 最適化の機能は、多くのチューニングと経験を必要とする。 ラック（訳注：サーバーのネットワーク構成、もしくはサーバー間のネットワークの物理的な構成と読み替えることができる）を意識したレプリカの配置ポリシーの目的は、データの信頼性、可用性、ネットワーク帯域の使用率を向上させることにある。 レプリカの配置ポリシーに対する現在の実装は、このような方針に従う初期段階の成果である。 このポリシーの実装における短期的なゴールは、稼動中のシステムにおいて検証を行い、その挙動から学習し、より洗練されたポリシーをテストし、研究する基礎を構築することである。

The placement of replicas is critical to HDFS reliability and performance. Optimizing replica placement distinguishes HDFS from most other distributed file systems. This is a feature that needs lots of tuning and experience. The purpose of a rack-aware replica placement policy is to improve data reliability, availability, and network bandwidth utilization. The current implementation for the replica placement policy is a first effort in this direction. The short-term goals of implementing this policy are to validate it on production systems, learn more about its behavior, and build a foundation to test and research more sophisticated policies.

巨大なHDFSのインスタンスは、通常多くのラックに散らばったコンピュータのクラスター上で動作する。 異なるラックに属する２つのノード間の通信は、スイッチを通過しなければならない。 同一ラック内のマシン間のネットワーク帯域は異なるラック間のネットワーク帯域より通常大きい。

Large HDFS instances run on a cluster of computers that commonly spread across many racks. Communication between two nodes in different racks has to go through switches. In most cases, network bandwidth between machines in the same rack is greater than network bandwidth between machines in different racks.

はじめに、各データノードはそのノードが所属するラックを決定し、そのラックIDの名前ノードに登録を通知する。 HDFSは、マシンのラックIDを決定する為に使用できる、容易に追加可能なモージュールの、APIを提供する。 単純だが最適ではないポリシーは、複数のラック上全てにレプリカを配置することである。 このようなポリシーは、データの読み込みが行われている際、ある一つのラック全体が落ちてしまっても、多重に構成されたラックの帯域を用いることにより、読み込みにおけるデータ消失を防ぐことができる。 また、このポリシーならば、クラスター内にてレプリカを均一に分散でき、それによってコンポーネントにおける失敗においても負荷を容易に分散することができる。 しかし、このポリシーは、書き込みにおいて多重なラックへのブロック転送を必要とする為、書き込みのコストを増大させる。

At startup time, each Datanode determines the rack it belongs to and notifies the Namenode of its rack id upon registration. HDFS provides APIs to facilitate pluggable modules that can be used to determine the rack id of a machine. A simple but non-optimal policy is to place replicas on unique racks. This prevents losing data when an entire rack fails and allows use of bandwidth from multiple racks when reading data. This policy evenly distributes replicas in the cluster which makes it easy to balance load on component failure. However, this policy increases the cost of writes because a write needs to transfer blocks to multiple racks.

一般的な場合、レプリケーション因子が３であるとすると、HDFSの配置ポリシーでは、ローカルなラックの一つのノードにレプリカを１個配置し、もう一つのレプリカはローカルラックの他の異なるノードに配置され、最後の１個は異なるラックの異なるノードに配置される。 このポリシーは、ラック間の書き込みトラフィックを減少させことになり、一般的に書き込み効率を増大させる。 ラックにおける書き込み失敗は、ノードの書き込み失敗より少ない；このポリシーはデータの信頼性と可用性の保障に影響を及ぼさない。 しかし、ブロックは３個ではなく２個のユニークなラックに配置されているため、読み込みの際、ネットワーク帯域の総使用量を減少させることができる。 このポリシーに従い、ファイルのレプリカはラックに均一に分散しない。 レプリカの３分の１は一つのノードに存在し、３分の２は１つラックに存在し、他の３分の１は残りのラックに分散されて配置されることになる。 このポリシーは、データの信頼性と読み込み性能に関して妥協することなく、書き込み効率を増大させる。

For the common case, when the replication factor is three, HDFS’s placement policy is to put one replica on one node in the local rack, another on a different node in the local rack, and the last on a different node in a different rack. This policy cuts the inter-rack write traffic which generally improves write performance. The chance of rack failure is far less than that of node failure; this policy does not impact data reliability and availability guarantees. However, it does reduce the aggregate network bandwidth used when reading data since a block is placed in only two unique racks rather than three. With this policy, the replicas of a file do not evenly distribute across the racks. One third of replicas are on one node, two thirds of replicas are on one rack, and the other third are evenly distributed across the remaining racks. This policy improves write performance without compromising data reliability or read performance.

現在、ここで述べたデフォルトのレプリカ配置ポリシーは、開発中である。

The current, default replica placement policy described here is a work in progress.

レプリカの選定 Replica Selection

全体のネットワーク帯域の使用量と読み出しレイテンシーを最小化するために、HDFSは、読み込み要求したクライアントに隣接したレプリカから、読み込みを行おうと試みる。 読み込みを行うクライアントのノードと同じラックにレプリカが存在するならば、読み込み要求に答えるようにそのレプリカを選択する。 angg/（??）HDFSのクラスターが幾つかのデータセンターにまたがって存在する場合は、他の遠隔に存在するレプリカではなく、ローカルなデータセンターに所在しているレプリカを選択する。

To minimize global bandwidth consumption and read latency, HDFS tries to satisfy a read request from a replica that is closest to the reader. If there exists a replica on the same rack as the reader node, then that replica is preferred to satisfy the read request. If angg/ HDFS cluster spans multiple data centers, then a replica that is resident in the local data center is preferred over any remote replica.

セーフモード SafeMode

スタート時において、名前ノードはセーフモード（Safemode）と呼ばれる特別な状態にある。 名前ノードがセーフモードであるとき、データブロックのレプリケーションは行われない。 セーフモードにある名前ノードはデータノードからハートビートとブロックレポートを受け取る。 ブロックレポートはデータノードが担当しているデータブロックのリストを含んでいる。 各ブロックにはレプリカの最小個数が指定されている。 データブロックのレプリカの最小個数が名前ノードにてチェックされている場合、そのブロックは安全なレプリケーション状態と考えられる。 名前ノードにて安全なレプリケーション状態にあるデータブロックの割合が適合であるかチェックされた後（加えて３０秒の猶予を経た後）、名前ノードはセーフモードから抜ける。 このとき、レプリカの個数が指定された個数より少ない場合でも、データブロックのリストが（既に存在していても）決定される。 そして、名前ノードは、それら指定された個数よりも少ないレプリカしかもたないブロックを、他のデータノードにレプリケートする。

On startup, the Namenode enters a special state called Safemode. Replication of data blocks does not occur when the Namenode is in the Safemode state. The Namenode receives Heartbeat and Blockreport messages from the Datanodes. A Blockreport contains the list of data blocks that a Datanode is hosting. Each block has a specified minimum number of replicas. A block is considered safely replicated when the minimum number of replicas of that data block has checked in with the Namenode. After a configurable percentage of safely replicated data blocks checks in with the Namenode (plus an additional 30 seconds), the Namenode exits the Safemode state. It then determines the list of data blocks (if any) that still have fewer than the specified number of replicas. The Namenode then replicates these blocks to other Datanodes.

HDFSの名前空間は、名前ノードに保存されている。 名前ノードは、EditLogと呼ばれるトランザクションログを利用し、ファイルシステムのメタデータに対して行われた全ての変更を永続的に記録する。 例えば、HDFSに新しいファイルが作成された場合、名前ノードはEditLogにファイル作成のレコードを追記する。 同様に、ファイルのレプリケーション因子の変更は、新しいレコードとしてEditLogに追記される。 名前ノードは、ローカルホストのOSのファイルシステム上のファイルに、EditLogを保存する。 全体のファイルシステムの名前空間は、ファイルブロックの配置やファイルシステムの属性を含め、FsImageと呼ばれるファイルに保存されている。 FsImageも、名前ノードのローカルなファイルシステムにファイルとして保存されている。

The HDFS namespace is stored by the Namenode. The Namenode uses a transaction log called the EditLog to persistently record every change that occurs to file system metadata. For example, creating a new file in HDFS causes the Namenode to insert a record into the EditLog indicating this. Similarly, changing the replication factor of a file causes a new record to be inserted into the EditLog. The Namenode uses a file in its local host OS file system to store the EditLog. The entire file system namespace, including the mapping of blocks to files and file system properties, is stored in a file called the FsImage. The FsImage is stored as a file in the Namenode’s local file system too.

名前ノードはファイシステムの名前空間全体のイメージを保持しており、ファイルのBlockmapをメモリー上に保持している。 このキーとあるメタデータ属性はコンパクトに設計されており、それは4GBのRAMをもつ名前ノードで膨大な個数のファイルとディレクトリを十分サポートできるように設計されている。 名前ノードは起動するとディスクからFsImageとEditLogを読み込み、全てのトランザクションをEditLogからFsImageのメモリー上の表現へ割り当て、この新しいバージョンのFsImageをディスク上へ書き込む。 このとき古いEditLogは破棄されるが、それは古いEditLogのトランザクションが既に現状のFsImageへ適用されているからである。 このプロセスは、checkpointと呼ばれる。 現状の実装では、checkpointは名前ノードが起動されたときにだけ実行される。 近い将来、定期的なcheckpointの実行がサポートされる予定である。

The Namenode keeps an image of the entire file system namespace and file Blockmap in memory. This key metadata item is designed to be compact, such that a Namenode with 4 GB of RAM is plenty to support a huge number of files and directories. When the Namenode starts up, it reads the FsImage and EditLog from disk, applies all the transactions from the EditLog to the in-memory representation of the FsImage, and flushes out this new version into a new FsImage on disk. It can then truncate the old EditLog because its transactions have been applied to the persistent FsImage. This process is called a checkpoint. In the current implementation, a checkpoint only occurs when the Namenode starts up. Work is in progress to support periodic checkpointing in the near future.

データノードはHDFSのデータをローカルファイルシステム上に保存する。 データノードはHDFSファイルに関する情報をもたない。 データノードはHDFSデータの各ブロックをローカルファイルシステム上で分割された１つのファイルとして保存する。 データノードは同一ディレクトリ内に全てのファイルを作成することはない。 その代わり、発見的な方法により、ディレクトリー毎に最適なファイルの個数を決定し、適切なサブディレクトリを作成する。 単一ディレクトリ内に全てのローカルファイルを作成するのは最適ではない。なぜなら、ローカルファイルシステムが単一ディレクトリ内に存在する膨大な個数のファイルを効率的にサポートすることはないからである。 データノードは起動すると、ローカルファイルシステムを走査し、全てのHDFSデータとそれらに対応する各ローカルファイルのリストを作成し、そのレポートを名前ノードへ送信する：これがBlockreportである。

The Datanode stores HDFS data in files in its local file system. The Datanode has no knowledge about HDFS files. It stores each block of HDFS data in a separate file in its local file system. The Datanode does not create all files in the same directory. Instead, it uses a heuristic to determine the optimal number of files per directory and creates subdirectories appropriately. It is not optimal to create all local files in the same directory because the local file system might not be able to efficiently support a huge number of files in a single directory. When a Datanode starts up, it scans through its local file system, generates a list of all HDFS data blocks that correspond to each of these local files and sends this report to the Namenode: this is the Blockreport.

全てのHDFSコミュニケーションプロトコルはTCP/IPプロトコルの最上層に属している。 クライアントは名前ノードマシン上の適合性のあるTCPポートに対して接続を確立する。 そして、名前ノードとClientProtocolを用いて対話を行う。 データノードはDatanodeProtocolを用いて名前ノードとの対話を行う。 ClientProtocolとDatanodeProtocolの両方に、リモートプロシージャコール（RPC）の概念が含まれている。 設計において、名前ノードは決して任意のRPCを規定しない。 代わりに、名前ノードはデータノードもしくはクライアントから発行されたRPCの要求に対して返答を行うだけである。

All HDFS communication protocols are layered on top of the TCP/IP protocol. A client establishes a connection to a configurable TCP port on the Namenode machine. It talks the ClientProtocol with the Namenode. The Datanodes talk to the Namenode using the DatanodeProtocol. A Remote Procedure Call (RPC) abstraction wraps both the ClientProtocol and the DatanodeProtocol. By design, the Namenode never initiates any RPCs. Instead, it only responds to RPC requests issued by Datanodes or clients.

HDFSのもっとも重要な目標は、たとえ故障が起きたとしても、確実にデータを保存することである。 故障の標準的な３つのタイプは、名前ノードの故障、データノードの故障、ネットワーク区画の故障である。

The primary objective of HDFS is to store data reliably even in the presence of failures. The three common types of failures are Namenode failures, Datanode failures and network partitions.

データディスク障害、ハートビート、再レプリケーション 　Data Disk Failure, Heartbeats and Re-Replication

各データノードは定期的に名前ノードへハートビートを送信する。 ネットワーク区画においては、データノードの一部と名前ノードとが断絶することがある。 名前ノードはハートビートが受け取れないことによりこのような状況を検出する。 名前ノードは直近のハートビートが来ないデータノードを不通とし、新しいIOリクエストを送信しない。 不通となったデータノードに記録された任意のデータは、HDFSにおいてはもう二度と利用されることはない。 データノードの死により、幾つかのブロックのレプリケーション因子の値が指定された値を下回る場合がある。 名前ノードは、レプリケーションを必要とするブロックを継続的に追跡しており、必要なときにはいつでもレプリケーションを開始する。 再レプリケーションの必要性が生じるのには、幾つかの理由が存在する：データノードが不能状態になった場合、レプリカが損なわれた場合、データノードのハードディスクが動作しなくなった場合、ファイルのレプリケーション因子が増加した場合などである。

Each Datanode sends a Heartbeat message to the Namenode periodically. A network partition can cause a subset of Datanodes to lose connectivity with the Namenode. The Namenode detects this condition by the absence of a Heartbeat message. The Namenode marks Datanodes without recent Heartbeats as dead and does not forward any new IO requests to them. Any data that was registered to a dead Datanode is not available to HDFS any more. Datanode death may cause the replication factor of some blocks to fall below their specified value. The Namenode constantly tracks which blocks need to be replicated and initiates replication whenever necessary. The necessity for re-replication may arise due to many reasons: a Datanode may become unavailable, a replica may become corrupted, a hard disk on a Datanode may fail, or the replication factor of a file may be increased.

クラスターの再バランシング Cluster Rebalancing

HDFSのアーキテクチャは、データ再バランシングスキーマ(data rebalancing schemes)と互換性がある。 スキーマにより、データノードの空き容量が特定の閾値以下になった場合、あるデータノードから他のデータノードへデータを自動的に移動する。 特定のファイルに対して突然の高レベルな要求が発生した場合、スキーマは動的に追加のレプリカを作成し、クラスター内にて他のデータを再バランシングする。 このタイプのデータ再バランシングスキーマは、まだ実装されていない。

The HDFS architecture is compatible with data rebalancing schemes. A scheme might automatically move data from one Datanode to another if the free space on a Datanode falls below a certain threshold. In the event of a sudden high demand for a particular file, a scheme might dynamically create additional replicas and rebalance other data in the cluster. These types of data rebalancing schemes are not yet implemented.

データの無欠性 Data Integrity

あるデータノードから所得したデータのブロックには、エラーが含まれる可能性がある。 このようなエラーは、ストレージデバイスや、ネットワーク、バグのあるソフトウェアにおける失敗により、引き起こされる。 HDFSのクライアントソフトウェアは、HDFSファイルの内容にチェックサム検証を実装する。 クライアントがHDFSファイルを作成する際、クライアントはファイルの各ブロックのチェックサムを計算し、同じHDFS名前空間にある別個の隠しファイルへ、それらのチェックサムを保存する。 ファイルの内容を受け取った際クライアントは、各データノードから受け取ったデータのチェックサムが、そのファイルに対応したチェックサムファイルへ保存されているチェックサムと、一致するか否かをチェックする。 もし一致しない場合、クライアントは、対応するブロックのレプリカをもつ他のデータノードから、該当のブロックを受けるとことを選択できる。

It is possible that a block of data fetched from a Datanode arrives corrupted. This corruption can occur because of faults in a storage device, network faults, or buggy software. The HDFS client software implements checksum checking on the contents of HDFS files. When a client creates an HDFS file, it computes a checksum of each block of the file and stores these checksums in a separate hidden file in the same HDFS namespace. When a client retrieves file contents it verifies that the data it received from each Datanode matches the checksum stored in the associated checksum file. If not, then the client can opt to retrieve that block from another Datanode that has a replica of that block.

メタデータディスク障害 Metadata Disk Failure

FsImageとEditlogはHDFSの中核となるデータ構造である。 これらのファイルが壊れた場合、HDFSのインスタンスは機能不全となる。 このような理由から、名前ノードはFsImageとEditLogの複数コピーを保持できるように構成可能である。 FsImageもしくはEditLogに対する任意の更新は、FsImageとEditLogのコピーそれぞれに同時に反映される。 このFsImageとEditLogの複数コピーに対する同期更新は、名前ノードがサポート可能な１秒当たりの名前空間トランザクション数を減少させるかもしれない。 しかし、本来HDFSはデータに集約的なシステムであり、メタデータに集約的なシステムではないため、この減少は許容できる。 再起動された名前ノードは、整合性のとれた最新のFsImageとEditLogとを選択し、それを使用する。

The FsImage and the EditLog are central data structures of HDFS. A corruption of these files can cause the HDFS instance to be non-functional. For this reason, the Namenode can be configured to support maintaining multiple copies of the FsImage and EditLog. Any update to either the FsImage or EditLog causes each of the FsImages and EditLogs to get updated synchronously. This synchronous updating of multiple copies of the FsImage and EditLog may degrade the rate of namespace transactions per second that a Namenode can support. However, this degradation is acceptable because even though HDFS applications are very data intensive in nature, they are not metadata intensive. When a Namenode restarts, it selects the latest consistent FsImage and EditLog to use.

名前ノードのマシンは、HDFSクラスターに障害が発生する唯一のポイントである。 名前ノードのマシンに障害が発生した場合、手動による介入が必要となる。 現在、名前ノードのソフトウェアを他の代替マシンに入れ替える自動的な再起動と障害復旧はサポートされていない。

The Namenode machine is a single point of failure for an HDFS cluster. If the Namenode machine fails, manual intervention is necessary. Currently, automatic restart and failover of the Namenode software to another machine is not supported.

スナップショット Snapshots

スナップショットは、ある時刻における特定のインスタンスのデータコピーを蓄える機能である。 スナップショット機能の一つの使用法は、ある障害が発生したHDFSのインスタンスを、以前のある時刻における障害のなかった良好なインスタンスへ、ロールバックすることであろう。 現在、HDFSはスナップショットをサポートしていないが、将来的にサポートする予定である。

Snapshots support storing a copy of data at a particular instant of time. One usage of the snapshot feature may be to roll back a corrupted HDFS instance to a previously known good point in time. HDFS does not currently support snapshots but will in a future release.

データブロック Data Blocks

HDFSは非常に巨大なサイズのファイルをサポートするように設計されている。 HDFSを利用するアプリケーションは強大なデータセットを扱うアプリケーションである。 そのようなアプリケーションは、データの書き込みは一度だけであるが、読み込みを複数回行い、そしてその読み込みにおいて十分なストリーミングスピードが要求される。 HDFSはファイルに対して単一書き込み-複数読み込み（write-once-read-many）を提供する。 HDFSが用いる典型的なブロックサイズは64MBである。 従って、HDFSのファイルは64MBのチャンク（訳注：最小単位のブロックと同義）に分割され、可能ならば各チャンクはそれぞれ異なるデータノードに置かれる。

HDFS is designed to support very large files. Applications that are compatible with HDFS are those that deal with large data sets. These applications write their data only once but they read it one or more times and require these reads to be satisfied at streaming speeds. HDFS supports write-once-read-many semantics on files. A typical block size used by HDFS is 64 MB. Thus, an HDFS file is chopped up into 64 MB chunks, and if possible, each chunk will reside on a different Datanode.

ファイル作成段階 Staging

クライアントからのファイル作成の要求は即座に名前ノードへは送られない。 実際、はじめにHDFSのクライアントは一時的なローカルファイルにファイルのデータをキャッシュする。 アプリケーションの書き込みは、この一時的なローカルファイルへアプリケーションが意識せずに（トランスペアレントに）リダイレクトされる。 ローカルファイルがHDFSの１つのブロックサイズ以上のデータを蓄積すると、クライアントは名前ノードに連絡を行う。 名前ノードはファイルシステムの階層にファイル名を書き込み、そのファイルのためのデータブロックを割り振る。 クライアントの要求に対して名前ノードは、データノードの指定とデータブロックの送付先を返答する。 そして、クライアントはデータブロックをローカルな一時ファイルから特定のデータノードへ反映させる。 ファイルを閉じると、一時的なローカルファイルに存在するまだ反映されていない残りのデータが、データノードに転送される。 このとき、クライアントはファイルを閉じた旨を名前ノードに伝える。 この時点において、名前ノードは該当のファイル作成命令が完了し、永続的に保存されたものとする。 ファイルが閉じられる以前に名前ノードが死んでしまった場合、ファイルは失われる。

A client request to create a file does not reach the Namenode immediately. In fact, initially the HDFS client caches the file data into a temporary local file. Application writes are transparently redirected to this temporary local file. When the local file accumulates data worth over one HDFS block size, the client contacts the Namenode. The Namenode inserts the file name into the file system hierarchy and allocates a data block for it. The Namenode responds to the client request with the identity of the Datanode and the destination data block. Then the client flushes the block of data from the local temporary file to the specified Datanode. When a file is closed, the remaining un-flushed data in the temporary local file is transferred to the Datanode. The client then tells the Namenode that the file is closed. At this point, the Namenode commits the file creation operation into a persistent store. If the Namenode dies before the file is closed, the file is lost.

上記のアプローチは、HDFS上で実行される対象のアプリケーションにおいて慎重に考慮して、受け入れられるべきである。 そのようなアプリケーションはファイルへストリーミングな書き込みを必要とする。 クライアントがクライアント側にてバッファリングを行わずにファイルをリモート側へ直接書き込んだ場合、ネットワークのスピードと混雑度はスループットに対して著しい損害を引き起こす。 このアプローチには先例がある。 初期の分散ファイルシステム（例えばAFS）では、クライアント側でキャッシュを行うことにより、パフォーマンスが向上した。 POSIXにおいて、データアップロードにおける高いパフォーマンスの達成要求は緩和されている。

The above approach has been adopted after careful consideration of target applications that run on HDFS. These applications need streaming writes to files. If a client writes to a remote file directly without any client side buffering, the network speed and the congestion in the network impacts throughput considerably. This approach is not without precedent. Earlier distributed file systems, e.g. AFS, have used client side caching to improve performance. A POSIX requirement has been relaxed to achieve higher performance of data uploads.

レプリケーションのパイプライン Replication Pipelining

前節で説明したように、クライアントがHDFSファイルにデータを書き込んだ際、はじめにそのデータはローカルファイルに書き込まれる。 HDFSのファイルのレプリケーション因子が３であると仮定する。 このとき、ローカルファイルにはユーザデータ全体のブロックが蓄積され、クライアントは名前ノードからデータノードのリストを受け取る。 受け取ったリストには、各ブロックのレプリカを担当するデータノードも含まれている。 そして、クライアントはそのデータブロックを第一のデータノードに反映させる。 第一データノードは、小さく分割された（4KB）データを受信しはじめ、各分割をローカルリポジトリに書き込み、それらの分割をリストの第二データノードへ転送する。 第二データノードは、データブロックの分割を受信しはじめると、リポジトリーに分割を書き込み、そして第三データノードへ分割を反映させる。 最後に、第三データノードはデータをローカルリポジトリーに書き込む。 したがって、データノードはパイプラインにおける直前のデータノードからデータを受け取り、同時にパイプラインにおける次のデータノードにデータを転送する。 これにより、データはあるデータノードから次のデータノードへと送り込まれてゆく。

When a client is writing data to an HDFS file, its data is first written to a local file as explained in the previous section. Suppose the HDFS file has a replication factor of three. When the local file accumulates a full block of user data, the client retrieves a list of Datanodes from the Namenode. This list contains the Datanodes that will host a replica of that block. The client then flushes the data block to the first Datanode. The first Datanode starts receiving the data in small portions (4 KB), writes each portion to its local repository and transfers that portion to the second Datanode in the list. The second Datanode, in turn starts receiving each portion of the data block, writes that portion to its repository and then flushes that portion to the third Datanode. Finally, the third Datanode writes the data to its local repository. Thus, a Datanode can be receiving data from the previous one in the pipeline and at the same time forwarding data to the next one in the pipeline. Thus, the data is pipelined from one Datanode to the next.

HDFSには多くの異なる方法でアプリケーションからアクセスすることが可能である。 HDFSは、アプリケーションからHDFSをネイティブに利用するためのJava APIを提供している。 このJava APIのためのC言語のワッパーも提供されている。 加えて、HTTPブラウザからもHDFSのインスタンスにあるファイルを閲覧することが可能である。 WebDAVプロトコルによるHDFSの利用形態も現在開発中である。

HDFS can be accessed from applications in many different ways. Natively, HDFS provides a Java API for applications to use. A C language wrapper for this Java API is also available. In addition, an HTTP browser can also be used to browse the files of an HDFS instance. Work is in progress to expose HDFS through the WebDAV protocol.

DFSShell DFSShell

HDFSはファイルとディレクトリ形式でまとめられたユーザーデータを提供する。 HDFSはDFSShellと呼ばれるコマンドライン・インターフェースを提供しており、ユーザーはDFSShellによってHDFSのデータとインタラクトすることができる。 DFSShellのコマンド集合のシンタックスは、ユーザーが既に慣れ親しんでいる他のシェル（例えば、bashやcsh）と似ている。 以下に、実行内容／コマンドの対となるサンプルを示す：

HDFS allows user data to be organized in the form of files and directories. It provides a commandline interface called DFSShell that lets a user interact with the data in HDFS. The syntax of this command set is similar to other shells (e.g. bash, csh) that users are already familiar with. Here are some sample action/command pairs:

DFSShellは、蓄積されたデータとインタラクトするスクリプト言語を必要とするアプリケーションを対象としている。

DFSShell is targeted for applications that need a scripting language to interact with the stored data.

DFSAdmin DFSAdmin

DFSAdminコマンド集合は、HDFSクラスターの管理を行うために利用される。 それらのコマンドはHDFSの管理者のみが使用する。 以下に、実行内容／コマンドの対となるサンプルを示す：

The DFSAdmin command set is used for administering an HDFS cluster. These are commands that are used only by an HDFS administrator. Here are some sample action/command pairs:

ブラウザインターフェイス Browser Interface

典型的なHDFSのインストールを行うと、設定可能なTCPポートを通してHDFSの名前空間が閲覧できるように、WEBサーバーが設定される。 これによってユーザーは、WEBブラウザーを使用してHDFSの名前空間とファイルの内容を閲覧することができる。

A typical HDFS install configures a web server to expose the HDFS namespace through a configurable TCP port. This allows a user to navigate the HDFS namespace and view the contents of its files using a web browser.

ファイルの削除と復元 File Deletes and Undeletes

ユーザーもしくはアプリケーションによってファイルが削除された場合、HDFSにおいてそのファイルは即座には削除されない。 代わりに、HDFSはそのファイルを別名にし、ディレクトリ /trash へ移動する。 削除されたファイルは /trash 内に残っているかぎり、すぐに復旧することが可能である。 ファイルが /trash に残っているのは、設定された時間内のみである。 ディレクトリ /trash に残っているファイルの残存期間が満了すると、名前ノードはHDFSの名前空間からそのファイルを削除する。 ファイルの削除はファイルに結びつけられたブロックを開放する。 注意すべき点は、ユーザーによりファイルが削除された時間と、HDFSにおいてファイル削除により開放された領域が増加するまでの時間との間には、かなりの遅れが存在するかもしれないということである。

When a file is deleted by a user or an application, it is not immediately removed from HDFS. Instead, HDFS first renames it to a file in the /trash directory. The file can be restored quickly as long as it remains in /trash. A file remains in /trash for a configurable amount of time. After the expiry of its life in /trash, the Namenode deletes the file from the HDFS namespace. The deletion of a file causes the blocks associated with the file to be freed. Note that there could be an appreciable time delay between the time a file is deleted by a user and the time of the corresponding increase in free space in HDFS.

ユーザーは /trash ディレクトリにファイルが残っている限り、その削除したファイルを復元できる。 ユーザーが削除したファイルを復元したい場合、/trash ディレクトリを操作して、そのファイルを取り戻すことができる。 ディレクトリ /trash には削除されたファイルの最新のコピーのみが含まれる。 ディレクトリ /trash はただ一つの特別な特徴を除いて、他のディレクトリと変わりない： HDFSは、指定された設定に従い、このディレクトリから自動的にファイルを削除する。 現状のデフォルト設定は、6時間以上経過したファイルを /trash から削除するようになっている。 将来的に、この設定は矛盾ないインターフェースを通して設定可能となる。

A user can Undelete a file after deleting it as long as it remains in the /trash directory. If a user wants to undelete a file that he/she has deleted, he/she can navigate the /trash directory and retrieve the file. The /trash directory contains only the latest copy of the file that was deleted. The /trash directory is just like any other directory with one special feature: HDFS applies specified policies to automatically delete files from this directory. The current default policy is to delete files from /trash that are more than 6 hours old. In the future, this policy will be configurable through a well defined interface.

レプリケーション因子の縮小化 Decrease Replication Factor

ファイルのレプリケーション因子が減少した場合、名前ノードは超過しているレプリカの内から削除可能なレプリカを選択する。 そして、次回のハートビートでその情報をデータノードに送る。 このとき、データノードは対応するブロックを削除し、対応する開放された領域がクラスター内に出現する。 繰り返しになるが、setReplication APIコールの完了とクラスター内にて開放された領域が出現するまでの間には、時間遅れが生じるかもしれない。

When the replication factor of a file is reduced, the Namenode selects excess replicas that can be deleted. The next Heartbeat transfers this information to the Datanode. The Datanode then removes the corresponding blocks and the corresponding free space appears in the cluster. Once again, there might be a time delay between the completion of the setReplication API call and the appearance of free space in the cluster.

HDFS Java API: http://lucene.apache.org/hadoop/api/

HDFS source code: http://lucene.apache.org/hadoop/version_control.html