Databricks

Delta Lake와 트랜잭션 로그

Delta Lake는 데이터 레이크에 신뢰성을 더하는 오픈소스 스토리지 레이어로, ACID 트랜잭션, 확장 가능한 메타데이터 처리, 배치·스트리밍 처리의 통합을 제공한다. 본질적으로는 Parquet 파일 포맷 위에 구축되며, 여기에 JSON 기반 트랜잭션 로그(Delta Log)를 더한다. 이 로그는 테이블에 가해진 모든 변경을 기록해, 동시 쓰기나 시스템 장애가 있어도 시스템이 데이터에 대한 일관된 뷰를 유지할 수 있게 한다.

ACID의 네 요소를 Delta Lake 맥락에서 보면 다음과 같다. Atomicity(원자성)는 트랜잭션이 '전부 아니면 전무'임을 보장한다 — 100개 파일을 쓰는 작업이 중간에 실패하면, 전체 커밋이 성공할 때까지 그 파일들은 리더에게 보이지 않는다. Consistency(일관성)는 테이블이 정의된 제약과 스키마에 따라 유효한 상태를 유지하도록 보장한다. Isolation(격리성)은 동시 작업을 직렬화해 여러 사용자가 동시에 읽고 써도 부분적이거나 손상된 데이터를 보지 않게 한다. Durability(지속성)는 트랜잭션 로그와 스토리지에 커밋된 쓰기가 영구적이며 시스템 장애에도 살아남음을 보장한다.

자주 쓰는 유지보수 명령: OPTIMIZE·Z-Ordering·VACUUM

잦은 소규모 쓰기가 누적되면 '작은 파일 문제(small file problem)'가 생겨 메타데이터 오버헤드로 쿼리 성능이 떨어진다. `OPTIMIZE` 명령은 작은 Parquet 파일들을 더 크고 효율적인 파일(보통 약 1GB)로 병합하는 파일 압축(compaction)을 수행해, 읽기 시 파일 열기/닫기 횟수를 줄이고 쿼리 실행 시간을 크게 단축한다.

Z-Ordering은 `OPTIMIZE`와 함께 쓰이는 데이터 레이아웃 최적화 기법으로, 관련 정보가 같은 파일에 모이도록 데이터를 재배치한다. 예를 들어 `customer_id`로 자주 필터링한다면, 그 컬럼으로 Z-Ordering하면 특정 고객의 데이터가 더 적은 수의 파일에 집중되어 '데이터 스킵(data skipping)'이 훨씬 효과적으로 동작한다 — 요청 범위의 값을 담고 있지 않은 파일 전체를 건너뛸 수 있기 때문이다.

`VACUUM` 명령은 타임트래블을 위해 보관 중이던 오래된 데이터 파일 중, 현재 버전에서 더는 참조되지 않고 보존 기간(기본 7일) 이상 지난 파일을 영구 삭제해 스토리지 비용을 절감한다. 주의할 점은 한 번 VACUUM한 파일에 의존하던 과거 버전으로는 더 이상 타임트래블할 수 없다는 것이다.

Schema Enforcement vs Schema Evolution

Schema Enforcement(스키마 강제)는 테이블에 미리 정의된 스키마와 정확히 일치하지 않는 쓰기 작업(예: 잘못된 데이터 타입이나 여분의 컬럼)을 거부해 데이터 손상을 막는다. Schema Evolution(스키마 진화)는 반대로, 새 데이터를 수용하도록 테이블 스키마를 자동으로 바꿀 수 있게 해준다. 쓰기 시 `.option("mergeSchema", "true")` 설정을 쓰면, 전체 테이블을 다시 쓰지 않고도 새 컬럼을 스키마에 추가할 수 있다. 즉 기본값은 '강제'로 데이터 품질을 지키되, 필요할 때만 명시적으로 '진화'를 허용하는 것이 Delta Lake의 설계 의도다.

참고로 Delta 테이블을 Delta 트랜잭션 로그를 이해하지 못하는 외부 엔진에서 읽어야 할 때 쓰던 '매니페스트 파일' 방식은 이 학습 프로그램의 다른 카테고리(Trino)에서 다루는 내용과 겹치므로, 여기서는 '이런 상호운용 이슈가 존재했다'는 정도만 짚고 세부 사항은 다루지 않는다.