퀴즈: 쏠림

6문항. 정답과 해설은 풀어 본 뒤에 보여 드립니다.

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

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

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

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

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

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

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

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

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

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

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

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