Mapper를 호출하기전에 일반 텍스트파일을 Key Value 값으로 맞춰줘야한다. 그러기 위해서 InputFormat을 맞춰주는 전처리 작업이 필요하다. 이를위해서 MapReduce는 2가지 방법을 제공해주고있다.

TextInputFormat

입력값이 일반텍스트일때, 라인단위로 쪼갠다. Key는 파일의 라인수가되고, Values는 해당라인의 텍스트가 된다

참조 : https://hadoop.apache.org/docs/r2.7.5/api/org/apache/hadoop/mapred/TextInputFormat.html

KeyValueTextInputFormat

입력값이 일반텍스트일때,  파일을 라인단위로 쪼개는데, 특정 구분자를 기준으로 쪼갠다. 만약 해당구분자가 존재하지않는경우 value는 빈값으로 리턴한다. 

참조 : https://hadoop.apache.org/docs/r2.7.5/api/org/apache/hadoop/mapred/KeyValueTextInputFormat.html

Hadoop Version 1

JobTracker 혼자 모든 자원들을 관리한다. 그렇기 때문에 JobTracker가 죽으면 클러스터위의 모든 어플리케이션들은 죽어버린다. 그리고 클러스터에 많은 어플리케이션이 붙으면 JobTracker는 병목현상을 일으켜서 성능이 급격히 저하된다. 이러한 이슈 때문에 Yarn(Yet Another Resource Negotiator)가 Hadoop 2.0부터 탑재되었다.

Hadoop Version 2

Yarn의 기본 아이디어는 JobTracker이 감당했던 일인 자원 관리와 job Scheduling / monitoring을 서로 나누는것이다.

이를 감당하는 컴포넌트들은 ResourceManager와 ApplicationMaster(AM), NodeManager 등으로 나뉜다. 

Resource Manager 는 기본적으로 순수하게 하둡 클러스터의 전체적인 리소스 관리만을 담당하는 심플한 모듈이다.
현재 가용한 리소스들에 대한 정보를 바탕으로 이러한 리소스들을 각 애플리케이션에 일종의 정책으로서 부여하고 그 이용 현황을 파악하는 업무에 집중한다.

Application Master 는 Resource Manager 과 협상하여 하둡 클러스터에서 자기가 담당하는 어플리케이션에 필요한 리소스를 할당받으며, 또한 Node Manager 과 협의하여 자기가 담당하는 어플리케이션을 실행하고 그 결과를 주기적으로 모니터링한다. 자기가 담당하는 어플리케이션의 실행 현황을 주기적으로 Resource Manager 에게 보고한다.

Application Master 의 정확한 정의는 특정 프레임워크 (MapReduce, Storm 등 다양한 어플리케이션) 별로 잡(Job)을 실행시키기 위한 별도의 라이브러리이다. 예를 들면, 기존의 MapReduce는 MapReduce Application Master 에서, 기존의 스트리밍 처리는 스톰(Storm) Application Master 에서 각자 담당하고 책임을 지게 된다.

즉, 특정한 어플리케이션의 처리 라이브러리를 Application Master 에 올림으로써 하나의 하둡 클러스터에서 다양한 어플리케이션이 돌아 가도록 하는 것이 핵심이다. 이러한 구조의 변화에 의해서 사용자는 데이터의 속성에 맞는 다양한 어플리케이션을 처리하는 별도의 Application Master 을 만들어서 확장시킬 수 있다.

아래 그림과 같이 Hadoop 1.0에서 data processing과 cluster resource management를 모두 감당해야했던 MapReduce에서 Yarn이 cluster resource management를 감당 해줌으로써 MapReduce는 data processing만 수행하면 되게 되었다. 이로써 1.0에서 생기던 병목현상이나, 하나의 JobTracker가 감당해야했던 일들을 여러 컴포넌트들이 분담하게 됨으로써 성능을 향상시킬 수 있었다.

또한, 기존의 MR어플리케이션 프로그래머들은 data processing을 위해 기존의 코드(MRv1)를 변경하지 않아도 되며, 기존의 코드 그대로 Application Master를 통하여 실행하게되면 아래계층에서 Yarn을 통하여 데이터에 효율적으로 접근이 가능하게된다.

참고 : https://stackoverflow.com/questions/31044575/mapreduce-2-vs-yarn-applications

http://skccblog.tistory.com/1884

노드 매니저(Node Manager)의 구성 요소

