하둡 Technical Review(DBguid.net)

출처 :  http://www.dbguide.net/knowledge.db?cmd=view&boardUid=152535&boardConfigUid=19&boardStep=&categoryUid=574 

하둡 Technical Review

하둡은 구글의 분산파일시스템과 맵리듀스의 오픈소스 구현체이다. 2006년 아파치 검색엔진 프로젝트의 Nutch의 서브 프로젝트로 시작되었으며 창시자는 더그커팅이다. 2007년부터 야후에서는 하둡 창시자의 더그커팅과 주요 오픈소스 개발자들을 고용하면서 하둡 프로젝트에 전폭적인 지원을 하게 되었다.

- 저자 심탁길 SK C&C 부장

1. 빅데이터 소개

빅데이터 개요

빅데이터란 기존의 방식으로 저장하거나 분석하기 어려울 정도의 큰 규모의 자료를 의미한다. 일반적으로 수TB에서 수PB수준의 데이터를 빅데이터라고 말한다. 가트너의 2012년 10대 전략 기술 중에서 빅데이터와 분석기술이 각각 6위와 7위에 랭크되었을 정도로 최근에 큰 화두가 되고 있는 기술이다. 빅데이터라는 표현은 2011년에 들어와서 많이 쓰기 시작했고, 그 전에는 대용량, 대규모 데이터라는 표현을 많이 썼다. 클라우드 컴퓨팅의 붐 초창기에 클라우드에 대한 다양한 관점의 정의와 시각 차가 있었던 것처럼, 현재 빅데이터의 정의와 범위에 대해서 다양한 시각 차가 존재 한다.
시간이 지나면서 클라우드 컴퓨팅에서 Public, Private, Hybrid같은 분류 기준이 생긴 것처럼, 향후 빅데이터도 명확하고 구체화된 분류 기준과, 기술들 그리고 서비스 유형에 대해 정리가 이루어 질 것으로 보인다. 소셜네트워크, 실시간 센서 데이터, 모바일 정보, PB급 데이터웨어하우징 등 과거엔 상상할 수 없었던 엄청난 양의 데이터들이 쏟아지고 있으며, 이미 한 해 생산되는 데이터 양이 제타바이트가 넘어 섰다. 전 세계적으로 빅데이터를 통해서 성공한 기업들이 많이 생기고 있으며, 글로벌 기업들은 앞 다퉈 빅데이터 확보 및 활용 방안 마련에 나서고 있다. 이제 우리에게 빅데이터는 더 이상 선택이 아닌 필연적인 해결 과제가 되었다.

빅데이터와 하둡

빅데이터 처리 기술은 크게 분석인프라, 분석 기술, 표현 기술 등으로 분류해 볼 수 있다. 분석 기술은 데이터를 분석하는 기술과 방법？을 의미하며, 통계, 데이터마이닝, 기계학습, 자연어처리, 패？인식 등이 이에 해당한다. 
표현 기술은 일반적으로 데이터 시각화로 알려져 있으며, 분석된 데이터의 특징이나 의미를 쉽게 이해할 수 있도록 잘 표현해 주는 기술이다. 분석 인프라는 분석과 표현을 수행할 수 있도록 해주는 기반 기술과 플랫폼들이라고 할 수 있으며, 이러？ 분석 인프라는 다시 대규모 데이터를 안정적으로 수집해서 저장하는 기술, 저장된 것을 효과적이면서도 빠르게 처리할 수 있는 기술, 저장된 데이터를 다양한 방식과 용도로 사용할 수 있도록 가공하고 관리해 주는 기술 등으로 나누어 볼 수 있다. 
비즈니스인텔리전스, 데이터웨어하우징, 클라우드 컴퓨팅, 분산 데이터베이스(NoSQL), 분산 병렬처리(하둡 맵리듀스), 분산파일시스템 등이 분석 인프라에 해당하는 기술들이다. 빅데이터 얘기가 나오면 빠지지 않고 나오는 솔루션인 하둡은 빅데이터의 분석 인프라에 속하는 기술로서 대용량의 비정형 데이터를 분석하고 저장하는 데 ？이 활용되고 있다. 이미 많은 글로벌 기업들이 분석인프라 기술로 하둡을 사용하고 있으며, 하둡 자체를 솔루션화해서 사업을 하는 기업도 점점 더 늘고 있다. 그 만큼 성능과 안정성이 검증된 기술이라고 할 수 있다.

