데이터 용량
- 연도별 디스크 / 전송 속도
- 1990년 - 1370MB / 4.4MB ⇒ 5분
- 2010년 - 1TB / 100MB ⇒ 2시간 30분
시간이 지남에 따라 데이터의 크기는 커지면서, 전송 속도는 그와 반대로 크게 발전하지 못함
어떻게 해야 해결 할 수 있는가?
→ Disk를 엄청 많이 두고 데이터들을 나누어서 저장한다.
문제1. 하드웨어 장애
- Disk를 많이 둔다는 것은 그만큼 장애 확률이 높아진다.
- RAID를 통해 복사본을 저장한다고는 하지만, 디스크 자체가 장애가 난다면?
- HDFS File System을 통하여 Replicas로 구성
문제2. 데이터를 보고 싶다면, 여러 Disk 결합
- 많은 분산 시스템에서 결합을 지원
- 하지만, 정합성에는 의문
- Network 이슈가 있을 수도 있고 해당되는 데이터가 정말 맞는지 신뢰 할 수 있는가?
- Map-Reduce를 통해 3개의 Node에서 검증 후 2개 이상이 맞다고 하면 신뢰 가능하지 않을까?
Map Reduce란?
- 일괄 질의 처리기
- 전체 Data Set에 대해 비정형 쿼리
- 대화형 쿼리는 불가능 ( 응답시간이 오래 걸리기 때문 )
HBase
- HDFS를 기본 저장소로 구성하며, Key-Value 형태로 구성 ( Online Read/Write, Batch 작업 지원 )
Hadoop2
- Yarn(Yet Another Resource Negotiator) = 클러스터 Resource 관리 시스템
Hadoop vs RDBMS
- DataBase를 여러 Disk로 구성하여 사용하면 되지 않을까?
- 탐색(Read/Write) 시간 > 전송 속도(Bandwidth)
- Dataset의 큰 부분을 Read, Write 하기에는 위에서 나온 전송 속도보다도 더 많은 시간이 필요
RDBMS
- 적은 양의 Data를 요청하기에 Response Time이 적다.
- 지속적으로 변경되는 Dataset에 적합
- Transaction + ACID
- 무결성, 중복제거 필수
- Index, 등의 속도 처리 필수
Hadoop
- Mapreduce 사용
- 비정형 분석과 같이 일괄 처리 방식(Batch)로 전체 데이터 셋 분석시 효과
- One Write Multi Read 시 효율
- Transaction이 존재하지 않는다.
- Read 시 Schema를 별도로 구성
- Log 데이터와 같이 고속의 Read, Write 가능 ( Normalize 하지 않는다 )
Hadoop과 같이 여러 노드에 많은 양의 데이터를 구성하는 경우 네트워크 대역폭을 신경써주어야 한다. ( Data를 많이 이동하면 포화 상태 )
- 가까이 위치하며, 단일 데이터 센터로 구성하여 높은 네트워크 대역폭을 구성하는게 좋다.
Map-Reduce는 자세한 내부 개념을 모른 상태로 Key-Value 관점만 생각하면 되어 용이
그렇다면, 대규모 분산 시스템으로 구성된 경우에 많은 Process들을 어떻게 Control하는 것일까?
- 문제 : 분산 시스템에서 프로세스가 실패인지, 정상인지 어떻게 아는가?
- 프로세스가 실패인지 정상인지 알 수 없다.
- 대안 : Mapreduce를 통해 의존성이 없는 Task(Shared-Nothing Architecture)로 구성
- 실패 처리한 Map을 다시 실행하기 보다 Reduce를 재실행하는데 초점
- 즉, 병렬 처리(여러 노드 Chunk 단위로 분리하여 일을 시킴) 후 정답을 제일 말한 값으로 구성한다.
GFS(Google File System)
- 용량이 큰 파일에 대한 저장소를 어떻게 해결할까?
- Distribute File System을 최초로 정의
- Master는 뇌, Chunk Server는 실제 일을 행하는 팔,다리와 같다.
