스파크를 다루는 기술.md

서평

• 스파크를 공부하면서 스파크 완벽 가이드를 본격적으로 읽기 전에 실무에서 도움이 되는 책을 고민하다가 스파크를 다루는 기술을 사서 읽었다.
• 아파치 스파크에서부터 스파크의 기초, 스파크 애플리케이션, 스파크 API, 스파크 SQL, 스파크 스트리밍, 스파크 ML,DL,GraphX, 스파크옵스, 스파크 클러스터, YARN 클러스터, 메소스 클러스터 등 스파크에 관한 전반적인 개념과 원리에 대해 배울 수 있어서 좋았고 각 장마다 실습코드가 있어서 많은 도움이 되었던거 같았다
• 실무에서 쓰던 YARN 클러스터나, 스파크 SQL, 배치에 대해서 전체적인 틀을 잡아줘서 좋았고 앞으로의 공부 방향에 대해 다듬을 수 있어서 좋았다.
• 이 책은 다양한 스파크 기능에 대한 유용한 지식을 전달하고 있으며 코드 설명을 통해서 읽는데 친숙하게 다가오며 실습을 할 수 있다는 점에서 메리트가 있었다. 스파크를 공부하고자 하는 분들은 기본서를 읽기 전에 큰 플로우를 확인할때 보면 좋을거 같다.

아파치 스파크

• 아파치 스파크
  • 고속 범용 분산 컴퓨팅 플랫폼
  • 분산 아키텍처 때문에 처리 시간에 약간의 오버헤드(overhead : 어떤 연산을 처리하는 데 별도로 필요한 간접적인 컴퓨팅 리소스를 의미)가 필연적으로 발생
  • 하둡 생태계의 여러 도구가 제공한 다양한 기능을 플랫폼 하나로 통합함, 실시간 스트림 데이터 처리 , 머신 러닝, SQL 연산, 그래프 알고리즘, 일괄 처리 등 여러 종륳의 프로그램을 단일 프레임워크에서 구현 할 수 있음
• 아파치 하둡
  • 분산 컴피팅용 자바 기반 오픈소스 프레임워크로 하둡 분산 파일 시스템(Hadoop Distributed File System, HDFS)과 맵리듀스 처리 엔진으로 구성됨
• 스파크를 구성하는 컴포넌트
  • 스파크 코어
    • RDD(Resilent Distributed Dataset) : 스파크 API의 핵심 요소, RDD는 분산 데이터 컬렉션(즉, 데이터셋)을 추상화한 객체로 데이터셋에 적용할 수 있는 연산 및 변환 메서드를 함께 제공
      • 불변성(immutable) : 읽기 전용(read-only)
      • 복원성(resilient) : 장애 내성
      • 분산(distributed) : 노드 한 개 이상에 저장된 데이터셋
    • HDFS, GlusterFS, 아마존 S3 등 다양한 파일 시스템에 접근할 수 있음
    • 공유 변수(broadcast variable)와 누적 변수(accumulator)를 사용해 컴퓨팅 노드 간에 정보를 공유할 수 있음
    • 네트워크, 보안, 스케줄링 및 데이터 셔플링(shuffling)등 기본 기능이 구현되어 있음
• 데이터 파티셔닝
  • 데이터를 여러 클러스토노드로 분할하는 메커니즘
  • 스파크의 성능과 리소스 점유량을 크게 좌우할 수 있는 RDD의 가장 기본적인 개념
  • 스파크 클러스터 : 병렬 연산이 가능하고 네트워크로 연결된 머신(즉, 노드)의 집합
  • RDD 파티션(과거에는 스플릿) : RDD 데이터의 일부(조각 또는 슬라이스)를 의미함
    • 스파크에서 RDD 파티션 개수는 매우 중요, 파티션 개수가 데이터를 클러스터에 분배하는 과정에 영향을 미칠 뿐만 아니라 해당 RDD에 변환연산을 실행할 태스크 개수와 직결되기 때문
  • HashPartitioner
    • 각 요소의 자바 해시 코드를단순화mod 공식에 대입해 파티션 번호를 계산
    • 각 요소의 파티션 번호를 거의 무작위로 결정하기 때문에 모든파티션을 정확하게 같은 크기로 분할할 가능성이 낮음
    • 대규모 데이터셋을 상대적으로 적은 수의 파티션으로 나누면 대체로 데이터를 고르게 분산시킬 수 있음
  • RangePartitioner
    • 정렬된RDD의 데이터를 거의 같은 범위 간격으로 분할할 수 있음
    • 대상 RDD에서 샘플링한 데이터를 기반으로 범위 경계를 결정
• 데이터 셔플링
  • 파티션 간의 물리적인 데이터 이동
  • 셔플리은 새로운 RDD의 파티션을 만들려고 여러 파티션의 데이터를 합칠 때 발생
    • 맵 태스크 : 셔플링 바로 전에 수행한 태스크
    • 리듀스 태스크 : 바로 다음에 수행한 태스크
