본문 바로가기
츄Log/끄적끄적

Hadoop 에코시스템 먹방 -2. HDFS

by 츄츄🦭 2024. 6. 11.
728x90

HDFS


> 하둡 클러스터의 데이터 저장소 역할을 하는 분산 파일 시스템임
> 일반적인 상용 하드웨어로 클러스터 구성이 가능하며 대용량 파일을 다룰 수 있도록 설계됨
> 내결함성과 확장성이 뛰어남

HDFS 전제와 목표

Hardware Failure
> 상용 하드웨어를 사용할 수 있도록 설계됨
사용 하드웨어는 쉽게 고장날 수 있기에 HDFS는 서버 장애가 발생하더라도 작업에 영향이 가지 않도록 데이터를 복제하여 저장하고
빠르게 장애를 탐지하여 복구하는 것을 목표로함

Large Data Sets
> 파일을 블록 단위로 저장하여 단일 디스크의 크기보다 큰 파일을 저장할 수 있음

Simple Coherency Model
> 쓰기 연산보다 읽기 연산이 많다는 것을 전제로 함
> HDFS에 저장된 것은 수정이 불가하여 데이터 일관성 문제를 단순화했고 이를 통해 높은 처리량을 지원함

Moving Computation is Cheaper than Moving Data
> 연산에 필요한 데이터가 큰 경우 데이터를 옮겨 연산하는 것보다 데이터가 있는 곳에서 연산하는 것이 효율적임
> HDFS는 애플리케이션이 데이터가 있는 위치에 가깝게 이동할 수 있는 인터페이스를 제공함 


HDFS 구조

> HDFS는 Master역할을 하는 Namenode와 Worker역할을 하는 여러 Datanode들로 이루어져있다
> Namenode는 클러스터에 저장되어있는 파일에 대한 metadata와 Datanode를 관리한다
> Datanode는 실질적으로 데이터를 저장하는 역할을 한다 

Namenode
> 네임노드는 Datanode가 전달해주는 메타데이터를 받아서 전체 노드의 메타 정보와 파일 정보를 묶어서 관리한다. 
(메타데이터는 파일 이름, 파일 크기, 파일이 위치한 블록의 정보 등을 포함한다)
> Datanode가 주기적으로 전달하는 heartbeat와 블록리포트를 통해 데이터노드의 상태와 블록 상태를 관리한다
(블록리포트에는 데이터노드에 저장된 블록 목록과 각 블록이 로컬디스크의 어디에 저장되어있는지에 대한 정보가 포함되어있다)
> 사용자는 namenode를 통해 데이터를 쓰고 읽을 수 있다.
> 데이터노드 하나에 장애가 발생한다면 네임노드는 해당 노드에 저장된 데이터를 다른 노드에 복사하여 유실이 없도록 유지함

Datanode
> 사용자로부터 요청된 읽기/쓰기 작업을 수행하는 주체
> 주기적으로 네임노드에 heartbeat와 블록리포트를 전달하여 데이터가 관리될 수 있도록 함

 

블록이라는 개념

> 파일을 저장하는 Hdfs의 단위
> 파일은 지정한 크기의 블록으로 나뉘고 각 블록은 독립적으로 저장된다. 
> 블록은 128MB와 같이 큰 단위로 설정하여 블록 탐색 비용을 최소화한다.
> 블록단위로 나뉘어 저장되기 때문에 파일 하나의 크기가 단일 디스크의 크기보다 큰 대용량 파일들도 저장 가능하다 
> 블록은 사용자가 설정한 replication factor만큼 복제되어 저장됨
> 보통 3개의 복제본을 생성하고 각각 다른 노드에 분산저장됨
> 일부 노드가 고장날 경우 다른 노드의 블록으로 쉽게 복구할 수 있음
> 맵리듀스를 이용한 분산 컴퓨팅은 블록의 지역성을 이용해 성능을 높일 수 있음 

Namenode의 한계

> Namenode에서 모든 파일의 메타 정보를 메모리에 유지하고 있음.

예를들어 블록 사이즈가 128MB인 환경에서 네임노드의 메모리 사용량은 다음과 같이 계산될 수 있음
1. 1024MB파일 하나를 저장하는 경우
- 1 파일 inode
- 8 블록(1024MB / 128MB)
=> 9 * 150 byte = 1,350 byte의 heap메모리 필요

2. 128MB 파일 8개를 저장하는 경우
- 8 파일 inode
- 8 블록
=> 16 * 150byte = 2,400 byte의 heap 메모리 필요

3. 1MB파일 1,024개를 저장하는 경우
- 1024 파일 inode
- 1024 블록
=> 2048 * 150 = 307,200 byte의 heap 메모리 필요

이처럼 작은 크기로 파일 개수를 늘리게 되면 namenode는 결국 메모리 부족 문제가 발생할 수 있음 (OOM)
네임노드의 메모리는 정해져 있기 때문에, 하나의 네임노드에서 관리할 수 있는 파일개수는 제한적임
(네임노드의 메모리 사용량은 파일 개수에 의존적)

이러한 한계를 극복하기 위해 HDFS Federation 기능을 적용할 수 있음
> 파일 시스템을 여러 네임스페이스로 분리하고, 네임스페이스별로 네임노드를 독립적으로 관리할 수 있음 
> 네임노드가 여러개 생기기 때문에 파일 개수 제한이 확장되며 하나의 네임노드에 문제가 생겨도 다른 네임노드에 영향을 주지 않음 

HDFS사용시 주의점

> 블록 크기보다 작은 파일을 다수 생성하는 사용 패턴은 HDFS에 적합하지 않음 
> 작은 파일을 읽는 것은 네임노드와 데이터노드에 대해 많은 탐색이 필요하므로, 데이터를 비효율적으로 처리하게됨
> YARN에서 데이터를 처리할 때, 블록 단위로 컨테이너를 생성하는 경우가 있어서 블록 수가 많아지면 YARN의 리소스 사용 효율도 떨어짐
> 전체 파일 개수에 제한이 있기 때문에, 작은 파일이 많을 경우 디스크 공간에 여유가 있어도 데이터를 저장할 수 없는 상황이 발생함
> 따라서 10TB데이터 셋을 저장한다고 가정하면 아래에서 두번째처럼 큰 파일로 저장하는 것이 훨씬 효율적임 
    - 1MB크기의 파일 1천만개 (10,485,760개)
    - 1024MB크기의 파일 1만개 (10,240개)

728x90