하둡이 대규모의 비정형 데이터 분석을 배치로 처리하는 데 주로 사용된다고 했는데, 실제 빅데이터 시스템을 구축한다고 하면, 비정형 분석뿐만 아니라, 데이터의 실시간 분석, 정형 데이터 처리, 다양한 분석 알고리즘, 웍 플로우(Workflow), 시각화(Visualization) 같은 기술이 필요하다. 이러한 주요 기술들 중 상당 부분은 이미 다양한 오픈소스 프로젝트의 형태로 개발이 되어서 바로 활용 가능한 수준이며 이러한 기술들의 집합을 하둡 에코시스템 또는 빅데이터 에코시스템으로 표현을 하기도 한다.

이러한 빅데이터 생태계에서 하둡의 위치는, 시스템의 운영체제로 생각해 볼 수 있다. 운영 체제만으로는 시스템을 완성하기 힘들다. 하나의 시스템을 구축하기 위해서는 운영체제 외에도 개발환경도 있어야 하고 다양한 도구와 라이브러리들도 필요하다. 이러한 다양한 도구와 라이브러리들이 하둡 에코시스템의 솔루션들이라고 할 수 있다. 지금은 하둡 자체 보다 더 강력한 솔루션으로 발전하고 있는 이러한 에코시스템 기술들을 잘 이해하고 필요 시 활용할 수 있다면, 빅데이터 처리를 위한 준비는 충분히 되었다고 할 수 있다.

2. 하둡 소개

구글 인프라

전세계에서 가장 많은 데이터를 저장하고 처리하는 기업이 있다면 구글일 것이다. 구글은 이미 2007년에 일일 데이터 처리랑이 400PB에 이르렀고, 작업 당 평균 입력 데이터 크기가 180GB 수준이었다. 180GB의 경우 하나의 디스크에서 순차적으로 데이터를읽는 데만 약 45분의 시간이 걸린다. 하지만 180GB가 1000개의 디스크에 나누어서 저장되어 있고, 각 디스크에서 동시에 병렬 로 데이터를 읽을 수 있다면 180분이라는 시간은 2~3초로 단축 될 수 있다. 서버를 구성하는 CPU,메모리의 성능이나 용량은 최근 10년간 엄청난 속도로 발전을 거듭해 왔지만, 상대적으로 디스크 IO 스피트는 과거나 지금이나 큰 차이가 없었다. 이는 모든 연산 작업의 부하 지점이 CPU나 메모리가 아닌 디스크 IO속도로 귀결 되었으며, 대용향 데이터를 빠르게 처리하기 위해서는 무엇보다는 병렬로 데이터를 읽고 쓸 수 있는 데이터 중심의 분산 컴퓨팅 시스템이 절실했다. 이러한 요구사항을 수용하기 위해서 기존의 방식이 아닌 새로운 관점의 접근과 설계가 이루어 졌으며, 과거의 방식과는 확연히 다른 급진적인 아키텍처인 비 공유(Shared Notting) 아키텍처가 탄생하게 되었다. 구글의 분산 컴퓨팅의 주요 플랫폼 기술로 구글파일시스템(GPS)과 맵리듀스(MapReduce)가 있으며, 이러한 플랫폼 기술들은 하둡 프로젝트의 롤모델이 되었다.

하둡 개요

하둡은 구글의 분산파일시스템과 맵리듀스의 오픈소스 구현체이다. 2006년 아파치 검색엔진 프로젝트의 Nutch의 서브 프로젝트로 시작되었으며 창시자는 더그커팅이다. 2007년부터 야후에서는 하둡 창시자의 더그커팅과 주요 오픈소스 개발자들을 고용하면서 하둡 프로젝트에 전폭적인 지원을 하게 되었다. 이후 야후는 검색엔진, 데이터마이닝, 등 다양한 내부 서비스에 적용을 하면서 하둡의 성능과 안정성을 지속적으로 개선하였고, 현재 약 50.000여대의 서버에서 사용 하고 있으며, 가장 큰 단일 클러스터는 4,000대 규모이다.
하둡을 구성하는 주요 데몬들은 다음과 같다.
분산 파일시스템인 HDFS의 마스터 데몬이 네임노드(Name Node)이고 슬레이브 데몬이 데이터노드(Data Node)이다. 세컨더리네임노드는 네임노드의 메타정보를 주기적으로 백업하고 병합해 주는 일을 수행한다. 맵리듀스 시스템의 마스터가 잡트랙커(JobTracker)이며 워커노드를 태스크랙커 (TaskTraker)라고 한다. 데몬들이기 때문에 한대의 서버에서 하둡의 모든 데몬들을 구동할 수 있다. 보통 개발 환경에서는 1대의 서버에서 하둡데몬들을 구동시키고 개발 및 테스트 작업을 수행한다. 특별한 경우가 아니라면 1대에서 수행한 작업은 1,000대의 서버로 구성된 클러스터에서도 문제 없이 동작하는 맵리듀스의 확장성 때문에 가능한 일이다.

