쿼리 계획

쿼리 계획이란?

: 작성한 코드가 실제 클러스터에서 실행 가능한 저수준 연산으로 변환되는 핵심 과정으로 로지컬 플랜과 피지컬 플랜으로 이어지며, Catalyst Optimizer가 최적화를 담당

분석 → 논리적 계획 → 물리적 계획 → 코드 생성의 단계를 거쳐 입력한 코드를 즉시 실행 않고 최적의 경로를 찾음

1. 분석 : 사용자가 작성한 SQL이나 DF 코드의 컬럼 이름, 테이블 이름 등이 실제 데이터와 일치하는지 카탈로그를 통해 확인
2. Logical Planning : 무엇을 할 것인지 정의
   • Unresolved Logical Plan : 쿼리문의 문법 등을 확인을 하는 것으로 쿼리를 parsing 한 후 처음으로 실행
     
     • 이상한 특수문자나 구문적 오류가 있으면 걸러짐.
   • Catalog : 테이블에 대한 정보를 저장하는 메타 데이터
   • Analyzed Logical Plan(with Catalog) : 사용자가 코드 작성하면 코드가 말이 되는지 확인
     • 참조 확인 : select("col1")이라고 쓰면, 실제 col1이라는 컬럼 있는지, 테이블 이름 맞는지를 catalog통해 확인
     • 의미적 정당성 검사 : 문법뿐만 아니라 데이터 타입이 연산에 적합한지를 검사
     • 이 과정 통과하면 논리적이라고 판단되어 Analyzed Logical Plan이 됨
   • Optimized Logical Plan : 논리적으로 문제가 없으면 Catalyst Optimizer가 개입해 "어떻게 하면 더 효율적으로 데이터를 처리할까"
     • Predicate 푸시다운 : 필터링 연산을 최대한 데이터 소스와 가까운 쪽으로 밀어넣는 것
       • 100만 건 다 읽은 후 10건만 고르는 것이 아니라, 읽을 때부터 조건에 맞는 10건만 가져와
     • Projection Pruning : 실제로 최종 결과에 필요한 컬럼만 골라서 읽는 것
     • Constant Folding : 실행 시점에 계산할 필요가 없는 상수 식을 미리 계
3. Physical Planning : 어떻게 실행할 것인지 정의
   • Candidate Physical Plans : 최적화된 로지컬 플랜을 받아 실행 가능한 여러가지 후보를 만듦
     • 다양한 전략 수립 : 조인을 할때 한쪽 테이블이 작다면 모든 노드에 뿌려서 처리할지, 아니면 데이터를 다 섞어 처리할지 고민
   • Cost-based Optimization : 가성비 좋은 거 선택
   • Final Physical Plan : CBO를 통해 선택된 단 하나의 계획
     • 실행 지침서: 이 계획에는 Scan, Join, Shuffle 등 클러스터 전반에서 일어날 모든 물리적 연산과 순서가 명시
     • 최종 계획은 RDD의 DAG로 변환돼 실제 실행을 위해 executor로 전달 
4. 코드 생성 : 최적화된 물리적 계획을 실제 Java 바이트 코드로 변화
5. Adaptive Query Execution(AQE, 적응형 쿼리 실행)
   1. Dynamic Shuffle Partitioning : 실제 데이터 크기에 맞춰 셔플 파티션 수를 자동으로 조절해 성능을 최적화
   2. BroadCast Join Optimization : 실행 중 데이터가 충분히 작다고 판단 되면 셔플 조인을 브로드캐스트 조인으로 즉시 전환
   3. Skewed Join Handling : 데이터 쏠림(Skew) 현상을 감지하고 큰 파티션을 쪼개어 연산 속도를 맞춤

SELECT * FROM large_tbl JOIN small_tbl ON id

AQE가 없으면 : 데이터들을 셔플해서 조인

AQE가 있으면 : small_tbl을 브로드캐스트로 전환 후 브로드캐스트 조인

• 브로드캐스트 조인? 
  : 작은 크기의 테이블을 드라이버에서 읽어 모든 실행 노드(executor)로 통째로 복사(broadcast)해 전달하는 조인방식
  • 각 노드는 메모리에 올라온 작은 테이블과 큰 테이블의 파티션을 로컬에서 즉시 조인, 셔플 과정이 발생하지 않아 네트워킹 오버헤드가 획기적으로 줄어