하둡

0. 개요

하둡은 하나의 성능 좋은 컴퓨터 대신, 적당한 성능의 범용 컴퓨터를 클러스터로 구성하여 병렬 분산처리 하는 오픈소스 프레임워크입니다.

주요 구성 요소에는 HDFS, YARN, MapReduce 등이 있습니다.

특히 하둡은 버전에 따라 변경사항이 많기 때문에 각 버전의 대표적인 특징을 설명하겠습니다.

1. 하둡 v1

v1 버전에서는 하둡의 기본 아키텍처가 정립되었습니다.

분산저장은(HDFS)는 네임노드(Namenode)와 데이터노드(Datanode)가 담당합니다.

병렬처리(MapReduce)는 잡트래커(JobTracker)와 태스크트래커가(TaskTracker) 담당합니다.

v1 버전에서 잡트래커에 큰 문제가 있습니다. 잡트래커가 클러스터의 자원관리 및 애플리케이션 라이프사이클 관리 모두 담당했습니다. 이로 인해 최대 4000개의 노드만 등록이 가능했습니다.

또한, 병렬 처리의 작업 단위는 슬롯(slot)인데 맵(Map) 슬롯 리듀스(Reduce) 슬롯의 개수가 정해져 있고 실행 시점에서 역할이 정해지면 슬롯의 용도를 변경할 수 없습니다. 때문에, 맵 작업 중에는 슬롯이 대기 상태로 존재하며 병목현상이 발생합니다.

출처 : https://wikidocs.net/26170

v1의 경우 아키텍처의 구조적인 특징으로 분산처리에 맵리듀스만 가능합니다.

2. 하둡 v2

v2 버전은 YARN 아키텍처를 도입해 v1의 잡트래커의 병목현상을 제거했습니다.

YARN 아키텍처는 잡트래커의 기능을 분리하여 자원 관리는 리소스매니저(Resource Manager) 및 노드매니저(Node Manager)가 담당합니다. 또한, 애플리케이션 라이프사이클 관리는 애플리케이션 마스터(Application Master)가 담당하며 작업 처리는 컨테이너(Container)가 담당합니다.

출처 : https://gachonyws.github.io/assets/images/hadoop_v2.png

이러한 특징으로 1만개 이상의 노드 등록이 가능해졌습니다.

또한, 맵리듀스만 가능했던 v1과 달리 Spark와 같은 다른 분산 처리 모델도 사용 가능해졌습니다.

Federation을 통해 네임노드가 커지는 문제도 해결할 수 있습니다.

3. 하둡 v3

v3에서는 이레이저 코딩을 도입해 HDFS의 사용량을 감소시켰습니다. v2까지는 데이터 블록을 2개 추가 복제(Replication)하여 200%의 용량을 더 사용했습니다. 하지만 RAID 방식의 이레이저 코딩을 사용해 50% 정도만 추가로 사용하도록 변경되었습니다.

또한, 스크립스를 재작성하여 버그 수정 및 성능을 높이고 기본 보트들을 변경했습니다.

4. HDFS

HDFS는 아래와 같은 특징을 지닙니다.

• 블록 단위 저장
  • HDFS는 데이터를 블록 단위로 나눠서 저장합니다.
  • 기본적으로 128MB 크기를 사용하며, 마지막 블록을 제외하고 모두 같은 크기를 지닙니다.
  • 디스크보다 큰 데이터 파일이더라도 블록으로 나뉘어 저장되기 때문에 큰 파일도 저장할 수 있습니다.
• 블록 복제를 이용한 장애 복구
  • HDFS의 기본 복제 단위는 3입니다.
  • 블록은 랙(Rack) 단위로 구분되는데, 복제되는 블록은 서로 다른 랙에 저장됩니다.
  • 블록에 문제가 생기면 복제한 다른 블록을 이용해 데이터를 복구합니다.
• 읽기 중심
  • HDFS는 한 번 쓰면 여러 번 읽는 것을 목적으로 합니다.
  • 때문에, 데이터 수정은 지원하지 않습니다.
  • 실질적 데이터 수정은 델타 파일(Delta File)에 기록되어 사용됩니다.
• 데이터 지역성
  • 네트워크를 이용한 데이터 전송 시간 감소
  • 대용량 데이터 확인을 위한 디스크 탐색 시간 감소
  • 적절한 단위의 블록 크기를 이용한 CPU 처리시간 증가

출처 : https://wikidocs.net/images/page/23582/hdfsarchitecture.png

HDFS는 하나의 네임노드와 여러 개의 데이터노드로 구성됩니다. 네임노드는 메타데이터를 가지고 있어 이를 이용해 데이터를 쓰고 읽을 수 있습니다.

데이터를 읽는 순서는 아래와 같습니다.

1. 네임노드에 파일이 보관된 블록 위치 요청
2. 네임노드가 블록 위치 반환
3. 각 데이터 노드에 파일 블록 요청
   • 노드 블록이 깨져 있으면 네임노드에 이를 알리고 다른 블록 확인

