HDFS Design Goal & Block Based File System

HDFS

HDFS는 하둡의 file system을 말한다.

Design Goal

1. Hardware Failure

hdfs는 분산 서버에 발생하는 다양한 장애를
빠른 시간에 감지하고 대처할 수 있게 설계되었다.
데이터를 저장하면 복제본을 만들며 분산 서버들은 주기적으로 health check를 통해 장애를 빠르게 감지하고 대처한다.

2. Streaming Data Access

HDFS는 클라이언트의 요청을 빠르게 처리하는 것보다 동일한 시간 내에 더 많은 데이터를 처리하는 것을 목표로 한다.
그래서 user와의 상호작용보다는 batch 처리에 더 맞게 디자인 되어있다.

HDFS는 Random Access 대신 Streaming 방식으로 데이터를 접근한다.

3. Large Data Sets

하나의 파일이 GB ~ TB 수준의 크기로 저장될 수 있게 설계되었다. 높은 bandwidth를 지원하고 하나의 클러스터에서 수백대의 노드를 구성할 수 있다. 하나의 인스턴스에서는 수백만개 이상의 파일을 지원한다.

4. Simple Conherency Model

write-once-read-many access model로
한 번 저장한 데이터는 수정할 수 었으며 읽기만 여러번 가능하게 하여 무결성을 지킨다.
append는 가능하다.

이런 방식은 높은 throughput을 가능하게 하며 MapReduce에서 큰 장점을 발휘한다.

5. Moving Computation is Cheaper than Moving Data

데이터를 이동시켜야 할 때, 데이터가 크기 때문에 데이터가 아닌 컴퓨팅 자원을 이동시킨다.

6. Portability Across Heterogeneous Hardware and Software Platforms

쉽게 HW/SW 플랫폼을 옮길 수 있도록 디자인 되어있다. 어떤 OS를 사용하고 HW를 사용하던지 동일하게 동작한다.

---

HDFS Architecture

Block Based File System

HDFS는 블럭 구조의 파일 시스템이다.
파일을 일정 크기의 블록으로 나누어서 여러 서버에 분산 저장한다.
기본 블럭 크기는 128MB로 설정되어 있으며 변경 가능하다.
블럭 구조로 분산 저장하기 때문에 대용량 데이터를 저장할 수 있다.

하나의 파일은 하나 또는 복수의 블럭에 저장된다. 그리고 해당 파일이 어느 블록에 저장되었는지는 메타데이터로 name node가 메모리에서 관리한다.
만약 하나의 파일이 하나의 블럭 사이즈를 넘어가면 이전 블럭을 모두 채운 뒤에 다음 블럭을 채우면서 여러 블럭에 나누어 저장된다.
예를 들면 130MB면 128 + 10MB로 나뉘어 2개의 블럭에 저장된다.

그리고 복수의 파일은 반대로 하나의 블럭에 저장될 수 없다.

실제 디스크를 점유하는 공간은 블럭 크기가 아닌 블럭 내에 파일이 실제로 차지한 크기이다.

장점

Block 크기를 고정했기에 여러 장점들이 있다.

1. Disk Seek Time 감소

하드디스크 경우 파일을 찾기 위해서는 seek time과 섹터에 도달하는 search time이 필요하다.
HDFS는 seektime이 bandwidth의 1% 사용하는 것을 목표로 하여 이를 고려하여 적당한 수준의 블럭 크기를 정했다.

2. Metadata size 감소

일반 파일시스템은 블럭/페이지 크기가 4k ~ 8k 정도이기 때문에 대용량 파일을 저장하기에 너무 많은 메타데이터가 생성된다.( 데이터가 어디에 저장되어 있는 지 정보 등)

3. Communication cost between client and namenode

client가 파일을 접근할 때 namenode에 먼저 해당 파일의 위치를 조회한다. 기존 파일 시스템처럼 데이터 블럭이 작아서 개수가 많으면 소통을 위한 비용이 증가한다.