Databricks 데이터 엔지니어

Databricks 데이터 엔지니어 2강

[Associate] Delta Lake 구조와 핵심 기능

David Lee 2026년 5월 24일 · 2분 읽기

이번 강은 레이크하우스의 저장 포맷인 Delta Lake를 다룬다.

Databricks 2강 개념도

Delta Lake는 값싼 오브젝트 스토리지에 ACID 트랜잭션·스키마·시간여행을 더한 오픈 테이블 포맷이다. Databricks의 모든 테이블은 기본적으로 Delta다.

이 강의 목표는 다음과 같다.

  • Delta 테이블이 물리적으로 어떻게 구성되는지 안다.
  • 트랜잭션 로그가 ACID를 어떻게 보장하는지 이해한다.
  • Time Travel·OPTIMIZE·VACUUM을 활용한다.

1. Delta 테이블의 구조

Delta 테이블은 하나의 디렉터리이고, 그 안에 두 가지가 있다.

  • 데이터 파일: 실제 데이터를 담은 .parquet 파일들.
  • _delta_log/: 커밋마다 남기는 JSON 트랜잭션 로그.

쿼리는 로그를 먼저 읽어 "지금 유효한 파일 목록"을 구성한 뒤 그 파일만 읽는다. 즉 로그가 테이블의 진실이다.

2. 트랜잭션 로그와 ACID

  • 쓰기가 일어나면 새 파일을 쓰고, 로그에 "이 파일을 추가/제거" 기록을 원자적으로 남긴다.
  • 커밋이 완료돼야 로그에 반영되므로, 읽는 쪽은 항상 일관된 스냅샷만 본다(격리).
  • 실패한 쓰기는 로그에 없으니 무시된다(원자성).

3. Time Travel

로그에 버전이 쌓이므로 과거 시점을 조회·복원할 수 있다.

SELECT * FROM sales VERSION AS OF 3;
SELECT * FROM sales TIMESTAMP AS OF '2026-07-01';
RESTORE TABLE sales TO VERSION AS OF 3;   -- 되돌리기
DESCRIBE HISTORY sales;                    -- 버전 이력

4. OPTIMIZE와 VACUUM

  • OPTIMIZE: 작은 파일을 큰 파일로 병합해 읽기 성능을 높인다. ZORDER BY로 자주 필터하는 컬럼을 함께 정렬한다.
  • VACUUM: 더 이상 참조되지 않는 오래된 파일을 정리한다. 기본 보존 기간(7일) 이전 파일은 삭제해 저장 비용을 줄인다. 단, 너무 짧게 잡으면 Time Travel이 불가능해진다.
OPTIMIZE sales ZORDER BY (customer_id);
VACUUM sales RETAIN 168 HOURS;

예제

예제) 스트리밍으로 초당 작은 파일이 수천 개 쌓여 쿼리가 느려졌다. 어떻게 개선하나?

해설) OPTIMIZE로 작은 파일들을 병합(compaction)해 파일 수를 줄인다. 자주 필터하는 컬럼이 있으면 ZORDER BY로 함께 정렬해 데이터 스킵을 높인다. 오래된 미참조 파일은 VACUUM으로 정리한다.

샘플 문제

문) 실수로 어제 테이블 전체를 잘못된 값으로 덮어썼다. 데이터를 되돌리는 방법은?

  • (A) VACUUM 실행
  • (B) RESTORE TABLE ... TO VERSION AS OF 로 이전 버전 복원
  • (C) OPTIMIZE 실행
  • (D) 테이블 DROP 후 재생성

정답: (B). 트랜잭션 로그 덕에 이전 버전이 남아 있어 RESTORE로 되돌릴 수 있다. (단 VACUUM으로 해당 버전 파일이 이미 정리됐다면 불가.)

정리

  • Delta 테이블 = Parquet 데이터 파일 + _delta_log 트랜잭션 로그.
  • 로그가 유효 파일 목록을 정의해 ACID(원자성·격리)를 보장한다.
  • Time Travel로 과거 버전을 조회·복원한다.
  • OPTIMIZE(파일 병합·ZORDER), VACUUM(오래된 파일 정리)로 관리한다.

다음 강에서는 데이터베이스·테이블·뷰 같은 관계형 엔티티를 다룬다.

댓글 0