Published 2022. 7. 21. 13:00

Hadoop 클러스터 구축 고려사항/하둡 버전에 다른점

ML/Hadoop & Spark

728x90

클러스터(Cluster)란?

-여러 대의 컴퓨터들이 연결되어 하나의 시스템처럼 동작하는 컴퓨터들의 집합

클러스터는 확장성을 가지고 있어서 work -node만 추가하면 확장을 하는 구조를 가지고 있습니다.

Gateway 노드를 따로 두는데 설정파일등을 통해서 클라이언트들의 조건을 통제하것을 수행합니다.

마스터/work Architecture

철수가 사정상 프로젝트 C를 못하는상황이 생기면 해당 프로젝트를 올바르게 대처를 할수 없기에

프로젝트 별로 담당자를 한명이 아닌 두명이 담당을 하면서 백업 식으로 일 처리가 돌아가게 됩니다.

즉 철수가 없더라고 영희가 해당 프로젝트를 처리할수 있습니다.

사람이 즉 노드가 되어 한 노드가 작동을 못하더라도 다른 노드가 해결을 할수 있습니다.

정상적으로 동작을 하지 않아도 장애상황을 대응 하기 위해 다른 work에 파이션을 저장을 해놔서 큰 문제가 일어나지 않습니다.

클러스터 규모 결정하기

스토리지 용량으로 결정하기

저장될 데이터 크기 예측
복제 전략 결정
저장 기간 고려
필요한 노드 수 결정

예시

저장될 데이터 크기 예측

하루에 저장되는 데이터의 크기는 1TB

복제 전략 결정

복제 계수는 3

저장 기간 고려

3년

필요한 노드 수 결정

서버 한대의 저장 용량 : 5TB*12
70대

스토리지 용량으로 결정하기 - 추가 고려사항

데이터 포맷
데이터 압축 여부
데이터 증가율의 변화

데이터 수집 속도로 결정하기

데이터 수집 속도 예측
데이터 처리 속도 예측

데이터수집 속도로 결정하기

1테라비아트 데이터 분석
5분이내에 결과를 저장
쓰기 속도는 디스크당 초당 50MB
디스크 70개가 병렬로 써야함
서버당 디스크가 24개씩 있느 ㄴ경우
약 3대의 서버가 필요

클러스터 하드웨어 결정

워크로드에 따른 하드웨어 선정

CPU
Memore
I/O

AWS에서 EMR 클러스터를 구축할때 어떤 워크로드를 가지고 있냐에 따라 어떤 인스턴스 타입을 선택할지 결정하는것이 워크 로드에 따른 하드웨어 결정을 하는것과 비슷합니다.

Hadoop 구성요소

하둡을 버전을 비교해볼때 크게 변화가 되었습니다.

1.0은 2개의 컴포넌트만 존재하지만 2.0은 중간에 Yarn이 추가가 되어 다른 애플리케이션도 동작을 시킬수 있습니다

예를 들면 아파치 스파크 flink 등 분산 애플리케이션을 동작을 시킬수 있습니다.

버전 1의 타입 입니다.

가장 큰 문제점은 namenode가 단일 장애 지점이라서 동기화의 시간차이가 있기때문에 Secondary namenode가 존재해도 일부 데이터가 유실될수 잇는 문제가 있다.

또한, 클러스터 전체 사용률이 굉장히 낮았습니다.

그리고 jobtracker 역시 클래스터 전체 리소스를 관리하기 때문에 부화가 많이 발생을 한다.

MapReduce외에도 다른 작업을 실행할수 없는 문제점이 있다.

하둡 버전 2.0

1.0과 달리 맵퍼와 리듀서의 슬롯이 별도로 존재하지 않고 둘 다 컨테이너 안에서 동작하여 컨테이너 자체도 따로 슬롯이 ㅅ는것이 아니라 전체 클러스터의 리소스 상황과 요처된 잡의 리소스 요구에 따라 컨테이너가 몇개 실행될지 결정됩니다.

(jopTracker task tracker 대신에 Resource Manager와 node manager가 추가가 되었습니다.)

2.0에서는 하둡1.0에서 4만개 이상의 테스크를 동시에 실행하지 못하는 문제를 Resource Manager와 Application Master의 분리로 해결하였습니다.

Hadoop 3

Erasure Coding 지원
YARN Timeline Service v2 도입
Java 8
NameNode이중화 기능 강화

2개이상의 NameNode기능을 제공합니다.