[그림 5]는 서비스 환경에서 하둡 클러스터를 구성하는 일반적인 예이다. 주요 마스터 데몬들인 네임노드와 세컨더리 네임노드, 그리고 잡트랙커는 서로 다른 서버나 Rack에 구성을 한다. 그리고 데이터노드와 태스크트랙커는 맵리듀스 작업 수행 시 데이터 지역성(Data Locality)을 보장하기 위해서 같은 물리 서버에서 구동을 한다. 하둡에서 Rack은 물리적인 개념이 아닌 운영자가 데이터 관리를 안전하고 효율적으로 하기 위한 논리적인 개념이다. 즉 하나의 물리적인 스위치에 할당된 IP 대역을 기준으로 Rack을 구성할 수 있다. 같은 스위치 내에서도 IP 대역을 일부 분리하여 논리적인 Rack을 만들 수 있다. 그래서 이러한 Rack Aware 기능을 이용하여 효율적인 데이터 관리와 장애 대응이 가능하다.

3. 하둡 분산파일시스템(HDFS)

HDFS 개요

HDFS는 PB이상의 데이터를 저장할 수 있는 Scalable한 분산 파일시스템이다. 하둡 프로젝트의 최대 스폰서인 야후에서는 4,000여대의 서버로 단일 HDFS 클러스터를 구성하여 수PB 이상의 데이터를 저장 관리하고 있다.
HDFS는 고가의 서버가 아닌 범용 x86서버와 서버당 다수의 로컬 디스크를 사용하여 파일시스템을 구성한다. 하나의 파일은 고정된 크기의 다수의 블록들로 나누어서 저장이 되며, 각 블록은 3중 복제 되어 여러 대의 서버에 분산 저장이 된다. 파일이 블록 단위로 저장이 되기 때문에 저장 할 수 있는 파일 한 개의 크기는 이론적으로 제한이 없다. 필자의 경우 TB 수준의 파일을 HDFS에 저장해서 사용을 해 왔다. 블록들이 클러스터를 구성하는 전체 노드에 그리고 전체 디스크에 고르게 분산되어 저장 되기 때문에, 디스크 IO 성능이 중요한 맵리듀스 같은 데이터 중심에 병렬 처리 연산에 최적화된 파일 시스템이라고 할 수 있다. 다만 POSIX를 완전히 지원하지 않기 때문에 무작위 쓰기(Random Write)가 필요한 DBMS같은 응용 애플리케이션은 적합하지 않다. 

주로 파일 같은 유형의 데이터를 저장하는 데 많이 사용된다. HDFS는 [그림 6]과 같이 마스터 데몬인 네임노드, 세컨더리 네임노드, 그리고 다수의 데이터노드들로 구성된다. 네임노드는 파일시스템의 네임스페이스(디렉토리 구조, 파일명, 파일별 블록 목록, 블록 별 데이터 노드 목록 등)를 관리하면서 클라이언트의 파일 접근 요청을 처리한다. 또한 데이터 노드들이 살아 있는지를 주기적으로 점검하면서 특정 데이터 노드 장애 시 블록 복구 작업을 지시한다. 세컨더리 네임노드는 네임노드의 네임스페이스 정보와 파일시스템 커밋로그를 주기적으로 백업을 받아서 병합하는 작업을 수행한다. 즉 특정 시점의 네임스페이스 정보를 보관하는 백업 기능뿐만 아니라, 커밋로그의 내용을 네임스페이스 정보에 반영하여 새로운 스냅샷을 생성하는 체크포인팅 기능도 수행한다. 데이터노드는 로컬파일시스템에 실제 데이터 블록 목록들을 저장/관리한다. 최초 구동 시 자신이 가지고 있는 모든 블록 목록들을 네임노드에게 보내며, 네임노드는 이 블록 정보들을 기반으로 네임스페이스를 최신 정보로 업데이트한다.