노드 매너저는 노드(Node) 마다 설치되는 에이전트이며, 하둡 클러스터에 있는 각 연산 노드를 처리합니다. 여기에는 리소스 매니저와의 동기화, 컨테이너의 생명주기 관리를 감독하고, 각 컨테이너의 리소스(메모리, CPU) 사용을 모니터링하며, 노드의 건강, 로그의 관리, 다른 얀 응용 프로그램에 의해 악용될 수 있는 보조 서비스들을 감시합니다.

NodeStatusUpdater

시작 시점에 이 구성요소는 리소스 매니저에 등록을 수행하고, 노드에서 사용할 수 있는 자원에 대한 정보를 전송합니다. 그 후에 노드 마스터와 리소스 매니저간의 통신은 컨테이너의 상태에 대한 업데이트를 제공합니다. (노드에서 동작중인 새 컨테이너의 상태, 완료된 컨테이너, 기타). 또한 리소스 매니저는 이미 실행중인 컨테이너를 잠재적으로 종료하기 위해서 NodeStatusUpdater에게 신호를 줄 수 있다.

ContainerManager

ContainerManager는 노드 매니저의 핵심입니다. 노드에서 실행되는 컨테이너를 관리하는데 필요한 기능의 일부를 수행하는 하위 구성 요소로 구성됩니다.

ⓐ RPC server

컨테이너 매니저(ContainerManager)는 애플리케이션 마스터(Application Master)로부터 새로운 컨테이너를 시작하거나 실행중인 컨테이너를 정지하도록 요청을 받습니다. 컨테이너 매니저(ContainerManager)는 아래에서 설명할 ‘ContainerTokenSecretManager’와 작업하여 모든 요청을 인증합니다. 이 노드에서 실행중인 컨테이너에서 수행되는 모든 작업은 보안 툴에 의해서 후 처리될수 있도록 감사 로그(audit-log)에 기록됩니다.

ⓑ ResourceLoalizationService

컨테이너가 필요한 다양한 파일 리소스를 안전하게 다운로드하고 관리합니다. 이 구성 요소는 가능한 모든 디스크에 파일을 분산하도록 노력합니다. 또한 다운로드 받은 파일들의 접근권한과 적절한 사용량을 제한합니다.

ⓒ ContainersLauncher

컨테이너를 가능한 빠르게 준비하고 시작하기 위해서 스레드 풀을 유지합니다. 또한 리소스 매니저나 애플리케이션 마스터에서 보내진 요청이 있다면 컨테이너의 프로세스들을 정리합니다.

ⓓ AuxServices

노드 매니저는 보조 서비스를 구성하여 노드 매니저의 기능을 확장하기 위한 프레임 워크를 제공합니다. 이 기능은 특정한 프레임 워크들이 필요로 하는 노드 별 커스텀 서비스 사용을 허가하면서 여전히 노드 매니저의 다른 부분으로부터 분리합니다. 이 서비스는 노드 매니저가 시작하기 전에 설정되어야 합니다. 보조 서비스들은 노드에서 응용 프로그램의 첫번째 컨테이너가 시작될때와 응용 프로그램이 완료된 것으로 간주될 때 통지 됩니다.

ⓔ ContainersMonitor

컨테이너가 시작되면 이 구성 요소가 컨테이너가 실행되는 동안의 자원 활용에 대한 모니터링을 시작합니다. 메모리 같은 자원의 공정한 공유와 격리를 강화하기 위해서, 각 컨테이너는 리소스 매니저에게 이러한 자원의 일부를 할당 받습니다. ContainersMonitor는 각 연속적인 컨테이너의 사용을 모니터링하고, 컨테이너가 할당을 초과할 경우, 컨테이너를 종료시키기 위해 신호를 보냅니다. 이것은 동일한 노드에서 실행중인 정상 컨테이너들에게 영향을 미치는 모든 폭주 컨테이너를 방지하기 위한 것입니다.

ⓕ LogHandler

컨테이너의 로그들을 로컬 디스크에 유지하거나 압축하여 파일 시스템에 업로드할 수 있도록 설정할 수 있는 탈착 가능한 구성 요소입니다.

ContainerExecutor

컨테이너가 필요로 하는 파일 및 디렉토리를 안전하게 배치시키기 위해서 그리고 안전한 방법으로 컨테이너에 상응하는 프로세스들을 시작하거나 정리하기 위해서 기본 운영 체제와 상호 작용합니다.

