Spark 기본기(Executor Tuning) / Part 01

• 1 클러스터 관리자 유형 
  • 1.1 Standalone 
  • 1.2 Apache Mesos
  • 1.3 Hadoop YARN
• 2 Spark의 Memory 관리
  • 2.1 Existing memory management
  • 2.2 Storage memory management
• 3 Spark를 띄울때 가장 기본적으로 설정해야하는 요소.Driver와 Executor의 사이즈와 개수는 어떻게 정하는 것이 좋을까?
  • 3.1 EXECUTOR의 역할
  • 3.2 다수의 작은 executor가 좋을까? VS 소수의 큰 executor가 좋을까?
    • 3.2.1 다수의 작은 executor의 두가지 문제
    • 3.2.2 소수의 큰 executor의 두가지 문제
    • 3.2.3 효율적 세팅을 위해서
  • 3.3 결론
• 4 Spark Application 실행 과정(흐름)
  • 4.1 요약
• 5 Reference

---

클러스터 관리자 유형 

Spark는 현재 3종류의 클러스터 관리자를 지원합니다.

 

Standalone 

a simple cluster manager included with Spark that makes it easy to set up a 
독립형 - 간단한 클러스터 매니저가 Spark에 포함되어있어 관리자는 클러스터를 쉽게 구성할 수 있습니다

Apache Mesos

a general cluster manager that can also run Hadoop MapReduce and service applications.
Apache Mesos - Hadoop의 MapReduce와 서비스 응용프로그램을 실행할 수 있는 일반적인 클러스터 관리자

 

Hadoop YARN

the resource manager in Hadoop 2.

Hadoop YARN – Hadoop 2. 의 리소스 매니저를 이용합니다.

 

현재 회사에 적용된 Cluster Mode는 Standalone Mode 입니다.

이유는 기관 특성상 제한적인 네트워크 및 컴퓨팅 자원을 이용해야 하기 때문입니다.

AWS, AZURE 등 클라우드 컴퓨팅을 사용하면, 대체적으로 YARN을 이용해서 관리합니다.

추후에 Driver Manager가 Down될시에 예비책으로 다른 Driver Manager를 사용합니다.

---

 

Spark의 Memory 관리

 

Existing memory management

Spark의 기존 메모리 관리는 정적인 메모리 분할(Memory fraction)을 통해 구조화 되어 있습니다.

메모리 공간은 3개의 영역으로 분리되어 있습니다. 각 영역의 크기는 JVM Heap 크기를 Spark Configuration에 설정된 고정 비율로 나누어 정해집니다.

• Execution: 이 영역은 Shuffle, Join, Sort, Aggregation 등을 수행할 때의 중간 데이터를 버퍼링하는데에 사용됩니다. 이 영역의 크기는 spark.shuffle.memoryFraction(기본값: 0.2)를 통해 설정됩니다.
• Storage: 이 영역은 주로 추후에 다시 사용하기 위한 데이터 블록들을 Caching하기 위한 용도로 사용되며, Torrent Broadcast(?)나 큰 사이즈의 Task 결과를 전송하기 위해서도 사용됩니다. 이 영역의 크기는 spark.storage.memoryFraction(기본값: 0.6)을 통해 설정됩니다.
• Other: 나머지 메모리 공간은 주로 사용자 코드에서 할당되는 데이터나 Spark에서 내부적으로 사용하는 메타데이터를 저장하기 위해 사용됩니다. 이 영역은 관리되지 않는 공간이기 때문에 더이상 언급하지 않을 것이며, 기본값은 0.2입니다.

각 영역 메모리에 상주된 데이터들은 자신이 위치한 메모리 영역이 가득 찬다면 Disk로 Spill됩니다. Storage 영역의 경우 Cache된 데이터는 전부 Drop되게 됩니다. 모든 경우에서 데이터 Drop이 발생하면 I/O 증가 혹은 Recomputation으로 인한 성능 저하가 나타나게 됩니다.

Storage memory management

Storage 영역은 BlockManager에 의해 관리된다. 주 사용 목적은 RDD Partition을 Caching하는 것이지만, Torrent broadcast나 Driver로 대규모 작업 결과를 보내는데에도 사용된다.

Storage Level

각 Block은 해당 Block이 Memory, Disk, Off-Heap 중 어디에 저장될지 명시하는 Storage Level에 연관되어 있다. Block은 Memory가 부족할 때 Memory에서 Disk로 Evict되어 Memory와 Disk 모두에 존재하는 경우도 있다.

Storage Level은 또한 Block이 Serialized 된 형태로 저장되는지 아닌지에 대해서도 명시합니다. MEMORY_AND_DISK_SER Storage Level은 특히 주목해야합니다. MEMORY_AND_DISK_SER Storage Level에서는 Block이 이미 Serialized 된 ByteArray 상태로 Memory에 존재하기 때문에 Disk로 Evict할 때 Serialize하지 않아도 되서 Evict 비용이 저렴합니다.

 

---

Spark를 띄울때 가장 기본적으로 설정해야하는 요소.
Driver와 Executor의 사이즈와 개수는 어떻게 정하는 것이 좋을까?

