Hadoop 작동 원리 및 컨셉 - Hadoop HDFS 공식 문서 번역

문서 작성 목적

이 문서는 Apache Hadoop HDFS에 대해 설명하고 어떻게 동작하는 지 정리하고 공유하기 위해 작성했다. 이 문서는 Hadoop 공식 문서를 기준으로 조사한 자료를 기반으로 정리했으며 기존 공식문서를 단순 번역한 것이 아닌 내용의 재정리를 통해 알기 쉽게 변형해 작성했다. Hadoop의 버전에 따라 관련 내용이 다른 부분이 있으므로 버전을 확인하고 읽도록 한다.

Hadoop HDFS 버전

이 문서에서 설명하는 Hadoop HDFS 버전은 다음과 같다. 아래의 버전을 사용한 이유는 아직 실제 현업에서는 버전 3 이상의 Hadoop을 이용하는 경우가 아직 드물기 때문에 문서 작성 기준일 기준(2010.03.11) 버전 2의 최신버전을 기준으로 작성하는 것이다.

Hadoop HDFS 2.10.0

Hadoop HDFS란?

Hadoop HDFS(Distributed File System)는 범용 하드웨어에서 실행되도록 설계된 분산 파일 시스템이다. 그러나 다른 분산 파일 시스템과의 차이는 상당하다. HDFS는 내결함성이 높으며 저렴한 하드웨어에 배치되도록 설계되어 있다. HDFS는 애플리케이션 데이터에 대한 높은 처리량 액세스를 제공하며 데이터 세트가 큰 애플리케이션에 적합하다. HDFS는 파일 시스템 데이터에 대한 스트리밍 액세스를 가능하게 하기 위해 몇 가지 POSIX 요구사항을 완화한다. HDFS는 원래 Apache Nutch 웹 검색 엔진 프로젝트를 위한 인프라로 구축되었다. HDFS는 Apache Hadoop Core 프로젝트의 일부이다. project URL은 다음과 같다. http://hadoop.apache.org/

POSIX는 이식 가능 운영 체제 인터페이스의 약자로, 서로 다른 UNIX OS의 공통 API를 정리하여 이식성이 높은 유닉스 응용 프로그램을 개발하기 위한 목적으로 IEEE가 책정한 애플리케이션 인터페이스 규격이다. 위키백과

Hadoop HDFS 목표

Hardware Failure

하드웨어 오류는 예외가 아니라 표준이다. HDFS 인스턴스는 각각 파일 시스템 데이터의 일부를 저장하는 수백 또는 수천 개의 서버 시스템으로 구성될 수 있다. 엄청난 수의 구성요소가 있고 각 구성요소가 사소한 고장 확률을 가지고 있다는 사실은 HDFS의 일부 구성요소가 항상 기능하지 않을 수 있다는 것을 의미한다. 따라서 결함의 감지 및 결함으로부터의 신속하고 자동적인 복구는 HDFS의 핵심 아키텍처 목표다.

Streaming Data Access

HDFS에서 실행되는 애플리케이션은 데이터 세트에 대한 스트리밍 액세스 권한이 필요하다. 이 애플리케이션들은 일반적으로 범용 파일 시스템에서 실행되는 범용 애플리케이션은 아니다. HDFS는 사용자의 대화형 사용보다는 배치 처리를 위해 설계되었다. 데이터 액세스 대기 시간이 짧기 보다는 높은 데이터 액세스 처리량에 중점을 두고 있다. POSIX는 HDFS를 대상으로 하는 애플리케이션에 필요 없는 많은 하드 요구사항을 부과한다. 몇 가지 핵심 영역의 POSIX 의미들은 데이터 처리 속도를 높이기 위해 제외되었다.

Large Data Sets

HDFS에서 실행되는 응용 프로그램에는 대용량 데이터 세트가 있다. HDFS의 일반적인 파일은 크기가 기가바이트에서 테라바이트에 이른다. 따라서 HDFS는 대용량 파일을 지원하도록 조정된다. HDFS는 높은 집계 데이터 대역폭을 제공하고 단일 클러스터에서 수백 개의 노드로 확장해야 한다. 단일 인스턴스에서 수천만 개의 파일을 지원해야 한다.

