[11주차] 하둡과 Spark (1)

🙂 빅데이터

✔ 정의

• 서버 한대로 처리할 수 없는 규모의 데이터
• 기존의 소프트웨어(Oracle, MySQL 등 Production DB)로는 처리할 수 없는 규모의 데이터
• 4V (Volume, Velocity, Variety, Veracity)

✔ 특징

• 큰 데이터를 손실없이 보관할 방법이 필요: 스토리지
• 처리 시간이 오래 걸림: 병렬처리
• 이런 데이터들은 비구조화된 데이터: SQL X

🍦 해결방안

• 큰 데이터 저장이 가능한 분산 파일 시스템이 필요
• 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
• 비구조화 데이터를 처리할 방법이 필요

결국 다수의 컴퓨터로 구성된 Framework가 필요

✔ 대용량 분산 시스템

• 분산 환경 기반 (1대 혹은 그 이상의 서버로 구성 - 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요)
• Fault Tolerance (소수의 서버가 고장나도 동작)
• 확장이 용이 (Scale Out)

---

🙂 Hadoop

✔ 정의

An open source SW platform for distributed storage and distributed processing of very large data sets on computer clusters built from commodity HW

🍦 HDFS - 분산 파일 시스템

• 데이터를 블록 단위로 나누어 저장
  • 블록의 크기는 128MB
• 블록 복제 방식 (Replication)
  • 각 블록은 3군데에 중복 저장
  • Fault Tolerance를 보장할 수 있는 방식으로 이 블록들은 저장됨
• 하둡 2.0 Name Node 이중화 지원
  • Active & Standby
    • 둘 사이에 share edit log가 존재
  • Secondary Name Node는 여전히 존재

🍦 MapReduce - 분산 컴퓨팅 시스템

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

YARN 1.0

---

🙂 YARN의 동작 방식

• 세부 리소스 관리가 가능한 범용 컴퓨팅 Framework
  • 리소스 매니저: Job Scheduler, Application Manager
  • 노드 매니저
  • 컨테이너: 앱 마스터, 태스크
• Spark가 이 위에서 구현됨

✔ YARN의 동작

• 클라이언트: MapReduce 또는 Spark

🍦 하둡 1.0 vs. 하둡 2.0

하둡 2.0에서 소개된 클러스터 자원 관리자를 YARN이라고 부름

🍦 하둡 3.0

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

---

🙂 맵리듀스 프로그래밍

✔ 특징

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

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

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

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

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

🍦 Shuffling

• Mapper의 출력을 Reducer로 보내주는 프로세스
• 전송되는 데이터의 크기가 크면 NW 병목을 초래하고 시간 오래 소요

🍦 Sorting

• 모든 Mapper의 출력을 Reducer가 받으면 이를 key 별로 sorting

🍦 Data Skew

각 Task가 처리하는 데이터의 크기에 불균형이 존재한다면?

• 병렬처리의 의미가 없음. 가장 느린 Task가 전체 처리 속도를 결정
• 특히 Reducer로 오는 나눠지는 데이터의 크기는 큰 차이가 있을 수 있음
  • Group By나 Join 등에 이에 해당
  • 처리 방식에 따라 Reducer의 수에 따라 메모리 에러 등이 날 수 있음
• 데이터 엔지니어가 고생하는 이유 중 하나
  • 빅데이터 시스템에는 이 문제가 모두 존재

🍦 문제점

낮은 생산성

• 프로그래밍 모델이 가진 융퉁성 부족 (2가지 오퍼레이션만 지원)
• 튜닝/최적화가 쉽지 않음 (ex. 데이터 분포가 균등하지 않은 경우)

배치작업 중심

• 기본적으로 Low Latency가 아니라 Throughput에 초점이 맞춰짐

🍦 대안

• 더 범용적인 대용량 데이터 처리 Framework의 등장
  • YARN, Spark
• SQL의 컴백: Hive, Presto 등이 등장
  • Hive
    • MapReduce 위에서 구현. Throughput에 초점. 대용량 ETL에 적합
  • Presto
    • Low Latency에서 초점. 메모리를 주요 사용. Adhoc 쿼리에 적합
    • AWS Athena가 Presto 기반

---

🙂 Spark

하둡 - 1세대

Spark - 2세대

✔ 구성

• Spark Core
• Spark SQL
• Spark ML (Spark MLlib)
• Spark Streaming
• Spart GraphX

✔ Spark vs. MapReduce

