[Hadoop] 하둡 - HDFS 기초 #1

하둡의 시작인 HDFS의 기초 및 아키텍쳐에 관하여 간단하게 정리한글 입니다.

HDFS(Hadoop Distributed File System)은 저사양 서버를 이용하여 대용량의 분산파일시스템을 구축할수 있는 장점이 있습니다.

고사양이나 안정적인 파일저장 또는 트랜잭션에는 적합한 시스템이 아니지만, 대규모 데이터 저장 또는 배치 처리시 유용한 파일 시스템 입니다.

이글은 "시작하세요! 하둡 프로그래밍"을 참고하였습니다.

대부분의 내용이 생략되고 정리된 내용이므로 자세한 내용은 꼭 책을 구입하여 확인하시기 바랍니다.

HDFS의 특징

1. 장애복구

- 빠른시간안에 장애를 파악하고 대처할수 있도록 설계되었습니다. 또한 복제 데이터가 존재하므로 데이터 손실을 방지합니다.

2. 스트리밍 방식의 데이터 접근

- HDFS는 스트리밍 방식으로 데이터에 접근하여 순차적으로 쭈~욱 읽는 방식입니다. 따라서 랜덤 엑세스 방식이 아니므로 빠른게 데이터에 접근하여 처리하기보다는 대용량의 데이터를 순차적으로 처리하는데 적합 합니다.

3. 대용량 데이터 저장

- 하나의 파일이 GB, TB 이상의 크기도 저장할 수 있습니다.

4. 데이터 무결성

- HDFS에 저장되 데이터는 read / append만 가능하며 수정이 불가능 합니다.

Block File System

- 데이터를 블록 단위로 나눠서 저장합니다.

- 1.2.1에서 블록은 64MB, 2.0 부터는 128MB가 기본 블럭의 크기 입니다.(물론 조정가능)

- 블럭의 메타데이터(파일정보, 파일명, 디렉토리 구조)등은 네임노드에 저장되며 메모리에 로드됩니다.

- 따라서 네임노드의 Heap 메모리에 따라 네임노드가 관리할수 있는 노드의 수는 영향을 받습니다. (100만개의 블록 -> Heap 1GB 필요)

ex) Block size:64MB 이고 저장할 파일이 200MB 라면

1. 파일이 네개의 블럭으로 나눠짐 (Block#1, Block#2, Block#3, Block#4)

2. 네 블럭의 복사본을 기본 세개씩 생성함. (기본 복제값이 3)

3. 따라서 총 저장할 블럭은 4 * 3 = 12개가됨.

4. 12개의 블럭이 여러 데이터노드에 각각 분리되어 저장됨.

-> Datanode1 = { Block#1, Block#2, Block#3 }

-> Datanode2 = { Block#4, Block#2, Block#1 }

-> Datanode2 = { Block#3, Block#4, Block#2 }

....

- 블럭은 무조건 64MB를 사용하는게 아니라, 해당 사이즈에 맞게 조정되어 저장됩니다. -> 10Kb의 파일이 블럭에 담길경우 실제로 10Kb의 디스크 공간만 차지함.

Name node

네임노드는 메타정보저장 및 관리를 진행합니다.

주요 기능은 아래와 같습니다.

1. 메타 데이터 관리: 파일시스템 이미지(파일명, 디렉토리, 파일 크기, 권한)와 블럭정보 mapping 

2. 데이터 노드 모니터링: 

- 데이터 노드는 3초단위로 상태정보와 블록정보를 담은 Heartbeat 시그널을 네임노드로 전송하며, 이 시그널이 오지않으면 장애노드로 판단하여 데이터를 새 노드로 복제.

- 용량이 부족한 노드 발견시 데이터 블록을 다른 노드로 이동.

- 블럭의 복제본수 유지. (복제본 수와 다른 블럭 발견시 삭제 또는 부족시 복제)

3. 클라이언트 요청처리

- HDFS에 파일저장시 네임노드에서 요청을 받아 권한승인을 하거나, 조회시 어떤 블럭을 조회해야 하는지 알려줍니다.

- 단 실제 파일 저장은 Client가 직접 데이터 노드로 전송합니다.

Data node

물리적인 데이터를 저장합니다.

Secondary name node

보조 네임 노드는 변경이력을 파일시스템 이미지(메모리에 저장되어 있는 메타데이터를 저장한 파일)에 반영하는 작업을 합니다.

기본적으로 name node는 메모리에 메타정보를 저장하여 사용하며, restart시를 메모리의 정보 복원을 위해 editslog와 fsimage 파일을 사용합니다.

- editslog: HDFS의 모든 변경이력 저장 (파일저장, 이동 등등..)

- fsimage: 메모리에 저장된 메타데이터의 파일 시스템 이미지를 저장한 파일

- 정보복원 절차

1. 네임노드 구동시 로컬에 저장된 editslog와 fsimage 조회

2. 메모리에 fsimage 로드

3. 메모리에 editslog의 내용 적용

4. 로드된 메모리의 정보로 다시 fsimage 파일 갱싱

5. editslog 초기화

6. 데이터노드가 보낸 Block report를 메모리에 로딩된 파일 시스템 이미지에 적용

- Block report: 데이터 노드에 적용되 있는 블록의 목록

만약 지속적인 파일 시스템 사용으로 editlog 파일의 크기가 커질경우 3번 작업의 시간이 오래 걸릴 수 있습니다.

이를 방지하기 위해 보조네임노드는 주기적으로 editlog를 fsimage에 적용해 주어 editlog의 크기를 줄이는 작업을 수행합니다.

- rolling: 현재의 로그 파일 이름을 변경하고, 원래의 이름으로 로그파일을 새로 만듬

1. 보조네임노드 -> 네임노드: editslog 롤링 요청

2. 네임노드는 editslog 를 rolling (기존 editslog 롤링 및 editslog.new 파일생성)

3. 보조네임 노드는 네임노드의 editslog와 fsimage를 다운로드함

4. 보조네임 노드는 fsimage를 메모리에 로딩후 editslog를 적용 -> 새로운 fsimage.ckpt를 생성

5. fsimage.ckpt를 네임 노드로 전송

6. 네임노드는 fsimage.ckpt를 fsimage로 변경. editslog.new를 editslog로 변경

- 1시간 단위로 주기적으로 작업함. (기본값)

- fs.checkpoint.period 속성값으로 주기 수정 가능

정리하면 보조 네임 노드는 말그대로 네임노드에 장애가 발생시 대체하는 백업서버가 아닙니다.

두개의 파일을 적절하게 싱크해 주는 작업을 따로 진행해주는 노드 입니다.