[Hadoop] Spark 동작 단계

Spark는 Hadoop의 연산 프레임 워크 중 하나로서, 대규모 통합 분석 엔진으로 가장 범용적으로 쓰이는 기술 중 하나이다. 

이에 동작 단계에 대해 좀 더 상세히 알아보기 위해 블로그에 정리해보기로 했다.

해당 자료는 이전에 작성했던 글이다.
https://deep-flame.tistory.com/10

[Hadoop] 연산 프레임워크 (feat. MapReduce, Spark, Flink)

 

 

Spark의 동작 단계

---

Spark 동작 단계

 

크게 5단계로 이루어진다.

1. DataFrame이나 SQL Query 등의 코드를 제출한다.
2. 코드가 유효하다면, Spark는 코드를 Logical Plan으로 변환한다.
3. Logical Plan을 Catalyst Optimizer를 통해서 최적화과정을 진행한다.
4. 최적화된 Logical Plan이 어떻게 클러스터에서 실행될지 정의하는 Physical Plan이 생성된다.
5. 위의 단계가 완료되면 Spark는 Physical Plan을 실행/처리하고, 모든 계산을 수행하여 출력한다.

 

위에서 밑줄친 Logical Plan, Physical Plan에 대해 좀 더 상세히 알아볼 것이다.

 

 

 

1. Logical Plan

---

Logical Plan은 수행하는 모든 연산 단계에 대한 추상화이며, 클러스터의 Driver(마스터 노드) 또는 Executor(작업자 노드)에 대해 아무것도 참조하지 않는다.

Spark Context는 Logical Plan을 생성/저장하고, 이는 사용자의 표현을 최적화된 버전으로 변환한다.

 

Logical Plan

프로세스

설명에 앞서 Logical Plan은 3단계로 구분된다.
1. Unresolved Logical Plan or Parsed Logical Plan
2. Resolved Logical Plan or Analyzed Logical Plan or Logical Plan
3. Optimized Logical Plan

 

1. Unresolved Logical Plan

val file = spark.sparkContext.textFile(“…”)

위 코드를 SparkContext는 Spark가 이해할 수 있는 표현으로 변환하려고 시도한다. 그리고 그 첫번째 스텝이 Unresolved Logical Plan을 생성하는 것이다.

해당 코드는 유효하지만 열이름이나 테이블 이름이 정확하지 않거나 존재하지 않을 수도 있다. 따라서 우리는 이를 Unresolved Logical Plan이라고 부른다.

 

2. Resolved Logical Plan

dataFrame.select("age") // Column "age" may not exists

Spark는 Unresolved Logical Plan을 검사하기 위해 Analyzer와 Catalog를 이용한다. Catalog에는 Spark테이블, DataFrame, DataSet 그리고 Meta Store에서 가져온 데이터도 포함된다. 

검사 과정은 코드에서 표시되는 정보들이 실제로 존재하는지에 대한 검사이다. 만약 Analyzer가 테이블명(dataFrame)이나 칼럼명("age")를 resolve할 수 없다면 이를 기각하게된다. 반면 resolve한다면 Resolved Logical Plan을 생성한다.

 

3. Optimized Logical Plan

Optimized Logical Plan 생성

Resolved Logical Plan은 자체 규칙을 적용하고, 실행계획을 최적화하는 Catalyst Optimizer을 통과하게 된다. 

이는 맞춤형 수행을 위해 custom optimizer도 생성할 수 있다.

 

 

2. Physical Plan

---

Physical Plan

클러스터에서 Logical Plan을 어떻게 실행할지 간단히 정의한다. 이는 다양한 전략을 시도해보고, Cost Model을 이용하여 비교한다. 

만약 계획을 리소스와 실행시간으로 평가한다면 최적의 계획/전략이 "Best Physical Plan" 또는 "Selected Physical Plan"으로 선택될 것이다.

 

예시

우리가 2개의 table의 join쿼리를 실행한다고 하면 클러스터 내 다른 데이터 노드 안에 많은 다른 수의 파티션이 있는 Fat Table과 Thin Table이 있을 것이다.

예를 들어 남성 고객 테이블과 여성 고객 테이블을 Join한다고 했을 때, 남성 고객테이블은 많은 데이터 노드에 저장되어있을 것이다. 또한 이를 나이별로 파티션해서 보관한다고 했을 때, 한 데이터 노드 내 다수의 파티션이 있을 것이다.

Spark는 더 나은 최적화를 위해 어떤 파티션을 먼저 결합해야하는지 그리고 결합 유형은 어떻게 하는지에 대해 결정한다.

Best Physical Plan이 선택되면 클러스터에서 분산 방식으로 실행한 쿼리에 대한 실행 코드를 생성한다. 이 프로세스를 Codegen이라고 하며 이것은 Spark의 Tungsten의 실행 엔진이다.

 

 

참고
https://blog.knoldus.com/understanding-sparks-logical-and-physical-plan-in-laymans-term/
https://johnie-yeo.github.io/hello/back-end/2020/04/20/Spark%EB%8F%99%EC%9E%91%EB%8B%A8%EA%B3%84.html