빅데이터와 분산 처리 시스템(TIL 45)

석형원·2024년 6월 17일

TIL hadoop spark yarn

TIL

목록 보기

44/52

✏️ 오늘 학습한 내용

1. 빅데이터의 정의
2. 빅데이터 처리가 갖는 특징
3. 하둡(Hadoop)
4. YARN 동작 방식
5. 맵리듀스 프로그래밍
6. 하둡 설치
7. Spark
8. Spark 프로그램 실행 옵션

🔎 빅데이터의 정의

서버 한대로 처리할 수 없는 규모의 데이터
( 아마존의 Data Scientist, John Rauser가 내린 정의 )

기존의 소프트웨어로는 처리할 수 없는 규모의 데이터

빅데이터의 특성 4V

Volume : 데이터의 크기가 대용량인지
Velocity : 데이터의 처리 속도가 중요
Variety : 데이터의 특성이 구조화/비구조화 데이터 중 무엇인가?
Veracity : 데이터의 품질이 좋은가?

📃 빅데이터의 예시

디바이스 데이터

모바일 디바이스의 위치 정보
스마트 TV
각종 센서 데이터 (Iot 센서)
네트워킹 디바이스

웹 데이터

수십 조개 이상의 웹 페이지
웹 검색엔진 개발이야 말로 진정한 대용량 데이터 처리 기술
-> 구글이 빅데이터 기술의 발전에 지대한 공헌
사용자 검색어와 클릭 정보 자체도 빅데이터
-> 데이터 마이닝하여 개인화 시도
웹 자체가 NLP 거대 모델 개발의 훈련 데이터로도 사용됨

🔎 빅데이터 처리가 갖는 특징

빅데이터 처리의 특징

큰 데이터를 손실 없이 보관할 방법이 필요
-> 분산 파일 시스템 필요 (S3, HDFS)
처리 시간이 오래걸림
-> 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
비구조화 혹은 반구조화된 데이터일 가능성이 높음 (ex) 웹 로그)
-> SQL 만으로는 처리하기 힘듬

즉, 빅데이터를 처리하기 위해선 다수의 컴퓨터로 구성된 프레임워크가 필요합니다.

대용량 분산 시스템이란?

분산 환경 기반 ( 다수의 서버로 구성 )
- 분산 파일 시스템과 분산 컴퓨팅 시스템이 필요
Fault Tolerance
- 소수의 서버에 문제가 생겨도 동작해야함
확장의 용이성
- Scale Out이 되어야함
  ( 서버 수 늘리기 )

🔎 하둡(Hadoop)

하둡(Hadoop)의 등장
- Doug Cutting이 구글랩 발표 논문들에 기반해 만든 오픈소스 프로젝트

하둡이란?

Hortonworks의 정의

An open source software platform for distributed storage and distributed processing of ver large data sets on computer clusters built from commodity hardware
distributed storage : 분산 파일 시스템 HDFS
distributed processing : 분산 컴퓨팅 시스템 MapReduce

즉, 다수의 노드로 구성된 클러스터 시스템 (Cluster)

하둡의 발전

Hadoop 1.0 :
MapReduce 분산 컴퓨팅 시스템이 도는 구조

Hadoop 2.0 :
YARN이란 이름의 분산 처리 시스템 위에서 동작,
Spark는 YARN 위에서 애플리케이션 레이어로 실행됨
( 1.0에 비해 아키텍쳐가 크게 변경됨 )

-> 1.0의 MapReduce라는 분산 처리 시스템의 생산성이 떨어진다는 제약점을 극복하고자 보다 일반적인 분산 처리 시스템을 만든 것이 2.0의 YARN

HDFS (분산 파일 시스템)

하나의 큰 데이터가 들어오면 블록 단위로 쪼개 다수의 서버에 나눠서 저장
- 블록의 크기는 128 MB (default)
블록 복제 방식 (Replication)
- 블록 단위로 다수의 서버에 저장을 하는 경우,
  특정 서버가 고장이 나면 블록이 소실될 위험이 존재
