Hadoop을 학습해보자 ㅋㅋ

Hadoop은?

• Hadoop은 Big Data를 처리하고 분석하는데 사용되는 OpenSource Software Framework 입니다.
• 저렴한 하드웨어로 구성된 분산 시스템에서 페타바이트 규모의 데이터를 처리 할 수 있도록 설계
• data를 분석 할 때 나눠서 분석하고 합치면 되므로 빠르다.
• 저장된 데이터를 변경하는 것이 불가능하고, 실시간 데이터와 같은 신속한 작업에서는 부적합하다.

Hadoop 구성요소

1. HDFS(Hadoop Distributed File System)
   1. Hadoop 분산 파일 시스템
      1. 데이터를 저장하는 분산형 file system으로 실시간처리보다는 배치처리 목적으로 설계 → 작업량이 작거나 빠른 데이터 응답이 필요한 작업에는 적합하지 않음
   2. 데이터를 여러 노드에 분산저장하여 처리 속도를 높입니다.
   3. NameNode와 DataNode로 구성
      1. NameNode
         1. 분산처리 시스템에서 Master를 담당
            1. Meta데이터 관리와 DataNode를 관리
            2. 각 DataNode에서 전달하는 Meta데이터를 받은 후 전체 노드의 Meta데이터 정보와 파일정보를 묶어서 관리
            3. file system을 유지하기 위해 Meta데이터를 관리
               1. 데이터를 저장할 시 기본적으로 블록단위로 들어옴 → 이때 들어온 블록들을 어느 DataNode에 저장 할 지를 정해준다고 이해하자.
            4. DataNode는 실제로 데이터를 저장하는 컴퓨터이기 때문에 에러가 날 수 있음 → NameNode와 DataNode는 3초마다 Heartbeat을 주고 받는다.
               1. DataNode에서 살아있다고 NameNode에 문서를 보내 알려준다. → 알림이 오지 않으면 문제가 생겼다고 판단.
                  1. 문제가 생긴다면 다른 DataNode에 복제된 블럭을 가지고와서 사용하면 된다.
      2. DataNode에 블록 단위로 나누어 데이터를 저장
         1. 주기적으로 NameNode에 Heartbeat와 Block Report를 전달한다.
            1. Heartbeat : DataNode의 동작여부를 판단하는데 이용
               1. Heartbeat이 전달되지 않는 DataNode는 동작하지 않는것으로 판단 → 더이상 데이터를 저장하지 않도록 설정한다.
            2. Block Report : Block의 변경사항을 체크하고, NameNode의 Meta 데이터를 갱신한다.
      3. Meta 데이터는 전체적인 구조를 나타낸다.
         1. 파일이름, 파일크기, 파일생성시간, 파일 접근권한, 파일 소유자 및 그룹 소유자, 파일이 위치한 블록의 정보 등으로 구성된다.
2. MapReduce
   1. 대규모 데이터 집합을 처리하는 프로그래밍 모델
   2. 입력 데이터를 작은 작업 단위(Map)로 분산하고, 각 작업 단위를 병렬적으로 수행한 후 결과를 하나로 합칩니다.(Reduce)
3. YARN(Yet Another Resource Negotiator)
   1. Hadoop Cluster의 자원관리 시스템
   2. Cluster의 자원을 Application에 할당하고 관리
   3. Container라는 단위로 자원을 관리
      1. Container는 CPU, Memory, Disk 등의 자원을 포함
4. 기타 구성 요소
   1. HBase: NoSQL Database
   2. pig: 데이터 분석을 위한 Scripting 언어
   3. Hive: SQL과 유사한 언어를 사용하여 DataWareHouse 작업을 수행할 수 있도록 하는 도구
   4. Oozie: Hadoop 작업을 자동화하는데 사용되는 도구
   5. Flume: 로그 데이터 등을 실시간으로 수집하는데 사용되는 도구

HDFS’s NameNode&DataNode

NameNode 구동과정

• 기본적으로 네임노드는 fsimage와 edits를 읽어서 작업을 처리한다.
  • 먼저 fsimage를 읽어서 메모리에 적재한 후 edits파일을 읽어와서 변경 내역을 반영한다.
  • 현재의 메모리 상태를 반영하여 fsimage파일을 생성한다.
  • 데이터노드로부터 Block Report를 수신하여 Mapping Info를 생성하고 서비스를 시작한다.

