📘 2편. Hadoop 기본 구성도 – HDFS·YARN·Hive·Spark 운영 흐름 완전정복

금융권 빅데이터 플랫폼의 중심에는 여전히 Hadoop 에코시스템이 있다.
Cloud-Native·Lakehouse로 빠르게 이동하는 중이지만, 대규모 배치 처리, 안정성, 데이터 거버넌스 관점에서는 Hadoop 기반 아키텍처의 영향력이 여전히 크다.

이번 글에서는 금융권 실무에서 매일 사용하는
👉 HDFS · YARN · Hive · Spark
전체 구성도와 운영 흐름을 상세히 설명한다.

단순 개념 설명이 아니라, 실제 현업에서 장애가 날 때 어떤 흐름으로 분석하는지, Spark와 Hive가 데이터에 접근하는 실제 동작까지 전부 다룬다.

🏗️ 1. Hadoop 전체 구성도 (금융권 표준)

아래는 금융권 대형 Hadoop 클러스터에서 가장 많이 사용되는 구조다.

이 구조의 핵심은 다음 흐름을 이해하는 것이다.

📌 Spark/Hive 쿼리 실행 → YARN 자원할당 → HDFS 블록 읽기 → 결과 반환

🟦 2. HDFS 구조와 운영 흐름

🔹 2.1 HDFS 파일 저장 구조

HDFS는 대규모 파일을 “블록 단위”로 저장한다.
기본값은 다음과 같다.

Block Size: 256MB 또는 128MB
Replication: 3 (금융권 표준)

예시:

파일 800MB 저장 →
128MB 블록 기준 = 7개 블록 생성
각 블록이 3개의 DataNode에 복제 저장

🔹 2.2 HDFS 주요 구성요소

구성요소 역할

NameNode	메타데이터 저장(파일 이름, 블록 위치 등)
JournalNode	HA(이중화) 로그 저장
DataNode	실제 블록 데이터 저장

🔹 2.3 HDFS 운영 시 알아야 할 핵심 흐름

Spark/Hive가 파일을 읽는 과정:

Spark/Hive가 NameNode에 “파일 위치” 요청
NameNode가 “블록이 위치한 DataNode 주소 리스트” 반환
Spark Executor가 각 DataNode에서 직접 데이터 읽기
Spark의 Locality 기반으로 최적화

🔹 2.4 금융권 운영 경험에서 나온 핵심 트러블슈팅

✔️ 1) DataNode Data Locality 문제

Spark Job이 “Node-local”이 아닌 “Rack-local/Off-switch”에서 실행되면 성능 급격히 저하.

원인:

DataNode 간 데이터 불균형
특정 DataNode에만 블록 집중

해결:

hdfs balancer -threshold 5

✔️ 2) NameNode Heap 메모리 부족

조회 테이블 수가 많을수록 NameNode heap이 부족해지고
"java.lang.OutOfMemoryError" 발생.

대응:

Heap Size 32GB 이상 권장
fsimage 압축 설정 활성화

🟧 3. YARN 구조와 운영 흐름

🔹 3.1 YARN 핵심 구성

구성요소 기능

ResourceManager	클러스터 전체 자원(CPU/Memory) 스케줄링
NodeManager	노드별 Executor 실행 관리
ApplicationMaster	Spark Job의 생명주기 관리
Container	Spark Executor가 실제 실행되는 공간

🔹 3.2 Spark Job 실행 흐름

Spark-submit
   → ResourceManager에게 자원 요청
   → ApplicationMaster 시작
   → NodeManager가 Executor Container 생성
   → Executor가 DataNode에서 블록 읽기
   → Job 실행 후 종료

🔹 3.3 금융권에서 가장 많이 나는 YARN 장애 유형

✔️ 1) Queue Capacity 부족

어떤 Queue는 200%로 과부하, 어떤 Queue는 idle.

→ 금융권에서는 Queue를 “부서 단위”로 나누는 게 필수.

✔️ 2) NodeManager Heartbeat 끊김

CPU 폭주 Job or 디스크 장애로 heartbeat 누락

해결:

systemctl restart hadoop-yarn-nodemanager

✔️ 3) Container out-of-memory

Spark executor memory 부족.

Spark 옵션 수정:

--executor-memory 8g
--executor-cores 2
--driver-memory 4g

🟩 4. Hive 구성과 운영 흐름

Hive는 단순 SQL 엔진이 아니라 메타데이터 + HDFS 경로 기반의 스키마 레이어다.

🔹 4.1 Hive 구성요소

구성요소 설명

HiveServer2	클라이언트 SQL 요청 처리
Metastore	테이블 스키마 저장
Tez/Spark 엔진	쿼리 실행

🔹 4.2 Hive 쿼리 실행 흐름

