Hadoop 생태계로 설계하는 분산 저장과 배치 분석
HDFS, YARN, MapReduce, Hive QL의 역할과 분산 데이터 처리 구조, 운영·보안·성능 설계 기준을 정리합니다.
2026-08-14 · 최초 발행 2024-04-29
HDFS에 저장하고 Hive로 읽는 배치 데이터 플랫폼
Hadoop Ecosystem은 저비용 하드웨어 클러스터에서 대규모 데이터셋을 저장·처리·분석하기 위한 오픈소스 프레임워크 집합이다. HDFS가 분산 저장소를 맡고, YARN이 클러스터 리소스를 배분하며, MapReduce가 대용량 배치 계산을 수행한다. Hive QL은 그 위의 파일을 SQL 유사 질의로 다룰 수 있게 한다.
이 조합의 중심에는 스케일아웃 확장성, 장애 허용, 저비용 하드웨어 활용이라는 요구가 있다. 각 계층은 독립적으로 보이지만, 파일 포맷과 파티션 설계가 Hive의 스캔 비용에 영향을 주고, YARN 큐 설정은 배치 작업 간 간섭을 결정한다.
저장·계산·질의를 나누는 역할
HDFS는 대용량 파일을 고정 블록으로 나눈 뒤 여러 데이터노드에 복제해 보관하는 분산 파일 시스템이다. 네임노드는 메타데이터와 블록 맵을 관리하고, 데이터노드는 실제 블록을 저장한다. 노드 장애가 발생하면 복제본을 바탕으로 자동 복구한다.
기본 복제계수는 3이며, 랙 인식 배치로 내구성과 가용성을 확보한다. 대용량 순차 IO와 append 지향 워크로드에 맞춰져 있지만, 작은 파일이 많아지면 메모리와 메타데이터 오버헤드가 커진다.
YARN은 메모리와 CPU 같은 클러스터 자원을 할당하고 큐 기반 스케줄링을 제공한다. 애플리케이션마스터(AM)와 노드매니저(NM) 구조를 통해 확장성과 장애 격리를 확보하며, 멀티 테넌시 환경에서는 큐와 리소스 한계가 격리의 기준이 된다.
MapReduce는 입력을 키-값 형태로 변환하는 Map, 데이터를 재분배하는 Shuffle/Sort, 결과를 집계하는 Reduce 단계로 구성된 배치 처리 모델이다. 불변 입력과 deterministic reduce는 재실행 가능성을 뒷받침하고, 중간 결과는 로컬 또는 임시 HDFS에 저장된다. 대기 지연보다 처리량을 우선하는 긴 배치 작업에 적합하며, 태스크 재시도와 speculative execution으로 장애 허용과 작업 완결성을 지원한다.
Hive QL은 스키마 온 리드(schema-on-read) 방식으로 HDFS 파일을 테이블로 추상화하는 데이터 웨어하우스 SQL 계층이다. 실행 엔진으로 MapReduce, Tez, Spark를 사용할 수 있으며, 여기서는 MapReduce 기반 실행을 중심으로 본다. Partition, Bucket, SerDe, UDF/UDAF를 이용해 데이터 모델링과 최적화를 수행하고, ORC·Parquet과 함께 predicate pushdown 및 statistics 기반 최적화를 적용할 수 있다.
Hive Metastore는 테이블, 파티션, 스키마 메타데이터를 관리한다. 외부 테이블은 HDFS 경로를 직접 매핑한다. Text·CSV는 호환성이 좋고, ORC·Parquet은 압축과 열 지향 처리에 강점이 있다.
데이터가 흐르고 장애를 복구하는 경로
HDFS의 데이터노드 장애는 복제 부족 상태를 만들고, 재복제는 랙 인식을 고려해 수행된다. YARN에서 태스크가 실패하면 재시도 또는 speculative execution이 이어질 수 있다. 이 흐름은 저장 계층과 계산 계층이 각자의 장애를 별도로 다루는 방식이다.
| 컴포넌트 | 성능 | 확장성 | 일관성 | 안정성 | 운영 관점 |
|---|---|---|---|---|---|
| HDFS | 순차 IO 강점, 대역폭 중심 | 노드 선형 증설 | 최종적 일관성, 단일 writer | 복제·랙 인식, 자동 재복구 | 네임노드 HA 필요, 작은 파일 관리 이슈 |
| MapReduce | 고처리량 배치, 분산 정렬 강점 | 작업·노드 수 확장 용이 | 재실행으로 결과 일관성 | 태스크 재시도·스펙큘러티브 | 잡 튜닝 필요, 지연 시간 큼 |
| Hive QL | 컬럼형+파티션으로 스캔 최소화 | 분할·버킷 병렬 처리 | 메타스토어 기반 스키마 일관성 | 외부 테이블로 장애 영향 최소화 | SQL 인터페이스, 스키마 관리 용이 |
로그, ETL, 장기 보관에 적용하는 방식
웹·모바일 로그 스트림은 Flume 또는 Kafka를 거쳐 HDFS에 적재하고, MapReduce로 전처리한 뒤 Hive ETL로 연결할 수 있다. 결과는 일 또는 시간 단위 Hive 파티션 테이블과 대시보드 집계 지표가 된다.
RDBMS 덤프나 증분 데이터는 Sqoop로 풀 또는 CDC 추출을 수행한 뒤 HDFS에 적재한다. 이후 MapReduce 정제·조인과 Hive 모델링을 거쳐 ORC 테이블 기반의 마트 계층을 만들고 BI·리포팅에 연결한다.
감사로그와 트랜잭션 기록은 HDFS WORM 정책 유사 구성 및 파티션 보존 기간 관리 대상으로 둘 수 있다. Hive 외부 테이블은 감사 조회를 제공하고, 장기보관 정책 준수에 사용된다.
HDFS 명령으로 파일과 복제 상태 확인하기
운영 환경에서는 HDFS와 YARN 데몬이 기동되어 있어야 한다. Hadoop 3.3+ (HDFS, YARN), Hive 3.1+, Java 8+, Python 3.8+ 설치 구성을 전제로 하며, Kerberos 환경에서는 kinit 완료가 필요하다. 최신 패키지와 버전은 배포판 릴리스 노트를 기준으로 확인한다.
# 디렉터리/파일 업로드
hdfs dfs -mkdir -p /data/raw/logs
hdfs dfs -put access.log /data/raw/logs/
# 복제계수 확인/변경
hdfs dfs -stat %r /data/raw/logs/access.log
hdfs dfs -setrep -w 3 /data/raw/logs/access.log
# 무결성/불완전 블록 점검
hdfs fsck /data/raw -files -blocks -locations
Streaming WordCount로 MapReduce 실행 확인하기
hadoop-streaming JAR 경로를 확인한 뒤 mapper와 reducer를 준비한다.
mapper.py
#!/usr/bin/env python3
import sys
for line in sys.stdin:
for w in line.strip().split():
if w:
print(f"{w}\t1")
reducer.py
#!/usr/bin/env python3
import sys
cur, cnt = None, 0
for line in sys.stdin:
k, v = line.strip().split("\t")
if cur is None:
cur, cnt = k, int(v)
elif k == cur:
cnt += int(v)
else:
print(f"{cur}\t{cnt}")
cur, cnt = k, int(v)
if cur is not None:
print(f"{cur}\t{cnt}")
실행은 다음과 같다.
chmod +x mapper.py reducer.py
hdfs dfs -mkdir -p /user/$USER/wc/in
hdfs dfs -put README.txt /user/$USER/wc/in/
hadoop jar $HADOOP_HOME/share/hadoop/tools/lib/hadoop-streaming-*.jar \
-D mapreduce.job.reduces=2 \
-input /user/$USER/wc/in \
-output /user/$USER/wc/out \
-mapper mapper.py \
-reducer reducer.py \
-file mapper.py -file reducer.py
hdfs dfs -cat /user/$USER/wc/out/part-*
태스크가 실패하면 YARN UI에서 원인을 확인하고, 입력 데이터가 손상된 경우 스킵 레코드 옵션(-D mapreduce.map.skip.maxrecords) 사용을 검토한다. 작은 파일이 다수라면 구조화 전 HDFS concat 또는 MapFile·SequenceFile 변환으로 합치는 방식을 고려할 수 있다.
Hive 외부 테이블과 파티션 집계
metastore 연결과 권한 부여가 완료된 상태를 전제로 한다. MapReduce 엔진을 사용할 때는 해당 설정을 적용한다.
-- 필요 시 MR 엔진 지정 (환경에 따라 Tez/Spark 권장)
SET hive.execution.engine=mr;
-- 날짜 파티션 ORC 외부 테이블
CREATE EXTERNAL TABLE IF NOT EXISTS web_access_orc (
ts string,
user_id string,
url string,
status int,
bytes bigint
)
PARTITIONED BY (dt string)
STORED AS ORC
LOCATION 'hdfs:///warehouse/web_access_orc';
-- 파티션 추가 및 데이터 로드(경로 기준)
ALTER TABLE web_access_orc ADD IF NOT EXISTS PARTITION (dt='2025-11-01')
LOCATION 'hdfs:///data/raw/logs/dt=2025-11-01';
-- 집계 예시: 일자/URL별 트래픽
SELECT dt, url, SUM(bytes) AS total_bytes, COUNT(*) AS hits
FROM web_access_orc
WHERE dt BETWEEN '2025-11-01' AND '2025-11-07'
GROUP BY dt, url
ORDER BY dt, total_bytes DESC
LIMIT 100;
동등·범위 필터에는 파티션 컬럼을 포함하고, ORC·Parquet과 ZLIB·SNAPPY를 선택한다. 테이블 및 컬럼 통계는 ANALYZE TABLE ... COMPUTE STATISTICS로 갱신한다.
보안과 운영에서 함께 관리할 제약
Kerberos 기반 인증과 Apache Ranger/Sentry를 통한 RBAC, 열·행 수준 정책은 접근통제를 강화하지만 운영 복잡성을 높인다. 전송 구간의 TLS와 저장 구간의 Transparent Encryption을 함께 적용할 때는 CPU 오버헤드와 키 관리 복잡성을 고려해야 한다. Ranger Audit, 마스킹, 토큰화는 감사와 비밀정보 보호에 쓰이며, 정책 범위는 성능 영향을 줄이도록 설계한다.
ORC·Parquet은 압축과 열 선택적 읽기에 강점이 있지만 CPU 사용량이 증가할 수 있다. CSV·Text는 호환성에 유리한 대신 스캔 비용이 커진다. 고선택도 컬럼을 파티션으로 구성하고 조인 키를 버킷팅하면 셔플 비용을 줄일 수 있지만, 파티션이 과도하면 메타데이터 부하가 증가한다. 스키마 온 리드는 유연성을 제공하는 반면 품질 관리의 사후 비용을 높일 수 있어 스키마 레지스트리 도입을 권장한다.
용량 계획에서는 블록 크기 128–256MB, 복제계수 일반 3, 헤드룸 20–30%를 기준으로 비용과 내구성의 균형을 잡는다. 작은 파일은 주기적 컴팩션, HDFS concat, Hive INSERT OVERWRITE로 병합해 NameNode 메모리를 절감한다. SLA별 YARN 큐 분리와 컨테이너 메모리·코어 상한 설정은 멀티 테넌시 간 간섭을 줄이는 수단이다.
NameNode HA는 JournalNode와 ZKFC로 구성하고, 정기 fsck 및 발열 노드 격리 절차를 마련한다. HDFS·YARN·Hive 메트릭은 Prometheus+Grafana로 수집하며 실패 잡의 자동 재시도와 알림을 연계한다.
설계 선택이 만드는 효과
노드를 선형으로 확장하면 저장 및 처리량을 늘릴 수 있고, 페타바이트급 데이터셋 처리도 가능하다. 저비용 하드웨어와 오픈소스 스택은 TCO 절감 및 라이선스 종속성 감소에 기여한다.
복제와 재시도 메커니즘은 데이터 내구성과 작업 완결성을 뒷받침한다. 컬럼형 포맷과 파티션을 함께 적용하면 워크로드에 따라 스캔 데이터를 50–95% 절감할 수 있으며, 배치 윈도우 단축 효과도 기대할 수 있다. 스키마 온 리드와 SQL 계층은 데이터 온보딩과 분석의 민첩성을 제공한다.