Changelog Producer

В Уроке 01 мы видели, что SST-файлы в Paimon хранят системную колонку _VALUE_KIND, кодирующую тип операции: +I (insert), -U (update before), +U (update after), -D (delete). В Уроке 02 — что merge engine’ы используют эти маркеры для merge. Теперь ключевой вопрос: как Paimon генерирует корректный changelog для downstream-потребителей?

Changelog — поток CDC-событий, описывающий каждое изменение в таблице. Для стриминговых pipeline’ов это фундамент: Flink job читает changelog одной таблицы и генерирует changelog для следующей.

Зачем нужен changelog?

Проблема: не каждый changelog одинаково полезен. Для операторов агрегации (SUM, COUNT) нужен полный changelog с retraction-сообщениями: -U (вычесть старое значение) + +U (прибавить новое). Без ретракции SUM будет расти бесконечно вместо корректного обновления.

_row_kind: 4 типа CDC-событий

Paimon кодирует тип операции в колонке _row_kind (при чтении) и _VALUE_KIND (при хранении):

Полный changelog — это поток, содержащий все 4 типа событий. Неполный changelog — только +I и +U (без retraction). Тип changelog определяется режимом changelog producer.

4 режима Changelog Producer

Paimon предлагает 4 режима, отличающихся полнотой changelog и стоимостью его генерации:

none

CREATE TABLE batch_only_table (
 id BIGINT,
 value STRING,
 PRIMARY KEY (id) NOT ENFORCED
) WITH (
 'changelog-producer' = 'none'
);

Режим по умолчанию для batch-таблиц. Стриминговое чтение вернёт все записи из новых snapshot’ов, но без _row_kind. Downstream-операторы не могут различить INSERT и UPDATE — агрегации будут некорректными.

input

Когда использовать: источник уже генерирует полный CDC (Debezium, Maxwell, Canal). Нулевой overhead — Paimon не выполняет дополнительных lookup’ов.

Ограничение: если источник отправляет только INSERT-подобные события (например, обновление как новый INSERT без retraction), changelog будет неполным.

lookup

Когда использовать: источник не содержит retraction (только новые значения), но downstream нуждается в полном changelog для агрегаций. Типичный сценарий: API-запись, ETL с INSERT OVERWRITE-семантикой.

Стоимость: один lookup в LSM-дереве на каждую запись. Для write-heavy workload’ов (>100K записей/сек) overhead может быть значительным.

CREATE TABLE orders (
 order_id BIGINT,
 amount DECIMAL(10, 2),
 status STRING,
 PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
 'changelog-producer' = 'lookup',
 'merge-engine' = 'deduplicate'
);

full-compaction

Когда использовать: write-heavy workload, где lookup overhead неприемлем, но near-real-time changelog достаточен. Задержка changelog = интервал компакции.

Стоимость: нет overhead при записи. Changelog генерируется как побочный продукт компакции — “бесплатно” с точки зрения дополнительных I/O.

CREATE TABLE metrics (
 metric_id STRING,
 value DOUBLE,
 ts TIMESTAMP,
 PRIMARY KEY (metric_id) NOT ENFORCED
) WITH (
 'changelog-producer' = 'full-compaction',
 'full-compaction.delta-commits' = '3'
);

Сравнение режимов

Changelog нормализация

Некоторые downstream-операторы (например, Flink GROUP BY с UDAF) требуют нормализованный changelog: каждый UPDATE представлен как пара -U/+U, каждый INSERT — как +I, каждый DELETE — как -D. Paimon автоматически нормализует changelog при стриминговом чтении:

Streaming Pipeline Patterns

Pattern 1: CDC → Paimon → Aggregation

Pattern 2: API → Paimon → Streaming Join

Pattern 3: High-Volume → Near-RT Analytics

Сравнение с CDC в других форматах

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

1. _row_kind кодирует 4 типа CDC-событий: +I (insert), -U (update before), +U (update after), -D (delete)
2. 4 режима changelog producer: none (batch), input (проброс), lookup (LSM lookup), full-compaction (diff при компакции)
3. Полный changelog с retraction (-U/+U пары) необходим для корректных стриминговых агрегаций
4. lookup — универсальный, но дорогой; full-compaction — дешёвый, но с задержкой; input — бесплатный, но зависит от источника
5. Нормализация происходит на стороне reader — Paimon хранит raw events, а нормализует при стриминговом чтении
6. Paimon — единственный из 4 форматов (Delta, Iceberg, Hudi, Paimon) с нативным changelog producer как первоклассной концепцией