저번 포스팅에서는, Map Reduce 를 공부하였습니다.
이번에는 하둡의 여러 에코시스템들에 대해 공부하고 정리해보도록 하겠습니다.

📌 Hadoop 을 공부하고 정리한 파트이기 때문에, 에코시스템에 대한 기본적인 내용을 담고 있습니다. 각 에코시스템의 디테일한 내용은 추후 공부하고 따로 포스팅하겠습니다. :D

📘 분산 시스템의 이해와 하둡의 등장 배경
📘 하둡의 핵심 구성요소와 이론
📘 YARN(Yet Another Resource Negotiator) 기본 이론
📘 Map Reduce 기본 이론

🐘 1. 하둡 에코시스템과 관련 프로젝트

하둡은 단순한 분산 저장 및 처리 프레임워크로 출발했지만, 현실 세계의 복잡한 데이터 처리 요구사항을 만족시키기 위해 수많은 에코시스템 구성 요소들로 확장되었습니다.
이러한 에코시스템들은 하둡의 기본적인 기능(HDFS와 MapReduce)만으로는 해결하기 어려운 실질적인 문제들을 보완하고, 다양한 사용 시나리오에 대응하기 위해 등장하게 되었습니다.

옛날로 돌아가보면, 초기 하둡은 HDFS를 통해 데이터를 저장하고, MapReduce를 이용해 데이터를 처리하는 구조로 시작되었습니다.
이 구조는 대규모 배치 처리에는 적합했지만, 여러가지 제한점이 존재했습니다.

몇 가지 예시를 들어보면,
MapReduce는 배치 처리에 최적화되어 있어, 실시간 로그 분석, 이벤트 기반 처리등 스트리밍 데이터나 실시간 분석에는 적합하지 않았으며,
모든 처리를 Java 기반으로 MapReduce 로직을 작성해야 했기 때문에, SQL을 선호하는 데이터 분석가들에게는 진입장벽이 매우 높았습니다.
또한, 배치 처리 외에 ETL, 머신러닝, 검색, 그래프 분석 등 다양한 워크로드를 유연하게 지원하기 어려웠습니다.

이러한 한계점을 보완하기 위해, 하둡 기반 위에 전문적인 기능을 수행하는 다양한 서브 프로젝트들이 자연스럽게 등장했습니다.

하둡은 하나의 거대한 일체형 소프트웨어가 아니라, 서로 다른 역할을 수행하는 여러 프로젝트들이 느슨하게 결합된 모듈형 생태계(Modular Ecosystem)로 구성되어 있습니다.

각각의 도구들은 특정 문제 영역을 해결하도록 설계되었고, 서로 연동되면서 보다 유연하고 확장 가능한 분산 시스템을 구성합니다.

아래에서 더 자세히 알아보겠지만, 지금 몇 가지만 간략하게 이야기해보면 이해가 쉬울겁니다.

• Pig, Hive → SQL 혹은 DSL로 MapReduce 추상화 → 사용자 편의성 향상
• HBase → HDFS 위에 컬럼 기반 DB 구축 → 실시간 조회 기능 제공
• Zookeeper → 분산 환경에서의 구성 관리 및 락 처리 → 고가용성 보장
• Oozie, Airflow → 워크플로우와 작업 스케줄링 → 자동화된 데이터 파이프라인
• YARN → 자원 관리의 중앙 집중화 → 다양한 애플리케이션 실행 지원
• Spark, Tez, Flink → MapReduce를 대체하거나 보완하는 고속 처리 엔진

이처럼 각각의 프로젝트는 독립적으로도 활용 가능하지만, 하둡이라는 공통된 기반 위에서 상호 보완적인 관계로 작동합니다. 이러한 설계는 하둡이 단순한 프레임워크를 넘어, 범용 분산 데이터 처리 플랫폼으로 진화하게 된 핵심 배경이기도 합니다.

위와 같은 이유와 사상을 가지고, 하둡 에코시스템은 오픈소스를 기반으로 하며, 누구나 참여하고 확장할 수 있도록 설계되어 있습니다. 이로 인해 다양한 기업과 커뮤니티에서 자신들의 요구에 맞춰 하둡을 커스터마이징하고, 새로운 컴포넌트를 추가할 수 있게 되었습니다.

대표적인 예로, Cloudera, Hortonworks, MapR 등 상용 디스트리뷰터들은 하둡을 기반으로 한 통합 플랫폼을 제공하면서, 보안, 모니터링, 통합 관리 도구 등 엔터프라이즈 환경에서 필요한 기능들을 추가해 생태계를 더욱 풍성하게 만들었습니다.

그럼 지금부터 대표적인 에코시스템 몇 가지를 알아보도록 하겠습니다.

🐘 1.1. Apache Avro 와 Parquet 그리고 ORC

하둡은 방대한 양의 데이터를 효율적으로 저장하고 처리할 수 있는 플랫폼이라는 점은 많은 분들이 이미 알고 있을 것입니다. 또한, 하둡의 분산 파일 시스템(HDFS)에 저장된 데이터는 정형, 반정형, 비정형 여부에 관계없이 Spark, Hive, Pig, Impala, Presto 등 다양한 처리 엔진을 통해 가공하고 분석할 수 있다는 점도 잘 알려져 있습니다.

