러닝 스파크

 

 

p.2

구글 파일 시스템(Google File System, GFS),  맵리듀스(MapReduce, MR), 빅테이블(BigTable) 등을 만들어 내게 되었다. GFS가 클러스터 안에서 상용 서버에 장애 내구성이 있는 분산 파일 시스템을 제공한다면, 빅테이블은 GFS를 기반으로 구조화된 대규모 데이터의 저장 수단을 제공했다. 맵리듀스는 함수형 프로그래밍 개념을 기반으로 하여 GFS와 빅테이블 위에서 대규모 데이터 분산 처리가 가능한 새로운 병렬 프로그래밍의 패러다임을 소개했다.

 

좀 더 본질적으로는 맵리듀스 애플리케이션은 데이터를 애플리케이션으로 가져오는 게 아니라 맵리듀스 시스템과 연계하여 데이터의 지역성과 랙의 근접성 등을 고려해 데이터가 존재하는 곳으로 연산코드(맵 함수와 리듀스 함수)를 보내게 된다.

 

클러스터의 워커 노드들은 중간 연산을 통해 집계하고, 결과를 합쳐 리듀스 함수에서 최종 결과를 생산해서 이를 애플리케이션이 접근 가능한 분산 저장소에 기록한다. 이러한 접근 방식은 네트워크 트래픽을 크게 감소시키면서 네트워크로 데이터를 분산시키는 것을 지양하고, 로컬 디스크에 대한 IO를 극대화한다.

 

p.2-3

아파치 하둡은 야후 외부에서도 광범위하게 적용되고 수많은 오픈소스 커뮤니티의 기여자들과 두 곳의 오픈소스 기반 회사들(클라우데라 Cloudera와 호튼웍스 Hortonworks, 현재는 합병됨)에 영감을 주었지만, HDFS에서 돌아가는 맵리듀스 프레임워크에는 몇 가지 단점이 있었다.

 

첫째, 번거로운 운영 복잡도로 인해 관리가 쉽지 않았다. 

둘째, 일반적인 배치 처리를 위한 맵리듀스 API는 장황하고 많은 양의 기본 셋업 코드를 필요로 했으며, 장애 대응은 불안정했다.

셋째, 방대한 배치 데이터 작업을 수행하면서 많은 MR 태스크가 필요해지면 각 태스크는 이후의 단계들을 위해 중간 과정의 데이터를 로컬 디스크에 써야 했다. 이런 디스크 I/O의 반복적인 수행은 큰 타격이었으며, 거대한 MR을 처리하는 데 수 시간은 고사하고 수일까지 걸리는 경우도 있었다.

 

마지막으로, 하둡 MR은 일반적인 배치 처리를 위한 대규모 작업에는 적당하지만 머신러닝이나 스트리밍, 상호 반응하는 SQL 계통의 질의 등 다른 워크로드와 연계해 쓰기에는 한계가 있다. 

 

이런 새로운 종류의 워크로드를 다루기 위해서 엔지니어들은 용도에 딱 맞는 시스템들을 만들어내었고(아파치 하이브Hive, 아파치 스톰Storm, 아파치 임팔라Impala, 아파치 지라프Giraph, 아파치 드릴Drill, 아파치 마하웃Mahout 등), 이들은 각자 자신만의 API 및 클러스터 설정 방식, 추가적인 하둡 운영의 부담과 개발자가 배우기 어렵다는 단점이 있었다.

 

p.4

스파크 설계 철학의 중심에는 네 개의 핵심 특징이 있다.

 

- 속도

- 사용 편리성

- 모듈성

- 확장성

 

p.11

 

p.13

스파크의 매력적인 특징은 스파크가 여러 다른 환경에서 다른 설정으로 돌아갈 수 있도록 다양한 배포 모드를 지원한다는 것이다. 클러스터 매니저는 어디서 실행되는지에 대한 자세한 정보 없이도(스파크의 이그제큐터를 관리 가능하고 자원 요청이 잘 수행되는 환경이라면) 돌아갈 수 있도록 추상화되어 있기 때문에 스파크는 아파치 하둡 얀이나 쿠버네티스 같은 대부분의 인기 있는 환경에 배포 가능하며 서로 다른 모드들에서 동작한다. 

 

