- MapReduce Job 실행 상세

 

  • ResourceManager(RM), NodeManager(NM), Application Master(AM)

 

 

 

  • 제출
    • 1단계
      • Job 제출하면 waitForCompletion() 메서드가 1초에 번씩 변경 내역이 있으면 콘솔로 보여줌
    • 2단계
      • RM 새로운 애플리케이션 ID 요청
    • 3단계
      • Job 실행에 필요한 JAR 파일, 환경 설정 파일, 계산된 입력 스플릿 등의 Job 리소스를 공유 파일시스템에 있는 해당 Job ID 이름의 디렉터리에 복사
    • 4단계
      • RM에게 Job 제출
  • 초기화
    • 5a, 5b 단계
      • 스케줄러는 컨테이너를 하나 할당하고, RM AM 프로세스를 시작
    • 6단계
      • AM 실행하고, 이후 Task로부터 진행 종료 보고를 수신
    • 7단계
      • Client 계산한 입력 스플릿 정보를 공유 파일시스템에서 읽어옴
  • 태스크 할당
    • 8단계
      • AM RM에게 모든 Task 컨테이너를 요청
      • Map Task 요청이 Reduce Task 요청보다 우선순위가 높음
      • (Slow Start) 전체 Map Task 5%(기본값) 완료되기 전까지 Reduce Task 요청은 처리되지 않음
  • 태스크 실행
    • 9a, 9b 단계
      • RM 할당받은 컨테이너를 시작함
    • 10단계
      • Job 환경 설정, JAR 파일, 분산 캐시 필요한 리소스를 로컬로 가져옴
    • 11단계
      • Map Reduce Task 실제 실행
      • YarnChild 별도 JVM에서 실행되어 강제 종료되어도 NM 영향을 받지 않음

 

- 진행 상황과 상태 갱신

 

  • 자식 프로세스는 진행 상황과 상태 정보를 집계하여 3초마다 인터페이스를 통해 AM에게 보고
  • 상태 정보
    • Job 개별 Task 실행중, 성공적으로 완료됨, 실패와 같은 Job 등의 정보
  • 진행 상황
    • 처리한 입력 데이터의 비율

 

- 완료

 

  • 마지막 Task 완료되면 AM Job 상태를 성공으로 변경
  • waitForCompletion() 메서드가 반환되고, Job 통계와 카운터가 콘솔에 출력
  • mapreduce.job.endnotification.url 속성을 통해 HTTP Job 통지(콜백) 설정할 있음

 

- 실패

 

  • 태스크 실패
    • (보통 10(기본값) 동안 진행 상황 갱신을 받지 못함)이나 예외가 발생한 경우 해당 Task 실패로 간주하고 해당 리소스를 풀어줌
      • 실행 시간이 Task 경우 MapReduce 진행 중임을 판단하도록 조치(레코드 읽기/쓰기, 카운터 증가 ) 필요함
    • AM 해당 실패한 Task 4(기본값)까지 재시도
    • 최대 허용 Task 실패 비율 설정하여, 일부 Task 실패해도 Job 중단되지 않도록 조절할 있음
  • 노드 매니저 실패
    • NM 충돌에 의해 실패하거나 굉장히 느리면, RM 하트비트 전송을 중단하거나 드물게 전송
    • RM NM 10(기본값) 동안 하트비트 전송이 중단되면 이를 스케줄링하는 노드 풀에서 제거
    • 하나의 NM에서 4(기본값) 이상의 Task 실패하면 NM 자체가 실패하지 않더라도 NM 블랙 리스트에 등록
  • 리소스 매니저 실패
    • RM 실패 이벤트 발생시 모든 실행 중인 Job 실패 (단일 고장점)
    • 고가용성(HA) 달성하기 위해서는 개의 RM 활성-대기 설정으로 실행해야
    • 실행 중인 애플리케이션에 대한 모든 정보는 고가용 상태 저장소(Zookeeper 혹은 HDFS) 보관

 

- 셔플과 정렬

 

 

 

  • 스플릿 생성
    • 분산 처리를 위해 Job 입력이 분리되는 논리적 고정 크기 조각
    • 맵리듀스 옵션을 통해 Max/Min 값을 설정할 있음
    • Split마다 하나의 Map Task 생성
    • 가장 적절한 Split 크기는 HDFS 블록의 기본 크기인 256MB 적당
      • Split 크기가 작을수록 부하분산에 좋은 효과
      • 너무 작으면 Split 관리와 Map Task 생성을 위한 오버헤드
    • 메모리 버퍼(기본값 100MB) Map Task 수행 결과를 저장함
  • 스필
    • 버퍼의 내용이 80%(기본값) 도달할 때마다 백그라운드 스레드가 전송할 Reducer 수에 맞게 파티션을 나누고 디스크에 스필을 시작
    • 스필이 진행되는 동안에도 Map 결과는 계속해서 버퍼에 쓰임
    • 버퍼가 가득차면 Map 스필이 종료될 때까지 블록됨
  • (정렬 ) 병합
    • 파티션 백그라운드 스레드는 키를 기준으로 인메모리 정렬 수행
    • 스필 파일이 3 이상인 경우 컴바이너로 Reducer 전송할 데이터양을 줄임
    • 압축 옵션은 상황에 따라 디스크에 빨리 쓰고 디스크 공간을 절약하며, Reducer 전송할 데이터 양을 줄일 있음
  • 복사
    • 5(기본값) 스레드로 Map 출력의 복사를 병렬로 수행
    • AM 하트비트로 완료 Mapper Reducer 매핑 정보를 생성
    • Reducer Mapper 출력을 회수한 후에도 오류에 의한 실패가 발생할 있기 때문에 Job 종료 AM으로부터 삭제 요청을 받을 때까지 기다림
  • 정렬(사실상 병합)
    • 정렬(병합) 라운드 단위(Map 출력 개수/병합 계수(기본값 10)) 수행됨
    • ex) 40 -> 4(4(40/10) 병합, 10 병합, 10 병합, 10 병합) + 6 -> Reducer
      • Reducer 전달하는 최종 round에서 개수를 병합 계수로 맞추기 위한 최소한의 병합을 수행하는 것이 목적
  • 리듀스
    • 최종 라운드는 병합 대신 Reduce 함수에 곧바로 전송하여 디스크 IO 줄임

 

 

 

참조: Hadoop: The Definitive Guide

'Development > Hadoop' 카테고리의 다른 글

하둡 공부 - 맵리듀스의 튜닝과 고급 기능  (0) 2019.01.24
하둡 공부 - MapReduce 실행  (0) 2019.01.24
하둡 공부 - Hadoop I/O  (0) 2019.01.24
하둡 공부 - YARN  (0) 2019.01.24
하둡 공부 - Hadoop Read & Write  (0) 2019.01.24
블로그 이미지

나뷜나뷜

,