Shuffle은 적을 수록 좋다고 배웠다. 이는 wide transformation이 적용되기에 동기적으로 작업이 모두 끝날 때까지 기다리고, 네트워크 및 Disk I/O가 발생해 느려지기 때문이다.

그래서 repartition을 해서 shuffle이 일어나더라도 data locality를 늘려서 시간을 줄이려고 했었다. 그러나 자꾸 out of memory 오류가 나길래 너무 답답해서 default partition값인 10을 20, 100, 200개까지도 늘려보았고, cache도 해보았지만 여전히 오류가 많았다.

하지만, 묘수처럼 repartition(5)를 해보았는데, 이게 웬걸? 전보다 훨씬 빠른 속도로 성공해냈다. 더 찾아보니, Java의 garbage collection이 문제였다는 것을 알았다. 적은 파티션으로 한 번에 많은 일을 처리하니 collect 해야 할 garbage도 줄어들고, 셔플 횟수도 줄일 수 있다는 것을 발견했다. 단순히 코드단에서 action의 개수를 줄이는 것이 아니라 이런 방법도 있다는 것이 너무 신기했다.