Deletion Vectors

DELETE FROM orders WHERE order_id = 42;

Copy-on-Write 동작:
1. order_id=42가 포함된 파일(1GB)을 찾음
2. 해당 파일의 모든 행을 읽음
3. order_id=42를 제외한 나머지 행으로 새 파일(~1GB) 작성
4. 기존 파일을 "제거됨"으로 로그에 기록
5. 새 파일을 "추가됨"으로 로그에 기록

→ 1행 삭제에 ~1GB 읽기 + ~1GB 쓰기 발생

DELETE FROM orders WHERE order_id = 42;

Deletion Vectors 동작:
1. order_id=42가 포함된 파일을 찾음
2. 해당 파일에서 order_id=42의 행 번호(row position)를 확인
3. 삭제된 행 번호만 기록한 작은 DV 파일 생성 (~수 KB)

→ 1행 삭제에 메타데이터만 쓰기 발생 (데이터 파일 재작성 없음)

Parquet 파일: part-00001.parquet (100만 행)
DV 파일:      part-00001.deletion_vector.bin

비트맵 예시: 0000...0001...0000...0010...0000
             ↑              ↑
          행 #42 삭제     행 #9999 삭제

-- 사용자 입장에서는 완전히 투명합니다
SELECT * FROM catalog.schema.orders;
-- Deletion Vector에 의해 삭제 표시된 행은 자동으로 제외됩니다

UPDATE orders SET amount = 100 WHERE order_id = 42;

Deletion Vectors 활성화 시:
1. order_id=42가 있는 파일의 DV에 해당 행을 삭제 표시
2. 수정된 새 행(order_id=42, amount=100)을 새 파일에 작성

→ 기존 파일은 그대로 유지, DV + 작은 새 파일만 생성

-- 테이블 생성 시 활성화
CREATE TABLE catalog.schema.orders (
    order_id BIGINT,
    customer_id BIGINT,
    amount DECIMAL(10, 2)
) TBLPROPERTIES ('delta.enableDeletionVectors' = true);

-- 기존 테이블에 활성화
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.enableDeletionVectors' = true);

-- 호환성 문제 등으로 비활성화가 필요한 경우
ALTER TABLE catalog.schema.orders
SET TBLPROPERTIES ('delta.enableDeletionVectors' = false);

-- OPTIMIZE 실행 시 DV가 적용된 파일이 정리됩니다
OPTIMIZE catalog.schema.orders;

-- OPTIMIZE 전: Parquet 파일 + DV 파일 (논리적 삭제)
-- OPTIMIZE 후: 삭제된 행이 제거된 새 Parquet 파일 (물리적 삭제)

일반 비트맵 (100만 행, 3행 삭제):
  000000...0001...000000...0010...000000...0001...
  → 100만 비트 = 125KB (대부분이 0으로 낭비)

RoaringBitmap (동일 상황):
  Container[42] → {42}
  Container[9999] → {9999}
  Container[500000] → {500000}
  → 수십 바이트 (삭제된 행 수에 비례)

_delta_log/
  00000000000000000042.json  ← 트랜잭션 로그
    {
      "remove": {"path": "part-00001.parquet", "deletionVector": {
        "storageType": "u",       // "u" = UUID 기반 파일 참조
        "pathOrInlineDv": "ab12cd34...",  // DV 파일 UUID
        "offset": 0,
        "sizeInBytes": 48,
        "cardinality": 3           // 삭제된 행 수
      }}
    }

읽기 과정:
1. Parquet 파일 로드 (기존과 동일)
2. DV 파일 로드 (추가 I/O, 수 KB)
3. RoaringBitmap 적용하여 삭제 행 필터링 (CPU, 마이크로초 수준)

실측 오버헤드:
  - DV 없는 파일: 0ms 추가
  - DV < 1KB: ~0.1ms 추가
  - DV 1~100KB: ~0.5ms 추가
  - DV > 1MB: 1~5ms 추가 (OPTIMIZE 필요 신호)

-- version 10에서 DELETE 실행 (DV 생성)
DELETE FROM orders WHERE customer_id = 42;

-- version 9 조회 (DELETE 이전)
SELECT * FROM orders VERSION AS OF 9;
-- → customer_id = 42 행이 포함됨 (DV 적용 안 됨)

-- version 10 조회 (DELETE 이후)
SELECT * FROM orders VERSION AS OF 10;
-- → customer_id = 42 행이 DV에 의해 필터링됨

시나리오: 일 100만 행 UPDATE (전체 10억 행 테이블)

Day 1: 1,000개 파일 중 500개에 DV 생성 (파일당 평균 2,000행 삭제 표시)
Day 7: 대부분 파일에 DV 존재, 파일당 평균 14,000행 삭제 표시
Day 30: DV 크기 급증, 읽기 오버헤드 5~10% 증가

→ OPTIMIZE 없이 방치하면 읽기 성능이 점진적으로 저하됩니다

-- 테이블의 DV 상태 확인
DESCRIBE DETAIL catalog.schema.orders;
-- numFiles, sizeInBytes 외에 DV 관련 메트릭 확인

-- 파일별 DV 현황 (Delta Log 직접 분석)
SELECT
    path,
    size,
    deletionVector.cardinality AS deleted_rows,
    deletionVector.sizeInBytes AS dv_size_bytes
FROM (
    SELECT explode(add) AS (path, size, deletionVector, ...)
    FROM delta.`s3://bucket/path/_delta_log/`
)
WHERE deletionVector IS NOT NULL
ORDER BY deleted_rows DESC;

-- 대규모 MERGE 후 즉시 OPTIMIZE (읽기 성능 복원)
MERGE INTO catalog.schema.orders AS target
USING staging.schema.updates AS source
ON target.order_id = source.order_id
WHEN MATCHED THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

-- MERGE 직후 OPTIMIZE (DV를 물리적으로 반영)
OPTIMIZE catalog.schema.orders;