맵리듀스 개요

맵리듀스(MapReduce)는 기존 하드웨어를 활용한 분산 프로그래밍 모델로서, 

대용량 데이터를 빠르고 안전하기 처리하기 위해 만들었다. 

2014년 OSDI 컨퍼런스에서 구글이 "MapReduce : Simplified Data Processing on Large Clusters" 논문을 발표한 이후, 

맵리듀스는 관심을 받기 시작했다. 

그리고 오픈소스 루씬(Lucene)의 개발자인 더그 커팅(Doug Cutting)이 하둡(Hadoop)을 만들면서 맵리듀스가 널리 알려졌다. 

하둡 오픈 소스 프로젝트는 구글의 분산 기술(GFS, MapReduce)을 기반으로 2006년부터 시작했다. 

하둡 파일 시스템(HDFS)는 대규모 분산 파일 시스템 구축의 성능과 안전정을 보여줬고, 

맵리듀스는 HDFS에 저장된 대규모 분산 파일에 대한 로그 분석, 색인 구축, 검색에 탁월한 능력을 발휘했다. 

이후, 아마존은 맵리듀스 플랫폼(Amazon Elastic MapReduce)을 클라우드 서비스로 제공하기 시작했고, 

몽고디비(MongoDB)와 같은 NoSQL에서도 MapReduce Operation을 제공했다. 

맵리듀스 - 발상의 전환

맵리듀스의 개념을 이해하기 위해, 먼저 기존 프로그래밍 방식을 생각해보자. 

첫째, 데이터를 가져온다. (Fetch Data)

둘째, 가져온 데이터를 처리한다. (Process Data)

셋째, 처리한 데이터를 저장한다. (Save Data)

기존 프로그래밍은 데이터를 가져와서 중앙에서 처리하고 다시 저장하는 구조다. 

하지만 대용량 데이터를 애써 분산 환경에 저장했는데, 처리를 위해 대용량 데이터를 다시 가져와야 한다니? 

즉, 데이터를 가져오는 비용이 많이 든다. 

그래서 데이터를 가져오지 않고 처리할 수 있는 '무엇'이 필요했다. 

이것이 바로 "맵리듀스"이다. 

발상 전환으로 데이터를 가져오지 않고, 데이터가 저장된 곳에서 처리할 수 있도록 만들었다. 

맵리듀스는 크게 맵(Map) 단계와 리듀스(Reduce) 단계로 나눈다. 

맵 단계가 바로 데이터가 저장된 로컬에서 동작한다. 

맵리듀스 이해 

맵 단계와 리듀스 단계 모두 입/출력으로 키-값(Key-Value) 쌍을 가진다. 

키와 값의 타입은 개발자가 선택하며, 맵 함수와 리듀스 함수도 개발자가 직접 작성해야 한다. 

맵리듀스의 단어수 계산(WordCount) 예제로 개념을 정리해 보자. 

"클라우드 컴퓨팅 용어의 정의는 무엇인가?"

"최근 클라우드 컴퓨팅이 화두가 되면서 애매모호한 용어로 인해"

위 두 문장의 단어를 세는 프로그램을 맵리듀스로 처리하면 다음과 같다. 

맵 함수의 입력은 다음과 같다 - 키: 줄번호(라인번호), 값: 문장(라인)

실제 키는 줄번호가 아니라, 파일 각 줄의 시작 오프셋(offset)이 된다. 

맵 함수에서는 각 문장을 공백으로 분류해 단어와 글자 수를 키-값 형태로 제공한다. 

그리고 정렬과 병합이 일어난다. 

여기까지가 분산 저장된 로컬 서버에서 일어나는 작업이다. 

리듀스 함수는 "단어-글자수 목록"을 입력으로 받아서, 각 단어들의 개수를 취합해 최종 결과를 제공한다. 

맵리듀스 구조

맵리듀스의 처리 과정을 한번 더 정리해 보자. 

대용량 입력 파일을 분리(Split)한 후, 맵 함수를 적용한다. 

그리고 리듀스 함수에 전달하기 위해 셔플링(Shuffling)이 일어나고 최종 결과를 생성한다. 

하둡에서 최초 입력 파일은 먼저 스플릿(Split)해서 HDFS에 저장한다. 

대용량 파일을 한번에 처리할 수 없기 때문에, 적절한 크기로 잘라낸 후 맵리듀스로 처리하는 것이다. 

하지만 스플릿의 크기가 너무 작을 경우, 분할 관리 및 맵 태스트 생성의 오버헤드가 있어 역효과가 날 수 있다. 

보통 하둡에서 64MB 이상의 스플릿을 사용하도록 권장하고 있다. 

클라우데라의 CDH에서는 기본값이 128MB로 설정되어 있다. 

셔플링(Shuffling)은 맵 함수의 결과를 취합하기 위해 리듀스 함수로 데이터를 전달하는 역할을 한다. 

그 전에 맵 함수의 결과에 대해 정렬과 병합(Sort & Merge)이 일어난다. 

