spark 실행구조

Spark

• 대용량 데이터를 빠르게 처리하기 위한 인메모리 기반의 분산 데이터 처리 엔진
• 클러스터 환경에서 데이터를 병렬 처리하는 라이브러리 집합

spark 등장 배경은 MapReduce 단점 보완하기 위해 ??

• 등장배경
  • "왜 갑자기 병렬 데이터 처리에 열광하게 되었을까" 와 같음
    • 예전엔 CPU등 하드웨어 성능이 해마다 눈에 띄게 발전함 → 2005년쯤 부터는 물리적인 한계로 성능향상이 점점 둔화됨 (단일 프로세서의 성능이 급격하게 상승하다 2005년 이후 둔화)
      • 이는 멀티 코어 프로세서가 탄생하는 계기가 됨, 하드웨어 엔지니어들은 병렬 CPU 코어를 추가하는 방향으로 선회
    • 반면, 데이터를 저장하는 하드웨어의 가격은 저렴해짐 → 데이터 저장비용이 저렴해지며 저장할 데이터가 대용량화 됨
    • 새로운 처리엔진과 프로그래밍 모델이 필요하게됨 → 클러스터 → 아파치 스파크

MapReduce의 단점

• 개발 편의성 부족
  • 코딩, 배포량 많음 (길고, 어려움, 배포번거로움)
  • 대안: SQL 기반의 Hive, Impala
    • Hive는 SQL을 사용하지만 내부적으로는 맵리듀스를 거친다 / 임팔라, 스팍은 아님
• 처리된 데이터 저장/전송
  • 많은 DISK I/O, 셔플시 N/W 트래픽 발생
  • 반복 작업시 비효율적
  • 대안 : In-memory processing (Impala, Spark)

마스터/슬레이브 구조

• 드라이버(1) : executor(N) (core라고도 하는듯? 태스크를 core라고 하나?)
• 하나의 드라이버와 익스큐터들을 합쳐서 스파크 애플리케이션

드라이버

• SparkContext를 생성하고 RDD를 만들고 '트랜스포메이션', '액션'을 실행
• 트랜스포메이션이냐 액션이냐에 따라 동작방식이 다르다.. 어떻게??
• main() 메소드가 실행되는 프로세스
  • 소스에 기술된 RDD의 생성/변환 로직을 이용해 어플리케이션을 제어
• 사용자 프로그램을 태스크로 변환
  • 드라이버는 물리적 실행 단위가 되는 task로 바꾼다.
    • 내부적으로 연산들의 관계에 대해 논리적인 비순환 그래프(DAG : Directed Acyclic Grapth)를 생성
    • 드라이버는 이 논리 그래프를 물리적인 실행계획으로 변환
    • 맵/트랜스포메이션을 "pipeling"해서 합치는 등 여러 최적화를 통해 실행 그래프를 여러 개의 stage로 바꾼다.
      • 각 stage는 여러 개의 task 로 이루어짐
        • task는 스파크 작업 계층에서 가장 작은 단위
        • task는 RDD의 파티션 단위로 데이터를 로드하고 변환/액션을 적용하는 처리 단위
  • 드라이버 1 : stage N : task : N*M
• 익스큐터에서 태스크들의 스케줄링
  • 물리적 실행계획이 나오면 드라이버는 익스큐터에서의 개별 작업들을 위한 스케줄을 조정한다. ??
  • 익스큐터는 task들을 실행하고 RDD 데이터를 저장하는 프로세스
  • 드라이버는 항상 실행 중인 익스큐터들을 살펴보고 각 태스크를 데이터 위치에 기반해 적절한 위치에서 실행될 수 있도록 노력한다. ?? (네임노드를 통해 데이터 위치를 파악해서?)

익스큐터

• 개별 task들을 실행하는 작업 실행 프로세스
• 스파크 애플리케이션 실행 시 최초 한번 실행되며, 도중에 오류로 죽더라도 스파크 애플리케이션은 계속 실행
• 익스큐터의 역할
  • Task들의 실행 결과를 드라이버에 되돌려줌
  • 각 익스큐터에 존재하는 블록 매니저를 통해 사용자 프로그램에서 캐시하는 RDD를 저장하기 위한 메모리 저장소를 제공
    • RDD가 익스큐터 내부에 직접 캐시되므로 단위 작업들 또한 같이 실행되기에 용이하다.

클러스터 매니저

• 스파크와 붙이거나 뗄 수 있는 컴포넌트
• 스파크가 얀, 메소스, 내장 매니저 등 다양한 외부 매니저들 위에서도 돌아갈 수 있게 한다.
• ex) yarn
  • 리소스 매니저 : master daemon
  • 노드 매니저 : worker daemon
  • 스파크는 드라이버, 익스큐터 모두 yarn의 작업 노드들 위해서 실행 할 수 있다 ??

클러스터에서 스파크 애플리케이션을 실행할 때 발생하는 단계

• 사용자는 spark-submit을 사용하여 애플리케이션을 제출한다.
• spark-submit은 드라이버 프로그램을 실행하고 사용자가 정의한 main() 메소드를 호출한다.
• 드라이버 프로그램은 클러스터 매니저에게 익스큐터 실행을 위한 리소스를 요청한다.
• 클러스터 매니저는 드라이버 프로그램을 대신해 익스큐터들을 실행한다.
• 드라이버 프로세스가 사용자 애플리케이션을 통해 실행된다. 프로그램에 작성된 RDD의 transformation과 action에 기반하여 드라이버는 작업 내역을 단위 작업 형태로 나눠 익스큐터들에게 보낸다.
• 단위 작업들은 결과를 계산하고 저장하기 위해 익스큐터에 의해 실행된다.
• 드라이버의 main()이 끝나거나 SparkContext.stop()이 호출된다면 익스큐터들은 중지되고 클러스터 매니저에 사용했던 자원을 반환한다.

spark submit

• —-deploy-mode
  • client (default) : 드라이버를 자신이 실행되는 머신에서 실행
    • 실시간 쿼리, OLAP에 적합, 왜??
  • cluster : 클러스터의 작업 노드에서 실행되도록 드라이버를 전송
    • 오래소요되는 작업에 적합 , 왜??
• 뭐가 더 유리한거지? I/O 때문에 결과를 외부(RDB등)로 쓰기 위한 작업이라면 클라이언트, hadoop 내에 쓰기 위한 작업이라면 클러스터 모드 가 유리 한걸까??