DataNode의 상태

• 데이터노드는 상태를 나타내는 정보로 활성상태와 운영상태를 확인 할 수 있다.

활성상태

• 데이터노드가 live, dead 상태인지 나타낸다.
• 데이터노드가 하트비트를 통해 활성상태가 확인되면 live 상태이다.
• 만약 문제가 발생해서 지정 시간동안 하트비트를 받지 못하면 네임노드는 데이터노드 상태를 Stale상태로 변경하고, 그 이후에도 지정한 시간동안 응답이 없으면 dead 노드로 변경한다.

운영상태

• 운영상태는 보통 데이터노드의 업그레이드나 작업을 하기위해 서비스를 잠시 멈춰야할 경우, 블록을 안전하게 보관하기 위해 설정

HDFS Safemode

safemode는 읽기 전용상태로 DataNode 수정이 불가능해서, 데이터의 추가, 수정, 복제가 일어나지 않는다.
보통 safemode는 Node에 문제가 생겼거나 서버 운영정비를 위해 설정을 한다.(자동으로 설정이 되기도 한다.)

HDFS(Hadoop Distributed File System)의 safemode와 datanode 활성상태는 관련이 있습니다. safemode는 HDFS가 클러스터의 상태를 점검하기 위해 사용되는 특수 모드입니다.

이 모드는 파일 시스템에 변경을 가하지 못하게 하여 데이터의 무결성을 보장합니다.

자세한 관계는 다음과 같습니다:

1. Safemode의 역할
   1. safemode는 HDFS가 시작될 때 활성화되며, 모든 datanode로부터 블록 리포트를 수신하여 클러스터의 데이터 블록 상태를 확인합니다.
   2. 이 과정에서 클러스터의 데이터 무결성을 검사합니다.
   3. 이 상태에서는 파일 시스템에 쓰기 작업이 불가능하고, 읽기 작업만 가능합니다.
2. Datanode 활성상태와의 관계
   1. safemode가 활성화된 동안 Namenode는 모든 Datanode로부터 블록 리포트를 받아야 합니다.
   2. 이 때 모든 Datanode가 활성화 상태여야 하며, 모든 블록이 복제 레벨에 맞게 있는지 확인합니다.
   3. 만약 Datanode가 비활성 상태이거나 블록이 손실되었다면, safemode가 종료되지 않거나 오래 지속될 수 있습니다.
3. Safemode 종료 조건
   1. 일반적으로 safemode는 모든 블록의 복제 수가 설정된 임계값 이상이 되면 자동으로 해제됩니다.
   2. 이 임계값은 전체 블록 중 일정 비율이 정상적일 때 해제되도록 설정할 수 있습니다.
4. 운영상의 고려사항
   1. 클러스터 운영 중에 Datanode가 다운되거나 네트워크 문제로 인해 Namenode가 모든 Datanode와 통신할 수 없으면, safemode가 해제되지 않아 파일 시스템의 쓰기 작업이 중단될 수 있습니다.
   2. 이는 클러스터의 가용성과 성능에 영향을 줄 수 있습니다.

따라서, safemode와 datanode의 상태는 밀접하게 연관되어 있으며, 클러스터의 안정성과 데이터 무결성을 유지하는 데 중요한 역할을 합니다.

HDFS 파일 사용

HDFS의 파일에 대한 내용을 배웠으니 내부 파일을 사용하는 법에 대해 알아보자!

HDFS File Read

HDFS의 파일을 읽는 순서

