Spark 는 무엇을 바꿨나
Article
"요즘은 MapReduce 안 쓰고 Spark 써요." 하둡을 알아보면 반드시 듣게 되는 말입니다.
맞는 말이지만 절반만 맞습니다. 3강에서 봤듯 Spark 가 대체한 건 계산 엔진 층 하나예요. 저장(HDFS)과 자원(YARN)은 그대로 쓰는 경우가 많습니다.
이번 시간에는 Spark 가 정확히 무엇을 바꿨는지 봅니다. 단순히 "빠르다"로 넘어가면 왜 빠른지, 언제는 안 빠른지를 놓치게 되니까요.
MapReduce 의 진짜 약점
13강에서 Shuffle 이 비싸다고 했죠. 그런데 더 근본적인 문제가 하나 있습니다. 단계마다 디스크를 거칩니다.
MapReduce 는 작업 하나가 끝나면 결과를 HDFS 에 씁니다. 그것도 복제 3벌로요. 다음 작업은 그걸 다시 읽고요. 단계가 열 개면 이 왕복이 열 번 일어납니다.
Spark 는 죽으면 어떻게 할까요
여기가 재미있는 부분입니다. 중간 결과를 디스크에 안 쓰면, 장비가 죽었을 때 그 결과가 사라지죠. 어떻게 복구할까요.
Spark 의 답은 다시 계산합니다 입니다.
- MapReduce중간 결과를 디스크에 저장해 뒀다가 다시 읽습니다
- Spark어떤 순서로 계산했는지를 기억해 뒀다가 그 부분만 다시 계산합니다
이 방식이 성립하는 조건이 있습니다. 원본 데이터가 안 변해야 하고(HDFS 가 보장), 같은 계산을 다시 하면 같은 결과가 나와야 합니다. MapReduce 가 강제하던 그 성질을 Spark 도 그대로 씁니다.
그래서 얼마나 빠를까요
"100배 빠르다"는 말을 자주 보는데, 조건을 따져봐야 합니다.
| 작업 | 차이 | 이유 |
|---|---|---|
| 같은 데이터를 수십 번 반복 | 매우 큼 | 반복마다 디스크 왕복이 사라집니다 |
| 여러 단계를 이어 붙인 처리 | 큼 | 단계 사이 저장·읽기가 없습니다 |
| 한 번 읽고 한 번 처리 | 작음 | 왕복할 중간 단계가 없습니다 |
| 메모리보다 큰 데이터 | 작거나 없음 | 결국 디스크를 쓰게 됩니다 |
표현력도 달라졌습니다
속도만 바뀐 게 아닙니다. 프로그램을 짜는 방식도 훨씬 편해졌어요.
MapReduce
Java · 두 클래스
- Map 클래스와 Reduce 클래스를 각각 만듭니다
- 모든 계산을 map/reduce 두 모양에 맞춥니다
- 단계가 여럿이면 작업을 여러 개 이어 붙입니다
Spark
몇 줄
- map · filter · groupBy · join 등을 이어 씁니다
- map/reduce 두 모양에 억지로 안 맞춰도 됩니다
- 여러 단계를 한 프로그램에 자연스럽게 씁니다
counts = (spark.read.text("/logs/2026-08/access.log")
.rdd.flatMap(lambda r: r.value.split())
.map(lambda w: (w, 1))
.reduceByKey(lambda a, b: a + b))
이 몇 줄이 14강의 그 전체 과정을 대신합니다. 안에서 벌어지는 일은 크게 다르지 않아요. Shuffle 도 여전히 일어나고, 그게 여전히 가장 비싼 구간입니다.
그런데 왜 하둡을 배웠을까요
여기서 이 시리즈의 앞부분이 왜 필요했는지가 드러납니다.
- 01
데이터는 여전히 HDFS 에 있습니다
블록·복제·NameNode 이야기가 그대로 적용됩니다. 작은 파일 문제도 그대로예요.
- 02
자원은 여전히 YARN 이 나눠줍니다
컨테이너, 대기열, ACCEPTED 대기가 그대로 나옵니다. 클러스터를 공유한다면요.
- 03
Shuffle 은 여전히 가장 비쌉니다
Spark 에서도 groupBy 와 join 이 느린 이유가 이겁니다. 13강의 내용이 그대로 적용돼요.
- 04
쏠림도 그대로 있습니다
한 키에 데이터가 몰리면 Spark 에서도 그 작업 하나만 안 끝납니다. 16강 그대로예요.
정리하면
- Spark 가 대체한 건 계산 엔진 층 하나입니다. HDFS·YARN 은 그대로 쓸 수 있어요
- 핵심 차이는 중간 결과를 메모리에 들고 있는 것입니다
- 죽으면 저장해 둔 걸 읽는 대신 계산 과정을 기억했다가 다시 계산합니다
- 반복이 많은 작업일수록 차이가 크고, 한 번 훑는 작업은 차이가 작습니다
- 메모리보다 큰 데이터에서는 이점이 줄어듭니다
- Shuffle·쏠림·작은 파일 문제는 Spark 에서도 그대로 있습니다
확인 문제
MapReduce 로 40분 걸리던 작업을 Spark 로 바꿨더니 38분이 나왔습니다. 기대한 만큼 안 빨라진 이유로 무엇을 의심해야 할까요?
정답 및 해설 보기충분히 고민해본 뒤 꼭 필요한 경우에만 열어보세요
그 작업이 한 번 읽고 한 번 처리하는 모양일 가능성이 큽니다.
Spark 의 이점은 단계 사이의 디스크 왕복을 없애는 데서 나옵니다. 그런데 원래 작업이 "읽고 → 집계하고 → 쓰고" 한 번에 끝나는 구조였다면, 없앨 왕복이 애초에 없어요. 아낄 게 없으니 시간도 그대로입니다.
두 번째로 의심할 것은 데이터가 메모리에 안 들어가는 경우입니다. 클러스터 전체 메모리보다 처리할 데이터가 크면 Spark 도 디스크로 넘기게 되고, 그러면 MapReduce 와 비슷해져요.
세 번째는 병목이 Shuffle 인 경우입니다. groupBy 나 join 이 있고 데이터 쏠림이 있다면, 엔진을 바꿔도 그 구간은 그대로 느립니다. 이때는 엔진이 아니라 15·16강에서 본 방법으로 접근해야 합니다.
다음 강의
하둡 주변에는 HDFS 로는 안 되는 일을 맡는 도구들이 있습니다. 한 건씩 즉시 읽고 쓰는 HBase, 실시간으로 흘러드는 데이터를 받는 Kafka 를 살펴봅니다.