Hadoop과 Hadoop ecosystem 의 기본 개념

1. 왜 이게 필요한가 

하둡(Apache Hadoop)의 등장은 2000년대 초반 인터넷 서비스의 급격한 팽창과 그로 인해 발생한 초거대 규모 데이터 처리의 한계를 극복하기 위한 필연적인 산물입니다.
당시의 데이터 관리 체계는 주로 관계형 데이터베이스 관리 시스템(RDBMS)과 고가의 전용 스토리지 하드웨어인 SAN(Storage Area Network)에 의존하고 있었습니다. 

그런데 문제가 터졌습니다. 웹 로그, 소셜 네트워크 서비스, 전자상거래 트랜잭션 등 비정형 및 반정형 데이터가 기하급수적으로 증가하기 시작했습니다.

기존 방식으로는 이 데이터를 감당할 수 없었고, 그렇다고 서버 한 대의 성능을 높이는 방식인 수직적 확장(Scale-up) 은

비용 대비 효율성이 급격히 저하되는 임계점에 도달하고 말았습니다.

=> 비정형 및 반정형 데이터가 증가함에 따라 비용 임계점 도달 

2. 개념의 본질  

하둡을 한 문장으로 정의하면 이렇습니다.

"값싼 범용 서버 여러 대를 클러스터로 구성하여, 마치 하나의 거대한 컴퓨터처럼 쓸 수 있게 해주는 분산 데이터 처리 플랫폼"

 

 

분산 파일 시스템인 GFS와 대규모 병렬 데이터 처리 프레임워크인 MapReduce의 개념을 차용하여 오픈소스 프로젝트인 하둡을 고안하였습니다.
 하둡의 핵심 설계 철학은 고가의 특수 장비 대신 저렴한 범용 서버(Commodity Hardware)를 클러스터로 구성하여 수평적 확장(Scale-out)을 달성하는 데 있었습니다.

=> 병렬처리 + 맵리듀스 개념을 차용하여, 수평적 확장을 달성

 

- 수평적 확장(Scale-out): 고가의 특수 장비 대신, 저렴한 범용 서버(Commodity Hardware)를 클러스터로 구성
- "하드웨어는 언제나 고장 날 수 있다": 수천 대의 범용 서버로 구성된 클러스터에서 특정 노드의 장애는 예외적인 사건이 아닌 일상적인 현상으로 전제하고 설계

 

이 두 번째 철학에서 나온 개념이 결함 허용성(Fault Tolerance) 입니다.

하둡의 설계 철학은 '하드웨어는 언제나 고장 날 수 있다'는 가정을 전제로 합니다.
수천 대의 범용 서버로 구성된 클러스터에서 특정 노드의 장애는 예외적인 사건이 아닌 일상적인 현상으로 간주됩니다. 
따라서 시스템은 개별 구성 요소의 결함에도 불구하고 전체 서비스의 가용성과 데이터 무결성을 유지해야 하며, 이를 결함 허용성이라 정의합니다.

 

개별 구성 요소의 결함이 생겨도 전체 서비스의 가용성과 데이터 무결성을 유지해야 한다는 설계 원칙입니다.

 

3. 직관적인 비유

하둡을 이해하는 가장 좋은 비유는 "도서관 사서 팀" 입니다.

혼자 일하는 사서(단일 서버) 한 명이 수백만 권의 책을 관리하려면 한계가 있습니다. 하둡은 이걸 이렇게 바꿉니다.

 

- 책(데이터)을 128MB 단위로 잘라서 여러 서가(데이터노드)에 나눠 보관합니다.
- 책이 분실될 것을 대비해 3부씩 복사해서 서로 다른 서가, 심지어 다른 건물(랙)에 배치합니다.
- 관리자 사서(네임노드) 는 "어떤 책의 몇 페이지가 어느 서가에 있는지"만 기억합니다.
- 누가 책을 요청하면, 팀원들이 동시에 각자의 서가를 뒤져서 빠르게 조합해 가져옵니다.

 

그리고 YARN이 등장하면서, 이 도서관에 사서 팀뿐 아니라 번역가, 큐레이터, 데이터 분석가 등 다양한 직군이

같은 공간(클러스터)에서 동시에 일할 수 있게 되었다고 이해하면 됩니다.

 

