예전에 사내 세미나용으로 급하게 번역한 문서입니다. 다양한 오역과 수많은 오탈자가 있으므로 단순 참고용으로만 사용하셨으면 하네요

Introduction
소개

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 Core project. The project URL is http://hadoop.apache.org/core/.
Hadoop 분산 파일 시스템(HDFS)는 범용 장비에서 동작하도록 설계된 분산 파일 시스템입니다. 이는 기존의 분산파일시스템과 많은 유사점을 갖고 있습니다. 하지만 다른 분산파일시스템과의 차이점 또한 큽니다. HDFS는 높은 장애복구(fault-tolerant) 성능과 저가의 하드웨어에 적용 가능하도록 설계되었습니다. HDFS는 어플리케이션 데이타에 대한 고성능의 접근성을 제공하며큰 규모의 데이타셋들을 사용하는 어플케이션에 적합합니다. HDFS는 파일 시스템 데이타에 스트리밍 접근이 가능하도록 일부 POSIX 요구조건을 완화합니다. HDFS는 원래 Apache Nutch 웹 검색엔진 프로젝트의 인프라스트럭처로써 개발되었습니다. HDFS는 Apache Hadoop Core 프로젝트의 일부입니다.이 프로젝트의 URL은 http://hadoop.apache.org/core/ 입니다.

Assumptions and Goals
전제와 목표

Hardware Failure
하드웨어 장애

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
하드웨어 장애는 예외상황보다 일반적입니다. HDFS 인스턴스는 수백, 수천개의 장비들로 구성될 수 있으며, 각각은 파일 시스템 데이타의 일부를 저장합니다. 엄청난 숫자의 컴포넌트들이 존재하고 각 컴포넌트의 장애발생 확률을 적지 않다는 것은 HDFS 컴포넌트중 일부는 항상 동작하지 않는 상태임을 의미합니다. 따라서, 장애를 탐지하고 자동으로 이를 신속하게 복구하는 것이 HDFS 아키텍쳐의 핵심적인 목표입니다.

Streaming Data Access
스트리밍 데이타 접근

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.
HDFS 상에서 실행되는 어플리케이션들을 데이타셋에 대한 스트리밍 접근을 요구합니다. 이들은 범용 파일시스템 위에서 동작하는 일반적인 어플리케이션이 아닙니다. HDFS는 사용자와의 상호작용보다 배치 프로세싱에 적합하도록 설계되었습니다. 낮은 데이타 접근 지연시간보다 높은 전송속도에 주안점을 두고 있습니다. POSIX는 HDFS의 목표 어플리케이션들이 필요로 하지 않는 많은 엄격한 요구조건을 가지고 있습니다. 일부 핵심적인 부분에서 POSIX 시멘틱들은 데이타 전송율을 증가시키기 위해 제외되었습니다.

Large Data Sets
대규모 데이타 셋

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.
HDFS 상에서 동작하는 어플리케이션들은 큰 데이타셋들을 갖습니다. HDFS에서는 일반적인 파일 하나가 기가바이트에서 테라바이트 정도의 크기를 갖습니다. 따라서 HDFS는 큰 파일들을 지원하는데 집중합니다. 이를 위해서는 높은 종합 데이타 전송률과 하나의 클러스터의 수백대 수준의 노드규모를 지원할 수 있어야 합니다. 하나의 인스턴스에서 수백만개의 파일들을 지원해야 합니다.

Simple Coherency Model
단순한 일관성 모델

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
HDFS 어플리케이션들은 파일들에 대해 한번-쓰고-여러번-읽는 접근모델을 필요로 합니다. 하나의 파일은 생성되고, 쓰여지고, 변경되지 않도록 닫혀야 합니다. 이러한 전제는 데이타 일관성 문제를 단순화하고 높은 성능의 데이타 접근을 가능하게 합니다. MapReduce 어플리케이션이나 웹 크롤러 어플리케이션은 이러한 모델에 완벽하게 적합합니다. 추후에 덧쓰기(appending-write) 기능을 지원할 계획이 있습니다.

