CS 전공/리뷰2012.06.11 08:28

근래 KAIST에서 수행하는 연구 중에는  Hadoop을 이용한 비정형데이터 처리가 있다.

그래서 작게나마 9대의 PC들을 가지고 연구실에서 Hadoop cluster를 구축하였다.

1대는 이미 실험실에 존재하던 서버로 이를 Name node로 설정하였고

나머지 8대는 새로 구입한 것으로 i5 quadcore CPU + 8GB 메모리, 1TB 7200RPM HDD와 256GB SSD를 탑재한 것이다.  이들은 data node로 설정하였다. 그리고 이들 모두를 Gigabit switching hub로 연결하였다.


수행하다보니 꼭 reduce task 에서 임의로 노드들의 eth0 네트워크 인터페이스가 죽어버리는 

현상을 경험하였다. 처음엔 Hadoop 세팅 자체의 문제이거나 ulimit 등의 사소한 문제로 생각하였으나 아니었다. 

 수차례의 닭질 끝에 결국엔 Cent0S에 제공하는 Realtek 네트워크 드라이버가 2.x대로

현재의 8.0대에 비해 현저히 버전이 낮은 상태였고, 옛날 버전의 드라이버가 무언가 문제를 일으킨

것을 찾아내었다.


이것을 파악한 것은 나중의 일이고, 처음엔 이것저것 테스트해보았다. 그중에는 스위칭허브를 100Mbps로 교체해 본 일도 포함되었다. 그런데 교체해보니 느리지만 reduce가 죽어서 100% 완료에 도달못하는 문제는 사라졌다. 

해서 이번에는 네트워크 드라이버들을 모두 업그레이드를 하고,  100Mbps와 1Gigabit switching hub를 교체해서 달아보면서 네트워크 성능이 어떻게 M/R job의 성능에 영향을 미치는지 간단히 측정해 보았다. 물론 이것은 어떠한 데이터를 가지고 어떠한 작업을 수행하느냐에 따라 크게 달라질 것이다.

필자의 데이터는 text 포맷이고, M/R job은 간단히 언급하자면, text에서 유일한 token들을 추리고,

이들이 전체 데이터에서 얼마나 반복되어 나타나는지 count하여, 원 text와 같이 출력하는 일이다.


실험 결과는: 

--------

11GB 데이터 적재 시

1 Gigabit : 222.449s

100Mbps: 1,369.204s 

으로 약 6.15배 차이 


11GB에  M/R 작업 수행 시

1 Gigabit : 3분 48초

100Mbps : 9분 11초

 으로 약 2.41배 차이


를 보여주었다.


이를 Amdahl's law(http://bart7449.tistory.com/244에 대입시켜 보면, 

data loading의 경우 1/( (1-p) + p/10 ) = 6.15 이고

p ~= 0.93 


M/R 작업 수행 시의 경우를 보면,

1 / ( (1-p) + p /10 ) = 2.41 

p ~= 0.65

이라는 결과가 나온다. 


즉, 데이터 로딩의 경우 네트워크가 Hadoop 시스템에서 차지하는 비율이 약 93% 에 이르고, 

M/R 작업의 경우에는 그 비율이 낮아지지만 그래도 과반이 넘는 약 65% 에 이르렀다.


이는 Hadoop 시스템에서 네트워크 성능이 Hadoop 시스템의 전체 성능에 엄청나게 영향을 미치는

요인이라는 얘기가 된다. 우리가 보통 시스템에서  I/O를 얘기를 할 때는 디스크 I/O만을 

크게 고려하는데, Hadoop 시스템에서는 오히려 네트워크 I/O가 더 큰 영향을 미치는 것으로 

판단된다.


네트워크 쪽 하는 사람들은 Hadoop을 network traffic log 등을 분석하는데 이용하는 것으로 아는데, 

bulk data transmission이 많은 이러한 Hadoop 환경에서

네트워크 성능 개선을 통한 Hadoop 시스템 개선이나  또는 Hadoop에 특화된 네트워크 구축 방법이나 개발 등이 좋은 주제가 될 수 있지 않을까?


혹 이와 관련하여 좋은 아이디어 있다면 연락주기를 희망한다.  :) 


 




 