4. 동작 원리  

하둡의 코어는 세 가지 레이어로 구성됩니다. HDFS(저장), MapReduce(처리), YARN(자원 관리) 입니다.

 

① HDFS — 어떻게 저장하는가

블록 분할과 복제

HDFS에 저장되는 모든 파일은 일정 크기의 블록(기본 128MB 또는 256MB)으로 분할됩니다.

각 블록은 설정된 복제 계수(Replication Factor, 기본값 3) 에 따라 서로 다른 데이터노드에 분산 저장됩니다.

이때 핵심이 랙 인식(Rack Awareness) 알고리즘입니다. 복제본 중 하나는 반드시 다른 랙(Rack)의 노드에 배치합니다.

물리적인 랙 전체에 장애가 발생하더라도 데이터 가용성을 보장하기 위해서입니다.

 

하트비트와 장애 감지

네임노드(Master)와 데이터노드(Slave) 사이에는 주기적인 하트비트 신호가 오고 갑니다.

데이터노드는 하트비트와 함께 자신이 보유한 블록의 목록인 블록 리포트를 네임노드에 전송합니다.

만약 정해진 시간 동안 하트비트가 도달하지 않으면, 네임노드는 해당 데이터노드를 '데드(Dead)' 상태로 판정합니다.

그 즉시 해당 노드가 보유했던 데이터를 클러스터 내 다른 정상 노드들로부터 재복제하는 프로세스를 시작하여 복제 계수를 유지합니다.

=> 결함 허용성을 전제로, 데이터 노드를 분산 저장하고 하트비트 신호로 장애난 데이터 노드를 감지한다.

 

단일 장애점(SPOF) 문제와 고가용성(HA)

초기 하둡의 치명적인 약점이 있었습니다. 단일 네임노드(Single NameNode) 구조로 인한 단일 장애점(Single Point of Failure, SPOF) 문제입니다.

수천 대의 데이터노드를 관리하는 네임노드가 중단될 경우, 전체 클러스터의 데이터 접근이 불가능해집니다.

이를 극복하기 위해 현대 하둡 아키텍처는 액티브-스탠바이(Active-Standby) 구조의 고가용성(HA) 메커니즘을 도입했습니다.

구체적으로는 다음과 같이 동작합니다.

 

- 공유 스토리지(Shared Storage) 또는 저널 노드(Journal Nodes) 그룹을 활용하여 에디트 로그(Edit Log)를 실시간으로 동기화합니다.
- 주 네임노드에 장애가 발생하면 주키퍼(ZooKeeper) 와 같은 코디네이터 서비스를 통해 보조 네임노드가 즉시 제어권을 승계합니다.
- 이 과정에서 펜싱(Fencing) 기술을 사용하여 두 노드가 동시에 쓰기 권한을 가지는 '스플릿 브레인(Split-brain)' 현상을 원천 방지합니다.

 

=> 네임노드(master)의 장애를 고려하여 액티브-스탠바이(Active-Standby) 구조 도입

 

데이터 정합성 — 체크섬(Checksum) 3단계 검증

데이터를 복제해 두는 것만으로는 충분하지 않습니다. 전송 중에 데이터가 오염될 수 있기 때문입니다.

HDFS는 저장 전후와 유휴 상태 전 구간에 걸쳐 지속적인 산술적 검증을 수행합니다.

 

첫째, 쓰기 파이프라인에서의 실시간 검증

클라이언트가 데이터를 HDFS에 기록할 때, 데이터는 패킷 단위로 분할되어 전송됩니다.

이때 각 패킷에 대해 32비트 순환 중복 검사(CRC-32) 를 통해 체크섬을 생성합니다.

데이터노드는 패킷을 수신함과 동시에 체크섬을 계산하여 클라이언트가 보낸 값과 대조합니다.

불일치가 발생하면 해당 패킷은 즉시 폐기되고 재전송을 요청합니다. 저장 단계 이전의 데이터 오염을 원천 차단하는 구조입니다.

 

둘째, 읽기 시점의 사후 검증

클라이언트가 데이터를 읽을 때, 데이터노드로부터 데이터 블록과 함께 저장된 체크섬 파일을 함께 전송받습니다.

