반응형
이제 겉으로 보이는 동작(스트리밍, 배치)을 넘어, 그 이면에서 실제로 노가다(?)를 뛰는 일꾼들과 지휘관, 즉 스파크 아키텍처의 심장부를 해부해 보겠습니다.
스파크가 왜 '분산 처리의 제왕'인지 이해하려면 드라이버(Driver)와 익스큐터(Executor)의 관계를 명확히 알아야 합니다. 이 둘은 단순한 상하 관계를 넘어, 아주 치밀한 통신 체계를 가지고 있거든요.

🏗️ Spark 내부 구조: "지휘관과 정예 병사들"
스파크 어플리케이션은 하나의 드라이버 프로그램과 클러스터 전역에 흩어져 있는 여러 개의 익스큐터 프로세스로 구성됩니다. 이들은 '클러스터 매니저(YARN, Kubernetes 등)'라는 자원 관리자의 중재 하에 협동합니다.
1. 드라이버(Driver): "작전 통제실의 브레인"
드라이버는 사용자가 작성한 코드가 실행되는 메인 프로세스입니다.
- SparkContext/SparkSession 생성: 모든 스파크 기능의 입구입니다.
- 코드 해석 및 DAG 생성: 사용자가 "Join 해!"라고 명령하면, 이를 어떻게 쪼개서 실행할지 논리적 실행 계획(Logical Plan)을 세우고, 이를 DAG(방향성 비정형 그래프)로 변환합니다.
- 스케줄링 (Task Scheduling): DAG를 실제 실행 가능한 단위인 태스크(Task)로 잘게 쪼갠 뒤, 어떤 일꾼(Executor)에게 어떤 일을 시킬지 결정합니다.
- 결과 수집: 각 일꾼이 계산한 결과물(
collect()등)을 다시 모아서 사용자에게 보여줍니다.
⚠️ 주의: 드라이버는 지휘관이지 짐꾼이 아닙니다.
collect()를 써서 너무 큰 데이터를 드라이버로 가져오면, 지휘관의 머리(Memory)가 터져서 전체 시스템이 다운(OOM, Out Of Memory)됩니다.
2. 익스큐터(Executor): "현장의 근육들"
익스큐터는 개별 작업 노드(Worker Node)에서 돌아가는 프로세스이며, 실제로 데이터를 읽고 계산하는 역할을 수행합니다.
- 태스크 실행: 드라이버가 보낸 태스크를 받아 실제로 CPU와 RAM을 돌려 계산합니다.
- 데이터 보관 (Storage): 사용자가
cache()나persist()를 호출하면, 데이터를 자신의 메모리나 디스크에 저장해 둡니다. 나중에 똑같은 데이터를 쓸 때 다시 읽지 않기 위해서죠. - 상태 보고: "나 지금 이만큼 했어", "나 지금 메모리 이만큼 남았어"라고 주기적으로 드라이버에게 하트비트(Heartbeat)를 보냅니다.
3. 작업의 단위: Job -> Stage -> Task
이 계층 구조를 이해해야 스파크를 제대로 다룬다고 할 수 있습니다.
- Job (작업):
count(),save()같은 액션(Action)을 호출할 때 생성되는 전체 단위입니다. - Stage (단계): 데이터를 서로 섞어야 하는 셔플(Shuffle)을 경계로 나뉩니다.
- 셔플이 없는 작업(Filter, Map)은 하나의 스테이지에서 한 번에 쭈욱 가고, 데이터를 섞어야 하면(Join, GroupBy) 스테이지가 분리됩니다.
- Task (태스크): 익스큐터 한 개가 처리하는 가장 작은 작업 단위입니다. 보통 데이터 파티션 1개당 태스크 1개가 할당됩니다.
4. 슬롯(Slot)과 코어(Core): "진짜 일꾼의 수"
익스큐터 내부에는 태스크 슬롯(Task Slot)이라는 개념이 있습니다.
- 만약 익스큐터 한 대에 4개의 CPU 코어를 할당했다면, 이 익스큐터는 한 번에 4개의 태스크를 동시에 처리할 수 있습니다.
- 사용자가 "파티션이 1,000개인데 왜 이렇게 느려?"라고 한다면, 현재 가용한 전체 슬롯 수가 부족해서 태스크들이 줄을 서서 기다리고 있기 때문일 확률이 높습니다.
5. 실전 비유: "프랜차이즈 식당 운영"
- 드라이버(Driver): 본사 사장님입니다. "오늘의 메뉴는 스테이크다!"라고 레시피(코드)를 짜고, 전국 매장에 "너희는 고기 썰고, 너희는 굽고, 너희는 소스 뿌려"라고 지시를 내립니다.
- 익스큐터(Executor): 개별 매장의 주방입니다. 본사에서 내려온 지시서(Task)대로 요리를 합니다.
- 클러스터 매니저: 인력 파견 업체입니다. 본사가 "오늘 요리사 100명 필요해"라고 하면 각 매장에 요리사를 배치해 줍니다.
- 셔플(Shuffle): 스테이크를 구웠는데 옆집 소스가 필요해서 배달 오토바이로 소스를 주고받는 상황입니다. 이때 시간이 가장 많이 걸리고 사고(네트워크 지연)도 많이 납니다.
반응형
'1. 개발 > 1.4. 데이터 분석' 카테고리의 다른 글
| Kafka 의 핵심 기술인 '제로 카피(Zero Copy)'와 '페이지 캐시' (0) | 2026.02.05 |
|---|---|
| Kafka vs RabbitMQ 어떤 상황에서 Kafka를 선택해야 하는가? (2) | 2026.02.05 |
| 카프카에 담긴 데이터를 가져다가 Spark로 요리할 때, 실시간으로 요리하는 '스트리밍(Streaming)' 처리는 어떻게 하는가? (0) | 2026.02.04 |
| 아파치 에어플로우(Apache Airflow) (0) | 2026.02.04 |
| 데이터 치우침(Data Skew) 현상 (0) | 2026.02.04 |