Posted by Bart

댓글을 달아 주세요

  1. 리눅스에서 네트워크 카드의 튜닝은 매우 많은 자료들이 있습니다.
    관심있게 보실 부분은 대용량 데이터를 전송할때 패킷을 크게 보낼 수 있도록 점보 프레임 설정이라던지,
    이더넷 랜카드의 irq등을 다양하게 쓰거나 최근 이슈가 되는 멀티큐잉을 지원하는 랜카드를 구입하시는 여러가지 방법이 있겠습니다.

    필요하시면 iz4blue.tistory.com 의 방명록에 올려주세요.

    2012.07.10 22:19 [ ADDR : EDIT/ DEL : REPLY ]

CS 전공/리뷰2012.01.06 10:49


지난 1월 5일 SKKU에 가서 한 발표 자료입니다.
MapReduce의 기본 원리와 특성들, 그리고 해당 프레임워크의 장단점과
개선 연구들을 다루었습니다.
뒷부분의 저희 연구내용 소개는  아직 출판이 안된 관계로 일부 뺐습니다.
Posted by Bart

댓글을 달아 주세요

CS 전공/리뷰2011.06.06 21:04
사실 1부에서 다루지 않았던 MapReduce의 성능 개선이나 개량 모델들에 대한 설명을 2부에서 하고 싶었습니다만, 시간 관계상 그게 여의치가 않았습니다.
해서, MapReduce 관련한 survey를 최근에 작성한 것이 있는데 그것으로 땜빵(?)을 할까 합니다.
혹 관심가지고 글을 기다리셨던 분이 계시다면 시간관계상 한글로 번역해서 올리지 못하는 점 죄송합니다.



 
 

Posted by Bart

댓글을 달아 주세요

CS 전공/리뷰2011.03.25 00:44
목 차
1. 데이터 센터와 클라우드 컴퓨팅
2. MapReduce
3. MapReduce에 관한 논쟁: 장점과 단점
4. MapReduce 개선에 관한 연구들
5. 연구 분야와 도전 과제들
6. 결론 및 향후 전망
관련 연구 


 

1. 데이터 센터와 클라우드 컴퓨팅

 
 
컴퓨터 구조학의 대가인 UC버클리 대 교수 David A. Patterson이 “데이터 센터가 곧 컴퓨터”라고 언급한 바와 같이 현재의 컴퓨팅은 개인이 소유한 PC를 이용한 컴퓨팅에서 데이터 센터가 보유한 무수히 많은 서버들을 이용하여 컴퓨팅을 임대, 사용하는 클라우드 컴퓨팅 으로 빠르게 넘어가고 있다[1].

클라우드 컴퓨팅은 “최소한의 관리만으로 빠르게 제공, 해제될 수 있는 조정 가능한 컴퓨팅 자원의 공유 풀을 접근할 수 있는 요구 중심의 네트워크 접근을 위한 모델”[2]로 정의한다. 클라우드 컴퓨팅을 위한 데이터 센터에서는 많은 계산이 요구되는 대용량 데이터를 많은 저가의 범용 x86 머신에 분배하여 병렬 처리하는 방식으로 확장성(scalability)를 제공한다. 이와 유사한 개념으로 기존에도 그리드 컴퓨팅과 같은 개념이 존재하였지만, 클라우드 컴퓨팅은 데이터 센터라는 지역적으로 집중된 한 곳에 많은 PC들을 설치해놓고 컴퓨팅을 대여, 이용한 만큼 과금한다는 점에서 자발적인 참여와 노드들이 서로 다른 관할권에 속하는 그리드 컴퓨팅과는 구별된다.  

MapReduce[3]는 이러한 데이터 센터 중심의 컴퓨팅에서 “첫 번째 명령어” [1]라고 언급될 정도로 여러 분야 특히 대용량 데이터 분석 및 처리 분야에서 많은 각광을 받고 있다. 2009년 한해 구글에서는 총 3,467K 개의 작업을 평균 488개의 노드를 이용해 처리했다고 밝혔다. 한 해에 데이터는 총 544,130 TB에 이르렀다 한다[4]. MapReduce의 오픈 소스 Java 구현인 Hadoop 또한 많은 분야에서 널리 이용되고 있다[5].
 

 2. MapReduce

