오픈소스 프레임워크 정리(YARN, HDFS, MapReduce)
MapReduce
특징
페타바이트 이상의 대용량 데이터를 신뢰도가 낮은 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기 위해 개발되었다.
맵리듀스 작업이 시작될 때 HDFS에서 데이터를 갖고 오고 작업이 끝나면 HDFS에 데이터를 쓴다.
2 phases: map & reduce. 그 사이에 sort와 shuffle이 있다.
맵과 리듀스의 input, output은 기본적으로 key, value 쌍이다.
슬롯이라는 개념으로 클러스터에서 실행할 수 있는 태스크 갯수를 관리한다. 맵 슬롯과 리듀스 슬롯이 있다.
맵리듀스 클러스터 안에서 모든 기능이 다 수행되므로 컴퓨팅에 필요한 리소스 상태(각 서버의 상태)는 맵리듀스의 마스터 서버 역할인 잡트래커에 의해 관리됐다.
구조
잡트래커:
클러스터 자원 관리와 애플리케이션 라이프 사이클 관리라는 두 가지 핵심 기능을 수행한다.
클라이언트가 job을 잡트래커에게 보내면 잡트래커는 노드들에게 맵과 리듀스 태스크를 할당한다.
태스크트래커:
각 슬레이브 서버마다 하나의 데몬이 실행된다.
태스크를 할당 받은 노드들은 태스크트래커라는 데몬에 의해 각각 실행되는데 태스크트래커가 태스크를 인스턴스화하고 진행 상황을 잡트래커에 보고한다.
태스크를 실행할 때 태스크트래커의 쓰레드를 쓰는 것이 아니라 별도의 프로세스로 fork시켜서 실행한다.
태스크가 종료될 때 마다 태스크트래커는 잡트래커로부터 자기에게 할당된 다음 태스크를 가져와서 실행한다.
장점
단점
Single Point of Failure: 잡트래커가 돌아가고 있지 않으면 맵리듀스 잡 실행이 불가능하다.
잡트래커에는 전체 잡의 실행 정보를 유지해야하므로 힙 메모리도 여유있게 할당해줘야하는데 메모리가 부족하면 모니터링 할 수도 없고 새로운 잡의 실행을 요청할 수도 없다.(SPOF와 일맥상통)
맵 슬롯과 리듀스 슬롯 중 하나만 사용할 때는 다른 하나가 잉여 자원이 되기에 리소스 낭비이다.
클러스터 확장성이 제한적이다.
컴퓨팅 리소스 상태가 잡트래커에 의해 관리되기 때문에 다른 컴퓨팅 클러스터와는 연동하기 어렵다.
사용사례
Yarn
특징
기존의 맵리듀스 중에서 클러스터 리소스를 관리하는 부분만 가져와서 다른 서비스에서도 사용 가능하도록 구성한 시스템이다.
큐를 이용해 자원을 나누고 큐마다 별도로 스케줄링한다.
하둡의 잡트래커의 기능을 resourceManager와 applicationMaster가 대신하고 태스크트래커의 기능은 nodeManager가 대신했다.
기존 맵리듀스는 맵 슬롯과 리듀스 슬롯이라는 개념으로 자원을 관리했지만 얀은 리소스매니저로 cpu, memory, disk, network 등 실제 가용한 단위로 자원를 관리하고 배분한다.
태스크트래커가 태스크 단위로 잡을 실행했다면 노드매니저는 컨테이너 단위로 애플리케이션을 실행하고 각 상태를 스케쥴링한다.
구조
각각의 컴퓨팅 클러스터를 application이라고 한다.
resourceManager:
얀 클러스터의 마스터 서버로, 클러스터에 한 개 혹은 이중화를 위해 두 개 존재하며 클러스터의 전반적인 자원 관리를 하고 scheduler와 application manager를 조정한다.
클러스터 내의 노드 매니저들과 통신을 해서 할당된 자원과 사용중인 자원을 확인한다.
applicationMaster:
하나의 애플리케이션을 관리하는 마스터 서버이다.
클라이언트가 얀에 애플리케이션 실행을 요청하면 얀은 하나의 애플리케이션에 하나의 applicationMaster를 할당한다.
애플리케이션에 필요한 리소스를 스케쥴링하고 노드매니저에 애플리케이션이 필요한 컨테이너를 실행할 것을 요청한다.
nodeManager:
얀 클러스터의 worker 서버로, 맵리듀스의 태스크 트래커의 기능을 담당하고 resourceManager를 제외한 모든 서버에 실행된다.
사용자가 요청한 프로그램을 실행하는 컨테이너를 fork시키고 컨테이너의 라이프 사이클을 모니터링한다.
장점
단점
사용사례
YARN이 없을 때,
100대의 서버에 맵리듀스도 쓰고 스파크도 쓴다. 만약 50대에 맵리듀스 설치하고 50대에 스파크를 설치한다면 둘 중 하나의 작업만 할 때는 나머지 50대의 서버가 낭비된다.
100대에 둘 다 설치하는데 메모리를 분리 안하면 동시에 두 작업이 같은 메모리에서 일어날 때 작업 fail, 만약 메모리를 반반씩 나누면 낭비되는 메모리 생길 수 있다.
YARN이 있을 때,
100대의 서버에 얀만 설치한다. 맵리듀스 작업이 시작되면 100대의 서버 모두 활용해서 작업을 실행한다. 그러다가 스파크 작업이 할당되면 얀은 50대의 서버에서 실행되던 맵리듀스 태스크를 강제종료하고 스파크 작업에 리소스를 할당한다.
이렇게 유연하게 리소스를 할당할 수 있는 것은 얀의 스케쥴러 때문이다. FIFO, Capacity, Fair 스케쥴러가 있다.
HDFS
특징
수십 테라바이트 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고 그 저장된 데이터를 빠르게 처리할 수 있게 하는 파일시스템이다.
HDFS에 파일이 저장될 때 실제 로우데이터 하나가 저장되고, 또 체크섬이나 파일 생성일자 같은 메타데이터가 저장된 파일이 저장된다.
네임노드가 사라질 것을 대비하여 editslog와 fsimage라는 두 개의 파일을 생성한다.
editslog는 HDFS의 모든 변경 이력을 저장한다.
fsimage는 메모리에 저장된 메타데이터의 파일 시스템 이미지를 저장한 파일이다.
editslog가 커지면 fsimage를 만드는 시간이 오래 걸리므로 Secondary Namenode가 있다.
세컨더리네임노드는 체크포인트라는 작업을 통해 fsimage를 갱신해준다. 네임노드를 백업하는 것이 아니라 단순히 fsimage를 줄여주는 역할만 한다. fsimage가 너무 커서 네임노드가 메모리에 로딩되지 못하는 경우를 예방하기 위함이다.
한번 저장된 데이터는 읽기만 가능하게 하여 데이터 무결성을 유지한다. 이동, 삭제, 복사만 가능하다.
하둡 2.x 기준으로 블록 사이즈가 128MB로 크게 함으로써 seek time을 감소시키고 네임노드가 유지하는 메타데이터의 크기를 감소시킬 수 있다.
블록을 저장할 때 기본적으로 3개씩 블록의 복제본을 저장한다.
구조
네임노드:
메타데이터를 관리하고 데이터노드를 모니터링한다.
장애가 발생한 데이터노드의 블록을 새로운 데이터노드에 복제한다.
클라이언트의 요청을 접수한다.
데이터노드:
클라이언트가 저장하려는 데이터를 로컬디스크에 유지한다.(메타데이터와 로우데이터)
장점
단점
사용사례
특징
페타바이트 이상의 대용량 데이터를 신뢰도가 낮은 컴퓨터로 구성된 클러스터 환경에서 병렬 처리를 지원하기 위해 개발되었다.
맵리듀스 작업이 시작될 때 HDFS에서 데이터를 갖고 오고 작업이 끝나면 HDFS에 데이터를 쓴다.
2 phases: map & reduce. 그 사이에 sort와 shuffle이 있다.
맵과 리듀스의 input, output은 기본적으로 key, value 쌍이다.
슬롯이라는 개념으로 클러스터에서 실행할 수 있는 태스크 갯수를 관리한다. 맵 슬롯과 리듀스 슬롯이 있다.
맵리듀스 클러스터 안에서 모든 기능이 다 수행되므로 컴퓨팅에 필요한 리소스 상태(각 서버의 상태)는 맵리듀스의 마스터 서버 역할인 잡트래커에 의해 관리됐다.
구조
잡트래커:
클러스터 자원 관리와 애플리케이션 라이프 사이클 관리라는 두 가지 핵심 기능을 수행한다.
클라이언트가 job을 잡트래커에게 보내면 잡트래커는 노드들에게 맵과 리듀스 태스크를 할당한다.
태스크트래커:
각 슬레이브 서버마다 하나의 데몬이 실행된다.
태스크를 할당 받은 노드들은 태스크트래커라는 데몬에 의해 각각 실행되는데 태스크트래커가 태스크를 인스턴스화하고 진행 상황을 잡트래커에 보고한다.
태스크를 실행할 때 태스크트래커의 쓰레드를 쓰는 것이 아니라 별도의 프로세스로 fork시켜서 실행한다.
태스크가 종료될 때 마다 태스크트래커는 잡트래커로부터 자기에게 할당된 다음 태스크를 가져와서 실행한다.
장점
단점
Single Point of Failure: 잡트래커가 돌아가고 있지 않으면 맵리듀스 잡 실행이 불가능하다.
잡트래커에는 전체 잡의 실행 정보를 유지해야하므로 힙 메모리도 여유있게 할당해줘야하는데 메모리가 부족하면 모니터링 할 수도 없고 새로운 잡의 실행을 요청할 수도 없다.(SPOF와 일맥상통)
맵 슬롯과 리듀스 슬롯 중 하나만 사용할 때는 다른 하나가 잉여 자원이 되기에 리소스 낭비이다.
클러스터 확장성이 제한적이다.
컴퓨팅 리소스 상태가 잡트래커에 의해 관리되기 때문에 다른 컴퓨팅 클러스터와는 연동하기 어렵다.
사용사례
Yarn
특징
기존의 맵리듀스 중에서 클러스터 리소스를 관리하는 부분만 가져와서 다른 서비스에서도 사용 가능하도록 구성한 시스템이다.
큐를 이용해 자원을 나누고 큐마다 별도로 스케줄링한다.
하둡의 잡트래커의 기능을 resourceManager와 applicationMaster가 대신하고 태스크트래커의 기능은 nodeManager가 대신했다.
기존 맵리듀스는 맵 슬롯과 리듀스 슬롯이라는 개념으로 자원을 관리했지만 얀은 리소스매니저로 cpu, memory, disk, network 등 실제 가용한 단위로 자원를 관리하고 배분한다.
태스크트래커가 태스크 단위로 잡을 실행했다면 노드매니저는 컨테이너 단위로 애플리케이션을 실행하고 각 상태를 스케쥴링한다.
구조
각각의 컴퓨팅 클러스터를 application이라고 한다.
resourceManager:
얀 클러스터의 마스터 서버로, 클러스터에 한 개 혹은 이중화를 위해 두 개 존재하며 클러스터의 전반적인 자원 관리를 하고 scheduler와 application manager를 조정한다.
클러스터 내의 노드 매니저들과 통신을 해서 할당된 자원과 사용중인 자원을 확인한다.
applicationMaster:
하나의 애플리케이션을 관리하는 마스터 서버이다.
클라이언트가 얀에 애플리케이션 실행을 요청하면 얀은 하나의 애플리케이션에 하나의 applicationMaster를 할당한다.
애플리케이션에 필요한 리소스를 스케쥴링하고 노드매니저에 애플리케이션이 필요한 컨테이너를 실행할 것을 요청한다.
nodeManager:
얀 클러스터의 worker 서버로, 맵리듀스의 태스크 트래커의 기능을 담당하고 resourceManager를 제외한 모든 서버에 실행된다.
사용자가 요청한 프로그램을 실행하는 컨테이너를 fork시키고 컨테이너의 라이프 사이클을 모니터링한다.
장점
단점
사용사례
YARN이 없을 때,
100대의 서버에 맵리듀스도 쓰고 스파크도 쓴다. 만약 50대에 맵리듀스 설치하고 50대에 스파크를 설치한다면 둘 중 하나의 작업만 할 때는 나머지 50대의 서버가 낭비된다.
100대에 둘 다 설치하는데 메모리를 분리 안하면 동시에 두 작업이 같은 메모리에서 일어날 때 작업 fail, 만약 메모리를 반반씩 나누면 낭비되는 메모리 생길 수 있다.
YARN이 있을 때,
100대의 서버에 얀만 설치한다. 맵리듀스 작업이 시작되면 100대의 서버 모두 활용해서 작업을 실행한다. 그러다가 스파크 작업이 할당되면 얀은 50대의 서버에서 실행되던 맵리듀스 태스크를 강제종료하고 스파크 작업에 리소스를 할당한다.
이렇게 유연하게 리소스를 할당할 수 있는 것은 얀의 스케쥴러 때문이다. FIFO, Capacity, Fair 스케쥴러가 있다.
HDFS
특징
수십 테라바이트 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고 그 저장된 데이터를 빠르게 처리할 수 있게 하는 파일시스템이다.
HDFS에 파일이 저장될 때 실제 로우데이터 하나가 저장되고, 또 체크섬이나 파일 생성일자 같은 메타데이터가 저장된 파일이 저장된다.
네임노드가 사라질 것을 대비하여 editslog와 fsimage라는 두 개의 파일을 생성한다.
editslog는 HDFS의 모든 변경 이력을 저장한다.
fsimage는 메모리에 저장된 메타데이터의 파일 시스템 이미지를 저장한 파일이다.
editslog가 커지면 fsimage를 만드는 시간이 오래 걸리므로 Secondary Namenode가 있다.
세컨더리네임노드는 체크포인트라는 작업을 통해 fsimage를 갱신해준다. 네임노드를 백업하는 것이 아니라 단순히 fsimage를 줄여주는 역할만 한다. fsimage가 너무 커서 네임노드가 메모리에 로딩되지 못하는 경우를 예방하기 위함이다.
한번 저장된 데이터는 읽기만 가능하게 하여 데이터 무결성을 유지한다. 이동, 삭제, 복사만 가능하다.
하둡 2.x 기준으로 블록 사이즈가 128MB로 크게 함으로써 seek time을 감소시키고 네임노드가 유지하는 메타데이터의 크기를 감소시킬 수 있다.
블록을 저장할 때 기본적으로 3개씩 블록의 복제본을 저장한다.
구조
네임노드:
메타데이터를 관리하고 데이터노드를 모니터링한다.
장애가 발생한 데이터노드의 블록을 새로운 데이터노드에 복제한다.
클라이언트의 요청을 접수한다.
데이터노드:
클라이언트가 저장하려는 데이터를 로컬디스크에 유지한다.(메타데이터와 로우데이터)
장점
단점
사용사례
댓글
댓글 쓰기