> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sifi.life/llms.txt
> Use this file to discover all available pages before exploring further.

# 왜 테이블 유지 보수가 필요한가요?과 소형 파일 문제 (Small Fil

> 이 문서는 **[레이크하우스 아키텍처](/training/03-lakehouse-architecture/overview)** 섹션의 일부입니다.

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

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, 4MB | 6개의 작은 파일       |
| **OPTIMIZE 후** | \~1GB                            | 1개의 최적화된 파일로 병합 |

### 기본 사용법

```sql theme={null}
-- 테이블 전체 최적화
OPTIMIZE catalog.schema.orders;

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

### 조건부 최적화

```sql theme={null}
-- 특정 조건의 데이터만 최적화 (파티션 프루닝)
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를 수동으로 실행하는 대신, 데이터를 쓸 때 **자동으로 적절한 크기의 파일을 생성** 하는 기능도 있습니다.

```sql theme={null}
-- 테이블 속성으로 활성화
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.autoOptimize.optimizeWrite' = 'true');
```

> 💡 **Optimized Write** 는 쓰기 시점에 파일 크기를 최적화하지만, 이미 쌓인 소형 파일은 처리하지 못합니다. 기존 파일의 압축에는 OPTIMIZE를 별도로 실행해야 합니다.

***

## VACUUM (불필요한 파일 정리)

### 동작 원리

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

### 기본 사용법

```sql theme={null}
-- 기본 실행: 7일(168시간)보다 오래된 파일 삭제
VACUUM catalog.schema.orders;

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

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

### DRY RUN (삭제 미리 확인)

실제로 삭제하기 전에, 어떤 파일이 삭제될지 미리 확인할 수 있습니다.

```sql theme={null}
-- 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.
```

### 보존 기간 설정

```sql theme={null}
-- 테이블 속성으로 기본 보존 기간 설정
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.deletedFileRetentionDuration' = 'interval 30 days');
```

> ⚠️ **주의사항**:
>
> * VACUUM 후에는 보존 기간 이전의 **타임 트래블이 불가능** 해집니다
> * 기본 보존 기간 7일보다 짧게 설정하는 것은 **강력히 권장하지 않습니다**(진행 중인 쿼리가 실패할 수 있음)
> * 7일 미만으로 설정하려면 `spark.databricks.delta.retentionDurationCheck.enabled = false`를 먼저 설정해야 합니다

***