Skip to main content
이 문서는 레이크하우스 아키텍처 섹션의 일부입니다.

왜 테이블 유지 보수가 필요한가요?

Delta Lake 테이블은 시간이 지나면서 두 가지 문제가 자연스럽게 발생합니다.
  1. 소형 파일 누적: 잦은 INSERT, 스트리밍 수집으로 인해 작은 파일이 수천~수만 개 쌓입니다
  2. 불필요한 파일 잔류: UPDATE/DELETE 후 이전 버전의 파일이 계속 남아 스토리지 비용이 증가합니다
OPTIMIZE 는 첫 번째 문제를, VACUUM 은 두 번째 문제를 해결합니다. 이 두 작업은 Delta Lake 테이블을 건강하게 유지하는 핵심 유지 보수 작업입니다.

소형 파일 문제 (Small File Problem)

💡 Small File Problem(소형 파일 문제) 이란 테이블에 매우 작은 크기의 파일이 대량으로 쌓이는 현상입니다. 각 파일을 열고 닫는 I/O 오버헤드가 누적되어 쿼리 성능이 심각하게 저하됩니다.

언제 발생하나요?

원인설명
Structured Streaming마이크로 배치마다 소량의 데이터를 쓰면 작은 파일이 생성됩니다
잦은 INSERT소량 데이터를 빈번하게 INSERT하면 파일이 쪼개집니다
과도한 파티셔닝파티션 수가 많으면 각 파티션의 파일이 매우 작아집니다
많은 동시 쓰기여러 작업이 동시에 테이블에 쓰면 파일이 분산됩니다
예를 들어, 1분마다 100행씩 쓰는 스트리밍 파이프라인이 있다면, 하루에 1,440개의 작은 파일 이 생성됩니다. 한 달이면 약 43,200개입니다.

OPTIMIZE (데이터 압축)

동작 원리

OPTIMIZE는 여러 개의 작은 파일을 읽어 적절한 크기의 큰 파일로 병합(bin-packing) 합니다. 기본 목표 파일 크기는 약 1GB 입니다.
상태파일 구성설명
OPTIMIZE 전1MB, 2MB, 500KB, 3MB, 100KB, 4MB6개의 작은 파일
OPTIMIZE 후~1GB1개의 최적화된 파일로 병합

기본 사용법

-- 테이블 전체 최적화
OPTIMIZE catalog.schema.orders;

-- 결과 확인
-- +-------------------------------------------+
-- | path | metrics                             |
-- +-------------------------------------------+
-- | ...  | numFilesAdded: 5, numFilesRemoved: 150, ... |
-- +-------------------------------------------+

조건부 최적화

-- 특정 조건의 데이터만 최적화 (파티션 프루닝)
OPTIMIZE catalog.schema.orders
WHERE order_date >= '2025-03-01';

-- 최근 데이터만 최적화 (자주 사용하는 패턴)
OPTIMIZE catalog.schema.orders
WHERE order_date >= current_date() - INTERVAL 7 DAYS;

Optimized Write (자동 파일 크기 최적화)

OPTIMIZE를 수동으로 실행하는 대신, 데이터를 쓸 때 자동으로 적절한 크기의 파일을 생성 하는 기능도 있습니다.
-- 테이블 속성으로 활성화
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true');
💡 Optimized Write 는 쓰기 시점에 파일 크기를 최적화하지만, 이미 쌓인 소형 파일은 처리하지 못합니다. 기존 파일의 압축에는 OPTIMIZE를 별도로 실행해야 합니다.

VACUUM (불필요한 파일 정리)

동작 원리

Delta Lake에서 UPDATE나 DELETE를 실행하면, 기존 파일은 즉시 삭제되지 않습니다. 타임 트래블과 진행 중인 쿼리를 위해 이전 버전의 파일이 보존 됩니다. VACUUM은 지정된 보존 기간보다 오래된 불필요한 파일을 영구적으로 삭제 합니다.

기본 사용법

-- 기본 실행: 7일(168시간)보다 오래된 파일 삭제
VACUUM catalog.schema.orders;

-- 보존 기간 지정: 30일
VACUUM catalog.schema.orders RETAIN 720 HOURS;

-- 보존 기간 지정: 90일
VACUUM catalog.schema.orders RETAIN 2160 HOURS;

DRY RUN (삭제 미리 확인)

실제로 삭제하기 전에, 어떤 파일이 삭제될지 미리 확인할 수 있습니다.
-- DRY RUN: 삭제될 파일 목록만 반환 (실제 삭제 안 함)
VACUUM catalog.schema.orders DRY RUN;

-- 결과 예시:
-- +--------------------------------------------+
-- | path                                       |
-- +--------------------------------------------+
-- | s3://bucket/table/part-00001-old.parquet   |
-- | s3://bucket/table/part-00002-old.parquet   |
-- +--------------------------------------------+
-- Found 2 files to delete.

보존 기간 설정

-- 테이블 속성으로 기본 보존 기간 설정
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = 'interval 30 days');
⚠️ 주의사항:
  • VACUUM 후에는 보존 기간 이전의 타임 트래블이 불가능 해집니다
  • 기본 보존 기간 7일보다 짧게 설정하는 것은 강력히 권장하지 않습니다(진행 중인 쿼리가 실패할 수 있음)
  • 7일 미만으로 설정하려면 spark.databricks.delta.retentionDurationCheck.enabled = false를 먼저 설정해야 합니다