“Moving Computation is Cheaper than Moving Data”
"계산을 옮기는 것이 데이타를 옮기는 것보다 저렴하다"

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.
어플리케이션이 요청한 계산은 사용하고자 하는 데이타 근처에서 실행될때 훨씬 더 효율적입니다. 특히 데이타셋의 크기가 클수록 더욱 두드러집니다. 이는 네트워크 혼잡을 최소화하고 시스템의 전반적인 성능을 향상시킵니다. 이러한 전제는 계산을 데이타 근처로 옮기는 것이 데이터를 어플리케이션이 실행되는 곳으로 옮기는 것보다 종종 더 낫다는 것입니다. HDFS는 어플리케이션들에게 그것들을 데이타의 위치에 가깝게 옮길 수 있는 인터페이스를 제공합니다. 

Portability Across Heterogeneous Hardware and Software Platforms
이종 장비와 소프트웨어 플랫폼간의 이동성

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의 도입을 쉽게 합니다.

Namenode and Datanodes
네임노드, 데이타노드

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
HDFS는 마스터/슬레이브 구조를 갖습니다. HDFS 클러스터는 하나의 네임노드, 파일시스템의 네임스페이스를 관리하고 클라이언트의 파일접근을 통제하는 마스터서버를 갖습니다. 추가적으로 수많은 데이타노드들을 갖으며 일반적으로 클러스터의 노드당 하나씩이고 해당 노드에 설치된 스토리지를 관리합니다. HDFS는 파일시스템의 네임스페이스를 노출시키고 사용자 데이타를 파일에 저장할 수 있도록 합니다. 내부적으로, 하나의 파일은 여러개의 블록들로 나누어지며 이 블록들은 데이타노드 집합에 저장됩니다. 네임노드는 열기, 닫기, 파일명 또는 디렉토리명 변경과 같은 파일 시스템 네임스페이스에 대한 명령을 수행합니다. 또한 블록들과 데이타노드들간의 맵핑관계를 설정합니다. 데이타노드들은 해당 파일시스템의 클라이언트에게 읽기, 쓰기 요청을 제공합니다. 데이타노드는 또한 블록을 생성하고, 삭제하고, 네임노드의 명령에 따라 복사본을 작성합니다.

HDFS Architecture

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.
네임노드와 데이타노드는 범용장비에서 수행되도록 설계된 소프트웨어의 일부입니다. 이러한 장비들은 일반적으로 GNU/Linux 운영체제를 사용합니다. HDFS는 자바언어로 제작되었습니다; 자바를 지원하는 모든 장비에서 네임노드 또는 데이타노드 소프트웨어를 실행할 수 있습니다. 이식성이 높은 자바언어의 사용은 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 메타데이타의 저장소입니다. 시스템은 이런 식으로 사용자 데이타가 절대로 네임노드를 통과하지 않도록 설계되었습니다.

The File System Namespace
파일 시스템 네임스페이스

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는 전통적인 계층 파일구조를 지원합니다. 사용자나 어플리케이션은 디렉토리를 생성하고 해당 디렉토리에 파일을 저장할 수 있습니다. 파일 시스템 네임스페이스 계층구조는 대부분의 기존 파일 시스템과 유사합니다. 이는 파일을 생성하거나 삭제하고, 파일을 한 디렉토리에서 다른 디렉토리로 이동시키고, 파일명을 바꿀 수 있는 시스템들입니다. HDFS는 아직 사용자 할당량이나 접근권한 부분이 구현되어 있지 않은 상태입니다. HDFS는 하드링크나 소프트링크를 지원하지 않습니다. 그렇다고 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에 의해 관리될 파일의 복사본 숫자를 설정할 수 있습니다. 파일의 사본 숫자를 해당 파일의 복사계수라고 합니다. 이 정보는 네임노드에 저장됩니다.

Data Replication
데이타 복사본

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.
HDFS는 거대한 클러스터 장비들 사이에 매우 큰 파일을 신뢰성있게 저장할 수 있도록 설계되었습니다. 이는 각 파일을 순차적인 블록들에 저장합니다; 파일의 모든 블록은 마지막 블록을 제외하고 모두 같은 크기를 같습니다. 파일의 블록들을 장애복구를 위해 사본이 작성됩니다. 블록 크기와 복사계수는 파일마다 설정가능합니다. 어플리케이션은 파일의 사본갯수를 지정할 수 있습니다. 복사계수는 파일을 생성할때 설정할 수 있으며 추후에 변경될 수 있습니다. HDFS의 파일들은 한번-쓰고(write-once) 항상 유일한 작성자를 갖습니다.
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.
네임노드는 블록들의 복사와 관련한 모든 결정들을 처리합니다. 네임노드는 클러스터의 데이타노드들로 부터 주기적으로 생존신호와 블록 레포트를 전송받습니다. 생존신호가 수신되는 것은 해당 데이타노드가 정상동작함을 의미합니다. 블록 레포트는 해당 데이타노드에 존재하는 모든 블록들의 리스트를 가지고 있습니다.

