본문 바로가기
BigData 기술/Hadoop

HDFS 주요 개념 - 네임노드, 데이터노드

by 잇서니 2019. 10. 28.
반응형
HDFS는 네임노드(master)와 데이터노드(slave)로 구성되어 있으며 데이터를 분산 저장하는 파일시스템입니다. Hadoop의 핵심이기도 합니다.

이 글에서는 HDFS의 특징과 네임노드, 데이터노드의 주요 특징을 정리합니다.

 

 

1. HDFS 특성

  • scale out
  • 블록을 복제하여 저장하므로 하나 서버가 장애가 나도 영향도가 적음
  • 하둡은 원래부터 배치 프로세싱을 위해 디자인됨

 

  • worm (write-once-read-many)
    • 오직 하나의 주체만 파일을 쓸 수 있다. 동시쓰기 x
    • 파일 쓰기에 대한 사용권(lease) 개념이 적용된다. 클라이언트는 파일쓰기를 위해 일정 기간의 사용권을 얻어야 한다. 그 동안 다른 클라이언트는 해당 파일쓰기를 할 수 없다.

 

  • update는 불가능하며 append 개념이 적용됨
    • update작업을하려면아래와같은테이블을활용해야함
      • hive transaction table
      • phoenix table
      • ...

 

  • 대용량 데이터에 맞게 디자인 됨
    • 블럭사이즈 디폴트가 128MB, 512MB까지 설정가능
    • 사이즈가 작은 파일이 여러개 있는 것은 부적합.(파일이 1MB여도 128MB 블록 1개에 저장됨. 그 다음 파일은 다른 블록에 저장됨.)
      • 네임노드는 각 블록마다 메타데이터를 갖고 있다.
      • 작은 파일이 여러개 있으면 메타데이터도 많아지므로 네임노드 성능저하를 발생시킴

 

2. 네임노드

(1) 메타데이터 관리

메타데이터는 기본적으로 메모리에 로딩해놓는다.

 

fsimage 파일

  • 어떤 시점에서 HDFS 메타데이터에 대한 스냅샷 파일이다.
  • 가장 최근에 체크포인팅(fsimage + edits => fsimage)을 한 시점까지의 메타데이터를 갖고 있다.
  • 파일 퍼미션, 엑세스 시간, HDFS 파일 위치, HDFS 블록 메타정보가 기록되어 있다. 
  • dfs.namenode.name.dir 경로에 저장이 된다. (디스크에도 저장)
  • 네임노드 시작할 때 fsimage를 메모리에 로딩한다.

 


edits 로그

  • 마지막 체크포인팅이후, 변경사항을 기록하는 로그파일이다.
  • 네임노드 시작할 때 edits log를 fsimage에 적용한다. (체크포인팅)
  • 네임노드가 HA 구성이 되어있는 경우, 액티브 네임노드가 저널노드에 edits 로그를 쓴다. 스탠바이 네임노드는 저널노드에서 edits 로그를 읽고, 주기적으로 체크포인팅을 수행한다. 
  • dfs.journalnode.edits.dir 경로에 저장이 된다. (디스크에도 저장)

 


블록 매핑 정보

  • 네임노드가 시작할 때, 데이터노드로부터 블록위치 정보를 받는다.
  • 네임노드가 시작한 이후 데이터노드가 주기적으로 블록리포트(블록위치 정보)를 준다.
  • 네임노드가 갖고 있는 블록 메타정보와, 데이터노드가 보내준 블록위치 정보를 매핑하여 각 블럭의 위치를 매핑한다. 매핑된 내용은 따로 디스크에 저장하지 않고, 메모리에만 저장해놓는다.

 

(2) 데이터노드 관리

  • 네임노드는 주기적으로 데이터노드에게 Heart Beat를 받아서 데이터노드 상태를 체크한다.
  • 장애가 생긴 데이터노드를 감지하면 조치를 취한다.
    • 데이터노드 상태를 dead로 변경한다.
    • 장애가 생긴 데이터노드에 I/O가 생기지 않도록 한다.
 
 

(3) 구동과정

아래 글을 참고해주세요.

 

[HDFS] 네임노드 구동과정 (Namenode Startup Process)

