Bucket + Partition Design

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

Двухуровневая организация данных

Каждая таблица в Paimon делится на партиции (опционально) и бакеты (обязательно для primary key таблиц с фиксированным числом). Бакет — это отдельное LSM-дерево, которое обслуживается независимым writer thread’ом.

Почему бакеты? Primary key таблица должна уметь найти существующую запись при upsert. В Delta Lake и Iceberg это делается через полный scan или вспомогательные индексы. В Hudi — через Bloom/Record Index. Paimon использует хеширование: запись с primary key K всегда попадает в бакет hash(K) % num_buckets. Merge engine внутри бакета (LSM-дерево) обеспечивает корректное объединение.

Hash Bucket: механика назначения

Для primary key таблицы с параметром bucket = N (N > 0):

1. Вычислить partition — по partition key (если задан)
2. Вычислить bucket — hash(primary_key_columns) % N
3. Записать в LSM-дерево бакета

Детерминизм: одна и та же запись всегда попадает в один и тот же бакет. Это критично для merge engine: при повторном upsert запись order_id=12345 снова окажется в bucket-3, где LSM-дерево найдёт предыдущую версию и выполнит merge. Если бы запись попала в другой бакет — merge engine не смог бы найти предыдущую версию, и возникли бы дубликаты.

Как выбрать число бакетов?

Число бакетов bucket = N — это фиксированная настройка при создании таблицы. Изменить N без rescale операции невозможно. Два типа ошибок:

Правило: целевой размер SST-файла — 128–256 MB (по умолчанию target-file-size = 128MB). Если партиция содержит ~10 GB данных, то 10 GB / 128 MB ≈ 80 бакетов — разумная отправная точка. На практике 4–128 бакетов покрывают большинство сценариев.

Cross-Partition Update

Что происходит, когда запись меняет партицию? Пример: заказ order_id=12345 был в партиции dt=2025-03-25, но бизнес-логика переносит его в dt=2025-03-27.

Dynamic Bucket

Фиксированное число бакетов (bucket = N) требует заранее знать распределение данных. Это ограничение: новая партиция начинается пустой, а hot partition может расти непредсказуемо. Dynamic bucket решает эту проблему.

Как работает маршрутизация в dynamic bucket? Paimon поддерживает in-memory index (primary key → bucket ID). При записи: lookup в индексе → если key найден, записать в существующий бакет. Если key новый и текущий бакет полон (достиг target-row-num) — создать новый бакет.

Unaware Bucket Mode

Для append-only таблиц (без primary key) Paimon предлагает bucket = -1 с особой семантикой: unaware-bucket mode. В этом режиме нет hash-распределения — записи просто назначаются в файлы по мере поступления.

Отличия unaware-bucket от primary key таблицы:

Rescale Bucket

Что если вы выбрали bucket = 4, а данные выросли в 10x? Rescale bucket — операция изменения числа бакетов. Paimon поддерживает её начиная с версии 0.8.

Партиционирование: стратегии и pruning

Партиции в Paimon аналогичны Hive-style партициям: каждая партиция — директория в object storage. Paimon поддерживает multi-level партиционирование (PARTITIONED BY (year, month, day)).

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

Bucket pruning — уникальная особенность Paimon. Если запрос содержит фильтр по primary key, Paimon может вычислить hash(PK) % N и прочитать единственный бакет вместо всех N:

-- Point lookup: partition pruning + bucket pruning
SELECT * FROM orders
WHERE dt = '2025-03-27' AND order_id = 12345;
-- Paimon читает: 1 партиция × 1 бакет × LSM-lookup
-- Вместо: 365 партиций × 4 бакета × full scan

Стратегии партиционирования

Bucket Mode: сводная таблица решений

Подводим итоги

Двухуровневая система партиционирования Paimon — partition + bucket — решает две задачи одновременно: логическая организация данных (partition по бизнес-атрибутам) и физический параллелизм (bucket как единица LSM-дерева и writer thread).

Ключевые решения при проектировании таблицы:

1. Partition key — выбирайте атрибут с умеренной кардинальностью (дата, регион). Слишком высокая (user_id) → миллионы мелких партиций. Слишком низкая (country) → гигантские партиции без pruning.

2. Bucket mode — fixed (предсказуемый объём), dynamic (растущие данные), unaware (append-only).

3. Число бакетов — для fixed: expected_partition_size / target_file_size. Для dynamic: настройте dynamic-bucket-target-row-num.

4. Cross-partition update — дорогая операция. Проектируйте partition key так, чтобы записи редко меняли партицию.

В следующем уроке мы рассмотрим, как Paimon управляет накопленными данными: компакция, deletion vectors, z-order сортировка, data skipping и snapshot lifecycle.