Hadoop 아키텍처 다시 보기 — HDFS, YARN, 그리고 그 이후

┌──────────────────────────────────────────────────────────────┐
│                 Hadoop 핵심 설계 목표                          │
├──────────────────────────────────────────────────────────────┤
│ 1. 확장성(Scalability)                                         │
│    수평 확장 — 노드를 추가해서 용량/처리량을 늘린다.            │
│                                                                │
│ 2. 내결함성(Fault Tolerance)                                   │
│    장애는 정상 — 복제와 재시도로 데이터/작업을 보호한다.       │
│                                                                │
│ 3. 데이터 지역성(Data Locality)                                │
│    연산을 데이터 가까이로 — 네트워크 전송 최소화.              │
│                                                                │
│ 4. 범용 하드웨어(Commodity Hardware)                           │
│    값싼 서버 다수 — 비싼 단일 장비에 의존하지 않는다.          │
│                                                                │
│ 5. 처리량 우선(High Throughput, not Low Latency)               │
│    대용량 배치 처리에 최적 — 실시간 응답이 목표가 아니다.      │
└──────────────────────────────────────────────────────────────┘

┌───────────────────────────────────────────────────────────────┐
│   처리 계층 (Processing)                                       │
│   MapReduce · Spark · Tez · Hive · Pig · Flink ...            │
├───────────────────────────────────────────────────────────────┤
│   리소스 관리 계층 (Resource Management)                      │
│   YARN — ResourceManager / NodeManager / ApplicationMaster   │
├───────────────────────────────────────────────────────────────┤
│   스토리지 계층 (Storage)                                     │
│   HDFS — NameNode / DataNode / Block / Replication           │
└───────────────────────────────────────────────────────────────┘

파일: bigfile.log (380 MB), 블록 크기 128 MB

   bigfile.log
   ┌──────────────┬──────────────┬──────────────┐
   │  Block A     │  Block B     │  Block C     │
   │  128 MB      │  128 MB      │  124 MB      │
   └──────────────┴──────────────┴──────────────┘

각 블록은 복제 계수(replication factor, 기본 3)만큼 여러 DataNode에 복제됩니다.

   Block A ──▶ DataNode 1, DataNode 3, DataNode 5
   Block B ──▶ DataNode 2, DataNode 3, DataNode 6
   Block C ──▶ DataNode 1, DataNode 4, DataNode 6

┌─────────────────────────────────────────────────────────────┐
│                        NameNode (마스터)                     │
│  - 파일 시스템 네임스페이스(디렉터리/파일 트리) 관리         │
│  - 각 파일이 어떤 블록들로 이루어졌는지 기록                  │
│  - 각 블록이 어느 DataNode에 있는지 매핑 보관                 │
│  - 메타데이터는 메모리에 상주 (빠른 조회를 위해)             │
└─────────────────────────────────────────────────────────────┘
        │            │            │            │
        ▼            ▼            ▼            ▼
   ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐
   │DataNode1│  │DataNode2│  │DataNode3│  │DataNode4│   (슬레이브)
   │ 블록 저장│  │ 블록 저장│  │ 블록 저장│  │ 블록 저장│
   └─────────┘  └─────────┘  └─────────┘  └─────────┘
   - 실제 블록 데이터를 로컬 디스크에 저장
   - 주기적으로 NameNode에 하트비트와 블록 리포트 전송

┌──────────────── NameNode 메타데이터 영속화 ────────────────┐
│                                                             │
│   FsImage   : 특정 시점의 파일 시스템 전체 스냅샷           │
│   EditLog   : FsImage 이후 발생한 모든 변경 사항의 로그     │
│                                                             │
│   재시작 시 복구 절차:                                      │
│     1) FsImage 로드 (기준 스냅샷)                           │
│     2) EditLog 재생(replay) (그 이후 변경 반영)             │
│     3) 메모리 상의 최신 메타데이터 완성                     │
│                                                             │
└─────────────────────────────────────────────────────────────┘

        ┌──────────────┐   공유 EditLog    ┌──────────────┐
        │   Active     │◀────────────────▶│   Standby    │
        │   NameNode   │  (JournalNodes)   │   NameNode   │
        └──────┬───────┘                   └──────┬───────┘
               │                                  │
               │   DataNode들은 두 NameNode 모두에게  │
               │   하트비트와 블록 리포트를 전송      │
               ▼                                  ▼
        ┌───────────────────────────────────────────────┐
        │   DataNode 1 · DataNode 2 · DataNode 3 · ...   │
        └───────────────────────────────────────────────┘

   Active가 죽으면 → ZKFC + ZooKeeper가 감지 → Standby가 Active로 승격

