Apache Spark — 느린 잡의 답은 실행 계획과 이벤트 로그에 있다 · 조인 전략 · 퀴즈
퀴즈: 조인 전략
6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.
브로드캐스트 해시 조인이 정렬 병합 조인보다 빠른 가장 근본적인 이유는?
- 큰 쪽 표가 셔플 없이 제자리에서 해시 표를 찾아보기 때문이다
- 양쪽 표를 모두 키로 정렬해 두 줄을 나란히 훑기 때문이다
- 드라이버가 조인 결과를 직접 계산해 태스크를 띄우지 않기 때문이다
- 작은 쪽 표를 디스크에 먼저 써 두고 필요할 때만 읽기 때문이다
Spark 4.2 에서 spark.sql.autoBroadcastJoinThreshold 의 기본값과, 자동 브로드캐스트를 끄는 값은?
- 기본 64MB, 0 으로 두면 끈다
- 기본 256MB, false 로 두면 끈다
- 기본 10MB, -1 로 두면 끈다
- 기본 1MB, none 으로 두면 끈다
한쪽에 BROADCAST 힌트, 다른 쪽에 MERGE 힌트를 붙였다. 문서가 말하는 동작으로 맞는 것은?
- 둘이 충돌하므로 분석 단계에서 오류가 나며 쿼리가 멈춘다
- BROADCAST 가 우선하고 MERGE 힌트는 무시된다는 경고가 남는다
- 나중에 적힌 힌트가 이기므로 적은 순서에 따라 결과가 달라진다
- 두 힌트를 모두 버리고 통계만으로 전략을 다시 고른다
AQE 가 실행 도중 정렬 병합 조인을 브로드캐스트 해시 조인으로 바꿨다. 이때 얻는 것과 못 얻는 것을 바르게 말한 것은?
- 셔플과 정렬을 모두 피하므로 처음부터 브로드캐스트한 것과 같다
- 셔플 파일을 다시 써야 하므로 오히려 정렬 병합보다 느려진다
- 브로드캐스트는 계획 단계에서만 정해지므로 실행 중에는 바뀌지 않는다
- 양쪽 정렬은 피하지만 이미 일어난 셔플 비용은 되돌리지 못한다
주문 표를 판촉 표와 상품 ID 로 조인했더니 합계 매출이 원래보다 커졌다. 가장 먼저 의심할 것은?
- 판촉 표에 같은 상품 ID 가 여러 줄 있어 주문 행이 곱해졌다
- 브로드캐스트된 표가 실행기마다 복사되어 행이 중복 집계되었다
- AQE 가 파티션을 합치면서 같은 파티션을 두 번 읽었다
- 셔플 파티션 수가 200 이라 결과가 200 개 파일로 나뉘었다
고객 가운데 주문이 한 번도 없는 사람만 고르려 한다. 가장 알맞은 조인과 그 결과 칼럼은?
- inner 조인 뒤 주문 칼럼이 null 인 행을 거른다, 양쪽 칼럼이 남는다
- right 조인으로 주문 쪽을 모두 남긴다, 주문 칼럼만 남는다
- left_anti 조인을 쓴다, 고객 쪽 칼럼만 남는다
- cross 조인 뒤 키가 다른 행만 남긴다, 양쪽 칼럼이 남는다