일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- GCP
- beuatifulsoup
- HTML
- django
- Snowflake
- Til
- 데브코스
- cloud platform
- superset
- AWS
- 코딩 테스트
- 데이터 시각화
- 데이터 엔지니어
- 코딩테스트
- Tableau
- PCCP
- 팀 프로젝트
- Spark
- 코테 연습
- Kafka
- VPC
- airflow
- SQL
- Selenium
- 슈퍼셋
- Today
- Total
주니어 데이터 엔지니어 우솨's 개발일지
데이터 엔지니어링 56일차 TIL 본문
학습내용
빅데이터의 정의
- 서버 한대로 처리할 수 없는 규모의 데이터
- 기존의 소프트웨어로는 처리할 수 없는 규모의 데이터
4V
- Volume : 데이터의 크기
- Velocity : 처리속도
- Variety : 데이터의 특성 (정형, 비정형)
- Varecity : 데이터의 품질
빅데이터의 예 - 웹
- 수십 조개 이상의 웹페이지가 존재
- 온갖 종류의 지식의 바다
- 웹 검색엔진 개발은 진정한 대용량 데이터 처리
- 웹 페이지를 크롤하여 중요한 페이지를 찾아내고(페이지 랭크) 인덱싱하고 서빙한다
- 구글이 빅데이터 기술의 발전에 지대한 공헌
- 최근에는 웹 자체가 NLP 거대 모델 개발의 훈련 데이터로 사용된다.
빅데이터 처리의 특징
- 큰 데이터를 손실없이 보관할 방법이 필요
- 분산 파일 시스템이 필요 (스토리지)
- 처리 시간이 오래걸린다
- 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
- 비구조화된 데이터가 많기에 SQL만으로 처리하기 역부족이다.
- 비구조화 데이터를 처리할 방법이 필요
=> 다수의 컴퓨터로 구성된 프레임웍이 필요하다.
대용량 분산 시스템이란?
- 분산 환경 기반(다수의 서버로 구성)
- 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요
- Fault Tolerance
- 소수의 서버가 고장나도 동작해야한다.
- 확장이 용이해야한다.
- Scale Out이 가능해야한다.
하둡(Hadoop)
- 분산 파일 시스템(HDFS)과 맵리듀스(MapReduce) 프로그래밍 모델을 기반으로 하며, 다양한 데이터 처리 작업을 수행하는 오픈소스 프레임워크
- 다수의 컴퓨터를 마치 하나의 컴퓨터처럼 동작한다.
하둡의 발전
하둡 1.0 : HDFS위에 MapReduce라는 분산컴퓨팅 시스템이 도는 구조
- MapReduce 위에서 다양한 컴퓨팅 언어들이 만들어짐
- 피그, 하이브, 프레스토 등
하둡 2.0 : 아키텍쳐가 크게 변경
- YARN이란 이름의 분산처리 시스템위에서 동작하는 애플리케이션이 됨
- Spark는 YARN위에서 애플리케이션 레이어로 실행된다.
분산 파일 시스템(HDFS)
- 데이터를 블록단위로 나눠 저장
- 블록의 크기는 128MB (Default)
- 블록 복제 방식(Replication)
- 각 블록은 3군데에 중복 저장된다.
- Fault tolerance를 보장할 수 있는 방식으로 이 블록들이 저장된다.
- Fault tolerance : 일시적인 결함 또는 장애에도 계속해서 정상적으로 작동할 수 있는 능력
- 하둡 2.0 네임노드 이중화 지원
- Active & Standby
- 둘 사이에 share edit log가 존재
- Secondary 네임노드는 여전히 존재
MapReduce : 분산 컴퓨팅 시스템
하둡1.0 기준
- 하나의 잡 트래커와 다수의 태스크 트래커로 구성
- 잡 트래커가 일을 나눠서 다수의 태스크 트래커에게 분배
- 태스크 트래커에서 병렬처리
- MapReduce만 지원
- 제너럴한 시스템이 아니다
하둡 2.0 (YARN 1.0)
- 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임워크
- 리소스매니저 : 마스터 역할
- Job Scheduler, Application Manager 존재
- 노드 매니저 : 슬레이브 역할 - 리소스 관리
- 리소스 : 컨테이너(앱 마스터, 태스크)
=> 이 위에서 Spark가 구현됨
YARN의 동작
- 하둡 2.0의 클러스터 자원 관리자
1. 실행하려는 코드와 환경 정보를 RM(Resource Manager)에게 넘김
- 실행에 필요한 파일들은 application ID에 해당하는 HDFS 폴더에 복사가 미리 복사됨
2. RM은 NM(Node Manager)으로부터 컨테이너를 받아 AM(Application Master) 실행
- AM은 프로그램 마다 하나씩 할당되는 프로그램 마스터에 해당
3. AM은 입력 데이터 처리에 필요한 리소스를 RM에게 요구
- RM은 data locality를 고려해서 리소스(컨테이너)를 할당
4. AM은 할당받은 리소스를 NM을 통해 컨테이너로 론치하고 그 안에서 코드를 실행
- 이 때 실행에 필요한 파일들이 HDFS에서 Container가 있는 서버로 먼저 복사
5. 각 태스크는 상황을 주기적으로 AM에게 보고 (heartbeat)
- 태스크가 실패하거나 보고가 오랜 시간 없으면 태스크를 다른 컨테이너로 재실행
하둡 3.0 (YARN2.0 사용)
- YARN 프로그램들의 논리적인 그룹(플로우)으로 나눠서 자원관리가 가능
- 이를 통해 데이터 수집 프로세스와 데이터 서빙 프로세스를 나눠서 관리가 가능하다.
- 타임라인 서버에서 HBase를 기본 스토리지로 사용 (하둡2.1)
- 파일 시스템
- 네임노드의 경우 다수의 스탠바이 네임노드를 지원한다.
- HDFS, S3, Azure Storage 이외에도 Azure Date Lake Storage 등을 지원
MapReduce 프로그래밍의 특징
: 빅데이터를 처리하는데 목표를 둔다.
- 데이터 셋은 Key, Value의 집합이며 변경불가능하다.
- 데이터 조작은 map과 reduce 두 개의 오퍼레이션으로만 가능
- 이 두 오퍼레이션은 항상 하나의 쌍으로 연속으로 실행된다.
- 이 두 오퍼레이션은 코드를 개발자가 채워야한다.
- 맵리듀스 시스템이 Map의 결과를 Reduce단으로 모아준다.
- 이 단계를 보통 셔플링이라 부르며 네트웍단을 통한 데이터 이동이 생긴다
- Map : 입력으로 들어온 key,value 페어를 다른 key,value 페어나 리스트로 만들어 준다. (output이 없을 수 있다.)
- Reduce : Map의 출력 중에 같은 키를 갖는 출력들을 모아서 새로운 key,value 페어를 만들어 준다.
MapReduce 프로그래밍 핵심 : 맵과 리듀스
- Map : (k, v) -> [(k`, v`)*]
- 입력은 시스템에 의해 주어지며 입력으로 지정된 HDFS 파일에서 넘어온다
- 키, 밸류 페어를 새로운 키, 밸류 페어 리스트로 변환(transform)
- 출력 : 입력과 동일한 키, 밸류 페어를 그대로 출력해도 되고 출력이 없어도 된다.
- Reduce: (k', [v1', v2', v3', v4', ... ]) -> (k", v")
- 입력은 시스템에 의해 주어짐
- 맵의 출력 중 같은 키를 갖는 키/밸류 페어를 시스템이 묶어서 입력으로 넣어줌
- 키와 밸류 리스트를 새로운 키, 밸류 페어로 변환
- SQL의 GROUP BY와 흡사
- 출력이 HDFS에 저장됨
MapReduce : Shuffling and Sorting
- Shuffling
- Mapper의 출력을 Reduccer로 보내주는 프로세스
- 전송되는 데이터의 크기가 크면 네트웍 병목을 초래하고 시간이 오래 걸림
- Sorting
- 모든 Mapper의 출력을 Reducer가 받으면 이를 키별로 정렬한다.
MapReduce : Data Skew
- 각 태스크가 처리하는 데이터 크기에 불균형이 존재한다면?
- 병렬처리의 큰 의미가 없어진다. 가장 느린 태스크가 전체 처리 속도를 결정한다
- Reducer로 오는 나눠지는 데이터의 크기는 큰차이가 있을 수 있다.
- Group By나 Join등이 이에 해당한다.
- 처리 방식에 따라 Reducer의 수에 따라 메모리 에러등이 날 수 있다.
- 데이터 엔지니어가 고생하는 이유 중의 하나
- 빅데이터 시스템에는 이 문제가 모두 존재한다.
MapReduce 프로그래밍의 문제점
- 낮은 생산성
- 프로그래밍 모델이 가진 융통성 부족(2가지 오퍼레이션만 지원)
- 튜닝/최적화가 쉽지 않다
- 데이터 분포가 균등하지 않은 경우
- 배치작업 중심
- 기본적으로 Low Latency가 아니라 Throughput에 초점이 맞춰져 있다.
MapReduce의 대안
- 더 범용적인 대용량 데이터 처리 프레임웍들의 등장
- YARN, Spark
- SQL의 컴백 : Hive, Presto
- Hive : MapReduce위에 구현됨, Throughput에 초점, 대용량 ETL에 적합하다
- Presto
- Low latency에 초점, 메모리를 주로 사용, Adhoc 쿼리에 적합
- AWS Athena가 Presto기반
Spark
하둡의 뒤를 잇는 2세대 빅데이터 기술
- YARN등을 분산환경으로 사용
- Scala로 작성됨
- 빅데이터 처리 관련 다양한 기능을 제공한다.
Spark 3.0의 구성
Spark vs MapReduce
- Spark는 기본적으로 메모리 기반
- 메모리가 부족해지면 디스크 사용
- MapReduce는 디스크 기반
- MapReduce는 하웁(YARN)위에서만 동작한다.
- Spark은 하웁(YARN)이외에도 다른 분산 컴퓨팅 환경을 지원한다.(K8s, Mesos)
- MapReduce는 키와 밸류 기반 데이터 구조만 지원한다.
- Spark는 판다스 데이터프레임과 개념적으로 동일한 데이터 구조 지원
- Spark은 다양한 방식의 컴퓨팅을 지원한다.
- 배이 데이터 처리, 스트림 데이터 처리, SQL, 머신 러닝, 그래프 분석
Spark 프로그래밍 API
- RDD(Resilient Distributed Dateset)
- 로우레벨 프로그래밍 API로 세밀한 제어가 가능하다.
- 코딩 복잡도 증가
- DataFrame & Dataset (판다스의 데이터프레임과 흡사)
- 하이레벨 프로그래밍 API로 점점 많이 사용되는 추세
- 구조화 데이터 조작이라면 보통 Spark SQL을 사용
- DataFrame/Dataset이 꼭 필요한 경우는?
- ML 피쳐 엔지니어링을 하거나 Spark ML을 사용하는 경우
- SQL만으로 할 수 없는 일의 경우
Spark SQL
: 구조화된 데이터 처리를 SQL로 처리
- 데이터 프레임을 SQL로 처리 가능
- 데이터프레임은 테이블처럼 sql로 처리 가능
- 판다스도 동일 기능 제공
- 디스크 사용 타입
- Spark : 메모리 -> 디스크
- Presto : 메모리 ->디스크
- Hive : 디스크 -> 메모리
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
Spark ML의 장점
- 원스톱 ML 프레임워크
- 데이터프레임과 SparkSQL등을 이용해 전처리
- Spark ML을 이용해 모델 빌딩
- ML Pipeline을 통해 모델 빌딩 자동화
- MLflow로 모델 관리하고 서빙(MLOps)
- 대용량 데이터도 처리 가능 !
Spark 데이터 시스템 사용 예들
: 기본적으로 대용량 데이터 배치 처리, 스트림 처리 ,모델 빌딩
- 대용량 비구조화된 데이터 처리하기(ETL 혹은 ELT)
- ML모델에서 사용되는 대용량 피쳐 처리 (배치/스트림)
- Spark ML을 이용한 대용량 훈련 데이터 모델 학습
Spark 프로그램의 구조
- Driver : 실행되는 코드의 마스터 역할(YARN의 Application Master)
- 사용자 코드를 실행하여 실행 모드(client, cluster)에 따라 실행되는 곳이 달라진다.
- 코드를 실행하는데 필요한 리소스를 지정한다
: --num-executors, --executor-cores, --executor-memory
- 보통 SparkContext를 만들어 Spark 클러스터와 통신 수행
- Cluster Manager(YARN의 경우 Resource Manager)
- Executor (YARN의 경우 Container)
- 사용자 코드를 실제 Spark 태스크로 변환해 Spark 클러스터에서 실행
- Executor : 실제 태스크를 실행해주는 역할 수행(YARN의 컨테이너)
- 실제 태스크를 실행해주는 역할 수행(JVM) : Transformations, Actions
- YARN에서는 Container가 됨
Spark 클러스터 매니저 옵션
- local[n] : 내 컴퓨터에서 JVM하나짜리 돌리는 옵션
- 개발/테스트용
- n 은 코어의수 : executor의 수가 됨
- local[*] : 컴퓨터의 모든 코어를 사용
- YARN : 클라이언트모드와 클러스터모드가 존재
- Client 모드 : Driver가 Spark 클러스터 밖에서 동작
- YARN 기반 Spark 클러스터를 바탕으로 개발/테스트 등을 할 때 사용한다.
- Cluster 모드 : Driver가 Spark클러스터 내부에서 동작
- 하나의 Executor 슬롯을 차지한다.
- 실제 프로덕션 운영에 사용되는 모드
- Kubernetes, Mesos, Standalone 옵션도 존재
'데브코스' 카테고리의 다른 글
데이터 엔지니어링 58일차 TIL (0) | 2024.06.30 |
---|---|
데이터 엔지니어링 57일차 TIL (0) | 2024.06.30 |
데이터 엔지니어링 55일차 TIL (1) | 2024.06.07 |
데이터 엔지니어링 54일차 TIL (0) | 2024.06.06 |
데이터 엔지니어링 53일차 TIL (1) | 2024.06.05 |