[빅데이터 전문가의 하둡관리] HDFS의 동작 알고리즘

 

HDFS

 

 

 

---

 

1. HDFS는 네임노드와 데이터노드의 interaction

HDFS를 구성하는 컴포넌트는 네임노드와 데이터노드라는 것을 이전 챕터에서 배웠습니다.

 

 

 

 

- 네임노드는...

 

1) 파일과 디렉토리를 열고 닫는 모든 HDFS 오퍼레이션을 수행한다

 

2) 블록들을 데이터 노드에 할당한다

 

3) 메타 데이터를 관리한다. (파일에 속한 블록들의 위치, 파일의 상태 등...)

 

 

 

 

 

- 데이터노드의 데몬...

 

1) 네임노드에게 서버&포트 정보를 제공하여 클라이언트와 데이터노드가 데이터를 주고받을 수 있게 한다

 

2) 서버의 소켓을 열어둔 상태로 계속 유지하여 클라이언트가 효율적으로 읽고 쓸 수 있도록 돕는다

 

 

 

 

 

- 네임노드가 데이터노드로부터 하트비트를 받지 못하면?

 

1) 10초(default) 동안 데이터노드 77번에서 하트비트가 오지 않았다... (삐빅... 3초에 한 번은 와야 정상인데.....)

 

2) 네임노드는 데이터노드 77번이 죽은 것으로 표시한다

  -> 네임노드의 생각: "블록 10248~10300번을 잃은 건가...."

 

3) 하지만 HDFS에서 블록은 replication으로 여러 노드에 흩어져있기 때문에, 해당 블록들은 10~15번 노드에도 나뉘어 복제되어 있었다! 그래서 네임노드는 10~15번 데이터노드에게 데이터 복제 명령을 내린다.

 

4) 10~15번 데이터노드는 다른 데이터노드들에게 자기가 갖고 있던 블록을 각각 복제했다.

 

5) 잠시 낮아졌던 블록의 replication count가 다시 올라가게 되었다!!

 

 

 

---

 

 

2.  Rack awareness와 토폴로지

1) HDFS는 데이터를 저장할 때 노드의 물리적 위치(랙)를 고려하는 랙 인식(Rack Awareness) 정책을 사용합니다.

 

2) 즉, Replication Copy들이 각각 다른 Rack에 위치하도록 보장하는 것이죠. -> 이것은 더 높은 Fault Tolerance로 이어지게 됩니다.

 

• 예를 들어 데이터센터 관리자가 실수로 Rack 한 판에 커피를 쏟았습니다. (....)
• 이때 모든 데이터가 동일한 Rack에 있었다면, 우리는 그 데이터를 완전히 잃겠지만, 다른 Rack에도 카피가 있다면 어떻게든 복구시킬 수 있겠죠..?!

 

Rack은 이렇게 생겼습니다.

 

 

3) 다만 3 Copy 일 때 3개를 3개의 Rack에 다 나누어서 저장하도록........ 까지는 하지 않습니다!

 

• 왜냐면, 네트워크 대역폭 사용량을 고려했을 때 비효율적이기 때문이죠...
• 그러면?
  • COPY1, COPY2는 같은 랙의 다른 노드에
  • COPY3은 다른 랙에 분산 저장

 

4) Rack awareness는 비활성화가 기본값입니다 ^^; 설정하지 않았다면 모든 데이터 노드가 하나의 랙에 있는 것처럼 취급됩니다.

 

 

 

---

 

 

3. HDFS의 데이터 복제

 

1) HDFS는 데이터를 파일과 디렉토리라는 형태로 구분합니다.

 

2) 우리가 HDFS 데이터에 접근하려면, FS shell command라는 Hadoop 인터페이스 언어를 사용해야 합니다.

 

• 예) hdfs dfs -ls /user/hadoop 
• 예) hdfs dfs -mkdir /user/hadoop

 

3) HDFS의 블록 크기는 꽤나 큽니다. (default 128MB) .........왜일까요?!

• 디스크에서 데이터를 찾는 시간 = 탐색 시간 감소
• 네임노드가 관리하는 메타데이터 볼륨 감소
• 클라이언트와 네임노드의 통신 감소 (주로 통신은 블록의 위치조회를 위해서 하니까)

 

 

 

 

4) 데이터노드의 데이터는 어디에 저장됩니까?

• 데이터가 저장되는 로컬 파일시스템 저장 경로
  • hdfs-site.xml의 dfs.data.dir에 설정한 곳에 저장됩니다!

 

---

 

 

4. 클라이언트가 HDFS에서 데이터를 읽을 때

 

그림 출처: https://juneyr.dev/2018-10-31/hadoop

 

 

1) 클라이언트: 네임노드에게서 처음 블록 몇 개의 위치를 받음

 

2) 클라이언트: 체크썸 확인 후 읽음

 

3) 클라이언트: 네임노드에게서 다음 데이터 블록들의 위치를 받음 (1으로 돌아가 반복)

 

 

---

 

 

 

네임노드를 통해 '블록'이 전달되는 것이 아닙니다! '블록의 위치'가 전달되는 것이죠!

 

---

 

 

 

 

 

5. 클라이언트가 HDFS에 데이터를 쓸 때

그림 출처: https://juneyr.dev/2018-10-31/hadoop

 

 

