HDFS·S3·레이크하우스: 빅데이터 저장 계층 선택 기준

저장 계층은 워크로드와 운영 모델을 함께 결정한다

데이터 규모가 커지고 배치·스트리밍·대화형 분석이 한 환경에 모이면, 저장소 선택은 단순한 용량 문제가 아니다. 컴퓨트와 스토리지를 어떻게 결합할지, 일관성을 어디까지 보장할지, 카탈로그와 권한을 어떤 단위로 운영할지가 함께 결정된다.

HDFS, S3 객체 스토리지, 데이터 레이크하우스는 이 경계에 서로 다른 답을 제시한다.

HDFS는 데이터 지역성을 활용하는 분산 파일시스템이다

HDFS는 대용량 파일을 블록으로 나눠 여러 노드의 로컬 디스크에 분산 저장한다. 네임노드와 데이터노드로 구성되며, 컴퓨트와 스토리지가 결합된 모델이다. 데이터가 있는 위치에서 처리하는 데이터 지역성을 활용해 배치 워크로드에 적합하다.

S3는 컴퓨트에서 분리된 객체 스토리지다

S3는 키와 객체로 데이터를 관리하는 클라우드 객체 스토리지다. 사실상 무한한 확장성을 제공하며, 2020년 이후 강한 일관성을 제공한다. 컴퓨트와 스토리지가 완전히 분리돼 서버리스 워크로드를 포함한 탄력적 확장과 비용 조정에 유리하다.

레이크하우스는 객체 스토리지에 테이블 관리 계층을 더한다

데이터 레이크하우스는 객체 스토리지 위에 ACID, 스키마 진화, 타임 트래블을 제공하는 테이블 포맷 계층이다. Delta Lake, Apache Iceberg, Apache Hudi가 대표 구현이다.

배치·인터랙티브·스트리밍 처리를 하나의 스토리지와 카탈로그에서 운영할 수 있으며, 동시 업데이트와 변경 데이터 처리까지 다룰 수 있다.

결합도, 일관성, 메타데이터가 갈리는 지점

HDFS는 노드를 늘릴 때 스토리지와 컴퓨트를 함께 확장해야 한다. 반면 S3는 두 자원을 독립적으로 늘릴 수 있다. Lakehouse는 S3 같은 객체 스토리지에 테이블 계층을 얹고, 스냅샷과 매니페스트로 대규모 메타데이터를 관리한다.

일관성 모델도 다르다. HDFS는 파일 단위 append와 rename을 중심으로 하며 NameNode가 메타데이터 일관성을 관리한다. S3는 강한 일관성을 제공하지만 다중 객체 조작의 원자성은 제공하지 않는다. Lakehouse는 Optimistic Concurrency와 Commit Log를 사용해 ACID를 보장하고, 동시 업데이트 충돌을 처리하는 메커니즘을 갖춘다.

데이터 레이아웃은 공통적으로 Parquet나 ORC 같은 컬럼너 포맷과 파티션·버킷을 사용해 프루닝을 최적화한다. Lakehouse에서는 매니페스트와 스냅샷을 메타스토어(Glue/Hive Metastore), 카탈로그와 통합하며 Z-Order, 클러스터링 같은 데이터 스키핑 기능도 활용한다.

운영비 구조도 구분된다. HDFS는 디스크, 랙, 전력, 운영 인력에 따른 CapEx 부담이 이어진다. S3는 스토리지 클래스와 수명 주기 정책을 통해 TCO를 조정하기 쉬운 OpEx 모델이다. Lakehouse는 S3 스토리지 단가를 유지하면서도 테이블 관리 오버헤드를 감수하는 대신 쿼리 성능과 데이터 품질을 높인다.

보안과 거버넌스의 중심도 달라진다. HDFS는 Kerberos와 Ranger/Sentry를 기반으로 권한을 관리한다. S3는 IAM, KMS, 버킷 정책, 조직 단위 거버넌스를 사용한다. Lakehouse는 테이블·열 단위 권한, 데이터 라인리지, 감사 로그를 연계하고 Delta Sharing 또는 Iceberg REST를 통한 외부 데이터 공유에도 대응한다.

항목	HDFS	S3	Lakehouse
성능	데이터 지역성 기반 배치 고성능	대역폭/요청 수 조율 필요, 멀티파트 업로드 필수	메타데이터 프루닝·캐시로 대화형 성능 향상
확장성	노드 증설 필요, 랙 단위 확장	사실상 무한 확장	객체 스토리지 확장성 + 테이블 단위 스케일
일관성	네임노드 중심 강한 일관성	강한 일관성(최신 정보 확인 완료)	ACID 트랜잭션, 스냅샷/타임트래블
안정성	HDFS-HA 구성 필요	다중 AZ/리전 복제 옵션	테이블 레벨 롤백/재시도로 운영 안정성 상승
운영 편의	하드웨어/패치/밸런싱 부담	관리형 서비스, 정책 기반 수명주기	카탈로그·거버넌스 통합, 스키마 진화 자동화

