_Originally published by the Logic42 Sovereign Engineering Practice at [https://logic42.ai/articles/small-file-lakehouse-explosion-iceberg-compaction].*

작은 파일로 인한 레이크하우스 폭발: 스트리밍이 Iceberg를 파괴하는 이유

작은 파일로 인한 레이크하우스 폭발(small-file lakehouse explosion)이란 고빈도 스트리밍 파이프라인이 수천 개의 작은 Parquet 파일을 Apache Iceberg 또는 Delta 테이블에 직접 쓰는 운영상의 위기를 말합니다. 데이터 수집(data ingestion)이 30초 커밋 주기(commit cycles)로 실행되면, 테이블 메타데이터 트리(table metadata trees)가 기가바이트 단위로 부풀어 올라 Trino나 DuckDB와 같은 분산 쿼리 엔진이 파일 검색 과정에서 시간 초과(time out)를 일으키게 됩니다.

2025년과 2026년에 걸쳐 데이터 엔지니어링 팀들은 실시간 레이크하우스를 구축하기 위해 노력했습니다. 비즈니스 이해관계자들은 운영 대시보드 및 에이전트 분석(agentic analytics)을 위해 즉각적인 데이터 신선도(data freshness)를 요구했습니다. 팀들은 시간 단위 배치 ETL 작업(batch ETL jobs)을 실행하는 대신, Apache Flink나 Kafka를 클라우드 객체 스토리지에 직접 연결했습니다. 그리고 30초마다 데이터를 커밋했습니다.

작은 데이터셋으로 구성된 스테이징 환경에서는 실시간 스트리밍이 매우 좋아 보입니다. 이벤트를 하나 푸시하면 몇 초 후에 SQL 쿼리에 나타납니다. 하지만 프로덕션 환경에서는 지속적인 커밋이 수십 개의 파티션에 걸쳐 작은 120 KB Parquet 조각들을 눈사태처럼 만들어냅니다. 두 달 안에, 깨끗한 테이블에는 4,000,000개가 넘는 개별 객체가 쌓이게 됩니다.

왜 작은 Parquet 파일들이 레이크하우스 쿼리 성능을 파괴할까요?

작은 Parquet 파일들은 분산 쿼리 엔진이 컬럼 값(column values)을 스캔하는 대신 객체 스토리지 메타데이터를 읽는 데 실행 시간의 90%를 사용하기 때문에 쿼리 성능을 저하시킵니다. Trino나 ClickHouse 같은 엔진이 쿼리를 시작하면, 수천 개의 Iceberg 매니페스트 파일(manifest files)을 구문 분석하고, 객체 URL을 해석하며, 모든 작은 파일을 위해 개별 HTTP GET 요청을 발행해야 합니다.

비압축된 파일 수가 증가함에 따라 쿼리 지연 시간과 클라우드 스토리지 비용이 어떻게 상승하는지 살펴보세요:

저희는 이 상황을 목격했습니다. 한 금융 고객이 Iceberg 레이크하우스로 지속적인 Flink 수집(ingestion)을 실행했습니다. 엔진이 결국 포기했습니다. 문제는 스토리지 엔진 자체가 아닙니다. 문제의 원인은 데이터 수집 패턴에 있습니다.

레이크하우스 파편화의 세 가지 숨겨진 비용

관리되지 않은 스트리밍 파일은 단순히 임시(ad-hoc) 쿼리를 느리게 만들 뿐입니다. 이는 세 가지 핵심 차원에서 전체 데이터 플랫폼을 약화시킵니다.

1. 객체 스토리지 메타데이터 잠금 (Object Storage Metadata Lockup)

AWS S3나 Google Cloud Storage와 같은 클라우드 객체 저장소는 계층적 POSIX 파일 시스템이 아닙니다. 엔진이 파티션 내의 500,000개 파일을 나열(list)할 때, 수백 개의 메타데이터 마커를 페이지네이션(paginate)해야 합니다. 매니페스트 파일(manifest file)을 읽는 데 걸리는 시간이 실제 SQL 필터를 평가하는 시간보다 30배 더 오래 걸립니다.

2. 벡터화된 컬럼 프루닝 손실 (Loss of Vectorized Columnar Pruning)

Parquet은 딕셔너리 인코딩(dictionary encoding)과 컬럼 압축(columnar compression)을 통해 탁월한 성능을 달성합니다. 512 MB 파일에서는 컬럼 청크가 효율적으로 압축되며, 최소/최대 행 그룹 통계(min/max row group statistics)를 통해 리더가 전체 데이터 블록을 건너뛸 수 있게 합니다. 하지만 120 KB 파일의 경우, 헤더와 푸터가 바이트 카운트의 40%를 차지하여 압축 이점을 완전히 제거합니다.

3. 매니페스트 트리 트래싱 및 커밋 충돌 (Manifest Tree Thrashing and Commit Conflicts)

모든 스트리밍 마이크로 배치(micro-batch)는 새로운 테이블 스냅샷을 생성합니다. 여러 Flink 워커가 최적화되지 않은 컴팩션 작업이 실행되는 동안 동시 커밋(concurrent commits)을 시도하면, Iceberg의 낙관적 동시성 제어(optimistic concurrency control)가 커밋 충돌(commit collisions)을 유발합니다. 배치들이 실패하고, 이는 Kafka 브로커에 역압력(backpressuring)을 가하게 됩니다.

아키텍처 비교: 직접 스트리밍 대 빈-패킹 컴팩션

실시간 가시성을 희생하지 않으면서 서브초 단위의 쿼리 성능을 유지하려면, 스트리밍 수집 버퍼(ingest buffers)와 쿼리 가능한 분석 파티션(queryable analytical partitions)을 분리해야 합니다.

Logic42 아키텍처 수정안: 비동기 빈-패킹 및 Z-Order 정렬

우리의 Build-Transfer-Operate 방식에 따라, 우리는 활성 리더를 잠그지 않으면서 스트리밍 조각(streaming fragments)을 투명하게 통합하는 비동기 컴팩션 워커 파이프라인을 배포합니다.

# Logic42 Sovereign Lakehouse: 스케줄링된 Iceberg 컴팩션 러너
from pyiceberg.catalog import load_catalog
from pyiceberg.table import Table
...

Sovereign Lakehouse 수집을 위한 세 가지 규칙

1. 수집 버퍼와 분석 골드 테이블 분리:
   고속 스트리밍 이벤트를 추가 전용(append-only) 원시 버퍼 또는 임시 스테이징 파티션으로 라우팅하세요. 핵심 프로덕션 데이터셋에 30초 단위의 커밋을 직접 작성하지 마십시오.

2. 지속적인 빈-패킹 자동화:
   64MB보다 작은 파일을 최적의 512MB 컬럼 청크(columnar chunks)로 지속적으로 통합하는 독립적인 Spark 또는 PyIceberg 워커를 실행하세요. 이를 통해 Trino 파일 계획 시간을 50ms 미만으로 유지할 수 있습니다.

3. 스냅샷 계보 공격적 정리:
   테이블 스냅샷은 롤백 SLA가 요구하는 기간만큼만 보관하세요. 72시간보다 오래된 고아 매니페스트(orphan manifests)를 삭제하면 private MinIO 또는 AWS S3 버킷에서 테라바이트 규모의 유령 저장 공간을 회수할 수 있습니다.

작은 파일 폭발을 관리하지 못하면, 실시간 레이크하우스는 자체 메타데이터 무게에 무너질 것입니다. 저희는 귀사의 경계 내부에 결정론적 스토리지 기판(deterministic storage substrates)을 직접 구축하여, 데이터 수집 규모와 관계없이 쿼리가 빠르게 실행되도록 합니다.

인터랙티브 엔터프라이즈 데이터 및 AI 아키텍처 성숙도 지수 측정하기

운영 환경에서 이러한 아키텍처 병목 현상을 평가하고 계십니까? 단 3.5분 만에 스택을 벤치마킹하고, 즉각적인 Stage 1 블로커 감지 기능과 다운로드 가능한 이사회용 PDF 보고서를 받아보세요:
👉 Logic42에서 진단 시작하기 (https://logic42.ai/assessments/data-ai-maturity)