Simple Coherency Model

HDFS 애플리케이션에는 파일에 대한 Read-Once-Read-Many 액세스 모델이 필요하다. 일단 생성, 작성 및 닫힌 파일은 추가 및 잘라내는 경우를 제외하고 변경할 필요가 없다. 파일 끝에 내용을 추가하는 것은 지원되지만 임의 지점에서는 업데이트할 수 없다. 이러한 가정은 데이터 일관성 문제를 단순화하고 처리량이 높은 데이터 액세스를 가능하게 한다. MapReduce 응용 프로그램 또는 웹 크롤러 응용 프로그램이 이 모델과 완벽하게 일치한다.

“Moving Computation is Chaper than Moving Data”

응용 프로그램이 요청한 계산은 작동하는 데이터 근처에서 실행될 경우 훨씬 효율적이다. 특히 데이터 세트의 크기가 클 때는 더욱 그렇다. 이것은 네트워크 혼잡을 최소화하고 시스템의 전반적인 처리량을 증가시킨다. 그 가정은 종종 응용 프로그램이 실행되고 있는 곳으로 데이터를 이동하기 보다는 데이터가 있는 곳에 더 가깝게 연산장치를 마이그레이션하는 것이 더 낫다는 것이다. HDFS는 응용 프로그램이 데이터가있는 위치에 더 가까이 이동할 수 있는 인터페이스를 제공한다.

Portability Across Heterogeneous Hardware and Software Platforms

HDFS는 하나의 플랫폼에서 다른 플랫폼으로 이동하기 쉽게 설계되어 있다. 이를 통해 대규모 응용 프로그램을 위한 플랫폼으로 HDFS를 널리 채택 할 수 있다.

NameNode and DataNodes

HDFS

Master-Slave 구조를 가지고 있다.
HDFS에는 1개의 NameNode인 Master server가 있고 이 server는 파일 시스템 네임스페이스를 관리하며 클라이언트에 의한 파일 접근을 통제한다.
HDFS 클러스터는 파일 시스템 네임스페이스를 관리하고 클라이언트에 의한 파일 액세스를 제어하는 마스터 서버인 단일 NameNode로 구성된다.
HDFS는 파일 시스템 네임스페이스를 공개하고 사용자 데이터를 파일에 저장할 수 있다.

또한, 일반적으로 클러스터의 노드 당 하나씩 여러 개의 DataNode가 있으며,이 노드는 실행되는 노드에 연결된 스토리지를 관리한다.

NameNode

NameNode는 파일 및 디렉터리 열기, 닫기 및 이름 변경과 같은 파일 시스템 네임스페이스 작업을 실행한다.
DataNode에 대한 블록 매핑도 결정한다.
일반적으로 전용 1대의 서버에 설치되어 사용한다.

DataNode

내부적으로는 파일이 하나 이상의 블록으로 분할되고 이러한 블록은 DataNode 집합에 저장된다.
DataNode는 NameNode의 지침에 따라 블록 생성, 삭제 및 복제도 수행한다.
DataNode는 파일 시스템 클라이언트의 읽기 및 쓰기 요청을 처리할 책임이 있다.

NameNode, DataNode는 일반적인 컴퓨터에서 돌아갈 수 있도록 디자인된 소프트웨어의 일부분이다. 이러한 컴퓨터들은 보통 GNU/Linux OS에서 작동한다. HDFS는 자바 언어를 사용해 빌드되었다; 따라서 자바를 지원하는 어떤 컴퓨터든 NameNode나 DataNode software를 실행할 수 있다. 높은 이식성을 가진 자바의 사용성으로 인해 HDFS는 다양한 기계들에서 적용될 수 있다. 클러스터에 단일 NameNode가 존재하면 시스템의 구조가 크게 단순해진다. NameNode는 모든 HDFS 메타데이터에 대한 중재자 및 저장소이다. 이 시스템은 사용자 데이터가 NameNode를 통과하지 않고 저장될 수 없게 설계되었다.