모드	스파크 드라이버	스파크 이그제큐터	클러스터 매니저
로컬	랩톱이나 단일 서버 같은 머신에서 단일 JVM 위에서 실행	드라이버와 동일한 JVM 위에서 동작	동일한 호스트에서 실행
단독	클러스터의 아무 노드에서나 실행 가능	클러스터의 각 노드가 자체적인 이그제큐터 JVM을 실행	클러스터의 아무 호스트에나 할당 가능
얀(클라이언트)	클러스터 외부의 클라이언트에서 동작	얀의 노드매니저의 컨테이너	얀의 리소스 매니저가 얀의 애플리케이션 마스터와 연계하여 노드 매니저에 이그제큐터를 위한 컨테이너들을 할당
얀(클러스터)	얀 애플리케이션 마스터에서 동작	얀(클러스터) 모드와 동일	얀(클러슽터) 모드와 동일
쿠버네티스	쿠버네티스 팟에서 동작	각 워커가 자신의 팟 내에서 실행	쿠버네티스 마스터

 

p.17

스파크 2.x와 3.0에서의 성능 향상은 SQL을 위한 카탈리스트(Catalyst) 옵티마이저 최적화 컴포넌트와 콤팩트한 코드 생성을 해 주는 텅스텐의 효과를 많이 보았고, 이는 데이터 엔지니어의 삶을 더 쉽게 만들어 주었다. 데이터 엔지니어들은 RDD, 데이터 프레임, 데이터세트의 세 가지 스파크 API 중 당면한 작업에 적합한 것을 선택하여 사용하며, 스파크의 장점을 누릴 수 있다.

 

p.29

분산 데이터의 스파크 연산은 트랜스포메이션(transformation)과 액션(action)으로 구분된다. 트랜스포메이션은 이미 불변성의 특징을 가진 원본 데이터를 수정하지 않고 하나의 스파크 데이터 프레임을 새로운 데이터 프레임으로 그 이름처럼 변형(transform)한다. 다시 말해 select()나 filter() 같은 연산은 원본 데이터 프레임을 수정하지 않으며, 대신 새로운 데이터 프레임으로 연산 결과를 만들어 되돌려 준다.

 

모든 트랜스포메이션은 뒤늦게 평가된다. 다시 말해 그 결과는 즉시 계산되는 게 아니라 계보(lineage)라 불리는 형태로 기록된다. 기록된 리니지는 실행 계획에서 후반쯤에 스파크가 확실한 트랜스포메이션들끼리 재배열하거나 합치거나 해서 더 효율적으로 실행할 수 있도록 최적화하도록 한다. 지연 평가는 액션이 실행되는 시점이나 데이터에 실제 접근하는 시점(디스크에서 읽거나 쓰는 시점)까지 실제 실행을 미루는 스파크의 전략이다. 

 

하나의 액션은 모든 기록된 트랜스포케이션의 지연 연산을 발동시킨다. 

 

p.44

RDD는 스파크에서 가장 기본적인 추상적 부분이다. RDD에는 세 가지의 핵심 특성이 있다.

 

- 의존성(dependency)

- 파티션(지역성 정보 포함)

- 연산 함수 : Partition  => Iterator[T]

 

p.50

스파크의 기본 데이터 타입

데이터 타입	파이썬에서 할당되는 값	초기 생성 API
ByteType	int	DataTypes.ByteType
ShortType	int	DataTypes.ShortType
IntegerType	int	DataTypes.IntegerType
LongType	int	DataTypes.LongType
FloatType	float	DataTypes.FloatType
DoubleType	float	DataTypes.DoubleType
StringType	str	DataTypes.StringType
BooleanType	bool	DataTypes.BooleanType
DecimalType	decimal.Decimal	DecimalType

 

 

p.51

스파크의 파이썬 정형화 데이터 타입

데이터 타입	스칼라에서 할당되는 값	초기 생성 API
BinaryType	bytearray	BinaryType()
TimestampType	datetime.datetime	TimestampType()
DateType	datetime.date	DateType()
ArrayType	list, tuple, array 중	ArrayType(datatype, [nullable])
MapType	dict	MapType(keyType, valueType, [nullable])
StructType	list 혹은 tuple	StructType([fields])
StructField	해당 필드와 맞는 값의 타입	StructField(name, dataType, [nullable])