HDFS Datanodes

Replica Placement: The First Baby Steps
복사본 배치: 첫 걸음마

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의 신뢰성과 성능에 결정적인 문제입니다. 사본 배치의 최적화는 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
거대한 HDFS 인스턴스들은 일반적으로 수많은 랙들에 분산설치된 컴퓨터 클러스터에서 동작합니다. 서로 다른 랙에 위치한 두 노드간의 통신은 스위치들을 통과해야 합니다. 대부분의 경우, 같은 랙간의 네트워크 대역폭은 서로 다른 랙들간의 대역폭보다 훨씬 큽니다.
The NameNode determines the rack id each DataNode belongs to via the process outlined in Rack Awareness. 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.
네임노드는 랙 인식(Rack Awareness) 방법에 따라 각각의 데이타노드들이 설치된 랙을 구별합니다. 단순하지만 최적화되지는 않은 정책은 복사본을 서로 다른 랙에 위치시키는 것 입니다. 이는 랙 전체에 장애가 발생했을때 데이타 손실을 방지하고 데이타 읽기시 복수 개의 랙의 대역폭을 활용하도록 합니다. 이 정책은 복사본을 클러스터 전체에 균등하게 분산시켜 컴포넌트 장애에 따른 부하를 쉽게 분산키도록 합니다. 하지만 이 정책은 쓰기 시 복수 개의 랙에 블록들을 전송해야 하므로 쓰기 부하를 상승시킵니다.
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.
일반적으로 복사계수가 3일때 HDFS의 배치 정책은 하나의 사본을 동일 랙에 위치한 노드에 저장하고, 또 하나는 동일 랙의 다른 노드에 저장하며, 마지막 하나는 다른 랙의 노드에 저장하게 됩니다. 이 정책은 일반적으로 쓰기성능을 향상시키는 랙 내부간의 쓰기 트래픽을 제한합니다. 랙 장애의 확률은 노드 장애시보다 훨씬 낮습니다; 이 정책은 데이타 신뢰성과 가용성을 보장하는데 별다른 문제를 미치지 않습니다. 하지만 하나의 블록이 개별적인 두개의 랙에 위치하게 하므로 3개 랙에 분산한 경우보다 전체 네트워크 대역폭 사용을 감소시킵니다. 이 정책에 따르면 파일의 복사본은 랙 전체에 걸쳐 고르게 분산되지 않습니다. 복사본의 1/3은 하나의 노드에, 2/3은 하나의 랙에 위치하며 나머지는 다른 여분의 랙에 분산됩니다. 이 정책은 데이타 신뢰성이나 읽기 성능을 손상시키지 않는 선에서 쓰기 성능을 개선합니다.
현재 위와 같은 기본 사본 배치정책은 작업중에 있습니다.

Replica Selection
복사본 선택

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
전체적인 대역폭 사용율과 읽기 지연시간을 최소화하기 위해 HDFS는 reader로부터가 가장 가까운 복사본에서 읽기요청을 수행하도록 하기 위해 노력합니다. 만일 리더의 노드와 같은 랙에 복사본이 존재하는 경우 해당 사본은 읽기 요청을 수행하기 위해 준비됩니다. 만약 angg/HDFS 클러스터가 여러개의 데이타 센터들이 연결되어 있는 구조라면, 해당 데이타센터에 존재하는 복사본을 다른 어떤 사본들보다 우선시합니다.

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.
시작시, 네임노드는 안전모드라는 특정 상태에 진입합니다. 안전모드시에는 데이타 블록들에 대한 복사작업이 발생하지 않습니다. 네임노드는 데이타노드들로부터 허트비트(Heartbeat) 신호와 블록리포트(Blockreport) 메세지들을 수신합니다. 블록리포트는 해당 데이타노드가 보유한 데이타 블록들의 리스트를 가지고 있습니다. 각 블록은 설정된 최소 사본 숫자를 가지고 있습니다. 데이타 블록의 최소 사본 갯수 정보가 네임노드에 등록될때 블록이 안전하게 복사되었는지 확인합니다. 안전하게 복사된 블록들을 설정가능한 특정 비율까지 네임노드가 확인한 이후(+30초) 네임노드는 안전모드 상태를 종료합니다. 그리고 지정된 사본 숫자보다 적은 데이타 블록들의 리스트를 확인합니다. 그리고 네임노드는 해당 블록들을 다른 데이타노드들에 복사합니다.

