[빅데이터]데이터 엔지니어 - 하둡 에코 시스템의 이해(요약 본)

HDFS 데이터 저장 방식

1. 애플리케이션이 HDFS 클라이언트에 파일저장 요청

2. HDFS 클라이언트가 네임노드에 사용자가 요청한 파일경로 생성 요청

3. 네임노드가 데이터노드들(파이프라인) 반환 (복제개수만큼)

4. 첫번째 데이터노드에 저장, 첫번째 데이터노드는 두번째 데이터노드로 전송, 로컬 저장 후 세번쨰로 전송... 완료 후 첫번 째 데이터노드에 완료 사실 반환

5. 데이터노드장애 시 파이프라인에서 제거 후 네임노드가 다른 데이터노드 배치

6. 첫번째 데이터노드가 클라이언트에게 저장완료 응답

7. 클라이트가 애플리케이션에 완료 응답

HDFS 데이터 읽기

1. 네임노드에게 요청한 파일의 블록 위치 정보 요청

2. 클라이언트에 가까운 순서대로 정렬하여 데이터노드 목록 반환.

3. 클라이언트는 데이터노드에 파일 조회 요청

NameNode

1. 네임노드는 HDFS 메타데이터를 메모리에서 처리하지만, 유실 방지를 위해 에디트로그(EditLog)와 파일시스템이미지(FsImage) 파일 사용.

2. 에디트로그는 HDFS 메타데이터의 모든 변화를 기록(파일 저장, 파일 삭제, 위치 변경 등의 파일 상태 변화)

3. 에디트로그는 용량 제한 없이 커질 수 있으며 네임노드의 로컬 파일 시스템에 파일로 저장

4. 파일시스템이미지(FsImage) 파일은 파일 시스템의 네임스페이스(디렉터리명, 파일명, 상태 정보)와 파일에 대한 블록 매핑 정보를 저장하는 파일(HDFS의 스냅샷)

5. FsImage도 EditLog처럼 네임노드의 로컬파일시스템에 파일로 저장

NameNode 구동 단계

1. 로컬에 저장된 FsImage, EditLog 조회

2. EditLog 파일 내용 토대로 메모리에 올라간 FsImage 갱신

3. 갱신된 FsImage 로컬에 있는 FsImage 파일에 적용

4. EditLog 파일 초기화

SecondaryNameNode (체크포인팅 서버) (feat. 보조네임노드는 백업서버가 아니다!)

1. EditLog 파일이 제한없이 커질 시 FsImage 갱신할 수 없을 정도로 메모리에 로딩못하는 사태가 일어날 수 있어서...

2. 주기적으로 네임노드의 FsImage 갱신하는 역할(Checkpoint)

SecondaryNameNode 역할 구동 단계

0. Default로 1시간에 한 번씩 (fs.checkpoint.period) 구동

1. 네임노드에게 EditLog 파일 롤링 요청 (파일 롤링은 현재 로그파일이름을 변경하고, 원래 이름으로 새 로그 파일 만드는 것)

2. 그러면 네임노드는 파일 롤링 실행

3. Secondary Namenode에서 네임노드의 롤링된 기존 EditLog와 FsImage 다운로드 (HTTP GET)

4. 받아온 FsImage 메모리에 올리고 EditLog를 적용하여 새로운 FsImage 생성(체크포인트용 파일시스템이미지)

5. 체크포인트용 파일시스템이미지를 NameNode에 전송(HTTP POST)

6. 네임노드는 기존 FsImage 파일을 체크포인트용 파일시스템이미지파일로 변경, EditLog도 새로 생성된 것으로 변경

7. 메모리에 올라간 FsImage 최신 내역으로 갱신

\-\- 고찰: 보조네임노드가 동작하지않을 떄 네임노드 동작에 상관없지만\.\. EditLog가 과도하게 쌓인 경우\, 그리고 네임노드 재구동을 해야할 경우 과도하게 쌓인 EditLog를 메모리에 올리지 못하는 상황이 발생할 수 있다\.\!

HDFS HA 구성

0. HADOOP2 부터 보장하는 세팅

1. Zookeeper(QuorumPeerMain) 에서 네임서비스별 active/standby namenode 상태정보 저장

2. DFSZKFailoverController: NameNode 모니터링, active 죽으면 standby를 (JournalNode의 Editlog모두 읽은 후) active로 전환 Zookeeper 정보 갱신

3. JournalNode: active NameNode의 namespace 수정될떄 발생한s editlog 저장. (최소 3대 앙상블)

4. Active Namenode: editlog를 JournalNode에 기록

5. Standby Namenode: JournalNode에서 editlog를 읽어와 fsimage 갱신

6. DataNode: active/standby NameNode 모두에 Block정보와 HeartBeat 보냄

잡트래커

- 하둡1 네임노드에서 실행

- 맵리듀스는 잡이라는 하나의 작업 단위로 관리됨

- 하둡클러스터에 등록된 전체 잡의 스케쥴링 관리 및 모니터링

-- 새로운 잡 요청 시 잡트래커가 잡을 처리하기 위해 몇 개의 맵과 리듀스를 실행할지 계산

-- 어떤 태스크트래커에서 실행할지 결정

-- 잡 할당

- 전체 클러스터에서 하나의 잡트래커 실행

태스크트래커

- 하둡1 데이터노드에서 실행

- 잡 트래커의 작업 수행 요청을 받아 맵리듀스 프로그램 실행

- 잡트래커가 요청한 매퍼와 리듀서 갯수 만큼 맵, 리듀스 태스크 생성

- 새로운 JVM 구동해 맵, 리듀스 태스크 실행

-- 이 때, JVM은 재사용할 수 있게 설정 가능. 데이터노드가 하나라도 여러 개의 JVM 실행해서 병렬처리 가능

YARN (MRv2)

- 기존 잡 트래커의 기능을 리소스매니저와 애플리케이션 마스터로 분리.

리소스매니저

- 애플리케이션에 할당해야 하는 클러스터의 리소스를 관리,

- YARN의 마스터 역할

- 전체 클러스터의 리소스(CPU, 디스크, 네트워크) 관리

- 내부적으로 스케줄러와 애플리케이션 매니저 실행

- 스케줄러: 노드매니저와 통신하며 필요한 리소스에 대한 스케줄링 수행. (FIFO, Capacity, Pair) 확인

- 애플리케이션 매니저: 애플리케이션 마스터의 상태 관리(실행, 모니터링, 재실행), 스케줄러에게 애플리케이션 마스터 실행 시키기 위한 노드매니저 할당 받음.

- 할당 받은 노드매니저에게 애플리케이션 마스터 수행 요청

- 노드매니저는 애플리케이션 마스터 실행

- 애플리케이션 마스터는 리소스매니저에게 컨테이너 실행 요청할 노드매니저 목록 할당 받음 (and 요청)

- 노드매니저는 컨테이너 실행. 애플리케이션 종료되면 컨테이너와 애플리케이션 마스터 종료

\- 노드매니저: 데이터노드 당 1개씩\, 컨테이너 리소스 사용량 모니터링\, 관련 정보를 리소스매니저에게 알림\.

- 애플리케이션 마스터: YARN에서 실행되는 하나의 태스크를 관리(애플리케이션 당 1개)

하둡에코시스템

HDFS 발란서 : 지나치게 자주 사용되는 데이터노드의 블럭을 덜 사용되는 데이터노드로 옮겨줌.(백그라운드로 실행)