빅데이터 처리와 Hadoop의 등장
데이터의 크기가 증가하면서 서버 한대로 처리할 수 없는 규모의 데이터인 '빅데이터'의 개념이 등장하였다. 이러한 빅데이터를 처리하기 위해 대용량 데이터를 분산 처리하는 기술인 하둡이 등장하였다. 이후 하둡의 생산성을 증진시키기 위해 Spark가 등장하였는데, 여기서는 빅데이터 처리와 Hadoop에 대해 알아보려고 한다!
빅데이터 처리
빅데이터란?
- 서버 한대로 처리할 수 없는 규모의 데이터
- 기존의 소프트웨어로는 처리할 수 없는 규모의 데이터
- 4V : Volume (크기), Velocity (속도), Variaty (다양성), Veracity (정확성)
빅데이터 처리의 특징과 해결 방안
빅데이터 처리를 위해 데이터를 분산 저장 및 분산 처리가 필요하며, 결국 다수의 컴퓨터로 구성된 프레임워크가 필요하다.
- 스토리지
- 큰 데이터를 손실 없이 보관할 방법이 필요
- 큰 데이터 저장이 가능한 분산 파일 시스템이 필요
- 병렬 처리
- 처리 시간이 오래 걸림
- 병렬 처리가 가능한 분산 컴퓨팅 시스템이 필요
- SQL만으로는 부족
- 웹 로그와 같이 비구조화된 데이터일 가능성이 높음
- 비구조화 데이터를 처리할 방법이 필요
하둡 (Hadoop)의 개념
하둡의 등장
- Doug Cutting이 구글랩 발표 논문에 기반해 만든 오픈소스 프로젝트
- 2003년 The Google File System
- 2004년 MapReduce: Simplified Data Processing on Large Cluster
- 처음 시작은 Nutch라는 오픈소스 검색엔진 하부 프로젝트
하둡이란?
Hadoop은 고가용성 분산성 객체 지향적 플랫폼 (High Availability Distributed Object Oriented Platform)을 뜻하며, 객체 지향적 작업을 병렬 분산하여 고가용성을 확보할 수 있는 시스템이다. JAVA 기반 소프트웨어 플랫폼으로 빅데이터 처리와 스토리지를 관리하는 역할을 한다.
- 상용 하드웨어의 클러스터에 방대한 데이터를 분산 처리할 수 있는 프레임워크
- 다수의 컴퓨터가 소프트웨어로 통제되며, 마치 하나의 거대한 컴퓨터처럼 동작
하둡 (Hadoop)의 발전과 구성 요소
하둡의 발전 ver. 1.0
- HDFS 위에 MapReduce라는 분산 컴퓨팅 시스템이 실행되는 구조
- 생산성 증진을 위해 MapReduce 위에서 다양한 컴퓨팅 언어가 만들어짐 (Presto, Hive)
- HDFS : 대규모 데이터를 분산, 저장, 관리하기 위한 분산 파일 시스템
- MapReduce : 클러스터의 리소스 관리 및 데이터 처리
- 하나의 Job Tracker와 다수의 Task가 존재
- Job Tracker가 Job을 나눠 다수의 Task Tracker에게 분배
- Task Tracker에서 병렬 처리 진행
- 사용자는 Map과 Reduce 두 함수를 이용해 데이터를 처리 -> 뒤에서 따로 설명
하둡의 발전 ver. 2.0
- 1.0과 비교해 아키텍처가 크게 변경
- 기존 JobTracker와 TaskTracker가 사용되지 않고 이를 대체하는 YARN 사용
- YARN의 등장 배경
- 하둡은 YARN이란 이름의 분산처리 시스템 위에서 동작하는 애플리케이션이 됨
- Spark는 YARN 위의 애플리케이션으로 존재
- YARN : 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임워크
- 구성 요소
- Resource Manager : Scheduler, Application Manager
- Node Magager
- Application Master
- Container
- 1.0의 JobTracker의 역할을 Resource Manager, TaskTracker의 역할을 Node Manager가 수행
- Resource Manager : 클러스터 전체 리소스 내에서 다양한 애플리케이션이 동작하도록 총괄
- Node Manager : 각 리소스를 관제하며 Resource Manager에게 heartbeat와 관제 내용을 전송
- 이처럼 YARN은 리소스 관리와 스케줄링, 모니터링을 각각 다른 컴포넌트로 분리
- 구성 요소
YARN의 동작
- 실행 코드와 환경 정보를 Resource Manager (Application Magager)에게 제출
- Resource Manager는 Node Manager를 통해 Application Master 실행
- Application Master는 Resource Manager (Scheduler)를 통해 코드 실행에 필요한 리소스 요청
- Resource Manager는 Data Locality를 고려해서 리소스 (컨테이너)를 할당
- Application Master는 Node Manager를 통해 컨테이너를 받아 코드 실행 (Task)
- Task는 자신의 상황을 주기적으로 Application Master에게 업데이트 (Heartbeat)
- Task가 실패하거나 보고가 오랜 시간 없으면 Task를 다른 컨테이너에서 재실행
HDFS
해당 링크 (HDFS)에서 HDFS의 작동 방식을 더 자세히 확인할 수 있다.
- 대규모 데이터를 분산, 저장, 관리하기 위한 분산 파일 시스템
- 구성 요소
- NameNode
- HDFS의 모든 메타데이터 관리
- client는 메타데이터를 이용해 HDFS에 저장된 파일에 접근 가능
- 파일, 디렉터리의 open, close, rename 등의 기능 수행하고, DataNode와 Block들의 매핑 결정
- DataNode
- 주기적으로 NameNode에서 Block Report (노드에 저장된 블록의 정보)를 전송하여 DataNode가 정상 동작하는지 확인
- client가 요구하는 read, write 기능을 담당
- NameNode
- 데이터를 블록 단위로 나눠 저장
- 추상화 단위로 파일보다 Block을 사용하는 것이 스토리지 서브 시스템을 단순하게 만듦
- Fault Tolerance와 Availability를 제공하기 위한 복제를 효율적으로 수행
- 블록 복제 방식
- 각 블록은 세 곳에 중복 저장 -> 데이터의 유실 방지
- Fault Tolerance를 보장할 수 있는 방식으로 블록 저장
- 하둡 2.0 네임 노드 이중화 지원
- Active NameNode & Standby NameNode, 둘 사이에 share edit log가 존재
- Active NameNode에 문제가 생기면 Standby NameNode가 대체하여 작동
- NameNode에 문제가 생겼을 경우를 대비한 Secondary NameNode는 여전히 존재
MapReduce 프로그래밍
지금까지 하둡 1.0과 2.0의 구조와 각 요소의 작동 방식을 알아보았다. 그중 MapReduce는 Map과 Reduce 함수로 작동하는 요소로 사용자가 직접 작성한 코드를 분산 처리한다. MapReduce의 프로그래밍에 대해 알아보자.
MapReduce 프로그래밍의 특징
- 기본적으로 큰 데이터를 처리할 수 있는 것이 목표
- 분산 컴퓨팅을 지원하기 위한 목적으로 만들어진 프레임워크
- 데이터 셋은 Key, Value의 집합이며 변경 불가
- 데이터 조작은 Map과 Reduce 두 개의 오퍼레이션으로만 가능
- 두 오퍼레이션은 항상 하나의 쌍으로 연속으로 실행
- 오퍼레이션의 코드는 개발자가 작성
- MapReduce 시스템이 Map의 결과를 Reduce 단으로 모아줌
- 이 단계를 Shuffling이라 부르며 네트워크 단을 통한 데이터 이동이 생김
MapReduce 프로그램 동작 예시 : Word Count
Map과 Reduce
MapReduce 프로그래밍 모델은 Map과 Reduce라는 두 단계로 데이터를 처리한다. Map은 입력 파일을 한 줄씩 읽어 데이터를 변형 (Transformation)하며, Reduce는 Map의 결과 데이터를 집계 (Aggregation) 한다.
- Map
- 입력은 시스템에 의해 주어지며, 입력으로 지정된 HDFS 파일에서 넘어옴
- 코드를 통해 key, value 페어를 새로운 key, value 페어 리스트로 변환 (Transformation)
- 출력 : 입력과 동일한 key, value 페어를 그대로 출력해도 되고, 출력이 없어도 됨
- Reduce
- 입력은 시스템에 의해 주어짐
- key와 value 리스트를 새로운 key, value 페어로 변환
- SQL의 GROUP BY와 흡사하며 출력은 HDFS에 저장 (Aggregation)
Shuffling과 Sorting
- Shuffling
- Mapper의 출력을 Reducer로 보내주는 프로세스
- 전송되는 데이터의 크기가 크면 네트워크 병목을 초래하고 시간이 오래 걸림
- Sorting
- 모든 Mapper의 출력을 Reducer가 받으면 이를 키 별로 정렬
Data Skew
각 Task가 처리하는 데이터 크기에 불균형이 존재한다면 병렬 처리의 큰 의미가 없다. 결국 가장 느린 Task가 전체의 처리 속도를 결정하기 때문이다. 위의 이미지에서 Reducer의 입력 데이터 크기의 차이가 존재할 수 있으며, 이러한 문제는 병렬 처리가 필수적인 빅데이터 시스템에 모두 존재한다.
문제점과 대안
- 낮은 생산성
- 프로그래밍 모델이 가진 융통성 부족 : Map과 Reduce 오퍼레이션만 지원
- 튜닝 / 최적화가 어려움, 예) Data Skew
- 배치 작업 중심
- 기본적으로 Low Latency (지연시간)가 아닌 Throughput에 초점을 맞춤
- MapReduce의 대안
- 범용적인 대용량 처리 프레임워크 : YARN, Spark 등
- SQL의 컴백 : Hive, Presto
Reference
https://www.databricks.com/kr/glossary/hadoop
https://velog.io/@kimdukbae/HDFS-Hadoop-Distributed-File-System
'Data Engineering > 빅데이터' 카테고리의 다른 글
[빅데이터] csv vs parquet vs avro vs orc (2) | 2024.11.08 |
---|---|
[빅데이터] 하둡 (Hadoop)과 Spark 개념 정리 (0) | 2024.06.17 |