MapReduce는 Google에서 정보 검색을 위한 데이터 가공(색인어 추출, 정렬 및 역 인덱스 생성 등)을 목적으로 개발된 분산 환경에서의 병렬 데이터 처리 기법이자 프로그래밍 모델이며, 또한 이를 지원하는 시스템이다[3]. MapReduce는 비공유 구조(shared-nothing)로 연결된 여러 노드 PC들을 가지고 대량의 병렬 처리 방식(MPP; Massively Parallel Processing)으로 대용량 데이터를 처리할 수 있는 방법을 제공한다.  이를 보다 간편하게 하기 위해 MapReduce는 LISP 프로그래밍 언어에서의 map과 reduce 함수의 개념을 차용하여 시스템의 분산 구조를 감추면서 범용 프로그래밍 언어를 이용해 병렬 프로그래밍을 가능하게 한다.

 즉, MapReduce에서는 단순히 Map과 Reduce라는 두 함수의 구현을 통해 데이터 처리를 병렬화할 수 있다. Map과 Reduce가 수행하는 동작은 아래와 같다.

 

Map: (key1, value1) -> (key2, value2)    //(key, value) 쌍을 읽어 다른 (key, value) 쌍에 대응

Reduce: (key2, List_of_value2) -> (key3, value3)   //key2를 기준으로 취합된 value list를 읽어 집계된 값 value 3를 출력


즉, Map 함수는 임의 키-값 쌍을 읽어서 이를 필터링하거나, 다른 값으로 변환하는 작업을 수행하고, Reduce 함수는 Map 함수를 통해 출력된 값들을 새 키 key2를 기준으로 그룹화(grouping) 한 후 여기에 집계 연산(aggregation)을 수행한 결과를 출력한다. 이는 기존 SQL DBMS에서 selection 연산 후 group-by-aggregation을 수행하는 것과 유사하다고도 할 수 있다. 하지만, MapReduce는 이 간단한 두 함수를 이용해 여러 노드들을 대상으로 데이터를 병렬 처리할 수 있는 특징을 가진다.

 그림 1은 MapReduce의 처리 흐름을 나타낸다. 분석할 입력 데이터는 분산 파일 시스템인 GFS(Google File System)[6] 위에 먼저 적재되고, 이 때 데이터는 기본 64MB 크기의 여러 데이터 청크(chunk)들로 분할된다. GFS는 각기 분할된 청크들에 대해 장애로부터의 복구를 위해 2개의 추가적인 복사본을 생성하며 이들을 클러스터를 구성하는 각기 다른 노드 PC들에 위치시킨다.


 


그림 1. MapReduce의 처리 흐름


 
MapReduce 수행 시 이 GFS 상에 적재된 각 청크들은 Map 함수를 수행하는 Mapper 태스크들에 할당된다. Mapper들은 클러스터 상의 여러 노드들에 분산되어 있으며 각기 청크 하나를 받아 Map 함수를 수행하고 그 결과는 Mapper가 수행된 노드의 로컬 디스크에 기록한다. 만약 처리할 청크가 아직 있으면 실행 중에 이미 종료되어 유휴한 Mapper에게 추가로 청크를 할당한다. 이런 방식은 일찍 작업을 종료한 Mapper가 더 많은 청크를 입력받아 처리하도록 함으로써 적절히 부하를 분산시키는 런타임 스케쥴링 효과를 갖는다. 더 이상 처리해야 할 청크가 없고 모든 Mapper가 정상 종료되었다면, MapReduce의 스케쥴러는 Reducer 태스크를 수행한다.
 

 Reducer HTTPS를 이용해 여러 노드들로부터 Key2를 기준으로 각 reducer가 처리해야 할 키-값 쌍을 이전 Mapper들의 로컬 디스크로부터 읽어온다. 이는 집계 연산을 위해 Map 결과를 추가적으로 분할하기 위한 것으로 일반적으로 hash(key2) mod n과 같은 해시 분할을 이용하여 데이터를 n 개의 reducer에 분할시킨다. 이후 key2 값을 기준으로 정렬 연산을 수행하고, 이렇게 해서 정렬된 키-값 쌍들을 동일 키 값을 기준으로 그룹화를 수행한다. 이렇게 해서 각 key2 값을 기준으로 그룹지어진 값들을 대상으로 집계 연산을 수행하고 그 결과를 다시 GFS 상에 다른 키-값 쌍으로 출력한다.
 