NodeHealthCheckerService

이 구성 요소는 자주 구성된 스크립트를 주기적으로 실행하여 노드의 상태를 검사하는 기능을 제공합니다. 또한 디스크에 가끔 임시 파일을 생성하여 디스크의 상태를 모니터링합니다. 시스템의 모든 상태 변화를 차례로 리소스 매니저로 전송하는 NodeStatusUpdater로 통보 됩니다.

Security

ⓐ ApplicationACLsManager

노드 매니저는 권한이 부여된 사용자만 접근할 수 있도록 웹UI에 컨테이너 로그 표시와 같은 API를 직접 대면하는 사용자가 필요합니다. 이 구성 요소는 응용 프로그램 당 ACL 목록을 유지하고 요청을 수신 할 때마다 이를 적용합니다.

ⓑ ContainerTokenSeretManager

모든 수신 작업이 제대로 리소스 매니저에 의해서 승인되는 것을 보장하기 위해서 다양한 도착 요청을 확인합니다.

WebServer

응용 프로그램 주어진 시점에서 실행중인 컨테이너들과 노드 건강 정보 및 컨테이너에 의해서 생성된 로그들의 목록을 보여준다.

[ 노드 매니저 ]

출처 : http://ryufree.tistory.com/m/230?category=252660

① 리소스 매니저와 클라이언트간의 통신하는 구성요소들

ClientServie

리소스 매니저의 클라이언트 인터페이스입니다. 이 컴포넌트는 애플리케이션 제출, 애플리케이션 종료, 큐 정보 획득, 클러스터 상태 등과 같은 작업을 포함하여 클라이언트에서 리소스 매니저로 오는 모든 RPC 인터페이스를 관리합니다.

AdminService

관리자의 요청(Admin request)이 일반 사용자의 요청 때문에 실행되지 못하는 경우가 없도록 작업 명령에 더 높은 우선 순위(Higher priority)를 부여합니다. 노드-목록(node-list)을 새로 고치거나, 큐의 설정(Queues’ onfiguration) 등과 같은 관리자 작업(Admin Operation)은 별도의 인터페이스를 통하여 제공합니다.

② 리소스 매니저와 노드들을 연결하는 컴포넌트들

ResourceTrakerService

이 컴포넌트는 모든 노드에서 오는 RPC에 응답을 합니다. 새로운 노드를 등록하거나, 유효하지 않거나 사용이 중지된 노드로부터의 연결을 거부하거나, 노드의 하트비트(Heartbeat) 획득해서 얀 스케쥴러(YarnSheduler)에게 전달합니다. 리소스 트랙커 서비스(ResoureTrakerServie)는 NMLivelinessMonitor 와 NodesListManager와 긴말하게 협력합니다.

NMLivelinessMonitor

정상적으로 동작하는 노드들을 추적하고, 특히, 죽은 노드를 내리기 위해서 이 구성요소는 각 노드의 마지막 하트비트(Heartbeat) 시간을 추적합니다. 노드들이 설정된 간격(기본 10분) 안에 하트비트를 보내지 않으면 죽은것으로 간주하고, 리소스 매니저가 죽은 노드의 사용을 만료시킵니다. 만료된 노드에서 현재 수행중인 모든 컨테이너는 죽은것으로 표시되며, 그 노드에게는 새로운 컨테이너를 배정하지 않습니다.

NodesListManager

유효하거나 제외된 노드들의 집합입니다. yarn.resourcemanager.nodes.inlude-path와 yarn.resouremanager.nodes.exclude-path를 통해 지정된 호스트 설정 파일을 읽고, 그 파일를 기반으로 노드의 초기 목록을 생성을 담당합니다. 또한 시간이 진행됨에 따라 폐기하는 노드를 추적합니다.

③ 응용 프로그램별 ApplicationMasters와 통신하는 구성요소

AppliationMasterServie

모든 ApplicationMasters와의 RPC에 응답하는 구성 요소입니다. 그것은 새로운 ApplicationMasters의 등록과 종료되는ApplicationMasters에서의 종료/해제 요청, 동작중인 모든 ApplicationMasters에서의 컨테이너 할당/해제 요청을 받아 YarnSheduler로 전송하는 역할을 담당합니다. 이 요소는 아래에 설명된 AMLivelinessMonitor와 밀접하게 연관되어 있습니다.

AMLivelinessMonitor

