Catalyst와 Tungsten 두 백엔드로 최적화 된다
분석: DataFrame 객체의 relation을 계산, 컬럼의 타입과 이름 확인
Logical Plan 최적화
Physical Plan 만들기: Spark에서 실행 가능한 Plan으로 변환
코드 제너레이션: 최적화된 Physical Plan을 Java Bytecode로
SELECT zone_data.Zone, count(*) AS trips\
FROM trip_data JOIN zone_data \
ON trip_data.PULocationID = zone_data.LocationID \
WHERE trip_data.hvfhs_license_num = 'HV0003' \
Group By zone_data.Zone order by trips desc
Spark.sql("SELECT zone_data.Zone, count(*) AS trips\
FROM trip_data JOIN zone_data \
ON trip_data.PULocationID = zone_data.LocationID \
WHERE trip_data.hvfhs_license_num = 'HV0003' \
Group By zone_data.Zone").explain(True)
먼저 Parsed Logical Plan 이 실행 -> 사용자가 쓴 코드를 Logical Plan으로 변환
Zone과 trip 데이터가 join되고
필터되고
어그리게이트되고
정렬되는 순으로 아래서부터 역순으로 진행됨
다음으로 Analyzed Logical Plan이 실행 -> 사용자가 지정한 테이블에 무슨 컬럼이 있는지 확인을 함
join을 하고 필터링을 함
다음으로 Optimized Logical Plan이 실행 -> 필터링이 어차피 한 테이블 안에서만 이루어지는 것을 볼 수 가 있으니까 프로그램 자체에서 필터링을 안쪽으로 내림 (predicate pushdown???)
마지막으로 Physical Plan이 실행 -> 훨씬 더 detail한 plan
위 과정에선 그냥 join을 진행하였으나 BrodcastHashJoin을 사용 join의 유형까지 선택하는 단계predicate push down이란?
대부분의 쿼리 엔진은 필터링을 최대한 소스에 가깝게 적용하고자 한다. 소스에 가깝게 필터를 적용한다는 것의 의미는, 파일시스템에서 데이터를 읽어온 이후에 메모리에서 필터링 하는 것이 아니라, 파일을 읽을 때부터 꼭 필요한 데이터만 효율적으로 읽겠다는 것이다
출처: https://jaemunbro.medium.com/apache-spark-partition-pruning%EA%B3%BC-predicate-pushdown-bd3948dcb1b6
위 과정에서 나온 Physical Plan은 Tungsten으로 넘어가게 된다.