The Persistence of File System Metadata
파일 시스템 메타데이타의 영속성

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.
HDFS의 네임스페이스는 네임노드에 저장됩니다. 네임노드는 파일 시스템 메타데이타에 발생한 모든 변경사항을 지속적으로 기록하기 위해 EditLog라고 하는 트랜잭션 로그를 사용합니다. 예를 들어, HDFS에 새로운 파일을 생성하면 네임노드는 EditLog에 이를 기록합니다. 마찬가지로 파일의 복사계수를 변경하면 EditLog에 새로운 기록을 추가하게 됩니다. 네임노드는 EditLog를 호스트 운영체제의 파일로 기록합니다. 파일과 블록들간의 맵핑과 파일 시스템 속성을 포함하는 모든 파일 시스템 네임스페이스는 FsImage라는 파일에 기록됩니다. FsImage 역시 네임노드의 로컬 파일시스템에 저장됩니다.
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.
네임노드는 모든 파일 시스템 네임스페이스와 파일 Blockmap 의 이미지를 메모리상에 유지합니다. 이 핵심 메타데이타 요소는 네임노드가 4GB 정도의 램으로 엄청난 수의 파일들과 디렉토리들을 충분히 지원할 수 있도록 작게 설계되었습니다. 네임노드가 실행될때 디스크로부터 FsImage 와 EditLog를 읽어들이고 EditLog상의 모든 트랜잭션들을 메모리상의 FsImage에 적용한 이후 변경된 FsImage를 디스크에 저장합니다. 그리고 오래된 EditLog를 폐기하는데 이는 트랜잭션들이 영속성을 가진 FsImage에 적용되었기 때문입니다. 이러한 과정을 체크포인트 라고 합니다. 현재 구현상에서 checkpoint는 오직 네임노드가 실행될때만 발생합니다. 추후에 주기적인 첵크포인트 작업을 지원하도록 작업중에 있습니다.
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 데이타를 로컬 파일 시스템의 파일들로 저장합니다. 데이타노드는 HDFS 파일들에 대해서는 알지 못합니다. 이는 각 HDFS 데이타 블록을 로컬 파일 시스템에 분리된 파일로 저장합니다. 데이타노드는 모든 파일을 같은 디렉토리에 생성하지 않습니다. 대신에 디렉토리 하나당 최적의 파일수을 발견적인 방법으로 결정하고 서브디렉토리들을 적절하게 생성합니다. 로컬 파일시스템은 하나의 디렉토리에 엄청나게 많은 수의 파일들을 효과적으로 지원하지 못하므로 하나의 디렉토리에 모든 지역파일을 생성하는 것은 적절하지 않습니다. 데이타노드가 실행될때 로컬 파일 시스템을 탐색하고 각 로컬 파일들에 대항하는 HDFS 데이타 블록들의 목록을 작성하여 해당 레포트를 네임노드에 전송합니다. 이것이 Blockreport 입니다.

The Communication Protocols
통신 프로토콜

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 통신 프로토콜들은 TCP/IP 프로토콜의 최상위 레이어에 위치합니다. 클라이언트는 설정가능한 TCP 포트를 통해 네임노드 장비와 연결을 설정합니다. 클라이언트는 클라이언트 프토토콜을 통해 네임노드와 교신합니다. 데이타노드는 데이타노드 프로토콜을 사용하여 네임노드와 교신합니다. 원격 절차 호출(RPC:Remote Procedure Call) 추상화를 통해 클라이언트프로토콜과 데이타노드프로토콜을 감쌉니다. 설계에 따라 네임노드는 어떠한 RPC도 사용하지 않으며 대신 데이타노드나 클라이언트의 RPC 요청에 응답만을 수행합니다.

Robustness
로버스트:견고성

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.
HDFS의 주요한 목적은 장애시에도 신뢰성있게 데이타를 저장하는데 있습니다. 3개의 일반적은 장애유형으로는 네임노드 장애, 데이타노드 장애 그리고 네트워크 단락이 있습니다.