하지만 하둡과 그 에코시스템을 하나하나 학습하다 보면, 자연스럽게 “하둡에서 데이터를 어떤 형식으로 저장해야 효율적인가?” 라는 질문에 직면하게 됩니다. 실제로, 데이터 저장 형식은 하둡 환경에서 성능과 자원 효율성에 직결되는 핵심 요소입니다.

우리가 기존에 많이 사용해왔던 CSV, JSON, XML과 같은 친숙한 파일 포맷은 하둡 환경에서는 그리 선호되지 않습니다.

이유는 명확합니다. 이러한 형식은 하둡의 가장 큰 강점 중 하나인 병렬 처리와 스토리지 최적화에 불리하기 때문입니다.

하둡을 사용하는 주요 목적 중 하나는 대용량 데이터를 분산 저장하고 병렬로 처리하여 높은 처리량과 확장성을 확보하는 것입니다. 그런데 CSV나 JSON 같은 포맷은 구조상

• 스키마 정보가 외부에 별도로 존재해야 하고

• 압축이나 컬럼 단위 접근에 비효율적이며

• 데이터 분할(partitioning) 및 병렬 처리에 제약이 있습니다.

이러한 한계를 극복하기 위해, 하둡 기반 시스템에서는 보통 Avro, Parquet, ORC(Optimized Row Columnar)와 같은 최적화된 바이너리 포맷을 활용합니다.

이들 포맷은 공통점도 있지만, 각기 다른 특징과 사용 목적, 장단점이 존재합니다.
이제부터 이 세 가지 대표적인 저장 포맷을 비교 분석하면서, 어떤 상황에 어떤 포맷을 선택해야 하는지 정리해보겠습니다.

✅ 공통점

1. 하둡에 최적화된 저장 형식
   세 포맷 모두 HDFS 등 하둡의 분산 스토리지 환경에서 높은 성능을 내도록 설계되었습니다.

2. 내장 압축 기능 제공
   기본적으로 압축을 지원하며, 저장 공간을 절약하고 I/O 성능을 향상시킵니다.

3. 기계가 읽는 바이너리 형식
   사람이 읽기 편한 JSON, XML과 달리 이들 포맷은 바이너리 형태로 저장되어 기계가 읽기에 최적화되어 있습니다.
   이로 인해 하둡에서 JSON/XML을 사용하려 한다면, 하둡을 사용하는 이유 자체를 재고해야 할 정도입니다.

4. 병렬 처리 및 확장성
   세 가지 형식 모두 파일을 여러 디스크에 분산 저장할 수 있어 병렬 처리와 확장성이 뛰어납니다.
   반면 JSON, XML은 파일 단위로 처리되기 때문에 분할 처리에 제약이 있습니다.

5. 스키마 내장 지원
   세 포맷 모두 데이터 스키마를 함께 저장합니다.
   따라서 파일만으로도 어떤 데이터인지 알 수 있어, 시스템 간 데이터 이동 시 유리합니다.

6. Wire Format으로 사용 가능
   단순한 저장 포맷이 아니라, 네트워크를 통한 전송에도 사용할 수 있는 형식입니다.
   즉, Hadoop 클러스터 내에서 노드 간 데이터를 주고받는 데에도 활용됩니다.

🔍 Wire Format이란?
데이터를 메모리나 디스크에 저장할 수 있는 형식을 말하며, 이 데이터는 결국 네트워크를 통해 전송되기 때문에 “wire(선 위의)” 포맷이라고 부릅니다.

✅ Avro, Parquet, ORC의 차이점: 저장 방식과 활용 목적의 차이

세 포맷의 가장 큰 차이는 데이터를 저장하는 방식에 있습니다.
Avro는 행(Row)-기반 포맷인 반면, Parquet와 ORC는 열(Column)-기반 포맷입니다.

• 열 기반 포맷 (Columnar Format)은 분석 쿼리처럼 일부 열만 선택적으로 조회하는 작업에 유리합니다.
  예: 리포트 생성, 집계 분석 등

• 행 기반 포맷 (Row Format)은 전체 행 데이터를 자주 읽거나, 쓰기 작업이 빈번한 경우에 적합합니다.
  예: 트랜잭션 기록, 로그 수집 등

✅ 예시로 이해하는 저장 방식의 차이

▣ 예시 1: 열 기반 포맷이 유리한 경우
시나리오: 100만 명의 직원을 둔 대기업의 HR팀이 지역별 급여 데이터를 분석하는 경우

• 쿼리 목적: 급여, 지역 열만 조회
• Parquet/ORC처럼 열 기반 포맷은 필요한 열만 선택적으로 조회 가능하므로 읽기 I/O가 적고 매우 효율적입니다.
• 반면, Avro는 행 전체를 읽고 그 중 필요한 열만 필터링해야 하므로 비효율적입니다.

▣ 예시 2: 행 기반 포맷이 유리한 경우
시나리오: 항공사가 사용자에게 특정 시간대(오후 7시~자정) 모든 항공편 정보를 제공

