오늘 공부한 내용🤓

빅데이터

• 서버한 대로 처리할 수 없는 규모의 데이터
• 기존의 SW로는 처리할 수 없는 규모의 데이터
• 4V를 만족하는 데이터
  • Volume : 데이터 크기
  • Variety : 구조화/비구조화
  • Velocity : 데이터 처리 속도
  • Veracity : 데이터의 품질

빅데이터 처리 문제점

1. 큰 데이터를 손실없이 보관할 방법이 필요
   -> 스토리지, 분산 파일 시스템 필요
2. 처리 시간이 오래 걸림
   -> 병렬 처리
3. 비구조화 데이터
   -> SQL 만으로는 역부족, 처리 방법 필요

=> 다수의 컴퓨터로 구성된 프레임 워크 필요
=> 대용량 분산 시스템

분산 환경 기반으로 Fault Tolerance를 유지해야하고 확장에 용한 시스템을 구축해야 한다!

Hadoop(하둡)

• An open source software platform for distributed storage(분산 파일 시스템, HDFS) and distributed processing(분산 컴퓨팅 시스템, MapReduce) of very large data sets on computer clusters built from commodity hardware.
• 다수의 노드로 구성된 cluster 시스템
  • 마치 하나의 거대한 컴퓨터처럼 동작
  • 사실 다수의 컴퓨터들이 복잡한 SW로 통제된다.

HDFS

• Hadoop Distributed File System
• 하나의 마스터인 Name Node와 다수의 Data Node로 구성
• 데이터를 블록 단위로 나눠져서 데이터 노드안에 저장됨
• 블록 크기는 기본적으로 128MB
• 블록 복제 방식 (Replication)
  • 각 블록은 3군데에 중복 저장
  • Fault Tolerance를 보장할 수 있는 방법
• Name Node 이중화 지원(Hadoop 2.0 이상)
  • 절대로 꺼지만 안되기 때문에 Active & Standby 모드가 있음
  • Hadoop 1.0에서 사용했던 Secondary NameNode가 여전히 존재
  • Hadoop 1.0에서는 죽으면 자동으로 연결해주지 않았고, 2.0 버전에서는 Standby 모드였다가 Active 로 자동 전환

Hadoop 1.0

• HDFS 위에 MapReduce라는 분산 컴퓨팅 시스템이 도는 구조
• MapReduce만 사용하면 생산성이 떨어져서 다양한 컴퓨팅 프레임워크(Pgi, Hive, Presto, ...)가 만들어짐

Hadoop 2.0

• MapReduce 위에 프레임워크를 올리는 것이 일반적이니 조금 더 general한 시스템을 만들어서 그 위에 원하는 분산 처리 시스템을 만들도록 하자! 라는 아이디어로 YARN이 탄생
• YARN 1.0 버전
• Pig, Hive, Presto, ... : MapReduce, YARN 두 환경 위에서 모두 가능
• Spark, ... : YARN 위에서만 돌아가는 YARN Application

Hadoop 3.0

• YARN 2.0 사용
  • YARN 프로그램들을 논리적인 그룹(flow라고 부름)으로 나눠서 자원관리 가능
  • 비슷한 용도끼리 나눠서(데이터 수집 프로세스, 데이터 서빙 프로세스, ...) 관리
  • 타임라인 서버(YARN에서 발생하는 이벤트를 기록하는 서버)에서 HBase를 기본 스토리지로 사용
• 파일 시스템
  • NameNode에서 다수의 Standby Name Node 지원
  • HDFS, S3, Azure Storage 이외에도 Azure Data Lake Storage 등을 지원

MapReduce

• 하나의 Job Tracker와 다수의 Task Tracker로 구성
• Task Tracker와 Data Node는 하나의 서버에 구성하지만,
  Job Tracker와 Name Node는 중요한 시스템이기 때문에 Main Server를 2개를 구축해서 하나씩 설치하는 것을 권장