살아 있는 ApplicationMasters의 리스트와 정지/응답하지 않는 ApplicationMasters의 리스트에 대한 관리를 돕기 위해서, 이 구성 요소는 각 ApplicationMasters의 추적과 마지막 하트비트(Heartbeat) 시간을 유지합니다. 미리 정의된 간격(기본 10분) 내에 하트비트를 보내지 않는 ApplicationMasters는 정지한 것으로 여기고, ResourceManager에 의해서 만료됩니다. 만료된 ApplicationMasters에서 현재 동작하거나/할당된 모든 컨테이너는 죽은(dead) 것으로 표시됩니다. ResoureManager은 동일한 ApplicationMasters을 새로운 컨테이너에 동작시키기 위해서 스케쥴합니다. 이러한 동작은 최대 4번 시도될 수 있습니다.

④ ResoureManager의 핵심 – 스케쥴러와 관련된 구성 요소들

ApplicationsManager

제출된 응용프로그램의 컬렉션(Colletion, 집합)을 유지 관리할 책임이 있습니다. 또한 웹 UI나 응용 프로그램의 명령행을 통해서 사용자가 요청할 수 있도록 응용 프로그램의 캐시를 유지합니다.

ApplicationACLsManager

사용자가 클라이언트(Client) APIs와 관리 요청(Admin requests) APIs를 사용하려면 권한이 부여된 사용자만 접근할 수 있는 문(Gate)이 필요합니다. 이 구성요소는 응용 프로그램 당 ACL(Access-Control-List)의 목록을 유지하고, 응용 프로그램의 상태를 보거나 응용 프로그램을 중단과 같은 요청을 받을 때마다 권한을 적용합니다.  

ApplicationMasterLauncher

몇가지 이유로 인하여 종료된 이전 Application Master의 시도들과 새로 제출된 응용 프로그램의Application Master를 개시하기 위한 스레드 풀(Thread-pool)를 관리합니다. 또한 응용 프로그램이 정상적으로 또는 강제적으로 종료되었을 경우에 Application Master를 마무리 할 책임이 있습니다.

YarnScheduler

스케쥴러는 용량(Capacity), 큐(Queue) 등의 제약사항에 따라서 다양하게 실행되는 응용 프로그램에게 자원(Resource)을 할당하는 책임이 있습니다. 또한 메모리, CPU, 디스크, 네트워크 등과 같은 응용 프로그램의 자원 요구 사항을 기반으로 스케쥴링 기능을 수행합니다. 스케쥴러 기능은 현재 메모리만 제공하고 있으며, CPU에 대한 지원도 곧 완료될 예정입니다.

ContainerAllocationExpirer

이 구성요소는 모든 할당된 컨테이너들이 Application Master들을 통해서 사용되고 있으며, 이후에 컨테이너가 해당되는 노드 매니저에서 실행되고 있는지 보장할 책임이 있습니다. Application Master들은 신뢰할 수 없는 사용자 코드를 실행하고, 잠재적으로 그들을 사용하지 않고 할당을 유지할 수 있으며, 이로 인하여 클러스터를 충분히 활용하지 못하는 원인이 될수 있습니다.

이러한 문제를 해결하기 위해서, ontainerAllocationExpirer는 해당하는 노드 매너저에서 사용되지 않는 할당된 컨테이너들의 목록을 유지합니다. 어떠한 컨테이너이든 해당하는 노드 매니저가 정해진 시간(기본 10분) 안에 Resource Manager에게 컨테이너의 동작 상태를 보고하지 않으면 컨테이너가 정지했다고 간주하고 Resource Manager에 의해서 만료됩니다.

⑤ TokenSecretManagers (for security)

리소스 매니저는 토큰(Token)을 관리하고, 다양한 RPC 인터페이스에 대한 요청을 인증/권한부여 하는데 사용되는 비밀키(Secret-key)들을 청구하는 SecretManager의 콜렉션을 가지고 있습니다. 얀 보안에 대한 미래의 글에는 토큰, 비밀키, Secret-Manager들에 대한 상세한 설명을 포함할 것이며, 지금은 아래에 간략하게 요약만 합니다.

ApplicationTokenSeretManager

리소스 매니저 스케쥴링 요청을 보내는 임의의 프로세스를 피하기 위해서, 리소스 매니저는 애플리케이션 토큰(ApplicationTokens)을 사용합니다. 이 구성요소는 응용 프로그램이 종료될 때까지 메모리에 지역적으로 토큰을 저장하고, 유효한 Application Master 처리에서 발생하는 요청들을 인증하는데 사용됩니다.