• 쿼리 목적: 모든 열 데이터 필요
• 이 경우는 전체 행을 통째로 읽는 작업이므로 Avro 같은 행 기반 포맷이 훨씬 효율적입니다.
• Parquet/ORC는 열 단위 저장으로 인해 전 열을 모으는 데 오히려 I/O 비용이 증가합니다.

✅ 압축률 차이

Parquet와 ORC는 열 기반 구조 덕분에 압축률이 높습니다.
열 단위로 저장되므로, 유사한 값이 반복되는 열(예: 성별, 국가 코드, 상태 플래그 등)을 묶어 압축할 수 있기 때문입니다.
이 구조는 특히 IoT처럼 대량의 센서 데이터를 저장해야 할 때 스토리지 효율을 극대화할 수 있습니다.

반면, Avro는 행 전체를 묶어 저장하기 때문에 데이터의 다양성이 커지고, 결과적으로 압축률이 낮아지는 경향이 있습니다.

✅ 스키마 진화 지원 (Schema Evolution)

• Avro는 스키마 진화에 매우 강력합니다.
  데이터의 구조를 기술하는 메타데이터는 JSON으로 표현하고, 실제 데이터는 바이너리로 저장하므로 스키마 변경에 유연하게 대응할 수 있습니다.

• ORC는 Hive와의 긴밀한 통합 덕분에 Parquet보다 더 나은 스키마 진화 지원을 제공합니다.
  Hive 메타스토어와의 호환성도 뛰어나며, 필드 추가나 변경에 대해 상대적으로 잘 대응합니다.

✅ 주요 사용 사례 및 연결 기술

• Avro
  Kafka에서 메시지를 직렬화하는 포맷으로 널리 사용됩니다.
  또한 전송 포맷(wire format)으로도 적합하며, 데이터 교환에 최적화되어 있습니다.

• Parquet
  Cloudera 환경(CDH)에서 Impala와 자주 함께 사용되며, Spark, Drill, Hive 등 다양한 분석 도구에서 폭넓게 지원됩니다.

• ORC
  Hortonworks 기반(HDP)의 Hive에서 기본 포맷으로 사용되며, Presto 등에서도 지원됩니다.

❗ Apache Spark는 이 세 포맷 모두를 지원하므로, 사용 목적에 따라 가장 적합한 포맷을 선택하는 것이 중요합니다.

✅ 포맷별 요약 비교

✅ Hadoop 에서 각 포멧 사용 방법 ( Hive 예시 )

📁 1. TEXTFILE**

CREATE TABLE tb_text (
    ymd STRING,
    tag STRING,
    cnt INT
)
ROW FORMAT DELIMITED
FIELDS TERMINATED BY '\t'
STORED AS TEXTFILE;

압축 설정 (INSERT 전에 적용):

SET hive.exec.compress.output=true;
SET mapred.output.compression.codec=org.apache.hadoop.io.compress.GzipCodec;
-- 또는
SET mapred.output.compression.codec=org.apache.hadoop.io.compress.SnappyCodec;

단순 텍스트 저장에 적합하지만, 대규모 분석에는 비효율적임.

📁 2. PARQUET

CREATE TABLE tb_parquet (
    ymd STRING,
    tag STRING,
    cnt INT
)
STORED AS PARQUET;

압축 설정:

SET parquet.compression=SNAPPY;
-- 또는
SET parquet.compression=GZIP;
SET parquet.compression=UNCOMPRESSED;

열 기반 포맷으로, 분석 쿼리 및 Spark 환경에 최적화됨.

Parquet 의 경우 기존에는 아래처럼 등록하였음.

CREATE TABLE tb_parquet (
    ymd STRING,
    tag STRING,
    cnt INT
)
ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS 
    INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat'
    OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat';

그러나 0.14부터는 Parquet 를 지원해주어서, STORED AS PARQUET; 으로 등록하면 내부적으로 아래와 같이 등록됨.

ROW FORMAT SERDE 'org.apache.hadoop.hive.ql.io.parquet.serde.ParquetHiveSerDe'
STORED AS
  INPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetInputFormat'
  OUTPUTFORMAT 'org.apache.hadoop.hive.ql.io.parquet.MapredParquetOutputFormat'

📁 3. ORC

CREATE TABLE tb_orc (
    ymd STRING,
    tag STRING,
    cnt INT
)
STORED AS ORC
TBLPROPERTIES ("orc.compress"="ZLIB");
-- 또는
-- TBLPROPERTIES ("orc.compress"="SNAPPY");
-- TBLPROPERTIES ("orc.compress"="NONE");

Hive에서 권장하는 포맷이며, 높은 압축률과 성능 제공.

📁 4. AVRO

CREATE TABLE tb_avro (
    ymd STRING,
    tag STRING,
    cnt INT
)
STORED AS AVRO;

압축 설정:

SET hive.exec.compress.output=true;
SET avro.output.codec=snappy;
-- 또는
SET avro.output.codec=deflate;
SET avro.output.codec=bzip2;

스키마 진화가 자주 일어나는 환경 (예: Kafka) 에 적합.

