Spark(3) - MapReduce 프로그래밍

맵리듀스 프로그래밍

목표가 큰 데이터를 처리하는데 있다. 그렇다보니까 데이터셋의 포맷도 하나로 단순화 시켰다.

데이터 셋은 Key, Value의 집합이며 변경 불가(immutable)

데이터 조작은 map과 reduce  두 개의 오퍼레이션으로만 가능

Reduce는 Map의 출력 중에 같은 키를 갖는 출력을 모아 처리해서 새로운 key-value 페어를 만들어 주는 것

• 이 두 오퍼레이션은 항상 하나의 쌍으로 연속으로 실행됨
• 이 두 오퍼레이션의 코드를 개발자가 채워야 함

맵리듀스 시스템이 Map의 결과를 Reduce 단으로 모아준다. 이 단계를 보통 셔플링이라고 부르며, 네트웍단을 통한 데이터 이동이 생긴다. 

일반적으로 맵리듀스 한 번으로 원하는 결과를 얻지 못하고 몇 번을 거쳐서 원하는 결과를 낸다.

 

 

맵과 리듀스

• Map : (k, v) -> [(k', v')*]
  • 입력은 시스템에 의해 주어지며 입력으로 지정된 HDFS 파일에서 넘어옴
  • 키, 밸류 페어를 새로운 키, 밸류 페어 리스트로 변환
  • 출력 : 입력과 동일한 키, 밸류 페어를 그래돌 출력해도 되고 출력이 없어도 됨
• Reduce : (k', [v1', v2', v3', v4', ...]) -> (k'', v'')
  • 입력은 시스템에 의해 주어짐 - 맵의 출력 중 같은 키를 갖는 키/밸류 페어를 시스템이 묶어서 입력으로 넣어줌
  • 키와 밸류 리스트를 새로운 키, 밸류 페어로 변환
  • SQL의 GROUP BY와 흡사
  • 출력이 HDFS에 저장

 

MapReduce : Shuffling and Sorting

Shuffling

• Mapper의 출력을 Reducer로 보내주는 프로세스를 말함
• 전송되는 데이터의 크기가 크면 네트워크 병목을 초래하고 시간이 오래 걸림

Sorting

• 모든 Mapper의 출력을 Reducer가 받으면 이를 키별로 소팅

 

MapReduce : Data Skew

각 태스크가 처리하는 데이터 크기에 불균형이 존재한다면?

병렬처리의 큰 의미가 없음. 가장 느린 태스크가 전체 처리 속도를 결정한다. 특히 Reducer로 오는 나눠지는 데이터의 크기는 큰 차이가 있을 수 있다. (Group By나 Join등이 이에 해당함, 처리 방식에 따라 Reducer의 수에 따라 메모리 에러등이 날 수 있다.)

데이터 엔지니어가 고생하는 이유 중의 하나 - 빅데이터 시스템에는 이 문제가 모두 존재

 

MapReduce 프로그래밍의 문제점

낮은 생산성 - 프로그래밍 모델이 가진 융통성 부족(2가지 오퍼레이션만 지원), 튜닝/최적화가 쉽지 않다(데이터 분포가 균등하지 않은 경우)

배치작업 중심 - 기본적으로 Low Latency 가 아니라 Throughput 에 초점이 맞춰진다

 

MapReduce 대안의 등장

더 범용적인 대용량 데이터 처리 프레임워크가 등장

• YARN, Spark

SQL의 컴백 : Hive, Presto 등이 등장

• Hive : MapReduce 위에서 구현됨. Throughput에 초점. 대용량 ETL에 적합
• Presto : Low latency에서 초점. 메모리를 주로 사용. adhoc 쿼리에 적합, AWS Athena가 Presto 기반