Iceberg 이력 보존과 파일 삭제
Foundry 카탈로그가 관리하는 Iceberg 테이블의 보존은 스냅샷 만료와 고아 파일 제거로 구성합니다. 스냅샷 만료는 메타데이터의 과거 상태를 제거하고, 파일 정리는 더 이상 참조하지 않는 저장소 파일을 삭제합니다. 두 작업의 시점과 복구 가능성이 다릅니다.
스냅샷 만료 기준
Maintenance에서 Expire snapshots 작업을 구성합니다. 주요 기준은 다음과 같습니다.
| 기준 | 보호하는 스냅샷 |
|---|---|
| Minimum snapshots to retain | 나이와 관계없이 각 브랜치의 최근 최소 개수 |
| Minimum age 또는 time window to retain | 최신 스냅샷이 얼마나 더 있든 지정 기간보다 새로운 스냅샷 |
두 기준 중 하나를 만족하면 보존합니다. 최소 3개와 최소 30일로 설정했다면, 열흘 전 스냅샷은 더 최신인 것이 많아도 보존됩니다. 30일보다 오래되었더라도 최근 3개 안에 들어 있으면 보존됩니다.
이 기준은 해당 Iceberg 브랜치마다 독립 적용됩니다. 서로 겹치지 않는 두 브랜치에 최소 3개를 적용하면 서로 다른 스냅샷이 최대 6개 보호될 수 있습니다. 브랜치를 삭제하면 그 브랜치만 보호하던 스냅샷은 이후 보존 실행에서 만료 대상이 될 수 있습니다. 태그로 특정 오래된 스냅샷을 보호할 수도 있습니다.
만료한 스냅샷은 메타데이터에서 없어져 롤백이나 시간 여행에 다시 사용할 수 없습니다. 이전 스냅샷을 필요로 하는 다운스트림 증분 처리도 영향을 받을 수 있습니다.
테이블 속성과 작업 인수
프로시저에서 별도 값을 지정하지 않으면 관련 테이블 속성을 따릅니다.
| 프로시저 인수 | 생략했을 때 사용하는 속성 |
|---|---|
older_than | history.expire.max-snapshot-age-ms |
retain_last | history.expire.min-snapshots-to-keep |
Foundry의 기본 최대 스냅샷 나이는 30일이며 수정할 수 있습니다. 실제 설정과 인수 우선순위는 테이블 속성 및 작업 설정을 함께 확인합니다.
고아 파일 제거
고아 파일은 현재 테이블 메타데이터가 참조하지 않는 파일입니다. 아직 만료되지 않은 모든 스냅샷이 참조하는 파일은 고아 파일이 아닙니다. 실패한 쓰기, 메타데이터 정리 또는 이전 스냅샷 만료 뒤에 고아 파일이 남을 수 있습니다.
Foundry는 모든 Iceberg 테이블에 주기적으로 고아 파일 정리를 적용합니다. 필요하면 Maintenance에서 Remove orphan files 작업을 직접 구성할 수도 있습니다.
재해 복구를 위한 지연 삭제
Foundry는 메타데이터 정리와 물리 파일 삭제를 분리합니다. 재해 복구의 lookback 기간 안에 있는 파일은 현재 메타데이터에서 참조하지 않더라도 잠시 유지할 수 있습니다.
Expire snapshots는 스냅샷을 메타데이터에서 제거하지만 물리 파일 삭제는 나중으로 미룹니다.Remove orphan files는 사용자 지정older_than시각보다 오래되었고 재해 복구 lookback 기간도 지난 파일만 물리적으로 삭제합니다. 두 조건을 모두 충족해야 합니다.
관리형 테이블은 gc.enabled=false인 것처럼 동작하여 일반 Iceberg 삭제 작업이 재해 복구 기간 안의 파일을 지우지 못하게 합니다. 물리 파일이 남아 있다고 만료한 스냅샷을 일반 롤백이나 시간 여행으로 복원할 수 있다는 뜻은 아닙니다.
개수만으로 보존 기간을 정하지 않기
Append, Overwrite, Delete 및 컴팩션의 Replace 같은 데이터 커밋은 스냅샷을 만듭니다. 스키마만 변경하는 메타데이터 작업은 스냅샷을 만들지 않습니다. 최근 스냅샷 몇 개를 남기는 설정이 확보하는 실제 시간 범위는 데이터 및 유지보수 빈도에 따라 달라집니다.
비증분 테이블을 자주 컴팩션하면 논리적으로 같은 데이터의 스냅샷이 여러 개 생깁니다. 최근 3개만 남겨도 서로 다른 전체 데이터 버전 3개가 남는다는 뜻은 아닙니다.
증분 테이블의 최근 3개는 현재 상태와 최근 두 번의 추가 이전 상태만 보호할 수 있습니다. 각 스냅샷 자체는 전체 테이블 상태이지만, 더 오래된 전체 재빌드나 중요한 논리 버전까지 돌아갈 이력이 충분하지 않을 수 있습니다.
롤백 요구, 시간 여행 기간, 다운스트림 빌드 주기와 저장소 관리 목표를 함께 고려합니다. 소비 파이프라인이 드물게 실행된다면 마지막 처리 스냅샷에서 현재까지 변경을 계산할 충분한 이력을 남겨야 합니다.