Data Disk Failure, Heartbeats and Re-Replication
데이타 디스크 고장, 생존신호와 재-복사

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.
각각의 데이타노드들은 주기적으로 네임노드에 허트비트 신호를 전송합니다. 네트워크의 단락은 하위 데이타노드들과 네임노드간의 연결을 단절시킵니다. 네임노드는 허트비트 메세지의 부재를 통해 상황을 인지합니다. 네임노드는 허트비트 메세지를 보내지 않는 데이타노드를 죽었다고 취그하고 어떠한 새로운 IO 요청도 보내지 않습니다. 죽은 데이타노드에 등록된 모든 데이타는 더이상 HDFS에 유효하지 않게 됩니다. 데이타노드의 죽음은 일부 블록들의 사본숫자가 설정된 복사계수보다 부족한 상황을 유발할것입니다. 네임노드는 지속적으로 해당 복사본 생성이 필요한 블록들을 추적하고 필요한 경우 복사작업을 수행합니다. 재-복사의 필요성은 여러 이유들로 발생합니다; 데이타노드가 비활성화 되거나, 복사본의 손상, 데이타노드 하드디스크의 고장, 파일의 복사계수의 증가하는 경우입니다.

Cluster Rebalancing
클러스터 부하분배

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.
HDFS 아키텍쳐는 데이타 부하분배 설계와 호환됩니다. 이 설계안은 한 데이타노드의 여유공간이 특정 임계치까지 떨어진 경우 자동적으로 해당 데이타노드의 데이타를 다른 데이타노드로 옮길 것입니다. 특정 파일에 대한 갑작스러운 수요증가시, 동적으로 추가적인 복사본을 생성하고 클러스터의 다른 데이타들을 재분배 할 것입니다. 이런 방식의 데이타 부하분배 계획은 아직 구현되지 않았습니다.

Data Integrity
데이타 무결성

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.
데이타노드로부터 가져온 데이타 블록이 손상되어 전달될 수 있습니다. 이러한 손상은 저장장치 고장, 네트워크 장애, 소프트웨어 버그등에 기인할 것입니다. HDFS 클라이언 소프트웨어는 HDFS 파일들의 내용에 대한 체크섬을 확인합니다. 클라이언트가 HDFS 파일을 생성할때 파일의 각 블록들에 대한 체크섬을 생성하고 동일한 HDFS 네임스페이스에 분리된 숨김파일로 이를 저장합니다. 클라이언트가 파일 컨텐츠를 요청할때 각 데이타노드로부터 받아온 데이타와 해당하는 체크섬 파일의 체크섬이 일치하는지 확인합니다. 일치하지 않는 경우 클라이언트는 해당 블록의 사본을 가진 다른 데이타노드에게 해당 블록을 요청합니다.

Metadata Disk Failure
메타데이타 디스크 장애

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.
FsImage 와 EditLog 는 HDFS의 주요한 데이타 구조입니다. 해당 파일들의 손상은 HDFS 인스턴스를 고장낼 수 있습니다. 이런 이유로 네임노드는 FsImage 와 EditLog 의 복수개의 사본을 유지하도록 설정할 수 있습니다. FsImage 와 EditLog 에 대한 모든 변경사항은 각 사본들에 동기적으로 업데이트됩니다. FsImage 와 EditLog 사본들에 대한 이러한 동기적인 업데이트는 네임노드가 수행할 수 있는 초당 네임스페이스 트랜잭션 처리율을 저하시킬 수 있습니다. 하지만 HDFS 어플리케이션들이 실제 매우 데이타 의존적이며 메타데이타에 집중하지 않으므로 이러한 하락률은 타당한 수준입니다. 네임노드가 재시작될때 네임노드는 가장 최근의 FsImage 와 EditLog 를 선택해 사용합니다.
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.
네임노드 장비는 HDFS 클러스터에서 장애의 단일지점입니다. 만약 네임노드가 고장난다면 수동으로 이를 해결해야 합니다. 현재 자동 재실행과 장애시 예비 장비에 의한 네임노드 소프트웨어의 대체 실행은 지원되고 있지 않습니다.

Snapshots
스냅샷

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.
스냅샷은 특정 순간의 데이타 복사본을 저장할 수 있도록 합니다. 스냅샷 기능은 손상된 HDFS 인스턴스를 이전에 정상적으로 작동하던 시점으로 롤백할 수 있도록 할것입니다. HDFS는 아직 스냅샷을 지원하지는 않지만 추후 버전에서는 지원하게 될것입니다.