https://wikidocs.net/images/page/23582/스크린샷_2022-01-10_오전_10.41.49.png

데이터를 쓰는 순서는 아래와 같습니다.

1. 네임노드에 파일 정보를 전송하고, 파일의 블록을 써야할 노드 목록 요청
2. 네임노드가 파일을 저장할 목록 반환
3. 데이터 노드에 파일 쓰기 요청
   • 데이터 노드간 복제 진행

5. 네임노드

네임노드의 주요 역할은 메타데이터 관리 및 데이터노드 관리입니다.

메타데이터는 파일이름, 크기, 생성시간, 접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록 정보 등으로 구성됩니다. 각 데이터노드에서 전달하는 메타데이터를 받아서 전체 노드의 메타데이터 정보와 파일 정보를 묶어 관리합니다. 메타데이터는 사용자가 설정한 위치(dfs.name.dir)에 보관됩니다.

메타데이터 파일 종류는 아래와 같습니다.

• Fsimage 파일
  • 네임스페이스와 블록 정보
• Edits 파일
  • 파일의 생성, 삭제에 대한 트랜잭션 로그
  • 메모리에 저장하다가 주기적으로 생성

데이터노드 관리는 데이터노드에 주기적으로 하트비트와 블록리포트를 이용해 데이터노드의 동작상태 및 블록 상태를 관리합니다. 하트비트가 정상적으로 오지 않으면 네임노드는 해당 데이터노드에 IO가 발생하지 않도록 합니다.

네임노드의 구동 과정은 아래와 같습니다.

1. Fsimage를 읽어 메모리에 적재합니다.
2. Edits 파일을 읽서 변경 내용을 반영합니다.
3. 현재의 메모리 상태를 스냅샷으로 생성하여 Fsimage 파일을 생성합니다.
4. 데이터노드로부터 블록 리포트를 수신해 매핑정보를 생성합니다.
5. 서비스를 시작합니다.

6. 세컨더리 네임노드

네임노드가 구동되면 Edits 파일이 주기적으로 생성됩니다. 특히, 트랜잭션이 빈번하면 Edits 파일이 빠르게 생성됩니다. 이는 네임노드의 디스크 부족 문제를 발생시킬 수 있고, 네임노드 재구동 시간을 느려지게 할 수 있습니다.

세컨더리 네임노드는 Fsimage와 Edits 파일을 주기적으로 머지하여 최신 블록의 상태로 파일을 생성합니다. 파일 머지시 Edits 파일을 삭제하기 때문제 디스크 부족 문제를 해결할 수 있습니다.

출처 : https://charsyam.files.wordpress.com/2011/04/fsimage.png

7. 데이터노드

데이터노드는 두 가지 상태로 구분할 수 있습니다.

• 활성상태
  • Live or Dead 상태를 나타냅니다.
  • 하트비트를 네임노드가 받지 못하면 Stale 상태로 변경되고, 지정 시간동안 응답이 없으면 Dead로 변경됩니다.
• 운영상태
  • NORMAL : 서비스 상태
  • DECOMMISSIONED : 서비스 중단 상태
  • DECOMMISSION_INPROGRESS : 서비스 중단 상태로 진행중
  • IN_MAINTENANCE : 정비 상태
  • ENTERING_MAINTENANCE : 정비 상태로 진행 중

8. HDFS Federation

v1은 네임노드가 하나만 존재합니다.

블록이 많아지면 그만큼 메모리에 메타데이터를 저장하는 네임노드의 크기가 커지는 문제가 발생합니다.

HDFS Federation은 디렉토리 단위로 네임노드를 등록하여 사용합니다. 예를 들어 user, tmp 두 개의 디렉토리가 존재할 때, 두 개의 네임노드를 실행하여 각 파일을 관리합니다.

디렉토리 정보를 가지는 네임스페이스와 블록 정보를 가지는 블록 풀(Pool) 각 네임노드가 독립적으로 관리합니다. 네임스페이스와 블록 풀을 네임스페이스 볼륨(Volume)이라 하고, 네임스페이스 볼륨은 독립적으로 관리되기 때문에 하나의 네임노드에 문제가 생겨도 다른 네임노드에 전파되지 않습니다.

출처 : https://hadoop.apache.org/docs/r2.7.2/hadoop-project-dist/hadoop-hdfs/images/federation.gif

9. HDFS HA

네임노드는 HDFS의 **단일 실패 지점(SPOF)**입니다. 때문에, 네임노드에 문제가 발생하면 모든 작업이 중지되기 때문에 v2에서는 네임노드의 이중화로 이 문제를 해결합니다.

액티브 네임노드, 스탠바이 네임노드로 이중화하여 액티브 네임노드에 문제가 발생하면 스탠바이 네임노드를 동작시킵니다. 아파치 주키퍼를 이용해 장애 발생시 자동으로 변경될 수 있도록 합니다.

