하둡&Spark_(1)

빅데이터

• 서버 한 대로 처리할 수 없는 데이터
• 기존의 소프트웨어로는 처리할 수 없는 규모의 데이터
• 4V (Volume, Velocity, Variety, Varecity)
  • Volume - 데이터의 크기
  • Velocity - 데이터의 처리속도
  • Variety - 구조화/비구조화 데이터
  • Varecity - 데이터의 품질
• 빅데이터의 예
  • 웹
    • 수십 조개 이상의 웹 페이지 존재 -> 온갖 종류의 지식의 바다
    • 웹 검색엔진 개발은 진정한 대용량 처리
    • 사용자 검색어와 클릭 정보 자체도 대용량
    • 요즘은 웹 자체가 NLP 거대 모델 개발의 훈련 데이터로 사용
• 빅데이터의 처리 특징
  • 큰 데이터를 손실없이 보관할 방법 필요 : 스토리지
  • 처리 시간이 오래 걸림 : 병렬처리
  • 빅데이터는 비구조화 된 데이터일 가능성이 높음 : SQL 만으로는 부족 (Ex_웹 Log 파일)
• 대용량 분산 시스템
  • 분산 환경 기반 (1대 혹은 그 이상의 서버로 구성, 분산 파일 시스템과 분산 컴퓨팅 시스템 필요)
  • Fault Tolerance (소수의 서버가 고장나도 동작해야함)
  • 확장 용이 (Scale Out이 되어야 함)

---

Hadoop

• HDFS (분산 파일 시스템), MapReduce (분산 컴퓨팅 시스템)
• 다수의 노드로 구성된 클러스터 시스템
  • 하나의 커다란 컴퓨터처럼 동작
  • 다수의 컴퓨터들이 복잡한 소프트 웨어로 통제

HDFS - 분산 파일 시스템

• 데이터를 블록단위로 나누어 저장
  • 크기 - 128MB (디폴트)
• 블록 복제 방식 (Replication)
  • 각 블록은 세 군데에 중복 저장
  • Fault tolerance를 보장하는 방식으로 블록 저장
• 하둡 2.0 내임노드 이중화 지원
  • Active & Standby
    • 둘 사이에 share edit log가 존재
  • Secondary 내임노드는 여전히 존재

MapReduce - 분산 컴퓨팅 시스템

• 하둡 1.0
• 하나의 잡 트래커와 다수의 태스크 트래커로 구성
  • 잡 트래커가 일을 나눠서 다수의 태스크 트래커에게 분배
  • 태스크 트래커에서 병렬 처리
• MapReduce만 지원
  • 일반적인 시스템이 아님

---

분산 컴퓨팅 시스템 : 하둡 2.0 (YARN 1.0)

• 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임웍
  • 리소스 매니저
  • 노드 매니저
  • 컨테이너
• Spark이 이 위에서 구현

 YARN의 동작

1. 실행하려는 코드와 환경 정보를 RM (Resource Manager)에게 넘김
   1. 실행에 필요한 파일들은 application ID에 해당하는 HDFS 폴더에 미리 복사
2. RM은 NM (Node Manager)으로부터 컨테이너를 받아 AM (Application Master) 실행
   1. AM은 프로그램마다 하나씩 할당되는 프로그램 마스터에 해당
3. AM은 입력 데이터 처리에 필요한 리소스를 RM에게 요구
   1. RM은 data locality를 고려해 리소스(컨테이너)를 할당
4. AM은 할당받은 리소스를 NM을 통해 컨테이너로 런치하고 그 안에서 코드 실행
   1. 이 때 실행에 필요한 파일들이 HDFS에서 Container가 있는 서버로 먼저 복사
5. 각 태스크는 상황을 주기적으로 AM에게 보고 (heartbeat)
   
   1. 태스크가 실패하거나 보고가 오랜 시간 없으면 태스크를 다른 컨테이너로 재실행 (AM의 업무)

 하둡 3.0의 특징