[HDFS 쓰기 경로]

  Client
    │ 1. create() 요청 — "이 경로에 파일 만들래"
    ▼
  NameNode
    │   - 권한/존재 여부 확인, 네임스페이스에 파일 항목 생성
    │ 2. 첫 블록을 둘 DataNode 목록 반환 (복제 3 → 3개)
    │      예: DN1 ──▶ DN2 ──▶ DN3 (파이프라인)
    ▼
  Client
    │ 3. 데이터를 패킷 단위로 DN1에 전송
    ▼
  ┌─────────┐   복제 파이프라인   ┌─────────┐        ┌─────────┐
  │  DN1    │ ─── 패킷 전달 ───▶ │  DN2    │ ──────▶ │  DN3    │
  │ 디스크↓ │                    │ 디스크↓ │        │ 디스크↓ │
  └─────────┘                    └─────────┘        └─────────┘
    │                                                    │
    │ 4. ack는 역방향으로:  DN3 ──▶ DN2 ──▶ DN1 ──▶ Client │
    ▼                                                    
  Client
    │ 5. 블록이 다 차면 다음 블록 위해 2~4 반복
    │ 6. close() — NameNode에 쓰기 완료 통보
    ▼
  NameNode (메타데이터 최종 확정)

[기본 복제본 배치 (replication = 3, 랙 인식 기준)]

  복제본 1 : 클라이언트가 있는 노드(또는 같은 랙의 임의 노드)
  복제본 2 : 복제본 1과 다른 랙의 노드
  복제본 3 : 복제본 2와 같은 랙의 다른 노드

  목적:
   - 같은 랙에 2개 → 랙 내부 네트워크로 빠른 쓰기
   - 다른 랙에 1개 → 랙 전체 장애 시에도 데이터 보존

[HDFS 읽기 경로]

  Client
    │ 1. open() — "이 파일 읽을래"
    ▼
  NameNode
    │ 2. 파일의 블록 목록 + 각 블록의 DataNode 위치 반환
    │    (클라이언트와 가까운 순서로 정렬해서 줌)
    ▼
  Client
    │ 3. 각 블록마다 가장 가까운 DataNode에서 직접 읽기
    ▼
  ┌─────────┐  ┌─────────┐  ┌─────────┐
  │  DN (A) │  │  DN (B) │  │  DN (C) │   ← 블록별로 가까운 노드 선택
  └─────────┘  └─────────┘  └─────────┘
    │
    │ 4. 만약 어떤 DataNode가 응답 없으면
    │    → 다른 복제본을 가진 DataNode로 재시도
    ▼
  Client (블록들을 이어 붙여 완전한 파일로)

┌──────────────────────────────────────────────────────────────┐
│                  ResourceManager (RM, 마스터)                │
│   - Scheduler: 클러스터 자원을 애플리케이션에 할당           │
│   - ApplicationsManager: AM 시작/재시작 관리                 │
└───────────────┬──────────────────────────────────────────────┘
                │ 자원 할당 / 상태 보고
   ┌────────────┼────────────────────────┬───────────────┐
   ▼            ▼                        ▼               ▼
┌────────┐  ┌────────┐              ┌────────┐      ┌────────┐
│ Node-  │  │ Node-  │              │ Node-  │      │ Node-  │
│Manager │  │Manager │   ...        │Manager │      │Manager │
│ (NM)   │  │ (NM)   │              │ (NM)   │      │ (NM)   │
└───┬────┘  └───┬────┘              └───┬────┘      └───┬────┘
    │           │                       │               │
  컨테이너    컨테이너                컨테이너         컨테이너
 ┌──────┐   ┌──────┐               ┌──────┐        ┌──────┐
 │ App  │   │ Task │               │ Task │        │ Task │
 │Master│   │      │               │      │        │      │
 └──────┘   └──────┘               └──────┘        └──────┘

