Introduction to Hadoop - neozeus79/study GitHub Wiki

빅데이터란 무엇인가?

빅데이터의 3대 요소 https://t1.daumcdn.net/cfile/tistory/125FFF3A50A709C41C
- 크기(volumn)
  - 수십 테라바이트, 페타 바이트
- 속도(velocity)
  - 빠른 데이터 처리
- 다양성(variety)
  - 정형 (structured)
  - 반정형 (semi-structured)
  - 비정형 (unstructured)

하둡이란 무엇인가?

google이 발표한 논문(Google File System, MapReduce)을 더그커팅이 구현한 결과물
오픈소스 검색엔진 너치(nutch)에 적용하기 위해 시작
2008년 아파치 최상위 프로젝트로 승격
분산 파일 시스템 HDFS(Hadoop Distributed File System)에 데이터를 저장하여 분산 처리 시스템인 MapReduce를 이용하여 데이터 처리 방식

왜 하둡인가?

Hadoop vs. RDBMS
- Hadoop
  - 라이센스 비용: 오픈소스 프로젝트여서 소프트웨어 라이센스 비용에 대한 부담이 없음.
  - scale-out
  - 데이터 처리 방식: 여러대의 서버에 데이터를 저장하고, 데이터가 저장된 각 서버에서 동시에 데이터를 처리하는 방식
  - 장점: 저렴한 구축 비용, 비용 대비 빠른 데이터 처리, 장애를 대비한 특성(데이터 복제본 저장을 통한 데이터 유실이나 장애 발생 때 데이터 복구 가능)
- RDBMS(관계형 데이터베이스)
  - 정형 데이터의 경우 저장하는데 용이하지만, 웹로그와 같은 비정형 데이터들은 RDBMS에 적재하기에는 크기가 너무 큼
  - 상용 RDBMS 가 설치된 곳은 대부분 고가의 장비여서 무작정 장비를 늘리기에는 비용 문제가 있음
  - 라이센스 비용: 비용 부담 있음.
  - scale-up
  - 데이터 처리 방식: 데이터가 저장된 서버에서 데이터를 처리
Haooop Ecosystem
- hadoop을 효율적으로 사용하기 위한 다양한 서브 프로젝트 제공
  - 코디네이터: zookeeper
  - 리소스 관리: yarn, mesos
  - 데이터 저장: Hbase, Mesos
  - 데이터 수집: Chuckwa, Flume, Scribe, Sqoop, Hiho, Kafka
  - 데이터 처리: Pig, Mahout, Spark, Impala, Presto, Hive, Tajo
  - 워크플로우 관리: oozie. Airflow, Azkaban, Nifi
  - 데이터 시각화: Zepplin
  - 데이터 직렬화: Avro, Thrift

하둡에 대한 오해

RDBMS를 대체한다?
- 대체하는 것이 아닌 상호 보완적인 관계
  - 분석을 위한 데이터 처리시 거치는 ETL과정에 도움을 줌
- 하둡은 트랜젝션이나 무결성이 반드시 보장되어야 하는 시스템(제품 구매, 인터넷뱅킹 등...)에 적합하지 않음.
  - 데이터 무결성이 중요한 데이터는 트랜젝션 별로 무결성(일관성)을 보장하는 RDBMS에서 처리
  - 배치성으로 데이터를 처리하고, 저장하는 것은 hadoop에서 처리
하둡은 NoSQL이다?
- RDBMS가 아니지만, NoSQL도 아니다.
  - 하둡이 데이터베이스 시스템의 역할을 수행하는 것은 아님.
- NoSQL?
  - 관계형 데이터 모델이나 SQL문을 사용하지 않는 데이터베이스 시스템(혹은 저장소)
  - No SQL or Not Only SQL
  - RDBMS가 분산 환경에 적합하지 않아서 이를 극복하기 위해 고안된 것
  - RDBMS가 엔티티간의 관계에 중점을 두고 테이블 구조를 설계하는 방식이라면,
  - NoSQL은 키와 값의 쌍으로만 이루어짐. 인덱스와 데이터로 분리되어 별도로 운영됨. 조인이 없고, 데이터를 하나의 집합된 형태로 저장함(RBBMS는 row 단위), 샤딩이라는 기능이 있어서 데이터를 분할해 다른 서버에 나누어 저장

Hadoop1 구성 요소

HDFS (Hadoop Distributed File System)

특징
- 장애 복구
  - 데이터 저장시 다른 서버에 복제 데이터도 함께 저장하여 데이터 유실을 방지
  - 분산 서버간에 주기적으로 상태를 체크하여 빠른 시간에 장애 인지(오류시 분산 서버간 네트워크 차단)
- 스트리밍 방식의 데이터 접근
  - 클라이언트 요청을 빠른 시간내에 처리하는 것 보다 동일한 시간에 더 많은 데이터를 처리하는 것을 목표로 함
  - HDFS는 랜덤 접근 방식(임의의 위치에서 필요한 데이터만 읽고 쓰는 방식) 대신 스트리밍 방식으로 데이터에 접근 하도록 설계
