[Learning Spark] Chapter 2 : 아파치 스파크 다운로드 및 시작

 

스파크 셸에서 모든 처리가 하나의 머신에서 이루어지는 로컬 모드를 사용해보는 것으로 하자.

프레임워크를 익히며, 반복적 스파크 수행으로 빠르게 배울 수 있을거라 생각한다.

 

스파크 셸은 스칼라, 파이썬, R만 지원하지만, 스파크 애플리케이션은 자바 포함 다양한 언어로 작성 가능하고, 쿼리는 스파크 SQL로 실행할 수 있다. 실제로 복잡한 스파크 애플리케이션을 먼저 작성해볼 수 있지만, 분산 처리의 이득을 원하는 큰 데이터, 실무 작업에 로컬 모드는 적당하지 않고, YARN, 쿠버네티스 배포 모드를 써야 한다.

 

 

1단계 : 아파치 스파크 다운로드

https://spark.apache.org/downloads.html

Downloads | Apache Spark

위의 사이트로 가서 2번 드롭다운 메뉴에서 "Pre-built for Apache Hadoop"을 선택한다.

 

3번의 다운로드 링크를 클릭하면, 아래 링크로 리다이렉트가 된다.

여기서 아래의 tgz 파일을 클릭해준다.

*tgz 파일 : Gnu Zip(gzip) 압축 소프트웨어를 사용하여 압축된 여러 파일과 폴더로 구성된 TAR 아카이브 파일

 

다운로드가 다 되었다면, 

스파크의 디렉터리와 파일들을 확인할 수 있다.

 

그리고 나서 압축을 해제하고 다시 cd 로 그 디렉터리로 들어간다.

tar -xf spark-3.5.2-bin-hadoop3.tar

 

파일

그러면 아래와 같은 파일들을 볼 수 있다.

 

README.md

스파크 셸을 어떻게 사용하는지, 소스에서 어떻게 빌드하는지, 어떻게 단독 스파크를 실행하는지, 등의 상세한 설명

 

bin

스파크 셸들을 포함해(spark-sql, pyspark, spark-shell, sparkR) 스파크와 상호 작용할 수 있는 대부분의 스크립트를 가진다. 셸과 실행 파일은 나중에 spark-submit을 써 단독 스파크 애플리케이션을 제출하거나 쿠버네티스로 스파크를 실행할 때 도커 이미지를 만들고 푸시하는 스크립트 작성을 위해 사용

 

sbin 

다양한 배포 모드에서 클러스터의 스파크 컴포넌트들을 시작하고 중지하기 위한 관리 목적

 

kubernetes 

스파크 2.4 릴리스부터 쿠버네티스 클러스터에서 쓰는 스파크를 위한 도커 이미지 제작을 위한 Dockerfile들과 도커 이미지 빌드하기 전, 스파크 배포본을 어떻게 만들지에 대한 가이드 파일도 포함하고 있다.

 

data

MLlib, 정형화 프로그래밍, GraphX 등에서 입력으로 사용되는 *.txt 파일

 

examples

스파크는 자바, 파이썬, R, 스칼라에 대한 예제들을 제공한다.

 

-

스파크 연산

대화형 "셸"로 동작하며 광범위하게 사용되는 pyspark, spark-shell, spark-sql, sparkR 의 네가지 인터프리터들로 일회성 분석이 가능하다.

 

스파크 연산들은 저수준 RDD 바이트 코드인 작업(task)으로 변환되어 실행을 위해 스파크의 이그제큐터들에게 분산이된다.

 

애플리케이션 API를 써서 스파크 위에 돌아가는 사용자 프로그램으로, 드라이버 프로그램과 클러스터의 실행기로 이루어짐 SparkSession 스파크 코어 기능들과 상호 작용할 수 있는 진입점을 제공하며, 그 API로 프로그래밍을 할 수 있게 해주는 객체 스파크 셸에서 스파크 드라이버는 기본적으로 SparkSession을 제공하지만, 스파크 애플리케이션에서는 사용자가 SparkSession 객체를 생성해서 써야 한다. 잡(Job) 스파크 액션(action, save, collect)에 대한 응답으로 생성되는 여러 태스크로 이루어진 병렬 연산 스테이지(stage) 각 Job 은 스테이지라 불리는 서로 의존서응ㄹ 가지는 다수의 태스크 모음으로 나뉜다. 테스크(task) 스파크 이그제큐터로 보내지는 작업 실행의 가장 기본적인 단위

 

