하둡(Hadoop) 완전 정복 - 신입 엔지니어의 질문 모음

도람·2026년 6월 23일

신입 성장기

목록 보기
7/9
post-thumbnail

이 글은 여러 포스팅에 뿔뿔이 흩어져 있던 하둡 관련 개념들을 한 곳에 모아 정리하기 위해 작성하였다. 하둡을 배우면서 생겼던 의문들과 그에 대한 해답들을 함께 담았다.

하둡(Hadoop) 완전 정복 - 신입 엔지니어의 질문 모음

하둡(Hadoop)이란?

하둡(Hadoop)이란 대용량 데이터를 여러 서버에 나눠서 저장하고 처리하는 오픈소스 분산 처리 프레임워크이다.

여기서 오픈소스란 단순히 무료라는 의미가 아니라, 소스코드가 공개되어 있어 우리 환경에 맞게 커스터마이징이 가능하다는 의미이다. 실제로 오픈소스이지만 유료인 경우도 있다. (ex. Red Hat Linux)


하둡은 크게 세 가지 구성요소로 이루어져 있다.

하둡 (Hadoop)
    ├── HDFS (파일 시스템 - 저장 담당)
    ├── MapReduce (데이터 처리 담당)
    └── YARN (자원 관리 담당)

하둡 = 건물 전체, HDFS = 건물 안에 있는 창고


HDFS(Hadoop Distributed File System)란?

HDFS란 하둡 안에서 파일 저장을 담당하는 분산 파일 시스템이다. 대용량 데이터를 여러 서버에 나눠서 저장하는 방식이다.


데이터가 들어오면 HDFS가 자동으로 블록 단위로 나눠서 저장한다.

HDFS 핵심 특징

  • 데이터를 블록 단위(기본 128MB)로 쪼개서 여러 DataNode에 분산 저장한다.
  • 블록을 3개씩 복제하여 저장하기 때문에, 서버 하나가 죽어도 데이터가 유실되지 않는다.
  • 한 번 쓰면 수정이 어려운 구조로, 읽기에 최적화되어 있다.

HDFS 구조 - NameNode와 DataNode

역할설명
NameNode데이터가 어디 저장되어 있는지 관리하는 주체 (메타데이터 담당)
DataNode실제 데이터를 저장하는 서버들

NameNode는 전체 파일 시스템의 메타데이터를 관리한다. 어떤 파일이 어느 DataNode에 저장되어 있는지 알고 있는 관리자 역할이다. NameNode가 죽으면 전체 시스템이 위험해진다는 단점이 있다.


DataNode는 실제 데이터 블록을 저장하는 서버들이다. DataNode에는 디스크가 여러 개 꽂혀있고, 각 디스크를 마운트하여 그 위에 블록을 저장한다.

DataNode 서버
    하드디스크 1 → /data/disk1 마운트 → 블록 1, 블록 2 저장
    하드디스크 2 → /data/disk2 마운트 → 블록 3, 블록 4 저장

DataNode 마운트란?

마운트란 저장 장치(디스크)를 특정 디렉토리에 연결해서 사용할 수 있게 하는 것이다. 리눅스에서는 디스크를 꽂아도 자동으로 인식되지 않고, 직접 명령어로 연결해줘야 한다.

마운트 = 책장 칸(디스크)을 연결하는 것

블록 = 책장에 꽂힌 책들


DataNode에 마운트가 올라간다는 건?

DataNode에 연결된 디스크 개수가 늘어난다는 뜻이다. 저장 공간 자체가 늘어나는 것으로, 디스크를 추가 구매해야 하므로 비용이 증가한다.


DataNode에 블록 카운트가 올라간다는 건?

DataNode에 저장된 블록 개수가 늘어난다는 뜻이다. 데이터가 쌓일수록 블록이 생기고 그 개수가 늘어나는 것으로, 저장 공간이 줄어든다.