• 스파크의 DAG : RDD를 정점으로 RDD 의존 관계를 간선으로 정의한 그래프
• 체크포인팅(checkpointing) : 스파크는 장애 발생 이전에 저장된 스냅샷을 사용해 이 지점부터 나머지 계보를 다시 계산함

스파크SQL

• SparkSession : SparkContext와 SQLContext를 통합한 래퍼(wrapper) 클래스
• DataFrame을 저장하고 불러오기
  • MySQL 및 PostreSQL 관계형 데이터베이스와 스카를 연동하는 Dialect 클래스(JDBC의 JdbcType 클래스와 스파크 SQL의 DataType클래스를 매핑하는 클래스)를 제공
  • JSON
    • XML을 대체하는 경량(lightweight) 데이터 포맷
    • 스파크는 JSON 스키마를 자동으로 유추할 수 있기 때문에 외부 시스템과 데이터를 주고받는 포맷으로 매우 적합
    • 데이터를 영구적으로 저장하는 데 사용하기에는 저장 효율이떨어진다는 단점
    • 포맷이 간단하고 사용이간편하며 사람이 읽을 수 있는형태로 데이터를 저장
  • ORC(Optimized Row Columnar)
    • 하둡의 표준 데이터 저장 포맷인 RCFile 보다 효율적으로 하이브의 데이터를 저장하도록 설계된 파일 포맷
    • 칼럼형 포맷 : 각 로우의 데이터를 순차적으로 저장하는 로우 포맷과 달리 각 칼럼의 데이터를 물리적으로 가까운 위치에 저장하는 방식을 의미
    • 로우 데이터를 스트라이프(stripe) 여러 개로 묶어서 저장
    • 파일 끝에는 파일 푸터(file footer)와 포스트 스크립트(postscript)영역이 있음
      • 파일 푸터 : 파일의 스트라이프 목록과 스트라이프별 로우 개수, 각 칼럼의 데이터 타입을 저장
      • 포스트 스크립트 영역 : 파일 압축과 관련된 매개변수들과 파일 푸터의 크기를 저장
  • Parquet
    • 불필요한 의존 관계를 가지지 않으며 특정 프레임워크에 종속되지 않도록 설계됨
    • 칼럼별로 압축 방식을지정
    • 중첩된(nested) 복합 데이터 구조에 주점을 두고 설계
    • LZO, Snappy, GZIP 등 압축 라이브러리를 지원, 각 칼럼의 청크별로 최솟값과 최댓값의 통계를 저장해 쿼리를 실행할 때 일부 데이터를 건너뛸 수 있도록 연산을 최적화
  • 카탈리스트 최적화 엔진(Catalyst optimizer) : DataFrame과 Dataset의 두뇌, DataFrame DSL과 SQL 표현식을 하위 레벨의 RDD 연산으로 변환
  • 텅스텐 엔진 : 객체(정수형,문자열,튜플 등)를 이진수로 인코딩하고 메모리에서 직접 참조하는 방식으로 메모리 관리 성능을 개선
    • 온-힙 할당 모드 : 이진수로 인코딩한 객체를 JVM이 관리한느 대규모 long 배열에 저장
    • 오프-힙 할당 모드 : sun.misc.Unsafe 클래스를 사용해 마치 C 언어처럼 메모리를 주소로 직접 할당하고 해제

스파크 스트리밍 애플리케이션

• 스파크
• 확장성과 장애 내성을 갖춘 시스템
• 강력한 대규모 데이터 분석 기능 외에도 동일한 API로 스트리밍 프로그램과 일괄 처리 프로그램을 모두 지원하는 통합 플랫폼을 제공
• 실시간 레이어와 배치 레이어를 결합한 람다 아키텍처(lambda architecture)를 구축
• 하둡과 호환되는 여러 파일 시스템(HDFS,아마존 S3)과 다양한 분산 시스템(플럼,카프카,트위터)에서 데이터를 읽어 들일 수 있는 커넥터를 제공
• 아파치 카프카 : 확장성을 갖춘 분산 메시지 큐(queue) 시스템, 데이터 소스 및 저장 대상으로사용
• 스파크클러스터 매니저 : 스파크 자체 클러스터, YARN 클러스터, 메소스 클러스터
• 외부 데이터 소스
  • 카프카 : 빠른 성능과 확장성을 갖춘 분산 발행-구독(publish-subscribe) 메시징 시스템, 모든 메시지를유지하며 ,유실된 데이터를 재전송할 수 있음
  • 플럼 : 대량의 로그 데이터를 안정적으로 수집, 집계, 전송할 수 있는 분산 시스템
  • 아마존 Kinesis : 카프카와 유사한 아마존 웹 서비스의 스트리밍 플랫폼
  • 트위터 : 인기 소셜 네트워크인 트위터가 제공하는 데이터 API
  • ZeroMQ : 분산 메시징 시스템
  • MQTT : 경량(lightweight) 발행-구독 메시징 프로토콜
