Hadoop

: 데이터를 블록이라는 기본 단위로 나누어 파일의 형태로 저장할 수 있는 분산 파일시스템

Hadoop 은 먼저 단일 소프트웨어가 아니라 분산 시스템을 구성하는 다수의 소프트웨어 집합체다.

Hadoop 의 구성 요소

• HDFS : 데이터를 저장하는 분산 저장 스토리지 시스템
• YARN : 클러스터 자원 관리 및 Job 스케줄링 리소스 관리 시스템
• MapReduce : HDFS 에 분산 저장된 데이터를 병렬로 처리하는 것을 돕는 프레임워크
• Hive/Pig (부가적) : SQL 유사 문법으로 데이터 구조화 & 질의

HDFS 구성

NameNode (마스터, Master)

NameNode는 HDFS 클러스터의 중앙 통제 서버이자 Master 노드 역할.

• 메타데이터 관리(저장): 파일 시스템의 네임스페이스 (디렉터리->파일명->블록 시퀀스 -> 저장 위치 ,권한 등)와 파일의 블록 매핑 정보 (블록과 블록들의 순서, 블록을 저장하는 데이터노드 위치)를 관리
  .

파일 시스템의 모든 메타 데이터 저장,사용자에게 전달
- FSimage 파일 (파일 시스템 이미지)
- 네임 스페이스와 블록 정보
- Edits 파일
- 파일의 생성, 삭제에 대한 트랜잭션 로그
- 메모리에 저장하다가 주기적으로 생성한다.

• 클라이언트 접근 조정: 클라이언트가 파일을 읽거나 쓰려고 할 때, NameNode에 먼저 요청하여 파일의 위치 정보나 쓰기 권한을 얻습니다.

• DataNode 관리: DataNode로부터 주기적인 Heartbeat와 Block Report를 받아 DataNode의 상태와 저장된 블록 목록을 모니터링하고 관리합니다. 문제가 생기면 복제(Replication) 명령을 내린다.

• 하둡과 같은 분산파일시스템의 경우 메타데이터가 항상 네트워크를 통해서 전달되어야함 ( 분산되어있기 때문) 일단 네트워크를 거쳐 사용자에게 전달하는 구조 자체가 일반 파일 시스템보다 느리다.

-> 네트워크를 거치는 메타데이터를 메모리에 상주시킴으로써 사용자에게 더 빠르게 메타데이터를 전달할 수 있도록 설계

MetaData 구조

HDFS 디렉토리 구조 : 트리 구조

위에 설명했듯 메타데이터는 Memory 에 상주한다. -> 빠르기 때문
그런데 NameNode는 하나뿐이다. 이 하나뿐인 네임노드 머신이 다운되면 어떻게 될까 -> 시스템이 마비된다 (SPOF)

이럴 경우 빠르게 복구할 수있게 해놓은 것이 Fsimage 와 Edits 이다. + Secondary NamedNode 를 이용한다.

Edits

메타데이터 관련 명령 수행 목록은 Edits 파일에 기록된다. -> Log

Edits 파일은 하둡 파일 시스템의 로그를 관리하는 파일이고 로그가 많이 쌓이게 되면 고장을 복구할때 그만큼 많은 시간이 소요될 것이다.

따라서 Edits 만을 이용하여 복구하지 않는다

Fsimage

Edits 파일에 기록된 내용을 병합하여 기록해 놓은 파일이다. Edits 자체는 시스템 복구에 불필요한 내용도 많이 포함하고 있다.

Secondary NameNode

• NameNode의 원천적인 백업 역할 X , 아예 별개의 노드 , NameNode의 체크포인트를 저장.

위에서 설명한 Edits 파일을 이용해서 FsImage 파일을 병합하는 역할을 한다.

NameNode 에서 Edits 파일을 FsImage 파일로 병합하기 위해서는 NameNode 를 한번 껏다가 다시 시작하면 병합을 수행한다. 하지만 그 병합을 하기 위해서 NameNode를 끌 수 없으니 Secondary NameNode 가 생겨난 것. Secondary NameNode 가 Edits 를 병합해 FsImage 를 만들고 이것을 '체크포인트'라 부른다. 이 FsImage는 다시 NameNode로 전달된다.