워크로드에서 저장 계층을 고르는 기준

먼저 배치·스트리밍·대화형 처리의 비율, 동시성, 지연 허용 한계를 정한다. 이어 업데이트와 머지 빈도, 스키마 변경 속도, 보존 기간을 데이터 모델 관점에서 확인해야 한다.

온프레미스에서 대용량 배치를 처리하고 낮은 지연의 로컬 IO가 필요하다면 HDFS 중심 구성이 맞는다. 클라우드 네이티브 환경에서 탄력적 확장과 TCO 최적화가 우선이라면 S3가 적합하다. 동시 업데이트, 머지, CDC, 실시간과 대화형 처리를 함께 다뤄야 하면 Lakehouse 테이블 포맷을 선택한다.

레이아웃 설계에서는 시간·업무 키를 기준으로 파티션 키를 정하고 파일 크기를 128~1024MB 범위에서 관리한다. 멀티파트 업로드를 적용하며 Glue/Hive Metastore와 카탈로그의 일관성도 관리 대상에 포함한다.

권한은 IAM/Ranger 정책을 데이터셋·테이블·컬럼 계층으로 나누고 KMS와 키 로테이션을 연계한다. 감사와 라인리지를 수집하는 파이프라인도 함께 구성한다. 성능과 비용은 Disaggregated cache, Alluxio, 컬럼식 압축, 파일 컴팩션을 활용하고 스토리지 클래스·수명 주기·리전/AZ 복제 정책을 조정해 다듬는다.

저장부터 분석과 공유까지 이어지는 흐름

⤢✕

S3에서는 멀티파트 업로드가 실패했을 때 파트 리스트를 정리하고 재시도 지수 백오프를 적용한다. Lakehouse는 Optimistic Concurrency 충돌 시 스냅샷을 다시 계산해 재시도하며, 파일 레벨 컴팩션으로 소파일 폭증을 막는다. HDFS에서는 네임노드 페일오버 시 저널노드 일관성을 확인하고 재시도 정책을 설정한다.

환경별 구성과 운영상의 선택

온프레미스 대규모 배치 처리에는 HDFS와 YARN/Spark 기반의 주기적 ETL이 어울린다. 데이터 지역성을 높이고 네임노드 HA와 랙 인식 배치로 장애 허용성을 확보하는 구성이다.

클라우드 분석과 데이터 허브는 S3, Glue Catalog, Trino/Spark를 결합해 범용 SQL과 배치를 통합할 수 있다. 장기 보관 데이터는 스토리지 클래스 전환으로 비용을 최소화한다.

CDC와 업서트가 중심인 분석 환경에서는 Delta, Iceberg, Hudi 기반 Lakehouse가 MERGE/DELETE와 타임 트래블 기반 감사를 다루기 좋다. 배치와 스트리밍 테이블을 통합해 실시간 분석을 구성할 수 있다.

외부 협업에서는 Delta Sharing이나 Iceberg REST Catalog로 계정 간 테이블을 공유하고, 권한·마스킹 정책을 연계해 민감 데이터를 통제한다.

객체 스토리지 전환은 수명 주기와 저빈도 클래스를 활용하는 조건에서 스토리지 TCO를 3070% 절감할 수 있다. 컴퓨트를 분리하면 피크에는 탄력적으로 확장하고 비피크에는 다운스케일해 비용을 최적화할 수 있다. 컬럼너 포맷과 파티션 프루닝은 스캔 데이터를 5095% 줄이며, Lakehouse의 스냅샷과 메타데이터 최적화는 대화형 쿼리 지연을 낮춘다. ACID와 타임 트래블은 재현성과 감사를 돕고, 카탈로그 중심의 스키마 관리는 스키마 드리프트를 완화한다.

파일, 카탈로그, 권한에서 피할 문제

HDFS는 지연에 민감한 배치와 기존 온프레미스 클러스터 재활용에 유리하지만 하드웨어 운영 부담이 있다. S3는 민첩성과 비용 측면에서 강점이 있으나 메타데이터와 소파일이 급증하면 성능이 떨어질 수 있다. Lakehouse는 업데이트와 동시성에 강하지만 테이블 관리 오버헤드와 포맷·엔진 호환성을 검증해야 한다.

파일은 256~1024MB를 목표 크기로 두고 멀티파트 업로드와 정기적인 소파일 컴팩션을 적용한다. 파티션 키는 고카디널리티를 피하고 날짜와 업무 키를 함께 사용한다.

카탈로그는 Glue/HMS를 단일 진실 공급원(SSOT)으로 일원화하고, 테이블 명명 규칙과 버전 규칙을 정한다. 열 단위 권한, 마스킹, Row-level 필터를 적용하며 감사 로그 집계도 자동화한다.

저장 계층의 전환은 S3 또는 HDFS에 표준 포맷을 정착시키는 일에서 시작한다. 이후 카탈로그를 일원화하고 핵심 도메인부터 Lakehouse 테이블로 전환한 뒤, 컴팩션과 옵티마이저 튜닝을 자동화하는 순서로 확장할 수 있다.