네임노드가 시작되는 과정을 정리하면서 네임노드의 동작들을 더 제대로 이해해보고자 합니다 :) 1. fsimage를 디스크에서 읽어 메모리에 로딩한다. fsimage는 dfs.namenode.name.dir 경로에 저장되어 있다

it-sunny-333.tistory.com

 

 

 

(4) 체크포인팅

  • 체크포인팅을 주기적으로 안 해주면, edits 로그가 계속 커진다. 네임노드를 재시작할 때 fsiamage를 메모리에 로딩하고 edits 로그를 반영하는데 edits 로그가 크면 반영하는 시간이 길어진다. 그럼 그 시간동안에 하둡 클러스터를 사용할 수 없게 된다. 그래서 정기적으로 체크포인팅을 해서 네임노드를 빠르게 재시작할 수 있도록 한다.
  • edits_log + fsimage => fsimage

 

(5) 네임노드 HA 구성요소

  • Active / Standby NameNode
  • Journal Node
  • Zookeeper
  • ZKFC (Zookeeper Failover Controller)

 

네임노드 HA에 대한 상세한 설명은 아래 글에 정리해두었습니다.

 

[HDFS] 네임노드 HA(High Availability, 고가용성)와 체크포인팅

네임노드의 역할부터 알아보자. (1) 메타데이터 관리 기본적으로 메타데이터는 메모리에 로딩해놓는다. fsimage 파일 어떤 시점에서 HDFS 메타데이터에 대한 스냅샷 파일이다. 가장 최근에 체크포

it-sunny-333.tistory.com

 

(6) 네임노드 주요설정

  • dfs.namenode.dir
  • dfs.namenode.resource.du.reserved
  • dfs.namenode.shared.edits.dir
  • dfs.journalnode.edits.dir
  • fs.defaultFS
  • fs.nameservices
 

2. 데이터노드

(1) 블럭 복제

  • 3 copy : 노드 / 같은 랙 노드 / 다른 랙 노드

 

  • 쓰기
    • client가 네임노드에게 데이터노드 리스트를 요청함
    • 네임노드는 블록을 저장할 데이터노드 3개를 알려줌
    • client는 무작위 순서로 데이터노드에 데이터를 밀어넣음
    • client는 primary 데이터노드에게 쓰기 요청을 보냄
    • primary 데이터노드는 나머지 secondary 데이터노드들에게 쓰기 요청을 보냄
    • secondary 데이터노드가 블럭 쓰기를 완료했으면 primary 데이터노드에게 알림
    • primary 데이터노드는 client에게 쓰기 완료됐다고 응답함

 

  • 읽기
    • client가 네임노드에게 블록을 저장하고 있는 데이터노드 리스트를 요청함
    • 네임노드는 데이터노드 리스트를 알려줌
    • client는 각 데이터노드에 접근하여 블럭을 읽는다.
    • 마치 스트리밍처럼 1번 데이터노드에서 다 읽었으면 그 다음 데이터노드에서 읽고 ...
 

(2) 블럭데이터

  • 모든 HDFS 데이터는 데이터노드가 실행되는 노드의 로컬 파일 시스템에 저장된다.
  • dfs.datanode.data.dir 경로에 데이터가 저장된다.
  • 실제 데이터를 갖고 있는 데이터 파일과 메타파일(체크섬, 생성 스탬프 등)이 있다.
ls -al /data1/hdfs/data/current/BP~~~/current/finalized/subdir99/subdir166

blk_1080272385
blk_1080272385_6535378.meta
  • 하둡의 기본 블럭 사이즈는 128MB 이다. 파일이 블록 사이즈보다 작으면 전체 블록을 모두 사용하지 않고 일부 영역만 사용한다.
 

(3) Block Report / Heartbeat

  • Block Report : 블럭위치정보, 생성 스탬프 등에 대한 정보를 네임노드에게 보낸다.
  • Hearbeat : 데이터노드 살아있어요! 신호를 네임노드에게 보낸다.
 

(4) 데이터노드 주요설정

  • dfs.datanode.data.dir
  • dfs.datanode.du.reserved

 

 

 

반응형

댓글