| [Learning Spark] "Chapter 1 : 아파치 스파크 소개, 통합 분석 엔진"와 스터디 및 유튜브를 보고 정리한 내용입니다. |
아파치 스파크의 시작과 역사
컴퓨터 규모 측면에서, 우리가 가지는 데이터가 지속적으로 쌓이고, 많아짐으로
구글은
"어떻게 해야 수십억개가 넘어가는 페이지들을 빠르게 indexing을 해서 user에게 내줄수 있을까"
에 대한 고민에서 새로운 접근 방식이 필요했다.
- 기존의 RDBMS(관계형 데이터베이스)는 이런 문제를 해결하기가 어려웠음
그래서 구글 파일 시스템(Google File System, GFS), 맵리듀스(MapReduce, MR), 빅테이블(BigTable) 등을 만들었다.
*GFS : 클러스터 안에 상용 서버 장애 내구성이 있는 분산 파일시스템 제공(빅데이터들을 저장하고, 분산 파일 시스템 검색 빠르게 고안된 파일 시스템)
*빅테이블 : GFS를 기반으로 구조화된 대규모 데이터 저장 수단(Expend한 no-SQL DB를 GFS에 구축되어 대규모의 구조화된 데이터를 저장하고 관리하고 사용하는 것)
*맵리듀스 : 함수형 프로그래밍 개념을 기반으로, GFS/빅테이블 위에서 대규모 데이터 분산 처리가 가능한 병렬 프로그래밍(데이터 처리)
이 3가지 기술이 Apache(비영리적, 오픈소스 기반) 재단에 기증이 되었다.
하둡, 야후의 검색 엔진 시스템에서 채택이 되었다.
그러나 HDFS(하둡 파일 시스템)에서 돌아가는 맵리듀스 프레임워크는 몇가지 단점이 있었다.
1. 번거로운 운영 복잡도(Operational Complexity)
2. 배치 처리를 위한 맵리듀스 API는 장황하고, 불안정함(Verbose and Complex API)
설정하기 위해 수많은 boiler plate code 필요, 퍼포먼스 이슈
3. Performance issue : Disk I/O
방대한 배치 데이터 작업에서, 맵핑을 하는 중간 과정에서 입력한 데이터를 로컬 디스크에 읽고/쓰고/.. 과정을 반복
hard-Disk 물리적인 메모리 쓰고 읽는(I/O) 과정은 시간과 오버헤드로(time consuming & performance overhead) 퍼포먼스에서 불리한 한계점을 가짐
4. Limitations in handing diverse workload (하둡 MR은 머신러닝, 스트리밍, interactive SQL query 등 다른 워크로드와 연계하기 한계)
Apache Spark : Introduction
장점
- 속도(speed)
1. CPU 등의 하드웨어가 발달했는데, 멀티코어/쓰레드 기술과 L1, L2, L3 캐쉬 용량을 잘 활용하도록 설계됨
2. DAG(방향성 비순환 그래프, directed acyclic graph)로 이루어진 스케쥴러가 여러 클러스터(다양한 서버가 동시동작하는 분산 처리 환경 등) 병렬 프로세싱으로 속도 증가
3. 물리적 메인 엔진인 텅스텐(Tungsten)이 compact 코드를 일반화할 수 있음 - 전체적 코드 생성(whole-stage code generation)을 하고 있음(3장)
*DAG(방향성 있는 그래프) : 개념 설명
- 사용 편리성(Ease of use)
RDD(Resilent distributed dataset, 논리적인 유연한 분산 데이터 구조의 추상) 자료구조 제공
데이터 프레임, 데이터 셋이 위에 구축 -> 사용자가 밑의 수준의 이해가 없어도 기존에 있던 이해로 사용 가능
스파크는 내부적으로 트랜스포메이션(transformation)과 엑션(action)을 통해 어플리케이션과 언어를 지원
- 모듈성(Modularity)
다양한 프로그래밍 언어(scalar, java, python, sql, R 등), 핵심 컴포먼트(스파크 SQL, 스파크 정형화 스트리밍, 스파크 MLlib, GraphX) 존재, 문서화된 API를 제공하여 여러 워크로드를 하나의 스파크 엔진에서 실행 가능
- 확장성(Extensibility)
저장소와 계산을 포함하는(아파치 하둡은 data store, search, update가 하나의 모듈, 그러나 스파크는 분리) 다양한 소스에 저장된 데이터를 모두 읽어오고, 메모리단에서 처리하여 유연함 제공
단일화된 스택의 아파치 컴포먼트(Apache Spark components as Unified stack)
4개의 다양한 워크로드르르 위한 라이브러리(책 기준, 스파크 SQL, MLlib, 정형화 스트리밍, GraphX)
API를 써서 스파크 애플리케이션을 만들면, 스파크 코어 엔진이 적절한 DAG로 변환해 실행한다.
스파크가 내부적으로 사용할 라이브러리를 spark core engine과 별도의 API를 사용하여 다양한 언어에서 애플리케이션을 만들고
내부적으로 방향성 그래프(DAG)로 전환 후, 코어 엔진에서 실행
아파치 스파크의 분산 실행(Apache Spark's Distributed Execution)
하나의 스파크 애플리케이션은 스파크 클러스터의 병렬 작업을 조율하는 하나의 드라이버 프로그램으로 이루어진다.
드라이버는 SparkSession 객체를 통해 클러스터의 분산 컴포넌트(스파크 이그제큐터executor와 클러스터 매니저)들에 접근한다.
Spark Application
: 사용자가 작성한 코드 자체(스칼라, 자바, 파이썬 등)
사용자와 인터렉션하면서, 상호작용을 코딩 레벨에서 적용
스파크 드라이버(Spark Driver)
: 스파크의 실행을 총괄하는 마스터 프로세스
- 클러스터 매니저와 통신하여 스파크 이그제큐터를 위해 자원 요청
- 스파크 작업 DAG 연산 형태로 변환
- 스케쥴링, 각 실행 단위를 태스크로 나누어 스파크 이그제큐터에게 분배
- 자원이 할당되면, 드라이버-이그제큐터 직접 통신
클러스터 매니저(Cluster Manager)
: 리소스를 관리 및 할당, 클러스터 내에 워크로드들을 관리하고, 드라이버, 어플리케이션을 위한 리소스 할당하고 빼앗음
예) 내장 단독(Standalone) 클러스터 매니저, 아파치 하듑 얀(YARN), 아파치 메소스(Mesos), 쿠버네티스(kubernetes)
Spark Session
드라이버와 클러스터와 연결을 담당하는 엔트리 포인트, 시작점으로 애플리케이션에서 접근하기 위한 지점이 됨
- 데이터 소스에서 데이터 읽고, 메타데이터 접근, 스파크 SQL 질의 수행
스파크 이그제큐터
: 클러스터의 각 워커노드에서 동작, 드라이버 프로그램과 통신하며 워커에서 할당된 task 실행
배포 모드에서 노드당 하나의 이그제큐터, 로컬 머신에는 하나만
배포 모드
다양한 디플로이먼트 모델을 지원
분산 데이터와 파티션
실제 물리적 데이터는 HDFS, 클라우드 저장소에 존재하는 파티션이 되어 저장소 전체에 분산
데이터가 파티션으로 물리적 분산되어, 스파크는 각 파티션을 고수준에서 논리적 데이터 추상화(메모리의 데이터 프레임 객체_로 간주함
스파크 이그제큐터는 데이터 지역성 고려하여 네트워크에서 가장 가까운 파티션을 읽어 들이도록 task 할당
=> 효과적 병렬 처리(parallel processing) 가능