| 포맷 | Hive 권장 여부 | 압축 설정 방식 | 특징 요약 |
|————-|—————-|—————-|———–|
| TEXTFILE | 낮음 | SET 방식 | 단순, 비효율적 |
| PARQUET | 높음 | SET 방식 | 분석 쿼리 최적 |
| ORC | 매우 높음 | TBLPROPERTIES | Hive 최적화 |
| AVRO | 중간 이상 | SET 방식 | 스키마 진화 |

❗ 해당 글은, 하둡 에코 시스템에 대한 간단한 내용을 공부하고 다룹니다. 각 에코시스템의 보다 더 자세한 내용은 추후 공부하여, 따로 포스팅 할 예정입니다.

🐘 1.2. Apache Flume

🐘 1.3. Apache Sqoop

🐘 1.4. Apache Kerberos

🐘 1.5. Apache Hive

🐘 1.6. Apache Impala

🐘 1.7. Apache HBase

🐘 1.8. Apache Spark

🐘 1.9. Apache Oozie

🐘 1.10. Apache Zookeeper

🐘 1.11. Apache Crunch

🐘 1.12. 그 외 프로젝트와, 프로젝트의 큰 종류

🐘 2. 하둡의 운영과 관리

🐘 2.1. 하둡의 주요 설정 파일과, 설정 값

🐘 2.2. 실제 하둡 클러스터 구축과 보안

🐘 2.3. 현업에서의 하둡을 관리하는 방법

🐘 3. 기타 하둡에 대해 알아야 할 몇 가지

🐘 3.1. 하둡 I/O

🐘 3.2. Schema on Read vs Schema on Write

🐘 3.3. 하둡의 세 가지 모드

🐘 3.4. CDH

🐘 3.5. Cascading

🐘 3.6. 쿠버네티스 환경에서는 하둡이 되지 않는 이유?

🐘 4. 실제 하둡 관련 면접 질문 사례 모음

❓ 질문: RDBMS 와 HDFS의 차이점은 무엇인가요?

관계형 데이터베이스(RDBMS)와 하둡 분산 파일 시스템(HDFS)은 모두 데이터를 저장하고 처리하기 위한 시스템이지만, 설계 철학과 사용 목적이 크게 다릅니다.
RDBMS는 주로 구조화된 데이터를 저장하기 위한 시스템으로, 모든 데이터는 명확하게 정의된 스키마(schema)에 따라 저장됩니다. 즉, 데이터를 데이터베이스에 적재하기 전에 미리 테이블 구조가 정의되어 있어야 하며, 해당 구조에 맞지 않는 데이터는 저장할 수 없습니다. 이러한 특성 덕분에 데이터의 무결성을 보장할 수 있고, 복잡한 질의(쿼리)나 트랜잭션 처리에 매우 적합합니다. 이러한 이유로 RDBMS는 OLTP(Online Transaction Processing), 즉 은행이나 ERP 시스템처럼 다수의 사용자가 실시간으로 데이터를 삽입·수정·조회하는 환경에서 널리 사용됩니다.
반면 HDFS는 다양한 형태의 데이터를 유연하게 저장할 수 있도록 설계되었습니다. 구조화된 데이터뿐만 아니라 JSON, XML, 이미지, 로그 파일 등 반구조화 또는 비정형 데이터도 저장할 수 있습니다. 또한 HDFS는 데이터를 수십 대에서 수천 대의 서버에 분산 저장하고 병렬로 처리할 수 있도록 설계되어 있어, 대용량 데이터 처리에 매우 효과적입니다.
스키마 적용 방식에서도 두 시스템은 다릅니다. RDBMS는 ‘스키마 온 라이트(schema-on-write)’ 방식으로, 데이터를 저장할 때 스키마를 미리 검사합니다. 이로 인해 데이터의 정확성과 정합성은 높지만, 유연성이 떨어지고 초기 처리 속도는 느릴 수 있습니다. 반면 HDFS는 ‘스키마 온 리드(schema-on-read)’ 방식을 따르며, 데이터를 저장할 때는 유효성 검사를 수행하지 않기 때문에 빠르게 데이터를 쌓을 수 있고, 실제 분석이나 검색 시점에 스키마를 적용하여 데이터를 해석합니다. 이 방식은 비정형 데이터를 많이 다루는 환경에서 매우 유리합니다.
또한, RDBMS는 일반적으로 단일 서버 또는 소규모 클러스터에서 동작하며, 고성능의 트랜잭션 처리를 목표로 하기 때문에 읽기 속도가 빠른 반면, HDFS는 쓰기 성능이 매우 뛰어나며 대용량의 데이터를 빠르게 수집할 수 있습니다. 마지막으로 라이선스 측면에서도 차이가 있습니다. RDBMS는 상용 제품이 많아 비용이 발생할 수 있지만, Hadoop은 오픈소스 기반으로 누구나 자유롭게 사용할 수 있다는 점도 큰 장점입니다.
결론적으로, RDBMS는 구조화된 데이터를 대상으로 빠른 트랜잭션과 정합성이 필요한 환경에 적합하고, HDFS는 다양한 형태의 대용량 데이터를 유연하게 저장하고 분석하는 데 적합한 플랫폼입니다.

❓ 질문: 빅데이터를 설명하는 5V는 무엇인가요?

