Delta Lake

오픈소스!

스키마 진화

• 데이터 변경에 따라 테이블 스키마가 자동으로 조정!

스키마 강제

• 입력되는 데이터가 정의된 스키마와 일치하는지 확인

🌟시간 여행 : 아래에서 자세히 다룸

Delta Lake

버전 관리, 최적화, VACUUM 핵심 정리

Databricks 실습 중 헷갈렸던 개념들을 직접 질문하며 정리한 노트

---

1. DESCRIBE HISTORY — 트랜잭션 로그 조회

DESCRIBE HISTORY beans

Delta Lake는 테이블을 수정하는 모든 작업을 버전으로 기록한다.

version	operation
0	CREATE TABLE
1	WRITE
2	WRITE
3	UPDATE
4	UPDATE
5	DELETE
6	MERGE

• operationParameters : WHERE 조건 등 상세 파라미터 확인 가능
• operationMetrics : 추가/삭제된 행, 파일 수 확인 가능

---

2. Time Travel — 이전 버전 조회 및 복원

-- 버전으로 조회
SELECT * FROM beans VERSION AS OF 1
SELECT * FROM beans@v1   -- 단축 문법

-- 타임스탬프로 조회
SELECT * FROM beans TIMESTAMP AS OF '2024-01-01'

-- 임시 뷰로 등록
CREATE OR REPLACE TEMP VIEW pre_delete_vw AS
SELECT * FROM beans VERSION AS OF 4

-- 특정 버전으로 복원
RESTORE TABLE beans TO VERSION AS OF 5

📌 질문했던 것: CREATE OR REPLACE TEMP VIEW는 왜 트랜잭션 로그에 안 남을까?

VIEW는 실제 데이터 파일을 건드리지 않는다. "어떻게 볼지"에 대한 정의만 저장하기 때문에 Delta 트랜잭션 로그에 기록되지 않는다. TEMP 여부와 무관하게, 일반 VIEW도 마찬가지.

---

3. OPTIMIZE + Z-Order — 파일 압축 및 데이터 재배치

OPTIMIZE beans ZORDER BY (name)

이 명령 하나가 두 가지를 동시에 한다:

① Compaction (파일 압축)
작은 파일 수백 개 → 큰 파일 몇 개로 병합

② Z-Ordering (데이터 재배치)
name 기준으로 비슷한 값을 같은 파일에 모아둠

Before: 파일1 [Alice, Zoe, Bob]  파일2 [Carol, Alice, Zoe]
After:  파일1 [Alice, Alice]     파일2 [Bob, Bob]     파일3 [Carol, Carol]

→ WHERE name = 'Alice' 쿼리 시 파일 1개만 읽으면 됨 (Data Skipping)

📌 질문했던 것: 파일 개수는 어떻게 확인해?

DESCRIBE DETAIL beans
-- numFiles, sizeInBytes 컬럼 확인

OPTIMIZE 결과 출력에서 numFilesAdded, numFilesRemoved로 변화를 확인할 수 있다. 현재 실습의 beans 테이블은 numFiles: 1, sizeInBytes: 1685 (~1.6KB)로 매우 작아서 Z-Order 효과가 거의 없다. 데이터가 클수록 효과가 극적으로 나타남.

---

4. VACUUM — 오래된 파일 영구 삭제

-- 삭제될 파일 미리 보기 (실제 삭제 안 함)
VACUUM beans RETAIN 0 HOURS DRY RUN

-- 실제 삭제
VACUUM beans RETAIN 0 HOURS

📌 질문했던 것: DRY RUN이 정확히 뭐야?

"실제로 실행하지 말고, 뭘 할지만 보여줘"라는 뜻. 삭제 대상 파일 목록만 출력한다. RETAIN 0 HOURS는 현재 버전 외 모든 파일을 삭제하는 위험한 옵션이라 DRY RUN으로 먼저 확인하는 것이 중요하다.

기본 보존 기간은 7일이며, 아래 설정으로 우회 가능 (프로덕션에서는 주의):

SET spark.databricks.delta.retentionDurationCheck.enabled = false;
SET spark.databricks.delta.vacuum.logging.enabled = true;

---

5. VACUUM 후 Time Travel이 불가능한 이유

SELECT * FROM beans@v1
-- FileReadException: 파일 없음 → 에러 발생

📌 질문했던 것: VACUUM 해도 DESCRIBE HISTORY는 보이는 이유?

VACUUM은 파일을 지우는 것이지, 트랜잭션 로그를 지우는 게 아니다.

beans/
├── _delta_log/          ← 로그 파일 (VACUUM이 건드리지 않음)
│   ├── 00000.json       ← "v0: 테이블 생성"
│   └── 00001.json       ← "v1: 데이터 추가"
│
└── part-0001.parquet    ← 실제 데이터 파일 (VACUUM이 삭제)

• DESCRIBE HISTORY → 로그를 읽는 것 → VACUUM 후에도 보임
• beans@v1 조회 → 실제 파일을 찾는 것 → VACUUM 후 FileReadException

즉, VACUUM 후 beans@v1에서 에러가 나는 것이 정상이다. 에러가 나야 VACUUM이 제대로 된 것.

---

정리: 각 명령어 역할 한눈에 보기

명령어	역할	로그 기록
DESCRIBE HISTORY	트랜잭션 기록 조회	-
SELECT ... VERSION AS OF	이전 버전 조회	-
RESTORE TABLE	이전 버전으로 복원	✅
OPTIMIZE ZORDER BY	파일 압축 + 데이터 재배치	✅
VACUUM DRY RUN	삭제 대상 미리보기	-
VACUUM	오래된 파일 영구 삭제	✅ (설정 시)