Mapper들은 선택적으로 combiner를 가질 수도 있다. 이는 Mapper가 키-값 쌍만을 출력하고 이를 Reducer가 복사, 분할하는데 드는 I/O와 네트워크 대역폭을 절감하고자 각 Mapper가 출력하는 키-값쌍에 대해 미리 그룹화하고 집계 연산을 수행하도록 하는데 이용된다(pre-aggregation).

  데이터 처리 중에 장애 발생 시 Mapper의 경우 같은 청크를 대상으로 다시 수행하거나, 또는 유휴한 다른 Mapper가 해당 청크를 수행하게 함으로써 내고장성을 지원한다. Reducer의 장애의 경우에는 Mapper의 결과는 이미 로컬 디스크에 Mapper의 결과가 실체화된 상태이므로 Mapper의 수행은 건너뛰고 Reducer 작업을 다시 수행한다. 파일의 내구성은 GFS의 데이터 복제에 의존한다.
 

 MapReduce에서는 또한 2 개 이상의 MapReduce 작업을 서로 연결함으로써 보다 복잡한 알고리즘을 구현하는 것도 가능하다. 즉 한 MapReduce 작업이 종료된 후 두 번째 MapReduce 작업이 GFS상의 첫 작업의 결과를 입력으로 하여 동작하는 방식이다. 이 경우에도 각 Map, Reduce 단계의 결과들은 모두 로컬 디스크 또는 분산 파일 시스템 위에 기록됨으로써 내구성이 보장된다.
 

 3. MapReduce에 관한 논쟁: 장점과 단점

MapReduce의 인기에 대해 데이터베이스 연구자들, 특히 병렬 DBMS를 연구해 왔던 학자들은 많은 비판을 가하였다. DBMS 진영의 대표적인 학자들인 M. Stonebraker D. DeWitt MapReduce“A Major Step Backward”라고 비판한 바 있다[7]. 이들은 MapReduce에서의 데이터 병렬 처리 기법은 이미 기존 병렬 DBMS에서 이미 해왔던 것이며, DBMS에서 지원하는 많은 기능들, 예를 들어 스키마, 표준 질의어, 인덱스 기법, 질의 최적화, 압축, 여러 데이터 분할 기법 등 이 빠져 있다고 비판하였다. 이후 2009 SIGMOD에는 이들과 MIT Sam Madden 팀이 같이 Hadoop과 행-기반 DBMS와 열-기반 병렬 DBMS의 성능을 Grep TPC-H 연산 등을 대상으로 비교한 논문을 발표하였다[8]. 여기에서는 데이터 적재 시간을 제외한 나머지 모든 작업에서 MapReduce DBMS, 특히 열-기반 병렬 DBMS보다 못하다라고 언급하였다. MapReduce를 옹호하는 진영은 주로 산업계에서 종사하는 실무자들로 이 비교가 DBMS로 수행하기 좋은 작업들을 대상으로 하였다고 반박하였다. 그들은 MapReduce의 용도는 DBMS와 다르며, 데이터의 일괄 병렬 처리를 위한 시스템으로써 그 의의가 크다고 설명하였다. 반대로 DBMS 진영에서는 연구자들을 중심으로 MapReduce는 이미 연구되었거나 DBMS에서 이미 지원하고 있는 병렬 처리 기법이나 데이터 처리 기법들을 고려하지 않은 매우 순진한(naïve) 시스템이라 비판하였다. 이 기술적 논쟁이 가열되자 ACM에서는 이 두 진영의 의견을 학회지 CACM 2010 1월호에 나란히 올려 이 논쟁을 소개하였다[9, 10]. 

두 진영에서 서로 언급하고 있는 MapReduce의 장단점을 요약하면 다음과 같다.
 

 3.1. MapReduce의 장점

1) 단순하고 사용이 편리