사용자 SQL 요청  
   → HiveServer2  
   → Metastore에서 스키마 조회  
   → 실행 엔진(Tez/Spark)에 전달  
   → YARN 자원할당  
   → HDFS에서 데이터 스캔  
   → 결과 반환

🔹 4.3 금융권에서 자주 발생한 Hive 문제

✔️ 1) ORC/Parquet schema mismatch

컬럼 추가 후 기존 데이터와 충돌 발생.

대책:

테이블은 항상 external + partition
스키마 변경 시 테이블 recreate 권장

✔️ 2) Dynamic Partition Insert 성능 저하

1,000개 이상의 파티션 생성 시 성능 급감.

해결:

set hive.exec.dynamic.partition=true;
set hive.exec.dynamic.partition.mode=nonstrict;
set hive.exec.max.dynamic.partitions=10000;

✔️ 3) Metastore DB 락 문제

특히 MySQL 기반 Metastore에서 빈번.

해결:

Metastore DB index 최적화
대규모 ETL은 가능한 Spark SQL로 전환

🟪 5. Spark 구성과 운영 흐름

Spark는 Hadoop 플랫폼의 핵심 처리 엔진이다.

🔹 5.1 Spark 주요 컴포넌트

Driver
Executor
Task
Shuffle Service
Broadcast Manager
Storage Memory (RDD Cache 등)

🔹 5.2 Spark SQL 실행 흐름

SparkSession 생성
   → Catalyst Optimizer가 SQL 최적화
   → Logical Plan → Physical Plan 변환
   → YARN Executor 배포
   → HDFS 블록 스캔
   → Shuffle 후 Job 완료

🔹 5.3 금융권 Spark 운영에서 가장 중요한 3가지

✔️ 1) Shuffle 튜닝이 모든 성능의 핵심

Shuffle Spill 발생하면 성능 10배 느려짐.

해결:

--conf spark.sql.shuffle.partitions=200

✔️ 2) Broadcast Join 활용

소규모 dimension table은 broadcast하면 속도 5~30배 향상.

val df = large.join(broadcast(dim), "key")

✔️ 3) Cache 남용 금지

Cache 때문에 Executor 메모리 부족 → OOM 발생.

규칙:

꼭 필요한 RDD만 Cache
Stage 실행 종료 후 unpersist()

🟫 6. HDFS→YARN→Hive→Spark 운영 흐름 종합 시나리오

📌 시나리오: 금융권 신규 지표 생성 Spark Job 실행

Airflow가 Spark Job 실행
Spark-submit → YARN ResourceManager 자원 요청
ResourceManager → NodeManager에게 Executor 할당
Executor → NameNode에서 파일 위치 조회
Executor → DataNode에서 블록 읽기
Spark Job 처리 및 Shuffle
결과를 HDFS에 저장
Hive External Table로 메타데이터 인식
BI Tool(예: BI매트릭스)에서 조회

💡 7. 실전 팁 3개

팁 1) Metastore 장애는 Hive 문제가 아니라 대부분 DB 문제다.

DB Connection Pool, Table Lock, 오래된 index 문제를 먼저 확인하라.

팁 2) Spark 성능의 80%는 “파티션 관리 + Shuffle 튜닝”으로 해결된다.

팁 3) DataNode 불균형은 Spark 성능 저하의 핵심 원인이다.

주기적으로 balancer 실행하는 습관이 필요하다.

🎯 8. 마무리

이번 2편에서는 금융권 빅데이터 플랫폼의 핵심인
HDFS · YARN · Hive · Spark의 전체 구조와 운영 흐름을
현업 기준으로 완전히 정리했다.

다음 3편에서는:

📘 3편. Hadoop 운영 자동화 – 금융권 표준 스크립트 완전 공개

Spark/Hive/HDFS 운영 자동화 스크립트와
장애 대응을 위한 실전 코드들을 모두 공개한다.

🟦 금융권 하둡(Hadoop) 아키텍처 시리즈 (전 10편)

저작자표시 비영리 동일조건 (새창열림)

'빅데이터 플랫폼 & 아키텍처' 카테고리의 다른 글

6편. Hadoop + Kafka 기반 실시간 분석 아키텍처 – End-to-End 구현 가이드 (0)	2025.11.28
5편. Hadoop 운영 자동화 – 스크립트·Job Template·배포 체계 표준화 (0)	2025.11.28
4편. 금융권 Hadoop 보안 아키텍처 – 계정·권한·감사·데이터 보호 실전 가이드 (0)	2025.11.28
3편. Hadoop 운영 자동화 스크립트 모음 – 금융권 표준 실전 스크립트 공개 (0)	2025.11.28
1편. 금융권에서 하둡(Hadoop)을 왜 쓰는가? — 도입 배경과 아키텍처의 진화 (0)	2025.11.28

2편. Hadoop 기본 구성도 – HDFS·YARN·Hive·Spark 운영 흐름 완전정복