[BigData] 빅데이터와 하둡

여재우·2024년 1월 15일
bigdatahadoop
0

LIT

목록 보기
19/21

빅데이터의 정의

1. 서버 한대로 처리할 수 없는 규모의 데이터

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

대표적인 기존 소프트웨어: 오라클, MySQL과 같은 관계형 DB

  • 분산환경을 염두에 두지 않음

    • Scale-up 접근방식
      - 메모리 추가, CPU 추가, 디스크 추가

3. 4V(Volume, Velocity, Variety, Varecity)

빅데이터의 특징

  • Volume: 데이터의 크기가 얼마나 큰지
  • Velocity: 데이터의 처리 속도가 중요한지
  • Variety: 데이터가 구조화/비구조화 인지
  • Veracity: 데이터의 품질이 좋은지

빅데이터 처리가 갖는 특징

  • 큰 데이터를 손실 없이 보관할 방법이 필요함
    • 스토리지, 큰 데이터 저장이 가능한 분산 파일 시스템 필요
  • 처리 시간이 오래 걸리는 것을 해결 해야함
    • 병렬처리가 가능한 분산 컴퓨팅 시스템 필요
  • 비구조화된 데이터를 처리 해야함, SQL만으로는 부족
    • ex) 웹 로그 파일

결국 다수의 컴퓨터로 구성된 프레임웍이 필요

대용량 분산 시스템 이란?

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

하둡이란?

  • 다수의 노드로 구성된 클러스터 시스템
    • 마치 하나의 거대한 컴퓨터처럼 동작
    • 사실은 다수의 컴퓨터들이 복잡한 소프트웨어로 통제

하둡의 발전

하둡 1.0

💡 하둡 1.0은 HDFS위에 MapReduce라는 분산컴퓨팅 시스템이 도는 구조

하둡 2.0

  • 하둡 2.0에서 아키텍쳐가 크게 변경됨
    • 하둡은 YARN이란 이름의 분산처리 시스템 위에서 동작하는 어플리케이션이 됨
    • Spark는 YARN위에서 애플리케이션 레이어로 실행됨

HDFS - 분산 파일 시스템

  • 데이터를 불록 단위로 나눠 저장
    • 블록 크기: 128MB (Default)
  • 블록 복제 방식 (Replication)
    • 각 블록은 3군데에 중복 저장됨
    • Fault tolerance를 보장할 수 있는 방식으로 이 블록들이 저장됨
  • 하둡 2.0 네임노드 이중화 지원
    • Active & Standby
      • 둘 사이에 Share edit log가 존재
    • Secondary 네임 노드는 여전히 존재

MapReduce - 분산 컴퓨팅 시스템

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

YARN의 동작 방식

  • 분산 컴퓨팅 시스템: 하둡2.0(YARN 1.0)
  • 세부 리소스 관리가 가능한 범용 컴퓨팅 프레임웍
    • 리스소 매니저
      • Job Scheduler, Application Manager
    • 노드매니저
    • 컨테이너
      • 앱 마스터
      • 태스크
  • Spark이 이 위에서 구현됨

YARN의 동작

  1. 실행에 필요한 파일들은 application ID에 해당하는 HDFS 폴더에 미리 복사됨
  2. AM은 프로그램 마다 하나씩 할당되는 프로그램 마스터에 해당
  3. RM은 data locality를 고려해서 리소스(컨테이너)를 할당
  4. 이 때 실행에 필요한 파일들이 HDFS에서 Container가 있는 서버로 먼저 복사
  5. 태스크가 실패하거나 보고가 오랜 시간 없으면 태스크를 다른 컨테이너로 재실행

하둡 3.0의 특징

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

MapReduce 프로그래밍의 특징

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

Map과 Reduce

  • Map: (k, v) → [(k`, v`)]
    • 입력은 시스템에 의해 주어지며 입력으로 지정된 HDFS 파일에서 넘어옴
    • 키,밸류 페어를 새로운 키,밸류 페어 리스트로 변환 (transformation)
    • 출력: 입력과 동일한 키, 밸류 페어를 그대로 출력해도 되고 출력이 없어도됨
  • Reduce: (k’, [v1’, v2’, v3’, v4’, …]) → (k’’, v'')
    • 입력은 시스템에 의해 주어짐
      • 맵의 출력 중 같은 키를 갖는 키/밸류 페어를 시스템이 묶어서 입력으로 넣어줌
    • 키와 밸류 리스트를 새로운 키,밸류 페어로 변환
    • SQL의 GROUP BY와 흡사
    • 출력이 HDFS에 저장됨

MapReduce: Data Skew

  • 각 태스크가 처리하는 데이터 크기에 불균형이 존재한다면?
    • 병렬처리의 큰 의미가 없음. 가장 느린 태스크가 전체 처리 속도를 결정
    • 특히 Reducer로 오는 데이터 크기는 큰 차이가 있을 수 있음
      • Group By나 Join등에 이에 해당함
      • 처리 방식에 따라 Reducer의 수에 따라 메모리 에러등이 날 수 있음

MapReduce 프로그래밍의 문제점

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

MapReduce의 대안들

  • 더 범용적인 대용량 데이터 처리 프레임웍들
    • YARN, Spark
  • SQL: Hive, Presto등
    • Hive
      • MapReduce위에서 구현
      • Throughput에 초점
      • 대용량 ETL에 적합
    • Presto
      • Low latency에서 초점
      • 메모리를 주로 사용
      • Adhoc 쿼리에 적합
      • AWS Athena 기반
profile
여재우
꾸준히 학습하고 기록하기 위한 log
이전 포스트

[BI] Docker환경에 Superset 구축

다음 포스트

[Spark] 데이터 처리

0개의 댓글