• 데이터 셋은 오직 key-value 집합만 가능하며, 변경 불가(immutable)
• 데이터 조작은 map과 reduce 이 2개의 오퍼레이션으로만 가능
  • 이 두 연산은 항상 하나의 쌍으로 연속으로 실행
  • 개발자가 이 두 연산의 코드를 채워야 한다.
  • 한 번 실행했다고 데이터 셋이 완성되는 것이 아니라, 여러번 실행하여 결과가 나오는 것이 일반적

Map

• 입력으로 들어오는 key-value 페어를 다른 key-value 페어나 리스트로 만들어주는 과정(Transformation)
• 데이터 블록 별로 Map 연산이 진행된다.
• input : 시스템에 의해 주어지며, 입력으로 지정된 HDFS 파일에서 넘어온다.
• output : 입력과 동일한 key-value 페어를 그대로 출력해도 되고, 출력이 없어도 되고, 여러 개를 묶은 리스트 형태여도 된다.

Reduce

• Map의 output을 새로운 key-value 페어로 변환하는 과정
• SQL의 GROUP BY와 흡사
• input : Map의 output 중 같은 key를 갖는 페어를 시스템이 묶어서 넣어준다.
• output: HDFS에 저장

Shuffling & Sorting

• Map에서 Reduce로 넘어갈 때 시스템에서 처리하는 일련의 작업들
• Shuffling
  • mapper의 출력을 reducer로 보내주는 프로세스
  • mapper의 결과를 같은 key를 갖는 value들을 묶는다.
  • 전송되는 데이터의 크기가 크면 네트워크 병목을 초래하고 시간이 오래 걸린다.(data skew)
• Sorting
  • 모든 mapper의 출력을 reducer가 받을 때 이를 key별로 sorting하는 과정

Data Skew

각 task가 처리하는 데이터 크기에 불균형이 존재할 때 발생한다. 가장 느린 task가 전체 처리 속도를 결정하므로 병렬처리에 의미가 없어진다.
특히, Reducer로 나눠지는 데이터의 크기가 큰 차이가 있으며, 처리 방식과 Reducer의 수에 따라 메모리 에러 등이 날 수 있다.
데이터 엔지니어가 가장 고생하는 이유 중 하나이다.

MapReduce의 문제점

1. 낮은 생산성
   • 2가지 연산만 지원하므로 프로그래밍 모델이 가진 융통성 부족
   • 데이터 분포가 균등하지 않을 경우 튜닝/최적화가 쉽지 않다.
2. 배치 작업 중심
   • 디스트를 통해 입출력이 이뤄지므로 low latency(빠른 데이터 처리)가 아니라 throughput(대용량 처리)에 초점이 맞춰져 있다.
3. shuffling 이후에 data skew 발생하기 쉬움
   • Reduce task 수를 개발자가 지정해줘야 한다.

MapReduce 대안

1. 더 범용적인 대용량 데이터 처리 프레임워크 등장
   • YARN, Spark
2. SQL의 복귀
   • Hive, Presto

YARN

• 하둡 2.0/3.0에서 사용됨
• 하나의 마스터인 Resource Manager와 다수의 Node Manager로 구성
• 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임워크
• Resource Manager은 Job Scheduler와 Application Manager로 이루어져 있다.
• Node Manager은 서버에 해당하는 리소스(컨테이너)들을 관리하고 Resource Manager가 Node Manager에게 자원을 요구하면 비어있는 리소스를 전달
• 컨테이너는 Java의 JVM과 같은 의미로, 두가지 형태(App Master, Task)로 프로세스를 지원

YARN 동작 방식

1. 실행코드와 환경정보를 RM(Resource Manager)에게 제출
2. RM은 놀고있는 컨테이너를 가진 NM(Node Manager)을 찾아 AM(Application Master) 실행
3. AM은 입력 데이터 처리에 필요한 리소스(컨테이너)를 RM에게 요구
4. AM은 할당받은 리소스를 NM을 통해 컨테이너에서 코드를 실행 -> Task
5. 각 task들은 상황을 주기적으로 AM에게 업데이트 -> Heartbeat

