クイズ: シャッフルとパーティション数

AQE 를 끄고 30만 줄을 groupBy 한 뒤 바로 파일로 썼더니 결과 쪽 태스크가 200 개였다. 200 은 어디서 왔나?

• 입력 파일 블록 수에서 자동으로 계산되었다
• spark.sql.shuffle.partitions 의 기본값이다
• local[2] 의 코어 수에 100 을 곱한 값이다
• groupBy 키의 고유 값 개수와 같다

AQE 와 파티션 합치기를 기본값으로 켰다. 셔플 파티션을 합치는 기준에 대한 설명으로 옳은 것은?

• 무조건 advisoryPartitionSizeInBytes 64MB 에 맞춰 뭉친다
• 파티션을 합치지 않고 200 개를 그대로 쓴다
• parallelismFirst 가 true 라 목표 크기를 무시하고 최소 크기 1MB 만 지킨다
• 코어 수와 정확히 같은 개수로 다시 나눈다

100 개 파티션인 DataFrame 을 파일 10 개로 쓰고 싶다. 셔플 없이 파티션을 줄이는 방법은?

• coalesce(10)
• repartition(10)
• repartition(10, "day")
• spark.sql.shuffle.partitions=10

큰 자료를 무거운 변환 뒤 coalesce(1) 로 파일 하나로 썼더니 변환까지 느려졌다. 문서가 설명하는 원인은?

• coalesce 가 내부에서 셔플을 두 번 일으켰다
• 파일 하나를 쓸 때는 AQE 가 꺼지도록 되어 있다
• coalesce(1) 은 자료를 드라이버로 모아서 쓴다
• 셔플이 없어 앞 단계 계산까지 한 태스크로 합쳐졌다

RDD 가이드가 셔플 비용이 큰 이유로 드는 세 가지 조합은?

• 디스크 입출력, 자료 직렬화, 네트워크 입출력
• 드라이버 메모리, 가비지 수집, 로그 기록
• 파일 목록 조회, 스키마 추론, 압축 해제
• 코드 생성, 쿼리 파싱, 통계 수집

CSV 를 읽어 filter 와 withColumn 만 한 뒤 Parquet 으로 쓴 잡의 이벤트 로그를 보았다. 완료 스테이지 수로 가장 알맞은 것은?

• 변환마다 하나씩 스테이지 셋
• 읽기와 쓰기로 스테이지 둘
• 셔플이 없으므로 스테이지 하나
• 셔플 파티션 수와 같은 200