ContainerTokenSecretManager

컨테이너 토큰(ContainerToken)은 리소스 매니저가 특정 노드에 존재하는 컨테이너를 관리하고 있는 Application Master에게 발급한 특별한 토큰입니다. ContainerTokenSecretManager는 ContainerToken을 위한 SecretManager입니다.

ContainerToken은 컨테이너가 할당된 해당 노드 매니저와의 연결을 생성하는 Application Master에 의해서 사용됩니다. 이 구성요소는 리소스 매니저 특정이고, 기본 마스터와 비밀키를 추적하고 가끔 키들을 롤백(Roll)합니다.

RMDelegationTokenSecretManager

ResourcManager specific delegation-token secret-manager. 이 구성요소는 리소스 매니저와 인증되지 않은 프로세스로 작업하길 원하는 클라이언트에게 위임 토큰(Delegation token)을 생성할 책임이 있습니다.

⑥ DelegationTokenRenewer

보안 모드에서 리소스 매니저는 Kerberos 인증이며, 응용 프로그램을 대신하여 파일 시스템 토큰을 갱신하는 서비스를 제공합니다. 이 구성요소는 응용 프로그램이 실행되는 동안 그리고 토큰이 더 이상 갱신할 수 없을때까지 제출된 응용프로그램의 토큰을 갱신합니다.

결론

얀에서 리소스 매니저는 주로 스케쥴링 작업에 국한됩니다. 예를 들면 단지 경쟁 응용 프로그램들 간의 시스템에서 사용 가능한 자원을 중재하고 응용프로그램들의 상태 관리는 관심을 가지지 않습니다. 이 때문에 위에서 설명한 모듈 방식과 더불어 분명한 책임의 분리 그리고 이전 포스트에서 설명한 강력한 스케쥴러 API로 인하여, 리소스 매니저는 확장성과 다른 프로그래밍 패러다임에 대한 지원등 가장 중요한 설계 요구 사항을 충족할 수 있습니다. 서로 다른 정책 제한을 허용하기 위해서 리소스 매니저는 플러거블(Pluggable)하고 다른 알고리즘 사용을 허가합니다.

[ 리소스 매니저 ]

 출처 : http://ryufree.tistory.com/m/230?category=252660

아파치 하둡 얀은 리소스 관리와 컴포넌트 처리를 분리한 하둡 2.0에 도입된 아파치 소프트웨어 재단의 서브 프로젝트입니다. 얀은 맵-리듀스의 차세대 기술로서 맵-리듀스의 확장성과 속도문제를 해소하기 위해 새로 개발된 프로젝트입니다. 얀 이전의 맵-리듀스에서는 4000노드 이상의 클러스터에서 시스템 확장에 문제가 발생하여 야후(Yahoo)에서 새로 설계하였습니다.

가장 큰 변화로는 얀 자체로 맵-리듀스를 구동할 수 있으며, 추가로 다른 분산 처리 프레임워크(Tez, HBase, Giraph, Spark 등)를 사용자의 인터페이스 개발만으로 구동이 가능하게 되었습니다.

[ 하둡 2.0 스택 ]

얀(YARN)은 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)의 상단에서 빅 데이터용 애플리케이션들을 실행하는 대용량 분산 운영체제 역할을 수행합니다. 얀(YARN)을 이용하면 안정적인 기반에서 배치 작업과 양방향 실시간 작업을 수행할 수 있습니다. 아파치 재단은 얀(YARN)을 ‘맵-리듀스 버전 2(MRv2)’로 명명했습니다.

YARN의 구조

얀(YARN)은 크게 리소스 매니저(Resource Manager), 노드 매니저(Node Manager), 애플리케이션 마스터(Application Master), 컨테이너(Container)로 구성되어 있습니다.

① 리소스 매니저(Resource Manager)

클러스터 전체를 관리하는 마스터 서버의 역할을 담당하며, 응용 프로그램의 요청을 처리합니다. 리소스 매니저는 클러스터에서 발생한 작업을 관리하는 애플리케이션 매니저(Applications Manager)를 내장하고 있으며, 응용 프로그램들 간의 자원(resource) 사용에 대한 경쟁을 조율합니다. 여기서 말하는 자원이란 CPU, 디스크(disk), 메모리(memory)등을 의미합니다.