Executor에 관한 몇 가지 기본 전제를 확인해 봅시다.

• executor는 캐싱과 실행을 위한 공간을 갖고 있는 JVM입니다.
• executor와 driver의 사이즈는 하나의 노드나 컨테이너에 할당된 자원보다 많은 메모리나 코어를 가질 수 없습니다.
• executor의 일부 공간은 스파크의 내부 메타 데이터와 사용자 자료구조를 위해 예약되어야 한다. (평균 약 25%) 이 공간은 spark.memory.fraction 설정으로 변경 가능하며 기본값은 0.6으로, 60%의 공간이 저장과 실행에 쓰이고 40%는 캐싱에 쓰입니다.
• 하나의 partition이 여러개 executor에서 처리될 수 없다 : 하나의 partition은 하나의 executor에서 처리합니다.

EXECUTOR의 역할

1. 개별 작업을 실행하고 결과를 드라이버에 반환합니다.
2. 작업자 노드의 데이터를 캐시(지속)할 수 있습니다.

다수의 작은 executor가 좋을까? VS 소수의 큰 executor가 좋을까?

다수의 작은 executor의 두가지 문제

1. 하나의 파티션을 처리할 자원이 충분하지 않을 수도 있습니다.
2. 하나의 파티션이 여러개의 executor에서 계산될 수는 없습니다. 따라서 셔플, skewed 데이터의 캐시, 복잡한 연산의 transformation 수행 시 OOM 또는 disk spill이 생길 수 있습니다.
3. 자원의 효율적 사용이 힘듭니다.같은 노드내 executor끼리 통신에도 약간의 비용이 필요하다.
   1GB executor를 갖고 있는 경우 연산을 제외한 오버헤드에만 250MB, 거의 25% 수준의 공간을 써야할 수도 있습니다.

따라서 자원이 허용된다면, executor는 최소 4GB 이상으로 설정하는 것을 추천합니다.

소수의 큰 executor의 두가지 문제

1. 너무 큰 executor는 힙 사이즈가 클 수록 GC가 시작되는 시점을 지연시켜 Full GC로 인한 지연이 더욱 길어질 수 있습니다.
2. executor당 많은 수의 코어를 쓰면 동시 스레드가 많아지면서 스레드를 다루는 HDFS의 제한으로 인해 성능이 더 떨어질 수도 있습니다.
   Sandy Ryza(Advanced Analytics with Spark의 저자)는 executor당 5개의 코어를 최대로 보아야 한다고 제안합니다.(How-to: Tune Your Apache Spark Jobs (Part 2) - Cloudera Blog )
   경험적으로, 7–8개 이상의 코어 할당은 성능 향상에 도움도 되지 않을 뿐더러 CPU 자원을 불필요하게 소모하는 것으로 보입니다.

(Yarn에서 활용하는 경우 64GB 정도를 upper limit으로 보면 좋습니다.

효율적 세팅을 위해서

CPU 자원 기준으로 executor의 개수를 정하고, executor 당 메모리는 4GB 이상, executor당 core 개수( 1 < number of CPUs ≤ 5) 기준으로 설정한다면 일반적으로 적용될 수 있는 효율적인 세팅이라고 할 수 있습니다.
core와 memory size 세팅의 starting point로는 아래 설정을 잡으면 무난하게 실행되지 않을까 싶습니다.

결론

executor Memory는 최소 4GB 이상, executor 당 Core는 5개 이하

AWS 에서 제안하는 계산식 :

2022.02.07 - [Data Engineering/Apache Spark] - spark-submit 하드웨어 옵션 체크하기

spark-submit 하드웨어 옵션 체크하기

 

---

Spark Application 실행 과정(흐름)

사용자가 Spark를 사용할 때의 대략적인 실행 흐름은 다음과 같다.

1. 사용자가 Spark-submit을 통해 어플리케이션을 제출한다.
2. Spark Driver가 main()을 실행하며, SparkSession를 생성한다.
3. SparkContext가 Cluster Manager와 연결된다.
4. Spark Driver가 Cluster Manager로부터 Executor 실행을 위한 리소스를 요청한다.
5. Spark Context는 작업 내용을 task 단위로 분할하여 Excutor에 보낸다.
6. 각 Executor는 작업을 수행하고, 결과를 저장한다.

요약

사용자 프로그램을 수행하기 위하여, Spark Driver 내의 Spark Context가 Job을 task 단위로 쪼갠다.

Cluster Manager로부터 할당받은 Executor로 task를 넘긴다.

 

---

Reference

https://paranwater.tistory.com/414

Spark Cluster Manager Types (스파크 클러스터 매니저 타입 3종류 번역)

https://jaemunbro.medium.com/spark-executor-%EA%B0%9C%EC%88%98-%EC%A0%95%ED%95%98%EA%B8%B0-b9f0e0cc1fd8

[Apache Spark] Executor 사이즈와 개수 정하기

https://artist-developer.tistory.com/8

[Spark] 스파크 구조 및 실행 과정

https://blog.knoldus.com/understanding-the-working-of-spark-driver-and-executor/#:~:text=The%20central%20coordinator%20is%20called,Executors%20at%20all%20the%20time.