하둡 완벽 가이드 5장 맵리듀스 프로그래밍 6장 맵리듀스 작동 방법

5장 맵리듀스 프로그래밍

Job Tuning
매퍼 개수: 매퍼가 얼마나 오랫동안 수행되고 있는가? 너무 작은 시간 동안 수행된다면 더 작은 수의 매퍼를 사용해본다.
리듀서 개수: 리듀서 개수는 거의 클러스터에 있는 리듀스 슬롯 개수보다 적어야 한다. 리듀서가 한 번만에 완료되고 리듀서 단계에서 클러스터 전체를 이용하도록 지원한다.
컴바이너: 사용자 잡이 컴바이너를 이용할 수 있는지 확인한다.
중간 데이터 압축
맞춤형 직렬화
셔플 꼬임

Apahce Oozie
연관되어 있는 잡의 워크플로우를 실행하는 시스템이다.
하둡 클러스터에서 수천 개의 워크플로우를 적합한 시간 내에 실행되도록 관리할 수 있다.
workflow engine: 다른 종류의 하둡 잡으로 구성된 워크플로우를 저장하고 실행한다.
coordinator engine: 미리 정의되어 있는 스케쥴과 데이터 가용성을 기반으로 워크플로우 잡을 실행한다.



6장 맵리듀스 작동 방법

맵리듀스1
클라이언트: 맵리듀스 작업을 제출한다.
잡트래커: 잡 수행을 상호조정한다.
태스크트래커: 해당 잡에 대해 분할된 태스크를 수행한다.
분산파일시스템: 다른 단게 간에 잡 파일을 공유하기 위해 사용된다.

잡 설정 태스크: 태스크트래커가 맵 태스크 실행 전 잡 설정을 위해 실행
잡 청소 태스크: 리듀스 태스크 실행 전 잡 청소를 위해 실행


맵리듀스2(얀)
병목현상을 해결하기 위해 설계됐다.
잡트래커의 책임을 여러 개의 책임자에게 분리해서 나눠준다.
리소스매니저: 클러스터 전반에 걸쳐 리소스 이용을 관리한다.
애플리케이션마스터: 클러스터에서 실행 중인 애플리케이션의 생명주기를 관리한다.
얀은 맵리듀스보다 더 일반적이다.
동일 클러스터에서 여러 다른 얀 애플리케이션이 함께 실행될 수 있다.







댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - MapReduce: Simplified Data Processing on Large Clusters

Abstract 맵리듀스는 큰 데이터 셋을 다루는 프로그래밍 모델이다 . 사용자는 map 함수를 통해서 키 / 밸류 쌍을 이용하여 intermediate key/value pair 를 만들고 reduce 함수를 통해서 그 intermediate pair 들을 같은 key 별로 합쳐준다 . 많은 일들이 이런 모델을 통해 표현될 수 있다 . 이 모델은 분산 시스템이나 병렬 시스템에 대한 경험이 부족하더라도 분산 시스템의 자원을 쉽게 사용할 수 있게 해준다 . 1. introduction 데이터가 많아지면서 reasonable time 안에 작업을 끝내기 위해 수백 혹은 수천대의 기계에 분산되어야 했다 . 이 때 어떻게 연산을 병렬화하고 , 데이터를 분산하고 , 실패 작업을 어떻게 처리할지가 이슈가 되었다 . 이런 복잡한 문제들을 해결하기 위해 병렬화의 세세한 부분들은 숨기고 fault tolerance 하며 데이터를 분산시켜주고 로드 밸런싱을 해주는 라이브러리를 통해서 연산을 맵과 리듀스로 간단히 표현하도록 했다 . 2. Programming Model 사용자가 직접 만드는 맵 함수는 입력으로 key/value pairs 를 받아서 intermediate key/value pairs 를 만든다 . 그러면 intermediate key/value pairs 에 대해서 맵리듀스 라이브러리가 같은 key 별로 value 들을 묶어서 리듀스 함수로 보내준다 . 마찬가지로 사용자가 직접 만드는 리듀스 함수는 이 데이터를 받아서 key 별로 묶인 value 들을 합쳐서 표현한다 . 리듀스 함수에 전달되는 intermediate 데이터는 iterator 의 형태로 전달되기 때문에 메모리에 다 안 들어갈 정도로 큰 데이터도 처리할 수 있다 . 예를 들어서 , 어떤 문서에 있는 각 단어들이 몇 번 나왔는지 세는 프로그램을 생각해보자 . 그렇다면 맵 함수는 입력으로 < 문서 이름 , 문서 내용 > 의...
자세한 내용 보기

논문 정리 - The Google File System

The Google File System 1. Introduction 새로운 관점 component failure 은 예외가 아니라 일반적인 상황이다 . 그래서 constant monitoring, error detection, fault tolerance, automatic recovery 가 필요하다 . 파일의 크기가 커졌다 . I/O 작업이나 block 크기 등이 고려되어야 한다 . 원래 있는 데이터에 덮어쓰는 작업보다는 새로운 데이터를 추가한다 . 따라서 appending 이 성능 최적화에 중요해졌다 . 2. Design Overview 2.1 assumptions 시스템은 잘 고장나는 저렴한 장비들로 구성되어 있다 . 시스템은 큰 파일이 있다 . 작은 파일들도 있지만 optimizing 할 때는 고려하지 않는다 . 로드는 주로 큰 스트리밍 읽기와 작은 랜덤 읽기로 구성되어 있다 . 로드는 또한 파일에 데이터를 추가하는 많은 sequential write 가 있다 . 같은 파일에 여러 사용자가 동시에 데이터를 추가하는 경우도 잘 고려해야 한다 . 빠른 반응 속도 보다는 high sustained bandwidth 가 더 중요하다 . 대부분의 타겟 애플리케이션은 데이터 뭉텅이를 빠른 시간 내에 처리하는 것을 중요하게 여긴다 . 2.2 Interface 파일은 hierarchically , 디렉토리에 정렬돼있고 path name 으로 구분된다 . 또한 GFS 는 snapshot 과 record append 기능이 있다 . snapshot 은 파일이나 디렉토리 트리를 복사한다 . record append 는 다수 클라이언트가 데이터를 하나의 파일에 동시에 추가할 수 있도록 해준다 . 각 append 의 atomicity 를 보장하면서 . 2.3 Architecture 하나의 마스터와 여러개의 chunkserver 로 구성되어 있다 . 그리고 다수의...
자세한 내용 보기

kazoo: Using zookeeper api with python

``` pip3 install kazoo ``` https://kazoo.readthedocs.io/en/latest/basic_usage.html https://kazoo.readthedocs.io/en/latest/api/client.html ### 접속 ``` from kazoo.client import KazooClient zk = KazooClient(hosts='127.0.0.1:2181') zk.start() ``` 호스트에 접속할 때 default port는 2181이다. ### 상태 Listener zookeeper의 상태가 변하는 것을 알 수 있다. ``` from kazoo.client import KazooState def my_listener(state):     if state == KazooState.LOST:         # Register somewhere that the session was lost     elif state == KazooState.SUSPENDED:         # Handle being disconnected from Zookeeper     else:         # Handle being connected/reconnected to Zookeeper zk.add_listener(my_listener) ``` LOST CONNECTED SUSPENDED 의 state를 가질 수 있다. 가능한 상태 변화 - LOST -> CONNECTED - CONNECTED -> SUSPENDED - CONNECTED -> LOST - SUSPENDED -> LOST - SUSPENDED -> CONNECTED ### CRUD - `zk.create("/my/favorite/node", b"a value")` `create(path...
자세한 내용 보기