- 이를 막기 위해, Fault tolerance를 보장할 수 있는 방식으로 블록들을 저장
- 각 블록은 3 군데에 중복 저장됨
하둡 2.0 내임노드 이중화 지원
- 내임노드 :
  - 데이터 노드를 관리하는 마스터 노드
  - 데이터 블럭들이 어느 데이터 노드들에 있는지 등의 정보를 가지고 있는 디렉토리
  - 항상 3 군데에 데이터 노드가 저장이 될 수 있도록 백그라운드에서 명령을 내리는 역할도 수행
  만약, 내임노드가 무슨 이유에서든 동작하지 않는다면?
  
  HDFS에 있는 정보가 의미가 없어지기 때문에 내임 노드 이중화가 매우 중요해집니다.
- 초기 하둡 1.0에서는 Secondary 내임노드를 두어, 내임노드가 정지되었을 때, 엔지니어가 직접 수동으로 Secondary 내임 노드 기반으로 내임 노드를 생성해야 했습니다.
- 하둡 2.0에서는 Active & Standby 라는 2개의 내임 노드를 만들었습니다. ( 내임노드 이중화 )
  - Active 내임 노드의 문제가 생기면 Standby 내임 노드가 자동으로 그 역할을 대신해줍니다.
  - Secondary 내임 노드도 여전히 존재합니다.

MapReduce : 분산 컴퓨팅 시스템

하나의 Job Tracker, 다수의 Task Tracker로 구성
- 잡 트래커가 일을 나눠서 다수의 태스크 트래커에게 분배
- 태스크 트래커에서 병렬 처리
MapReduce만 지원
- General한 시스템이 아님

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

세부 리소스 관리가 가능한 범용 컴퓨팅 프레임워크
- 리소스 매니저
  ( Job Schuduler, Application Manager )
- 노드 매니저
  ( 그 서버에 해당하는 리소스들을 관리 )
- 컨테이너
  ( java의 JVM, 2가지 형태가 존재 )
  - 앱 마스터
  - 태스크
맵리듀스와 유사하나 범용적으로 더 많은 기능을 지원
Spark이 이 YARN 위에서 구현됨

🔎 YARN 동작 방식

YARN의 동작

클라이언트( MapReduce 혹은 Spark )가 실행하려는 코드와 환경 정보를 리소스 매니저에게 전달

실행에 필요한 파일들은 application ID에 해당하는 HDFS 폴더에 복사가 미리 복사됨
리소스 매너저가 노드 매니저를 통해 앱 마스터를 실행

YARN Application마다 하나의 앱 마스터가 생성됨
앱 마스터가 리소스 매니저에게 코드에 실행에 필요한 리소스를 받아옴

리소스 매니저는 data locality를 고려해서 컨테이너(리소스)를 할당
앱 마스터가 노드 매니저를 호출하여 컨테이너들에서 코드를 실행 ( 태스크 )

이때, 실행에 필요한 파일들이 HDFS에서 Container가 있는 서버로 먼저 복사됨
태스크들은 자신의 상황을 주기적으로 앱 마스터에게 업데이트 (heartbeat)

태스크가 실패하거나 보고가 오랜 시간 동안 없으면 태스크를 다른 컨테이너로 재실행
( Fault tolerance를 보장 )

하둡 3.0의 특징

YARN 2.0을 사용
YARN 1.0 대비 YARN 2.0의 차별점

YARN 프로그램들의 논리적인 그룹(플로우)으로 나눠서 자원 관리가 가능

이를 통해 데이터 수집 프로세스와 데이터 서빙 프로세스를 나눠서 관리 가능

예를 들어, YARN이 다용도로 사용이 될 때,
비슷한 목적을 가진 APP끼리 리소스를 공유 가능

즉, 리소스 관리 측면에서 매우 효율적

파일 시스템
- 내임 노드의 경우 다수의 스탠바이 내임노드를 지원
- HDFS, S3, Azure Storage 외에도 추가로 Azure Data Lake Storage 등을 지원

🔎 맵리듀스 프로그래밍