1. open()명령어를 통해 DistributedFileSystem에 있는 FileSystem의 파일을 open 합니다.
2. RPC(Remote Procedure Call)를 NameNode에 호출하여 저장되어있는 블록이 저장된 DataNode의 주소를 받는다.
3. DistributedFileSystem은 client가 데이터를 검색할 수 있도록 검색을 지원하는 입력스트림은 FSDataInputStream을 client에게 줍니다. 그러면 그것을 통해 찾고자하는 DataNode와 DFSInputStream이 Mapping 됩니다. 그리고 검색 후 read()명령어를 호출 합니다.
4. DataNode 주소가 저장된 DFSInputStream은 DataNode와 연결되고, 데이터는 DataNode에서 client로 가게 됩니다. 이러한 형식으로 반복 read()를 호출하여 파일을 읽습니다.
5. Block 끝에 도달하면 DFSInputStream은 DataNode에 대한 연결을 닫고, 다음 Block에 가장 가까운 DataNode를 찾습니다.
6. 읽기를 마치면 FSDataInputStream에서 close()를 호출 합니다.

Hadoop v3.0이 나왔으니 3.0을 보도록 하자 ㅎㅎ

Hadoop v2 : YARN 아키텍처 도입

• Job Tracker의 병복현상을 제거
• 자원관리: Resource Manager, Node Manager
• (Cluster당 1만개 데이터 등록 가능)
• 작업처리 : Container
  • YARN 아키텍처 작업의 처리 단위
    
    

YARN은 크게 4가지 주요 Component로 구성되어 있다.

• ResourceManager: Cluster 전체의 Resource를 관리하고, Job의 Scheduling을 담당 합니다.
• Node Manager: 각 노드에서 Container를 관리하고, Resource 사용정보를 ResourceManager에게 보고 합니다.
• Application Master: 각 Application에 대해 Resource를 Assing받고, Job을 관리 합니다.
• Container: Application의 Job이 실행되는 Resource 단위 입니다.

Resource 요청 및 할당 과정

1. Application Submit(client)
   1. client가 Application Job을 생성해 ResourceManager에게 제출합니다.(ex. Spark submit)
   2. ResourceManager는 Application에 고유한 Application ID를 부여
   3. Application Job을 관리하는 ApplicationMaster를 실행
      1. Application Job을 관리하고 필요한 리소스를 요청하는 역할!
   4. ResourceManager는 애플리케이션을 실행할 첫 번째 Container를 특정 노드에 할당합니다.
      1. 이 Container는 ApplicationMaster를 실행하는데 사용됩니다.
   5. 최종적으로 첫번째 Container가 할당되고 ApplicationMaster가 실행된 후, ApplicationMaster는 Application을 실행하기 위해 추가적인 리소스를 요청 합니다.
2. Resource 요청
   1. ApplicationMaster는 필요한 Resource를 ResourceManager에게 요청
3. Resource 할당
   1. Resource 상태 확인
      1. Cluster에는 여러 NodeManager가 있으며, 각 NodeManager는 해당 노드의 리소스 상태(CPU, Memory 등)를 관리 합니다.
      2. NodeManager는 정기적으로 자신의 리소스 상태를 ResourceManager에게 보고합니다.
      3. 즉, “현재 이 노드에 얼마만큼의 CPU와 메모리가 사용 가능하다”는 정보를 ResourceManager에 주기적으로 보냅니다.
   2. Resource 할당
      1. ResourceManager는 보고 받은 Resource 상태 정보를 바탕으로, 어느 NodeManager에 리소스를 할당할 수 있는지 결정합니다.
      2. 이 과정은 스케줄러에 의해 수행됩니다. 스케줄러는 클러스터의 리소스를 어떻게 나눌지 결정하는 역할을 합니다. 여기에는 다양한 정책이 사용됩니다:
         1. FIFO (First In First Out): 먼저 온 요청을 먼저 처리합니다.
         2. Capacity: 각 사용자나 그룹이 사용할 수 있는 최대 Resource 용량을 설정합니다.
         3. Fair: 모든 애플리케이션에 공정하게 Resource를 나누어 줍니다.
   3. 할당된 Resource 전달
      1. ResourceManager는 결정된 Resource 할당 정보를 AM과 NM에게 전달합니다.
      2. 예를들어, “NodeManager A, 너는 이만큼의 Resource를 사용해서 이 Container를 실행해라”라는 식으로 명령을 내립니다.
      3. 여기에서 AM은 Application Job을 전체적으로 관리하는 역할을하며 Resource 할당정보를 받으면, 어떤 Job을 어떤 Container에서 실행 할 지 계획을 세우고, 그 계획을 NodeManager에게 전달합니다.
