티스토리 뷰
728x90
1️⃣ Spark Driver & Executor 구조 이해
Spark 애플리케이션은 크게 Driver와 Executor로 구성된다.
구성요소역할
| 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️⃣ 리소스 산정 공식 (실무 절차)
- 노드 스펙 파악
→ 예: 16 vCPU / 64GB RAM - 노드당 Executor 개수 결정
→ 보통 1~2개 (GC/Shuffle 부담 고려) - Executor Core 수 산정
→ (vCPU - 1) ÷ Executor 수 → 7 Core - Executor Memory 산정
→ (64GB - OS 여유 10%) ÷ Executor 수 → 약 28GB - 총 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 |
댓글
250x250
공지사항
최근에 올라온 글
최근에 달린 댓글
- Total
- Today
- Yesterday
TAG
- Bot
- 테슬라 크레딧 사용
- 개리마커스
- COUNT
- 팔로워 수 세기
- 메디파크 내과 전문의 의학박사 김영수
- 김달
- 클루지
- 모델y
- follower
- 테슬라 레퍼럴 코드 확인
- 어떻게 능력을 보여줄 것인가?
- 레퍼럴
- 모델 Y 레퍼럴
- 테슬라 레퍼럴 적용 확인
- 테슬라 추천
- 테슬라
- 할인
- wlw
- 연애학개론
- 책그림
- 테슬라 리퍼럴 코드 생성
- 인스타그램
- 테슬라 리퍼럴 코드
- 유투브
- Kluge
- 테슬라 리퍼럴 코드 혜택
- 테슬라 레퍼럴
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | 4 | 5 | 6 | |
| 7 | 8 | 9 | 10 | 11 | 12 | 13 |
| 14 | 15 | 16 | 17 | 18 | 19 | 20 |
| 21 | 22 | 23 | 24 | 25 | 26 | 27 |
| 28 | 29 | 30 | 31 |
글 보관함