クイズ: データの偏り

봇 한 명이 클릭의 40% 를 만든 자료를 사용자 ID 로 조인하는데 셔플 파티션 수를 200 에서 2,000 으로 늘렸다. 가장 느린 태스크는 어떻게 되는가?

• 태스크가 열 배로 늘어 가장 느린 태스크도 열 배 빨라진다
• 봇의 행이 모두 여전히 한 태스크로 가서 거의 줄지 않는다
• AQE 가 늘어난 파티션을 다시 합쳐 200 개로 되돌린다
• 해시가 봇의 행을 파티션 전체에 고르게 흩어 쏠림이 사라진다

스테이지의 쏠림을 수치로 알아보는 가장 알맞은 방법은?

• 스테이지 전체의 셔플 읽기 바이트를 전날과 견준다
• 실행기별 메모리 사용량의 평균을 본다
• 태스크별 셔플 읽기 레코드의 최대와 중앙값의 비를 본다
• 잡 수와 스테이지 수가 계획보다 많은지 센다

AQE 쏠림 조인이 어떤 셔플 파티션을 쏠렸다고 판정하는 기본 조건으로 맞는 것은?

• 중앙값의 5배보다 크고 동시에 256MB 보다 커야 한다
• 중앙값의 5배보다 크거나 64MB 보다 크면 된다
• 평균의 2배보다 크고 동시에 10MB 보다 커야 한다
• 파티션 크기와 상관없이 레코드 수가 백만을 넘으면 된다

솔팅으로 조인의 쏠림을 풀 때 치르는 대가로 맞는 것은?

• 큰 쪽 표의 행 수가 소금 값의 가짓수만큼 늘어난다
• 조인 결과에 같은 짝이 소금 값의 가짓수만큼 중복된다
• 브로드캐스트가 꺼져 반드시 정렬 병합 조인이 된다
• 작은 쪽 표를 소금 값의 가짓수만큼 복제해야 한다

같은 봇 자료에서 groupBy("user_id").count() 는 쏠림이 거의 없었다. 그 이유로 가장 정확한 것은?

• count 는 셔플 없이 드라이버에서 바로 계산되기 때문이다
• 셔플 앞의 부분 집계가 맵 태스크마다 키당 한 줄로 줄여 보내기 때문이다
• AQE 쏠림 최적화가 집계에도 똑같이 적용되기 때문이다
• groupBy 는 사용자 ID 가 아니라 행 번호로 파티션을 나누기 때문이다

사용자 표와 클릭 표의 외부 조인이 한 태스크에서 멈춘다. 그 태스크의 키가 null 이었다. 가장 먼저 할 일은?

• null 키 행은 어차피 짝이 없으니 먼저 걸러 따로 붙인다
• 셔플 파티션 수를 늘려 null 키가 여러 곳에 나뉘게 한다
• 브로드캐스트 임계값을 -1 로 바꿔 정렬 병합을 강제한다
• 드라이버 메모리를 늘려 null 키를 드라이버에서 처리한다