티스토리 뷰

DE

[DE] Spark driver & executor (core, memory)

승가비 2025. 11. 4. 16:43
728x90

1️⃣ Spark Driver & Executor 구조 이해

Spark 애플리케이션은 크게 DriverExecutor로 구성된다.

구성요소역할
Driver 전체 DAG를 구성하고, Task를 스케줄링하고, 결과를 수집함. (Application의 뇌)
Executor 실제 Task를 실행하는 워커 프로세스. 여러 개의 스레드(Core)로 병렬 수행함.
Core Executor 내에서 동시에 실행 가능한 Task의 개수.
Memory Executor가 데이터를 캐싱하거나, 셔플 버퍼를 유지하거나, 사용자 객체를 저장하는 공간.

즉, Spark는 **“Driver가 계획을 세우고, Executor들이 나눠서 일하는 구조”**다.

“Spark는 마스터-워커 구조로, Driver가 스케줄링을 담당하고 Executor가 병렬 Task를 수행합니다.”


2️⃣ Core와 Memory의 관계

Spark는 병렬 처리를 위해 “Core” 단위로 작업을 분할한다.
Executor 하나가 몇 개의 Core를 갖느냐에 따라 한 번에 돌릴 수 있는 Task 개수가 결정된다.

  • --executor-cores: Executor 당 병렬 스레드 수
  • --num-executors: 전체 Executor 개수
  • --executor-memory: Executor 하나당 메모리 크기

💡 계산식:

 
총 병렬 슬롯(=총 코어 수) = num-executors × executor-cores 총 메모리 사용량 = num-executors × executor-memory

예를 들어,
--num-executors 10, --executor-cores 4, --executor-memory 8G라면
→ 총 40개의 병렬 슬롯, 총 80GB 메모리가 Executor들에 분산된다.


3️⃣ Driver vs Executor — 메모리 병목의 차이

  • Driver 메모리 부족:
    • DAG Plan이 복잡하거나, 큰 Broadcast Join 수행 시 OutOfMemoryError 발생
    • 증상: “Job aborted due to stage failure” or “GC overhead limit exceeded”
  • Executor 메모리 부족:
    • RDD/DataFrame 캐시, Shuffle, GroupBy 수행 시 Spill 발생
    • 디스크 스필이 많아지면 성능 급락 (특히 Sort/Join 단계)

“Driver OOM은 스케줄링 단계에서, Executor OOM은 실제 Task 수행 중에 발생합니다.”


4️⃣ 실무 기준값 (Core & Memory 사이징 가이드)

구분Executor CoreExecutor MemoryDriver Memory설명
소형 ETL / 테스트 2~3 4~8 GB 2~4 GB 빠른 시도용, 병렬성 낮음
일반 배치 4~6 8~16 GB 4~8 GB 가장 많이 쓰이는 표준
대규모 조인 / 집계 5~8 16~32 GB 8~12 GB Shuffle/Cache 집중형
스트리밍 2~4 8~16 GB 4~8 GB 안정성 우선, 마이크로배치 대응

🔸 기본 원칙

  • Executor에 너무 많은 Core를 주면 GC 지연 증가
  • 너무 적게 주면 병렬성이 떨어짐
  • 보통 Executor 당 4~6 Core, 8~16GB 메모리가 가장 안정적

5️⃣ 리소스 산정 공식 (실무 절차)

  1. 노드 스펙 파악
    → 예: 16 vCPU / 64GB RAM
  2. 노드당 Executor 개수 결정
    → 보통 1~2개 (GC/Shuffle 부담 고려)
  3. Executor Core 수 산정
    → (vCPU - 1) ÷ Executor 수 → 7 Core
  4. Executor Memory 산정
    → (64GB - OS 여유 10%) ÷ Executor 수 → 약 28GB
  5. 총 Executor 개수
    → 클러스터 노드 × 노드당 Executor 수

“Executor 당 4~6 Core, 8~16GB 메모리로 시작하고, GC/Spill 로그를 기반으로 조정합니다.”


6️⃣ spark-submit 예

 
spark-submit \
--class com.example.BatchJob \
--master yarn \
--deploy-mode cluster \
--num-executors 10 \
--executor-cores 5 \
--executor-memory 16G \
--driver-memory 8G \
--conf spark.sql.shuffle.partitions=300 \
--conf spark.default.parallelism=100 \
app.jar

“Executor 10개, 각 5 Core로 총 50개의 Task를 병렬 실행하며,
Executor 당 16GB 메모리로 Shuffle/Cache 영역을 확보했습니다.
Driver는 8GB로 DAG 스케줄링을 안정적으로 처리합니다.”


7️⃣ 튜닝 포인트 요약

증상원인개선 방법
Spill 과다 메모리 부족 Executor 메모리↑, 파티션 수↑
GC Time ↑ Core 과다 Executor Core↓, Memory↑
Stage Skew 특정 키 집중 Salt key, Repartition
Driver OOM DAG 너무 큼 Driver Memory↑, Broadcast 조정
Task 실패 OOM 또는 네트워크 Timeout Retry, Memory↑, Timeout↑

8️⃣ 마무리 정리

  • Driver는 뇌, Executor는 팔.
  • Core는 병렬성, Memory는 안정성.
  • 처음엔 4~6 Core, 8~16GB Memory로 시작하고, GC·Spill 로그로 조정하라.
728x90

'DE' 카테고리의 다른 글

[DE] Spark Streaming  (0) 2025.11.06
[DE] Redis 대신 HBase를 선택했는가?  (0) 2025.11.06
[DE] Kafka (replication.factor=3, min.insync.replicas=2)  (0) 2025.11.03
[DE] Kafka (acks=0, 1, all)  (0) 2025.11.03
[DE] Row-based vs Column-based  (0) 2025.11.03
댓글