- 대용량 데이터 저장
  - 하나의 파일이 GB, TB 이상의 크기일 경우 이를 분산 저장하여 대용량 데이터 저장이 가능하도록 설계 됨.
- 데이터 무결성
  - 한번 저장된 데이터는 읽기만 가능하고 수정 불가 (2.0 알파 버전 부터는 저장된 파일에 append 가능)
  - 파일 이동, 복사, 삭제할 수 있는 인터페이스는 제공
HDFS 아키텍쳐
- 블록 구조의 파일 시스템
  - 64MB의 블록(chunk)으로 나누어 분산된 여러 서버에 나누어서 저장 (hadoop2 = 128mb)
  - 참고) 64mb 이유? (참고. 일반 디스크 블록 크기 = 4kb)
    - 디스크 seek time 감소
      - 디스크 탐색 시간을 디스크 전송 대역폭의 1% 정도로 되도록 구성
        
        디스크 탐색 시간 = 데이터 위치 찾는 시간(seek time) + 데이터 섹터에 도달하는 시간 (search time)
        
        일반적인 seek time = 10ms, 디스크 전송 대역폭 = 100mb/s
    - 네임노드가 유지하는 메타데이터의 크기 감소
      - 메타데이터 = 블록위치, 파일명, 디렉토리 구조, 권한 정보 등..
      - 메모리에 저장하여 관리하다 보니 제한된 메모리 크기에서 블록 크기를 작게하여 블록의 개수가 많아지면 저장 할 수 있는 데이터가 줄어들게 됨
    - 클라이언트와 네임노드의 통신 감소

NameNode (master)
- 기능
  - 메타데이터 관리
    - 파일 시스템 이미지(파일명, 디렉토리, 크기, 권한) + 파일 블록 맵핑 정보
    - 빠른 응답을 위해 메모리에 전체 데이터를 로딩하여 관리
  - 데이터 노드 모니터링
    - 데이터 노드가 전송하는 heartbeat를 이용해 데이터 노드 상태, 용량 모니터링
    - 일정기간 heartbeat가 없을 경우 장애 발생 서버로 판단
  - 블록 관리
    - 데이터 노드에 장애가 발생하거나 용량이 부족할 경우 해당 데이터 노드 블록을 신규 데이터 노드에 복제하여 블럭 복제수를 관리 함.
  - 클라이언트 요청 접수
    - HDFS에 접근하려면 네임노드에 먼저 접속
    - 조회시 블록의 위치 정보 반환, 저장시 기존 파일 저장 여부와 권한 확인 거쳐서 승인
DataNode (slave)
- 클라이언트가 HDFS에 저장하는 파일을 로컬 디스크에 유지
  - 저장 파일 종류: 실제 데이터, 메타데이터(체크섬, 파일 생성일자 등)
- 네임노드에게 3초마다 Heartbeat 메세지 전송(데이터 노드 상태 정보 + 저장된 블록 목록)

MapReduce

Mapreduce란?
- HDFS에 저장된 파일을 분산 배치 처리를 할 수 있게 도와주는 프레임워크
  - 개발자: mapreduce 프로그램 모델에 맞게 애플리케이션 구현
  - Mapreduce Framework: 데이터 전송, 분산처리, 내고장성(fault tolerance)등의 복잡한 부분 자동 처리
MapReduce 아키텍쳐
- Client
  - 사용자가 실행한 MapReduce 프로그램과 하둡에서 제공하는 맵리듀스 API 의미
- JobTracker
  - client가 하둡으로 실행을 요청하는 맵리듀스 프로그램을 Job이라는 하나의 작업 단위로 관리
  - hadoop cluster에 등록된 전체 잡의 스케쥴을 관리. 모니터링
  - 하둡 클러스터 전체에서 하나의 JobTrancker가 실행되며, 보통 NameNode 서버에서 실행
- TaskTracker
  - client가 요청한 MR프로그램 실행하는 역할을 하고, Hadoop의 DataNode 서버에서 실행
- 동작
  1. 사용자가 새로운 Job 요청 하면, 처리에 필요한 Map, Reduce 실행 개수(slot 수) 계산
  2. 어떤 TaskTracker에서 실행할지 결정
  3. TaskTracker에 Job 할당
  4. TaskTracker는 JobTracker의 작업 수행 요청을 받아 요청한 slot개수 만큼 Task 생성하고 신규 JVM 구동해서 MR프로그램 실행
  5. JobTracker와 TaskTracker는 HeartBeat 메소드를 이용하여 네트워크 통신을 통해 Task의 상태 와 작업 실행 정보를 주고 받음
  6. TaskTracker 장애 발생하면 다른 TaskTracker를 찾아서 재실행
MapReduce DataFlow
- Map 단계: 입력 파일을 한줄 씩 읽어서 데이터를 변형(Transformation)
  1. 입력 데이터를 고정된 크기로 분리(input-split)
  - 저장된 블록을 다시 분리하는 것은 아님(가상분리)
  1. input-split은 Map task의 입력 데이터로 전달
  2. MapTask는 input-split의 데이터를 레코드 단위로 맵함수 실행
  3. MapTask 출력 데이터는 TaskTracker가 실행되는 로컬 디스크에 저장됨.
  - 출력시 출력키를 기준으로 정렬
  - HDFS에 저장되지 않고 로컬 디스크에 저장하는 이유는 중간데이터이기 때문에 영구 보관할 필요 없어서 이며, 작업이 완료 되면 삭제됨