• 스파크-카프카커넥터
  • 다이렉트 커넥터(direct connector)
    • 입력된 메시지를 정확히 한 번(exactly-once) 처리함
  • 리시버 기반 커넥터(receiver-based connector)
    • 메시지 한 개를 여러 번 읽어 옴
    • 데이터 유실을 방지하려고 로그 선행 기입(write-aheda logging) 기법을 사용, 그만큼계산 속도가 감소
• 스파크 스트리밍의 잡 성능
  • 성능 개선
    • 처리 시간 단축
      • 스케줄링이 지연되면 가장 먼저 스트리밍프로그램의 최정화를 시도한 배치당 처리 시간을 최대한 단축
      • 외부 시스템으로 데이터를 전송한다면 파티션 내에서 커넥션을 재사용하고 커넥션 풀링(connection pooling) 등 기법을 활용
      • 미니배치 주기를 더 길게 늘림
        • 잡 스케줄링, 태스크 직렬화, 데이터 셔플링 등 공통 작업에 걸리는 시간이 더 많은데이터로 고르게 분산되면서 개별 데이터 레코드당 처리 시간이 감소
        • 너무 길면 각 미니배치에 필요한 메모리양이 증가함
        • 클러스터 리소스를 추가로 투입해 처리시간을 단축함
    • 병렬화 확대
      • 모든 CPU 코어를 효율적으로 활용하고 처리량을 늘리려면 결국 병렬화를 확대
    • 유입 속도 제한

스파크 MLlib