의미영향
마운트 증가디스크 연결 늘어남비용 증가
블록 카운트 증가데이터 쌓임저장공간 감소

RAID와 비교

RAIDHDFS
범위디스크 여러 개서버 여러 대
목적스토리지 안전성 확보대용량 분산 저장 및 처리

HDFS에서 데이터를 가져올 때

HDFS에서 데이터를 가져올 때도 여러 서버에서 동시에 가져온다. 이를 병렬 처리 또는 분산 처리라고 한다.

파일 요청
    ↓
NameNode한테 "이 파일 어디 있어?" 물어봄
    ↓
NameNode가 "서버1, 서버2, 서버3에 있어" 알려줌
    ↓
서버1, 서버2, 서버3에서 동시에 블록 가져옴
    ↓
합쳐서 원본 파일 복원

MapReduce란?

MapReduce란 HDFS에 저장된 대용량 데이터를 꺼내서 분석/처리하는 방식이다.

HDFS = 창고 (저장만 함)

MapReduce = 창고에서 꺼내서 가공하는 공장


Map 단계

데이터를 이동시키지 않고 있는 곳에서 바로 처리하는 단계이다.

전체 데이터 (1억 줄)
    ↓
서버 1 → 자기 데이터에서 처리
서버 2 → 자기 데이터에서 처리
서버 3 → 자기 데이터에서 처리

한 곳에 모아서 처리하면 데이터 이동에만 시간이 엄청 걸리기 때문에, 있는 곳에서 바로 처리하는 것이다.


Reduce 단계

각 서버에서 처리한 결과를 합쳐서 최종 결과를 만드는 단계이다.

서버 1 결과: "에러 로그" 300개 ─┐
서버 2 결과: "에러 로그" 500개 ─┼──→ 합산 → 최종 결과: 1000개
서버 3 결과: "에러 로그" 200개 ─┘

한 줄 요약

Map = 데이터 있는 곳에서 바로 처리 (이동 최소화)

Reduce = 각자 처리한 결과 합쳐서 최종 답 도출


YARN이란?

YARN(Yet Another Resource Negotiator)이란 하둡에서 자원(CPU, 메모리)을 나눠주는 관리자이다.

하둡 클러스터에 서버가 여러 대 있고 작업도 여러 개 들어오면, YARN이 어떤 서버에서 어떤 작업을 처리할지 배분해준다.

서버들 = 직원들

작업들 = 해야 할 업무

YARN = 팀장 (누구한테 어떤 업무 줄지 결정)


스케줄링이란?

작업을 언제 어디서 처리할지 순서를 정해주는 것이다. 작업이 동시에 100개 들어오면 YARN이 각 서버에 배분하는 역할을 한다.


전체 흐름 정리

데이터 들어옴
    ↓
HDFS가 자동으로 분산 저장
    ↓
사용자가 분석 요청
    ↓
YARN이 자원 배분
    ↓
MapReduce가 처리 후 결과 반환

HAR (Hadoop Archive)란?

HAR이란 하둡에서 작은 파일 여러 개를 하나로 묶는 것이다.


왜 필요하냐?

HDFS는 큰 파일에 최적화되어 있다. 작은 파일이 엄청 많으면 NameNode가 파일 하나하나의 메타데이터를 다 관리해야 하므로 NameNode 메모리 부담이 커지고 성능이 저하된다.

작은 파일 1000개 → NameNode가 1000개 메타데이터 관리 → 부하 큼
        ↓ HAR로 묶기
.har 파일 1개 → NameNode가 몇 개만 관리 → 부하 감소

HAR의 효과

NameNode 관점

  • 블록 카운터 감소 → NameNode 메모리 부하 감소 ✅

DataNode 관점

  • 블록 수는 줄어들지만 실제 디스크 용량은 그대로 ❌
  • HAR은 DataNode 디스크 용량 확보와는 관계없음

