← 학습 카테고리

Learn

Spark

84개 모듈 · 현재 55번째

Spark 모듈 55/84 spark-learn-55

Delta Lake 유지보수 — OPTIMIZE/ZORDER로 압축·정렬, VACUUM으로 청소

Delta Lake OPTIMIZE/VACUUM 및 pandas API on Spark 공식 문서 종합 (웹 리서치, 2026) — Delta Lake 공식 문서(optimizations-oss.html, delta-utility.html) + Apache Spark 공식 문서(migration_guide/koalas_to_pyspark.html) Delta Lake 공식 문서 Compaction and Z-Ordering, Utility commands

이 모듈을 다 읽으면

  • OPTIMIZE의 압축(bin-packing)과 ZORDER BY의 역할이 서로 다르다는 것을 설명할 수 있다
  • VACUUM의 보존 기간(retention)을 너무 짧게 설정하면 왜 위험한지 설명할 수 있다

spark-learn-46에서 다룬 Spark의 Delta Lake 카탈로그 연동·MERGE INTO를 전제로, 시간이 지나며 계속 쌓이는 작은 파일들과 더 이상 쓰이지 않는 옛 파일들을 정리하는 두 가지 유지보수 명령 OPTIMIZE와 VACUUM을 정리한다.

OPTIMIZE — 작은 파일을 압축(bin-packing)

OPTIMIZE 명령은 여러 개의 작은 파일을 더 큰 파일로 병합(compaction)해, 이후 읽기 쿼리의 속도를 개선한다. 이 압축 연산은 멱등적(idempotent)이어서, 이미 압축이 끝난 테이블에 OPTIMIZE를 다시 실행해도 추가로 바뀌는 게 없다 — 즉 반복 실행해도 안전하다.

핵심 포인트

  • OPTIMIZE는 작은 파일들을 더 큰 파일로 압축(bin-packing)해 읽기 쿼리 속도를 개선
  • 압축 연산 자체는 멱등적 — 이미 압축된 테이블에 다시 실행해도 추가 변화 없음

ZORDER BY — 관련 데이터를 같은 파일에 모아 데이터 스키핑을 강화

OPTIMIZE events ZORDER BY (eventType)처럼 ZORDER BY 절을 함께 쓰면, 지정한 컬럼(들) 기준으로 서로 관련된 값들을 같은 파일 집합에 모아 재배치한다 — 이렇게 관련 데이터가 물리적으로 모여 있으면, Delta Lake의 데이터 스키핑 알고리즘이 쿼리와 무관한 파일을 훨씬 많이 걸러낼 수 있어 실제로 읽어야 하는 데이터량이 크게 줄어든다. 다만 압축과 달리 ZORDER BY는 멱등적이지 않다 — 실행할 때마다 해당 파티션 안의 기존 파일과 새 파일을 다시 뒤섞어 재정렬하므로, 반복 실행이 매번 추가 비용을 발생시킨다는 점을 감안해야 한다.

핵심 포인트

  • ZORDER BY(컬럼)로 관련 데이터를 같은 파일 집합에 모아 데이터 스키핑 효율을 크게 높임
  • OPTIMIZE의 압축과 달리 ZORDER BY는 멱등적이지 않음 — 실행할 때마다 파티션 내 파일을 다시 재정렬해 매번 추가 비용 발생

VACUUM — 더 이상 참조되지 않는 옛 파일 청소, 그리고 보존기간의 함정

VACUUM은 Delta 테이블의 트랜잭션 로그에서 더 이상 참조되지 않으면서 동시에 보존 기간(기본 7일)보다 오래된 파일들을 실제로 디스크에서 삭제한다. 여기서 핵심 위험은 보존 기간을 '동시에 그 테이블에 접근 중인 가장 오래 걸리는 트랜잭션이나 스트리밍 컨슈머의 지연 시간'보다 짧게 잡으면 안 된다는 점이다 — 만약 그보다 짧게 잡으면, VACUUM이 아직 진행 중인 읽기·쓰기 작업이 참조하고 있는 파일을 지워버려 동시 실행 중인 리더가 실패하거나 테이블이 손상될 수 있다. 이 때문에 Delta Lake는 지나치게 짧은 보존 기간으로 VACUUM을 실행하려 하면 기본적으로 막는 안전장치를 두고 있으며, 이를 우회하려면 spark.databricks.delta.retentionDurationCheck.enabled를 false로 명시적으로 꺼야 한다.

핵심 포인트

  • VACUUM은 참조 안 되면서 보존기간(기본 7일)보다 오래된 파일을 실제로 삭제
  • 보존기간이 동시 실행 중인 가장 긴 트랜잭션/스트리밍 지연보다 짧으면 진행 중인 리더가 실패하거나 테이블 손상 위험 — 기본 안전장치가 이를 막고, 우회하려면 spark.databricks.delta.retentionDurationCheck.enabled=false 명시 필요