COW vs MOR Deep-Dive

В предыдущем уроке мы увидели, что Hudi-таблица состоит из FileGroup → FileSlice, а FileSlice может содержать только base file (COW) или base + log files (MOR). Теперь разберём побайтово, как работает запись и чтение в каждом типе.

Выбор COW vs MOR — необратимое решение, закреплённое в hoodie.properties. Это не просто «быстрее пишем / быстрее читаем» — два типа имеют принципиально разные write paths, read paths, и наборы доступных запросов.

NOTE

В Hudi 1.0 появились partial updates для MOR-таблиц — column-level merge, который обновляет только изменённые колонки. Это расширяет разрыв между COW и MOR: MOR получает преимущество не только в скорости записи, но и в эффективности хранения partial changes.

Write Path: COW (Copy-on-Write)

COW — «копирование при записи». При любом изменении (INSERT, UPDATE, DELETE) Hudi полностью перезаписывает затронутые base files:

COW Write Path: Upsert

Входящий батч (upsert)

1. Index lookup

Index: record key → FileGroup

2. Tag records

INSERT (новые)

UPDATE (существующие)

3. Merge + rewrite

Прочитать base → merge → записать новый base

4. Commit

commit instant (новые base files)

Стоимость COW upsert

Допустим, FileGroup содержит 1 млн записей (base file ~100 MB). При обновлении 10 записей из этого FileGroup:

Прочитать весь base file (100 MB read)
Найти 10 записей по record key
Заменить их значениями из батча (precombine определяет «победителя»)
Записать новый base file (100 MB write)

Итого: 200 MB I/O для обновления 10 записей. Это write amplification — цена COW.

COW Write Amplification

До upsert

upsert 10 записей

После upsert

TIP

COW write amplification можно снизить через clustering — пересортировку данных так, чтобы часто обновляемые записи оказались в одних FileGroup. Тогда upsert затрагивает меньше FileGroup → меньше перезаписей. Подробнее — в Уроке 06.

Write Path: MOR (Merge-on-Read)

MOR — «слияние при чтении». При записи Hudi не трогает base files, а дописывает дельту в log files:

MOR Write Path: Upsert

Входящий батч (upsert)

1. Index lookup + tag

Index: record key → FileGroup

2. Append to log

Append Data Block в log file

3. Deltacommit

deltacommit instant (новые log blocks)

Стоимость MOR upsert

Тот же сценарий: 10 обновлённых записей из FileGroup с 1 млн строк:

Сериализовать 10 записей в Avro (~5 KB)
Дописать Data Block в log file (~5 KB write)

Итого: ~5 KB I/O вместо 200 MB. Write amplification отсутствует. Но есть read amplification — при чтении придётся мержить log с base.

MOR: Log Accumulation

t1: создание

t2: upsert 10

t3: upsert 50

t4: compaction

HoodieLogFile: внутренняя структура

Log file — не просто append-only файл. Это структурированный контейнер из блоков:

Структура HoodieLogFile

Log Header

Data Block 1

Delete Block

Data Block 2

Schema Evolution в Log Blocks

Каждый Data Block хранит свою Avro-схему в заголовке. Это поддерживает schema evolution внутри одного log file:

Block 1: schema v1 {order_id, amount, status}
Block 2: schema v2 {order_id, amount, status, priority} ← новая колонка

При merge reader проецирует записи из разных блоков в общую target schema, заполняя отсутствующие колонки default-значениями.

NOTE

Delta Lake хранит схему в каждом commit. Iceberg — в metadata file с column-id mapping. Hudi хранит схему в каждом log block — это granular подход, который позволяет разным блокам внутри одного log-файла иметь разные схемы. Цена — дублирование schema string (~2-5 KB на блок).

Merge Strategy: как MOR сливает данные при чтении

Когда reader выполняет snapshot query на MOR-таблице, он должен смержить base file с цепочкой log files:

MOR Merge Strategy

Snapshot Query (MOR)

Читаем base file (record_key → record)

Применяем log blocks (overwrite по record_key)

Precombine (разрешаем дубликаты)

Результат: merged records

