Spark 실전 성능 튜닝 #Executor, #Shuffle, #GC

 

 

저번 주제에 이어서 이번에도 속도에 관련된

Spark Tuning Option (Executor 메모리, Shuffle 파라미터, GC)를 다뤄보려고 한다

---

Executor & Core 최적화

Spark는 클러스터 내에서 Executor라는 컨테이너들이 병렬로 작업을 수행한다.

→ 너무 많으면? 노드 메모리 부족, 컨텍스트 스위칭 비용 증가

→ 너무 적으면? CPU 코어 놀고 있음.

 

 

핵심 튜닝 파라미터

파라미터	설명
--num-executors	Executor 개수
--executor-cores	Executor당 CPU 코어 수
--executor-memory	Executor당 메모리 크기

 

권장 패턴

 

• 한 Executor당 3~5 Core
• Executor 메모리는 4~8GB (GC 병목 피하기)
• 코어당 1 Task → 코어 수 늘리면 동시 Task 처리량 증가

 

 

예: 적절한 설정 예시

클러스터에 16 Core, 64GB 메모리 머신 4대라면

--num-executors 8 \
--executor-cores 4 \
--executor-memory 8G

 

• 총 Executor 8개 → 머신당 2개 정도 → 코어 4개씩 사용
• 메모리는 Yarn Overhead 고려해 적당히 남겨둬야 한다

 

 

---

 

Shuffle 튜닝

 

Spark에서 느려지는 1순위 원인 → Shuffle.

Shuffle 파티션이 너무 작으면? → 작은 파일 다수 생성 → File I/O 폭증

너무 크면? → 한 Task가 처리할 데이터가 커져서 OutOfMemory 가능성 ↑

 

핵심 파라미터

파라미터	설명
spark.sql.shuffle.partitions	Shuffle 단계의 기본 파티션 수
spark.default.parallelism	RDD 연산 기본 파티션 수

 

• 기본값은 200 → 대용량 처리면 부족할 수 있음
• 일반적으로 데이터 크기(GB) x 2 ~ 3 정도가 적정

예: 1TB 처리라면 → 2000 ~ 3000 정도 적정

 

SET spark.sql.shuffle.partitions=3000;

 

---

 

GC 튜닝

 

대규모 Executor 메모리 사용 시 JVM GC 병목은 흔한 문제다.

 

!권장

• 메모리 너무 크게 주지 않기 (8GB 이상이면 GC Tuning 필요)
• GC 옵션 직접 지정 (G1GC 권장)

 

예: G1GC 옵션

--conf "spark.executor.extraJavaOptions=-XX:+UseG1GC"

 

• spark.memory.fraction (기본 0.6): 실행 메모리와 캐시 메모리 비율
• spark.memory.storageFraction (기본 0.5): Storage 영역 비율

필요하다면 이 값을 줄여서 캐시 → 실행 영역 확보.

 

 

---

 

전체 꿀팁 흐름 정리

출처 입력

 

항목	팁
Executor 설정	코어/메모리 적절히 쪼갬
Partition	Shuffle Partition 수 적절히 늘림
GC	G1GC 사용, 너무 큰 Heap 피하기
Broadcast Join	작은 테이블은 강제로 Broadcast
중간 결과	Temp Table로 단계 나눠서 I/O 최소화

 

---

 

실전 명령어 예

 

spark-submit \
  --master yarn \
  --num-executors 8 \
  --executor-cores 4 \
  --executor-memory 8G \
  --conf spark.sql.shuffle.partitions=3000 \
  --conf "spark.executor.extraJavaOptions=-XX:+UseG1GC" \
  --class com.example.MyJob my-spark-job.jar

 

 

---

 

 

마무리

 

• Spark는 메모리, 코어, 파티션, GC 네 가지가 핵심 튜닝 축이다.
• 잡이 느리면 항상 Spark UI 에서 Stage별로 Shuffle/GC 시간 확인.
• 쿼리만 고쳐도 80%는 빨라지고, 리소스 튜닝으로 20% 더 최적화할 수 있다.

 

 

 

 

 

학스의 개발일지