맵리듀스 프로그래밍의 특징

기본적으로 큰 데이터를 처리하는데 목표를 둠,

그러다보니 데이터 셋의 포맷도 하나로 단순화시키고,
모든 데이터 셋은 한번 만들어지면 변경할 수 없게 만듬

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

맵리듀스 프로그래밍의 핵심 (Map, Reduce)

Map : (k, v) -> [(k', v')*]
- 입력은 시스템에 의해 주어짐,
  입력으로 지정된 HDFS 파일에서 넘어옴
- key, value 쌍을 새로운 key, value 페어 리스트로 변환 (transformation)
- 출력 : 입력과 동일한 key, value 쌍을 그대로 출력해도 되고 출력이 없어도 됨
Reduce : (k’, [v1’, v2’, v3’, v4’, …]) -> (k’’, v'')
- 입력은 시스템에 의해 주어짐
  ( Map의 출력 중 같은 key를 갖는 key/value 쌍을 시스템이 묶어서 입력으로 넣어줌 )
- key value 리스트를 새로운 key value 쌍으로 변환
- SQL의 Group by와 유사
- 출력이 HDFS에 저장됨

MapReduce 프로그래밍 예제

이 경우, 입력이 key값은 랜덤하게 지정되고 value값은 텍스트로 지정됨
-> Map 관점에서 key-value쌍으로 보이도록 지정

Map의 출력은 단어가 key가 되고 갯수가 value가 되는 새로운 key-value 쌍이 됨

이 출력을 시스템이 모아서 같은 key를 갖는 레코드들을 하나의 레코드로 묶어서 Reduce의 입력으로 넣음

이때, 맵과 리듀스가 별도의 서버에서 작동한다고 한다면? 이런 데이터들이 시스템에 의해서 묶여서 다른 서버로 네트워크를 통해서 전송이됨
( Shuffling )

또한, Reduce에 전달하기 전에 다양한 Map 태스크에서 나온 출력들을 한번 묶어 줘야함
( Sorting )

Reduce의 숫자에 따라서 최종 파일의 수가 결정됨

주의 : 특정 Reduce로 데이터가 너무 많이 몰리는 Data skew가 발생할 수 있음

Map: (k, v) -> [(k', v')*]
-> 키,밸류 페어를 새로운 키,밸류 페어 리스트로 변환

ex)
Input: (100, “the brave yellow lion”)
-> 100은 의미 없는 랜덤한 값
Output: 
[
 (“the”, 1),
 (“brave”, 1),
 (“yellow”, 1),
 (“lion”, 1)
]

Reduce: (k’, [v1’, v2’, v3’, v4’, …]) -> (k’’, v'')
-> SQL의 GROUP BY와 동일
-> 키,밸류 리스트를 새로운 키,밸류 페어로 변환

ex)
Input: ("lion": [1, 1, 1])
Output: ("lion": 3)

MapReduce: Shuffling and Sorting

Shuffling
- Mapper의 출력을 Reducer로 보내주는 프로세스를 의미
- 전송되는 데이터의 크기가 크면 네트워크의 병목을 초래하고 시간이 오래 걸리게 됨
- 맵과 리듀스가 별도의 서버에서 작동해도 네트워크를 통해 전송됨
Sorting
- 모든 Mapper의 출력을 Reducer가 받으면 이를 key별로 sorting

MapReduce: Data Skew

각 태스크가 처리하는 데이터 크기에 불균형이 존재한다면?
- 병렬처리의 큰 의미가 없게됨
  -> 가장 느린 태스크가 전체 처리 속도를 결정
- 특히 Reducer로 오는 데이터 크기는 큰 차이가 있을 수 있음
  ( Group By나 Join 등이 이에 해당함 )
이는 데이터 엔지니어가 고생하는 이유 중의 하나
-> 빅데이터 시스템에는 이 문제가 모두 존재

MapReduce 프로그래밍의 문제점

낮은 생산성
- 프로그래밍 모델이 가진 융통성 부족
  (2가지 오퍼레이션만 지원)
