하둡완벽가이드 Ch6. 맵리듀스 작동 방법
Upcoming SlideShare
Loading in...5
×
 

하둡완벽가이드 Ch6. 맵리듀스 작동 방법

on

  • 3,088 views

하둡 완벽가이드 챕터6. 맵리듀스 작동 방법

하둡 완벽가이드 챕터6. 맵리듀스 작동 방법

Statistics

Views

Total Views
3,088
Views on SlideShare
2,972
Embed Views
116

Actions

Likes
4
Downloads
76
Comments
0

1 Embed 116

http://cecil1018.wordpress.com 116

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

하둡완벽가이드 Ch6. 맵리듀스 작동 방법 하둡완벽가이드 Ch6. 맵리듀스 작동 방법 Presentation Transcript

  • Hadoop The Definitive Guide Ch.6 How MapReduce Works 아꿈사 cecil 13년 8월 31일 토요일
  • Anatomy of A MapReduce Job Run 13년 8월 31일 토요일
  • Map Reduce 3가지 동작방식 • local • 단일 JVM에서 전체 잡을 실행 • 작은 데이터 셋으로 맵리듀스 프로그램을 실행하거나, 테스트 하는 목적에 적합 • classic • 잡 트래커와 태스크 트래커를 사용하는 맵리듀스 1 •YARN • 새로운 프레임워크 맵리듀스 2 13년 8월 31일 토요일
  • Map Reduce I 13년 8월 31일 토요일
  • 주요 컨포넌트 • 클라이언트 • 맵 리듀스 잡을 제출 • 잡 트래커 • 잡 수행 과정을 조정 • JobTracker를 주 클래스로 하는 자바 응용 프로그램 • 태스크 트래커 • 잡에 대한 분할된 태스크를 수행 • 자바 응용 프로그램으로서 TaskTracker를 주 클래스로 함 • 분산 파일 시스템 (HDFS) • 각 단계들 간에 잡 파일을 공유하기 위해 사용 13년 8월 31일 토요일
  • 맵리듀스 잡의 동작 13년 8월 31일 토요일
  • 잡 제출 • Job의 waitForCompletion 메소스 수행 과정 • Job의 submit 메소드를 호출 • 진행 과정을 조사하여 변경이 생기면 콘솔로 출력 • 잡 제출 과정 • 잡트래커에서 새로운 잡 ID를 요청 • 잡의 출력 명세를 확인 • 잡에 대한 입력 스플릿을 계산 • 잡수행에 필요 자원을 잡트래커 파일시스템 상의 해당 잡 ID를 이름으로 하는 디렉토리에 복사 (jar, 설정 파일, 스플릿 정보) • 잡 트래커가 잡을 시작할 준비가 되었음을 알림 13년 8월 31일 토요일
  • 잡 초기화 • 잡 트래커가 submitJob 메소드의 호출 받으면 잡을 내부 큐에 저장 • 잡 스케쥴러는 큐에서 잡을 읽어서 초기화 과정을 진행 • 실행할 잡을 표현하기 위해 하나의 객체를 생성 • 이 객체는 잡에 대한 태스크 뿐만 아니라 상태 및 진행 과정을 유지하기 위한 부가 정보를 캡슐화 • 초기화 과정 • 공유 파일 시스템으로 부터 계산된 입력 스플릿 정보를 가져옴 • 각 스플릿에 대해 하나의 맵 태스크를 생성 • mapred.reduce.tasks 속성 값에 따라 이 수 만큼 리듀스 태스크를 생성 • 추가 태스크 생성 • 잡 설정 태스크: 맵 태스크 실행전 잡 설정을 위해 실행 • 잡의 최종 출력을 위한 디렉토리와 태스크 출력을 위한 임시 작업 공간을 생성 • 잡 청소 태스크: 리듀스 태스크 실행전 잡 청소를 위해 실행 • 태스크 출력을 위한 임시 작업 공간을 삭제 13년 8월 31일 토요일
  • 태스크 할당 • 태스크 트래커는 하트비트를 보내는 단순한 루프를 수행 • 하트비트는 라이브 체크 및 메시지 채널 용도로 사용됨 • 하트 비트의 일부로 태스크 수행 준비가 되었는지 여부를 전달 • 하트비트의 응답으로 할당된 테스크 전달 • 태스크 트래커는 맵 및 리듀스 태스크를 위한 많은 수의 혼합된 슬롯을 가짐 • 정확한 수치는 태스크 트래커의 CPU 코어수와 메모리에 따라 결정 • 일반적으로 맵 태스크 슬롯을 리듀스 태스트 슬롯보다 먼저 채움 • 잡 트래커의 태스크 트래커 선택 기준 • 리듀스 태스크는 순차적으로 선택됨. 지역성을 고려하지 않음 • 태스크 트래커는 네트워크 상의 지역을 계산하여 가능하면 인접해 있는 입력 스플릿을 갖 도록 선택 13년 8월 31일 토요일
  • 태스크 실행(1/2) • 태스크 트래커의 태스트 실행 과정 • 잡 JAR을 로컬 파일 시스템으로 복사 • 분산 캐시로부터 필요한 모든 파일을 로컬 파일 시스템으로 복사 • 태스크 실행을 위한 로컬 잡 디렉토리를 생성하고, JAR를 압축 해제 • 태스크 러너 인스턴스를 생성하여 태스크를 수행 • 태스크 러너는 별도의 자바 가상 머신을 실행 • 각 잡은 별도의 JVM에서 실행됨 • 사용자가 개발한 맵/리듀스 함수의 어떤 버그도 태스크 트래커에 영향을 미치지 못함 • 자식 프로세스와는 엄빌리컬 인터페이스를 통해 통신 • 스트리밍과 파이프는 사용자가 제공한 실행 파일을 실행하고 통신하기 위해 특별한 맵 리듀스 태스크를 수행 13년 8월 31일 토요일
  • 태스크 실행(2/2)⅓ 13년 8월 31일 토요일
  • 진행 상황과 상태 갱신 (1/2) • 맵리듀스 잡은 대부분 상당한 시간이 걸리기 때문에 진행 상황에 대한 피드 백을 얻는 것이 중요 • 태스크 진행율 • 맵 태스크: 처리된 입력의 비율 • 리듀스 태스크: 총 진행을 3단계로 나누어 계산(셔플 포함) • 카운터를 통한 피드백 • 태스크는 카운터를 가지고 있음. • 프레임워크에 내장되거나 사용자가 정의한 카운터를 실행하는 방식으로 이벤트 카운트 가능 • 진행 상황의 통지 • 태스크는 보고 플래그가 설정되어 있다면 태스크 트래커에게 진행 상황을 3초마다 보고 • 태스크 트래커는 하트비트에 진행중인 모든 태스크의 상태를 포함하여 전송 • 클라이언트 잡은 매초마다 잡 트래커를 폴링하여 최신 정보를 갱신 13년 8월 31일 토요일
  • 진행 상황과 상태 갱신 (2/2) 13년 8월 31일 토요일
  • 잡 완료 • 잡 트래커는 하나의 잡에 대한 마지막 태스크가 완료 되었을 경우 상태를 “성공”으로 변경 • 클라이언트는 상태를 검사하고, 사용자에게 알려주기 위한 메시지를 출력 • waitForcompletion 메소드가 종료되고, 잡 통계와 카운터가 콘솔로 출력됨 • 잡 트래커의 설정에 따라 HTTP 잡 통지 가능 • 콜백을 받고자 하는 클라이언트는 job.end.notification.url을 설정 13년 8월 31일 토요일
  • Map Reduce II YARN (Yet Another Resource Negotiator) 13년 8월 31일 토요일
  • 이전 버전과의 차이 (1/2) • 이전 버전의 맵 리듀스 시스템은 4,000 노드 이상의 매우 큰 클 러스터 상에서 동작시 병목현상 이슈가 발생함 • 확장성 문제를 해결하기 위해 잡트래커의 책임을 여러 컨포넌트 로 분리 • 리소스 매니저: 리소스 이용을 관리 • 애플리케이션 마스터: 클러스터에서 실행중인 애플리케이션의 생명 주기 관리 • 노드매니저: 컨테이너를 감시하고, 응용 프로그램이 할당받은 그 이상의 리소스가 사용되지 않도록 보장 • 잡 트래커와 다르게 응용 프로그램의 각 인스턴스는 애플리케이 션 마스터를 고정적으로 할당시켜 응용 프로그램의 지속성을 유지 13년 8월 31일 토요일
  • 이전 버전과의 차이 (2/2) 출처: Hortonworks, http://hortonworks.com/hadoop/yarn 13년 8월 31일 토요일
  • 주요 컨포넌트 • 클라이언트 • 맵리듀스 잡을 제출 • 얀 리소스 매니저 • 클러스터 내 컴퓨팅 리소스 할당을 조정 • 얀 노드 매니저 • 클러스터 내 서버의 컴퓨팅 컨테이너를 배포 및 모니터 • 맵리듀스 애플리케이션 마스터 • 맵 리듀스 잡을 실행하고 있는 태스크를 조정 • 분산 파일 시스템 • 다른 시스템 컴포넌트 간 잡 파일을 공유하기 위해 사용 13년 8월 31일 토요일
  • YARN Map-Reduce 13년 8월 31일 토요일
  • 잡 제출 • 잡 제출 과정은 이전 버전과 유사 • 잡 제출 과정 • 사용자 API를 사용하여 잡 제출 실행 • 리소스 매니저로부터 새로운 애플리케이션 ID 를 할당 받음 • 클라이언트는 잡 리소스를 분산 파일 시스템으로 복사 • 리소스 매니저의 submitApplication을 호출하여 잡 제출을 완료 13년 8월 31일 토요일
  • 잡 초기화 • 리소스 매니저는 submitApplication이 호출되면 스케쥴러로 요청을 전달 • 스케쥴러의 잡 할당 과정 • 컨테이너를 할당하고, 리소스 매니저는 노드 매니저의 관리를 받도록 애플리케이션 마스터를 할 당 받은 컨테이너로 배포 • 애플리케이션 마스터는 잡의 진행 상황을 감시하기 위한 다수의 북키핑 객체를 생성하면서 잡을 초기화 • 태스크로 부터 잡의 진행상황과 완료를 통보 받음 • 공유 파일 시스템으로 부터 계산된 스플릿을 받음 • 애플리케이션 마스터는 mapreduce.job.reduces 속성으로 정해진 다수의 리듀스 객체와 맵 태스 크 객체 생성하고 태스크 수행 방법을 결정 • 작은 잡일 경우 동일 JVM에서 태스크를 실행(유버 라이즈 or 유버 태스크) • 애플리케이션 마스터는 모든 태스크를 실행 전에 출력 디렉토리를 생성하는 잡 설정 메소드를 호출 13년 8월 31일 토요일
  • 태스크 할당 • 유버 태스크로 실행하기 적합하지 않은 잡일 경우 애플리케이션 마스터는 리소스 매니 저에게 컨테이너를 요청 • 모든 요청은 하트 비트 호출에 피기백 됨 • 맵 태스크의 데이터 지역성과 특별히 입력 스플릿이 위치한 호스트 및 해당 랙 정보 포함 • 태스크는 데이터 지역성을 고려하여 할당함 • 메모리 할당 방식 • 맵리듀스 1 • 클러스터 구성 시 설정된 고정 개수의 슬롯을 가짐 • 슬롯은 최대 메모리 허용치가 클러스터 단위로 고정되어 있음 • 적은 태스크가 주어질 경우 이용률이 떨어짐 • YARN • 애플리케이션은 메모리의 최소 할당과 최대 할당에 대한 요청이 가능 • 기본적인 메모리 할당은 스케줄러에 지정되어 있음 13년 8월 31일 토요일
  • 태스크 실행 • 태스크 실행 과정 • 애플리케이션 마스터는 노드 매니저에 협조를 얻어 컨테이너를 작동 • 태스크는 자바 애플리케이션으로 실행됨YarnChild • 애플리케이션은 태스크가 필요로 하는 리소스를 로컬로 가져옴 • 맵이나 리듀스 태스크 실행 • 맵 리듀스 1과 동일하게YarnChild는 할당된 JVM에서 실행 • Yarn은 JVM 재사용을 지원하지 않음. 매번 생성 • 스트리밍과 파이프 프로그램은 맵리듀스 2과 동일하게 작동 13년 8월 31일 토요일
  • 진행 상황과 상태 갱신 (1/2) • YARN에서는 진행상황과 상태 정보를 애플리케이션 마스터에게 보고 • 클라이언트는 진행 상황의 변화를 확인하기 위하여 매초마다 애플리케이션 마스터를 조회 • 진행 상황 모니터링 • 맵리듀스 I: 잡 트래커의 웹 UI를 통해 제공 • YARN: 리소스 매니저의 웹 UI를 통해 실행중인 모든 애플리케이 션을 보여주고, 각 링크가 애플리케이션 마스터의 웹 UI로 연결 됨 13년 8월 31일 토요일
  • 진행 상황과 상태 갱신 (2/2) 13년 8월 31일 토요일
  • 잡 완료 • 잡이 완료되면 애플리케이션 마스터와 태스크 컨테이너는 작업 상태를 정리하고 OutputCommitter의 잡 청소 메소드를 호출 • 잡 정보는 사용자가 필요할 때 사후 조사를 위 해 잡 히스토리 서버가 아카이빙 • 맵 리듀스 I에서처럼 HTTP 콜백을 통해 잡 실 행 관련 이벤트 통지 13년 8월 31일 토요일
  • Failures 13년 8월 31일 토요일
  • Map Reduce I 13년 8월 31일 토요일
  • 태스크 실패 • 실패 유형 • 대부분의 실패 유형은 맵 또는 리듀스 태스크 내의 사용자 코드 예외 • JVM 버그로 인한 실패 • 태스크 트래커가 일정기간 진행 상황을 갱신 받지 못할때 • 잡 트래커는 태스크의 실패를 통지 받으면 태스크 실행을 다시 스케쥴링 • 이전에 실패한 태스크 트래커에게 태스크 할당하지 않음 • 특정 태스크가 4번 이상 실패시 더 이상 실행 안함, 전체 잡을 실패로 간주 (mapred.map.max.attempts, mapred.reduce.max.attempts) • 실패 허용 비율을 설정하여 몇몇 태스크의 실패와 관련 없이 잡을 성공으로 처리 가능 (mapred.max.map.failures.precent, mapred.max.reduce.failures.precent) • 강제로 종료된 태스크의 경우 실패로 간주하지 않음 (실패한 태스크 트래커 상에서 실행된 태스크) 13년 8월 31일 토요일
  • 태스크 트래커 실패 • 잡 트래커로의 하트 비트 전송이 중단될 경우 실패로 간주 • 잡 트래커는 해당 태스크 트래커를 풀에서 제외 • 진행중인 태스크와 완료되지 못한 맵태스크를 조사하여 다른곳에서 재 실행 • 블랙 리스트 관리 • 동일 잡에서 4개 이상의 태스크가 특정 태스크 트래커에서 실패한다면 장애 로 기록하고, 장애횟수가 최소 한계점을 넘을 경우 블랙리스트로 관리 • 블랙 리스트가 된 태스크 트래커는 태스크를 할당 받지 못함 • 장애에 대한 유효시간이 만료되면, 다시 태스크를 실행할 기회를 얻음 • 시스템 장애일 경우 클러스터에 다시 등록되고 재실행되어야 블랙리스트로 부터 제거 됨. 13년 8월 31일 토요일
  • 잡 트래커 실패 • 가장 심각한 실패 유형 • 잡 트래커의 실패를 다룰 수 있는 매커니즘이 없음 • 모든 잡이 실패함 • 이러한 실패유형은 드물게 발생 • YARN의 설계 목적이 맵 리듀스의 단일점 실 패 제거에 있음 13년 8월 31일 토요일
  • Map Reduce II YARN (Yet Another Resource Negotiator) 13년 8월 31일 토요일
  • 태스크 실패 • 맵 리듀스 1과 유사 • 애플리케이션 마스터로의 핑이 없을 경우 실 패로 간주 13년 8월 31일 토요일
  • 애플리케이션 마스터 실패 • 애플리케이션 마스터가 실패할 경우 몇번의 재시도가 일어남. • yarn.resourcemanager.am.maxretries • 기본 값은 재실행하지 않음 • 애플리케이션 마스터가 실패하면 리소스 매니저가 새로 운 컨테이너에서 실행할 새로운 인스턴스를 생성 • 클라이언트는 진행 상황 보고를 위해 마스터를 폴링 • 클라이언트는 마스터의 주소를 캐시하고 있는데, 마스터 실패시 리소 스 매니저에게 새로운 마스터의 주소를 요청함 13년 8월 31일 토요일
  • 노드 매니저 실패 • 리소스 매니저로의 하트 비트 전송이 없을때 실패로 간주 • 기본값 10분 • yarn.resourcemanager.nm.liveness-monitor.expiry-interval-ms • 실패한 노드 매니저에서 실행 중인 태스크나 마스터는 각각의 복구 매카니즘을 따름 • 애플리케이션의 실패 횟수가 높으면 블랙 리스트로 관리됨 • 블랙 리스트는 애플리케이션 마스터가 관리 • 한 노드 매니저에서 3개 이상의 태스크가 실패하면 태스크를 다른 노드로 다시 스케쥴링 • mapreduce.job.maxtraskfailures.per.tracker 13년 8월 31일 토요일
  • 리소스 매니저 실패 • 리소스 매니저의 실패는 심각 • 리소스 매니저 없이는 어떤 잡이나 태스크도 컨테이너에 배치되지 못함 • 리소스 매니저 시스템 충돌 문제 해결 • 체크 포인트 메카니즘을 사용하여 안정적인 스토리에 상태 정보를 저장하는 방식을 목 표로 함 • 충돌후 관리자에 의해 재 실행되고 저장되었던 상태로 부터 복구됨 • 리소스 매니저가 사용하는 스토리지 • yarn.resouremanager.store.class로 설정 • 기본 값은 org.apache.hadoop.yarn.server.resource.manager.recovery.MemStore • 현재 주키퍼 기반 저장소가 개발중에 있으며, 향후 리소스 매니저의 실패에 안정적인 복 구 기능이 제공될 예정 13년 8월 31일 토요일
  • Job Scheduling 13년 8월 31일 토요일
  • • FIFO 큐 기반의 스케쥴러 • 맵 리듀스의 기본적인 스케쥴링 방식 • 우선 순위를 부여하여 스케쥴링시 먼저 실행되는 것이 가능하나, 선점을 허용하지 않음 • 페어 스케쥴러 • 모든 사용자가 클러스터를 시간적으로 공평하게 공유할 수 있도록 하는 것이 목적 • 잡은 풀에 위치, 기본적으로 사용자는 자신만의 풀을 가짐 • 선점을 허용. 어떤 풀이 자원을 공평하게 공유 받지 못했다면, 많은 자원을 사용중인 풀 의 태스크를 강제로 종료 • 커패시티 스케쥴러 • 클러스터는 다수의 큐로 구성되고, 각 큐는 할당된 수용량이 있음 • 큐의 잡을 FIFO 스케쥴링 하는 것을 제외하면 페어 스케쥴러와 유사 • 사용자나 조직이 맵 리듀스 클러스터를 개별적으로 사용하는 듯한 효과를 줌 13년 8월 31일 토요일
  • Shuffle and Sort 13년 8월 31일 토요일
  • 셔플 • 정렬을 수행하고 맵의 출력을 리듀서의 입력 으로 전달하는 과정 • 맵 리듀스 프로그램을 최적화할때 중요한 튜 닝 포인트 • 셔플은 코드 기반의 영역으로 현재 정재와 개 선이 끊임없이 이루어 지고 있음 13년 8월 31일 토요일
  • 맵 과정 • 맵 태스크는 환형 구조의 메모리 버퍼를 가지고 있으며, 이 메모리에 데이터를 기록 • 버퍼의 내용이 한계 크기에 도달하면, 백 그라운드 스레드는 디스크로 스필 시작 • 디스크 쓰기에 앞서 리듀스에 상응하는 파티션을 생성 • 각 파티션 내에서 인메모리에서 키에 따라 정렬을 수행 • 컴바이너 함수가 있을 경우 정렬된 출력을 바탕으로 컨바인 잡을 수행 • 메모리 버퍼가 스필 한계에 도달할때 마다 새로운 스필 파일이 생성되고, 태스크가 완료되기 전 스필파일을 하나로 병합 • 최소 3개의 스필 파일이 존재할 경우 출력 파일을 쓰기전 컨바인 잡을 수행 • 출력 파일의 파티션은 리듀서가 HTTP 프로토콜을 통해서 가져 갈수 있도록 만들어짐 The Map Side io.sort.mb io.sort.spill.per cent 0.80 mapred.local.dir 13년 8월 31일 토요일
  • 리듀스 관점 • 리듀스 태스크는 클러스터 전반에 걸쳐 있는 여러개의 맵 태스크로 부 터 파티션을 가져와야 함 • 맵 출력이 작을 경우 메모리 버퍼로 복사 • 메모리의 버퍼가 한계 크기에 도달하면 병합되어 디스크에 저장 • 컴바이너가 있다면 병합 과정에서 데이터 양을 감소 시키기 위해 실행됨 • 복사된 파일이 디스크에 축적되면 이를 더 크고 정렬된 파일로 변합 • 모든 맵 출력이 복사되면 병합 과정을 수행 • 리듀스 함수는 정렬된 출력 내 각각의 키에 대해서 호출이 되고 이 단계 의 출력을 분산 파일 시스템에 곧 바로 기록됨 • 태스크 트래커가 데이터 노드와 같은 곳에서 실행이 되기 때문에, 블록의 첫번째 복제본 은 로컬에 저장됨 13년 8월 31일 토요일
  • 설정 조정 • 맵 리듀스 성능을 향상 시킬려면 셔플을 튜닝할 줄 알아야 함 • 일반적인 원칙은 셔플에 가능한 한 많은 메모리를 할당하는 것 • 맵과 리듀스 함수가 동작하는 데 있어서 충반한 메모리를 확보하도록 보장해 주어야 함 • 맵과 리듀스 함수 작성 시 가능하면 메모리를 적게 사용하도록 작성 • 맵 측면에서 보면 적은 수의 파일이 디스크로 스필 될때 가장 좋은 성능을 발휘 • 맵 출력의 크기를 측정할 수 있다면, io.sort.* 속성을 적절히 설정하여 스필 파일의 수를 최소화 할 수 있음 • 리듀스 측면에서는 중간 데이터 전체가 메모리에 있을 때 가장 좋은 성능을 발휘 • 리듀스 함수가 모든 메모리를 예약해 두기 때문에 이러한 현상은 발생하지 않음 • 리듀스 함수가 메모리를 조금만 필요한다면, apred.inmem.merge.threshold를 0으로 mapred.job.reduce.input.buffer.percent를 1.0으로 설정하여 성능향상을 도모할 수 있음 13년 8월 31일 토요일
  • Task Execution 13년 8월 31일 토요일
  • 투기적 실행 • 맵 리듀스 모델은 잡을 태스크로 나누고 병렬적으로 수행하는 것 • 잡 실행을 느리게 만드는 태스크에 대한 고민이 필요 • 투기적 실행 • 예상했던 것보다 태스크 수행이 느릴 경우를 감지하여 다른 동일한 예비 태스크를 실행 • 하둡은 낭비를 막기 위하여 해당 잡에 대한 모든 태스크가 실행되고 난 후에 실행 • 일정 시간이 경과 되었지만, 다른 태스크의 평균 진행 속도보다 느린 태스크만 대상으로 함 • 태스크가 성공적으로 완료되면 수행 중인 모든 복제 태스크는 강제 종료 됨 • 기본적으로 활성화 되어 있으나, 클러스터의 효율성 측면에서 비용이 따름 • 리듀스 태스트에 대한 투기적 실행 • 일반적으로 사용 안하는 것이 좋음 • 리듀스 태스크를 중복으로 실행하는 것은 맵 출력을 가져와야 하고, 클러스터에 걸쳐 전반적인 네 트워크 트래픽을 증가 시킴 13년 8월 31일 토요일
  • 출력 커미터 • 하둡 맵 리듀스는 잡과 태스크가 완전히 성공하거나 실패하는 것을 보장하기 위해 커밋 프로토콜을 사용 • 기본 값은 FileOutputCommitter이고, 사용자 맞춤형으로 변경 가능 Output Committers OutputCommitter setOutputCommitter() JobConf mapred.output.committer.class OutputCommitter OutputFormat getOut putCommitter() FileOutputCommitter OutputCommitter OutputCommitter public abstract class OutputCommitter { public abstract void setupJob(JobContext jobContext) throws IOException; public void commitJob(JobContext jobContext) throws IOException { } public void abortJob(JobContext jobContext, JobStatus.State state) throws IOException { } public abstract void setupTask(TaskAttemptContext taskContext) throws IOException; public abstract boolean needsTaskCommit(TaskAttemptContext taskContext) throws IOException; public abstract void commitTask(TaskAttemptContext taskContext) throws IOException; public abstract void abortTask(TaskAttemptContext taskContext) throws IOException; } } setupJob()13년 8월 31일 토요일
  • 태스크 JVM 재사용 • 하둡은 다른 실행중인 태스크와 분리되도록 자신의 JVM에서 태스크를 수행 • 각 태스크에 대해 새로운 JVM을 시작시키는 오버헤드는 약 1초 • 매우 짧은 시간 수행하는 태스크일 경우 JVM을 재 사용하는 것이 성 능상의 이득 • 태스크 JVM을 재사용하도록 설정하면 태스크는 하나의 JVM에서 순차적으로 수행됨 • mapred.job.reuse.jvm.num.tasks • YARN에서는 JVM 재사용 기능은 제공되지 않음 13년 8월 31일 토요일
  • 비정상 레코드 생략하기 • 에러가 있는 레코드를 다루는 가장 좋은 방법은 매퍼와 리듀서 코드안 • 무시하거나, 예외를 발생 시켜 해당 잡을 취소 • 매퍼나 리듀서를 수정할 수 없는 3rd 파티 라이브러인 경우 • 하둡은 생략 모드를 지원, 기본적으로 OFF 상태 • 생략 모드의 동작 I) 태스크 실패 II) 태스크 실패 III) 생략 모드가 활성화 됨. 태스크는 실패했지만 실패한 레코드는 태스크 트래커에 저장됨 IV) 생략 모드가 여전히 활성화 됨. 테스크가 이전 시행에서 실패했던 레코드를 생략 • 하둡에 의해 탐지된 비정상 레코드는 잡 출력 디렉토리의 _log/skip에 저장됨 • 생략 모드는 새로운 맵 리듀스 API에서는 제공되지 않음 13년 8월 31일 토요일
  • References 1. Tom White (2013). 하둡 완벽가이드. (심탁 길, 김현우, 옮김). 서울: 한빛미디어. (원서출판 2012) 2. HadoopYARN “A next-generation framework for Hadoop data processing”, Hortonworks, http://hortonworks.com/ hadoop/yarn 13년 8월 31일 토요일