728x90

🔍 Spark UI 병목 찾는 순서 (이대로 보면 됨)

0️⃣ 한 줄 요약

👉 Stages → Tasks → Shuffle → Executors

이 순서로 보면 90% 병목 찾음

1️⃣ Jobs 탭 – “어디서 오래 걸렸나?”

먼저 보는 것

Job 실행 시간
어떤 Job이 유독 김?

👉 제일 오래 걸린 Job 하나를 고른다

2️⃣ Stages 탭 – ⭐ 핵심

여기서 거의 다 보인다

체크 포인트

Stage 실행 시간
Shuffle Read / Write 있는 Stage
Stage 개수 (너무 많거나 적은지)

👉 시간 많이 먹는 Stage = 병목 후보

⚠️ 흔한 Stage 병목 패턴

Exchange, Sort, Aggregate
join 직후 Stage

👉 대부분 shuffle 문제

3️⃣ Tasks 탭 – “몇 개가 느린가?”

Stage 클릭 → Tasks 보면 👇

봐야 할 것

Task Duration 분포
몇 개 Task만 유독 김? (꼬리 길면 문제)

의미

Task 시간 고르지 않음
→ 데이터 스큐(skew) 가능성

👉 특정 key에 데이터 몰림

4️⃣ Shuffle Read / Write – 진짜 범인

Shuffle Read가 크면?

join / groupBy 과다
partition 수 부족

Shuffle Write가 크면?

repartition 남발
unnecessary shuffle

👉 Spark 병목의 70%는 shuffle

5️⃣ Executors 탭 – 리소스 병목 확인

체크리스트

Executor CPU 사용률
Memory 사용량
GC Time 비율

위험 신호

GC Time 비중 큼
Executor 자주 죽음
Task 실패 반복

👉 메모리 부족 / 캐시 과다

6️⃣ Storage 탭 – cache 문제 찾기

확인

cache된 DataFrame 있음?
메모리 점유율 과다?

👉 cache 했는데 한 번만 쓰면

→ 오히려 병목

🧠 병목 유형별 빠른 진단표

증상 원인 대응

Stage 시간 김	shuffle 과다	join/partition 점검
Task 몇 개만 김	데이터 스큐	salting, repartition
GC Time 큼	메모리 부족	cache 제거, memory 증가
Executor idle	partition 부족	repartition 증가
Executor 과부하	partition 과다	coalesce

🔥 실무에서 제일 자주 보는 병목 TOP 3

1️⃣ Join + Shuffle

해결: broadcast join, join key 점검

2️⃣ Partition 수 안 맞음

너무 적음 → CPU 놀음
너무 많음 → 오버헤드

3️⃣ 무지성 cache

cache → unpersist 안 함

면접용 30초 답변 (이거 외워도 됨)

“Spark UI에서는 먼저 Stages 탭에서

실행 시간이 긴 Stage를 확인하고,

Shuffle Read/Write 여부를 봅니다.

이후 Tasks 분포로 데이터 스큐를 확인하고,

Executors 탭에서 CPU·메모리·GC를 점검해

리소스 병목인지 판단합니다.”

마지막 핵심 문장

👉 Spark 병목 =‘shuffle + partition + memory’ 중 하나다.