빅데이터는 기존의 데이터베이스 관리 시스템으로는 처리하기 어려울 만큼 거대하고 복잡한 데이터를 의미하며, 이러한 데이터를 정의하기 위해 흔히 5가지 핵심 특성으로 요약된 ‘5V’ 개념이 사용됩니다.
첫 번째는 Volume(볼륨)입니다. 이는 데이터의 양을 의미하는데, 빅데이터는 테라바이트(TB), 페타바이트(PB), 엑사바이트(EB)를 넘어서는 막대한 양의 데이터를 포함합니다. 예를 들어, SNS, IoT 센서, CCTV 영상, 전자상거래 로그 등에서 생성되는 데이터는 하루에도 수십~수백 기가바이트에 이를 수 있습니다.
두 번째는 Velocity(속도)입니다. 데이터가 생성되고 전달되는 속도가 매우 빠르다는 뜻입니다. 과거에는 데이터가 주기적으로 배치(batch)로 수집되었지만, 오늘날의 빅데이터 환경에서는 초당 수천~수만 건의 이벤트가 실시간으로 생성되고 분석됩니다. 예를 들어 실시간 위치 기반 추천 서비스나 금융 거래 이상 탐지 시스템은 빠른 데이터 속도를 요구합니다.
세 번째는 Variety(다양성)입니다. 빅데이터는 단순한 정형 데이터뿐만 아니라, 로그 파일, 이미지, 오디오, 비디오, 센서 데이터 등 다양한 형태의 데이터를 포함합니다. 이러한 이질적인 데이터 유형을 통합하여 분석할 수 있는 유연성이 필수적입니다.
네 번째는 Veracity(정확성)입니다. 데이터가 아무리 많고 빠르게 수집되더라도, 그 품질이 낮거나 불확실하다면 신뢰할 수 있는 분석 결과를 도출하기 어렵습니다. 따라서 빅데이터 환경에서는 데이터 정제(cleaning) 및 품질 검증이 중요한 과제가 됩니다.
다섯 번째는 Value(가치)입니다. 결국 데이터를 수집하고 분석하는 목적은 비즈니스 또는 사회적 가치 창출입니다. 원시 데이터(raw data) 그 자체보다는, 그로부터 유의미한 통찰(insight)을 도출하는 것이 핵심입니다.

❓ 질문: RDBMS와 HDFS의 차이점은?

Hadoop은 대용량 데이터를 분산 저장하고 병렬 처리할 수 있도록 설계된 오픈소스 프레임워크입니다. 2000년대 중반, 구글의 GFS와 MapReduce 논문을 기반으로 만들어졌으며, 현재는 다양한 빅데이터 플랫폼의 기반이 되고 있습니다.
Hadoop의 핵심 구성요소는 크게 두 가지로 나뉩니다.
첫 번째는 HDFS (Hadoop Distributed File System)입니다. HDFS는 데이터를 여러 개의 블록으로 나눈 뒤, 이를 여러 노드에 분산 저장합니다. 하나의 파일이 수백 MB 또는 수 GB 단위일지라도, 블록 단위로 쪼개서 저장되며, 복제(replication) 메커니즘을 통해 장애에 강한 저장소를 구현합니다.
두 번째는 YARN (Yet Another Resource Negotiator)입니다. YARN은 하둡 클러스터 내에서 컴퓨팅 자원을 효율적으로 관리하고, 작업(job)을 스케줄링하고 실행하는 역할을 합니다. MapReduce, Spark, Tez, Hive 등 다양한 데이터 처리 엔진들이 YARN 위에서 실행되며, 자원 할당과 실행 상태 모니터링 등을 YARN이 책임집니다.
이 외에도 데이터 처리용 컴포넌트로는 MapReduce, Apache Spark, Hive, HBase, Pig, Flink 등이 있으며, 각각 SQL 처리, 실시간 스트리밍, 머신러닝 등에 특화된 기능을 제공합니다.
결론적으로, Hadoop은 HDFS와 YARN이라는 핵심 구성 요소를 바탕으로 대용량 데이터 저장 및 처리를 위한 강력한 생태계를 제공하며, 다양한 오픈소스 툴과 결합해 유연한 분석 플랫폼으로 활용됩니다.

❓ 질문: Hadoop을 사용하는 데 있어 흔히 발생하는 과제는?

✅ 1. NameNode의 단일 장애 지점 문제
Hadoop의 초기 구조에서는 NameNode가 클러스터 전체의 메타데이터를 단독으로 관리합니다.
따라서 NameNode가 장애를 일으키면 전체 클러스터의 운영이 중단되고, 최악의 경우 데이터 손실이 발생할 수 있습니다.
이를 보완하기 위해 High Availability(HA) 구성이 도입되었지만, 기본 구조 자체가 갖는 위험성은 여전히 존재합니다.

✅ 2. 보안 취약성
기본 Hadoop은 보안 기능이 제한적입니다. 그래서 데이터 접근 제어가 세분화되어 있지 않고, 누가 데이터를 조회하거나 변경했는지 추적하기 어렵습니다.
Kerberos 같은 인증 시스템이 있지만, 설정이 복잡하고 유지 비용이 크다는 단점이 있습니다.
추가 보안 계층(Sentry, Ranger 등)을 도입해야 실질적인 데이터 보호가 가능하지만, 이는 운영 복잡도를 높이는 요인이 됩니다.