모든 스파크 애플리케이션의 핵심에 스파크 드라이버 프로그램이 있으며, 드라이버는 SparkSession 객체를 만든다.

스파크 셸을 써서 작업할 때 드라이버는 셸에 포함되어있는 형태에 SparkSession 객체가 미리 만들어진다.

 

 

스파크 잡(Spark Job)

드라이버는 스파크 애플리케이션 코드를 하나 이상의 스파크 잡(특정한 일을 수행하는 독립된 단위)이라는 단위로 분리시킨다.

그리고 각 잡은 DAG(방향성 그래프여서 순서 포함)로 변환하여 그래프에서 각 노드는 하나 이상의 스파크 스테이지에 해당한다.

 

 

스파크 스테이지(Spark Stage), 잡보다 작음

작업이 연속/병렬적으로 수행되는지에 맞춰 스테이지에 해당하는 DAG 노드가 생성된다. 모든 스파크 연산이 하나의 스테이지 안에서 실행될 수 없어, 여러 스테이지로 나뉜다.(멀티 프로세싱의 단위)

*셔플(shuffle) : 데이터를 서로 재분배하는 과정

 

트랜스포메이션, 액션, 지연 평가(Transformations, Actions, and Lazy Evaluation)

분산 데이터의 스파크 연산은 트랜스포메이션(transformation), 액션(action)으로 구분된다.

트랜스포메이션 : 불변성 특징을 가진 원본 데이터를 수정하지 않고 하나의 스파크 데이터 프레임을 새로운 데이터 프레임으로 변형한다.

예) select(), filter() - 원본 데이터 프레임을 수정하지 X, 새로운 데이터 프레임으로 연산 결과를 만들어 되돌림

=> 평가가 늦음, 즉시 계산 X, 계보(Lineage) 형태로 기록

기록된 리니지는 트렌스포메이션들끼리 재배열하거나 합치거나 해 더 효율적으로 최적화한다.

 

액션 : 기록된 모든 트랜스포메이션의 지연 연산을 발동

=> 유연성을 확보

 

아래 테이블을 확인해보면, Transformations의 연산 중에 join() 같은 연산이 오래 걸리는 연산인데,

매번 하면 오버헤드가 많으니, 한번에 모아서 하는 것

 

오,, 되게 스파크가 "대용량 데이터"를 부화없이, 어떻게 접근하려고 하는지 살짝 이해가 되어서 좋았다.
액션을 받을 때까지, 리니지 형태로 기록하는거는 속도 측면에서 많은 데이터들을 다룰때, 이 작은 차이가 큰 속도 차이를 만들어낼 수 있을 것 같다고 생각이 들었다.
스파크 ,, 재법 내 취향인데

 

 

좁은/넓은 트랜스포메이션(Narrow and Wide Transformations)

지연 연산 개념의 큰 이득은 스파크가 연산 쿼리를 분석하고 어디서 최적화할지 알 수 있음

-> 조인이나 파이프라이닝이 될 수 있고,

연산들을 한 스테이지로 합치거나,

반대로 어떤 연산이 셔플이나 클러스터 데이터 교환이 필요한지 등

 

 

- 좁은(Narrow)

: 입력 파티션을 연산해 하나의 파티션을 내놓는 트랜스포메이션

예) filter(), contains() - (하나의 파티션을 처리해 데이텨 교환없이 결과 파티션 생성)

- 넓은(Wide)

:  파티션으로부터 데이터를 읽어 합치고, 디스크에 쓰는 일

예) groupBy(), orderBy()

 

어떻게 최소화해야하는지는 사용자가 고민해야 한다.