[YARN 잡 제출 및 실행 시퀀스]

  Client                RM              NM(여러 노드)        AM
    │                    │                   │               │
    │ 1. submitApplication                   │               │
    │───────────────────▶│                   │               │
    │                    │ 2. AM 컨테이너 할당 요청           │
    │                    │──────────────────▶│               │
    │                    │                   │ 3. AM 컨테이너 │
    │                    │                   │    시작        │
    │                    │                   │──────────────▶│
    │                    │ 4. AM 등록(register)               │
    │                    │◀──────────────────────────────────│
    │                    │ 5. 태스크용 컨테이너 요청          │
    │                    │◀──────────────────────────────────│
    │                    │ 6. 컨테이너 할당 응답              │
    │                    │──────────────────────────────────▶│
    │                    │                   │ 7. AM이 NM에   │
    │                    │                   │   태스크 실행  │
    │                    │                   │   지시         │
    │                    │                   │◀──────────────│
    │                    │                   │ 8. 태스크 실행 │
    │                    │                   │   (컨테이너 안)│
    │ 9. 진행 상황 조회   │                   │               │
    │◀───────────────────┼───────────────────┼───────────────│
    │                    │ 10. 완료 후 AM 등록 해제, 자원 반납 │
    │                    │◀──────────────────────────────────│
    ▼                    ▼                   ▼               ▼

// Mapper: 한 줄을 받아 각 단어에 대해 (word, 1) 방출
public class WordCountMapper
    extends Mapper<LongWritable, Text, Text, IntWritable> {

  private final static IntWritable ONE = new IntWritable(1);
  private final Text word = new Text();

  @Override
  protected void map(LongWritable key, Text value, Context context)
      throws IOException, InterruptedException {
    String line = value.toString();
    for (String token : line.split("\\s+")) {
      if (!token.isEmpty()) {
        word.set(token);
        context.write(word, ONE);
      }
    }
  }
}

// Reducer: 같은 단어에 대한 1들을 모두 더함
public class WordCountReducer
    extends Reducer<Text, IntWritable, Text, IntWritable> {

  private final IntWritable result = new IntWritable();

  @Override
  protected void reduce(Text key, Iterable<IntWritable> values, Context context)
      throws IOException, InterruptedException {
    int sum = 0;
    for (IntWritable v : values) {
      sum += v.get();
    }
    result.set(sum);
    context.write(key, result);
  }
}

// Driver: 잡 설정과 제출
public class WordCountDriver {
  public static void main(String[] args) throws Exception {
    Configuration conf = new Configuration();
    Job job = Job.getInstance(conf, "word count");
    job.setJarByClass(WordCountDriver.class);
    job.setMapperClass(WordCountMapper.class);
    job.setReducerClass(WordCountReducer.class);
    job.setCombinerClass(WordCountReducer.class); // 맵 단계 부분 집계
    job.setOutputKeyClass(Text.class);
    job.setOutputValueClass(IntWritable.class);
    FileInputFormat.addInputPath(job, new Path(args[0]));
    FileOutputFormat.setOutputPath(job, new Path(args[1]));
    System.exit(job.waitForCompletion(true) ? 0 : 1);
  }
}

[MapReduce 전체 데이터 흐름 (셔플 포함)]

  입력 (HDFS 블록들)
   ┌────────┐ ┌────────┐ ┌────────┐
   │ Split1 │ │ Split2 │ │ Split3 │
   └───┬────┘ └───┬────┘ └───┬────┘
       ▼          ▼          ▼
   ┌────────┐ ┌────────┐ ┌────────┐
   │ Map 1  │ │ Map 2  │ │ Map 3  │     ← 각 Map이 (키,값) 방출
   └───┬────┘ └───┬────┘ └───┬────┘
       │          │          │
       │  [파티셔닝 + 정렬 + (선택)컴바이너]
       │          │          │
       └────┬─────┴─────┬────┘
            │  S H U F F L E  │           ← 네트워크로 키 기준 재분배
       ┌────┴─────┐ ┌────┴─────┐
       ▼          ▼ ▼          ▼
   ┌────────────────┐ ┌────────────────┐
   │  Reduce 1      │ │  Reduce 2      │  ← 같은 키는 같은 Reducer로
   │ (키 A,B 담당)  │ │ (키 C,D 담당)  │
   └───────┬────────┘ └───────┬────────┘
           ▼                  ▼
       ┌────────┐         ┌────────┐
       │ 출력 1 │         │ 출력 2 │       ← HDFS에 결과 기록
       └────────┘         └────────┘

