Hadoop 완벽 가이드 1장 2장

1장
하둡 vs 자발적컴퓨팅
자발적 컴퓨팅은 큰 데이터를 쪼갠 뒤 세계 여러 컴퓨터로 보내서 풀어달라고 한다.
신뢰할 수 없는 컴퓨터이기 때문에 3개의 지원자 중 2개 이상이 일치할 경우 승인하는 방식이다.
이는 대역폭을 늘리는 것이 아니라 cpu 사이클을 늘리는 방식이다.
하둡은 이와 다르게 단일 데이터 센터에서 실행되므로 신뢰할 수 있는 전용 하드웨어이다.

피그: 대규모 데이터 셋 탐색용 데이터 흐름 언어와 실행 환경. HDFS와 맵리듀스 클러스터에서 수행된다.
하이브: 분산 데이터웨어하우스. HDFS에 저장된 데이터를 관리하고 데이터 쿼리를 위해 SQL 기반 쿼리 언어를 제공한다.
HBase: 분산 컬럼 지향 데이터베이스. 스토리지로 HDFS를 사용한다. 맵리듀스를 이용한 일괄 처리 방식의 계산과 랜덤 읽기가 가능한 포인트 쿼리 방식 모두를 지원한다.
주키퍼: 다수 컴퓨터로 분산 처리되는 고가용성 저장 서비스. 분산 응용 프로그램을 구축하기 위해 사용될 수 있는 분산 락 같은 primitive를 제공한다.
스쿱: 관계형 데이터베이스와 HDFS 간 데이터를 효율적으로 이동시키기 위한 도구.
오지: 하둡 잡의 워크플로우를 실행하고 스케쥴링하기 위한 서비스.


2장 맵리듀스
맵 단계의 입력은 원본 데이터이다.
예를 들어 세계 각 기상청에서 만든 데이터들을 수집해서 각 해의 최고 기온을 뽑는다고 해보자.
맵 함수는 리듀스 함수의 준비 단계인데 잘못된 레코드를 제거하는 역할도 수행한다.
각 데이터는 키-값 쌍으로 맵에 전달된다. 이 때, 키는 파일 내에서 몇 번째 데이터인지 나타내는 오프셋이다. (1, 2020xxxx41xxxx)
맵에서 키는 무시하고 값 데이터에서 연도와 기온을 추출한 뒤 출력한다. [2020, 41], [2020, 25], ...
이 출력이 리듀스 함수로 전달 되기 전에 맵리듀스 프레임워크가 키를 중심으로 값의 리스트를 만들어서 리듀스 함수로 보낸다. (2020, [41, 25, 33, 31])
리듀스 함수는 각 키마다 있는 기온 리스트의 최댓값을 추출한다.

맵 자바 파일과 리듀스 자바 파일을 각각 만든 뒤 맵리듀스 자바파일을 메인으로 해서 jar 파일을 만든다.

하나의 잡트래커와 다수의 태스크트래커가 있는데 잡트래커는 시스템 전체에서 모든 잡이 수행되도록 태스크를 스케쥴링한다.
스플릿이 작아질수록 load balancing에 좋은 효과를 내지만 너무 작으면 관리와 맵 태스크 생성을 위한 오버헤드가 커질 수 있다.
잡을 위한 적합한 분할 크기는 기본적으로는 64MB의 HDFS 블록을 사용하는 추세이다.

data locality optimization: 노드에서 맵 태스크를 실행할 때 잘 작동한다.
클러스터의 중요한 공유 자원인 네트워크 대역폭을 사용하지 않기 때문이다.
네트워크를 쓰지 않고 로컬 데이터만을 사용하도록 한다.

리듀스 태스크는 일반적으로 모든 매퍼로부터 출력을 입력으로 받기 때문에 데이터 지역성의 장점이 없다.
정렬된 맵의 결과는 리듀스 태스크가 실행 중인 노드로 네트워크를 통해 전송된다.
리듀스의 츨력에 대한 각 HDFS 블록은 첫 복제본이 로컬 노드에 저장되고 그 이외의 복제본은 out-rack에 저장된다.

컴바이너 함수
맵과 리듀스 태스크 간 데이터 전송을 최소화하기 위해 필요하다.
예를 들어 어떤 해의 최고 기온을 구하는 작업이라고 할 때 맵1에서는 (2000, 0), (2000, 10)이 나왔고 맵2에서는 (2000,5), (2000, 15), (2000, 20)가 나왔다고 하자.
컴바이너가 없는 경우는 다 맵에 전달되어 (2000, [0, 10, 5, 15, 20])에서 최댓값을 찾게 된다.
하지만 컴바이너를 거치면 미리 최댓값을 뽑은 뒤 보내도록 해서 맵에 전달되는 데이터는 (2000, [10, 20])이 된다.
하지만 항상 가능한 것은 아니고 만약 평균값을 구해야 하는 경우라면 이런 식의 컴바이너는 사용할 수 없다.
리듀서는 하나의 매퍼에게만 데이터를 받는 것이 아니다.





댓글

댓글 쓰기

이 블로그의 인기 게시물

논문 정리 - 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...
자세한 내용 보기