RESTORE TABLE — Time Travel은 '보기'만, RESTORE는 실제로 '되돌리기'
Delta Lake RESTORE TABLE 및 Spark Aggregator API 공식 문서 종합 (웹 리서치, 2026) — Databricks 공식 문서(sql/language-manual/delta-restore), Apache Spark 공식 Javadoc(org.apache.spark.sql.expressions.Aggregator) Databricks 공식문서 RESTORE
이 모듈을 다 읽으면
- RESTORE TABLE이 spark-learn-68의 Time Travel(조회만 가능)과 근본적으로 어떻게 다른지 설명할 수 있다
- RESTORE가 메타데이터 전용 작업이라는 것과, VACUUM이 여기에 주는 같은 제약을 설명할 수 있다
spark-learn-68에서 다룬 Time Travel(VERSION/TIMESTAMP AS OF로 과거 스냅샷을 '조회'만 함)을 전제로, 그 과거 상태로 테이블 자체를 실제로 되돌리는 RESTORE TABLE 명령을 정리한다.
조회 vs 되돌리기 — Time Travel과의 근본적 차이
spark-learn-68의 Time Travel(VERSION AS OF/TIMESTAMP AS OF)은 과거 시점의 테이블을 '읽어보는' 임시적 조회일 뿐, 테이블의 현재 버전 자체는 전혀 바뀌지 않는다. RESTORE [TABLE] table_name [TO] TIMESTAMP AS OF... 또는 VERSION AS OF...는 이와 달리 테이블을 그 과거 상태로 영구적으로 되돌린다 — 이후의 변경사항들을 실질적으로 취소하는 효과를 낸다는 점에서 Time Travel의 '조회'와 RESTORE의 '되돌리기'는 근본적으로 다른 작업이다.
핵심 포인트
- Time Travel(spark-learn-68): 과거 시점을 조회만 함 — 테이블의 현재 버전은 전혀 안 바뀜
- RESTORE [TABLE] ... TO VERSION/TIMESTAMP AS OF ...: 테이블을 그 과거 상태로 영구적으로 되돌림 — 이후 변경사항을 실질적으로 취소하는 효과
메타데이터 전용 작업 — 과거 이력 자체는 안 지운다
RESTORE는 메타데이터 전용(metadata-only) 작업이다 — 트랜잭션 로그를 갱신해서 '어떤 파일들을 읽을 것인가'를 그 과거 버전 기준으로 재설정할 뿐, 히스토리 자체를 지우지는 않는다. 즉 RESTORE로 되돌린 뒤에도 원래 있던 버전 히스토리는 그대로 남아있어, 필요하면 RESTORE 자체를 다시 취소(그 전 버전으로 또 RESTORE)할 수도 있다.
핵심 포인트
- RESTORE는 트랜잭션 로그를 갱신해 읽을 파일 집합을 재설정하는 메타데이터 전용 작업 — 히스토리 자체는 안 지움
- RESTORE 이후에도 버전 히스토리가 남아있어 RESTORE 자체를 다시 취소(재-RESTORE)하는 것도 가능
VACUUM과의 같은 제약 — spark-learn-68의 함정이 여기도 적용된다
spark-learn-68에서 다룬 VACUUM의 제약이 RESTORE에도 그대로 적용된다 — VACUUM이 어떤 버전의 데이터 파일을 이미 지워버렸다면, 그 버전으로는 Time Travel도 RESTORE도 둘 다 불가능하다. VACUUM은 최신 버전이 더 이상 필요로 하지 않는 파일을 디스크에서 지워 저장 비용을 줄이는 작업이라, VACUUM을 실행하고 나면 그 이전 버전들로 되돌아갈 수 있는 선택지 자체가 사라진다는 걸 알아야 한다 — RESTORE를 나중에 쓸 가능성이 있다면 VACUUM 보존 기간을 신중히 잡아야 하는 이유가 여기 있다.
핵심 포인트
- spark-learn-68에서 다룬 VACUUM 제약이 그대로 적용 — VACUUM이 지운 버전의 파일로는 Time Travel도 RESTORE도 불가능
- RESTORE를 나중에 쓸 가능성이 있다면 VACUUM 보존 기간을 신중히 잡아야 함