Databricks 데이터 엔지니어 13강

이번 강은 스파크 잡의 성능 최적화를 다룬다.

느린 쿼리의 대부분은 셔플·조인·파티셔닝에서 비롯된다. 원인을 이해하고 튜닝 도구를 적용한다.

이 강의 목표는 다음과 같다.

• 셔플이 왜 비싼지 이해한다.
• 브로드캐스트 조인·AQE를 활용한다.
• 파티셔닝·캐싱을 올바르게 쓴다.

1. 셔플 (Shuffle)

join·groupBy 같은 넓은 변환(wide transformation)은 노드 간 데이터 재분배(셔플)를 일으킨다.

• 셔플은 네트워크·디스크 I/O가 커 비싸다.
• 데이터 스큐(특정 키에 쏠림)가 있으면 일부 태스크가 과부하된다.

2. 브로드캐스트 조인

큰 테이블과 작은 테이블을 조인할 때, 작은 쪽을 모든 노드에 복제하면 셔플 없이 조인한다.

from pyspark.sql.functions import broadcast
big.join(broadcast(small), "id")

3. AQE (Adaptive Query Execution)

AQE는 실행 중 실제 통계를 보고 계획을 조정한다.

• 셔플 파티션 수 자동 조정, 스큐 조인 분할, 조인 전략 전환.
• 기본 활성화되어 있으며, 대부분의 경우 켜 두는 것이 좋다.

4. 파티셔닝과 캐싱

• 파티셔닝: 적정 크기로. 고카디널리티 컬럼 파티셔닝은 과분할을 부르니 Liquid Clustering을 고려(9강).
• 캐싱: 반복해서 쓰는 중간 결과만 캐시한다. 남용하면 메모리를 낭비한다.

예제

예제) 수억 행 주문 테이블과 수천 행 상품 테이블을 조인하는데 셔플로 매우 느리다. 어떻게 개선하나?

해설) 작은 상품 테이블을 broadcast로 지정해 모든 실행 노드에 복제한다. 그러면 큰 테이블을 셔플하지 않고 로컬에서 조인해 훨씬 빨라진다. AQE가 켜져 있으면 크기를 보고 자동으로 브로드캐스트를 적용하기도 한다.

샘플 문제

문) 큰 테이블과 작은 테이블의 조인에서 셔플을 피하는 방법은?

• (A) 두 테이블 모두 파티셔닝
• (B) 작은 테이블을 브로드캐스트 조인
• (C) VACUUM 실행
• (D) 캐싱만 적용

정답: (B). 작은 테이블을 각 노드에 복제(broadcast)하면 큰 테이블 셔플 없이 조인해 성능이 크게 좋아진다.

정리

• join·groupBy 같은 넓은 변환은 셔플을 일으켜 비싸다.
• 큰↔작은 조인은 브로드캐스트로 셔플을 피한다.
• AQE가 실행 중 파티션·조인·스큐를 자동 조정한다.
• 파티셔닝은 적정 크기로, 캐싱은 반복 사용 데이터만.

다음 강에서는 보안과 거버넌스를 심화한다.