MapReduce는 먼저 Map(), Reduce()라는 두 개의 함수를 구현함으로써 병렬 처리를 가능하게 한다는 것이 큰 장점이다. 데이터의 분산 배치와 실행은 스케쥴러가 담당함으로써 사용자는 분산 시스템의 물리적 구조를 알지 않아도 데이터 병렬화(data parallelism) 방식을 통한 분산 처리를 매우 쉽게 할 수 있는 이점이 있다.
 

 2)  유연성

MapReduce는 특정화된 데이터 모델이나 스키마 정의, 질의 언어에 의존적이지 않다. 사용자는 범용의 프로그래밍 언어를 이용하여 데이터를 어떻게 처리할지 기술한다. 따라서 관계형 데이터 모델로는 표현되기 어려운 다르거나, 비정형적인 데이터 모델들도 지원할 수 있는 유연성을 갖는다.

 3)  저장 구조와의 독립성

MapReduce는 병렬 데이터 처리를 위한 시스템으로 하부 저장구조와 독립적이다. 기본적으로는 MapReduce GFS와 같은 분산 파일 시스템 상의 파일을 입출력으로 하지만, 그외 일반 파일 시스템이나 DBMS 등 다른 저장 구조를 하부에 두는 것도 가능하다.

 4) 내고장성

MapReduce는 분산 파일 시스템의 데이터 복제(replication)에 기반한 데이터의 내구성(durability) 지원과 함께 Mapper Reducer의 태스크 장애 시 각 태스크의 재수행을 통해 장애로부터의 내고장성을 확보한다. 이 때 Map Reduce 작업이 처음부터 다시 실행되는 것을 막기 위해 Map의 결과는 Mapper가 수행된 노드의 로컬 디스크에 기록된다.
 

 5) 높은 확장성(scalability)

MapReduce의 오픈 소스 구현인 Hadoop 4,000 노드 이상으로 확장될 수 있을 정도로 높은 확장성을 가진다[11]. 처리해야 할 데이터 크기가 커지면 그만큼 높은 작업처리량(throughput)을 가지도록 시스템을 개선해야 한다. 기존의 방식은 HW 성능의 개선을 통해처리량을 향상시키는 scale-up 방식이었던 반면에, MapReduce는 저가의 범용 PC들을 추가로 할당함으로써 확장성을 지원하는 scale-out 방식의 구현을 용이하게 한다.


 3.2. MapReduce의 단점

1)  고정된 단일 데이터 흐름

Map Reduce만을 정의하도록 한 MapReduce는 단순한 인터페이스를 제공함에 반해, 복잡한 알고리즘이나 selection-then-group-by-aggregation 작업이 아닌 알고리즘에서는 효율적이지 않다. 대표적인 것이 Join과 같은 이항 연산자(binary operator)의 지원이나 Loop의 지원이다. MapReduce에서는 이항 연산자를 지원하지 않았다. 때문에 Join은 하나의 MapReduce 작업으로 표현되지 못하고 여러 개의 MapReduce 작업을 직렬로 연결해 표현해야만 했다. Loop의 경우도 매 반복 때마다 계속 입력을 반복해서 읽어야 하는 등의 I/O 낭비가 심하였다. , MapReduce에서는 DAG(Directed Acyclic Graph) 형태로 자신의 워크플로우를 따로 정의하는 작업은 불가능하며, 복잡한 알고리즘의 구현을 위해서는 여러 번의 MapReduce 작업을 수행해야 하는 불편함과 그에 따른 성능 저하가 많다. [12]는 어떻게 반복적인 작업을 MapReduce가 비효율적으로 수행할 수 있는지에 대한 대표적인 예가 될 수 있겠다.
 

 2)  스키마, 인덱스, 고차원 언어 등의 미지원

 MapReduce는 병렬 처리에 대한 두 인터페이스를 제공하는 것 이외에 기존의 DBMS가 제공하는 스키마나 질의 언어, 인덱스 등을 제공하지 못한다. 스키마는 데이터의 무결성(integrity)를 지원하는데 있어서 중요한데, 이의 미비는 결국 프로그램 로직 상에서 무결성을 검증하도록 하게 한다. 이런 경우 프로그램도 복잡해지려니와 하부 데이터 형식의 변경은 프로그램 로직의 변경을 야기하고, 매번 데이터를 읽을 때마다 파싱을 수행해야 하는 부담도 갖는다. SQL과 같은 질의 언어의 미지원도 또한 질의 형식의 재활용이나 손쉬운 질의의 작성을 어렵게 한다. 인덱스는 질의 처리 성능의 향상을 위해 중요하지만 MapReduce는 인덱스를 지원하지 않으며, 데이터의 일괄 처리만을 제공한다. 때문에 DeWitt Stonebraker등은 MapReduce를 단순한 LTE(Load-Transform-Extract) 도구로만 처음에 언급하였다[7].
 

 3)  단순한 스케쥴링

 MapReduce는 기본적으로 런타임 스케쥴링에 기반한다. Hadoop의 예에서, 런타임 스케쥴링에서는 태스크를 수행하는 경우는 1) 실패한 태스크를 재수행하거나 또는 2) 아직 수행되지 않은 태스크를 수행하는 경우 또는 3)태스크가 매우 느린 경우이다.  특히 3)의 경우는 임계값을 설정해 두고 일정 시간 동안에 임계값을 도달하지 못하는 경우 straggler로 판정하고 이를 다시 수행시키는데, 노드 PC 성능이 상이한 경우 이 과정이 효과적이지 못하다.