4. Container 실행
   1. NodeManager는 할당된 Resource를 사용하여 Container를 생성 → Container안에서 Application Job을 실행
5. Job 완료
   1. Job이 완료되면, AM은 해당 Container를 종료시키고, ResourceManager에게 Resource를 반환 합니다.
   2. Application의 모든 작업이 완료되면, ApplicationMaster는 자신을 종료하고, ResourceManager에게 Application의 종료를 알립니다.

요약하면

• 리소스 요청: ApplicationMaster가 ResourceManager에 필요한 리소스를 요청합니다.
• 리소스 할당: ResourceManager가 클러스터 상태를 기반으로 리소스를 할당합니다.
• 컨테이너 실행: NodeManager가 할당된 리소스를 사용하여 컨테이너를 실행합니다.
• 작업 완료: 작업이 완료되면 리소스를 반환합니다.

HDFS 사용자 가이드

• hdfs하면?
  • NameNode, DataNode, MetaData가 딱! 생각나야합니다.
  • NameNode, DataNode는 Cluster의 현재 상태를 쉽게 확인할 수 있는 웹서버를 내장하고 있습니다.
    • ex) http://namenode-name:9870/
  • Rack인식: Task를 예약하고 저장소를 할당할 때 Node의 물리적 위치를 고려합니다.
  • Safemode
  • fsck: 파일 시스템의 상태를 진단하고 누락된 파일이나 block을 찾는 utility
  • fetchdt: Delegation Token을 가져와 local system의 파일에 저장하는 utility
  • Balancer: DataNode간 데이터가 고르게 분배되지 않은 경우 Cluster를 균형있게 조정하는 도구
    • Hot spotting을 피하고, 부하를 균등하게 주면서 분산처리를 함
  • Shell Commands
    • Hadoop은 HDFS 및 Hadoop이 지원하는 다른 filesystem과 직접 상호적용하는 다양한 shell과 같은 명령을 포함 합니다.
  • DFSAdmin Command
    • 명령 bin/hdfs dfsadmin은 몇가지 HDFS관리 관련 작업을 지원 합니다.
    • ex) bin/hdfs/dfsadmin -help
  • Secondary NameNode
    • Namespace의 주기적인 checkpoint를 수행하고 NameNode에서 HDFS edits log파일의 크기를 특정 limit내로 유지하는데 도움을 줍니다.
  • Checkpoint Node(=Secondary NameNode)
    • fsimage와 edits를 다운로드하여 local에서 병합하고 새로운 이미지를 활성 NameNode에 업로드 합니다.

HDFS High Availability Using the Quorum Journal Manager

• Quorum Journal Manager(QJM)을 사용하여 Active 및 Standby NameNode간에 edits log를 공유하는 HDFS HA를 구성(변경사항 동기화)하고 사용하는 방법을 다룹니다.
• QJM의 주요 목표는 데이터의 일관성과 내구성을 보장하는 것입니다.

Architecture

• 일반적인 HA 클러스터는 두개 이상의 개별 기기가 NameNode로 구성.
  • 하나의 NameNode가 Active상태에 있으며, 나머지는 Standby상태에 있습니다.
  • 이 구조를 통해, 하나의 NameNode가 장애가 발생하더라도 다른 NameNode가 계속해서 서비스를 제공할 수 있습니다. 이를 통해 시스템이 중단 없이 계속 운영될 수 있습니다.
• 주요 구성요소
  • NameNode
    • Active NameNode: 현재 시스템을 관리하고 파일시스템 요청을 처리하는 주 역할
    • Standby NameNode: AN가 장애발생 시 즉시 이를 대체할 준비가 되어있음.
      • 준비는?
        • Active노드와 Standby노드 간 상태를 동기화 하기 위해서 두 노드는 “JournalNodes”(JNs)라는 별도의 daemon그룹과 통신합니다.
        • Standby노드는 JNs에서 edits log를 읽을수 있으며, 변경사항을 지속적으로 모니터링 하면서 edits log 내용을 확인하여 변경사항을 자신의 namespace에 적용합니다.
  • JournalNodes(JNs)
    • Active NameNode와 Standby NameNode 간에 상태를 동기화하기 위해 사용
    • Active NameNode가 파일 시스템의 변경 사항을 JNs에 기록하면, Standby NameNode가 이를 읽어 동일한 상태를 유지합니다.
      • Active노드가 namespace 수정을 수행할 때마다 이러한 JNs의 다수에게 수정 기록을 내구성있게 기록 합니다.
  • Zookeeper
    • Active NameNode와 Standby NameNode 간의 조정을 담당합니다.
    • 어느 NameNode가 Active인지, Standby가 Active로 전환할 때를 결정하는 역할을 합니다.
