A Comparison of Approaches to Large Scale Data Analysis 논문 소감
- Posted at 2009/04/23 11:49
- Filed under project/lucene_hadoop
http://database.cs.brown.edu/sigmod09/
논문의 저자 중에 한 사람인 Michael Stonebraker는 DBMS 에서 아주 유명한 사람으로 테스트에 사용된 Parallel DB 중의 하나인 Vertica를 만드는데도 참여 했다고 합니다. 이 정도면 논문의 방향이 어떤게 흘러갈지는 예상 가능하겠죠. ㅋㅋㅋ
테스트 결과는 데이터 로딩 시간을 제외하고 논문에서 수행한 모든 테스트 에서 Parallel DB가 성능이 2 ~3배 또는 몇십배 빠르다라는 것입니다.
1. 데이터 로딩 시간: Hadoop에서의 데이터 로딩은 HDFS로 저장만 하고 DB에서의 데이터 로딩은 lock, 저장, index 생성 등의 처리를 하기 때문에 당연히 느리겠죠.
2. Grep: 작은 데이터를 이용한 실험에서는 Hadoop이 2배 정도 느린 것으로 나오고 있는데 이것은 Hadoop의 경우 Task 스케줄링하는데 max 10초 정도 소요됩니다. 물론 이 수치를 조정하면 수행 시간은 더 빨라집니다.(http://www.jaso.co.kr/241)
큰 데이터를 이용하여 작업한 경우에는 스케줄링 시간이 전체 시간에 주는 영향을 미미하기 때문에 제대로 된 비교 테스트라고 볼 수 있습니다. 테스트 결과에서 보면 DBMS-X와 Hadoop은 차이가 별로 없고 Verica가 가장 빠른 것을 볼 수 있는데 논문에서는 Verica는 기본적으로 데이터를 압축해서 저장하기 때문이라고 합니다.
3. Select Task: 논문에서 수행한 query는 인덱스가 잡혀져 있는 데이터에 대해 query를 수행하였습니다. DB의 경우 당연히 range scan을 수행하겠죠... 그러면 인덱스가 잡혀 있지 않은 컬럼에 대해 scan을 하는 경우에는 어떻게 될까요? DB의 경우 full scan을 하거나 index를 생성한 다음에 scan을 해야 합니다. 따라서 정당한 비교가 되기 위해서는 full scan으로 테스트 하거나 index를 생성하는데 걸리는 시간까지 포함해야 합니다.
4. Aggregation Task: 논문 보면서 가장 의문이 되었던 부분입니다. Grep 테스트 수행에서 보면 1TB 데이터를 100 Node에서 수행하는데 250초 정도 소요되었습니다. Grep의 경우 순수하게 scan하고 패턴 매칭만 하기 때문에 Map 데이터 파일을 읽는 시간이라고 볼 수 있습니다. Aggregation Task에서는 100 node의 경우 2TB를 수행하였기 때문에 Map 수행에는 500 ~ 600초 걸렸을 것으로 예상할 수 있습니다. Aggregation의 전체 수행 시간은 1600초 정도 걸렸습니다. 따라서 Map -> Reduce로 전달되고 Reduce 수행되는데에만 전체 시간의 50% 이상이 수행되었다고 볼 수 있습니다. Map에서 Reduce로 전달되는 데이터가 큰 경우라면 모르겠지만 50MB의 출력 결과를 보면 조금은 이상한 수치라고 생각이 듭니다. 테스트에서 사용한 0.19.0 버전이 Map -> Reduce 스케줄링에 다소 문제가 있었는데 이 문제 때문인지 아니면 다른 원인이 있었는지는 확인할 방법이 없습니다. 제 경험상 이 정도 수치라면 600 ~ 700초로 수행이 가능할 것 같은데... 그 시간이먄 DBMS와 비슷한 성능을 보이는 거죠...
5. Join Task: 가장 눈속임이 많은 실험 결과입니다. 실험 수치상으로는 Hadoop이 몇십배 느린 것으로 나옵니다. DBMS가 빠른 이유는 Join 되는 두개의 테이블이 동일한 key 영역으로 파티셔닝 되어 있기 때문입니다. 동일한 키 영역을 가지는 데이터는 동일한 노드에 있기 때문에 로컬에서 JOIN을 수행한 다음 결과만 merge 하면 됩니다.
Hadoop의 경우에는 이 경우에도 full scan을 수행해야 겠죠... 문제는 JOIN을 파티셔닝이 되지 않은 다른 컬럼을 이용할 경우에는 어떻게 되냐 하는 것입니다. DBMS의 경우 한번 파티셔닝 된 것을 다시 바꾸기 위해서는 테이블을 다시 생성해야 합니다. 이 시간은 데이터 로딩 시간과 동일할 겁니다. Hadoop의 경우 파티셔닝이 파일 사이즈로 되어 있기 때문에 상관이 없겠죠.
Hadoop은 주로 데이터 분석에 많이 사용되는데 데이터 분석에 대한 요구사항은 수시로 변하고 변화를 예측하기도 어렵습니다. Hadoop이 사용되는 업무도 보면 주로 원본 데이터를 그대로 Hadoop에 저장한 다음에 필요에 따라 다양한 관점으로 분석하는데 많이 사용합니다. 따라서 특정 키를 중심으로 파티셔닝을 할 경우 이런 업무에는 사용하지 못하는 문제가 있습니다.
이 논문은 성능 비교 그래프를 많이 제시하면서 독자의 눈을 유혹하고 있습니다. 일반적으로 논문을 읽을 때에는 그림에만 집중하고 글은 대충 넘기는 경우가 많습니다. 혹시나 Hadoop에 대해서 자세히 알지 못하는 개발자가 논문만 보고 Hadoop이 훨씬 성능이 느리다 라는 편견을 주기에 딱 좋은 형태로 편집이 되어 있다는 생각이 드네요.
Parallel DBMS가 성능이나 추상화가 잘되어 있고 사용하기 편하고 다양한 도구가 많은 것은 인정합니다. 하지만 Hadoop도 필요한 분야에서는 더 좋은 성능을 내고 편리하고 값 싸게 구성할 수 있는 것도 사실입니다.
Posted by 김형준
- Response
- No Trackback , 3 Comments
Trackback URL : http://www.jaso.co.kr/trackback/343
Comments List
-
안녕하세요, Hadoop사용자 모임에서 인사드렸던 김영우입니다.
우선 논문 분석은 너무 잘 정리해주셔서 잘 읽었습니다. ^^ 개인적으로도 'DBMS-specific'한 작업들로 테스트가 이루어져 저자들의 의도에 결과를 맞추었다는 의혹(?)을 가지고 있었습니다. 글에서도 말씀하신 대로 '문제'를 해결하는 IT 엔지니어로서, 'Use the right tool for the job' 이라는 문구가 생각이 납니다. DBMS를 쓰느냐 Hadoop을 쓰느냐를 결정하는 것은 단지 특정 작업에 성능이 좋다는 근거로 접근하기 보다는 시스템과 조직 관점에서 종합적인 근거와 판단이 필요하다고 봅니다.
http://www.dbms2.com/2009/04/15/cloudera-presents-the-mapreduce-bull-case/
많은 벤치마크에서 무시하는 부분 중에 하나가 '비용', '유연성'과 '확장성'인데 실제 필드에서 업무를 하다보면 '성능'은 누군가가 만든 '숫자'에 불과하단 생각도 해봅니다. 물론 적당한 성능이 보장되어야 그 시스템이 살아남을 수 있긴하지만요. ㅎㅎㅎ-
외국에서도 어떤식으로 반박글이 나올 것은 예상했습니다. ㅋ 좋은 정보 감사합니다.
-
-
안녕하세요. MapReduce 관련한 글들을 조회하다가 글을 읽어보게 되었습니다.
글의 주제가 관심이 가서 잘 읽어보았습니다. 해당 논문에 대한 제 판단이 님과 많이 달라서 글을 남겨볼까 합니다.
저는 이 논문에서의 실험이 fair comparison이라고 생각합니다. 제가 생각하는 모든 병렬 DBMS의 모토는 실행에 있어 가급적 I/O와 네트웍 전송을 줄이자입니다. 이런 면에서 보면 MapReduce는 병렬 DBMS의 모토와 굉장히 상반되는 모델입니다. 그리고, 이것이 M. Stonebraker와 D. DeWitt이 초기에 MapReduce를 “a major step backwards”라고 주장한 대표적인 이유라 생각합니다. mapReduce에서는 local file에서 HDFS로 데이터를 적재하고, map() 결과를 local file로 materialize 시킨 후에 다시 reduce가 읽어들어 HDFS에 기록합니다. 이런 모델은 I/O와 네트워크 전송량을 증가시킵니다. 뿐만 아니라 이때 데이터 분포가 skewed 될 수 있습니다. 하지만 이렇게 해서 얻어지는 장점으로 더 많은 노드에 대한 fault-tolerance를 보장할 수 있다는 것이고 그것이 MapReduce의 장점 중 하나라고 생각합니다.
비교에 관해 쓰신 내용 중에 2. Grep 실험 부분에서 DBMS-X(현시점에서MS는 Parallel DBMS를 가지고 있지 않으니 Oralce 아니면, IBM 제품으로 생각됩니다.) 가 또한 압축을 지원한 상태에서 실험을 하였다고 논문에서 언급하고 있습니다. 그리고, Vertica와 DBMS-X의 실험 결과가 별 차이가 없고 Hadoop이 더 많은 시간을 소비하고 있습니다. 이런 이유는 Vertica가 aggressive compression을 쓰고 있기도 하지만, hadoop에서 local file에 기록된 각 map()결과를 다시 HDFS에 올려 하나의 파일로 합치는데 걸리는 시간 또한 많이 소비되는 것도 한 이유라고 봅니다.
3.의 경우 인덱스를 이용하니 당연히 병렬 DBMS가 빠르지만, 정당한 비교가 되기 위해서 인덱스 생성 시간을 포함해야 한다고 하셨는데, 인덱스 생성시간은 이미 데이터 로딩 시간에 포함되어 있으니, 다시 이 시간을 포함하면 중복입니다. 그리고, 제가 아는 한 인덱스는 초기 인덱스 생성 비용을 소비하여, 추후의 데이터 검색 시 이를 빠르게 하는 것이 목적이기 때문에, 단일 질의 처리에 대해서 인덱스 생성 비용을 추가하는 것은 바람직한 비교가 아니라 생각합니다. 아니면, 인덱스를 이용한 질의와 인덱스를 이용하지 않은 질의를 각각 나누어서 비용을 계산하는 것이 더 정당하다고 봅니다.
더불어서 Vertica는 data layout이 column-oriented입니다. 그만큼 selection 연산 처리하는데 있어 I/O cost가 굉장히 낮은 장점이 있습니다. 아마 index를 쓰지 않고 full-scan하더라도 특정 경우(테이블의 컬럼 수가많고, select하는 컬럼수는 적은 경우)에는 Hadoop보다도 나을 수 있을 겁니다.
4. aggregation task의 결과가 저렇게 나온 이유는 스케쥴러 문제보다는 바로 data skewness 때문에 발생하는 reduce()간의 load imbalancing과data materialization 때문에 발생하는 disk I/O 때문으로 판단됩니다.
5. 병렬 DBMS에서의 데이터는 PK-FK 값을 같은 hash 값을 가지는 파티션들로 분할하여 각 노드의 로컬 디스크에 저장합니다. 때문에 조인이 로컬 시스템에서 이뤄지고, 결과값만 전송하여 취합하는 식으로 수행되니 당연히 빠르겠죠. 여기에 인덱스 구조까지 같이 쓰면 더욱더 빠를 겁니다. 파티셔닝이 되지 않은 다른 컬럼을 가지고 조인을 하는 경우에는 물론 느려지겠죠. 조인을 위해서는 네트웍 전송이 있어야 하니까.. 하지만, 애초에 테이블을 만들 때 Pk-FK 를 정의하는 것은 그 값을 기준으로 조인을 하기 위해서이고, 애초에 조인할 대상이 미리 결정되어 있기 때문일 것입니다. 임의 컬럼으로 조인하는 경우가 얼마나 많을지요? 오히려 그런 경우가 있다면 그 테이블을 FK 수에 맞추어서 여러 테이블로 분할하는 것이 더 이상적일텐데요.
제가 생각하기에 MapReduce가 성능 면에서 병렬 DBMS에 비해 확실히 나은 경우는 데이터를 한번 읽어 한번 분석할 때인 것으로 판단됩니다. 데이터 적재 시간 + 실행 시간이 분명 DBMS보다 나은 경우가 존재하니까요. 또, 관계형 모델로 표현하기 어려운 매우 비정형적인 데이터들을 처리하는 경우도 해당이 될 거라 생각합니다
