Row-level операции: CoW, MoR, deletion vectors

В уроке 2 мы разобрали, что каждый коммит создаёт новый snapshot, а данные в файлах иммутабельны. Но как тогда работают DELETE, UPDATE и MERGE INTO, если файлы нельзя модифицировать?

Iceberg предлагает три стратегии: Copy-on-Write (V1+), Merge-on-Read с delete files (V2), и Deletion Vectors (V3). Каждая — с разным балансом между стоимостью записи и скоростью чтения.

Зачем нужны row-level deletes?

Data lakehouse — не только append. Реальные сценарии требуют удаления и обновления строк:

Во всех случаях проблема одна: Parquet-файлы иммутабельны. Нельзя “зайти” в файл и изменить одну строку.

Copy-on-Write (CoW)

Простейшая стратегия, доступная с V1:

Идея: чтобы удалить/обновить строку в файле, перезаписать весь файл без этой строки (или с обновлённым значением).

Характеристики CoW:

Merge-on-Read (MoR) — V2

V2 спецификация добавила delete files — специальные файлы, которые описывают удалённые строки без перезаписи data files.

Идея: вместо перезаписи — записать маленький файл-маркер “эти строки удалены”. При чтении — merge data file с delete file и отфильтровать удалённые строки.

Position delete files

Position delete file — Parquet-файл с двумя колонками:

file_path (string) | pos (long)
---------------------------------
"s3://.../data-001.parquet" | 42
"s3://.../data-001.parquet" | 1337
"s3://.../data-001.parquet" | 99999

Каждая запись — координата (файл, позиция строки в файле). Позиция — 0-based индекс строки в Parquet row group.

Equality delete files

Equality delete file — Parquet-файл с значениями предикатов:

customer_id (long)
------------------
42
73

Все строки во всех data files, где customer_id = 42 или customer_id = 73, считаются удалёнными.

Sequence numbers — корректность при конкурентных записях

Как отличить строку, добавленную ДО delete от строки, добавленной ПОСЛЕ? Без этого delete мог бы удалить строки из будущих INSERT-ов.

V2 использует sequence numbers:

Snapshot 5 (seq=5): INSERT → data-001.parquet
Snapshot 6 (seq=6): DELETE customer_id=42 → equality-delete-001.parquet (seq=6)
Snapshot 7 (seq=7): INSERT → data-002.parquet (содержит customer_id=42!)

Equality delete с seq=6 применяется только к файлам с seq ≤ 6. Файл data-002.parquet с seq=7 — не затронут, даже если содержит customer_id=42.

Deletion Vectors (V3)

V3 спецификация (ратифицирована в июне 2025) заменяет position delete files deletion vectors — компактными бинарными битмапами.

Проблема position deletes в V2

Position delete files — Parquet-файлы с координатами. При активных UPDATE/DELETE:

1. Proliferation: каждая операция создаёт новый position delete file. После 1000 UPDATE-ов — 1000 delete files для одного data file
2. Read overhead: при чтении нужно загрузить и merge все 1000 delete files
3. Нет compaction гарантий: спецификация V2 не требовала от writers объединять delete files. Многие не делали — таблицы деградировали

V3 решение: Roaring bitmaps в Puffin files

Формат deletion vector

1. Roaring bitmap: компактная структура для разреженных множеств целых чисел. Каждый бит = одна строка: 0 = жива, 1 = удалена
2. Puffin file: бинарный контейнер (аналог Parquet footer для blob-ов). Один Puffin-файл может содержать deletion vectors для нескольких data files
3. Правило одного DV: в snapshot максимум один deletion vector на data file. Writer обязан merge новых deletes с существующим DV

data-001.parquet → file-001.puffin [DV: bitmap, positions 42, 1337, 99999]
data-002.parquet → file-001.puffin [DV: bitmap, positions 7, 15, 28]
data-003.parquet → (нет DV — все строки живы)

Read path с deletion vectors

1. Открыть data file → начать сканировать строки
2. Загрузить DV для этого data file (один blob из Puffin)
3. Для каждой строки: проверить бит в bitmap
 - бит = 0 → строка жива, вернуть
 - бит = 1 → строка удалена, пропустить

Roaring bitmap — O(1) проверка per-bit (lookup по контейнеру + bit test). Минимальный CPU overhead.

Совместимость с V2

• V3 deprecates position delete files — writers не должны создавать новые position delete files в V3 таблицах
• Существующие position deletes валидны — при upgrade V2→V3 старые position delete files читаются
• Writer обязан при обновлении deletes для data file: прочитать существующие position deletes + DV → записать объединённый DV

UPDATE и MERGE INTO

UPDATE и MERGE INTO — комбинация DELETE + INSERT:

UPDATE

UPDATE orders SET status = 'cancelled' WHERE order_id = 42;

MERGE INTO

MERGE INTO target USING source
ON target.id = source.id
WHEN MATCHED AND source.op = 'delete' THEN DELETE
WHEN MATCHED AND source.op = 'update' THEN UPDATE SET *
WHEN NOT MATCHED THEN INSERT *;

MERGE INTO — основная операция для CDC. Один statement обрабатывает delete, update и insert:

1. Join source и target по ключу
2. Matched + delete → position delete / DV для строки
3. Matched + update → position delete / DV + INSERT новой строки
4. Not matched → INSERT
5. Всё в одном атомарном snapshot

CoW vs MoR vs Deletion Vectors

Количественное сравнение

Конфигурация стратегии

В Spark:

-- Установить MoR для DELETE/UPDATE
ALTER TABLE orders SET TBLPROPERTIES (
 'write.delete.mode' = 'merge-on-read',
 'write.update.mode' = 'merge-on-read',
 'write.merge.mode' = 'merge-on-read'
);

-- Или CoW
ALTER TABLE orders SET TBLPROPERTIES (
 'write.delete.mode' = 'copy-on-write',
 'write.update.mode' = 'copy-on-write',
 'write.merge.mode' = 'copy-on-write'
);

Row lineage (V3)

V3 добавляет row lineage — метаданные для отслеживания изменений на уровне строк:

• _row_id — уникальный идентификатор строки (присваивается при записи)
• _last_updated_sequence_number — sequence number snapshot-а, в котором строка была последний раз изменена

Это позволяет:

• Incremental CDC: SELECT * FROM orders WHERE _last_updated_sequence_number > 5 — все изменённые строки с snapshot 5
• Audit trail: точная история изменений каждой строки
• Efficient replication: только изменённые строки, без полного scan

-- Создать V3 таблицу с row lineage
CREATE TABLE orders (
 order_id BIGINT,
 amount DECIMAL(10,2),
 status STRING
) USING iceberg
TBLPROPERTIES ('format-version' = '3');

-- Все строки с изменениями после snapshot 5
SELECT * FROM orders WHERE _last_updated_sequence_number > 5;

Сравнение с Delta Lake

Итоги

1. Copy-on-Write — перезапись файлов; дорогая запись, дешёвое чтение. Для bulk/редких обновлений
2. Position deletes (V2) — координаты (file_path, pos) в Parquet; дешёвая запись, растущий read overhead
3. Equality deletes (V2) — предикаты (customer_id=42); мощные для GDPR, но дорогие при чтении (per-row check)
4. Sequence numbers — защита от ложного удаления будущих INSERT-ов; обязательны в V2+
5. Deletion vectors (V3) — Roaring bitmaps в Puffin files; O(1) per-row check, writer обязан merge, один DV per data file
6. Row lineage (V3) — _row_id + _last_updated_sequence_number для incremental CDC и audit
7. UPDATE = DELETE + INSERT, MERGE INTO — комбинация в одном атомарном snapshot