HDFS IO 동작 방식

HDHS에서 하나의 파일 (/foo/bar)을 읽는 과정을 살펴보자.
- HDFS에서 파일 입출력은 DFSCilent라는 객체를 통해서 수행되며 DFSCilent은 네임노드에게 /foo/bar/라는 파일의 네임스페이스정보를 요청한다.
- 네임노드는 /foo/bar 파일에 대한 블록 정보를(파일은 어떤 블록들로 구정되어 있는지, 각 블록은 어떤 데이터노드에 저장되어 있는 지 등) DFSCilent는 블록들이 저장된 데이터노드에 직접 접속을 해서 테이터를 순차적으로 읽는다. 기본적으로 블록들은 3대의 데이터노드에 3중 복제된다. 따라서 각 블록 별로 하나의 데이터노드를 선택해서 접속을 해야 하는데 여기에는 규칙이 있다. DFSCilent가 데이터노드와 같은 서버에 있으면 데이터 지역성(Data Loclity) 원칙에 의해 로컬 데이터노드를 선택한다. 그 다음에는 동일한 Rack인지 여부를 확인하고, 아닐 경우에는 무작위로 데이터노드를 선택한다.

단일 사용자가 파일을 읽을 경우,파일을 구성하는 블록의 개수만큼 차례로 다른 데이터노드에 접속을 해서 블록을 읽어야 하는 데, 이런 오버헤드 때문에 단일 응답속도는 일반적인 NAS나 SAN에 비해 떨어진다. 반면 많은 다수의 사용자가 동시에 파일을 읽거나 쓸 경우 IO작업은 하둡 클러스터 전체 서버에 분산 되며, 각 서버 내에서도 다수의 디스크에 분산되기 때문에 아주 높은 Throughput을 낼 수 있다. 필자의 경우 몇 년 전 수행한 프로젝트에서 23대의 x86서버들로 하둡 클러스터를 구성하여 40Gbps의 동영상 다운로드 트래픽을 안정적으로 처리한 경험이 있다. 하둡 같은 분산파일시스템은 클러스터를 구성하는 서버들의 모든 네트워크 대역폭과 디스크 성능을 최대한 활용하는 아키텍처이기 때문에 가능했다. HDFS의 파일 쓰기 과정도 읽기와 유사하며 특별한 설정이 없으면 블록은 3중 복제를 한다. 읽기와 마찬가지로 DFSCilent는 네임노드에게 File.txt라는 파일 쓰기 요청을 하고 각 블록 별로 저장할 데이터노드들을 반환 받는다. 그러면 DFSCilnet는 첫 번째 데이터노드에 블록을 전송하며, 척 번째 데이터노드는 파이프라이닝 방식으로 두 번째 데이터노드에게,두 번째는 다시 세 번째에게 블록을 전송한다. 척 번째 데이터노드는 블록 복제 과정에서 일종의 마스터 역할을 수행하며, 파이프라이닝 상의 데이터노드들로 데이터 전송이 완료되면 DFSClient 에게 해당 데이터 전송이 완료 되었다는 것을 알려준다. HDFS예 파일을 쓸 ？에도 파일을 읽을 때와 마찬가지로 정책이 있다. 3중 복제라고 가정 했을때, 첫 번째 블록은 HDSClient가 실행되는 같은 서버의 데이터노드에 저장이 된다. 두 번째 블록은 다른 Rack의 임의의 데이터노드에 저장이 되며, 세 번째 블록은 같은 Rack의 다른 데이터노드에 저장이 된다. 그래서 HDFS를 구성하는 특정 서버가 중단 되도 심지어 Rack 전체 장애가 생겨도 사용자에게는 정상적인 파일 서비스를 제공할 수 있다.

4. 하둡 맵리듀스(MapReduce)

맵리듀스 개요

