Table Types и Merge Engines

В Уроке 01 мы разобрали LSM-дерево — фундаментальную структуру Paimon. Но LSM-дерево само по себе не отвечает на вопрос: что происходит, когда в таблице появляются две записи с одинаковым primary key? Ответ определяется двумя вещами: типом таблицы и merge engine’ом.

Paimon разделяет таблицы на два фундаментально разных типа, а для primary key таблиц предлагает 5 merge engine’ов — каждый определяет свою семантику объединения записей.

Два типа таблиц

-- Primary Key Table
CREATE TABLE orders (
 order_id BIGINT,
 user_id BIGINT,
 amount DECIMAL(10, 2),
 status STRING,
 updated_at TIMESTAMP,
 PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
 'merge-engine' = 'deduplicate',
 'sequence.field' = 'updated_at'
);

-- Append-Only Table
CREATE TABLE events (
 event_id STRING,
 user_id BIGINT,
 event_type STRING,
 payload STRING,
 event_time TIMESTAMP
) WITH (
 'bucket' = '4'
);

Sequence Field

Перед разбором merge engine’ов — критичная концепция: sequence field.

Когда две записи с одинаковым PK оказываются в разных sorted runs, как определить, какая из них новее? По умолчанию Paimon использует _SEQUENCE_NUMBER — монотонно растущий счётчик, присваиваемый при записи. Но в реальных pipeline’ах порядок записи может не совпадать с бизнес-порядком (out-of-order events).

Merge Engine: deduplicate

deduplicate — merge engine по умолчанию. При наличии нескольких записей с одинаковым PK оставляет последнюю (по sequence field):

Когда использовать: CDC из RDBMS (Debezium), полные snapshot-обновления, любой pipeline где каждое обновление содержит полную строку.

Ограничение: если обновление содержит только изменённые колонки (partial update), deduplicate перезапишет всю строку — неизменённые колонки получат значения из последнего батча, даже если это NULL.

Merge Engine: partial-update

partial-update — merge engine для колоночных обновлений. Объединяет записи по колонкам: берёт последнее не-NULL значение каждой колонки:

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

• Несколько микросервисов обновляют разные колонки одной сущности
• Wide table с десятками колонок, где каждое событие обновляет 2-3 колонки
• Real-time feature store: разные pipeline’ы вычисляют разные фичи одного пользователя

CREATE TABLE user_features (
 user_id BIGINT,
 -- Источник 1: профиль
 name STRING,
 email STRING,
 -- Источник 2: поведение
 last_login TIMESTAMP,
 session_count INT,
 -- Источник 3: платежи
 total_spent DECIMAL(10, 2),
 plan STRING,
 PRIMARY KEY (user_id) NOT ENFORCED
) WITH (
 'merge-engine' = 'partial-update',
 'sequence.field' = 'last_login'
);

Merge Engine: aggregate

aggregate — merge engine, который применяет агрегирующие функции к колонкам при merge. Каждая колонка может иметь свою функцию агрегации:

Поддерживаемые функции агрегации:

CREATE TABLE product_metrics (
 product_id STRING,
 view_count BIGINT,
 revenue DECIMAL(10, 2),
 last_seen TIMESTAMP,
 categories STRING,
 PRIMARY KEY (product_id) NOT ENFORCED
) WITH (
 'merge-engine' = 'aggregate',
 'fields.view_count.aggregate-function' = 'sum',
 'fields.revenue.aggregate-function' = 'sum',
 'fields.last_seen.aggregate-function' = 'max',
 'fields.categories.aggregate-function' = 'listagg'
);

Merge Engine: first-row

first-row — merge engine, который оставляет первую запись с данным PK и игнорирует все последующие:

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

• Дедупликация стриминговых событий (at-least-once delivery из Kafka)
• Таблица первых касаний (first-touch attribution)
• Идемпотентный append: каждый event_id записывается ровно один раз

Merge Engine: none

none — специальный merge engine, который не выполняет merge. Все версии записи с одинаковым PK сохраняются:

CREATE TABLE audit_log (
 entity_id STRING,
 action STRING,
 actor STRING,
 timestamp TIMESTAMP,
 PRIMARY KEY (entity_id, timestamp) NOT ENFORCED
) WITH (
 'merge-engine' = 'none'
);

С merge-engine = 'none' Paimon ведёт себя как append-only таблица, но с primary key — это нужно для:

• Чтение changelog-потока (все версии видны)
• Audit-логирование (каждое изменение — отдельная запись)

Сводная таблица merge engine’ов

Delete семантика

Удаление в Paimon зависит от типа таблицы:

Primary Key таблицы

Append-Only таблицы (Deletion Vectors)

Append-only таблицы не имеют PK, поэтому delete-маркеры не работают. Начиная с Paimon 1.0, поддерживаются deletion vectors:

Merge при чтении vs при компакции

Ключевой аспект: когда происходит merge?

Paimon всегда выполняет merge-on-read для корректности. Компакция — это оптимизация, сокращающая количество sorted runs и ускоряющая merge при чтении.

Ключевые выводы

1. Два типа таблиц: primary key (LSM + merge engine) и append-only (Parquet + deletion vectors)
2. 5 merge engine’ов: deduplicate (default, full-row), partial-update (column-level), aggregate (SUM/MAX/MIN), first-row (idempotent), none (все версии)
3. Sequence field — критичен для out-of-order events. Без него — merge по internal _SEQUENCE_NUMBER, который отражает порядок записи, не бизнес-порядок
4. Delete: PK-таблицы используют delete-маркеры (_VALUE_KIND=-D), append-only — deletion vectors (bitmap)
5. Merge-on-Read — Paimon всегда merge-ит при чтении для корректности; компакция — оптимизация
6. Выбор merge engine определяет семантику таблицы — это архитектурное решение, а не tuning parameter