Spark 성능 튜닝

1. Spark Executor 는 몇개나?

instance는 개수, core 수가 중요

예를 들어, executor.instance가 10개, executor.core 수가 2 라면,

10개의 instance에 각각 core가 2개가 실행되므로, 총 20개.

거기에 executor.memory를 1G로 설정한다면 core당 memory가 할당되어 총 20G가 할당된다. 

- Kafka 를 소스로 한다면, Kafka 파티션 수를 보자. 파티션 당 core가 할당되는 것이 좋다.

1 task, 1 core

- 하나의 task를 1개의 core에서 처리하는데, 한번에 128MB 안으로 읽을 수 있도록 설정하는 것이 좋다.

기본이 128MB이기 때문. 넘어가면 그 만큼 나눠서 읽어야 하기 때문에 성능이 떨어진다. 

파티션의 크기가 코어 당 메모리 수를 결정한다.

 

2. Output partition 의 수

위에서 말한 것 처럼. 기본 HDFS의 블록 사이즈는 128MB이기 때문에 한번에 읽을 수 있도록 하려면 블록 사이즈가 128MB보다 안쪽으로 적재될 수 있도록 파티션 수를 조정해 주는 것이 좋다.

만약 집계 계산 결과인 경우, 파티션 10개에 쓰는데 집계 결과가 너무 작아서 불필요하게 파일 수만 많아 질 수 있다. 이런 경우는 오히려 줄여주는 게 좋다.

coalesce는 파티션을 줄일 때, repartition은 파티션 수를 늘리거나 줄일 때 사용하는데 repartition은 shffle이 발생할 수 있다.

필요하다면 적재할 row 수를 지정할 수 있는 기능도 있다.

 

3. Shuffle Partition
Spark 성능에 가장 크게 영향을 미치는 Partition이라고 한다.

Join, groupBy 등의 연산을 수행할 때 Shuffle Partition이 쓰이는데, 이것도 마찬가지로 128MB 안으로 처리될 수 있도록 설정해주는 것이 좋다. 그렇지 않으면 미처 처리하지 못한 데이터를 메모리 혹은 disk로 다시 넣어뒀다가 꺼내어 다시 처리하게 되는데 이 I/O로 인해 성능에 크게 영향을 미치게 된다. 

spill 발생 여부를 확인하고, DAG에서 어디서 작업이 지연되는지 확인하고. 

문제되는 구간을 찾으면, 쿼리를 수정한다. 이왕이면 집계 연산 전에 대상 테이블의 크기를 줄여주는 것이 좋겠지요?

만약 조인을 하는데, 한쪽에 데이터가 너무 몰린다(skew)싶으면, 데이터를 한번 보자. 만약 조인하는 테이블의 크기가 아주 작다면? 차라리 브로드캐스트해시조인을 적용하여 셔플이 발생하지 않도록 하는 것이 더 좋을 것이다.

 

 

 

 

참고

https://tech.kakao.com/posts/461

Spark Shuffle Partition과 최적화 - tech.kakao.com