✅ 3. 실시간 처리 미지원
Hadoop의 핵심 처리 모델인 MapReduce는 배치 처리 기반입니다.
이 방식은 대용량 로그 분석 등에는 효과적이지만, 실시간 스트리밍 데이터 처리에는 부적합합니다.
그래서 Spark, Flink 같은 별도의 실시간 처리 프레임워크가 이를 보완합니다.

✅ 4. 작은 파일 처리 비효율
Hadoop은 기본적으로 대용량 데이터를 다루는 데 최적화되어 있습니다.
각 파일마다 메타데이터가 NameNode에 저장되며, 파일 수가 많아질수록 NameNode 메모리 사용량 급증합니다.
결과적으로 작은 파일들의 갯수가 늘어나면 응답 지연 및 성능 저하가 발생하게 됩니다.
이를 해결하기 위해 Hadoop Archive 등의 접근이 필요합니다.

❓ 질문: Hadoop에서 Distributed Cache의 목적은 무엇인가요?

Hadoop의 분산 캐시(Distributed Cache)는 MapReduce 작업 실행 시 모든 노드에 필요한 읽기 전용 파일(예: JAR 파일, 설정 파일, 참조용 작은 데이터 파일 등)을 미리 로컬에 배포하여 성능을 향상시키는 기능입니다.
HDFS에서 반복적으로 읽는 대신, 작업 시작 시 노드 로컬 디스크에 캐시되어 파일을 반복 다운로드하지 않도록 방지하고,
작은 참조 파일을 빠르게 읽을 수 있어 처리 속도가 개선됩니다.
또한 Mapper/Reducer가 동일한 참조 파일을 활용 할 수 있게 되기 때문에 성능이 향상됩니다.
예를 들어, MapReduce 작업 40개가 있고, 각 작업이 동일한 작은 참조 파일을 반복적으로 읽어야 한다면, 이 파일이 HDFS에만 존재할 경우 매번 네트워크 I/O가 발생합니다.
하지만 분산 캐시에 등록하면 해당 파일이 각 노드 로컬 디스크에 복사되어, 모든 작업이 빠르게 접근할 수 있습니다.

❓ 질문: Hadoop이 실행할 수 있는 세 가지 모드는?

Hadoop은 사용하는 목적과 환경에 따라 세 가지 실행 모드를 지원합니다.
가장 기본적인 실행 방식은 로컬 모드(또는 독립형 모드)입니다. 이 모드는 Hadoop이 단일 Java 프로세스로 실행되며, HDFS 대신 로컬 파일 시스템을 사용합니다.
기본 설정 그대로 동작하기 때문에 core-site.xml, hdfs-site.xml, mapred-site.xml 같은 설정 파일을 따로 구성할 필요가 없습니다.
또한 마스터나 슬레이브 노드를 정의하지 않아도 되며, 디버깅 용도로 가장 유용하고 빠르게 실행되는 모드입니다.

두 번째는 의사 분산 모드(Pseudo-Distributed Mode)입니다.
이 모드에서는 각 Hadoop 데몬(NameNode, DataNode, ResourceManager, NodeManager 등)이 각각 별도의 Java 프로세스로 실행됩니다.
따라서 클러스터가 아닌 단일 머신에서 분산 환경을 시뮬레이션할 수 있습니다.
이 모드를 사용하기 위해서는 설정 파일(core-site.xml, hdfs-site.xml, mapred-site.xml)을 일부 수정해야 하며, 실제 분산 환경과 유사한 조건에서 테스트하거나 디버깅을 수행하는 데 적합합니다.
입력 및 출력 경로로는 HDFS가 사용됩니다.

마지막으로, 완전 분산 모드(Fully-Distributed Mode)는 Hadoop이 실제 운영 환경에서 사용하는 배포 방식입니다.
여러 대의 머신이 하나의 클러스터를 구성하며, 클러스터 내에서 특정 노드는 마스터 역할(NameNode, ResourceManager)을, 나머지 노드는 슬레이브 역할(DataNode, NodeManager)을 수행합니다.
이 모드는 확장성, 장애 복구, 보안 등 다양한 엔터프라이즈 요구사항을 만족시킬 수 있도록 설계되었으며, 모든 구성 파일과 환경 변수를 세밀하게 설정해야 합니다.
완전 분산 모드는 대규모 데이터를 안정적으로 처리하고자 할 때 적합한 방식입니다.

❓ 질문: 분산 캐시에 있는 파일의 변경 사항을 동기화하는 방법은?

함정 질문입니다.
분산 캐시는 Hadoop에서 작업 실행 전에 모든 노드에 동일한 파일을 미리 복사해두는 기능입니다. 이때 복사된 파일은 읽기 전용(read-only) 으로 처리되며, 실행 중에는 변경하거나 업데이트할 수 없습니다.
즉, 어떤 노드에서 분산 캐시에 있는 파일을 수정하더라도, 다른 노드의 캐시에는 전혀 반영되지 않습니다. 각 노드가 가지고 있는 파일은 작업이 시작될 때의 상태 그대로 유지됩니다.