② 노드 매니저(Node Manager)

노드당 하나씩 존재하며, 슬레이브 노드(slave node)의 자원을 모니터링(monitoring) 하고 관리하는 역할을 수행합니다. 노드 매니저는 리소스 매니저의 지시를 받아 작업 요구사항에 따라서 컨테이너를 생성합니다.

③ 애플리케이션 마스터(Application Master)

노드 매니저와 함께 번들로 제공되며, 작업당 하나씩 생성이 되며, 컨테이너를 사용하여 작업 모니터링과 실행을 관리합니다. 또한, 리소스 매니저와 작업에 대한 자원 요구사항을 협상하고, 작업을 완료하기 위한 책임을 가집니다.

④ 컨테이너(Container)

CPU, 디스크(Disk), 메모리(Memory) 등과 같은 속성으로 정의됩니다. 이 속성은 그래프 처리(Graph processing)와 MPI(Message Passing Interface: 분산 및 병렬 처리에서 정보의 교환에 대해 기술하는 표준)와 같은 여러 응용 프로그램을 지원하는데 도움이 됩니다. 모든 작업(job)은 결국 여러 개의 작업(task)으로 세분화되며, 각 작업(task)은 하나의 컨테이너 안에서 실행이 됩니다. 필요한 자원의 요청은 애플리케이션 마스터(Application Master)가 담당하며, 승인 여부는 리소스 매니저(Resource Manager)가 담당합니다. 컨테이너 안에서 실행할 수 있는 프로그램은 자바 프로그램뿐만 아니라, 커맨드 라인에서 실행할 수 있는 프로그램이면 모두 가능합니다.

[ YARN의 전체 구성도 ]

리소스 매니저(Resource Manager)의 구조

리소스 매니저는 클러스터마다 존재하며, 클러스터 전반의 자원 관리와 작업(task)들의 스케쥴링을 담당합니다. 리소스 매니저는 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 애플리케이션 마스터(Application Master)를 실행합니다. 또한 클러스터 내에 설치된 모든 노드 매니저(Node Manager)와 통신을 통해서 각 서버마다 할당된 자원과 사용중인 자원의 상황을 알 수 있으며, 애플리케이션 마스터들과의 통신을 통해 필요한 자원이 무엇인지 알아내어 관리하게 됩니다.

리소스 매니저(Resource Manager) 내부에는 여러 개의 컴포넌트들이 존재하며, 스케쥴러(Scheduler), 애플리케이션 매니저(Application Manager), 리소스 트랙커(Resource Tracker) 세개의 메인 컴포넌트가 있습니다.

① 스케쥴러(Scheduler)

노드 매니저(Node Manager)들의 자원 상태를 관리하며 부족한 리소스들을 배정합니다. 스케쥴러는 프로그램의 상태를 검사하거나 모니터링 하지 않으며, 순수하게 스케쥴링 작업만 담당합니다. 스케쥴링이란 자원 상태에 따라서 작업(task)들의 실행 여부를 허가해 주는 역할만 담당하며, 그 이상의 책임은 지지 않습니다. 즉, 프로그램 오류나 하드웨어의 오류로 문제가 발생한 프로그램을 재 시작시켜주지 않으며, 프로그램에서 요구하는 리소스(CPU, Disk, 네트워크등)에 관련된 기능만 처리합니다.

② 애플리케이션 매니저(Application Manager)

노드 매니저(Node Manager) 에서 특정 작업을 위해서 애플리케이션 마스터(Application Master)를 실행하고, 애플리케이션 마스터(Application Master)의 상태를 관리합니다. 여기서 애플리케이션 마스터(Application Master)라는 용어가 나오는데 얀에서 실행되는 하나의 작업(task)을 관리하는 마스터 서버를 말합니다.

③ 리소스 트랙커(Resource Tracker)

컨테이너(Container)가 아직 살아 있는지 확인하기 위해서, 애플리케이션 마스터(Applications Master) 재 시도 최대 횟수, 그리고 노드 매니저(Node Manager)가 죽은 것으로 간주 될 때까지 얼마나 기다려야 하는지 등과 같은 설정 정보를 가지고 있습니다.

[ 리소스 매니저: 서브 컴포넌트 ]

노드 매니저(Node Manager)의 구조

