MapReduce
MapReduce의 역사
MapReduce는 2004년 Google 사내에서 개발되었습니다. 당시 Google에 근무하던 Jeffery Dean과 Sanjay Ghemawat가 개발의 주역입니다(Dean & Ghemawat, 2004). 두 사람이 저술한 글 "MapReduce: 대형 클러스터의 데이터 처리 간소화(MapReduce: Simplified Data Processing on Large Clusters)"에서 언급했듯이 함수 프로그래밍에서 흔히 쓰이는 map과 reduce 함수에서 아이디어를 얻은 것이 기원입니다. 당시 Google의 독점 자산이던 MapReduce 시스템은 GFS(Google File System)에서 실행되었습니다. 2014년 무렵에는 Google에서 MapReduce를 자사의 기본 빅데이터 처리 모델로 사용하지 않게 되었습니다. MapReduce은 한때 HDFS에 보관된 데이터를 회수할 수 있는 유일한 방법이었지만, 이제는 그렇지도 않습니다. 지금은 Hive 및 Pig와 같이 SQL과 유사한 문을 사용하여 MapReduce 모델을 사용해 쓴 작업과 함께 실행해 HDFS에서 데이터를 가져오는 다른 쿼리 기반 시스템도 있습니다.
MapReduce는 어떻게 작용합니까?
MapReduce 시스템은 보통 세 가지 단계로 구성됩니다(Map과 Reduce 작업/함수를 조합한 것으로 일반화되어 있기는 하지만). MapReduce 작업은 다음과 같은 작업입니다.
- Map: 입력 데이터를 우선 여러 개의 작은 블록으로 분할합니다. 그런 다음 하둡 프레임워크가 처리할 데이터의 크기와 각 매퍼 서버에서 이용 가능한 메모리 블록에 따라 매퍼를 몇 개나 사용할지 결정합니다. 다음으로 각각의 블록을 매퍼에 할당하여 처리하도록 합니다. 각각의 "작업자" 노드가 map 함수를 로컬 데이터에 적용하고, 출력을 임시 스토리지에 씁니다. 기본(마스터) 노드가 있으므로 중복 입력 데이터의 사본 한 개만 처리되지 않도록 보장합니다.
- 셔플, 조합, 분할: 작업자 노드가 출력 키(map 함수가 도출)를 근거로 데이터를 다시 배포하여 한 키에 속하는 모든 데이터는 같은 작업자 노드에 위치하도록 합니다. 옵션 프로세스로 결합기(리듀서)가 각각의 매퍼 서버에서 따로 실행되어 각 매퍼의 데이터를 더 줄일 수도 있습니다. 이렇게 하면 데이터 풋프린트가 줄어들어 셔플과 정렬이 더 쉬워집니다. 분할(옵션 아님)은 데이터를 리듀서에 어떤 식으로 표시할지 결정하고, 데이터를 특정 리듀서에 할당하기도 하는 프로세스입니다.
- Reduce: 매퍼가 아직 진행 중인 동안에는 리듀서를 시작할 수 없습니다. 작업자 노드가 <key,value> 쌍 출력 데이터 그룹을 각각, 병렬로 처리하여 출력값으로 <key,value> 쌍을 도출합니다. 키가 같은 map 출력값은 모두 한 개의 리듀서에 할당되고, 이것이 그 키의 값을 집계합니다. 첫 데이터를 필수적으로 필터링하고 정렬해야 하는 map 함수와 달리 reduce 함수에서는 이 작업이 옵션입니다.
MapReduce를 사용할 때 고려해야 할 점은 어떤 것이 있습니까?
견고한 MapReduce 프로그래밍 패러다임
Map과 Reduce 인터페이스를 프로그래머에게 노출하여 Hadoop 내에 분산형 애플리케이션을 생성하는 작업이 간소화되었지만, MapReduce 프로그래밍 패러다임의 광범위한 로직을 표현하기는 어려운 일입니다. 반복 프로세스는 MapReduce와 잘 맞지 않는 로직의 대표적인 예입니다. 일반적으로 데이터를 메모리에 보관하지 않으며 반복 로직은 MapReduce 애플리케이션을 연쇄적으로 함께 연결하여 취급하므로 복잡성이 가중되는 결과를 초래하게 됩니다.
읽기/쓰기 집약적
MapReduce 작업은 데이터를 메모리에 거의 보관하지 않습니다. 사용자 데이터에 대한 분산형 메모리 구조 개념이 없기 때문입니다. 이 경우 데이터는 반드시 HDFS에서 읽고 HDFS에 써야 합니다. 더 복잡한 MapReduce 애플리케이션의 경우 크기가 작은 MapReduce 작업 여러 개를 연쇄적으로 연결하기도 합니다. 이러한 여러 작업 사이로 데이터를 전달할 수 없으므로, HDFS를 통해 데이터를 공유해야 합니다. 이 때문에 처리 병목 현상이 생깁니다.
Java 중심
MapReduce는 Java 기반이므로, Java를 사용하기 때문에 애플리케이션 제작에 가장 효과적인 방식입니다. 코드를 별도의 개발 환경에서 컴파일한 다음 Hadoop 클러스터에 배포해야 합니다. 이런 개발 방식은 SQL 같은 다른 기술이나 Python과 같은 인터프리터 언어에 익숙한 데이터 애널리스트나 데이터 사이언티스트 사이에서 널리 사용되는 방식은 아닙니다. MapReduce에는 C, Python이나 Shell Scripting과 같은 다른 언어로 쓰인 Map/Reduce 로직을 호출하는 기능이 없습니다. 대신 시스템 프로세스를 스핀업하여 이런 프로그램 실행을 처리하게 합니다. 이 작업을 실행하면 오버헤드가 발생하고, 이 때문에 작업 성능이 영향을 받게 됩니다.
빅데이터 서비스로서 서서히 폐지되는 과정
MapReduce는 빅데이터 계열에서 서서히 단계적으로 폐지되는 추세입니다. 아직 자사 Hadoop 배포에 MapReduce를 포함하는 벤더가 있기는 하지만, 이는 레거시 애플리케이션을 지원하기 위해서일 뿐입니다. 고객도 MapReduce 애플리케이션 제작을 하지 않게 되었으며, 그 대 신 Apache Spark처럼 좀 더 단순하고 빠른 프레임워크를 도입하고 있습니다.
MapReduce는 어떤 용도로 사용되나요?
요즘은 레거시 애플리케이션이나 Sqoop 및 Pig와 같은 Hadoop 네이티브 툴도 MapReduce를 사용합니다. MapReduce 애플리케이션 개발은 매우 제한적이며, 오픈 소스 기술로서 의미 있는 기여도 딱히 없습니다.
MapReduce와 Spark에 대한 일반적인 오해
- MapReduce 소개
- Spark 소개
MapReduce의 장점
- 확장성
- 유연성
- 보안 및 인증
- 빠른 데이터 처리 속도
- 매우 간단한 프로그래밍 모델
- 가용성 및 복원력
MapReduce 성능을 개선하는 방법에 대한 간단한 팁
- 우버 모드 사용
- 네이티브 라이브러리 사용
- 블록 크기 늘리기
- map 작업에 소요되는 시간 모니터링
- 데이터 압축이 분할 가능한지 여부 확인
- 감소된 태스크 수 설정
- 데이터 파티션 분석
- 셔플 단계 성능 변화
- MapReduce 코드 최적화
MapReduce 대 Databricks Delta 엔진
Databricks Delta Engine은 Apache Spark와 일명 Photon이라는 C++ 엔진 기반입니다. 이 때문에 MapReduce에 없는 DAG 처리의 유연성이 보장되고, 메모리 내 처리 속도가 빠르며 기본적으로 컴파일되는 특수 엔진을 통해 매우 빠른 쿼리 대응 시간을 제공합니다. 사용자는 Python, Scala, R 또는 SQL을 사용해 Databricks Delta Engine과 상호작용할 수 있습니다. 기존 Spark 애플리케이션을 수정하여 Delta Engine을 사용하도록 설정할 수도 있습니다. 단순한 줄 변경 하나(데이터 형식으로 "delta"를 지정)면 해결됩니다. MapReduce와 HDFS는 기본적으로 데이터의 트랜잭션 일관성을 지원하지 않고, 데이터 세트 내의 기존 데이터를 업데이트/삭제하는 기능도 지원되지 않습니다. Delta Engine을 사용하면 데이터 생산자와 소비자가 데이터에 동시에 액세스할 수 있으며, CRUD 기능도 온전히 제공합니다. 마지막으로, MapReduce는 크기가 작은 파일을 처리하는 기본 내장 기능이 없습니다. 이것은 빅데이터 환경이라면 흔히 있는 문제점입니다. Databricks Delta Engine의 자동 압축 기능이 스토리지에 쓴 데이터 크기를 최적화합니다. 또한 optimize 명령을 사용하여 온디맨드 방식으로 파일을 압축할 수도 있습니다. Delta의 트랜잭션 일관성 기능을 사용하면 최종 사용자나 애플리케이션이 데이터에 액세스하는 동안에도 이 작업을 실행할 수 있습니다.
MapReduce를 대체할 수 있는 5가지 최고의 대안
- Apache Spark
- Apache Storm
- Ceph
- Hydra
- Google BigQuery