Dynamic Partition Pruning — 조인 상대편 필터를 파티션 스캔에 재사용하기
Spark Dynamic Partition Pruning 및 RocksDB State Store Provider 공식 문서 종합 (웹 리서치, 2026) — Apache Spark 공식 문서(structured-streaming-programming-guide.html) + Apache Spark JIRA(SPARK-11150) + 커뮤니티 기술 블로그 Apache Spark JIRA SPARK-11150 및 커뮤니티 기술 자료
이 모듈을 다 읽으면
- DPP가 Predicate Pushdown과 Broadcast Hash Join의 원리를 어떻게 결합하는지 설명할 수 있다
- DPP가 브로드캐스트를 '재사용'한다는 게 정확히 무엇을 의미하는지 설명할 수 있다
spark-learn-42에서 다룬 4가지 물리적 조인 전략 중 Broadcast Hash Join을 전제로, 파티셔닝된 큰 테이블과 작은 테이블을 조인할 때 큰 테이블의 파티션 스캔 자체를 조인 필터로 미리 걸러내는 Spark 3.0+ 기본 최적화인 Dynamic Partition Pruning(DPP)을 정리한다.
문제 상황 — 파티셔닝된 큰 테이블을 필터 없이 전체 스캔
예를 들어 날짜로 파티셔닝된 대용량 orders 테이블을, 소규모 dim_region 테이블에서 특정 지역 조건으로 필터링한 뒤 region_id로 조인하는 쿼리를 생각해보자. 정적 분석만으로는 orders 테이블에 region 관련 필터 조건이 코드상 직접 없으므로, 옵티마이저가 orders의 파티션 프루닝을 걸 근거가 없어 관련 없는 파티션까지 전부 스캔하게 된다 — 정작 필요한 정보(어떤 region_id들이 실제로 조인에 참여하는지)는 조인 상대편인 작은 테이블을 필터링한 '이후'에야 알 수 있다는 게 핵심 문제다.
핵심 포인트
- 정적 분석 시점엔 파티셔닝된 큰 테이블에 필터 조건이 명시적으로 없어 프루닝 근거가 없음
- 필요한 필터 정보(실제 조인에 참여하는 키 값들)는 조인 상대편 테이블을 걸러낸 '이후'에야 알 수 있다는 게 핵심 문제 상황
DPP의 해법 — Broadcast Hash Join의 결과를 그대로 파티션 필터로 재사용
DPP는 작은 쪽 테이블(빌드 사이드)을 필터링·브로드캐스트하는 Broadcast Hash Join 과정에서 이미 만들어진 브로드캐스트 해시 테이블을, 큰 쪽 테이블(프로브 사이드)의 파티션 스캔에 대한 동적 필터로 그대로 재사용한다 — spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcastOnly(기본값 true) 설정이 이 재사용 여부를 결정한다. 즉 작은 테이블을 위해 어차피 계산해야 했던 브로드캐스트 해시 테이블에서 고유 키 값들을 뽑아, 그 키 목록을 큰 테이블의 파티션 필터로 주입하는 서브쿼리를 추가로 실행하는 방식이다. 핵심은 큰 테이블 조인 대상 데이터를 위해 작은 테이블을 '두 번 스캔'하지 않는다는 점 — 조인에 필요해서 어차피 만든 브로드캐스트를 그대로 재활용할 뿐이다.
핵심 포인트
- DPP는 Broadcast Hash Join에서 이미 만든 브로드캐스트 해시 테이블을 그대로 재사용해 큰 테이블의 파티션 필터로 주입 — 작은 테이블을 추가로 다시 스캔하지 않음
- spark.sql.optimizer.dynamicPartitionPruning.reuseBroadcastOnly(기본 true)가 브로드캐스트 재사용 여부를 제어