그리고 각 서버에 나뉜 데이터들을 키를 중심으로 합쳐서 리듀스 함수에 전달한다. 

이렇게 리듀스 함수로 데이터를 전달하는 것을 셔플링(Shuffling)이라고 한다. 

이제 파티셔너(Partitioner)와  컴바이너(Combiner)에 대해서 살펴보자. 

파티셔너는 맵 함수의 결과를 각 파티션으로 나누어 저장하는 역할을 한다. 

파티션을 나누는 기준은 키이며, 기본적으로 키에 해쉬 함수를 적용해 처리한다. 

위 그림에서도 맵 결과를 버퍼에 저장하다가, 디스크에 저장할 때 파티션, 정렬 등의 작업이 일어나는 것을 알 수 있다. 

컴바이너는 일반적으로 리듀서와 동일하게 사용한다. 

그래서 컴바이너를 "로컬 리듀서"라고도 한다.

왜 컴바이너가 필요할까?

맵리듀스는 대용량 처리를 위해 만들었다. 

맵 함수까지는 로컬에서 실행하지만 리듀스 함수로 데이터를 전달하는 것은 네트워크를 이용할 수 밖에 없다. 

로컬에서 리듀스 함수를 먼저 처리한다면, 네트워크로 전달하는 데이터 양이 대폭 감소할 것이다. 

리듀스 함수를 컴바이너로 사용하기 위해서, 리듀스 함수의 입력과 출력의 타입이 같아야 한다. 

그렇지 않을 경우, 별도의 컴바이너를 구현해서 활용할 수 있다. 

컴바이너 적용에 따른 차이는 다음 그림을 살펴보도록 하자. 

컴바이너를 적용함으로써 리듀스 함수로 전달하는 데이터 양이 조금 줄어든 것을 볼 수 있다. 

"뭐 이정도 쯤이야?"하고 생각할 수 있지만, 실제 대용량을 처리할 때 그 차이는 무시할 수 없을 것이다. 

빅데이터를 다룬다면, 맵리듀스의 개념과 구조 정도 이해해야 한다. 

맵리듀스 대신 Hive와 같은 기술로 처리하더라도, 개발자라면 내부적으로 어떤 일이 일어나는지 알아야 하지 않을까?

-- 2012년 2월 29일 처음 작성한 글을 재구성했습니다. 

올해부터 빅데이터에 관심이 부쩍 높아진 것 같습니다. 

클라우드 환경이 대중화되고 하둡 등 분산 처리 기술이 일반화 되면서 자연스럽게 빅데이터에 대한 관심도 늘어나는 것 같습니다. 

하지만 아직도 빅데이터를 단순히 대용량 데이터로만 생각하는 경향이 있어서 

빅데이터의 의미와 실제 사례를 간략하게 정리해 보려고 합니다. 

빅데이터 확장 배경

왜 빅데이터에 관심을 가지게 되었을까요?

먼저 하드웨어가 발달하고 ERP, CRM과 같은 것을 통해 데이터가 충분히 축적되었다는 것입니다. 

이렇게 축적된 데이터를 통해 비즈니스에 기여할 수 있는 인사이트를 만들 수 있을까? 하는 고민이 빅데이터의 시작이라고 생각합니다. 

모든 IT 관련 이슈들이 그러하듯 빅데이터란 것도 하루아침에 나타난 것이 아닙니다. 

예전에 데이터베이스에서도 OLAP 기반의 대용량 데이터 처리에 대한 관심들이 있었죠. 

하지만 데이터의 양이 그때와 비교해 너무 크다는 이슈도 있습니다. 

• 뉴욕 증권 거래소: 1일 1TB 거래 데이터 생성
• Facebook: 100억장 사진, 수 PB 스토리지
• 통신사: 시간당 10GB이상의 통화 데이터, 1일 240GB 생성, 월 생성 데이터의 크기 200TB 이상
• 메신저: 1일 메시지 41억건

혹자들은 향후 이렇게 축적된 데이터들이 각 비즈니스 사업자간 거래까지 이루어 질 수 있다고도 이야기 합니다. 

즉, 사내에 축적된 데이터를 사고 파는 비즈니스가 만들어 질 수 있다는 것이죠. 

물론 개인정보보호와 같은 이슈들은 있지만 충분히 가능한 이야기라고 생각됩니다. 

빅데이터의 3가지 요소는 다음과 같이 규모, 속도, 다양성으로 주로 다루고 있습니다. 

아래 그림을 참고하세요. 

빅데이터 활용 사례

이런 빅데이터가 실제 어떻게 활용될 수 있는지 사례를 통해 살펴보도록 하겠습니다. 

제품 개발과 관련된 사례

가전 제품을 새롭게 만들때 소비자가 잘 사용하지 않는 기능들을 추가해서 제품 가격이나 생산 비용이 상승하는 경우가 있습니다. 

소비자가 각 기능을 사용하는 빈도를 자동으로 수집해서 분석하면 새로운 제품을 출시할 때 자주 사용하지 않는 기능을 제거할 수 있을 것입니다. 

