HDFS란? (하둡분산파일시스템)

HDFS는 하둡 환경에서 분산 파일 시스템 기능을 담당하는 하둡의 주요 모듈입니다. 이번 글에서는 HDFS와 관련해 다음과 같은 부분들을 다루고자 합니다:

 

• HDFS의 주요 목적 (이번글)
• HDFS 주요 개념 및 아키텍쳐
• HDFS(하둡분산파일시스템) 읽기, 쓰기, 삭제 시의 Flow 살펴보기
• HDFS 네임노드 및 데이터노드의 기능과 구현

 

관련글:

• 하둡이란? (Apache Hadoop)

---

HDFS는 설계 시 특정 목적을 가지고 해당 목적을 만족시키기 위해 고안되었습니다. 또한, 그 요구사항을 만족하기 위해 희생한 부분들도 존재하는데요. 그러한 부분들을 알아보며 HDFS가 무엇이고, 어떤 것을 위해 만들어져서 사용되는지 사용하기에 적당하지 않은 곳은 어디인지 알아보겠습니다.

 

Client/Server Distributed File System - Image from [10]

HDFS의 주요 목적

HDFS는 구글파일시스템을 본 떠 오픈소스로 만들어 졌으며, 당시 데이터 환경의 가장 큰 고질병이었던, 잦은 노드 실패에 대한 소프트웨어 레벨의 해결이 주요 목표로 설계되었습니다. 또한, 수년간의 데이터 처리 시에 파일 시스템과 어떻게 작동하는지 분석하여 그러한 워크로드에 최적화하였습니다. 그렇기에 아래와 같은 특징을 가지고 있었습니다 [1, 3]:

 

• 유저스페이스 파일시스템 (FUSE): 전통적인 파일시스템은 (리눅스의) 커널 모듈과 몇몇의 유저스페이스 도구로 구현되어 마운트되고 최종 유저가 사용할 수 있습니다. 반면 HDFS는 유저스페이스 파일시스템입니다. 그렇기에 파일시스템 코드가 커널 스페이스 외부에서 실행됩니다. ext3와 같이 마운트할 필요가 없지만, 애플리케이션이 특정 유저스페이스 파일시스템과 호환가능해야 합니다. 관련된 부분으로, HDFS 사용 시에는 (모든 Replication이 HDFS 애플리케이션레벨에서 처리되기에) RAID와 같은 설정을 끄도록 권장하고 있습니다.

 

• 분산파일시스템: 하나의 디스크나 노드의 제약을 넘기 위해, 클러스터의 각 노드는 완전한 파일시스템의 일부 데이터만 저장합니다. 그렇기에 언제든지 노드를 추가하면 쉽게 전체 파일시스템 크기를 키울 수 있습니다.

 

• 컴포넌트 실패는 자연스럽게 발생하는 일이기에 Fault-tolerance하여야 함: 수백, 수천개의 특별한 하드웨어가 장착되지 않은 컴퓨터로 구성되어 하나의 노드, 파일 또는 블록이 망가지는 것은 자주 겪는 자연스러운 일입니다. 이러한 빈도는 데이터 사이즈가 점점 커지면서 더욱 올라가게 되어 있습니다. 그렇기에 이러한 것은 자동으로 회복될 수 있어야 합니다.

 

• 훨씬 큰 파일을 대상으로 I/O 연산과 블록 사이즈가 구현되어야 함: 파일 사이즈가 기존 시스템의 가정보다 훨씬 커졌습니다. 수십 기가 바이트의 파일이 흔하기에 한 파일의 크기에 대한 가정이 재정립 되어야 하며 그에 맞게 I/O와 블록 사이즈 등이 재설계되어야 합니다.

 

• append에 최적화되어야 함: 데이터 처리 워크로드를 분석 시, 대부분의 작업은 append로 이루어집니다. 그리고 랜덤 write는 거의 존재하지 않습니다. 또한, 한 번 쓰이면 대부분 sequential하게 데이터를 읽어서 사용합니다. 그렇기에 append가 성능 최적화와 Atomicity 확보의 중심이 되는 반면, 클라이언트의 캐싱은 그다지 유효하지 않습니다.

 

모든 아키텍쳐는 Trade-Off가 존재합니다. 위의 목적(장점)을 가진 반면, 하둡이 취약한 부분도 있습니다:

 

• Low-Latency 데이터 액세스: 수십 밀리세컨즈 범위의 latency를 요구하는 애플리케이션 환경에 HDFS는 적절하지 않습니다. 데이터 사용 패턴이 대부분 벌크의 데이터를 처리하는 작업이었기에, HDFS는 높은 처리량을 얻는 대신 latency를 포기하였기 때문입니다.

 

• 많은 수의 작은 파일들: 네임노드가 파일시스템의 메타정보를 인메모리에 가지고 있기 때문에, 파일시스템의 최대 파일 수는 네임노드의 메모리 크기에 좌우됩니다. 대략적으로 각 파일, 디렉토리, 그리고 블록의 메타정보는 150 bytes의 메모리를 차지합니다. 예로, 백만 개의 파일이 있고, 각 파일이 1개의 블록으로 구성되어 있다면 150 * 1,000,000 + 150 * 1,000,000 ~= 300,000,000 bytes로 300 MB의 메모리를 네임노드에서 사용하게 됩니다. 몇 백만의 파일은 가용하나 수십억개의 파일은 현재 하드웨의 한계를 넘어섭니다 [4].

 

• 다수의 writers와 랜덤 파일 쓰기: HDFS의 파일은 하나의 writer에 의해 append-only 형태로 write됩니다. 다수의 writers와 랜덤 파일 쓰기는 지원되지 않습니다.

 

 

Reference

[1] The Google File System

[2] Hadoop Definitive Guide

[3] Hadoop Operations

[4] HDFS Scalability: The limits to growth

[5]  Architecting Modern Data Platform

[6] An Introduction to HDFS Federation

[7] A write‑friendly approach to manage namespace of Hadoop distributed file system by utilizing nonvolatile memory

[8] The Hadoop Distributed File System

[9] GFS: Evolution on Fast-forward

[10] https://www.researchgate.net/figure/Schematic-of-the-Storage-Tank-client-server-distributed-file-system_fig1_3849015