더불어 한 클러스터에서 여러 MapReduce 작업을 동시에 수행하는 경우에 대해서 효과적인 다중-작업 스케쥴링을 제공하지 못한다.
 

 4)  상대적으로 낮은 성능

 MapReduceDBMS와 비교해 상대적으로 낮은 성능을 보인다. 이러한 시스템에서의 성능 측정은 대개 단위시간당 작업처리량(throughput)이나 시스템의 효율성(efficiency) 등으로 측정할 수 있다. [8]에서 보인 바와 같이 MapReduce는 다른 병렬 DBMS에 비해 데이터 적재 시간 이외에 우수한 성능을 보이지 못했다. DBMS의 경우 테이블에의 적재 이외에 인덱스 생성 시간 등이 소요되어 더 많은 시간이 소요되었다. [14]의 연구는 MapReduce를 이용한 병렬 정렬 연산에 있어 한 노드의 작업처리량이 5MB/sec에 못 미침을 보인다.

 MapReduce의 이러한 낮은 성능은 내고장성 지원을 위해 디스크 I/O를 희생하는 태생적인 이유에 근거한다. 우선 파일을 보관하는 분산파일 시스템은 2개의 replica를 추가로 가짐에 따라 디스크 공간과 I/O를 소비한다. 복제된 이후 읽기 연산은 각기 다른 복사본에 접근함으로써 병렬화를 꾀할 수는 있지만, 대신에 출력의 경우는 한 데이터를 가지고 여러 노드에 분산, 기록해야 한다.
또한 각 태스크는 수행 결과를 다음 태스크에 전달하기 이전에 태스크를 수행한 노드의 로컬 디스크 또는 분산 파일 시스템 상에 기록하는 과정을 먼저 수행한다. 이러한 추가적인 I/O는 DBMS에서는 존재하지 않던 것이었다. 예를 들어 다음과 같은 질의가 있다고 하자.

select distinct b.Name, avg(e.Salary)
from employee e, branch b where

b.Id= e.branchId and b.State ="AZ" 
groupby b.id

이 질의는 애리조나 주에 있는 지점들의 종업원의 봉급 평균을 지점별로 분류해서 출력하도록 한다.
이 질의에 대한 DBMS에서의 질의 플랜은 아래와 같다.

그림 2. 질의 플랜 트리

DBMS에서는 이러한 질의 플랜 트리의 수행에 있어 각 연산자가 다음 연산자에 데이터를 전달하기 전에, 데이터를 디스크에 기록한 다음 전달하지 않는다. 디스크 I/O를 가장 큰 비용으로 산정하여 디스크 I/O를 최대한 줄이고자 노력했기 때문이다. 반대로 MapReduce는 매번 연산자가 다음 연산자에 데이터를 전달 전에 디스크에 기록을 먼저 한다. Map은 로컬 디스크에 기록하고, Reduce는 분산 파일 시스템 위에 기록한다. MapReduce가 이러한 방식을 취하는 이유는 간단하게 내고장성을 지원하기 위해서이다. 반대로 디스크 I/O 때문에 성능은 더디어질수밖에 없다. 
 

