Tag Archives: yarn

YARN 관련 자료 정리 2

Apache Hadoop YARN – Concepts & Applications

http://hortonworks.com/blog/apache-hadoop-yarn-concepts-and-applications/
YARN의 분산 어플리케이션을 관리하기 위한 시스템

MRArch

ResourceManager

ResourceManger는 기본적으로 순수한 스케쥴러에 해당한다

시스템의 가용자원을 자원 경쟁중인 어플리케이션에 할당을 중재하는 역할을 한다

cluster utilization을 최적화(항시 모든 자원을 활용할 수 있도록 함)

pluggable scheduler를 가지므로, 상황에 따라 capacity 또는 fair 스케쥴러를 사용할 수 있다

ApplicationMaster

기존의 MRv1과 YARN 사이에는

  • JobTracker – RessourceManager
  • TaskTracker – NodeManager

와 같이 비슷한 개념이 있다. 반면 ApplicationMaster는 YARN에서 새롭게 등장한 개념이다
정의를 따르면

“프레임워크에 종속된 라이브러리의 인스턴스로,ResourceManager로부터 자원을 협상하고NodeManager와 협력하여 컨테이너를 실행하고 컨테이너의 자원 소모를 모니터링할 책임을 갖는다”

ApplicationMaster로 인한 YARN의 특징

확장성(Scale)
기존의 자원관리자에게 있었던 많은 기능/책임을 ApplicationMaster로 이관했고, 이를 통해 시스템 전체는 좀더 극적으로 확장할 수 있다
이를 위해 ResourceManager는 오롯이 순수한 스케쥴러로 동작하도록 설계
이제 ResourceManager는 자원에 대한 fault-tolerance를 제공하지 않으며, 해당 책임은 ApplicationMaster 인스턴스가 갖는다.
어플리케이션마다 별도의 ApplicationMaster 인스턴스가 있으므로, 이제 어플리케이션을 배치방식으로 실행하던 이전의 방식과 달리 병목현상이 없다

개방성(Open)
프레임워크에 종석된 코드는 모두 ApplicationMaster에 있으므로, YARN 시스템은 좀더 범용적이 되며 MapReuce 뿐만 아니라 MPI, 그래프 처리와 같은 다양한 프레임워크를 지원할 수 있다

YARN 설계시 결정한 핵심 표인트

Move all complexity (to the extent possible) to the ApplicationMaster while providing sufficient functionality to allow application-framework authors sufficient flexibility and power.
Since it is essentially user-code, do not trust the ApplicationMaster(s) i.e. any ApplicationMaster is not a privileged service.
The YARN system (ResourceManager and NodeManager) has to protect itself from faulty or malicious ApplicationMaster(s) and resources granted to them at all costs.

자원 모델(Resource Model)

어플리케이션은 ApplicationMaster를 통해 매우 구체적인 자원 요구사항을 요청한다

  • Resource-name (hostname, rackname – we are in the process of generalizing this further to support more complex network topologies with YARN-18).
  • Memory (in MB)
  • CPU (cores, for now)
  • In future, expect us to add more resource-types such as disk/network I/O, GPUs etc.

ResourceRequest와 Container

어플리케이션이 필요한 구체적인 자원 요구사항(resource request)를 ApplicationMaster를 통해 요청한다

Scheduler가 해당 자원 요청에 대해 응답하는데, 이는 container를 승인하는 행위다. container는 ApplicationMaster가 요청한 ResourceRequest에 기술된 자원 요구사항을 만족시킨다.

YARN 관련 자료 정리 1

YARN에 대해서 이것저것 살펴 보고 있는데, 아직 잘 감이 안잡힌다. 일단 인터넷 자료를 찾아봐야할 것 같다. YARN 관련 자료를 여기에 정리한다.

From Apache Documentation

[hr]

Apache Hadoop NextGen MapReduce (YARN)

http://hadoop.apache.org/docs/current/hadoop-yarn/hadoop-yarn-site/YARN.html
기존의 JobTracker는 아래 2가지 기능을 모두 가지고 있었으나, MRv2에서는 위의 2가지 기능을 각각의 데몬으로 분리함

  • 자원 관리(resource management)
  • 잡 스케쥴링과 모니터링(job scheduling and monitoring)

yarn_architecture

  • ResourceManager(RM)
    시스템의 어플리케이션 전체에 대해 자원을 중재하는 전역 최고 관리자
    두개의 메인 컴포넌트로 구성: 스케쥴러(Scheduler), ApplicationManager
  • ApplicationMaster(AM)
    어플리케이션당 하나
    프레임워크에 종속된 라이브러리로, RM로부터 자원을 할당받아 NM과 협조하여 태스크를 실행하고 모니터링한다
  • NodeManager(NM)
    슬레이브 노드당 하나

