Mapreduce & YARN

실무에 사용한 데이터 엔지니어링 스킬에 대한 정리내용입니다.   

개인적인 기록을 위해 작성하였습니다.

https://github.com/mjs1995/muse-data-engineer/blob/main/doc/Batch%20Processing/hadoop_map_yarn.md

GitHub - mjs1995/muse-data-engineer: 데이터 엔지니어로 성장하기

---

Mapreduce

https://www.datadoghq.com/blog/hadoop-architecture-overview/

• MapReduce는 여러 컴퓨터에 걸쳐 분산된 방식으로 대규모 데이터 세트를 처리하기 위해 맞춤 제작된 프레임워크
• 맵리듀스 프로그래밍은 큰 연산 작업을 다수의 값싼 서버로 구성된 클러스터에 고르게 나누어 처리하는 프로그래밍 모델로, 비용효율성과 수평확장성을 제공합니다. 이 연산 모델 아래에는 하둡 분산 파일시스템(HDFS, Hadoop Distributed Filesystem)이라는 분산 파일 시스템이 존재합니다.
• 데이터 컬렉션 각 요스를 한 형태에서 다른 형태로 맵핑(맵 단계)하고 이 맵핑된 데이터 컬렉션을 하나의 값 또는 더 작은 컬렉션으로 줄이는 (리듀스 단계) 데이터 연산에 기반을 둔 계산 패러다임으로 구글에서 개발했습니다. 맵리듀스는 맵과 리듀스 단계를 태스크로 나누고 클러스터에 이 태스크를 분산시킴으로써 수평 확장된 계산이 가능하도록 설계되었습니다.
• MapReduce 작업의 핵심은 3가지 작업으로 줄일 수 있습니다. 입력 데이터 세트를 <key, value> 쌍의 컬렉션으로 매핑하고, 결과 데이터를 섞고 (데이터를 리듀서로 전송) 다음으로 모든 쌍을 축소합니다.
•  

  

  https://stackoverflow.com/questions/22141631/what-is-the-purpose-of-shuffling-and-sorting-phase-in-the-reducer-in-map-reduce

  • Split
    • 맵리듀스는 매우 큰 입력 파일을 스플릿(split)으로 분할합니다. 하둡은 각각의 스플릿을 개별 맵 프로세스에게 보냅니다.
    • 하둡은 맵리듀스 잡의 입력을 입력 스플릿(input split) 또는 단순히 스플릿이라고 부르는 고정 크기 조각으로 분리합니다. 각 스플릿마다 하나의 맵 태스크를 생성하고 스플릿의 각 레코드를 사용자 정의 맵 함수로 처리합니다.
  • 맵(Map)
    • 맵리듀스의 맵핑 단계는 키-값 쌍의 집합의 입력을 새로운 키-값 쌍 집합으로 변환합니다. 각 키-값 쌍 입력에 대해 키-값 쌍이 0개 이상 출력될 수 있습니다.
    • 한 줄의 단어를 키-값 쌍으로 출력합니다.
  • 컴바이너(Combiner) 함수
    • 하둡은 맵의 결과를 처리하는 컴바이너 함수(컴바이너 함수의 출력이 결국 리듀스 함수의 입력이 됨)를 허용하며 컴바이너 함수는 최적화와 관련이 있습니다.
    • 하둡은 컴바이너 함수의 호출 빈도와 상관없이 리듀스의 결과가 언제나 같도록 보장합니다.
    • 컴바이너를 사용하면 매퍼와 리듀서 사이의 셔플 단계에서 전송되는 데이터양을 줄이는 데 큰 도움이됩니다.
  • 셔플(Shuffle)
    • 같은 키를 가진 키를 모두 모아서 같은 리듀서에게 보냄.
  • 정렬(Sort)
    • 리듀서로 전달된 데이터를 키 값 기준으로 정렬
  • 리듀스(Reduce)
    • 리듀스 단계는 맵 단계에서 생성된 키-값 쌍을 처리합니다. 맵리듀스의 중요한 기능은 모든 맵 태스크에서 생성된 같은 키의 키-값 쌍을 같은 리듀스 태스크로 전송하여 적절하게 결괏값을 줄이는 것
    • 리듀서의 입력 역시 키-값 쌍으로 키는 맵퍼에서 나온 단어 중 하나이고 값은 그 단어 발생 횟수의 컬렉션입니다.
    • 모든 리듀서는 각 단어의 값 컬렉션별로 값을 모두 더하고 단어-총 발생 수 키-값 쌍을 출력해야 함
    • 리듀서 함수의 목적은 값 컬렉션을 합계, 평균과 같은 값으로 변경하거나 다른 컬렉션으로 변경하는 것. 최종 키-값 쌍은 리듀서가 내보냅니다

---

YARN

• 

  https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.1.3/bk_using-apache-hadoop/content/yarn_overview.html

• 하둡의 클러스터 자원 관리 시스템, 클러스터의 자원을 요청하고 사용하기 위해 API를 제공합니다.
• 맵리듀스, 스파크 등과 같은 분산 컴퓨팅 프레임워크는 클러스터 계산 계층(YARN)과 클러스터 저장 계층(HDFS와 HBase) 위에서 YARN 애플리케이션을 실행합니다.
• 리소스 매니저와 노드매니저 등 두 가지 유형의 장기 실행 데몬을 통해 핵심 서비스를 제공합니다.
  • 클러스터에서 유일한 리소스 매니저는 클러스터 전체 자원의 사용량을 관리합니다.
  • 모든 머신에서 실행되는 노드 매니저는 컨테이너를 구동하고 모니터링하는 역할