WARNING

MOR merge загружает весь base file в memory (hash map по record key). Для FileGroup с 10M записей это может потребовать гигабайты RAM. Контролируйте размер FileGroup через hoodie.parquet.max.file.size (по умолчанию 128 MB) и количество записей через hoodie.copyonwrite.record.size.estimate.

Partial Updates (Hudi 1.0)

В Hudi 1.0 MOR получил partial updates — обновление только изменённых колонок:

Partial Updates: Column-Level Merge

Стандартный upsert

Partial update (1.0)

Partial updates используют PartialUpdateAvroPayload — payload class, который при merge не перезаписывает null-колонки из log. Это идеально для wide tables (100+ колонок), где обновляются 2-3 поля.

Три типа запросов на MOR-таблице

MOR-таблица поддерживает три типа запросов — это уникальная особенность Hudi, которой нет ни в Delta Lake, ни в Iceberg:

Типы запросов на MOR-таблице

Snapshot Query

Read-Optimized Query

Incremental Query

Когда какой использовать

Сценарий	Тип запроса	Почему
Дашборд аналитика	Read-Optimized	Допустимо отставание на 1-2 часа, важна скорость
Финансовый отчёт	Snapshot	Нужна точность до последней записи
ETL-пайплайн	Incremental	Обрабатываем только новые записи
Data science exploration	Read-Optimized	Массовое сканирование, merge на каждом файле — overkill
Real-time dashboard	Snapshot + частая compaction	Частая compaction снижает merge overhead

TIP

Read-optimized query на MOR — идентичен чтению COW-таблицы: только base files, без merge. Если ваш основной use case — аналитические запросы с допустимым отставанием, MOR + read-optimized + фоновая compaction даёт вам быструю запись и быстрое чтение. Платите за compaction отдельно.

COW vs MOR: полное сравнение

COW vs MOR: Write и Read Path

Copy-on-Write (COW)

Write Path

Read Path

Merge-on-Read (MOR)

Write Path

Read Path (snapshot)

Сравнительная таблица

Параметр	COW	MOR
Write latency	Высокая (перезапись base)	Низкая (append log)
Read latency (snapshot)	Низкая (только base)	Высокая (base + merge logs)
Write amplification	Высокая	Низкая
Read amplification		Зависит от log size
Instant type	`commit`	`deltacommit`
Типы запросов	1 (snapshot = read-optimized)	3 (snapshot, read-optimized, incremental)
Compaction нужна?		(критически)
Partial updates (1.0)
Мелкие файлы	(base перезаписывается)	(log файлы, до compaction)
Подходит для	Batch, нечастые upserts	Streaming, частые upserts

Compaction: мост между MOR и COW

Compaction — это процесс превращения MOR FileSlice в COW-подобный: merge log files в base file. После compaction FileSlice содержит только base — как в COW:

Compaction Process

До compaction

compaction

После compaction

Стратегии compaction

Стратегии Compaction

Inline Compaction

Async Compaction

# Стратегия: inline или async
hoodie.compact.inline=false
# Количество deltacommits до scheduled compaction
hoodie.compact.inline.max.delta.commits=5
# Compaction strategy
hoodie.compaction.strategy=org.apache.hudi.table.action.compact.strategy.LogFileSizeBasedCompactionStrategy

WARNING

Без compaction log файлы неограниченно растут. Snapshot query на MOR с 1000 log blocks станет невыносимо медленным — merge каждого FileGroup потребует чтения всех 1000 блоков. Всегда настраивайте compaction для MOR-таблиц. Рекомендация: async compaction каждые 5-10 deltacommits.

Когда выбирать COW vs MOR

Decision Tree: COW vs MOR

Частота обновлений?

Редкие (batch) → COW

Частые → Далее…

Допустимо отставание?

→ MOR

→ MOR + compaction

Антипаттерны

DANGER

Не используйте COW для streaming ingest с частотой < 5 минут. Каждый batch будет полностью перезаписывать base files — write amplification на порядок выше, чем MOR append. При 100 FileGroup × 128 MB base = 12.8 GB перезаписи на каждый microbatch.