❓ 질문: Hadoop에서 Data Locality이란 무엇인가요?

Hadoop에서 데이터 지역성이란, 데이터를 처리할 때 데이터를 네트워크를 통해 다른 위치로 옮기지 않고, 계산 작업(Task)을 데이터가 저장된 위치로 이동시키는 방식을 의미합니다. 이는 대용량 데이터를 다루는 환경에서 네트워크 전송 비용을 줄이고 성능을 높이기 위한 핵심 개념입니다.
빅데이터 환경에서는 처리해야 할 데이터의 양이 매우 방대하기 때문에, 데이터를 네트워크를 통해 전송하는 데 걸리는 시간과 비용이 상당히 큽니다. 따라서 Hadoop은 데이터를 이동시키는 대신, 계산을 데이터가 위치한 서버(데이터 노드)에서 수행함으로써 전체 처리 시간을 줄이고 시스템 효율을 높입니다.
Hadoop의 작업 스케줄러는 다음과 같은 우선순위 규칙에 따라 작업을 스케줄링합니다

• 로컬(local): 먼저, 데이터가 저장된 같은 노드에서 작업을 실행할 수 있는지 확인합니다. 이것이 가장 이상적인 경우입니다.
• 랙(local rack): 만약 해당 노드에 작업을 실행할 수 없다면, 같은 랙(Rack) 내에 있는 다른 노드에서 실행을 시도합니다. 같은 랙은 네트워크 지연이 적기 때문입니다.
• 원격(other rack): 위의 방법들이 모두 불가능할 경우, 다른 랙에 위치한 복제본이 저장된 노드에서 작업을 실행합니다.

예를들면, 어떤 회사에서 고객 로그 데이터를 분석하기 위해 Hadoop 클러스터를 사용하고 있다고 가정해보겠습니다. 이 로그 데이터는 logs.csv라는 이름으로 HDFS에 저장되어 있으며, 총 300GB 크기로 세 노드에 분산 저장되어 있습니다.
Node1에는 logs.csv의 블록 1이 저장되어 있고, Node2에는 블록 2, Node3에는 블록 3이 저장되어 있습니다. 각 블록은 복제(replication factor = 3) 되어, 세 노드 중 두 곳에 추가로 복사본이 존재합니다.
Hadoop은 먼저 각 블록을 저장하고 있는 노드에서 해당 블록을 처리하는 작업을 실행하려고 합니다. 예를 들어, Block 1을 처리하는 작업은 우선 Node1에서 실행됩니다. 이 경우, 데이터는 디스크에서 바로 읽히므로 네트워크를 사용하지 않습니다.
만약 Node1의 리소스가 부족해서 작업을 실행할 수 없다면, Hadoop은 Block 1의 복제본이 있는 다른 노드에서 실행을 시도합니다. 예를 들어, Block 1의 복제본이 Node2에도 있다면, Hadoop은 Node2에서 작업을 실행합니다. 이 경우에도 여전히 로컬 디스크 접근이 가능하므로 성능이 좋습니다.
만약 Block 1을 가진 어떤 노드에서도 작업을 실행할 수 없다면, Hadoop은 같은 랙(rack) 내의 다른 노드에서 작업을 실행합니다. 이 경우, 데이터는 네트워크를 통해 전달되지만, 랙 내부 통신은 상대적으로 빠르기 때문에 손실이 크지 않습니다.
가장 나쁜 경우는, 해당 데이터를 가진 노드가 모두 바쁘고, 다른 랙에 있는 노드에서 데이터를 네트워크로 받아와야 할 때입니다. 이 경우는 네트워크 병목이 발생할 수 있고, 성능 저하로 이어집니다.

❓ 질문: MapReduce가 권장되지 않는 경우는?

반복 처리 작업에는 MapReduce 가 권장되지 않습니다.
MapReduce는 많은 양의 데이터를 한 번에 처리하는 데는 매우 효과적인 방식입니다. 하지만 동일한 데이터를 반복적으로 여러 번 처리해야 하는 작업에는 잘 맞지 않습니다.
MapReduce는 작업 하나가 끝날 때마다 중간 결과를 HDFS 같은 디스크에 저장하고, 다음 작업은 그것을 다시 디스크에서 읽는 방식으로 동작합니다. 디스크 입출력은 네트워크보다도 훨씬 느리고, CPU나 메모리에 비해서는 비교할 수 없을 정도로 느립니다. 이런 구조 때문에, 같은 데이터를 여러 번 반복해서 읽고 처리해야 하는 작업은 매번 디스크 I/O 비용이 발생하므로 매우 비효율적입니다.

❓ 질문: NameNode 는 어떻게 DataNode 의 장애를 확인하는가?