구글에 의해 고안된 맵리듀스는 함수형 프로그래밍 언어인 LISP을 모델로 하여 맵과 리듀스라는 2개의 함수를 이용하여 대용량 데이터를 쉽고 빠르게 처리할 수 있는 방법론이다. 하둡 맵리듀스는 구글 맵리듀스의 소프트웨어 구현체이며 현재 빅데이터 처리를 위한 분산컴퓨팅 플랫폼의 실질적인 업계 표준이 되었다.
하둡 맵리듀스가 제공하는 주요 기능은 다음과 같다. - 대용량 데이터를 쉽게 처리할 수 있는 방법론과 프레임워크 제공 ？번에 수GB에서 수PB수준의 데이터 처리가 가능 - 작업 수행 시 데이터 지역성을 보장하여 네트워크 트래픽 발생 최소화 데이터가 있는 곳에서 프로세스가 실행 될 수 있도록 스케쥴링 


- 장애에 대？ 고립 및 자동 복구 장애가 발생하여도 데이터 복제본이 있는 다른 서버(데이터노드)에서 해당 태스크？ 재 시작하여 작업 중단 없이 처리를 계속할 수 있음 
- 선형적인 확장성 노드를 손 쉽게 추가하거나 줄일 수 있으며, 노드 추가 시 성능도 선형적으로 확장 
- 사용자는 오직 핵심 로직만 개발하면 됨 애플리케이션 개발 시 장애 처리에 대한 고민을 제거함 높았던 분산 컴퓨팅의 진입 장벽을 낮추어서 분산 컴퓨팅의 대중화를 이룸처리 모델로 MPI(Massage Passing Interface)가 있다. 
하나의 작업을 여러 개의 태스크로 쪼면서 연산 작업을 수행하는 방식이다. MPI 방식은 프로그래밍 자체도 어려웠지만, 프로그램을 개발해서 하나의 연산 작업을 실행할 때, 연산 도중에 발생할 수 있는 장애나 오류가 발생하면 처음부터 다시 작업을 실행해야만 했다. 사용자가 장애 상황에 대한 대비책까지도 미리 염두에 두고 작업을 실행해야만 했기 때문에 생산성과 효율성도 좋지 못했다. 반면에 맵리듀스는 어렵고 복잡했던 분산 컴퓨팅을 개념만 이해하면 누구든지 사용할 수 있도록 해주었다. 개념을 이해한 상태에서 맵과 리듀스 함수에서 어떤 로직으로 데이터를 처리할 지 고민만 하면 된다. 작업 도중 특정 태스크나 서버에 장애가 생겨도 신경 쓸 필요가 없다. 플랫폼에서 자동적으로 복구해서 재 실행을 해주기 때문이다. 클러스터를 1대의 서버로 구성하던지 1,000대의 서버로 구성하던지 동일하게 동작하며, 실행 프로그램과 데이터를 어떻게 클러스터 내에 배포 할지 고민할 필요도 없다. 하둡 맵리듀스는 높았던 분산 컴퓨팅의 문턱을 낮추어서 누구든지 사용할 수 있도록 해준 플랫폼이라고 할 수 있다.

맵리듀스 개념

하둡 맵리듀스의 개념을 살표보자. 하나의 맵리듀스 작업을 실행했을 때, 입력 데이터는 HDFS상의 파일이 될 수도 있고 DB의 레코드들이 될 수도 있다. 어떤 입력 데이터이던지 맵 함수의 입력으로는 키(k1)와 값(v1)의 형태로 들어오게 되는 데 사용자는 맵 함수 내의 입력 데이터인 k1과 v1을 어떻게 처리해서 내보낼지(k2, v2) 생각을 하면 되고 그 로직을 맵 함수 내에 작성을 하면 된다. 사용자가 처리한 맵 함수의 출력 키(k2)와 값(v2)은 로컬 디스크에 키를 기준으로 정렬이 되어서 저장이 된다. 모든 맵 처리 단계가 끝나면 하둡 프레임워크는 여러 서버들의 맵의 출력물을 네트워크로 읽어와 합병 정렬 하여 리듀스 함수로 보낸다. 그러면 리듀스 함수에서는 맵 함수의 출력 키를 중심으로 groupby 정렬 된 형태인 키(k2)와 값(v2)의 리스트 형태로 입력이 들어온다. 리듀스 함수내의 입력 데이터를 어떻게 처리할 지 생각을 하고 로직을 작성하여 최종적으로 원하는 결과 값을 만들 수 있다. 리듀스의 결과 값은 HDFS에 저장하며, 원할 경우 데이터베이스나 다른 파일시스템에도 저장할 수 있다.

맵리듀스 태스크 흐름