- 튜닝/최적화가 쉽지 않음
  ex) 데이터 분포가 균등하지 않은 경우
배치작업 중심
- 기본적으로 Low Latency가 아니라 Throughput에 초점이 맞춰짐 ( 대용량 처리에만 집중됨 )

MapReduce 대안들의 등장

더 범용적인 대용량 데이터 처리 프레임웍들의 등장
-> YARN, Spark
SQL의 컴백: Hive, Presto등이 등장
- Hive
  - MapReduce 위에서 구현됨.
    ( Throughput에 초점 )
  - 대용량 ETL에 적합
- Presto
  - Low latency에서 초점
    ( 메모리를 주로 사용, Adhoc 쿼리에 적합 )
  - AWS Athena가 Presto 기반

🔎 하둡 설치

리눅스 서버에 하둡 3.0을 의사분산 모드로 설치
-> 의사분산 모드는 Hadoop 관련 프로세스들을 개별 JVM으로 실행
Ubuntu 20.04에서 진행
자바 8 필요
( 하둡을 설치하기 위해선 자바 8이 필요 )
클라우드 환경에서 설치하는 경우
( AWS 우분투 EC2 t2.medium 인스턴스가 적정 )

설치 문서대로 설치를 진행

하둡 웹 UI - HDFS

내임 노드 (포트번호 : 9870)
데이터 노드 (포트번호 : 9864)

위 포트를 통해서 노드들에 Access 가능

맵리듀스 프로그램 실행 (단어수 세기)

hadoop을 설치 후에 생긴 bin/hadoop을 이용

WordCount 프로그램 실행
- bin/hadoop jar hadoop-*-examples.jar wordcount input output
  
  실행하고 싶은 jar파일을 지정 (examples.jar),
  그 jar파일의 중 어느 코드를 실행할 것인가 (wordcount),
  코드의 파라미터로 예상되는 것들을 지정,
  wordcount의 경우 두 파라미터,
  input (hdfs 상의 디렉토리),
  output (리듀스의 결과를 출력할 파일)
- bin/hadoop == bin/yarn
  ( 위 2개는 같은 명령어 )

HDFS 입력/출력 살펴보기

bin/hdfs dfs -ls input
bin/hdfs dfs -ls output

실행 예시)

cd hadoop-3.3.4/

# 사용자 계정에 해당하는 폴더가 생성이 안되어 있는 경우 미리 생성해주어야함
# 사용자는 hdoop이라 가정
bin/hdfs dfs -mkdir /user
bin/hdfs dfs -mkdir /user/hdoop

# 위 과정이 안되어 있으면 생성이 안됨
bin/hdfs dfs -mkdir input

# input값으로 txt파일 하나 생성 (랜덤한 문자가 들어간 텍스트 파일)
vi.words.txt
# input 폴더에 업로드
bin/hdfs dfs -put words.txt input
# 확인
bin/hfds dfs -ls input

# wordcount 예제 프로그램이 들어가있는 jar 파일의 위치를 지정
bin/hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-3.3.4.jar wordcount input output

# -> 여기서 경로는 실행하는 사람의 hdfs를 기준으로 생각함

# 결과 확인
bin/hdfs dfs -ls output
bin/hdfs dfs -cat output/part-r-00000

MapReduce 프로그래밍 문제점

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

🔎 Spark

Hadoop이 1세대 빅데이터 처리 기술이라면 Spark은 2세대 빅데이터 기술이라 할 수 있습니다.

버클리 대학의 AMPLab에서 아파치 오픈소스 프로젝트로 2013년에 시작
YARN 등을 분산환경으로 사용
Scala로 작성됨
빅데이터 처리 관련 다양한 기능 제공

Spark 3.0의 구성

Spark Core
Spark SQL
Spark ML
- Spark MLlib ( 없어지는 단계 )
Spark Streaming
Spark GraphX

Spark vs. MapReduce

Spark은 기본적으로 메모리 기반
- 메모리가 부족해지면 디스크 사용
- MapReduce는 디스크 기반
  ( 데이터가 어느정도 작은 규모라면 Spark가 훨씬 빠름 )