HAR 단점

  • 묶인 파일 안에서 특정 파일 찾으려면 인덱스 탐색 필요
  • 파일 하나 수정하려면 전체 다시 풀고 다시 묶어야 함
  • MapReduce 처리 속도 느려질 수 있음
  • 자주 접근하는 데이터에 사용하면 오히려 성능 저하

자주 안 쓰는 콜드 데이터에 사용하는 것이 적합하다.


HAR 명령어

# HAR 파일 만들기
hadoop archive -archiveName 이름.har -p /입력경로 /출력경로

# HAR 파일 내용 보기
hadoop fs -ls har:///출력경로/이름.har

crontab으로 HAR 자동화

HAR 작업을 매번 수동으로 하기 번거롭기 때문에 crontab으로 자동화할 수 있다.

# 매일 새벽 2시에 자동으로 HAR 생성
0 2 * * * hadoop archive -archiveName logs_$(date +%Y%m%d).har -p /logs/input /logs/archive

crontab = 알람 설정

makehar = 알람 울리면 할 일

수동으로 실행할 수도 있고, crontab으로 자동화해서 운영할 수도 있다.


DataNode 디스크 용량 확보 방법

HAR은 NameNode 부하를 줄이는 용도이지 DataNode 디스크 용량 확보와는 관계없다. DataNode 디스크 용량을 확보하려면 별도의 방법이 필요하다.

  • 디스크 추가 마운트 (비용 증가)
  • 오래된 데이터 다른 곳으로 이관 (콜드 스토리지)
  • 오래된 데이터 삭제
  • 압축해서 저장

실무에서는 보통 핫 데이터는 HDFS에 그대로 두고, 콜드 데이터는 S3 같은 저렴한 스토리지로 이관하는 방식으로 계층화하여 관리한다.


JuiceFS란?

JuiceFS란 HDFS와 동일한 역할을 하지만 저장소를 클라우드(S3 등 오브젝트 스토리지)로 바꾼 분산 파일 시스템이다.

JuiceFS = HDFS의 클라우드 버전


HDFS vs JuiceFS 구조 비교

HDFS
    ├── 메타데이터 → NameNode (전용 서버)
    └── 실제 데이터 → DataNode (전용 서버)

JuiceFS
    ├── 메타데이터 → Redis / MySQL (DB)
    └── 실제 데이터 → S3 (클라우드 스토리지)
HDFSJuiceFS
메타데이터NameNode 전용 서버Redis, MySQL 등 범용 DB
실제 데이터DataNode 전용 서버S3 같은 클라우드 스토리지
배포 환경온프레미스 (데이터센터)클라우드
확장성서버 직접 추가해야 함클라우드라 탄력적으로 확장 가능

S3랑 JuiceFS의 관계

S3는 데이터를 저장하는 스토리지이지만, 파일 시스템이 아니라서 HDFS처럼 쓰기가 불편하다. JuiceFS가 S3 위에 올라타서 S3를 HDFS처럼 사용할 수 있게 만들어주는 역할을 한다.

S3 = 그냥 하드디스크

JuiceFS = 그 하드디스크를 파일 시스템으로 만들어주는 것


HDFS가 클라우드에서 불리한 이유

HDFS는 블록을 3개씩 복제하는 설계 때문에 클라우드 디스크에 배포하면 온프레미스 대비 약 3배의 비용이 발생한다. 반면 JuiceFS는 S3를 기반으로 하여 탄력적으로 확장 가능하고 비용도 절감된다.


마무리

하둡은 단순한 저장 시스템이 아니라 HDFS, MapReduce, YARN이 유기적으로 연결된 분산 처리 생태계이다. 처음에는 복잡해 보이지만 각 구성요소의 역할을 이해하면 전체 흐름이 보이기 시작한다. JuiceFS처럼 하둡 생태계를 클라우드 환경에 맞게 발전시킨 기술들도 함께 알아두면 실무에서 큰 도움이 된다.

profile
정도를 걷는 엔지니어

0개의 댓글