• YARN 2.0을 사용
  • YARN 프로그램들의 논리적인 그룹으로 나눠서 자원 관리가 가능
    이를 통해 데이터 수집 프로세스와 데이터 서빙 프로세스를 나눠서 관리 가능
  • 타임라인 서버에서 HBase를 기본 스토리지로 사용 (하둡 2.1)
• 파일 시스템
  • 내임노드의 경우 다수의 스탠바이 내임노드를 지원
  • HDFS, S3, Azure Storage 이외에도 Azure Data Lake Storage 등을 지원

---

맵리듀스 프로그래밍

• 데이터 셋은 Key, Value의 집합이며 변경 불가 (immutable)
• 데이터 조작은 map과 reduce 두 개의 오퍼레이션으로만 가능
  • 두 오퍼레이션은 항상 하나의 쌍으로 연속으로 실행
  • 두 오퍼레이션의 코드를 개발자가 채워야함
• 맵리듀스 시스템이 Map의 결과를 Reduce단으로 모아줌
  • 이 단계를 보통 셔플링이라 부르며 네트워크단을 통한 데이터 이동이 발생

Map : (k, v) -> [(k', v')*]

• 입력은 시스템에 의해 주어지며 입력으로 지정된 HDFS 파일에서 넘어옴
• 키, 밸류 페어를 새로운 키, 밸류 페어 리스트로 변환 (transformation)
• 출력 : 입력과 동일한 키, 밸류 페어를 그대로 출력해도 되고 출력이 없어도 됨

Reduce : (k', [v1', v2', v3', v4', ...]) -> (k'', v'')

• 입력은 시스템에 의해 주어짐
  • 맵의 출력 중 같은 키를 갖는 키/밸류 페어를 시스템이 묶어서 입력으로 넣어줌
• 키와 밸류 리스트를 새로운 키, 밸류 페어로 변환
• SQL의 GROUP BY와 흡사
• 출력이 HDFS에 저장

Map, Reduce 프로그래밍 문제점

• 생산성이 떨어짐 (데이터 모델과 오퍼레이션에 제약이 많음)
• 모든 입출력이 디스크를 통해 이뤄짐
  • 큰 데이터 배치 프로세싱에 적합
• Shuffling 이후에 Data Skew가 발생하기 쉬움
  • Reduce 태스크 수를 개발자가 지정해주어야 함

---

Spark

• 프로그램 구조
  • Driver - 실행되는 코드의 마스터 역할 수행 (YARN의 Application Master)
  • Executor - 실제 태스크를 실행해주는 역할 수행 (YARN의 컨테이너)
• Driver
  • 사용자 코드를 실행하며 실행 모드 (client, cluster)에 따라 실행되는 곳이 달라짐
  • 코드를 실행하는데 필요한 리소스를 지정
    --num-executors, --executor-cores, --executor-memory
  • SparkSession을 만들어 Spark 클러스터와 통신 수행
     - Cluster Manager (YARN의 경우 Resource Manager)
     - Executor (YRAN의 경우 Container)
  • 사용자 코드를 실제 Spark 태크스로 변환해 Spark 클러스터에서 실행
• Executor
  • 실제 태스크를 실행해주는 역할 수행 (JVM) : Transformations, Actions
  • YARN에서는 Container가 그 역할을 함

Spark 클러스터 매니저

• local[n]
  • 개발/테스트용
     - Spark Shell, IDE, 노트북
  • 하나의 JVM이 클러스터로 동작
     - Driver와 하나의 Executor 실행
  • n은 코어의 수
     - Executor의 스레드 수가 됨
  • local[*]
     - 컴퓨터에 있는 모든 코어 사용
• YARN
  • 두 개의 실행 모드가 존재
     - Client vs Cluster
  • Client 모드 : Driver가 Spark 클러스터 밖에서 동작
     - YARN 기반 Spark 클러스터를 바탕으로 개발/테스트 등을 할 때 사용
  • Cluster 모드 : Driver가 Spark 클러스터 안에서 동작
     - 하나의 Container 슬롯을 차지
     - 실제 프로덕션 운영에 사용되는 모드