[Hadoop] Hadoop Basics 1. 왜 하둡을 사용하여야 할까?

hwwwa·2023년 3월 25일

hadoop

🐘 BigData Programming

목록 보기

4/6

Motivation

single drive에서 모든 데이터를 읽는다면 매우 많은 시간이 소요됨
multiple disks에서 한번에 읽으면 어느정도 문제 해결 가능
- 100개의 드라이브가 있다면, 각각 1/100의 데이터만 읽기
- 문제점
  - Hardware failure → replication(복제)로 해결
  - 데이터 결합 시 오류. 정합성을 지키는 것이 어려움.

Hadoop 사용 이유

왜 대용량 처리에서 Relational database 대신에 Hadoop이 필요할까?
RDB
- Relationship: 정규화를 통해 데이터를 나눔. 중복 관리. JOIN으로 데이터 조회
- 일부 데이터만 조회할 때 적합
Hadoop
- bruteforce. 큰 데이터에서 대부분의 데이터를 불러오는 대용량 일괄처리에 적합
- 전체 데이터셋을 대상으로 비정형(ad hoc) 쿼리를 빠르게 수행
- batch process(모아서 한번에 처리) vs stream process(실시간 처리)
- HDFS는 write-once, read-many-time(한번 쓰고 여러번 읽기)의 모토로 설계됨
  - 데이터셋은 생성되거나 복제된 것. 이에 대한 분석 작업들이 이루어짐
  - 전체 데이터를 읽는 시간이 첫 번째 레코드를 읽는 대기시간보다 중요함
- HDFS에서 대용량 데이터를 읽어올 때 Streaming Data Access 패턴을 보장해준다
  - 데이터가 끊기지 않고 처음부터 끝까지 잘 불러올 수 있게 만든 것이 하둡
  - 랜덤 탐색 없이 파일의 시작점부터 sequential하게 쭉 읽어나가는 것
Seek time은 transfer rate 보다 느리게 향상됨
- 왜 여러개의 디스크를 이용하는 데이터베이스의 데이터를 분석하기 어려울까? (하둡의 관점에서)
- Data access pattern이 seek에 치우치는 경우, dataset seek time이 streaming(transfer rate)보다 더 오래 걸릴 수 있음
  - seek time: 탐색시간. 하드디스크 헤드가 데이터의 트랙위치로 이동하는데 걸리는 시간
  - transfer rate: 대역폭. 전송시간. 찾은 데이터를 사용자의 버퍼로 보내는데 걸리는 시간
    
    → HDFS는 block 크기를 키워서 문제 해결
  - 대용량 데이터를 읽을 때 seek time의 영향이 줄어들고 디스크의 물리적인 속도인 transfer rate와 데이터를 읽는 속도가 거의 비슷해질 수 있음
latency: 데이터를 읽을 때 하둡에는 preprocessing 단계가 있음

Splitting

데이터 사이즈를 더 작게 split 했을 때 어떤 trade-off가 발생할까?
- 너무 작게 split하면 조각들을 관리하고 map task를 생성하는 오버헤드가 전체 실행 시간을 좌우할 수 있음
- mater node는 한 대 인데, master node에서 관리하는 메타 데이터를 불러올 때 병목 현상이 발생. main node에 대한 부하 발생
- 적절한 split 사이즈는 HDFS block 크기. 하둡은 default 128MB

Comparison with others

B-Tree vs MapReduce

B-Tree: RDB에서 사용하는 자료구조
DB 전체 레코드 중에서 작은 부분을 업데이트하는 경우 → B-Tree(RDB) 사용
- 작은 양의 데이터를 낮은 seek time에 추출하고 변경하기 위해 데이터셋을 인덱싱
- 지속적으로 변경되는 데이터셋에 적합
DB 전체 레코드 중 대부분을 업데이트하는 경우 → MapReduce 사용
- 비정형 분석과 같은 일괄 처리 방식으로 전체 데이터셋 분석이 필요한 작업에 적합

structured data vs semi-structured data vs unstructured data