• 분산 데이터 처리 알고리즘에서 클러스터의 네트워크 대역폭을 효율적으로 활용하기 위해서는 지역성을 보장하는 것이 가장 중요합니다. YARN은 특정 애플리케이션이 호출한 컨테이너에 대해 지역성 제약을 규정하는 것을 허용하며 지역성 제약은 특정 노드나 랙 또는 클러스터의 다른 곳(외부 랙)에서 컨테이너를 요청할 때 사용됩니다.
• YARN과 맵리듀스 1의 차이점
  • 맵리듀스 1에는 잡의 실행과정을 제어하는 하나의 잡트래커와 하나 이상의 태스크트래커등 두 종류의 데몬이 있습니다.

  • 

    https://docs.cloudera.com/HDPDocuments/HDP2/HDP-2.1.3/bk_using-apache-hadoop/content/yarn_overview.html

    • 잡트래커
      • 여러 태스크트래커에서 실행되는 태스크를 스케줄링함으로써 시스템에서 실행되는 모든 잡을 조율합니다.
      • 맵리듀스 1에서 잡 스케줄링(태스크와 태스크트래커를 연결)과 태스크 진행 모니터링(태스크를 추적하고, 실패하거나 느린 태스크를 다시 시작하고, 전체 카운터를 유지하는 방법으로 태스크 장부(bookeeping)를 맡고 있으며, 반면 YARN은 이러한 역할을 분리된 객체인 리소스 매니저와 애플리케이션 마스터(맵리듀스 잡당 하나)를 통해 처리합니다.
      • 완료된 잡에 대한 잡 이력을 저장하는 역할을 맡고 잡트래커의 부하를 줄이기 위해 별도의 데몬인 히스토리 서버를 통해 수행될 수도 있습니다. YARN에서 이와 동일한 역할은 애플리케이션의 이력을 저장하는 타임라인 서버가 맡고 있습니다.
    • 태스크트래커
      • 태스크를 실행하고 진행 상황을 잡트래커에 전송하기 때문에 잡트래커는 각 잡의 전체적인 진행 상황을 파악할 수 있습니다.
  • 맵리듀스 1과 YARN 컴포넌트의 비교
    • 잡트래커 - 리소스 매니저, 애플리케이션 마스터, 타임라인 서버
    • 태스크트래커 - 노드 매니저
    • 슬롯 - 컨테이너
  • YARN을 사용하여 얻을 수 있는 이익
    • 확장성 : 맵 리듀스 1보다 큰 클러스터에서 실행될 수 있습니다.
    • 가용성 : 고가용성(high availability - HA)은 서비스 데몬에 문제가 발생했을 때 서비스에 필요한 작업을 다른 데몬이 이어받을 수 있도록 상태 정보를 항상 복사해 두는 방법으로 구현합니다.
    • 효율성
    • 멀티테넌시(다중 사용자) : 하둡이 맵리듀스를 뛰어넘어 다양한 분산 애플리케이션을 수용할 수 있습니다.
• YARN 스케줄링

  • 

    https://github.com/mjs1995/muse-data-engineer/blob/main/doc/Batch%20Processing/spark_yarn.md

  • 스케줄러 옵션
    • FIFO, 캐퍼시티(가용량), 페어(균등) 스케줄러를 제공합니다.
    • FIFO
      • 애플리케이션을 큐에 하나씩 넣고 제출된 순서에 따라 순차적으로 실행함(선입선출 방식), 큐에 처음으로 들어온 애플리케이션 요청을 먼저 할당하고, 이 요청을 처리한 후 큐에 있는 다음 애플리케이션 요청을 처리하는 방식으로 순차적으로 실행합니다.
      • 공유 클러스터 환경에서는 적합하지 않습니다. 대형 애플리케이션이 수행될 때는 클러스터의 모든 자원을 점유해 버릴 수 있기 때문에 다른 애플리케이션은 자기 차례가 올 때까지 계속 대기해야 하며 다른 두 스케줄러는 장시간 수행되는 잡을 계속 처리하는 동시에 작은 비정형 질의도 중간에 실행하여 적당한 시간 내에 사용자가 결과를 얻을 수 있도록 허용합니다.
    • 캐퍼시티(Capacity)
      • 작은 잡을 제출되는 즉시 분리된 전용 큐에서 처리합니다.
      • 물론 해당 큐는 잡을 위한 자원을 미리 예약해 두기 때문에 전체 클러스터의 효율성은 떨어지며 대형 잡은 FIFO 스케줄러보다 늦게 끝나게 됩니다.
      • 회사의 조직 체계에 맞게 하둡 클러스터를 공유할 수 있습니다. 각 조직은 전체 클러스터의 지정된 가용량을 미리 할당받고 각 조직은 분리된 전용 큐를 가지며 클러스터 가용량의 지정된 부분을 사용하도록 설정할 수 있습니다.
    • 페어(Fair)
      • 실행 중인 모든 잡의 자원을 동적으로 분배하기 때문에 미리 자원의 가용량을 예약할 필요가 없으며 대형 잡이 먼저 시작되면 이때는 실행 중인 잡이 하나밖에 없기 때문에 클러스터의 모든 자원을 얻을 수 있습니다.
      • 대형 잡이 실행되는 도중에 작은 잡이 추가로 시작되면 페어 스케줄러는 클러스터 자원의 절반을 이 잡에 할당합니다. 각 잡은 클러스터의 자원을 공평하게 사용할 수 있게 됩니다.
      • 실행 중인 모든 애플리케이션에 동일하게 자원을 할당합니다.

---

Reference

• https://www.oreilly.com/library/view/hadoop-the-definitive/9780596521974/
• https://www.oreilly.com/library/view/programming-hive/9781449326944/