맵리듀스를 태스크 처리 관점에서 살펴보면 하나의 큰 파일은 HDFS에 저장될 때 고정된 크기 (64MB가 기본)의 여러 개의 블록들로 나누어서 다수의 서버 (데이터노드)에 중복 저장된다. 이 큰 파일을 입력데이터로 하여 맵리듀스 작업을 실행하면, 나누어진 블록들의 개수만큼 맵태스크가 생성이 되며, 각 블록은 맵 태스크가 생성이 되며, 각 블록은 맵태스크의 입력 데이터가 된다. 맵태스크에서는 블록을 라인단위로 읽어서 맵함수의 입력으로 보낸다. 이 라인 단위의 키와 값은 사용자가 작성한 로직에 의해 처리된 후 , 파티셔너(기본은 해쉬파티션)라는 몇 번째 리듀스 태스크로 보낼 지 결정해 주는 함수에 의해 계산되어 로컬 임시파일(파티션 파일)로 저장된다. 맵함수의 출력 키가 같으면 반드시 같은 파티션 파일로 보내지고, 키가 다를 경우에는 같은 파티션이 될 수도 안될 수도 있다. 맵태스크는 이러한 동작을 자신에게 할당된 입력 블록의 맵태스크는 과정이 끝나면 리듀스의 개수만큼 정렬된 파티션들이 중간 결과로 생성이 되며, 해당 파티션 파일들은 자신들이 가야 할 리듀스 태스크가 실행 된 서버로 네트워크 전송이 된다. 그런 다음 네트워크로 전송된 중간 파티션 파일들은 병합되고 정렬이 되어서 리듀스 태스크의 입력데이터로 들어간다. 그러면 리듀스 태스크는 사용자가 작성한 리듀스 함수를 반복적으로 호출하여서 입력 데이터를 처리를 하여, 최종 결과 값을 HDFS에 기록한다.

맵리듀스 시스템 동작 방식

하둡 맵리듀스의 동작 방식을 데몬 관점에서 살펴보도록 하자. [그림 10]처럼 잡트랙커가 맵리듀스 시스템의 마스터 역할을 하며 클라이언트로부터 맵리듀스 작업의 실행 요청을 받고 작업을 여러 개의 태스크로 나누어서 할당하는 스케쥴링을 한다. 그 각 작업 별 진척 사항을 관리하면서 장애 발생 시 다른 노드에게 태스크를 할당하는 식으로 장애 복구를 수행한다. 태스크트랙커는 맵리듀스의 워커역할을 한다. 먼저 맵리듀스 작업을 실행할 수 있도록 실행파일(job.jar)과 설정파일(job.xml)을 HDFS로부터 복사해서 클래스 경로에 등록하는 작업을 수행한다. 그 다음에 태스크런너라라는 쓰레드를 생성하여 새로운 자바가상머신(JVM)을 포크(fork)하여 맵이나 리듀스 태스크를 실행한다.

맵리듀스 작업을 실행하는 과정을 몇 단계로 나누어서 살펴보자

1단계: 맵리듀스 작업 실행 요청

클라이언트는 분석 하고자 하는 대상 데이터를 HDFS에 업로드 하고, JobClient라는 MapReduce 클라이언트 API를 이용하여 구동(Driver) 프로그램을 만들어 실행 한다.
구동프로그램이 실행되면 JobClient는 HDFS상의 사용자의 입력 데이터의 크기, 입/출력 경로 등을 확인하는 작업을 내부적으로 수행하고, 확인한 입력 데이터를 기준으로 맵태스크의 입력 단위인 Split정보들을 만든다. 입력 데이터가 파일일 경우 하나의 Split정보에는 시작과 끝 지점의 주소가 계산이 되며, 보통 큰 파일이 입력 데이터일 경우 파일을 구성하는 블록(64MB)이 Split 단위가 된다. 그리고 이 Split이 개별 맵태스크의 입력 데이터가 된다. Split 계산 작업이 끝나면 계산된 Split정보와 함께 실행할 바이너리(Job.jar)와 설정 정보(Job.xml)를 HDFS에 업로드를 한다. 클라이언트에서 할 준비 작업은 다 끝난 셈이다. 그런 다음에는 잡트랙커에게 실질적인 맵리듀스 작업을 수행해 달라는 요청을 보낸다.

2단계: 맵리듀스 작업 스케쥴링