네임노드는 클러스터 내 각 데이터노드로부터 주기적으로 하트비트(신호)를 수신하여 해당 노드가 정상적으로 작동 중인지 판단합니다. 만약 특정 데이터노드가 하트비트를 일정 시간 동안 보내지 않으면, 네임노드는 해당 노드를 사용 불가능한 상태로 간주합니다.
또한 블록 보고(Block Report)를 통해 각 데이터노드가 보유하고 있는 블록 정보를 파악하고 있으며, 데이터노드의 모든 블록 목록이 네임노드에 저장됩니다. 따라서 하트비트를 보내지 못하는 노드는 블록 복제 등의 과정을 통해 자동으로 대체되거나 복구됩니다.

❓ 질문: NameNode 가 재실행 되는 단계를 설명하세요.

네임노드 복구 프로세스는 다음과 같은 단계를 포함합니다.
먼저 파일 시스템 메타데이터 복제본(FSImage) 을 기반으로 새로운 네임노드를 시작합니다.
그리고 복제본에서 데이터를 불러온 뒤, 클라이언트와 데이터노드가 새로운 네임노드를 승인하도록 합니다.
새로운 네임노드는 마지막 체크포인트 기준으로 FSImage와 EditLog를 통해 상태를 복원하며, 이후 데이터노드로부터 블록 정보를 수신하여 클러스터 운영을 재개합니다.
이러한 과정을 통해 클라이언트 서비스가 정상적으로 재시작됩니다.

❓ 질문: Mapreduce 에서 Combiner 란?

컴바이너는 MapReduce 프로그래밍 모델에서 맵 단계와 리듀스 단계 사이에 위치하는 선택적 구성 요소로, ‘미니 리듀서(mini reducer)’ 역할을 합니다. 맵퍼 노드에서 생성된 중간 결과를 리듀서로 전송하기 전에 로컬에서 부분 집계를 수행하여 데이터 크기를 줄이는 역할을 합니다.
컴바이너를 사용함으로써 리듀서로 전송되는 데이터 양이 크게 감소하고, 이에 따라 네트워크 I/O가 줄어들어 전체 MapReduce 작업의 성능과 효율성이 향상됩니다.
예를 들어, 단어 수 세기(Word Count) 작업에서는 각 맵퍼가 처리한 단어 출현 빈도를 먼저 컴바이너에서 지역적으로 합산해 중복 데이터를 줄인 후 리듀서로 전달함으로써 네트워크 부하를 줄이고 처리 속도를 높입니다.
요약하자면, 컴바이너는 네트워크 트래픽 감소 및 리듀서 부하 분산을 통해 분산 처리의 효율성을 높이는 중요한 최적화 기법입니다.

🐘 5. 사라지는 하둡, 그러나 하둡을 알아야 하는 이유

하둡은 더 이상 빅데이터 생태계의 중심에 있지 않지만, 그 근간에 있는 아키텍처적 사고방식과 기술 원리는 여전히 유효합니다. MapReduce, HDFS, YARN은 분산 시스템의 설계와 대규모 데이터 처리의 본질을 이해하는 데 필수적인 개념이며, 오늘날의 Spark, Flink, Iceberg, Delta Lake 같은 최신 기술들도 그 연장선 위에 존재합니다.

즉, 하둡은 ‘과거의 기술’이 아니라 ‘현재를 설명하는 기술적 문법’입니다. 클라우드 기반 데이터 플랫폼으로 전환되는 지금 이 시점에서도, 하둡의 구조와 철학을 이해한 개발자는 기술 변화에 더욱 유연하게 대응할 수 있습니다.

하둡을 공부한다는 것은 단순히 오래된 기술을 익히는 것이 아니라, 데이터 엔지니어로서의 기본기를 다지고, 새로운 기술들을 더 깊이 있게 이해하기 위한 준비입니다. 결국 사라지는 것은 이름일 뿐, 그 뿌리는 지금도 살아 있다고 할 수 있겠습니다.

✏️ 결론

하둡의 이론을 차근차근 공부한 결과, 하둡은 오늘날의 데이터 처리 기술을 이해하는 데 여전히 중요한 ‘기술적 문법’임을 알 수 있었습니다.

점차 사람들의 기억에서 잊혀지고 있지만, 하둡이 남긴 분산 처리의 철학과 구조적 사고방식은 Spark, Flink, Iceberg 같은 현대 기술들 속에 깊이 녹아 있습니다.

데이터 엔지니어로서 하둡을 이해한다는 것은 단지 오래된 기술을 학습하는 것이 아니라, 기술의 뿌리를 꿰뚫고 미래 기술의 본질까지 이해하는 힘을 기르는 과정이라고 생각합니다. 이번 포스팅은 그 첫걸음으로써 충분한 의미가 있었다고 봅니다.

다음 시간에는 하둡의 핵심 구성요소인 HDFS와 YARN을 직접 실습해보고, 하둡 에코시스템 중에서도 가장 널리 사용되는 Hive까지 간단히 실습해볼 예정입니다.

이론으로 배운 개념들이 실제 환경에서 어떻게 동작하는지 하나씩 확인해보며, 하둡 아키텍처에 대한 이해를 더 깊게 다져보겠습니다.

📚 공부 참고 자료

📑 1. 패스트 캠퍼스 - 한 번에 끝내는 데이터 엔지니어링 초격차 패키지 Online.

📑 2. 파일포맷 orc, parquet, avro.. 별 테이블 생성과 압축방법