Spark

Spark vs MapReduce

Spark	MapReduce
메모리기반 (부족하면 디스크 사용)	디스크 기반
하둡(YARN) 이외에도 다른 분산 컴퓨팅 환경 지원 (K8s, MESOS,...)	하둡(YARN) 위에서만 동작
Pandas의 dataframe과 개념적으로 동일한 데이터 구조 지원	key-value 기반 데이터 구조만 지원
다양한 방식의 컴퓨팅 지원 (배치 데이터 처리, 스트림 데이터 처리, SQL, 머신러닝, 그래프 분석)	배치 데이터 처리만 가능

Spark API

• RDD(Resilient Distributed Dataset)
  • low level 프로그래밍 API로 세밀한 제어 가능
  • 코딩 복잡도 증가
• DataFrame & Dataset
  • high level 프로그래밍 API로 점점 많이 사용되는 추세
  • 구조화 데이터 조작이라면 보통 Spark SQL 사용
  • DataFrame과 Dataset이 필요한 경우
    • SQL만으로 할 수 없는 일일 때
    • ML 피쳐 엔지니어링을 하거나 Spark ML을 쓸 때

Spark SQL

• 구조화된 데이터 처리를 SQL로 처리
• DataFrame을 SQL로 처리 가능
• 초기에는 Hive 쿼리보다 최대 100배까지 빠른 성능
  현재, 모두 발전하면서 속도는 비슷해졌다.

Spark ML

• ML 관련 다양한 알고리즘, 유틸리티로 구성된 라이브러리(단, 딥러닝 지원은 미약)
  Classification, Regression, Clustering, Collaborative Filtering, ...
• spark.mllib : RDD 기반, 더이상 업데이트 X
• spark.ml : Dataframe 기반
• 원스톱 ML 프레임워크
  • Dataframe과 SparkSQL 등을 이용해 전처리
  • Spark ML을 이용해 모델 빌딩
  • ML Pipeline을 통해 모델 빌딩 자동화
  • MLflow로 모델 관리하고 서빙(MLOps)
• 대용량 데이터도 처리 가능

Spark 실행환경

• 개발/테스트/학습 환경(Interactive Clients)
  • 노트북(주피터, 제플린)
• 프로덕션 환경(Submit Job)
  • spark submit(CLI utility) : 가장 많이 사용
  • 데이터 브릭스 노트북 : 노트북 코드를 주기적으로 실행해 주는 것이 가능
  • REST API
    • Spark Standalone 모드에서만 가능
    • API를 통해 Spark Job을 실행
    • 실행 코드는 미리 HDFS 등의 파일 시스템에 적재되어 있어야 한다.

Spark 구조 (YARN 환경 기준)

• Driver
  • 실행되는 코드의 마스터 역할 수행(YARN의 application master)
  • 실행하는 모드(cluster, client)에 따라 실행하는 곳이 달라짐
    • cluster : Driver가 spark 클러스터 안에서 동작하여 프로덕션 환경 운영할 때 사용한다.
    • client : Driver가 spark 클러스터 밖에서 동작하여 개발/테스트할 때 사용한다.
  • 코드를 실행하는데 필요한 리소스를 지정
  • Spark session을 만들어 spark 클러스터와 통신 수행
    • cluster manager(YARN의 경우 Resource Manager)
    • Executor(YARN의 경우 container)
  • 사용자 코드를 실제 spark task로 변환해 spark 클러스터에서 수행
• Executor
  • 실제 task를 실행해주는 역할 수행(YARN의 container)

---

느낀 점😊

정말 생각보다 내용도 많고 어렵고 알찬 수업이었다.
3년 전 쯤에 spark에 대해 궁금해서 살짝 열어봤다가 이해가 안되서 접었었는데 강사님 설명으로 그때 생겼던 궁금증들의 90% 이상이 해결됐다. 물론 이제는 다른 궁금증들이 생겼지만 이번에 배운 내용을 기반으로 스스로 하나씩 채워나갈 수 있을 것 같다.