- Suffle 단계 : MapTask의 출력 데이터가 ReduceTask에게 전달되는 일련의 과정
  1. 파티셔너가 맵 출력레코드의 출력키 해시값을 구한다.(default: hash(key) % reduce 개수)
  - 각 해쉬값은 레코드가 속하는 파티션 번호로 사용
  - 파티션은 실행할 리듀스 개수만큼 생성
  1. 파티셔닝된 Map 출력데이터는 네트워크를 통해 ReduceTask에 전달
  - 처리할 데이터가 모두 모일때 까지 대기했다가 모두 모이면 데이터를 정렬하고 입력 데이터로 병합
  1. ReduceTask는 병합된 데이터를 레코드 단위로 읽음
- Reduce 단계: 맵의 결과 데이터를 집계 (Aggregation)하고 사용자에게 전달할 출력 파일 생성
  1. ReduceTask는 사용자가 정의한 Reduce함수를 레코드 단위로 실행
  2. 출력 데이터는 Reduce 개수만큼 파일 생성되어 HDFS에 저장 됨.

Hadoop2

Yarn

Yarn 등장 배경
- MapReduce 의 SPOF(Single Point of Failure, 단일 고장점): JobTracker
  - 클라이언트가 job을 실행 하려면 반드시 JobTracker가 실행 중이어야 함.
  - JobTracker의 메모리 이슈
    - JobTracker는 메모리 상에 전체 실행 정보 유지하는데 메모리에 많은 정보를 유지 하다보니 많은 메모리가 필요해서 JobTracker의 메모리가 부족하면 Job 상태 모니터링이 어렵고, 새로운 Job의 실행을 요청 할 수 없음.
- MapReduce 리소스 관리 방식 문제
  - MR은 slot(Map/Reduce slot)이라는 개념으로 클러스터에서 실행하는 Task 수 관리하는데, Map이나 Reduce로 작업이 몰리면 다른 작업이 수행하지 못해 잉여 자원이 되어 리소스가 낭비된다.
- 클러스터 확장 한계
  - 최대 단일 클러스터는 4,000개, 최대 동시 Task 수는 40,000 개가 한계
- MapReduce 프레임워크만 지원
- 버전 통일 제약
  - MR job 실행을 요청하는 클라이언트와 MR 클러스터의 버전 일치 필요
Yarn 목표
- JobTracker 주요 기능 추상화
  - 클러스터 resource 관리, Application life-cycle 관리로 기능 분리
- 다양한 데이터 처리 Application 수용
  - MR= MR API로 구현된 프로그램만 수용 가능
  - Yarn= 실행 요청 Application 모두 수용 가능. MR도 Yarn에서 실행되는 Application 으로 인식
Yarn 특징
- 확장성
  - 단일 클러스터 규모 10,000 노드까지 확장.
- 클러스터 resource 활용 개선
  - Resource Manager라는 신규 컴포넌트 개발하여 cpu, memory, disk, network 등 실제 가용 단위 자원을 관리하고 실행 Application에 자원 분배
- 워크로드 확장
  - MR외 interactive 질의, 실시간 처리, 그래프 알고리즘 등 다양한 워크로드 확정 가능
- MapReduce 호환성
  - hadoop1 에서 수행되던 MR 코드를 수정 없이 그대로 사용 가능.
Yarn 아키텍쳐

주요 기능
- Resource Manager
  - 글로벌 스케쥴러
  - 전체 클러스터에서 가용한 모든 시스템 자원 관리
  - 실행되는 application이 리소스를 요청하면, 이를 적절하게 분배. 리소스 사용 상태 모니터링
- Node Manager
  - MR의 Task Tracker 역할
  - container 를 실행하고 container life cycle 관리
- Container
  - Node Manager가 실행되는 서버의 시스템 자원을 표현
  - MR 이 TaskTracker 에서 task 단위로 실행 되었다면, Yarn 에서는 NodeManager 에서 Container 단위로 application 실행
- Application Master
  - 하나의 Application 을 관리하는 Master 서버
동작
1. client 가 Resource Manager 에게 Application 실행 요청
2. Resource Manager 는 Node Manager를 통해 Application Master 실행 요청
3. Application Master 는 Resource Manager 에게 실행 가능한 container 정보 요청
4. Resource Manager에게 전달 받은 container 정보를 가지고 해당 서버의 Node Manager 에게 Application 실행을 위한 container 생성 요청
5. Node Manager는 container 생성 후 Application 실행
6. Application 실행이 완료 되면 Application Master 에게 전달
7. Application Master 는 Resource Manager 에게 리소스 반환 요청
8. Resource Manager가 해당 서버의 Node Manager를 통해 Container 리소스 반환