Spark	MapReduce
메모리 기반 (메모리 부족 시 디스크 사용)	디스크 기반
하둡(YARN)이외에도 다른 분산 컴퓨팅 환경 지원 (K8s, Mesos)	하둡(YARN) 위에서만 동작
pandas dataframe과 동일한 데이터 구조 지원	key-value 기반 데이터 구조만 지원
다양한 방식의 컴퓨팅 지원 (배치 데이터, 스트림 데이터, SQL, ML, 그래프 분석)

✔ Spark 프로그래밍 API

• RDD (Resilient Distributed Dataset)
  • Low Level Programming API로 세밀한 제어 가능
  • 코딩 복잡도 증가
• DataFrame & Dataset (판다스의 DataFrame과 흡사)
  • 하이레벨 프로그래밍 API로 점점 많이 사용되는 추세
  • 구조화 데이터 조작이라면 보통 Spark SQL을 사용
  • DataFrame / Dataset이 꼭 필요한 경우는?
    • ML 피쳐 엔지니어링을 하거나 Spark ML을 쓰는 경우
    • SQL만으로 할 수 없는 일의 경우

✔ Spark SQL

• Spark SQL은 구조화된 데이터 처리를 SQL로 처리
• 데이터 프레임을 SQL로 처리 가능
  • 데이터프레임은 테이블처럼 sql로 처리 가능
  • 판다스도 동일 기능 제공
• Hive 쿼리보다 최대 100배까지 빠른 성능을 보장
  • 사실은 그렇지 않음. Hive도 메모리를 쓰는 걸로 발전
    • Hive: 디스크 -> 메모리
    • Spark: 메모리 -> 디스크
    • Presto: 메모리 -> 디스크

✔ Spark ML

• 머신러닝 관련 다양한 알고리즘, 유틸리티로 구성된 라이브러리
• Classification, Regression, Clustering, Collaborative Filtering, ...
• RDD 기반과 데이터프레임 기반의 두 버전이 존재
  • spark.mllib vs. spark.ml
    • spark.mllib가 RDD 기반. spark.ml은 데이터프레임 기반
    • spark.mllib는 RDD 위에서 동작하는 이전 라이브러리로 더 이상 업데이트가 안됨
  • 항상 spark.ml을 사용!
    • import pyspark.ml

🍦 장점

• 원스톱 ML Framework!
  • 데이터프레임과 SparkSQL등을 이용해 전처리
  • Spark ML을 이용해 모델 빌딩
  • ML Pipeline을 통해 모델 빌딩 자동화
  • MLflow로 모델 관리하고 서빙 (MLOps)
• 대용량 데이터도 처리 가능

🍦 예시

기본적으로 대용량 데이터 배치 처리, 스트림 처리, 모델 빌딩

• 예 1) 대용량 비구조화된 데이터 처리하기 (ETL 혹은 ELT)
• 예 2) ML 모델에 사용되는 대용량 피쳐 처리 (배치/스트림)
• 예 3) Spark ML을 이용한 대용량 훈련 데이터 모델 학습

✔ 프로그램의 구조

• Driver: 실행되는 코드의 마스터 역할 수행 (YARN의 Application Master)
  • 사용자 코드를 실행하며 실행 모드(client, cluster)에 따라 실행되는 곳이 달라짐
  • 코드를 실행하는데 필요한 리소스를 지정
  • 보통 SparkContext를 만들어 Spark 클러스터와 통신 수행
    • Cluster Manager (YARN의 Resource Manager)
      • local[n]
        • 개발/테스트용
        • n은 코어(executor)의 수
        • local[*]: 컴퓨터에 있는 모든 코어 사용
          

          

      • YARN
        • 두 개의 실행 모드: Client vs. Cluster
        • Client 모드: Driver가 Spark 클러스터 밖에서 동작
          • YARN 기반 Spark 클러스터를 바탕으로 개발/테스트 등을 할 때 사용
        • Cluster 모드: Driver가 Spark 클러스터 안에서 동작
          • 하나의 Executor 슬롯을 차지
          • 실제 프로덕션 운영에 사용되는 모드
      • Kubernetes
      • Mesos
      • Standalone
    • Executor (YARN의 경우 Container)
  • 사용자 코드를 실제 Spark Task로 변환해 Spark 클러스터에서 실행
• Executor: 실제 Task를 실행해주는 역할 수행
  • 실제 Task를 실행해주는 역할 (JVM): Transformations, Actions
  • YARN에서는 Container