클라이언트는 수신한 데이터에 대해 다시 체크섬을 계산하고 저장된 값과 일치하는지 확인합니다.

정합성 오류가 탐지되면 클라이언트는 네임노드에 해당 블록의 손상을 보고(Report)하고,

네임노드는 정상적인 다른 복제본(Replica)을 찾아 클라이언트에게 제공함과 동시에 손상된 블록의 폐기 및 복구 프로세스를 가동합니다.

 

셋째, 백그라운드 정기 검사

데이터노드는 내부적으로 '데이터 블록 스캐너(DataBlockScanner)' 라는 백그라운드 스레드를 운용합니다.

클라이언트의 요청이 없더라도 주기적으로 로컬 디스크에 저장된 모든 블록을 순회하며 체크섬을 검사합니다.

이를 통해 디스크의 물리적 노화로 인해 발생하는 점진적인 데이터 부패를 조기에 발견할 수 있습니다.

결론적으로 HDFS의 데이터 정합성은 단순히 데이터를 중복 저장하는 것에 그치지 않고,

저장 전·후 및 유휴 상태 전반에 걸쳐 지속적인 산술적 검증을 수행함으로써 보장됩니다.

 

② MapReduce — 어떻게 처리하는가

MapReduce는 YARN 위에서 동작하는 분산 애플리케이션 중 하나로, 분산 시스템에서 데이터 처리를 실행하는 데 사용됩니다.

임의의 자바 프로그램을 실행시킬 수 있기 때문에 비구조화 데이터를 가공하는 데 특히 적합합니다.

처리 방식은 2단계입니다.

흩어져 있는 데이터를 수직화한 뒤,

 

- Map 단계: 데이터를 쪼개서 각 노드가 병렬로 처리, 종류별로 분류
- Reduce 단계: 분류된 데이터를 모아 필터링·정렬·집계

 

③ YARN — 어떻게 자원을 관리하는가 (Hadoop 2.0)

초기 하둡은 MapReduce가 처리와 자원 관리를 동시에 담당했습니다. 비효율적인 구조였습니다.

Hadoop 2.0에서 등장한 YARN(Yet Another Resource Negotiator)은 클러스터의 자원 관리와 작업 스케줄링을 연산 프레임워크로부터 분리했습니다.

YARN의 역할은 세 가지입니다.

 

- CPU나 메모리 등의 계산 리소스를 관리하는 리소스 매니저
- 애플리케이션이 사용하는 CPU 코어와 메모리를 '컨테이너' 라는 단위로 추상화하여 관리
- 분산 애플리케이션이 실행되면 클러스터 전체의 부하를 보고, 비어 있는 호스트부터 컨테이너를 할당

 

이 분리 덕분에 동일한 데이터 위에서 실시간 스트리밍(Spark), 대화형 질의(Impala, Hive), 그래프 분석 등

다양한 워크로드가 공존할 수 있는 환경이 만들어졌습니다.

5. 실제 예시로 흐름 보기

"웹 로그에서 가장 많이 방문된 페이지 TOP 10 추출" 을 하둡으로 처리한다면:

[원본 로그 파일 500GB]
        ↓ HDFS가 128MB 블록으로 분할, 각 블록을 3개 노드에 복제 저장

[Map 단계] — 각 노드가 자기 블록만 병렬 처리
  /home → {"/home": 1}
  /about → {"/about": 1}
  /home → {"/home": 1}
  ...

[Reduce 단계] — 같은 키끼리 모아서 집계
  {"/home": 128,450}
  {"/about": 43,210}
  ...

[결과]
  TOP 10 페이지 리스트 반환

 

이 전체 과정에서 YARN은 Map/Reduce 각 작업에 컨테이너를 할당하고, 어느 노드에서 실행할지 스케줄링합니다.

만약 특정 노드가 처리 중 죽으면 HDFS는 다른 복제본에서 해당 블록을 재복구하고, YARN은 해당 태스크를 다른 노드에 재할당합니다.

 

6. 흔한 오해 / 주의사항

"하둡이 있으면 뭐든 빠르다?"

틀렸습니다. 하둡의 MapReduce는 기본적으로 배치 처리(Batch Processing) 에 최적화되어 있습니다.