노드 매니저는 노드(컴퓨터) 당 한 개씩 존재합니다. 해당 컨테이너(Application Container)의 리소스 사용량을 모니터링 하고, 관련 정보를 리소스 매니저에게 알리는 역할을 담당합니다. 애플리케이션 마스터(Application Master)와 애플리케이션 컨테이너(Application Container)로 구성되어 있습니다.

① 애플리케이션 마스터(Application Master)

하나의 프로그램에 대한 마스터 역할을 수행하며, 스케쥴러로부터 적절한 애플리케이션 컨테이너(Application Container)를 할당 받고, 프로그램 실행 상태를 모니터링하고 관리합니다.

② 애플리케이션 컨테이너(Application Container)

프로그램에 할당된 자원을 나타냅니다.

얀의 작업 순서

다음 그림은 얀 클러스터(YARN Cluster)에서 응용 프로그램이 실행되는 과정을 보여줍니다.

[ 얀의 작업 순서 ]

http://skccblog.tistory.com/1884

Hadoop이 버전1에서 버전2로 올라갔지만, 두 버전 모두 MapReduce 엔진을 주요 모듈로 가지고 있다.

MapReduce도 HDFS와 비슷한 방식으로 Job을 제출하고, Job의 진행 상황을 추적하는 로직을 가지고 있다.

네임노드가 있는 서버에는 잡 트래커(Job Tracker)가 있고,

데이터노드가 있는 장비에는 태스크 트래커(Task Tracker)가 배치된다.

비슷하게 잡 트래커는 여러 태스크 트래커에 효율적으로 임무를 할당하고, 결과를 수신하여 병합하는 역할을 한다.

하지만 MapReduce 엔진은 Hadoop 0.23버전에서 대폭 변경이 된다.

그래서 MapReduce 2.0 혹은 MRV2라고 불렀었는데,

나중에 YARN(Yet Another Resource Negotiator)이라는 이름이 지어졌다. 

(yarn은 '실'이라는 뜻이 있어서, YARN을 표현할 때 털실뭉치를 많이 사용한다)

YARN은 기존의 Job Tracker를 리소스 매니저(Resource Manager)와 어플리케이션 마스터(Application Master)로 분리하였다.

리소스 매니저들은 클러스터 내의 컴퓨팅 리소스들을 어플리케이션에 할당해 주는 역할을 한다.

어플리케이션 마스터는 컴퓨팅 리소스를 할당받아 어떤 어플리케이션을 실행하고, 라이프 사이클을 관리한다. 

이 어플리케이션은 전통적인 MapReduce 뿐 아니라, 다른 형태의 것도 가능해서 훨씬 더 융통성이 생겼다.

정리하면 리소스 매니저는 장비마다 있는 노드 매니저(Node Manager)를 통해 리소스를 관리하고, 어플리케이션 마스터는 어플리케이션 마다 할당되어 생성되며, 리소스 매니저와의 협상을 통해 실제 컴퓨팅 리소스를 사용한다.

이러한 변화는 아래의 Hadoop 스택을 통해서도 볼 수 있다. 즉 이제 MapReduce는 유일한 프로세싱 방법이 아니라, DAG(Directed Acyclic Graph, 방향성 비순환 그래프)로 일반화된 프로세싱 방법 위에서 돌아가는 하나의 어플리케이션일 뿐이다.

결론적으로 YARN은 Hadoop의 클러스터 컴퓨팅 파워를 더 향상시켰다.

확장성 : 매우 큰 동적인 클러스터를 효율적으로 관리할 수 있다

호환성 : YARN은 기존의 MapReduce 어플리케이션과의 하위 호환성을 제공한다. 그래서 Hadoop 1.0에서 작성된             프로그램은 Hadoop 2.0에서도 동작한다.

효율성 : 클러스터의 각 장비의 컴퓨팅 능력을 최대로 활용하여, 컴퓨팅 용량을 증가시켰다.

다양한 워크플로우 지원 : MapReduce 뿐 아니라 그래프 프로세싱, 반복(Iterative) 모델링, 머신러닝 등의

다른 워크 플로우도 지원한다.

Hadoop의 기본 모듈과 생태계 

Hadoop은 4개의 기본 모듈로 구성된다. Hadoop Common, HDFS, MapReduce, YARN이 그것들이다.

HBase, Pig, Hive 등의 모듈들도 다 이 네개의 기본 모듈 위에서 동작하는 것들이다.

출처 : http://ddmix.blogspot.kr/2015/11/hadoop-1-stack-overview.html