여기에 더해 MapReduce 태스크들은 블로킹 연산자이다. 예를 들어 모든 Mapper가  종료되기 전까지 Reducer는 시작될 수가 없다. 이는 한 태스크가 느려지면 그 위의 질의 플랜 상의 다른 연산자들이 수행되지 못하고 대기 상태로 기다리게 한다. 그리고 그만큼 전체 실행 시간은 길어진다.
DBMS에서의 질의 플랜 트리는 각 연산자들의 중간 결과를 디스크에 기록하지 않고, 처리하는 족족 위 연산자에 전달한다. 따라서 각 연산자들이 동일시점에 서로 다른 데이터를 가지고 처리할 수 있는 
 파이프라인 병렬화(pipeline parallelism)가 가능하다. 하지만, MapReduce에서는 이와 같은 같은 병렬화를 수행할 수 없고 하나의 늦은 태스크(straggeler) 때문에 전체 작업이 지연될 수 있다
.
물론 DBMS에서도 Sort 같은 블로킹 연산자들은 존재한다. 하지만, 보다 많은 파이프라인 병렬화를 지원한다.

또한 MapReduce는 인덱스를 지원하지 않고, 데이터를 일괄로 읽음에 따라 I/O를 절약하기 곤란하다. 위의 그림에서 scan 시 인덱스를 이용한 입력 데이터의 생략을 MapReduce는 기대할 수 없었다.

이러한 이유로 MapReduce는 태생적으로 병렬 DBMS에 비해 간단하면서도 내고장성을 지원할 수 있는 반면 상대적으로 낮은 성능을 보일 수 밖에 없다. DBMS 분야에서는 각 연산자의 중간 결과 실체화라는 MapReduce의 가장 큰 특징을 유지하면서 기존의 DBMS에서의 I/O를 줄이기 위한 예전 연구들을 MapReduce에 적용하는 방식으로 성능 향상을 꾀한다. (이는 2부에서 설명한다.)

 5)  상대적으로 어린 시스템

MapReduce40여년의 역사를 가진 DBMS와 비교하여 아직 나온지 얼마 안된 기술임에 따라 여러 개발도구나 BI(business intelligence), 3rd party tool들이 존재하지 않는다. 또한 그 자체도 개선의 여지가 아직 많다. 예로, 오늘까지 MapReduce 논문[3]의 인용횟수는 2,575회이다. 그만큼 인기도 있지만 개선의 여지도 많다고 봐야 한다. 

 
 MapReduce 개선에 관한 연구들과 연구 이슈, 도전 분야는 2부에 계속

 
 

관련 연구

1. David A. Patterson. Technical perspective: the data center is the computer. Communications of ACM, 51(1):105, 2008.

2.   Peter Mell and et al. NIST Definition of Cloud Computing V15, 2009. http://csrc.nist.gov/groups/SNS/cloud-computing

3.   Jeffrey Dean and Sanjay Ghemawat, MapReduce: Simplified Data, Processing on Large Clusters, In Proceedings of OSDI 2004 and CACM Vol. 51, No. 1 2008

4.Jeff Dean, Design, Lessons, Advices from Building Large Distributed System, Keynote , LADIS 2009.

5. Hadoop. users List; http://wiki.apache.org/hadoop/PoweredBy

6. S. Ghemawat and et al., The Google File System, In Proceedings of ACM SIGOPS, 2003

7.   David J. DeWitt and Michael Stonebraker, MapReduce: a major step backwards, Database column blog, 2008

8.  Andrew Pavlo and et al. A Comparison of Approaches to Large-Scale Data Analysis, In Proceedings of SIGMOD 2009

9.   Michael Stonebraker and et al. MapReduce and Parallel DBMSs: Friends or Foes?, Communications of ACM, Vol 53, No. 1 pp. 64-71, Jan 2010

