Hadoop Architecture

HDFS 동작과정 정리

graph LR

subgraph U[User]
    ap[Application]
end

subgraph hd[ HADOOP ]
    subgraph hc[HDFS Client]
    end

    subgraph "NODES"
        direction LR
        subgraph NameNode
            direction LR    
            md([MetaData])
        end

        subgraph Secondary-NameNode
        end

        subgraph DataNode
            direction LR
            dn1([DataNode 1]) 
            dn2([DataNode 2]) 
            dn3([DataNode 3])
        end
    end
end

%% 쓰기 과정
ap -- "[1]" --> hc
hc -- "[2]" --> NameNode
NameNode -- "[3]" --> Secondary-NameNode
NameNode -- "[4:저장]" --> DataNode
DataNode -- "[4:상태정보 리턴]" --> NameNode
dn1 -- "[4]" --- dn2
dn2 -- "[4]" --- dn3

%% 읽기 과정
NameNode -- "[5]" --> hc
DataNode -- "[6]" --> hc
NameNode -- "[7]" --> Secondary-NameNode

%% Style
linkStyle 0,1,2,3,4,5,6 stroke-width:4px, stroke:white;
linkStyle 7,8,9 stroke-width:5px, stroke:black;

%% for layout
%% classDef invisible width:0px
%%  class dot1,dot2 invisible

[ HDFS 쓰기 ]

• step 1. 사용자가 데이터를 HDFS에 저장
• step 2. HDFS 클라이언트는 데이터의 메타데이터를 NameNode 에 저장
  • 메타데이터의 종류 :
• step 3. NameNode 메타데이터에 변경이 생기면 모든 로그를 세컨더리 NameNode Edits 파일에 저장
• step 4. 데이터는 여러개 블록으로 나누어져 DataNode 에 복제 저장
• step 4. DataNode 는 자신의 상태정보를 NameNode 에 송신

[ HDFS 읽기 ]

• step 5. HDFS 클라이언트가 NameNode 로부터 파일 블록에 대한 메타정보를 읽어온다.
• step 6. 메타정보를 이용하여 DataNode 로부터 파일을 읽어온다.
• step 7. NameNode 메타데이터에 변경이 생기면 모든 로그를 세컨더리 NameNode Edits 파일에 저장

YARN 동작과정 정리

%% graph
graph LR
    subgraph How YARN Works
    direction TB
        subgraph hc[Hadoop Client]
        end

        subgraph ResourceManager
        direction TB
            sd[Scheduler]
            am[Application Manager]
        end

        subgraph NODES
            subgraph Node1
                nm1[NodeManager]
                ct1[Container]
            end
            subgraph Node2
                nm2[NodeManager]
                ams[Application Master]
                ct2[Container]
            end
            subgraph Node3
                nm3[NodeManager]
                ct3[Container]
                ct4[Container]
            end
        end

    end

%% flow
hc -- "[ step 1 ]" --> ResourceManager
nm2 -. "[ step 2-0 ]" ..-> sd
sd -- "[ step 2-1 ]" --> am
am -- "[ step 2-2 ]" ---> ams
sd -- "[ step 3 ]" ---> ams
ams <-- "[ step 4 ]" --> nm1
ams <-- "[ step 4 ]" --> nm2
ams <-- "[ step 4 ]" --> nm3
nm1 <-- "[ step 5 ]" --> ct1
nm2 <-- "[ step 5 ]" --> ct2
nm3 <-- "[ step 5 ]" --> ct3
nm3 <-- "[ step 5 ]" --> ct4

Node1 -- "[ step 6 ]" --> ResourceManager
Node2 -- "[ step 6 ]" --> ResourceManager
Node3 -- "[ step 6 ]" --> ResourceManager

%% Style

%% linkStyle 0,1,2,3,4,5,6 stroke-width:4px, stroke:white;
%% linkStyle 7,8,9 stroke-width:5px, stroke:black;

%% for layout
%% classDef invisible width:0px
%%  class dot1,dot2 invisible

• step 1. 클라이언트가 Application 을 제출하면 Resource Manager 가 이를 담당한다.
• step 2. Resource Manager 내의 Application Manager는 Scheduler 로부터 Application Master를 실행시킬 NodeManager 를 할당받아 Application Master를 실행한다.
• step 3. Application Master 는 Scheduler 에게 필요한 자원을 할당 및 승인받는다.
• step 4. Application Master 는 NodeManager 들에게 필요한 Container 를 요청한다.
• step 5. NodeManager 는 필요한 Container 들을 만들고, Container 들은 진행상황을 Application Master 에 전달한다.
• step 6. NodeManager 들은 Node 상태를 Resource Manager 에게 전달한다.

하둡의 이점?

• 스케일 아웃 분산 시스템 : 성능 확장 시, 스케일 아웃 방식을 사용하여 구축 비용이 저렴하다
• 장애 복구 : 분산 서버 클러스터에서 노드가 오류를 일으켜도 저장된 데이터가 유실되거나 서비스가 중지되지 않는다.
• 대용량 데이터 : 한번 저장된 데이터는 수정이 불가하며, 장애를 자동으로 복구하여 데이터 무결성을 유지한다.

하둡 파일시스템 API