1) 네임노드는 클라이언트의 권한을 확인한다

 

2) 네임노드는 파일의 메타데이터를 자기에게 기록한다

 

3) 네임노드는 블록&데이터노드 정보를 클라이언트에게 보내준다

 

4) 클라이언트가 블록 쓰기 작업을 시작한다...

• 클라이언트는 1번 블록을 데이터노드 1에 쓴다 -> 클라이언트 ACK
• 데이터노드 1은 1번 블록을 데이터노드 2에 전달한다 (비동기) -> 블록 리포트
• 데이터노드 2는 1번 블록을 데이터노드 3에 전달한다 (비동기) -> 블록 리포트
• replica3 체계 완성!

 

5) ACK 패킷이 클라이언트에게 전달되면... 클라이언트는 2번 블록을 쓰기 시작한다.

 

7) 네임노드는 1번 블록에 대해 editlog transaction을 커밋한다

 

8) 블록 N개가 다 쓰이면 클라이언트는 이제 네임노드에 파일 쓰기 완료를 알린다

 

 

---

 

 

 

 

replicaNum이 3이라고 해서,

클라이언트가 블록정보를 3번 올리는 것이 아닙니다!

클라이언트는 1번만 업로드를 하고,

데이터노드들이 자기들끼리 짝짜꿍 카피를 하는 것이죠...

 

 

---

 

 

6. HDFS 복구 프로세스

 

1) HDFS는 데이터 무결성을 보장하기 위해 각 블록에 고유의 식별자를 할당한다

  =====> Generation Stamp <=====

• 모든 블록은 GS를 갖고 있다!
• 데이터노드는 클러스터에 새로 조인할 때 GS를 이용하여 변경 데이터를 찾는다

 

 

---

 

 

 

2) 사용권 복구 (Lease Recovery)

• HDFS에서는 파일이 기본적으로 읽기 전용이다. 그래서 클라이언트들은 보통 파일에 접근하거나 수정할 수 없다.

 

• 클라이언트는 데이터를 HDFS에 기록할 때 해당 파일에 대해 락을 걸 수 있다!
  • 이 락이 유지되는 동안은 특정 클라이언트만이 파일을 수정할 수 있다.
  • 락은 일정 시간 동안 유지되는데, 클라이언트는 주기적으로 락 시간을 갱신해야 한다.

 

• SOFT LIMIT == 1분
  
  • 1분 동안은 특정 클라이언트만이 수정할 수 있다
  • 소프트 리밋이 갱신되지 않으면 1분 후에 다른 클라이언트도 락을 소유할 수 있다.

 

• HARD LIMIT == 1시간
  • 파일 쓰기 작업에서 클라이언트가 응답하지 않으면 1시간 후 네임노드가 강제로 사용권을 회수한다.

 

• HDFS는 사용권 복구를 통해 파일이 무기한 잠기거나, 리소스가 낭비되는 상황을 방지한다

 

 

---

 

 

3) 블록 리커버리 (Block Recovery)

• 블록 리커버리는 사용권 복구가 일어난 이후, 파일의 마지막 블록이 완료상태가 아니라면 발생한다.
• 블록의 replication factor보다 복제본이 적어질 때에도 발생할 수 있다.

 

---

 

 

7. HDFS의 중앙집중적 캐시 관리

1) 네임노드는 자주 접근하는 파일에 대해서는, 데이터노드에 블록 캐시 명령을 내릴 수 있다.

• 디스크에서 읽지 말고 메모리에서 읽으라는 것이지!

 

2) 수행 흐름

• 클라이언트: hdfs cacheadmin 커맨드를 네임노드에 보낸다
• 네임노드: 그 블록을 가지고 있는 데이터노드에 캐시 명령을 보낸다
• 데이터노드: 블록을 캐시 한 후 네임노드에 캐시 결과를 보낸다
• application scheduler: 네임노드로부터 캐시 정보를 받아서, 지역화를 고려해 태스크 스케줄을 수행한다.

 

 

Application Scheduler는 YARN, Spark, MapReduce 같은 분산 처리 엔진에서 태스크 스케줄링을 담당하는 컴포넌트입니다. 스케줄러는 태스크를 어떤 노드에서 실행할지 결정하며, HDFS의 캐시 정보를 활용하여 태스크를 최적의 위치에 배치합니다.

 

---

 

 

 

8. 하둡 스토리지 구성

 

핵심 아이디어는, 좋은 컴퓨팅 파워를 갖고 있는 노드에, 자주 사용되는 "Hot data"를 저장하자는 것이다!

이렇게 구성해 볼 수 있겠다.

 

• Hot storage: 3개 다 디스크로 구성
• Warm storage: 1개는 디스크, 2개의 복제본은 아카이브로 구성
• Cold: 3개 다 아카이브로 구성

 

 

hdfs dfsadmin -getStoragePolicy $path로 현재 스토리지 정책을 확인해 보자!

 

(근데 보통은... Hot storage로 구성하겠죠...?!)

 

 

 

 

---

이 포스팅은 2024년 10월 ~ 12월에 공부한 도서인 빅데이터 전문가의 하둡관리 8장을 공부한 후 작성하였습니다.

 

 

 

 

그림 출처: https://juneyr.dev/2018-10-31/hadoop