MapReduce는 하둡(YARN) 위에서만 동작
- Spark은 하둡(YARN)이외에도 다른 분산 컴퓨팅 환경 지원 (K8s, Mesos)
MapReduce는 key-value 기반 데이터 구조만 지원
- Spark은 판다스 데이터프레임과 개념적으로 동일한 데이터 구조 지원
Spark은 다양한 방식의 컴퓨팅을 지원
- 배치 데이터 처리, 스트림 데이터 처리, SQL, 머신 러닝, 그래프 분석

Spark 프로그래밍 API

RDD (Resilient Distributed Dataset)
- 가장 low 레벨 프로그래밍 API
- 장점 : 세밀한 제어가 가능
- 단점 : 너무 low 레벨이라 생산성이 떨어지고 코딩 복잡도 증가
DataFrame & Dataset (판다스의 데이터프레임과 흡사)
- high 레벨 프로그래밍 API로 점점 많이 사용되는 추세
- 구조화된 데이터 조작이라면 보통 Spark SQL을 사용하는 것이 훨씬 유리
- DataFrame/Dataset이 꼭 필요한 경우는?
  - ML 피쳐 엔지니어링을 하거나 Spark ML을 쓰는 경우
  - SQL만으로 할 수 없는 일의 경우

Spark SQL

Spark SQL은 구조화된 데이터 처리를 SQL로 처리
DataFrame을 SQL로 처리 가능
- 데이터프레임을 테이블처럼 sql로 처리 가능
  ( 가독성도 높아지고 코드의 Readability도 높아짐 )
- Pandas도 동일 기능 제공
  ( Operation이 아닌 SQL을 사용하는 것 )
Hive 쿼리 보다 최대 100배까지 빠른 성능을 보장
( 사실은 그렇지 않음 -> Hive도 그 사이에 메모리를 쓰는 걸로 발전 )
- Hive: 디스크 -> 메모리 ( Tez )
- Spark: 메모리 -> 디스크
- Presto: 메모리 -> 디스크

Spark ML

머신러닝 관련 다양한 알고리즘, 유틸리티로 구성된 라이브러리
Classification, Regression, Clustering, Collaborative Filtering, …
-> 딥러닝 지원은 미약
RDD 기반과 DataFrame 기반의 두 버전이 존재
- 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 데이터 시스템 사용 예들

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

ex 1) 대용량 비구조화된 데이터 처리하기 (ETL 혹은 ELT) - 배치 처리

ex 2) ML 모델에 사용되는 대용량 피쳐 처리 (배치/스트림)

ex 3) Spark ML을 이용한 대용량 훈련 데이터 모델 학습

대용량 비구조화된 데이터 처리

Hive와 Presto를 대체하는 용도로 Spark를 사용
( ETL 혹은 ELT )

ML 모델에 사용되는 대용량 피쳐 처리

feature를 계산해서 NoSQL에 저장
추천 모델 API에 부를 때 파라미터에 사용

🔎 Spark 프로그램 실행 옵션

Spark을 YARN 위에서 실행한다고 가정

Spark 실행 환경

개발/테스트/학습 환경 (Interactive Clients)
- 노트북 (Jupyter, Jeppline)
- Spark Shell (CLI)
프로덕션 환경 (Submit Job)
- spark-submit (command-line utility)
  -> spark 코드를 실행하는데 가장 많이 사용됨
- 데이터브릭스 노트북 :
  노트북 코드를 주기적으로 실행해주는 것이 가능
- REST API :
  ( 거의 사용 안함 )
  - YARN이 아닌 Spark Standalone 모드에서만 사용 가능
  - API를 통해 Spark Job을 실행
  - 실행코드는 미리 HDFS 등의 파일시스템에 적재되어있어야함

Spark 프로그램의 구조 (1)

Driver
- 실행되는 코드의 마스터 역할 수행 (YARN의 Application Master)
Executor
- 실제 태스크를 실행해주는 역할 수행 (YARN의 컨테이너)

