본문 바로가기
  • 기술을 이야기하지만 사람을 생각합니다.
30. Cloud

[토크ON세미나_아파치 하둡 입문 1/3] HDFS 하둡 분산 파일 시스템

by WE DONE IT. 2022. 1. 22.
하둡 강의를 들으면서 빠르게 메모한 내용입니다.
나중에 예쁘게 정리해서 발행하고 싶었으나 게으름을 이기지 못해 오랫동안 방치하다가, 누군가에게는 일말의 도움이 될 수도 있겠다는 기대를 하며 공개 버전으로 전환하였습니다.

 

출처 :

[토크ON세미나] 아파치 하둡 입문 1강 - 하둡의 탄생과 생태계의 활용 | T아카데미

https://youtu.be/OPodJE1jYbg

 


  • Hadoop 1.0 ver 기준
    • Name Node : DFS 관리 master (데이터의 위치, 형식 보관)
    • Job Tracker : app/job 관리 master
    • 같은 slave node에 demon을 2개(DN, TT) 띄움
      • DN (data node) : 실 데이터 저장하는 slave node
      •  TT (task tracker) : slave node 

Block 블록

  • 하나의 큰 파일을 알아서 쪼개는 단위
  • 하나의 파일을 여러 개의 Block으로 저장
  • 64MB 또는 128MB (하둡이 버전업 하면서 가능해짐) 등의 크기로 나누어서 저장
  • Block하여 저장 후, 남은 파일 크기가 128MB 보다 작은 경우, 실제 크기 만큼만 용량을 차지함

예) 612MB 파일인 경우 -> 128MB + 128MB + 128MB + 128MB + 100MB 

 

하둡에서 블록 하나의 크기가 큰 이유는?

기본값 설정을 바꿀 수 있음

기본값 : 128 MB

 

블록을 탐색할 때 파일의 메타데이터를 빨리 찾기 위해 탐색 비용을 최소화할 수 있음

네트워크 전송시키는 데 시간을 할당할 수 있음

 

1분당 24GB가 생성되는 데이터의 경우

하둡 클러스터에 저장한다면

하둡 내부적으로 알아서 128MB으로 나눔 (블록 개수 : 24GB / 128 MB)

 

데이터를 조각내어 서버 내 분산 저장

데이터를 복사하여 여러 개(최소 3개)를 저장

 

장애가 발생한 경우, 3초마다 생존을 알리는데 일정 시간 이상 보내지 않은 경우 -> 장애로 인식 -> Name node : 모든 데이터의 위치를 알고 있음 + Block 리포트 받음 (Data node 어디에 copy 된지 알고 있음) -> 2번 node한테 3번 block 한번 더 복사하라고 지시함 -> 3 copy 유지

-> 서버가 장애나더라도 3 copy가 유지되도록

(운영자가 할 일은 1도 음슴)

Replica 3 

 

하둡 데이터 유실되는 경우

3개의 data node가 동시에 장애 발생하면 유실될 수 있음

장애나도 자체적으로 복구함

 

마스터 서버 : 모든 장애

하둡 1.0 : 마스터 서버 장애 체계 없음

하둡 2.0 : 마스터 서버 이중화

하둡 3.0 : 데이터 저장양 replication 3 -> 2배정도 이용할 수 있는 기술

 

Spark : 메모리 베이스 데이터 처리 (ETL)

 

네임노드 마스터 노드 스페 : 하둡 내 메타정보를 모두 저장 (메모리 크고, 규모가 있을수록 스펙 좋은 거 저자하는 게 좋음)

 

 

데이터 로컬리티 (Task Tracker)

Map Reduce에서 중요한 개념

실제 데이터가 있는 곳에서 먼저 수행함

연두색 노드가 바쁘면 다른 노드한테 잡을 시킬 수도 있음 (적어도 같은 Rack에 요청함, Rack 내에서 로컬리티를 보장하면 네트워크 이슈 등을 해결할 수 있음 )

데이터를 갖고 있는 노드한테 잡을 어사이니 한다.

적잘한 단위의 블록 크기를 이용한 CPU 처리 시간 증가

대용량 데이터 확인을 위한 디스크 탐색 시간 감소

네트워크를 이용한 데이터 전송 시간 감소

 

블록 캐싱

 

 

네임노드 역할

 

파일시스템 이미지 파일 관리(fsimage) 손상되면 하둡 데이터가 다 날라갈 수도 있음 (스냅샷)

 

보조 네임노드 (Second NN)

네임노드는 최신상태 + 변경된 노드를 반영함 

운영 중 변경된 사항은 edits.node 말고 snn에서 병합한 다음에 nn에 머지함

snn 장애 발생해도 이슈는 없으나 edits.node 부하이슈 -> 재시작할 때 못읽어서 메모리 반영을 못하고 out of memory exception 이 발생함 

장애 상황 감지 툴이 없음

 

 

데이터노느 역할

물리적으로 로컬 파일시스템에 HDFS 데이터를 저장함

진짜 데이터를 저장하는 노드에서는 레이드 구성을 하지 않음 (사용할 수 있는 용량이 줄기 때문, JBOD 구성)

블록 리포트 : 데이터노드가 -> 네임노드한테 리포팅함.

파이프라인 형태로 데이터노드들끼리 3카피 알아서 복사함

 

https://youtu.be/pixlGPc4vbA

 

댓글