작업마다 디스크 I/O를 거치기 때문에 실시간 처리에는 느립니다.

실시간 스트리밍이 필요하다면 메모리 기반으로 처리하는 Spark나 Flink가 훨씬 적합합니다.

 

"네임노드 하나면 충분하다?"

초기 하둡의 치명적 약점이 바로 이것이었습니다.

단일 네임노드 구조는 네임노드가 죽는 순간 클러스터 전체가 멈추는 SPOF 문제를 안고 있습니다.

현대 하둡은 Active-Standby HA 구조 + ZooKeeper + 펜싱으로 이를 해결했지만, 이 구성을 빠뜨리면 프로덕션 환경에서 큰 위험을 떠안게 됩니다.

 

"복제 3개면 데이터 정합성도 자동으로 보장된다?"

복제는 가용성을 높이는 것이고, 정합성은 별개의 문제입니다.

오염된 데이터가 조용히 3벌 복제될 수 있습니다.

HDFS가 쓰기·읽기·유휴 상태 전 구간에서 CRC-32 체크섬 검증을 수행하는 이유가 바로 여기에 있습니다.

 

7. 언제 쓰고 언제 쓰지 말아야 하나 (Trade-offs)

첫째, HDFS의 스토리지 계층에서 발생하는 가장 근본적인 트레이드오프는 데이터 처리량과 접근 지연 시간 사이의 불균형입니다. 

HDFS는 테라바이트급 이상의 대용량 파일을 순차적으로 읽어들이는 스트리밍 데이터 접근 패턴에 최적화되어 있습니다. 

이를 위해 블록 크기를 128MB 혹은 256MB 단위로 거대하게 설정하여 디스크 탐색 시간(Seek Time)을 최소화하고 데이터 전송률(Transfer Rate)을 극대화했습니다. 

그러나 이러한 설계는 필연적으로 밀리초 단위의 빠른 응답을 요구하는 무작위 데이터 접근(Random Access)이나

지연 시간에 민감한 트랜잭션 처리에는 극도로 취약하다는 본질적인 약점을 낳았습니다.

나아가 데이터의 논리적 구조를 관리하는 네임노드는 메타데이터를 메모리에 전적으로 상주시키기 때문에,

파일의 크기가 작고 개수가 많아질수록 메타데이터의 용량이 선형적으로 팽창하여 전체 클러스터의 메모리 병목을 유발하는 이른바 작은 파일 문제(Small File Problem)를 발생시킵니다.  이는 대용량 데이터의 연속적인 처리라는 목적을 달성하기 위해, 파일 저장 단위의 유연성을 희생한 결과입니다.
⇒  대용량 처리에 유용하지만, 단 건 /트랜잭션 처리 취약, 작은 파일도 많이 생길 수 있다.

둘째, 연산 계층에서 뚜렷하게 관찰되는 결함 허용성과 실행 성능 간의 상충 관계입니다. 

하둡의 원형인 맵리듀스(MapReduce) 프레임워크는 맵(Map) 단계와 리듀스(Reduce) 단계 사이의 셔플(Shuffle) 과정에서 발생하는 

모든 중간 연산 데이터를 로컬 디스크에 물리적으로 기록합니다. 

이는 클러스터 내 특정 워커 노드에 치명적인 장애가 발생하더라도 전체 작업을 처음부터 재시작하지 않고 

디스크에 보존된 중간 데이터 지점부터 복구할 수 있는 극단적인 결함 허용성을 시스템에 부여합니다. 

하지만 디스크 I/O 연산은 메모리 접근에 비해 수십만 배 이상의 지연을 유발하므로, 

전체 데이터 분석의 완료 시간을 급격히 저하시키는 가장 큰 성능적 족쇄가 됩니다. 

사용자가 앞서 학습한 임팔라(Impala)나 스파크(Spark)와 같은 현대 에코시스템의 분석 엔진들은 

바로 이 강력한 결함 허용성을 일부 혹은 완전히 포기하거나 데이터를 메모리 상에 유지하는 방식으로 설계 철학을 선회함으로써, 

막대한 디스크 I/O 비용을 초고속 연산 속도로 치환한 뚜렷한 트레이드오프의 산물이라 할 수 있습니다.
⇒  중간 결과 저장으로 데이터 안정성을 가진다. 그런데 디스크 읽고 쓰는 과정이 좀 걸린다.