Data Organization
데이타 구조

Data Blocks
데이타 블록

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.
HDFS는 매우 큰 파일을 지원하도록 설계되었습니다. HDFS 호환 어플리케이션들은 큰 데이타셋을 사용합니다. 이러한 어플리케이션들은 데이타를 한번만 쓰지만 여러번 읽으며 읽기 작업은 스트리밍 속도를 만족해야 합니다. HDFS는 파일들에 대한 한번-쓰고-여럿이-읽는 시멘틱을 지원합니다. HDFS에서 일반적으로 사용되는 블록의 크기는 64MB 입니다. 따라서 HDFS 파일은 64MB크기의 조각들로 나뉘며 가능한한 서로 다른 데이타노드에 해당 조각들을 위치시킵니다.

Staging
스테이징

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 클라이언트는 먼저 로컬 임시파일에 파일 데이타를 캐시합니다. 어플리케이션의 쓰기작업은 로컬 임시파일로 직접 리다이렉트 됩니다. 로컬 파일의 크기가 HDFS 블록 하나를 할당할 가치가 있을만큼 커졌을때 클라이언트는 네임노드에 접속합니다. 네임노드는 파일 시스템 계층에 파일명을 등록하고 파일에 데이타 블록을 할당합니다. 네임노드는 클라이언트의 요청에 대한 데이타노드 식별자와 목적 데이타 블록을 전달합니다. 그러면 클라이언트는 로컬 임시파일로부터 데이타의 블록을 할당된 데이타노드에 반영합니다. 파일이 닫힐때, 로컬 임시파일의 아직 반영되지 않은 남은 데이타를 데이타노드에 전송합니다. 그리고 클라이언트는 네임노드에 파일이 닫혔음을 알립니다. 이 때, 네임노드는 파일 생성작업을 파일 시스템 영속성에 반영합니다. 만일 파일이 닫히기 전에 네임노드가 죽은 경우 해당 파일을 잃게 됩니다.
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
위의 접근법은 HDFS에서 동작하는 대상 어플리케이션들을 신중하게 고려한 뒤에 적용되었습니다. 이러한 어플리케이션들은 파일에 대한 스트리밍한 쓰기를 필요로 합니다. 클라리언트측에서 버퍼링 없이 바로 원격 파일에 쓰기를 수행한다면 네트워크 속도와 네트워크 혼잡은 성능에 상당한 영향을 미치게 됩니다. 이러한 접근법에 대한 선례가 없던것은 아닙니다. 예를 들면 AFS같은 초기 분산 파일 시스템은 성능향상을 위해 클라이언트측 캐싱을 사용하였습니다. POSIX 요구조건은 데이타 업로드시 높은 성능 제공하기 위해 완화되었습니다.

Replication Pipelining
복사 파이프라인

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 파일의 복사계수가 3이라고 생각해 봅시다. 로컬 파일에 사용자 데이타의 모든 블록들이 쌓였을때, 클라이언트는 네임노드에 데이타노드 목록을 요구합니다. 이 목록은 블록의 사본을 저장할 데이타노드들을 담고 있습니다. 클라이언트는 데이타 블록을 첫번째 데이타노드에 반영합니다. 첫번째 데이타노드는 데이타를 작은 구획(4KB)들로 전송받기 시작하고, 각 구획 데이타를 로컬 저장소에 저장하고 리스트의 두번째 데이타노드로 전송합니다. 두번째 데이타는 데이타 블록의 구획들을 전송받아 로컬 저장소에 저장하고 세번째 데이타노드로 전송합니다. 마침내 세번째 데이타노드는 해당 데이타를 로컬 저장소에 저장합니다. 따라서 데이타노드는 데이타는 데이타노드는 이전 데이타노드로부터 파이프라인을 통해 데이타를 전송받고 동시에 데이타를 다른 데이타노드로 파이프라인을 통해 전송합니다. 그러므로 데이타는 하나의 데이타노드로부터 다른 데이타노드로 파이프라인 전송됩니다.

Accessibility
접근성

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.
어플리케이션이 HDFS의 접근하는 방법은 여러가지가 있습니다. HDFS는 원래 어플리케이션에 자바 API를 제공합니다. 이 자바 API를 C 언어로 래핑한 버전 역시 제공합니다. 추가적으로 HTTP 브라우저 또한 HDFS 인스턴스의 파일들을 열람할 수 있습니다. WebDAV 프로토콜을 통해 HDFS를 노출하는 방법이 작업중에 있습니다.

