하둡 생태계 (Hadoop Ecosystem)

목차

왜 하둡 생태계를 묻는가

하둡 생태계는 요즘 신규 시스템의 기본 선택지라기보다,
분산 저장과 분산 처리라는 문제가 왜 따로 등장했는지 설명하는 배경으로 자주 나옵니다.

면접에서 이 주제를 묻는 이유는 보통 다음과 같습니다.

  • 분산 저장 감각: 큰 파일을 여러 노드에 나눠 저장하는 모델을 이해하는가
  • 분산 실행 감각: 계산을 데이터가 있는 쪽으로 가져가는 발상을 설명할 수 있는가
  • 생태계 감각: 저장, 실행, SQL, NoSQL이 왜 분리됐는지 구분할 수 있는가
  • 현대화 감각: Hadoop 이후 Spark, object storage, lakehouse로 어떻게 이어졌는지 설명할 수 있는가

이 문서는 하둡을 제품 하나로 보기보다,
대규모 데이터 처리를 위한 저장·실행·질의 생태계로 설명하는 데 초점을 둡니다.

하둡 생태계를 한 문장으로 요약하면

하둡 생태계는 다음 질문에 대한 조합으로 볼 수 있습니다.

  1. 큰 데이터를 어디에 저장할 것인가
  2. 그 데이터를 여러 노드에서 어떻게 계산할 것인가
  3. SQL이나 조회 시스템으로 어떻게 접근할 것인가

대표 구성은 다음과 같습니다.

구성 요소 역할 면접에서의 한 줄 설명
HDFS 분산 파일 저장 큰 파일을 여러 노드에 나눠 저장하는 계층
YARN 자원 관리와 실행 조정 여러 작업이 클러스터 자원을 나눠 쓰게 하는 계층
MapReduce 전통적 분산 배치 처리 모델 데이터 가까이에서 병렬 계산하는 초기 표준
Hive SQL 기반 분석 계층 하둡 위에서 SQL로 대용량 데이터를 다루게 만든 도구
HBase wide-column NoSQL 저장소 대용량 sparse 데이터에 대한 랜덤 읽기/쓰기 저장소

즉, 하둡은 단순 저장소가 아니라
파일 시스템, 자원 관리, 분산 처리, SQL, NoSQL이 묶인 플랫폼으로 이해하는 편이 맞습니다.1

HDFS란

HDFS(Hadoop Distributed File System) 는 큰 파일을 여러 노드에 블록 단위로 나눠 저장하는 분산 파일 시스템입니다.23

면접에서는 다음 감각을 잡고 설명하면 충분합니다.

  • 대용량 파일 중심: 작은 파일을 엄청 많이 다루는 용도보다 큰 파일을 순차 처리하는 데 더 맞습니다.
  • 블록 저장: 파일을 블록으로 나누고 여러 노드에 분산 저장합니다.
  • 복제 기반 내구성: 블록 복제로 장애에 대비합니다.
  • 메타데이터와 데이터 분리: 메타데이터는 NameNode, 실제 블록은 DataNode가 담당합니다.

HDFS를 설명할 때 흔히 나오는 포인트는 다음과 같습니다.

  • 장점: commodity hardware 기반으로 큰 데이터를 저장하고 확장하기 좋습니다.
  • 장점: 데이터 지역성(data locality)을 활용해 계산을 데이터 근처로 보낼 수 있습니다.
  • 단점: 작은 파일이 너무 많으면 메타데이터 부담이 커집니다.
  • 단점: POSIX 파일 시스템처럼 자유로운 임의 수정 워크로드와는 결이 다릅니다.

좋은 답변은 “분산 파일 시스템입니다”에서 멈추지 않고,
읽기 위주의 대용량 순차 처리에 최적화된 저장 계층이라고 연결하는 편이 좋습니다.

YARN과 실행 계층