또한, 예상하지 못한 사용으로 인한 고장등을 파악해서 제품의 성능을 확장할 수도 있겠죠. 

실제 구글에서는 GOOG-411이란 서비스를 2007년부터 2010년까지 무료로 서비스를 했었습니다. 

GOOG-411은 우리나라 114와 같은 전화번호 안내 서비스인데요. 

음성통화이기는 하지만 전화번호 안내를 모두 사람이 아닌 기계가 처리하는 방식으로 되어 있었습니다. 

구글은 왜 이 서비스를 무료로 진행했던 것일까요? 

이유는 바로 구글의 음성인식 알고리즘의 성능 향상을 위해 음성 데이터를 수집하기 위해 진행한 것입니다. 

즉, 이 기간동안 수집된 음성들을 통해서 현재 구글의 음성인식 서비스가 완성되었다고 할 수 있겠죠.. 

마케팅 관련 사례

기존의 POS 시스템을 사용해서 판매량 분석과 같은 작업은 오래전부터 이루어지고 있습니다. 

그러나 POS는 판매시점의 데이터를 분석하게 되는데요. 

빅데이터를 활용하면 고객의 활동이나 동선등을 분석해서 새로운 인사이트를 도출할 수 있다는 것입니다. 

대표적으로 상품 추천 서비스나 최적화된 광고 전송과 같은 것들이 있을 수 있습니다. 

상품 추천을 가장 처음 시작한 아마존은 킨들이라는 전자책에 밑줄 긋기 기능을 제공하고 있습니다. 

사용자가 체크한 부분을 서버에 올리고 다른 사용자와 공유할 수도 있게 구성되어 있다고 합니다. 

이것을 통해 Amazon Popular Highlights 기능을 제공하고 있는데요. 

향후, 소비자에게 책을 추천할 때 가까운 고객이 밑줄 그은 부분을 소개하면서 추천해 줄 수도 있겠죠.. 

우리나라 통신사도 망 혼잡 시간에는 3G 데이터의 과다 트래픽 사용자의 속도를 실시간으로 떨어뜨리는 방식을 취하고 있는데요. 

이런 경우에도 시시각각 생성되는 시간대별, 지역별 트래픽 이용 상황에 대한 데이터를 실시간으로 수집해서 분석하는 것으로 볼 수 있을 듯 합니다. 

기타 사례

건물이나 자동차 등에 센서를 부착해서 데이터를 지속적으로 수집한다면 

매년 또는 분기별로 시행하는 정기 검사가 아니더라도 문제가 발생하기 전에 사전에 파악할 수 있을 것입니다. 

이러한 경우, 대형 사고로 이어지는 문제를 빅데이터를 통해서 사전에 차단할 수 있겠죠. 

요즘 보안과 관련된 이슈도 많은데요. 

신용카드의 부정 사용 방지를 위해서는 결제가 일어나는 짧은 시간이내에 부정 여부를 판단해야 합니다. 

이러한 경우에 수많은 거래 데이터를 분석하기 위한 빅데이터 처리가 필요하겠죠. 

그외에도 광고에서의 부정클릭 방지도 비슷한 로직으로 처리될 것 같습니다. 

또한 GPS나 차량 운행 기록을 수집해서 경제적인 운전 여부를 판단하거나 

수집된 데이터를 통해 장치의 실제 가동 현황등을 파악할 수도 있을 것 같습니다. 

스마트폰의 활용을 분석해서 성별, 연령별 인구분포 및 지역간 인구 이동 현황도 파악이 가능하다고 하네요. 

그리고 스마트 그리드 등과 같은 전력 사용 효율화도 현재 진행중인 것으로 알고 있습니다. 

마치면서 

향후 빅데이터가 활성화되면 온오프라인이 결합된 형태로 서비스가 가능해 질 것이라고 합니다. 

현재 인터넷을 통해 옷과 같은 상품을 살펴보면 다른 사이트를 들어갈 때마다 그 옷이 계속 따라다니는 것을 경험해 보셨을 것입니다. 

바로 리타게팅 광고의 결과인데요. 

나중에는 인터넷을 통해 옷을 살펴보고 난 후, 거리를 지나가다가 그 옷이 진열된 매장의 전광판에 

"들어오셔서 한번 입어보고 가세요" 하는 광고가 나올 수도 있을 것 같다는 생각도 드네요.. ^^

여기에 이야기한 부분 이외에도 실제 빅데이터의 사례는 무궁무진할 것이라고 생각됩니다. 

원래 빅데이터가 의미 없어 보이는 데이터들을 통해서 유의미한 정보를 추출하는 것이기 때문에 

주변의 데이터들에 대해서도 한번쯤 관심을 가져보시기 바랍니다. 

그리고 앞으로 빅데이터와 관련된 인사이트가 중시되면서 빅데이터를 처리할 수 있는 기획자, 기술자, 통계학자 등이 많이 필요할 것으로 보입니다. 

지금부터 준비를 한다면 빅데이터 시대에 핵심 인재가 될 수 있지 않을까 생각합니다.