저번 포스팅에서는, 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. 실제 하둡 관련 면접 질문 사례 모음

❓ 질문: 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에서 작업 실행 전에 모든 노드에 동일한 파일을 미리 복사해두는 기능입니다. 이때 복사된 파일은 읽기 전용(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 비용이 발생하므로 매우 비효율적입니다.

🐘 5. 점차 사라지는 하둡, 그러나 하둡을 얕게라도 공부해야 하는 이유

✏️ 결론

📚 공부 참고 자료

https://ngela.tistory.com/111