• 네임스페이스란?

• 내구성있게 기록이란?
  • Active 노드는 네임스페이스 수정 사항(예: 파일 생성, 삭제 등)을 수행할 때, 이러한 변경 사항을 여러 JournalNodes(JNs)에 보내어 안전하게 기록합니다.
• failvoer가 발생하면
  • Standby는 Active 상태로 승격되기 전에 JournalNodes의 모든 edits 내용을 읽었는지 확인 합니다.
  • 이를 통해 failover가 발생하기 전에 namespace state가 완전히 동기화 되도록 보장 합니다.
• 빠른 failover를 제공하기 위해
  • Standby 노드가 클러스터 내 Block위치에 대한 최신정보를 갖고 있는 것도 필요 합니다.
  • 이를 위해 DataNode는 모든 NameNode의 위치를 구성하고 Block 위치 정보 및 heartbeat를 모두에게 보냅니다.

NameSpace 상태 동기화 과정

• 변경 사항 발생
  • 사용자가 파일을 생성하거나 삭제하는 등의 작업을하면, Active NameNode는 이 변경사항을 Edits log에 기록 합니다.
• Edits log 기록
  • Active NameNode는 변경 사항을 JournalNodes (JNs)에 있는 저널 파일에도 기록합니다.
  • 여러 JN에 동시에 기록하여 내구성을 보장합니다.
    • 예를 들어, 5개의 JN이 있다면 최소한 3개 이상의 JN에 기록되어야 데이터가 안전하게 저장된 것으로 간주합니다.
• Standby NameNode 동기화
  • Standby NameNode는 주기적으로 JNs에서 Edit Log를 읽어와 변경 사항을 적용합니다.
  • 이를 통해 Standby NameNode는 Active NameNode와 동일한 메타데이터 상태를 유지합니다.
• FSImage 업데이트
  • 일정 시간이 지나거나 Edit Log가 너무 커지면, Active NameNode는 FSImage를 업데이트합니다. 이를 “체크포인트”라고 합니다.
  • Standby NameNode도 주기적으로 체크포인트를 수행하여 FSImage를 업데이트합니다.
    • FSImage는 NameNode가 관리하는 메타데이터의 스냅샷이며 이 파일은 파일 시스템의 구조, 파일과 디렉토리 속성(이름,권한, 소유자 등), 블록 매핑정보 등을 포함합니다.
      • 일반적으로 바이너리형식으로 저장 됩니다.
      • NameNode가 시작될 때 FSImage를 로드하여 메모리에 메타데이터를 로딩 합니다.

Quorum Journal Manager사용 시 JournalNode에 기록할 수있는 NameNode는 하나만 허용

• split-brain 시나리오로 인해 파일 시스템 metadata가 손상될 가능성은 없습니다.
  • Split-brain 시나리오는 주로 분산 시스템에서 발생하는 문제로, 네트워크 또는 시스템 장애로 인해 두 개 이상의 독립적인 그룹이 서로 통신하지 못하고 각자 독립적으로 작동할 때 발생합니다. 이는 시스템의 일관성과 안정성에 심각한 위협을 초래할 수 있습니다.
