MapReduce연산이 진행되는 DataFlow에 대해 살펴 보겠습니다.

1. Input Files

MapReduce Task를 위한 데이터는 inputFile에 저장되어 있습니다. 그리고 이 input file은 HDFS에 저장 되어있습니다. 이 파일의 포맷은 임시적이며, line-based log files 과 binary format 을 사용할 수 있습니다.

2. InputFormat

InputFormat은 input file이 어떻게 분할되고 어떻게 읽어지는 가를 정의합니다.

Hadoop의 Job은 Map task와 Reduce task로 나누어집니다.

그리고 이 task들은 Yarn에 의해 스케쥴링되고 클러스터안의 노드위에서 실행됩니다. 만약 task가 fail되면 자동으로 다른 노드로 rescheduling합니다.

InputFormat은 입력을 위해서 파일이나 다른 객체를 선택하여 getSplits()를 통하여 List<inputSplit>을 생성합니다. inputSplit를 Application Master에 전달하면 Map Task가 createRecordReader()를 실행시켜 RecordReader를 만듭니다.

Hadoop은 각각의 Split마다 하나의 MapTask를 생성하게 되는데, MapTask는 Split을 각각의 record로 나누어 사용자 정의 map Function을 적용합니다.

2.1. InputSplits

inputSplit은 inputFormat에 의해 생성되며, 데이터를 각각의 Mapper에 맞는 논리 형식으로 분할합니다. 예를들어서 HDFS의 File size는 128MB인데, 파일크기가 150MB라면 Block을 2개 읽어와서 논리적으로 시작과 끝을 지정합니다.

2.2. RecordReader

InputSplit에서 분할된 레코드들을 Mapper에 적합한 Key-Value쌍으로 변환합니다. 기본적으로 TextInputFormat를 사용하여 Key-Value쌍으로 변환합니다. InputFormat은 기본적으로 TextInputFormat를 지원하는데, TextInputFormat은 text file을 읽을때 \n까지를 한줄로 인식하고 한줄 단위로 Split을 만드는 기능을 합니다.

그리고 Record Reader은 InputSplit에서 유니크한 수인 byte offset을 키로하고, 각 라인을 value로 해서 하나의 새로운 Key-Value쌍을 만듭니다. 그리고 이 Key-Value쌍을 Data Processing을 위한 Mapper로 전송하게 됩니다.

3. Mapper

RecordReader를 통해서 입력된 record를 완전히 새로운 Key-Value쌍으로 만드는 프로세스 입니다. Mapper의해 발생된 출력은 HDFS에 바로 저장되지 않고 임시 데이터로 저장이고, 이 출력은 곧 Combiner에 입력으로 들어가게됩니다.

4. Combiner

‘Mini-reducer’라고 알려져 있는 Combiner는 Mapper의 출력을 local에서 Reduce를 처리합니다. local에서 각각에 대하여 reduce연산을 수행하게 되면 이후 진행되는 shuffling이나 Sorting Reducer작업을 위해 데이터를 전송할때 생기는 부하를 줄여주는 효과가 있습니다.

5. Shuffling and Sorting

Reduce에 입력으로 주기위해 Map연산이 끝난 데이터를 Reduce연산에서 생기는 네트워크 트래픽을 최소화 하기 위해서 Sorting하고 같은것으로 모으는 작업입니다.

6. Reducer

Mapper에 의해 생성된 key-Value쌍을 가지고 각각의 reduce연산을 통하여 최종 결과물을 출력합니다. 이 최종결과물은 HDFS에 저장됩니다.

7. RecordWriter

Reduce 연산이 끝난 Key-Value쌍을 출력 파일에 씁니다.

8. OutputFormat

OutputFormat에 의해 결정된 RecordWrite가 출력된 Key-Value쌍을 file에 씁니다. OutputFormat instances은 HDFS또는 그 local disk가 사용하는 하둡에의해 제공됩니다. reducer의 최종 출력은 OutputFormat instances에 의해 HDFS에 저장됩니다.

Indexing은 조회쿼리에 대한 연관문서를 빠르게 찾기위해 사용한다.

Inverted index

검색하고자 하는 단어가 입력되었을때, 해당문서에 단어가 존재하는지 안하는지 만을 알수있다.

The forward index

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