10.  Jeffrey Dean and Sanjay Ghemawat, MapReduce: A Flexible Data Processing Tool, Communications of the ACM,  Vol. 53, No. 1 pp. 72-72 Jan 2010

11.  Ajay Anand, Scaling Hadoop to 4000 nodes at Yahoo!, Yahoo! Developer Network, http://developer.yahoo.com/blogs/hadoop/posts/2008/09/scaling_hadoop_to_4000_nodes_a/

12.   J. Cohen, Graph twiddling in a mapreduce world, Computing in Science & Engineering pp. 29—41, 2009, IEEE Computer Society

13.   E. Anderson and et al. Efficiency matters!, ACM SIGOPS Operating Systems Review 44(1):40—45, 2010 ACM

Written by bart7449 

Posted by Bart
TAG MapReduce

댓글을 달아 주세요

CS 전공/리뷰2010.01.08 12:03

  블로그 주인장은 모 단체에서 DB 및 데이터 처리 기술 관련한 자료의 분석 추천및 검토를 담당하고 있습니다. 
이 분석 자료는 클라우드 컴퓨팅에서의 데이터 관리 이슈와 데이터 처리에 있어 MapReduce와 병렬 DBMS의 비교 분석을 중심으로 클라우드 컴퓨팅에서의 데이터 관리를 설명합니다.
이 자료의 분석은 고려대학교 대학원의 최현식씨께서 수고해 주셨습니다.

아래는 서문과 차례입니다. * 해당 자료의 열람 또는 다운로드는 www.kosen21.org에 가입 후 분석자료 메뉴에서 다운로드 하실 수 있습니다.


1. 분석자 서문 

최근 클라우드 컴퓨팅(cloud computing) 패러다임이 산업계뿐만 아니라 학계에서도 많은 관심을 받고 있다. 이와 더불어 데이터베이스 학계에서는 클라우드 컴퓨팅 환경에서 데이터관리에 대한 집중적인 연구들이 진행되고 있다. 본 분석은 현재 많은 관심을 받고 있는 비공유 구조(shared-nothing architecture) 기반 클라우드 컴퓨팅 환경(아마존 EC2와 같은)에서 유발되는 데이터 관리 이슈들과 이 환경에서 수행되는 데이터 관리의 한계점 및 가능성에 대해 살펴본다. 본 분석은 트랜잭션 데이터 처리보다는 대용량 데이터에 대한 분석 처리가 클라우드 환경에 적합하다는 것을 보인다. 그리고 대용량 데이터 분석을 위해 DBMS에 요구되는 기능들을 제시하고 이 기능들을 바탕으로 기존 오픈 소스 프로그램들과 상용 병렬 DBMS들을 평가한다. 추가적으로, 실험을 통해 두 계열 시스템의 성능을 비교 평가한 논문의 결과를 분석하여 성능 비교에 대한 추가적인 근거를 제시한다. 

2. 목차 

1. 개요 

2. 클라우드 환경에서의 데이터 관리 
2.1 클라우드 환경의 특성 
2.2 클라우드 환경에 적합한 데이터 관리 어플리케이션의 유형 

3. 클라우드 환경에서 데이터 분석용 어플리케이션 
3.1 클라우드 DBMS를 위한 필요기능 
3.2 MapReduce 계열 소프트웨어 
3.3 비공유 구조 기반의 병렬 DBMS 

4. MapReduce와 병렬 DBMS 시스템의 비교 
4.1 질의 시작 비용 
4.2 압축 기능 
4.3 데이터 적재 및 레이아웃 
4.4 실행 전략 
4.5 내고장성 모델 

5. 토론 
5.1 효율성의 비교 
5.2 입력 데이터 형식 
5.3 하이브리드 시스템 

Reference 


Posted by Bart

댓글을 달아 주세요

  1. 음 분석자료 제목이 뭔지 알수 있을까요? 검색이 안되는 것 같던데요~

    2010.04.12 17:48 [ ADDR : EDIT/ DEL : REPLY ]
    • 글 제목과 같은 제목입니다.
      아니면 지금 메인 페이지 하단에 제 1 인기글로 있으니 그것으로 찾으셔도 될 듯.

      2010.04.12 18:34 신고 [ ADDR : EDIT/ DEL ]