[Map 측 → Reduce 측 셔플 상세]

  Map 측:
   1. map() 출력이 메모리 버퍼에 쌓임
   2. 버퍼가 차면 디스크로 스필(spill) — 이때 파티션별로 정렬
   3. 여러 스필 파일을 하나로 머지(merge)
   4. (컴바이너 설정 시) 맵 쪽에서 부분 집계해 데이터량 축소

  Reduce 측:
   5. 각 Map으로부터 자기 파티션 데이터를 가져옴(fetch, 네트워크)
   6. 가져온 데이터를 키 기준으로 머지+정렬
   7. reduce() 호출 — 같은 키의 값들을 한 번에 처리

┌──────────────────────────────────────────────────────────────┐
│  SQL / 질의:  Hive, Impala, Presto/Trino                      │
│  스크립트:    Pig                                             │
│  처리 엔진:   MapReduce, Spark, Tez, Flink                    │
│  NoSQL:       HBase (HDFS 위의 분산 키-값/컬럼 스토어)         │
│  수집:        Sqoop(RDB↔HDFS), Flume/Kafka(스트림)            │
│  조정:        ZooKeeper (분산 코디네이션)                     │
│  워크플로:    Oozie, Airflow                                  │
├──────────────────────────────────────────────────────────────┤
│  YARN  (리소스 관리)                                          │
├──────────────────────────────────────────────────────────────┤
│  HDFS  (분산 스토리지)                                        │
└──────────────────────────────────────────────────────────────┘

-- 외부 테이블 정의: HDFS 경로의 데이터를 테이블처럼 다룸
CREATE EXTERNAL TABLE access_log (
  ip        STRING,
  ts        STRING,
  url       STRING,
  status    INT
)
ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE
LOCATION '/data/access_log/';

-- 상태 코드별 집계
SELECT status, COUNT(*) AS cnt
FROM access_log
GROUP BY status
ORDER BY cnt DESC;

[HBase의 위치]

   애플리케이션 (낮은 지연 단건 조회 필요)
        │
        ▼
   ┌──────────┐
   │  HBase   │   ← 랜덤 읽기/쓰기, 행 단위 접근
   └────┬─────┘
        ▼
   ┌──────────┐
   │  HDFS    │   ← 실제 데이터 파일(HFile) 영속 저장
   └──────────┘

[고전적 Hadoop]                  [클라우드/레이크하우스]

 ┌──────────────┐                 컴퓨트(필요할 때만)
 │ 노드 = 스토리지 │                ┌──────┐ ┌──────┐ ┌──────┐
 │      + 컴퓨트   │ (co-location)  │Spark │ │Trino │ │Flink │
 │ HDFS  +  YARN  │                └───┬──┘ └───┬──┘ └───┬──┘
 └──────────────┘                     │        │        │
   데이터 지역성 중심                  └────────┼────────┘
   스토리지·컴퓨트 결합                         ▼
                                       ┌────────────────┐
                                       │ 오브젝트 스토리지 │
                                       │  S3 / GCS / ... │  (분리)
                                       └────────────────┘
                                  스토리지·컴퓨트 독립 확장

[레이크하우스 계층 구조]

 ┌──────────────────────────────────────────────┐
 │  질의/처리: Spark, Trino, Flink, Dremio ...   │
 ├──────────────────────────────────────────────┤
 │  테이블 포맷: Iceberg / Delta / Hudi          │
 │   - ACID 트랜잭션  - 스키마 진화  - 시간 여행 │
 ├──────────────────────────────────────────────┤
 │  파일 포맷: Parquet / ORC (컬럼 지향)         │
 ├──────────────────────────────────────────────┤
 │  스토리지: 오브젝트 스토리지(S3/GCS) 또는 HDFS │
 └──────────────────────────────────────────────┘

[흔한 점검 포인트]

 - 컨테이너 메모리( yarn.scheduler.maximum-allocation-mb )가
   태스크에 충분한가? OutOfMemory로 컨테이너가 킬되지 않는가
 - 맵/리듀스 태스크 수가 적절한가 (너무 적으면 병렬성 부족,
   너무 많으면 스케줄링 오버헤드)
 - 데이터 스큐(skew): 특정 키에 값이 몰려 한 Reducer만 오래 도는가
 - 셔플량이 과도하지 않은가 (컴바이너/파티셔너로 줄일 수 있는지)
 - 큐 설정이 적절한가 (특정 큐가 자원을 독식하는지)