structure in the datasets on which systems operate
structured data
- 정형 데이터. 미리 정의된 특정 스키마를 가진 DB 테이블처럼 형식이 정의된 항목으로 구조화
- csv, xml, RDB data, ...
- RDBMS에서 관리
semi-structured data
- 반정형 데이터. 정형 데이터에 비해 스키마가 유연하거나 생략될 수 있음. 데이터 구조에 대한 최소한의 규칙만 존재하면 됨
- 서버 로그 데이터. json, NoSQL, ...
- Hadoop에서 관리
unstructured data
- 비정형 데이터. 어떠한 내부 구조도 없음
- plain text, video, ...
- Hadoop에서 관리

Scaling

다양한 하둡 처리 모델은 데이터의 크기에 따라 Linear하게 확장됨
데이터는 분할되고 맵과 리듀스 같은 기본 함수는 분리된 파티션에서 병렬로 데이터 처리 가능
입력데이터의 크기가 두 배라면 작업이 두 배 느리게 실행됨
클러스터 크기가 두 배가 되면 작업이 기존보다 더 빠르게 수행됨
RDBMS의 SQL 쿼리는 nonlinear이기 때문에 scaling out 불가능
Scale out: 가로로 병렬 확장
Scale up: 기기의 성능 자체를 올리는 것

RDBMS vs MapReduce

	Traditional RDBMS	MapReduce
Data size	Gigabytes	Petabytes
Access	Interactive and batch	Batch
Updates	Read and write many times	Write once, read many times
Structure	Static schema	Dynamic schema
Integrity	High	Low
Scaling	Nonlinear	Linear

RDBMS는 nonlinear이므로 scaling out 불가능
MapReduce는 Write Once, Read Many times의 철학을 가진다 → WORM
- write가 필요한 경우 중간 데이터를 수정하는 것이 아니라 append로 다시 만든다
In fact, the differences between Hadoop systems and RDBMs are blurring.
- 사실상 발전해오면서 두 개념의 차이점이 모호해졌음

Grid Computing & Volunteer Computing

Grid computing
- MPI(Message Passing Interface)를 이용해 대규모 데이터를 처리
- compute-intensive(계산 중심) job에 적합, data-intensive(대용량 데이터) job에 비적합
  - 데이터 접근 시 네트워크 대역폭으로 인해 병목 현상 발생, compute node는 놀게됨
- data locality ⭐️
  - MapReduce는 compute node에 data를 함께 배치
    - 데이터가 로컬에 있으므로 접근이 빠름
- MPI는 low-level programming을 요구
  - 개발자에게 더 많은 제어권을 주지만, 고수준 분석 알고리즘뿐만 아니라 저수준 C 루틴과 socket과 같은 구성요소를 통해 data flow machanism을 명확하게 다룰 것을 요구함
  - checkpoint와 장애 복구를 명확하게 관리해야 함
- MapReduce는 high level programming에서만 동작
  - 개발자는 내부 data flow를 신경쓰지 않아도 됨
  - key-value와 같은 data model의 관점에서만 생각하면 됨
  - 실패한 task를 자동으로 감지하여 장애가 없는 node에 다시 배치하도록 구현되어있어 개발자가 failure에 대해 크게 고민하지 않아도 됨 (MapReduce가 task간의 상호 의존성이 없는 Shared-nothing 아키텍처이기 때문)
Volunteer computing(자발적 컴퓨팅)
- SETI@home
  - very CPU-intensive (Volunteers are donating CPU cycles, not bandwidth)
  - 쉬고있는 Volunteer 컴퓨터들의 CPU 연산력을 사용
  - chunk(청크) 단위로 문제 분리, 분석을 위해 전 세계의 컴퓨터로 전송
  - 작업 단위를 전송하는 시간이 계산하는 시간보다 빠르기 때문에 전 세계 수십만대의 컴퓨터에서 실행하는 데 적합
- MapReduce는 신뢰 가능한 전용 하드웨어에서 수 분 또는 수 시간 내에 실행되도록 설계됨
  SETI@home은 인터넷에서 신뢰 불가능한 머신에서도 오랜 시간 동작