셋째, 생태계 확장에 따른 시스템 아키텍처의 복잡도와 운영 오버헤드의 증가입니다. 

초기 하둡의 단일 목적 일괄 처리(Batch Processing) 아키텍처는 YARN의 도입과 함께 다목적 분산 공유 클러스터로 진화했습니다. 

HDFS라는 단일 스토리지 플랫폼 위에서 맵리듀스, 스파크, 임팔라 등 이기종의 분산 연산 엔진들이 한정된 자원을 경합하게 됨에 따라, 

YARN의 리소스 매니저(Resource Manager)는 클러스터 전체의 CPU와 메모리를

컨테이너 단위로 정밀하게 분할하고 스케줄링해야 하는 막대한 관리적 오버헤드를 떠안게 되었습니다.

더불어 마스터 노드의 고가용성(HA)을 달성하기 위해 필수적으로 도입된 주키퍼(ZooKeeper),

저널 노드(JournalNode) 등의 분산 조정(Coordination) 시스템들은 클러스터의 네트워크 아키텍처를 고도로 복잡하게 만들었으며,

네트워크 파티션 발생 시 분산 노드 간의 상태 불일치를 해결하기 위한 분산 합의 알고리즘의 백그라운드 실행 비용을 시스템 전반에 가중시켰습니다.

⇒ 하나의 하둡 시스템 위에서 목적에 맞게 다른 도구도 사용 가능, 그런데 시스템이 너무 거대해지고 복잡해질 수 있다.

TB~PB 단위 대용량 배치 처리	✅ 최적	Scale-out 설계 철학 자체가 이를 위함
저비용 대용량 데이터 보관	✅ 최적	범용 서버 + HDFS 복제로 저비용 구성 가능
비정형 데이터(로그, JSON 등) 가공	✅ 적합	자바 프로그램 직접 실행 가능한 MapReduce
실시간 스트리밍 처리	❌ 비적합	Spark/Flink 권장, MapReduce는 배치 전용
수십 GB 이하 소규모 데이터	❌ 오버엔지니어링	클러스터 운영 비용이 이득보다 큼
빠른 랜덤 읽기/쓰기	❌ 비적합	RDBMS나 NoSQL(HBase 등) 권장

 

YARN의 등장 이후 하둡은 단순히 "MapReduce를 돌리는 플랫폼"이 아닙니다.

하둡 클러스터를 자원 풀로 삼아 다양한 도구를 올려 쓰는 빅데이터 플랫폼으로 진화했습니다.

그래서 현대 빅데이터 아키텍처에서 하둡은 Spark, Hive, Impala, HBase 등과 함께 에코시스템 단위로 평가하고 도입을 결정해야 합니다.

 

한 줄 요약

섹션	핵심
왜 필요한가	비정형 데이터 폭증으로 단일 서버의 수직적 확장이 한계에 도달했다.
개념의 본질	싼 서버 여러 대를 묶어 하나처럼 쓰되, 장애를 일상으로 전제하고 설계한 플랫폼이다.
직관적 비유	책을 잘라 여러 서가에 3부씩 나눠두고, 관리자가 위치만 기억하는 도서관 팀이다.
HDFS 저장	블록으로 분할 → 3중 복제 → 하트비트로 장애 감지 → 자동 재복제로 가용성을 유지한다.
데이터 정합성	쓰기·읽기·유휴 상태 전 구간에서 CRC-32 체크섬으로 데이터 오염을 막는다.
MapReduce	데이터를 병렬로 쪼개어 처리(Map)하고 다시 모아 집계(Reduce)하는 배치 처리 프레임워크다.
YARN	자원 관리를 연산에서 분리하여, 하나의 클러스터 위에서 여러 워크로드가 공존하게 했다.
트레이드오프 ①	대용량 순차 처리를 위해 무작위 접근과 저지연성을 포기했다.
트레이드오프 ②	극단적인 결함 허용성을 위해 디스크 I/O 비용을 감수했다.
트레이드오프 ③	확장성을 얻는 대신 ZooKeeper·저널 노드 등으로 운영 복잡도가 높아졌다.