Spark 프로그램의 구조 (2)

Driver:
- 사용자 코드를 실행하며 실행 모드(client, cluster)에 따라 실행되는 곳이 달라짐
  
  Cluster 모드에서 실행되는 경우, Driver가 YARN Cluster 안(Container)에서 동작함
  
  Client 모드의 경우, YARN Cluster 밖에서 동작함
  
  차이점 :
  Clinet 모드는 기본적으로 Notebook, Spark Shell처럼 개발/학습/디버깅을 위해서 Cluster 밖에서 돌리는 것
  
  Cluster 모드는 spark-submit와 같은 command-line utility를 써서 개발이 끝난 코드를 Cluster 안에서 돌리는 것
- 코드를 실행하는데 필요한 리소스를 지정함
```
# 실행 중인 Spark Job을 끝내는 데 몇개의 executor가 필요한가?
--num-executors

# executor 마다 몇개의 cpu를 쓰는 지?
--executor-cores 

# executor 마다 얼마나 큰 메모리를 쓰는 지?
--executor-memory
```
- SparkContext를 만들어,
  Spark 클러스터와 통신 수행
  - Cluster Manager
    (YARN의 경우 Resource Manager)
  - Executor
    (YARN의 경우 Container)
- 사용자 코드를 실제 Spark 태스크로 변환해 Spark 클러스터에서 실행
Executor:
- 실제 태스크를 실행해주는 역할 수행 (JVM):
  Transformations, Actions
- YARN에서는 Container가 됨

📃 Spark 클러스터 매니저 옵션

local[n]
YARN
Kubernetes
Mesos
Standalone

local[n]

이 세팅을 이용해서 Spark Shell을 돌리거나,
Pycharm과 같은 IDE에서 Spark Cluster를 실행시킬 수 있음.

여러 노트북 환경에서 Local 모드로 동작하는 Spark Cluster와 Interaction할 수 있음

개발/테스트 용
- Spark Shell, IDE, 노트북
n은 코어의 수 : executor의 수가 됨
local[*]이란?
- 컴퓨터에 있는 모든 코어를 사용한다는 의미

ex) local[4]가 사용되면 하나의 JVM 안에 4개의 쓰레드, 3개의 Executor가 만들어짐

YARN

두 개의 실행 모드가 존재: Client vs. Cluster
Client 모드
- Driver가 Spark 클러스터 밖에서 동작
- YARN 기반 Spark 클러스터를 바탕으로 개발/테스트 등을 할 때 사용
Cluster 모드
- Driver가 Spark 클러스터 안에서 동작
- 하나의 Container 슬롯을 차지
- 실제 프로덕션 운영에 사용되는 모드

요약

빅데이터 정의
서버 한대로 처리할 수 없는 규모의 데이터,
또는 기존의 소프트웨어로는 처리할 수 없는 규모의 데이터
빅데이터 처리 특징
1. 큰 데이터를 손실 없이 보관할 분산 파일 시스템 필요
2. 처리 시간이 오래걸리기에 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
3. 비구조화 혹은 반구조화 된 데이터를 처리할 수단이 필요
대용량 분산 시스템 정의
분산 환경 기반에 Fault Tolerance를 보장되며,
확장이 용이한 시스템
하둡
분산 환경 기반의 다수의 노드로 구성된 클러스터 시스템
맵리듀스 프로그래밍
큰 데이터를 처리하는데 목표를 두어,
Map과 Reduce 두 가지 Operation으로 데이터를 조작

큰 데이터 처리에는 용이하나 낮은 생산성과 배치 작업에 치우쳐있다는 단점이 존재함
Spark
Hadoop 다음의 2세대 빅데이터 기술로,
MapReduce의 단점을 일정 부분 극복하였으며,
빅데이터 처리 관련 다양한 기능을 제공하는 분산 처리 프레임워크입니다.

석형원

데이터 엔지니어를 꿈꾸는 거북이, 한걸음 한걸음

이전 포스트

Airflow 운영과 대안 (TIL 43)

다음 포스트