The File System Namespace

HDFS는 전통적인 계층 파일 구조를 지원한다. 사용자 혹은 응용 프로그램은 디렉토리를 생성하거나 디렉토리 안에 파일을 저장할 수 있다. The File System namespace 계층은 다른 파일 시스템과 유사하다. 파일 생성, 파일 지우기, 파일을 한 디렉토리에서 다른 디렉토리로 이동, 파일의 이름 재지정이 가능하다. HDFS는 user quotas과 access permissions을 지원한다. HDFS는 하드 링크나 소프트 링크를 지원하지 않는다.

HDFS는 FileSystem의 명명 규칙을 따르지만 일부 경로와 이름(예: /.reserved 및 .snapshot )은 예약되어 있다. 투명한 암호화 및 스냅샷과 같은 기능은 예약된 경로를 사용한다.

NameNode는 파일 시스템 네임스페이스를 유지한다. 파일 시스템 네임스페이스 또는 그 속성의 변경은 NameNode에 의해 기록된다. 응용 프로그램은 HDFS로 유지해야 하는 파일의 복제본 수를 지정할 수 있다. 파일의 복사본 개수를 해당 파일의 복제 팩터라고 한다. 이 정보는 NameNode에 의해 저장된다.

Data Replication

HDFS는 다음과 같은 특징을 가진다.

매우 큰 클러스터 안에 있는 머신들을 통해 매우 큰 용량의 파일들을 신뢰성 있게 저장할 수 있게 설계됐다.
파일을 연속적인 블록으로 저장한다.
파일의 블록들은 Fault

_Tolerant_을 위해 복제된다.
블록 사이즈, 복제 팩터는 설정 파일로 설정가능하다.
마지막 블록을 제외한 모든 블록은 같은 크기이다.

응용 프로그램은 파일의 복제본 수를 지정할 수 있다. 복제 팩터는 파일 생성 시 지정할 수 있으며 나중에 변경할 수 있다. HDFS의 파일은 한 번 쓰기(첨부 및 잘라내기 제외)이며, 한 번에 한 명의 작성자가 엄격히 있다.

NameNode는 블록 복제에 관한 모든 결정을 내린다. 클러스터의 각 DataNode에서 주기적으로 하트비트 및 블록 보고서를 수신한다. 하트비트의 수신은 DataNode가 제대로 작동하고 있음을 의미한다. 블록 보고서에는 DataNode의 모든 블록 목록이 포함되어 있다.

Replica Placement: The first baby steps

복제본을 배치하는 것은 HDFS의 신뢰성과 성능에 매우 중요하다. 복제본 배치 최적화는 HDFS가 대부분의 다른 분산 파일 시스템과 구별되는 점이다. 복제본 배치 최적화는 많은 조정과 경험이 필요한 기능이다. Rack-aware한 복제본 배치 정책의 목적은 데이터 안정성, 가용성 및 네트워크 대역폭 활용률을 개선하는 것이다. 복제본 배치 정책에 대한 현재 구현은 이 방향의 첫 번째 노력이다. 이 정책을 구현하는 단기적인 목표는 생산 시스템에서 검증하고, 그 행동에 대해 더 많이 배우고, 보다 정교한 정책을 테스트하고 연구할 수 있는 기반을 구축하는 것이다.

대형 HDFS 인스턴스는 일반적으로 여러 랙에 분산되어 있는 컴퓨터 클러스터에서 실행된다. 서로 다른 랙에 있는 두 노드 간의 통신은 스위치를 통과해야 한다. 대부분의 경우, 동일한 랙에 있는 시스템 간의 네트워크 대역폭은 서로 다른 랙에 있는 시스템 간의 네트워크 대역폭보다 크다.