core-site.xml 에서 fs.checkpoint.period 로 edits 를 가져와 병합하는 주기를 설정할 수 있고, fs.checkpoint.size로 파일 크기를 설정할 수 있다.

---

DataNode (슬레이브/워커, Slave/Worker)

DataNode는 슬레이브 노드이자 워커 노드 역할을 하며, NameNode의 지시에 따라 실질적인 작업 수행 역할.

• 실제 데이터 저장: 파일이 블록 단위로 쪼개져 DataNode의 로컬 디스크에 저장됩니다. (실제 데이터 소유)

• I/O 요청 처리: 클라이언트로부터 직접 읽기(Read) 및 쓰기(Write) 요청을 받아 데이터를 전송합니다.

• NameNode 보고: 주기적으로 NameNode에 Heartbeat를 보내 자신이 살아있음을 알리고, Block Report를 보내 현재 저장하고 있는 블록 목록을 보고합니다.
  - 주기적으로 NameNode에 하트비트와 블록 리포트 전달
  - Heartbeat → 데이터 노드의 동작 여부 판단
  - Block Report → 블록의 변경사항 체크 → 네임노드의 메타데이터 수정
  

사용자의 파일은 블록 단위로 나누어 관리 + 기본값으로 하나의 블록을 3개의 데이터노드에 복제, 저장 -> 고가용성

Hadoop 2.x/3.x의 기본값은 128MB 또는 256MB.

이유: 블록 크기가 크면 디스크 탐색 시간(Seek Time)에 비해 데이터를 연속적으로 전송하는 시간(Transfer Time)의 비율이 높아져 높은 처리량(High Throughput)을 얻는 데 유리 - 사용자가 사용하는 데이터의 크기에 따라 성능을 최적화하기 위해 임의의 설절 변경을 제공 - hdfs-sit.xml 에서 dfs.block.size 를 설정하면 됨

블록은 모든 운영체제의 파일 시스템에서 사용하는 개념이다. 파일을 블록 단위로 쪼개 디스크에 저장한다.

HDFS 에서는 하나의 블록이 파일에 할당되면 블록을 다 쓰지 않더라도 남은 공간을 활용 할 수 있다.

---

Data Rebalancing

분산 파일 시스템의 용량이 모자라거나 작업을 수행하기 위해 DataNode 의 수가 부족할 수 있다. 이때 HDFS 는 DataNode를 추가함으로써 전체 FS 용량을 사용자가 원하는 대로 늘리거나 동작 중인 노드 수를 증가시킬 수 있다.

새로 추가된 노드에는 아무런 데이터도 존재하지 않음 -> 파일 시스템의 용량 확장 + 사용할 수 있는 노드 수 증가

그러나 이때 fs -get/-put(읽기/쓰기) 이용률의 불균형이 발생한다

• 읽기 명령은 존재하는 데이터로 부터 읽을 수밖에 없기 때문에 새로운 데이터의 역할 X

• 쓰기 명령은 데이터가 적게 존재하는 곳에 쓰도록 설계되어 있어 새로운 데이터노드에만 쓰기 명령이 이루어진다.

이렇듯 새로운 노드 추가는 전체 FS의 용량은 늘릴 수는 있으나 이용률 불균형으로 인해 전체적으로 얻을 수 있는 이득이 적다.
-> 데이터 재배치를 통해 이용률을 고르게 한다.

데이터 재배치는 사용 중인 데이터노드로부터 저장 중인 블록을 새롭게 추가된 데이터노드를 복제하고 기존 데이터노드에서 복제된 블록을 삭제한다.

다만 데이터 재배치에도 단점은 존재한다.

데이터 재배치를 통해 전체 FS 시스템의 용량도 늘리고 이용률도 균형을 맞출 수 있지만, 재배치를 수행하는동안 데이터노드와 네트워크에 불가피한 부하가 발생한다. 한꺼번에 많은 데이터를 옮긴다면 현재 구동중인 HDFS 시스템은 성능이 굉장히 저하될 것이다.

bin/start-balancer.sh 를 통해 재배치 수행 할수 있다.