DFSShell

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
HDFS는 사용자 데이타를 파일과 디렉토리 형식으로 관리할 수 있도록 합니다. 사용자가 HDFS의 데이타를 다룰 수 있도록 DFSShell 이라고 하는 커맨드라인 인터페이스를 제공됩니다. 명령어 문법은 사용자들이 이미 친숙한 다른 쉘들(e.g. bash, csh)과 유사합니다. 아래는 명령어 사용법에 대한 설명중 일부입니다.

Action Command
  /foodir 디렉토리 생성 bin/hadoop dfs -mkdir /foodir
  /foodir/myfile.txt의 내용보기 bin/hadoop dfs -cat /foodir/myfile.txt

DFSShell is targeted for applications that need a scripting language to interact with the stored data.
DFSShell 은 저장된 데이타에 대해 스크립트 언어로 작업하는 어플리케이션들을 대상으로 합니다.

DFSAdmin

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:
DFSAdmin 명령어들은 HDFS 클러스터를 관리하는데 사용됩니다. 이 명령어들은 오직 HDFS 관리자만이 실행할 수 있습니다. 아래는 명령어 사용법에 대한 설명중 일부입니다.

Action Command
클러스터를 안전모드로 바꾼다 bin/hadoop dfsadmin -safemode enter
데이타노드 목록 생성
bin/hadoop dfsadmin -report
데이타노드 기능중지 bin/hadoop dfsadmin -decommission datanodename

Browser Interface
브라우저 인터페이스

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.
일반적인 HDFS 설치는 설정가능한 TCP포트를 통해 HDFS 네임스페이스를 노출하는 웹 서버를 설정합니다. 이를 통해 웹브라우저를 사용하여 HDFS의 네임스페이스 탐색하고 파일들의 내용을 볼 수 있습니다.

Space Reclamation
공간 확보

File Deletes and Undeletes
파일의 삭제와 복구

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.
사용자나 어플리케이션에 의해 파일이 삭제됬을때, HDFS에서 즉시 삭제되지 않습니다. HDFS는 먼저 파일을 /trash 디렉토리로 이동시킵니다. 파일은 /trash에 보관되고 있는 동안은 금방 복구할 수 있습니다. 파일은 설정된 시간만큼 /trash 디렉토리에 보관됩니다. /trash 에서의 수명이 지난 파일에 대해 네임노드는 HDFS 네임스페이스에서 해당 파일을 삭제합니다. 파일에 대한 삭제는 해당 파일에 할당된 블록들을 지우게 됩니다. 사용자에 의해 파일이 삭제된 시간과 그로인해 HDFS 여유공간이 증가하는 시간사이에 인지할만한 지연시간이 발생할 수 있습니다.
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.
사용자는 삭제한 파일이 /trash 디렉토리에 남아있는 동안은 삭제된 파일을 복수할 수 있습니다. 만일 사용자가 삭제한 파일을 복구하고 싶은 경우, /trash 디렉토리를 탐색하여 해당 파일을 찾아냅니다. /trash 디렉토리는 삭제된 파일의 가장 최근사본만을 갖습니다. /trash 디렉토리는 한가지 특징을 제외하고는 다른 디렉토리와 완전히 동일합니다: HDFS는 이 디렉토리의 파일을 자동적으로 삭제하는 특정 정책을 적용할 수 있습니다. 현재의 기본 정책은 /trash 디렉토리에서 6시간이 지난 파일들을 삭제하는 것입니다. 앞으로는 잘 정의된 인터페이스를 통해 이 정책을 수정할수 있게 할것입니다.

Decrease Replication Factor
복사계수 감소

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.
파일의 복사계수가 감소할때, 네임노드는 삭제 가능한 초과된 복사본들을 선택합니다. 다음번 허트비트는 이 정보를 데이타노드로 전송합니다. 그러면 데이타노드는 해당 블록들을 삭제하고 그에 따르는 여유공간이 클러스터에 확보됩니다. 다시 말하지만, setReplication API 호출의 완료시점과 클러스터의 여유공간에 반영되는 시간 사이에는 지연시간이 있을 수 있습니다.

References

by Dhruba Borthakur


이 게시물을..