Delta Lake Deletion Vectors — 파일을 안 지우고 마스크만 남긴다
Delta Lake Deletion Vectors 및 Spark 4.0 VARIANT 타입 공식 문서·기술 블로그 종합 (웹 리서치, 2026) — Delta Lake 공식 블로그(deletion-vectors), Microsoft Learn(deletion-vectors), Databricks 공식 블로그(introducing-open-variant-data-type) Delta Lake 공식 블로그 Deletion Vectors, Microsoft Learn Deletion vectors in Databricks
이 모듈을 다 읽으면
- Copy-on-Write와 Merge-on-Read 두 패러다임의 차이를 설명할 수 있다
- Deletion Vector가 base Parquet 파일을 다시 쓰지 않고도 행을 논리적으로 지우는 원리를 설명할 수 있다
spark-learn-55에서 다룬 Delta Lake 유지보수(OPTIMIZE/VACUUM)를 전제로, DELETE/UPDATE/MERGE가 전통적으로 파일 전체를 재작성(Copy-on-Write)하던 방식 대신, 파일은 그대로 두고 삭제 표시만 남기는 Merge-on-Read 방식을 정리한다.
전통 방식(Copy-on-Write)의 비용과 Merge-on-Read의 등장
Delta Lake는 원래 Copy-on-Write(CoW)만 지원했다 — 변경이 생길 때마다 영향받는 데이터 파일을 그 자리에서 다시 쓰는 방식이다. Deletion Vectors는 여기에 Merge-on-Read(MoR)라는 새로운 패러다임을 더한다 — DELETE/UPDATE/MERGE 같은 변경 연산이 일어나도 기존 데이터 파일(base Parquet)은 건드리지 않고, 변경 사항을 별도로 기록해뒀다가 실제로 읽을 때(read 시점) 이를 반영해 병합한다. CoW는 자주 안 바뀌고 자주 읽히는 데이터에 적합하고, MoR는 자주 바뀌고 파일 여기저기에 흩어진 데이터에 적합하다는 트레이드오프가 있다.
핵심 포인트
- Copy-on-Write(전통 방식): 변경이 생길 때마다 영향받는 파일을 그 자리에서 재작성
- Merge-on-Read(Deletion Vectors): 변경 시 base 파일은 안 건드리고 변경 사항을 별도 기록, 읽을 때 병합 — CoW는 안정적/자주 읽는 데이터, MoR는 변경이 잦고 흩어진 데이터에 적합
런타임 동작 — 파일은 안 지우고 '가리기'만 한다
DELETE/UPDATE/MERGE가 실행되면 Delta Lake는 영향받는 base Parquet 파일을 재작성하지 않는다 — 대신 어떤 행들이 논리적으로 삭제됐는지를 나타내는 Deletion Vector(압축된 비트맵, Roaring Bitmap 기반)를 생성한다. 이 벡터가 작으면 트랜잭션 로그에 인라인으로 넣어 빠르게 조회할 수 있게 하고, 크면 별도 파일로 저장한다. 쿼리 시점에는 이 Deletion Vector에 기록된 행들을 결과에서 걸러내는(마스킹) 방식으로 처리한다 — clickhouse-learn-32에서 다룬 ClickHouse의 Lightweight DELETE(_row_exists 마스크 컬럼만 갱신하고 나머지는 그대로 유지)와 개념적으로 같은 '마스크로 표시 후 지연 처리'라는 패턴이 서로 다른 시스템에서 독립적으로 등장한 것이다.
핵심 포인트
- 변경 연산 시 base 파일은 그대로 두고, 삭제된 행 위치만 담은 압축 비트맵(Deletion Vector) 생성 — 작으면 로그에 인라인, 크면 별도 파일
- 쿼리 시점에 Deletion Vector로 마스킹해 결과에서 제외 — ClickHouse Lightweight DELETE(clickhouse-learn-32)의 '마스크 후 지연 처리' 패턴과 개념적으로 동일한 접근이 서로 다른 시스템에서 독립적으로 등장
트레이드오프 — 쓰기 증폭 감소 vs 읽기 시점 오버헤드
Deletion Vectors는 변경이 잦은 테이블에서 쓰기 증폭(write amplification)을 크게 줄이고 MERGE/DELETE/UPDATE의 실행 시간을 개선한다 — spark-learn-55에서 다룬 OPTIMIZE의 압축 필요성도 이 쓰기 증폭 감소와 같은 방향의 문제의식이다. 다만 대가로 읽기 시점에 약간의 연산 오버헤드(마스킹 처리)가 추가된다. 결국 이 벡터로 표시된 행들이 물리적으로 완전히 제거되는 시점은, spark-learn-55의 OPTIMIZE/VACUUM 같은 유지보수 작업이 실제로 파일을 재작성할 때다.
핵심 포인트
- 장점: 변경이 잦은 테이블에서 쓰기 증폭 감소, MERGE/DELETE/UPDATE 실행시간 단축 / 대가: 읽기 시점 마스킹 처리로 약간의 오버헤드 추가
- 물리적 완전 제거는 spark-learn-55의 OPTIMIZE/VACUUM 같은 유지보수 작업이 실제로 파일을 재작성할 때 이뤄짐