Suffle이란?

한 줄 정의

👉 Shuffle = 데이터가 네트워크를 타고 다른 Executor로 “재분배”되는 과정

---

왜 shuffle이 생기냐?

Spark는 원래 데이터를 **여러 조각(partition)**으로 나눠서 처리해.

그런데 어떤 연산은 같은 키를 가진 데이터가 한 곳에 모여야 해.

그때 발생하는 게 shuffle야.

---

shuffle이 생기는 대표 연산

아래 나오면 무조건 의심 👇

• groupBy
• join
• orderBy
• distinct
• repartition

예:

df.groupBy("user_id").count()

👉 user_id가 같은 row들을 한 Executor로 모아야 함

👉 그래서 데이터 이동 발생 = shuffle

---

그림 없이 비유로 이해하기 🎒

• 학생들이 교실 여러 곳에 흩어져 있음
• “같은 반끼리 모여!” 라고 지시함

👉 학생들이 교실을 옮겨 다님

👉 이 이동이 바로 shuffle

---

왜 shuffle이 느리냐?

shuffle은 동시에 3가지를 씀 ❌

1️⃣ 네트워크 I/O

2️⃣ 디스크 I/O (spill)

3️⃣ serialization / deserialization

👉 CPU보다 훨씬 느림

그래서:

• Spark 작업 느리다 = 대부분 shuffle 때문

---

shuffle 전 / 후 차이

❌ shuffle 있음

Executor A → 네트워크 → Executor B
Executor C → 디스크 → Executor D

✅ shuffle 없음

각 Executor가 자기 데이터만 처리

---

shuffle이 생겼는지 어떻게 아냐?

1️⃣ 코드로 바로 보임

groupBy / join / orderBy

2️⃣ Spark UI에서 확인

• DAG에 shuffle boundary
• Stage가 나뉘어 있음

---

그래서 최적화의 핵심은?

👉 shuffle을 줄이거나, 피하는 것

대표 방법:

• 작은 테이블 broadcast join
• join 전에 filter, select
• 불필요한 groupBy 제거
• 적절한 partition 설계

---

한 문장 요약 (면접용 ✨)

“Shuffle은 Spark에서 연산을 위해 데이터를 Executor 간에 재분배하는 과정으로, 네트워크와 디스크 I/O가 발생해 성능 병목의 주요 원인이 됩니다.”

---

이것만 기억해도 됨

• shuffle = 데이터 이동
• 느림 = 네트워크 + 디스크
• Spark 최적화 = shuffle 최소화

---

브로드캐스트 조인(broadcast join)

• *브로드캐스트 조인(broadcast join)**은 Spark 최적화에서 효과가 제일 큰 기술 중 하나야. 아주 쉽게 설명할게.

---

한 줄 정의

👉 작은 테이블을 모든 Executor 메모리에 복사해서,큰 테이블이 “이동 없이” 조인하는 방식

---

왜 이게 빠르냐?

일반 조인은 👇

• 큰 테이블 ↔ 큰 테이블
• 서로 데이터를 이동(shuffle) 해야 함 → 느림 ❌

브로드캐스트 조인은 👇

• 작은 테이블을 미리 전파
• 큰 테이블은 자기 자리에서 lookup만 함
• → shuffle 없음 ✅

---

그림 없이 비유로 이해하기 📘

• 큰 책(대용량 데이터)이 여러 교실에 나뉘어 있음
• 작은 참고표(작은 테이블)를 모든 교실에 한 부씩 복사

👉 학생(큰 테이블)이 이동할 필요 없이

👉 자기 교실에서 바로 참고표 보고 조인

---

언제 “작다”고 하냐?

정확한 기준은 없지만 보통 👇

• 수 MB ~ 수십 MB
• 수천 ~ 수십만 row
• 메모리에 충분히 올라가는 크기

핵심 기준: Executor 메모리에 올릴 수 있나?

---

코드로 보면 바로 이해됨

from pyspark.sql.functions import broadcast

df_big.join(
    broadcast(df_small),
    "user_id"
)

이 한 줄이 의미하는 것 👇

👉 df_small을 모든 Executor에 복사

---

broadcast 안 쓰면 어떻게 되나?

df_big.join(df_small, "user_id")

👉 Spark가 판단해서:

• 둘 다 크면 → shuffle join
• 작으면 → 자동 broadcast (안 될 수도 있음)

📌 그래서 명시적으로 broadcast 쓰는 게 안전

---

언제 쓰면 안 되나? ❌

• 테이블이 큼 (수백 MB 이상)
• Executor 메모리 부족
• 자주 바뀌는 대형 차원 테이블

👉 이때 쓰면 OOM(메모리 부족)

---

실무에서 자주 쓰는 패턴

예시

• clickstream (수억 row)
• product / user / category 테이블 (작음)

clicks.join(
    broadcast(products),
    "product_id"
)

👉 정석 중 정석

---

Spark는 자동으로 해주지 않나?

👉 가끔은 해주지만, 믿지 않는다

• 통계 부정확
• threshold 초과
• 계획 변경

📌 중요한 join은 직접 broadcast 지정

---

면접용 한 문장 ✨

“Broadcast join은 작은 테이블을 Executor 메모리에 복사해

shuffle 없이 큰 테이블과 조인하는 방식으로,

Spark 성능을 크게 개선할 수 있습니다.”

---

이것만 기억하면 됨

• broadcast join = shuffle 제거
• 작은 테이블일 때만
• 메모리 충분할 때만
• join 성능 체감 최고

---