From Hotonworks

[hr]

Hadoop Yarn

http://hortonworks.com/hadoop/yarn/
Hadoop 2.0과 YARN을 사용하면, 스트리밍, 인터랙티브(대화방식?) 등등을 사용할 수 있다.

YARN

YARN 동작방식

기존의 JobTracker/TaskTracker 구성을 아래와 같이 역할에 따라 분리

  • 전역 ResourceManager
  • 하나의 어플리케이션당 ApplicationMaster
  • 하나의 슬레이브 노드당 NodeManager
  • 하나의 어플리케이션당 Container(NodeManager 상에서 실행되는)

ResourceManager

ultimate authority that arbitrates resources among all the applications in the system.

the ResourceManager has a scheduler
NodeManager

the per-machine slave

responsible for launching the applications’ containers, monitoring their resource usage (cpu, memory, disk, network) and reporting the same to the ResourceManager
ApplicationMaster

the per-application ApplicationMaster

a framework-specific entity and is tasked with negotiating resources from the ResourceManager and working with the NodeManager(s) to execute and monitor the component tasks

has the responsibility of negotiating appropriate resource containers from the scheduler, tracking their status, and monitoring their progress

From the system perspective, the ApplicationMaster runs as a normal container
Scheduler

responsible for allocating resources to the various running applications, according to constraints such as queue capacities, user-limits etc

performs its scheduling function based on the resource requirements of the applications
컨테이너(Container)????

 

Introducing Apache Hadoop YARN

Introducing Apache Hadoop YARN

 

Apache Hadoop YARN – Background & Overview

Apache Hadoop YARN – Background and an Overview

MapReduce 모델

2단계를 거친다

  • map phase
    데이터를 분할한다
  • reduce phase
    map 출력 데이터를 입력으로 받아 aggregation을 수행한다

MapReduce 모델의 핵심은 “데이터 이동이 없다(lack of data motion)”이다. 즉 데이터가 있는 곳에 프로그램을 보내며, 프로그램이 있는 곳으로 데이터를 보내지는 않는다. 이를 통해 네트워크 I/O를 최소화하고, 로컬 머신의 디스크 I/O는 최대로 활용한다.

아파치 하둡 맵리듀스 프로젝트는 아래의 3가지로 나누어 생각해볼 수 있다

  • 클라이언트 맵리듀스 API
    맵리듀스 어플리케이션을 만들때 사용
  • 맵리듀스 프레임워크
    맵 단계, 정렬 단계, 셔플 단계, 병합 단계, 리듀스 단계와 같은 다양한 단계들에 대한 런타임 구현체
  • 맵리듀스 시스템
    맵리듀스 어플리케이션을 실행하고 클러스터 자원을 관리하며, job을 동시에 실행하기 위해 스케쥴링을 하는데 필요한 백엔드 인프라

현재 맵리듀스 시스템은 잡트래커와 태스크 트래커로 구성된다.

MRArch

  • 잡트래커
    자원 관리(태스크 트래커 관리)
    자원 소비/가용량 트래킹
    job 라이프 사이클 관리(job의 각 태스크 스케쥴링, job 진행상황 관리, 태스크에 대해 fault-tolerance 보장)
  • 태스크트래커
    잡트래커의 지시에 따라 태스크를 실행/중단
    주기적으로 태스크의 상태를 잡트래커로 전송

맵리듀스 모델 이외의 프로그래밍 모델에 대한 지원이 필요
맵리듀스 모델은 근본적으로 배치 지향적이다.
하지만 그래프 프로세싱, iterative 모델링, 실시간 처리, 준실시간 처리 모델에 대한 필요성이 높아짐

확장성(scalability)을 개선해야 한다

  • customer agility 문제?
    cluster utilization 문제?
    각 노드는 맵 슬롯과 리듀스 슬롯이 할당되며, 서로 대체가 불가능
    맵 슬롯이 꽉 차 있지만 리듀스 슬롯은 텅 빈 상태가 발생할 수 있으며 이를 cluster utilization 문제가 발생했다고 함
    high utilization을 유지하려면 이 문제를 해결해야 함

Apache Hadoop YARN
YARN 기본 개념은 잡트래커의 아래 2개지 역할을 별도의 데몬으로 분리하는 것

  • 자원 관리
    전역 ResourceManager
  • job 스케쥴링/모니터링
    ApplicationMaster(AM) per application

YARN에서는 ResourceManager와 노드별 NodeManager(NM)이 시스템을 구성한다

YARN 시스템에서는 기존의 맵리듀스 프레임워크를 거의 그대로 보존 -> 기존의 맵리듀스 어플리케이션과의 하위 호완성을 보장한다