클라이언트로부터 작업 실행 요청을 받은 잡트랙커는 먼저 스케쥴링을 위해서 JobQueue에 새로 운 작업을 등록한다. 그런 다음 HDFS에 저장된 Job실행 파일들(job.xml과 split정보)을 읽어서 각 작업 별로 수행할 맵과 리듀스 태스크 정보들을 JobQueue에 등록한다.

3단계: 태스크 할당 및 실행

태스크트랙커는 수 초 간격으로 주기적으로 잡트랙커에게 heartbeat 메시지를 보내면서 살아 있음을 알리고 동시에 자신이 수행 할 태스크가 있는 지 물어본다.
잡 트랙커는 태스크트랙커당 수행할 수 있는 최대 용량(하둡에서는 이것을 slot이라고 표현하는 데 태스크트랙커 데몬을 구동할 때 동시에 실행할 수 있는 최대 태스크 개수를 설정할 수 있다. 기본은 맵태스크 2개, 리듀스태스크 2개가 최대 수행 용량이 된다)과 수행 중인 태스크를 관리하면서 새로운 태스크를 배정한다. 이 때 데이터 지역성을 고려해서 처리해야 할 블록이 로컬에 있는 태스크 트랙커에게 맵태스크를 할당한다. 예를 들면 BigData라는 파일 하나를 처리하는 것을 가정해보자. BigDat3는 4개의 블록들(각 블록을 1, 2, 3, 4라고 하자)로 나누어서 HDFS에 저장이 되며, 2번 블록은 T1 태스크 트랙커가 구동된 물리서버에 있다. 이 경우 잡트랙커는 2번 블록을 T1 트랙커가 처리해야 할 태스크의 입력으로 지가 heartbeat을 보냈을 때 2번 블록을 처리하라는 명령을 응답 메시지로 보낸다. T1 태스크 트랙커는 응답 메시지를 보고 새로운 자식 JVM 프로세스를 fork하여 맵 또는 리듀스 태스크를 수행한다.

5. 맺음말

2006년 이후 하둡은 성능과 안정성이 비약적으로 발전하면서 분산컴퓨팅 분야의 업계 표준이 되었다. 그리고 하둡으로 처리 할 수 없는 빅데이터의 수 많은 요구 사항을 충족하기 위하여 다양한 하둡 연관 프로젝트들이 시작 되었고, 이러한 연관 프로젝트들 또한 지속적인 발전을 거듭하여 하둡 자체보다 훨씬 더 막강한 빅데이터 생태계를 형성하였다. 하지만 최근 하둡은 이러한 시대적인 조류에 편승하지 못한 채 한동안 정체 상태인 적이 있었다. 이해 관계로 인하여 1년 가까이 프로젝트 코드 개선 및 반영이 이루어지지 않았다. 최슨 하둡 프로젝트에서는 호튼웍스와(야후의 하둡 개발 및 운영팀이 분사하여 창업한 회사) 클라우데라(최초의 하둡 전문 회사)를 중심으로 새로운 도약을 시도하고 있다. 이러한 새로운 도약은 하둡의 다음 버전인 0.23에서(2011년 말 현재 Stable 버전은 0.20.203임) 반영 될 것이다. 다음은 하둡 0.23에서 선보일 주요 기능들이다. 

- 마스터 고 가용성 . 주요 마스터 데몬들인 네임노드와 잡트랙커를 Active
-Standby 구조로 전환 - 확장성 증대 . 단일 클러스터의 최대 수용 서버 대수가 현재 4,000대 수준인데 10,000대 규모 수용
(야후에서 2012년 초 테스트 및 검증 예정) . 
단일 네임노드에서 분산 네임노드 방식으로 변경하여 메타데이터 제약성 극복 
- 다양？ 병렬 처리 모델 수용 . MapReduce 2.0(Yarn)이라도 불리며, MapReduce 뿐만 아니라 Pregel, MPI 같은 다양？ 분산 병렬 처리 기법을 수용할 수 있는 아키텍처로 발전 - 유지보수성 개선 . 하둡의 버전이 다를 경우 서로 호환되지 않은 문제 해결. 단일 클러스터에서 다중 하둡 버전을 동시에 사용 가능 앞으로도 하둡과 생태계가 지속적으로 발전하여, 빅데이터로부터 다양？ 비즈니스 가치를 발굴하는 데 하둡이 중요한 역할을 할 수 있기를 바란다.

출처 :한국데이터베이스진흥원

제공 : DB포탈사이트 DBguide.net