• 스파크를 활용한 머신러닝
  • 머신러닝 :알고리즘은 결국 주어진 작업을 해결하는방법으로 스스로 학습
  • 스파크의 분산 처리 능력을 이용해 매우 큰 규모의 데이터셋에서도 비교적 빠른 속도로 머신 러닝 알고리즘을 훈련하고 적용
  • 머신 러닝 작업의 대부분 한곳에서 수행할 수 있는 통합 플랫폼을 제공
  • 사용자는 스파크라는 단일 시스템에서 데이터를 수집해 준비하고 다각도로 분석할 수 있음, 데이터를 곧바로 모델 훈려과 평가에 활용하고, 완성된 모델을 운영 환경에까지적용할 수 있음, 이 모든 과정을 단일 API로 구현할 수 있음
  • 파이프라인(pipeline) : 머신러닝과 관련된 모든 연산 작업을 시퀀스 하나로 모아 마치 단일 연산처럼 한 번에 처리함
  • 변환자(transformer) : 한 데이터셋을 다른 데이터셋으로 변환하는 머신 러닝 컴포넌트를 구현할 수 있음
  • 추정자(estimator) : 주어진 데이터셋을 학습해 변환자를 생성
  • 평가자(evaluator) : 모델 성능을 단일 지표로 평가
  • OVR 전략(One Vs. Rest)
    • 각 클래스당 모델을 하나씩훈련시키면서 다른 클래스들(즉,나머지(rest) 클래스들)을 음성으로 간주하는 방식으로 사용
    • 새로운 데이터 샘플을 분류할 때는 훈련된 모든모델에 이 샘플을 입력으로 전달하고, 가장 높은 확률을 출력하는 모델의 클래스를 샘플 레이블로 예측함
  • 랜덤포레스트
    • 의사 결정 트리를 여러 개 학습하고, 각 트르의 예측 결과를 모아서 가장 좋은 결과를 선택하는 앙상블 기법
      • 알고리즘의 과적합을 방지하고, 트리 하나로는 찾을 수 없는 전역 최적점을 찾을 수 있다는 이점을 제공
    • 튜닝 작업을 많이 하지 않아도 좋은 성능을 낼 수 있으며 분류 및회귀 문제에도 모두 사용가능
    • 특징 변수 배깅(feature bagging) 기법을 사용
      • 알고리즘은 의사 결정 트리의 각 노드별로 특징 변수의 부분 집합을 무작위 선정하고, 이 집합 내에서만 다음 분기를 결정
      • 특징 변수 배깅이 필요한 이유는 의사 결정 트리들의 상관성(correlation)이 높을수록(즉, 트리가 서로 비슷할수록) 랜덤 포레스트의 모델의 오차율이 증가하기 때문, 특징 변수 배깅은 의사 결정 트리들을 차별화함
  • 군집화
    • 데이터를 여러 그룹으로 분할 :고객 세분화(customer segmentation)나 유사한 행동을 보인 고객을 그루핑하는 작업
    • 이미지 세분화(image segmentation) : 이미지 하나에서 구분 가능한영역을 인식하고 분리
    • 이상 탐지(anomaly detection)
    • 텍스트 분류(text categorization) 또는 주제 인식(topic recognition)
    • 검색 결과 그루핑 : yippy 검색 엔진은 검색 결과를 범주별로 묶어서 보여줌
    • 군집 비용(군집 왜곡(distoration) : k-평균 군집화 모델을 평가하는 기본 지표로, 각 군집의 중심점과 해당 군집에 포함된 각 데이터 포인트 간 거리를 제곱해 합산한것

GraphX

• 최단 거리(shortest path) : 한 정점에서 다른 정점들로 향하는 최단 경로를 찾음
  • 특정 정점에서 그래프의 각 정점으로 도달하기 위해 따라가야 할 간선의 최소 개수를 찾는 알고리즘
• 페이지랭크(page rank) : 정점으로 들어오고 나가는 간선 개수를 바탕으로 정점의 상대적 중요도를 계산함
  • 그래프 내각 정점의 중요도를 해당 정점에 도착하는 간선 개수를 기반으로 계산
• 연결요소(connected components) : 그래프에서 서로 완전히 분리된 서브그래프를 찾음
  • 모든 정점에서 다른 모든 정점으로 도달할 수 있도록 연결된서브그래프를 의미
  • 그래프의 연결요소가 오직 한 개만 있으며, 그래프의모든 정점이 다른 모든 정점으로 도달할 수 있을때를 뜻함
• 강연결요소(Strongly Connected Components, SCC) : 그래프에서 서로 연결된 정점들의 군집을 찾음
  • 모든 정점이 다른모든 정점과 연결된 서브 그래프를 의미

스파크옵스

스파크 클러스터 구동

• 스파크 클러스터 : 복수의 머신에 분산된 방식으로 실행되는 프로세스들이 연결된 집합
• 스파크 런타임 컴포넌트
  • 클라이언트(client)
    • 클라이언트 프로세스 : 드라이버 프로그램을 시작, 스파크 애플리케이션을 실행하는 spark-submit 스크립트나 spark-shell 스크립트, 스파크 API를 사용한 커스텀 애플리케이션이 클라이언트 프로세스애 해당함
  • 드라이버(driver)
    • 스파크 애플리케이션의 실행을 관장하고 모니터링함
    • 클러스터 매니저에 메모리 및 CPU 리소스를 요청함
    • 애플리케이션 로직을 스테이지와 태스크로 분할
    • 여러 실행자에 태스크를 전달
    • 태스크 실행 결과를 수집
    • 클러스터 배포 모드(cluster-deploy mode) : 클러스터 배포 모드에서는 드라이버 프로세스 클러스터 내부에서 별도의 JVM프로세스로 실행하며, 드라이버 프로세스의 리소스(주로 JVM 힙 메모리)를 클러스터가 관리함
    • 클라이언트 배포 모드(client-deploy mode) : 클라이언트 배포 모드에서는 드라이버를 클라이언트의 JVM 프로세스에실행하며,클러스터가 관리하는 실행자들과 통신함
  • 실행자
    • 드라이버가 요청한태스크들을 받아서 실행하고, 그 결과를 드라이버로 반환하는 JVM 프로세스
• 스파크 클러스터 유형
  • 스파크 자체클러스터
    • 스파크 전용 클러스터, 오직 스파크 애플리케이션에만 적합하도록 설계되었기 때문에 켈베로스(Kerberos) 인증 프로토콜로 보호된 HDFS를 지원하지 않음
  • YARN 클러스터
    • YARN은 하둡의리소스 매니저 및 작업 실행 시스템
      • 이미 상당한 규모의 YARN 클러스터를 운영하는 조직이 많음, YARN 클러스터를 관리하고 모니터링하는 기술적노하우, 도구, 절차를 갖추고 있음
      • YARN을 사용하면 스파크뿐만 아니라 다양한 유형의 자바 애플리케이션을 실행할 수 있으므로 기존 레거시 하둡과 스파크 애플리케이션을 손쉽게 통합할 수 있음
      • 켈베로스를 기반으로 하는 보안 HDFS는 오직 YARN에서만 지원함
      • 스파크를 클러스터의 모든 노드에 설치할 필요가 없다
  • 메소스 클러스터
    • 확장성과 장애 내성을 갖춘 c++ 기반 분산 시스템 커널
    • c++와 파이썬 애플리케이션을 지원
    • 다양한 유형의 리소스(예: cpu, 디스크 공간, 네트워크 포트)를 스케줄링할 수 있다
    • 메소스는 2단계 스케줄링 아키텍처로 구성되므로 스케줄러 프레임워크의 스케줄러
  • 스파크 로컬 모드
    • 스파크 로컬 모드와 스파크 로컬 클러스터 모드는 단일 머신에서 실행하는 독특한 형태의 사프크 자체 클러스터
    • 스파크를 손쉽게 빠르게 구축하고 테스트할 수 있지만, 운영 환경으로 사용할 수 없음
• 잡스케줄링과 리소스 스케줄링
  • 잡 스케줄링
    • 애플리케이션의 드라이버와 실행자가 시작되면 스파크 스케줄러는 이들과 직접 통신하면서 어떤 실행자가 어떤 태스크를 수행할지 결정함
    • 클러스터의 cpu 리소스 사용량을 좌우함
    • 클러스터 리소스 스케줄링 : 여러 스파크 애플리케이션의 실행자에리소스를 할당함
      • 단일 클러스터에서 실행하는 다수의 애플리케이션에 클러스터의 리소스를 나누어주는 작업은 클러스터 매니저가 담당
      • 스파크가지원하는 모든 유형의 클러스터매니저는 각 애플리케이션이 요청한 리소스를 제공하고, 애플리케이션이 실행이 끝나면 할당했던 리소스를 다시 회수하는 역할을 수행함
    • 스파크 리소스 스케줄링 : 단일 스파크 애플리케이션 내에서 태스크를 실행할 CPU 및 메모리 리소스를 스케줄링함
    • 클러스터 매니저가 CPU와 메모리 리소스를 각 실행자에게 할당하면 스파크 애플리케이션 내부에서는 잡 스케줄리이 진행됨
    • 클러스터 매니저와 관계없이 스파크 자체에서 수행하는 작업으로, 잡을 어떻게 태스크로 분할하고 어떤 실행자에 전달할지 결정함
    • 선입선출 스케줄러
      • 선착순, 가장 먼저 리소스를 요청한 잡이 모든 실행자의 태스크 슬롯을 필요한 만큼(또는 남은 만큼)전부 차지한다(FIFO 스케줄러는 각 잡이 단일 스테이지로 구성된다고 가정함)
    • 공정 스케줄러
      • 실행자 리소스(즉, 실행자의 스레드)를 놓고 경쟁하는스파크 잡들에라운드로빈(round robin)방식으로 균등하기 리소스를 분배함
    • 태스크 예비 실행
      • 예비 실행(SPECULATIVE EXECUTION) : 태스크가 실행자들에 분배되는 방식을 설정할 수 있다. 낙오(straggler) 태스크(동일 스테이지의 다른 태스크보다 더 오래 걸리는 태스크) 문제를 해결할 수 있음
    • 데이터 지역성(data locality)
      • 스파크가 데이터와 최대한 가까운 위치에서 태스크를 실행하려고 노력하는 것을 의미
• 스파크 웹 UI
  • 다양한 스파크의 환경과 잡 실행 통계 정보를 제공
  • Jobs 페이지
    • 현재 실행중인 잡, 완료된 잡, 실패한 잡의 통계정보를 제공함
  • Stages페이지
    • 잡의 스테이지를 요약한 정보를 제공함, 각 스테이지의 시작 시간, 실행 시간, 실행 현황, 입출력 데이터의크기, 셔플링 읽기 쓰기 데이터양을 확인가능
  • Storage 페이지
    • 캐시된 RDD 정보와 캐시 데이터가 점유한 메모리, 디스크,타키온 스토리지 용량을 보여줌
  • Environment 페이지
    • 스파크 환경 매개변수뿐만 아니라 자바 및 스칼라의 버전, 자바 시스템 속성, 클래스패스 정보를 확인할 수 있음
  • Executors 페이지
    • 클러스터 내 모든 실행자 목록(드라이버 포함)과 각 실행자(또는 드라이버)별 메모리 사용량을 포함한 여러 통계 정보를 제공함
  • 실행자(executor)

스파크 자체 클러스터

• 스파크 배포판과 함께 제공
• 장점
  • 아키텍처가 단순
  • 설치와 설정이 쉬움
  • 스파크에 맞게 특별히 구현 및 최적화되어 과도한 일반화나 요구 사항, 환경 설정 등 여러 불필요하고 불완전한 기능은 탑재하지 않았음
• 구성
  • 마스터 프로세스
    • 클라이언트가 실행을 요청한 애플리케이션들을 받고, 각 애플리케이션에 워커 리소스(CPU 코어)를 스케줄링함
  • 워크 프로세스(슬레이브 프로세스)
    • 애플리케이션의 태스크를 처리할 실행자를 시작함(클러스터 배포 모드에서는 애플리케이션의 드라이버를 실행하는 역할도 워커가 담당)
    • 드라이버 : 스파크 잡을 조정하고 모니터링하는 컴포넌트이며
    • 실행자 : 잡의 태스크를 실행하는 컴포넌트
  • 스파크 자체 클러스터를 구성하려면 클러스터의 모든 노드가 워커의 역할을 하도록 각 노드에 스파크를 설치해야함
    • 스파크를 설치한다는 것은 바이너리 형태의 배포판을 내려받아 압축을 해제하거나 스파크의 소스 파일을 직접 빌드하는 작업을 의미
      • 1단계 : 클라이언트 프로세스는 애플리케이션을 마스터에 제출
      • 2단계 : 마스터는 1번 노드의 워커에 드라이버를 시작하라고 지시
      • 3단계 : 1번 노드의 워커는 드라이버 JVM을 시작
      • 4단계 : 마스터는 두 워커에 애플리케이션의 실행자를 시작하라고 지시함
      • 5단계 : 두 워크는 각각 실행자 JVM을 시작함
      • 6단계 : 드라이버는 실행자와 직접 통신하며 스파크 애플리케이션을 실행함, 클러스터의 프로세스들은 더 이상 관여하지 않음
• 셀 스크립트로 클러스터 시작
  • 스파크 자체 클러스터의 컴포넌트를 시작하는 세 가지 시작 스크립트를 제공
    • start-master.sh : 마스터 프로세스를 시작함
    • start-slaves.sh : 클러스터에 등록된 워커 프로세스들을 모두 시작함
    • start-all.sh : 마스터 프로세스와 워커 프로세스들을 시작함
  • 각 컴포넌트의 프로세스를 중지하는 종료 스크립트
    • stop-master.sh
    • stop-slaves.sh
    • stop-all.sh
• 주키퍼
  • 네이밍 저장소, 분산 동기화 및 그룹 서비스 기능을 지원하는 빠르고 간편한 시스템
  • 주키퍼 클라이언트(여기서는 스파크)는 주키퍼를 활용해 프로세스를 관리하고 소규모 공유 데이터를 저장함
  • 등록된 여러 클라이언트 프로세스 중에서 리더 프로세스를 선출하는 기능을 제공
• 스파크 자체 클러스터의 웹 UI
  • 마스터 웹 UI 페이지
    • 클러스터 리소스(메모리 및 CPU 코어) 사용 및 잔여 현황뿐만 아니라 워커, 애플리케이션, 드라이버 정보도 제공
    • 해당 워커가 관리하느 실행자와 드라이버 목록 보기 가능
    • Logs칼럼의 각 링크를 클릭하면 해당 로그 파일도 살펴볼 수 있음
    • 애플리케이션 이름을 클릭하면 해당 애플리케이션의 스파크 컨텍스트가 실행한 스파크 웹 UI 페이지로 이동
• 이벤트 로깅
  • 웹 UI를 표시하는 데 필요한 이벤트 정보를 spark.eventLog.dir 매개변수에 지정된 폴더(/tmp/spark-events)에 기록
• EC2에서 스파크 실행
  • EC2 스크립트는 아마존 EC2로 스파크 자체 클러스터를 빠르게 구축할 수 있도록 지원
  • 아마존 EC2(Amazon Elastic Computer Cloud)는 아마존이 제공하는 클라우드 컴퓨팅 서비스
  • 사용자는 EC2 서비스를 활용해 아마존의 가상 서버를 임대하고 자신만의 애플리케이션을 실행
  • AWS가 각광받는 이유는 사용이 편리하고 다양한 기능을 제공하며 비교적 가격이 저렴함
  • spark-ec2 스크립트로 실행할 수 있는 액션
    • launch : EC2 인스턴스를 생성하고 필요한 소프트웨어 패키지들을 설치한 후 스파크 마스터와 슬레이브를 시작함
    • login : 스파크 마스터를 실행 중인 인스턴스에 로그인함
    • stop : 모든 클러스터 인스턴스를 중지함
    • start : 모든 클러스터 인스턴스를 시작하고 클러스터를 재구성함
    • get-master : 스파크 마스터를 실행 중인 인스턴스 주소를 반환함
    • reboot-slaves : 워커를 실행 중인 인스턴스들을 재시작함
    • destroy : 모든 EC2 인스턴스들을 종료하고 클러스터를 제거함, 이 액션은 실행되면 되돌릴 수 없음
      • $ ./spark-ec2 -k SparkKey -i SparkKey.pem destroy spark-in-action
      • --key--pari : -k 키 페어 이름을 지정
      • --identity-file : -i,앞서 생성한 프라이빗 키가 담긴 pem 파일을 전달
      • --region : -r : 선택한 리전을 전달

Yarn클러스터

• 하둡의 차세대 맵리듀스 실행 엔진
• 장점
  • 스파크 애플리케이션의 켈베로스 보안 HDFS(켈베로스 프로토콜로 인증한 사용자만 접근할 수 있는 하둡 분산 파일 시스템)에 접근할 수 있음
• Yarn 아키텍처
  • 주요 컴포넌트로 리소스매니저와 노드매니저가 존재
    • 리소스 매니저(resource manager)
      • 클러스터당 하나씩 실행됨
      • 스파크 자체 클러스터의 마스터 프로세스와 유사
    • 노드 매니저(node manager)
      • 클러스터 각노드에서 실행됨
      • 워커 프로세스와 유사
  • 컨테이너(CPU 및 메모리 리소스가할당된 JVM 프로세스) 내에서 실행됨
  • 애플리케이션 마스터(application master) : 각 애플리케이션에 존재하는 특별한 컴포넌트
    • 애플리케이션을 실행하는 데 필요한 리소슬르 리소스 매니저에 요청함
    • 스파크를 YARN에서 실행하면 스파크의 드라이버 프로세스가 YARN 애플리케이션 마스터의 역할을 담당함
    • 노드 매니저는 컨테이너들이 사용하는 리소스를 추적하고 리소스 매니저에 보고함
  • 단계
    • 1. 클라이언트는 가장 먼저 애플리케이션을 리소스 매니저에 제출함
    • 2. 리소스 매니저는 노드 매니저 중 하나를 선정해 애플리케이션 마스터를 실행할 컨테이너를 할당하라고 지시함
    • 3. 지시를 받은 노드 매니저는 애플리케이션 마스터(스파크 들아ㅣ버)의 컨테이너를 시작함
    • 4. 애플리케이션 마스터는 스파크 실행자에 사용할 컨테이너들을 리소스 매니저에 추가로 요청함
    • 5. 리소스 매니저가 리소스 할당을 실행하면 애플리케이션마스터는 실행자를 실행할 새로운 컨테이너를 시작하고 노드 매니저에 요청함
    • 6. 노드 매니저는 이 요청을 수행함
  • 구성
    • 자체(로컬) 모드 : YARN을 단일 자바 프로세스로 실행함, 스파크의 로컬 모드와 유사함
    • 의사 분산 모드(pseudo-distributed mode) : 단일 머신에서 모든 하둡 데몬(여러 자바 프로세스)을 실행함, 스파크의 로컬 클러스터 모드와 유사함
    • 완전 분산 모드 : YARN을 여러머신에서 실행함
  • 설정 파일
    • slaves : 클러스터 머신의 호스트네임 목록(한 줄당 하나씩 나열)으로 스파크 자체 클러스터의 slaves 파일과 유사
    • hdfs-site.xml : 하둡 파일 시스템 설정
    • yarn-site.xml : YARN 설정
    • yarn-env.sh : YARN 환경 변수
    • core-site.xml : 보안, 고가용성, 파일 시스템에 관련된 다양한 매개변수
  • 리소스 스케줄링
    • YARN의 ResourceManager는 리소스 스케줄링 기능을 플러그인 형태로 구현해 적용할 수 있는 확장 인터페이스를 제공함
    • FIFO 스케줄러
      • 가장 간단한 형태의 스케줄러 플러그인으로 애플리케이션에 필요한 모든 리소스를 한꺼번에 할당함
      • 두 애플리케이션이 동일한리소스를 요청하면, 먼저 요청한 애플리케이션이 우선적으로 리소스를 할당받음(선입선출)
    • 용량 스케줄러(capacity scheduler)
      • YARN의 기본 스케줄러
      • YARN 클러스터 하나를 여러 조직이 공유하면서 각 조직에 일정 용량의 리소스를 항상 보장(보장된 용량을 스케줄링)하도록 설계됨
      • 큐 단위로 리소스를 스케줄링함
    • 공정 스케줄러
      • 모든 애플리케이션에 최대한 (평균적으로) 공평한 지분의 리소스를 할당함
  • 동적 리소스 할당
    • 스파크 애플리케이션은 클러스터 매니저가 할당한 실행자를 애플리케이션 실행이 완료될 때까지 사용함
    • 애플리케이션은 동일한 실행자를 여러 잡에 걸쳐 사용하며, 일부 잡이 실행자의 리소스를 사용하지 않더라도 한번 할당된 리소스는 그대로 유지됨
    • 정적리소스 할당 방식의 장점은 이전 잡의 태스크에서 생성한 데이터를 동일한 실행자의 다른 태스크에서도 재사용 가능
    • spark-shell 애플리케이션은 사용자가 장시간 자리를 비우는 동안 유휴 상태가 되지만, 애플리케이션에 할당된 실행자들은 클러스터의 리소스를 점유한채로 유지됨 -> 동적 할당(dynamic allocation)은 이러한 비효율을 개선함, 애플리케이션에 할당된 실행자 리소스를 임시로 회수해 다른 애플리케이션이 이 리소스를 사용할 수 있도록 하는 기능

Mesos 클러스터

• 리눅스 커널이 싱글 컴퓨터의 리소스를 관리하고 단일 머신에서 실행되는 애플리케이션에 공급하는 것처럼, 분산 애플리케이션에 분산 시스템 커널을제공하고 상용(commodity) 클러스터 리소스를 공급함
• 자바, C/C++, 파이썬으로 작성한 애플리케이션을 실행함
• 메소스 버전 0.20부터는 도커 컨테이너를 실행할 수 있음
  • 도커 컨테이너는 애플리케이션을 실행하는 데 필요한 모든 라이브러리와 환경 설정을 포함한 일종의 패키지
• 장점
  • 리소스 미세 스케줄링 모드를 지원한느 유일한 클러스터 매니저
  • 스파크 태스크를 도커 이미지에서 실행할 수 있음
• 개선해야할 점
  • 보안 관련 기능
  • 상태 유지(stateful) 애플리케이션(데이터 베이스 등의 영구 스토리지를 사용하는 애플리케이션) 지원 기능
• 메소스 아키텍처
  • 메소스의 기본 컴포넌트는 마스터 ,슬레이브, 애플리케이션(메소스에서는 애플리케이션을 프레임워크(framework)라고도 함)
  • 메소스 마스터는 애플리케이션에필요한 슬레이브 리소스를 스케줄링함
  • 메소스의 슬레이브는 태스크를 수행할 애플리케이션의 실행자를 시작함
  • 특이 사항
    • 스파크외에도 다른 유형의 애플리케이션(자바, 스칼라,C/C++, 파이썬 애플리케이션)을 스케줄링할 수 있음
    • CPU 및 메모리 뿐만 아니라 디스크 공간, 네트워크 포트를 스케줄링
    • 커스텀 리소스의 스케줄링도 지원함
    • 애플리케이션이 클러스터의 마스터에 리소스를 요청하는 방식 대신, 클러스터가 애플리케이션에 리소스를 제안하면 애플리케이션이이를 수용하거나 거부하는 방식으로 리소스를 할당함
    • 메소스 프레임워크(스파크 애플리케이션)
      • 스케줄러 : 메소스 마스터가 제안한 리소스를 수용하거나 거부할 수 있으며, 마스터에 태스크 목록을 전달해 슬레이브가 메소스 실행자를 시작하도록 요청함
      • 실행자 : 실행자는 프레임워크의 스케줄러가요청한 태스크를 수행함
  • 과정
    • 1. 메소스 슬레이브는 자신의 리소스를 마스터에 제안함
    • 2. 스파크 드라이버(spark-submit)가 실행하는 메소스 전용 스케줄러는 자신을 메소스 마스터에 등록함
    • 3. 메소스 마스터는 스파크 메소스 스케줄러에 가용 리소스를 제안함(마스터는 프레임워크가 실행되는 동안 이 작업을 반복적으로 수행함)
    • 4. 스파크의 메소스 스케줄러는 마스터가 제안한 리소스 일부를 수용하고, 사용할 리소스 목록과 이 리소스로 실행하는 태스크 목록을 메소스 마스터에 전송함
    • 5. 마스터는 스케줄러가 요청한 리소스를 사용해 태스크를 시작하라고 슬레이브에 지시함
    • 6. 슬레이브는 실행자(메소스 셸 명령 실행자(Command Executor)를 시작하며, 메소스 실행자는 (제공된 명령을 사용해) 태스크 컨테이너에서 스파크 실행자를 시작
    • 7. 스파크 실행자는 스파크 드라이버에 접속해 직접 통신하고 스파크 태스크를 실행함
  • 모드
    • 조대 모드 : 스파크가 메소스 슬레이브당 스파크 실행자 하나만 구동하는 모드를 의미
    • 미세 모드
      • 스파크 태스크당 스파크 실행자가 한 개, 즉 메소스 태스크가 한 개씩 시작됨
      • 미세 모드에서는 조대 모드에 비해 훨씬 더 많은 스파크 실행자를 준비해야 함
      • 더 많은 초기화, 통신, 데이터 직렬화 작업을 수행함, 미세 모드로 잡을 실행하면 조대 모드보다 더 느릴수 있음
      • 미세모드를 사용하는 이유는 클러스터의 리소스를 더욱 유연하게운용할 수 있기 때문
      • 미세 모드는 주로 장시간 실행되는 태스크가 필요한 배치 잡이나 스트리밍 잡에 유용함
• 메소스 컨테이너
  • cgroups(컨트롤 그룹(control group)) : 프로세스의 리소스 사용을제한하고 격리하는 리눅스 커널의 기능, 컨트롤 그룹은 한정된 리소스(CPU, 메모리, 네트워크 디스크)를 할당받은 프로세스 집합
  • 도커 컨테이너 : 가상 머신과 유사함, 도커 컨테이너는 리소스를 제한한다는 점에서 cgroups와 유사하지만 프로세스에 필요한 시스템 라이브러리를 함께 제공한다는 점이 다름
• 메소스의 리소스 스케줄링
  • 1. 메소스 마스터에서 실행하는 리소스 할당 모듈(resource-allocation module)이 수행
    • 리소스 할당 모듈은 어떤 리소스를 어떤 프레임워크에 어떤 순서로 제안할지 결정함
    • 메소스는 메모리, CPU, 디스크, 네트워크 포트를 스케줄링 할 수 있으며, 커스텀 리소스의 스케줄링도 지원함
    • 리소스 할당 모듈은 모든 프레임워크의 리소스 수요를 충족시키면서 리소스를 최대한 공정하게 분배하는 것을 목표로함
  • 2. 프레임워크 스케줄러가 담당함

맵리듀스

• 잡을 잘게 분할하고 클러스터의모든 노드로 매핑(map), 즉 파견해 분산 처리를 수행하는 새로운 패러다임
• 각 노드는 분할된 잡을 처리하는 중간 결과를 생성함, 그 다음 분할된 중간 결과를 리듀스(reduce), 즉 집계해 최종 결과를 냄
  • 병렬 처리 : 전체 연산을 잘게 나누어 동시에 처리하는 방법
  • 데이터 분산 : 데이터를 여러 노드로 분산하는 방법
  • 장애 내성 : 분산 컴포넌트의 장애에 대응하는 방법
• 최소한의 API만 노출해 대규모 분산 시스템을 다루는 복잡한 작업을 효과적으로 감추고 병렬 처리의 세 가지 문제를 프로그래밍적인 방식으로 해결 함