Quiz: Join strategies

브로드캐스트 해시 조인이 정렬 병합 조인보다 빠른 가장 근본적인 이유는?

• 큰 쪽 표가 셔플 없이 제자리에서 해시 표를 찾아보기 때문이다
• 양쪽 표를 모두 키로 정렬해 두 줄을 나란히 훑기 때문이다
• 드라이버가 조인 결과를 직접 계산해 태스크를 띄우지 않기 때문이다
• 작은 쪽 표를 디스크에 먼저 써 두고 필요할 때만 읽기 때문이다

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 조인 뒤 키가 다른 행만 남긴다, 양쪽 칼럼이 남는다