스탠바이 네임노드는 세컨더리 네임노드의 역할을 동일하게 수행하기 때문제, HA 모드에서는 세컨더리 네임노드를 실행하면 오류가 발생합니다.

출처 : https://hadoopabcd.files.wordpress.com/2015/02/quorum-journal-with-zk.png

10. 이레이저 코딩

HDFS는 복제로 내결함성(Fault Tolerance)을 제공합니다. 기본적으로 3 복제(원본 1, 복제 2)를 합니다. 복제로 인해 200%의 오버헤드가 발생하게 됩니다.

이레이저 코딩(Erasure Coding)은 RAID 스트라이핑 방식을 통해 구현 되었습니다. 이로 인해 약 50% 오버헤드만 발생됩니다.

출처 : https://wikidocs.net/images/page/132171/스크린샷_2021-06-17_오후_4.29.45.png

더 자세한 설명은 여기에서 확인하실 수 있습니다.

11. 맵리듀스

맵리듀스는 간단한 단위작업을 반복하여 처리할 때 사용하는 프로그래밍 모델입니다. 간단한 작업인 맵(Map)과 결과물을 모아서 집계하는 리듀스(Reduce) 단계로 구성됩니다.

하둡에서 맵리듀스 작업은 병렬로 처리 가능한 작업으로, 여러 컴퓨터에서 동시에 작업을 처리하여 속도를 높일 수 있습니다.

출처 : https://wikidocs.net/images/page/22827/스크린샷_2021-05-20_오후_9.59.06.png

맵리듀스의 작업 단위는 하둡 v1, v2에 따라 명칭이 다릅니다.

v1에서 작업 단위는 잡(job)이고, v2에서 작업 단위는 애플리케이션(Application)입니다.

상황에 따라 맵리듀스는 리듀서의 개수가 다를 수 있습니다.

1. 리듀서가 하나인 경우
2. 출처 : https://autofei.files.wordpress.com/2010/06/2-2.png?w=300&h=165
3. 데이터 정렬 작업의 경우 리듀서 하나로 모든 작업을 처리합니다.
4. 리듀서가 여러개인 경우
5. 출처 : https://autofei.files.wordpress.com/2010/06/2-3.png?w=300
6. 일반적 집계 작업의 경우 리듀서가 여러개 생성되고, 리듀서 수 만큼 파일이 생성됩니다. HDFS의 부하 방지를 위해 추가적인 파일 머지 작업이 필요할 수 있습니다.
7. 리듀서가 없는 경우
8. 출처 https://autofei.files.wordpress.com/2010/06/2-4.png?w=300&h=254
9. 원본 데이터를 읽어서 가공을 하고 바로 쓰는 경우입니다. 매퍼 수 만큼 파일이 생성되기 때문에 추가적인 파일 머지 작업이 필요할 수 있습니다.

12 YARN 아키텍처

v2에서 도입한 클러스터 리소스 관리 및 애플리케이션 라이프 사이클 관리를 위한 아키텍처입니다.

YARN은 잡트래커의 기능을 분리하여 자원 관리는 리소스매니저 및 노드메니저가 담당합니다. 애플리케이션 라이프사이클 관리는 애플리케이션 마스터와 컨테이너가 담당합니다.

자원 관리에서 노드매니저는 클러스터의 각 노드마다 실행됩니다. 현재 노드의 자원 상태를 관리하고, 리소스매니저에게 이를 보고합니다.

리소스매니저는 노드매니저로 받은 정보를 이용해 클러스터 전체의 자원을 관리합니다. 자원 사용 상태를 모니터링하고, 애플리케이션 마스터에서 자원 요청을 하면 자원을 사용할 수 있도록 처리합니다.

리소스매니저에서 자원을 분배하는 규칙은 스케줄러를 통해 이뤄집니다. 스케줄러에 의해 설정된 규칙에 따라 자원을 효율적으로 분배합니다.

출처 : https://bigdataanalyticsnews.com/wp-content/uploads/2014/09/Yarn-Architecture.png

라이플 사이클 관리는 아래와 같은 순서로 이뤄집니다.

• 클라이언트가 리소스매니저에게 애플리케이션 제출
• 리소스매니저는 비어있는 노드에서 애플리케이션 마스터 실행
• 애플리케이션 마스터는 작업을 실행하기 위해 자원을 리소스매니저에게 요청
• 애플리케이션 마스터는 할당 받은 자원으로 각 노드에 컨테이너 실행
• 컨테이너에서 작업이 종료되면 결과를 애플리케이션 마스터에게 알림
• 애플리케이션 마스터는 작업 종료를 리소스매니저에게 알리고 자원 해제

YARN 아키텍처로 v1에 비해 다양한 에코 시스템을 동작시킬 수 있습니다.

출처 : https://miro.medium.com/v2/resize:fit:794/1*QOtqppI05HngvmjuZhN6yA.png