NameNode는 Hadoop Rack Awareness에 설명된 프로세스를 통해 각 DataNode가 속한 랙 ID를 결정한다. 단순하지만 최적화되지 않은 정책은 복제본을 고유한 랙에 배치하는 것이다. 이것은 전체 랙에 장애가 발생했을 때 데이터가 손실되는 것을 방지하고 데이터를 읽을 때 여러 랙의 대역폭을 사용할 수 있게 한다. 이 정책은 클러스터에서 복제본을 고르게 배포하여 구성 요소 고장에 대한 부하 균형을 쉽게 맞출 수 있도록 한다. 그러나 이 정책은 쓰기 블록을 여러 랙으로 전송해야 하기 때문에 쓰기 비용을 증가시킨다.

공통적으로, 복제 인자가 3일 때, HDFS의 배치 정책은 작성자가 데이타노드에 있는 경우 로컬 컴퓨터에, 그렇지 않으면 작성자와 동일한 랙에 있는 임의의 데이터노드에, 다른 (원격) 랙에 있는 노드의 다른 노드에, 그리고 동일한 원격 랙에 있는 다른 노드에 하나의 복제본을 배치하는 것이다. 이 정책은 일반적으로 쓰기 성능을 향상시키는 랙 간 쓰기 트래픽을 줄인다. 랙 고장의 가능성은 노드 고장의 확률보다 훨씬 적다. 이 정책은 데이터 신뢰성과 가용성 보증에 영향을 미치지 않는다. 그러나 블록이 3개가 아니라 2개의 고유한 랙에만 배치되기 때문에 데이터를 읽을 때 사용되는 총 네트워크 대역폭은 감소한다. 이 정책을 사용하면 파일의 복제본이 랙 전체에 균등하게 분포되지 않는다. 복제본의 첫 번째는 한 노드에, 두 번째는 같은 랙에, 나머지 3분의 1은 다른 랙에 고르게 분포한다. 이 정책은 데이터 신뢰성이나 읽기 성능에 영향을 주지 않으면서 쓰기 성능을 향상시킨다.

   +---------------+        +---------------+
   | Rack          |        | Rack          |
   | +-----------+ |        | +-----------+ |
   | | data node | |        | | data node | |
   | +-----------+ |        | +-----------+ |
   | +-----------+ |        |               |
   | | data node | |        |               |
   | +-----------+ |        |               |
   +---------------+        +---------------+

복제 인자가 3보다 클 경우, 4번째 및 다음 복제본의 배치는 상한(기본적으로 (복제 - 1) / 랙 + 2)의 랙당 복제본 수를 유지하면서 무작위로 결정된다.

NameNode는 1개의 DataNode가 가진 동일한 블록의 복제본을 가지는 것을 허용하지 않기 때문에, 생성된 최대 복제본 수는 해당 시점의 총 데이터 노드 수이다.

HDFS에 스토리지 유형 및 스토리지 정책에 대한 지원이 HDFS에 추가된 후, NameNode는 위에서 설명한 랙 인식 외에도 복제본 배치를 고려한다. NameNode는 처음에는 랙 인식에 기반하여 노드를 선택한 다음, 후보 노드에 파일과 관련된 정책에 필요한 스토리지가 있는지 확인하십시오. 후보 노드에 스토리지 유형이 없는 경우 NameNode는 다른 노드를 찾으십시오. 복제본을 배치하기에 충분한 노드를 첫 번째 경로에서 찾을 수 없는 경우, NameNode는 두 번째 경로에서 폴백 스토리지 유형을 가진 노드를 찾는다.

여기에 설명된 현재 기본 복제본 배치 정책은 진행 중인 작업이다.

스토리지 유형 및 스토리지 정책에 대한 지원이 HDFS에 추가 된 후 NameNode는 위에서 설명한 랙 인식 외에 복제 배치에 대한 정책을 고려한다. NameNode는 처음에 랙 인식을 기반으로 노드를 선택한 다음 후보 노드에 파일과 연관된 정책에 필요한 스토리지가 있는지 확인한다. 후보 노드에 스토리지 유형이 없으면 NameNode는 다른 노드를 찾는다. 첫 번째 경로에서 복제본을 배치하기에 충분한 노드를 찾을 수없는 경우 NameNode는 두 번째 경로에서 대체 스토리지 유형이있는 노드를 찾는다.

kelpin