YARN(Yet Another Resource Negotiator) 는 하둡 클러스터에서 여러 작업이 CPU, 메모리 같은 자원을 나눠 쓰게 하는 자원 관리 계층입니다.1

하둡을 저장과 실행으로 나누면 다음처럼 볼 수 있습니다.

  • HDFS: 데이터를 저장
  • YARN: 어떤 작업이 어느 자원을 얼마나 쓸지 조정

이 구분이 중요한 이유는 클러스터 안에서 여러 종류의 작업이 함께 돌 수 있기 때문입니다.

  • 배치 작업
  • SQL 질의
  • ETL 파이프라인
  • 머신러닝 전처리

YARN을 설명할 때는 “분산 처리 엔진”이라기보다
여러 엔진이 공용 클러스터 자원을 공유하게 만드는 계층이라고 말하는 편이 더 정확합니다.

MapReduce의 의미와 한계

MapReduce 는 대규모 데이터를 여러 노드에서 병렬 처리하는 고전적인 프로그래밍 모델입니다.1

핵심 아이디어는 단순합니다.

  1. 입력 데이터를 나눈다
  2. 각 조각에서 map 작업을 수행한다
  3. key 기준으로 shuffle 한다
  4. reduce 작업으로 집계한다

MapReduce를 지금도 알아야 하는 이유는,
현대 엔진을 이해할 때도 아래 개념이 계속 남아 있기 때문입니다.

  • 분산 입력 분할
  • shuffle 비용
  • 데이터 지역성
  • 배치 중심 사고방식

다만 한계도 분명합니다.

  • 단점: 반복 계산과 대화형 질의에는 비효율적일 수 있습니다.
  • 단점: 디스크 중심 중간 결과 처리로 지연이 커질 수 있습니다.
  • 단점: 프로그래밍 모델이 단순한 대신 표현력이 제한될 수 있습니다.

그래서 실무에서는 MapReduce 자체보다,
그 한계를 보완하는 Spark 같은 엔진으로 넘어간 흐름까지 설명하면 답변이 더 자연스럽습니다.

Hive는 어디에 맞는가

Hive 는 하둡 위에서 SQL로 대규모 데이터를 읽고 관리하게 만든 데이터 웨어하우스 계층입니다.45

면접에서 Hive를 설명할 때는 다음 정도가 핵심입니다.

  • SQL 인터페이스: 분석가나 데이터 엔지니어가 SQL로 접근하기 쉽습니다.
  • 메타데이터 관리: 테이블, 파티션, 스키마 정보를 중앙에서 관리합니다.
  • 배치/분석 워크로드: OLTP보다는 대규모 분석 질의에 맞습니다.

Hive를 RDBMS와 같은 감각으로 설명하면 어색해집니다.

  • RDBMS: 낮은 지연의 트랜잭션 처리
  • Hive: 대규모 데이터셋에 대한 분석 질의

즉, Hive는
하둡 위에서 SQL 기반 분석을 가능하게 한 계층으로 이해하는 편이 좋습니다.

분석 시스템의 큰 그림은 OLTP와 OLAP (OLTP vs OLAP) 문서와 같이 보면 연결이 좋습니다.

HBase는 어떤 역할인가

HBase 는 하둡 생태계 안에서 자주 함께 언급되는 wide-column NoSQL 저장소입니다.6

이 문서에서는 HBase를 제품 심화보다
“하둡 생태계 안의 랜덤 접근형 저장소” 라는 관점으로 설명합니다.

다음처럼 비교하면 이해가 쉽습니다.

항목 HDFS / Hive HBase
주 모델 파일 기반 배치 분석 key 기반 랜덤 읽기/쓰기
강한 지점 큰 파일, 스캔, 집계 sparse 데이터, 빠른 lookup
적합한 경우 배치 분석, SQL 집계 시계열 일부 조회, 프로필/피처 저장
약한 지점 낮은 지연 lookup ad hoc 분석 질의와 복잡한 join