• Split-brain 시나리오의 개념과 문제점
  • 정의
    • Split-brain은 분산 시스템에서 네트워크 장애 또는 하드웨어 장애로 인해 시스템의 일부 그룹이 완전히 분리되어 각각 독립적으로 작동할 때 발생합니다.
    • 이 때 각 그룹은 자신의 상태를 기반으로 결정을 내릴 수 있으며, 이로 인해 시스템 전체의 일관성을 해칠 수 있습니다.
  • 문제점
    • Split-brain 상태에서는 각 그룹이 독립적으로 작동하므로, 동일한 리소스에 대해 각각 다른 결정을 내릴 수 있습니다.
    • 예를 들어, 데이터베이스 클러스터에서 Split-brain이 발생하면 각 그룹이 서로 다른 데이터를 변경할 수 있어 데이터 불일치 문제가 발생할 수 있습니다.
    • 또한, 서로 다른 그룹이 네트워크 복구 후 다시 결합되면, 데이터 충돌이 발생할 가능성이 있습니다.
  • 해결방법
    • Split-brain을 방지하거나 해결하기 위해 다양한 방법이 존재합니다.
    • 주로 사용되는 방법으로는 Quorum 기반의 투표 알고리즘을 활용하여 다수결을 통해 동작하는 방식이 있습니다.
      • 예를 들어, Zookeeper와 같은 분산 코디네이션 서비스가 이러한 문제를 해결하는 데 도움을 줍니다.
        • Zookeeper는 분산 환경에서 일관성 있는 상태 관리와 리더 선출을 담당하는 분산 코디네이션 서비스입니다.
        • 리더 선출: Zookeeper는 여러 서버 중에서 하나를 리더로 선출하여, 그룹 내에서 단일한 결정 권한을 부여합니다. 이를 통해 Split-brain을 방지하고 동일한 상태를 유지할 수 있습니다.
        • 동기화: 클라이언트와 서버 간의 동기화를 위해 Zookeeper는 일관성 있는 상태 관리를 제공합니다. 클라이언트는 Zookeeper를 통해 데이터 노드의 상태 변경이나 설정 값을 동기화하고, 이를 통해 일관성 있는 결정을 내릴 수 있습니다.
        • 클러스터에서 각 노드가 변경 사항을 Zookeeper에 기록하고, 이를 통해 다른 노드들이 변경 사항을 동기화하고 일관성 있는 데이터를 유지할 수 있습니다.
    • 또한, 네트워크 분할 탐지와 자동 복구 메커니즘이 구현된 시스템 구성도 문제를 완화하는 데 도움이 될 수 있습니다.

Automatic Failover

Automatic Failover는 HDFS 배포에 2가지 새로운 구성 Compoents를 추가합니다.

• ZooKeeper quorum
  • 역할: 여러 ZooKeeper 서버가 클러스터를 구성하여 공유 상태와 리더 선출을 관리합니다.
  • 중요성: HDFS에서는 NameNode의 고가용성을 위해 이들 중 하나가 사용됩니다.
• ZooKeeper Failover Controller(ZKFC)
  • Hadoop의 HDFS에서 HA(High Availability)를 구성할 때, 각 NameNode에는 ZKFC가 함께 설치되어 있어야 합니다.
  • ZKFC는 해당 NameNode의 상태를 모니터링하고, ZooKeeper를 통해 NameNode의 상태 및 리더 선출을 조정합니다.
  • 역할: NameNode의 상태를 모니터링하고, Active와 Standby 간의 자동 장애 조치(failover)를 관리하는 Zookeeper 클라이언트인 새로운 Component 입니다.
  • NameNode를 실행하는 각 machine은 ZKFC를 실행하며 다음을 수행합니다.
    • Health monitoring
      • ZKFC는 주기적으로 로컬 NameNode에 health check를 수행하여 상태를 평가합니다. 예를 들어, NameNode가 응답하지 않거나 비정상적인 상태일 경우 이를 감지합니다.
    • Zookeeper session management
      • local NameNode가 healthy한 경우, ZKFC는 Zookeeper에 session을 유지 합니다. Local NameNode가 Active인 경우 특별한 lock znode도 유지 합니다. session이 만료되면 lock znode는 자동으로 삭제 됩니다.
    • Zookeeper-based election
      • local NameNode가 healthy하고 ZKFC가 다른 노드가 현재 lock znode를 보유하지 않는다고 확인하면, 자신이 lock을 획득하려고 시도 합니다. 성공하면 won the election하게 되면, local NameNode를 Active 상태로 만드는 failover를 실행할 책임이 있습니다. 이전 Active를 필요에 따라 fencing한 후 local NameNode를 Active상태로 전환합니다.