이 문서는 레이크하우스 아키텍처 섹션의 일부입니다.
왜 테이블 유지 보수가 필요한가요?
Delta Lake 테이블은 시간이 지나면서 두 가지 문제가 자연스럽게 발생합니다.- 소형 파일 누적: 잦은 INSERT, 스트리밍 수집으로 인해 작은 파일이 수천~수만 개 쌓입니다
- 불필요한 파일 잔류: UPDATE/DELETE 후 이전 버전의 파일이 계속 남아 스토리지 비용이 증가합니다
소형 파일 문제 (Small File Problem)
💡 Small File Problem(소형 파일 문제) 이란 테이블에 매우 작은 크기의 파일이 대량으로 쌓이는 현상입니다. 각 파일을 열고 닫는 I/O 오버헤드가 누적되어 쿼리 성능이 심각하게 저하됩니다.
언제 발생하나요?
| 원인 | 설명 |
|---|---|
| Structured Streaming | 마이크로 배치마다 소량의 데이터를 쓰면 작은 파일이 생성됩니다 |
| 잦은 INSERT | 소량 데이터를 빈번하게 INSERT하면 파일이 쪼개집니다 |
| 과도한 파티셔닝 | 파티션 수가 많으면 각 파티션의 파일이 매우 작아집니다 |
| 많은 동시 쓰기 | 여러 작업이 동시에 테이블에 쓰면 파일이 분산됩니다 |
OPTIMIZE (데이터 압축)
동작 원리
OPTIMIZE는 여러 개의 작은 파일을 읽어 적절한 크기의 큰 파일로 병합(bin-packing) 합니다. 기본 목표 파일 크기는 약 1GB 입니다.| 상태 | 파일 구성 | 설명 |
|---|---|---|
| OPTIMIZE 전 | 1MB, 2MB, 500KB, 3MB, 100KB, 4MB | 6개의 작은 파일 |
| OPTIMIZE 후 | ~1GB | 1개의 최적화된 파일로 병합 |
기본 사용법
조건부 최적화
Optimized Write (자동 파일 크기 최적화)
OPTIMIZE를 수동으로 실행하는 대신, 데이터를 쓸 때 자동으로 적절한 크기의 파일을 생성 하는 기능도 있습니다.💡 Optimized Write 는 쓰기 시점에 파일 크기를 최적화하지만, 이미 쌓인 소형 파일은 처리하지 못합니다. 기존 파일의 압축에는 OPTIMIZE를 별도로 실행해야 합니다.
VACUUM (불필요한 파일 정리)
동작 원리
Delta Lake에서 UPDATE나 DELETE를 실행하면, 기존 파일은 즉시 삭제되지 않습니다. 타임 트래블과 진행 중인 쿼리를 위해 이전 버전의 파일이 보존 됩니다. VACUUM은 지정된 보존 기간보다 오래된 불필요한 파일을 영구적으로 삭제 합니다.기본 사용법
DRY RUN (삭제 미리 확인)
실제로 삭제하기 전에, 어떤 파일이 삭제될지 미리 확인할 수 있습니다.보존 기간 설정
⚠️ 주의사항:
- VACUUM 후에는 보존 기간 이전의 타임 트래블이 불가능 해집니다
- 기본 보존 기간 7일보다 짧게 설정하는 것은 강력히 권장하지 않습니다(진행 중인 쿼리가 실패할 수 있음)
- 7일 미만으로 설정하려면
spark.databricks.delta.retentionDurationCheck.enabled = false를 먼저 설정해야 합니다