HBase를 설명할 때 중요한 포인트는 다음입니다.

  • 장점: 대규모 sparse 데이터에 대한 key 기반 접근에 맞습니다.
  • 장점: 하둡 생태계와 가까워 배치/분석 흐름과 연결하기 좋습니다.
  • 단점: 전통적인 RDBMS처럼 join 중심 질의에 맞지는 않습니다.
  • 단점: 운영 난이도와 데이터 모델 설계가 쉽지 않습니다.

즉, HBase는 “하둡용 MySQL”이 아니라
배치 파일 처리와 별개로 낮은 지연 key 접근이 필요할 때 쓰는 wide-column 계열 저장소라고 설명하는 편이 안전합니다.

오늘날에는 어떻게 설명하면 좋은가

요즘 면접에서는 “지금도 Hadoop을 그대로 쓰는가”라는 질문이 따라올 수 있습니다.

이때는 너무 단정적으로 말하기보다 다음 흐름으로 설명하면 좋습니다.

  • 저장 계층: HDFS 대신 S3 같은 object storage를 쓰는 경우가 많아졌습니다.
  • 실행 계층: MapReduce보다 Spark나 Flink가 더 자주 언급됩니다.
  • 분석 계층: Hive 메타스토어, lakehouse 테이블 포맷, SQL 엔진으로 진화했습니다.

하지만 하둡 생태계의 핵심 개념은 여전히 남아 있습니다.

  • 큰 데이터를 분산 저장한다
  • 계산을 수평 확장한다
  • 배치와 분석을 분리한다
  • SQL과 저장 포맷을 메타데이터로 관리한다

즉, 오늘날 면접에서는
하둡 자체의 최신 유행보다 현대 데이터 플랫폼의 출발점으로 설명하는 편이 더 좋습니다.

스트림 중심 처리 엔진 비교는 스트림 처리 (Stream Processing) 문서와 같이 보면 좋습니다.

트레이드오프

선택 장점 주의점
HDFS 중심 저장 큰 파일과 순차 처리에 강함 작은 파일과 낮은 지연 접근에는 불리할 수 있음
Hive 같은 SQL 계층 SQL 기반 분석 접근성이 좋음 트랜잭션 시스템처럼 설명하면 어색함
HBase 도입 key 기반 랜덤 접근에 유리 운영 복잡도와 데이터 모델 설계 부담이 큼
공용 클러스터 자원 공유 자원 활용률을 높이기 좋음 멀티테넌시 운영과 자원 경합 관리가 필요

좋은 답변은 “하둡이 좋다/옛날 기술이다”가 아니라,
어떤 데이터 패턴과 운영 조건에서 어떤 계층이 필요한지 구분하는 것입니다.

면접 포인트

  • 하둡은 단일 제품보다 저장, 실행, SQL, NoSQL이 묶인 생태계로 설명하는 편이 좋습니다.
  • HDFS는 대규모 순차 처리용 분산 파일 시스템으로 설명하는 것이 핵심입니다.
  • YARN은 저장소가 아니라 클러스터 자원 관리 계층입니다.
  • MapReduce는 고전적 모델이지만, shuffle과 배치 처리 감각을 설명할 때 여전히 유효합니다.
  • Hive는 SQL 기반 분석 계층, HBase는 key 기반 랜덤 접근 저장소로 구분하면 답변이 정리됩니다.
  • 요즘은 object storage, Spark, lakehouse로 이어지는 진화 흐름까지 말하면 더 자연스럽습니다.

참고 자료

  1. Apache Hadoop Docs ↩ ↩2 ↩3

  2. Apache Hadoop Docs, “HDFS Users Guide” ↩

  3. Apache Hadoop Docs, “HDFS Architecture Guide” ↩

  4. Apache Hive ↩

  5. Apache Hive Docs, “Introduction to Apache Hive” ↩

  6. Apache HBase Reference Guide ↩