Партиционирование

Быстрая аналитика в Selena начинается с макета таблицы, который соответствует вашим шаблонам запросов. Это руководство превращает практический опыт в четкие правила для партиционирования, помогая вам:

• Сканировать меньше данных с помощью агрессивного отсечения партиций
• Управлять задачами жизненного цикла (TTL, удаления GDPR, tiering) с помощью операций только с метаданными
• Масштабироваться плавно по мере роста количества tenant'ов, объема данных или окон хранения
• Контролируемая write amplification — новые данные попадают в "горячую" партицию; compaction происходит в исторических партициях

Держите этот совет под рукой при моделировании новой таблицы или рефакторинге старой — каждый раздел дает критерии, направленные на конкретную цель, эвристику проектирования и операционные ограничения, чтобы вы избежали дорогостоящего перепартиционирования в будущем.

Партиционирование vs. Bucketing — разные задачи

Понимание различия между партиционированием и bucketing является фундаментальным при проектировании производительных таблиц Selena. Хотя оба помогают управлять большими наборами данных, они служат разным целям:

• Партиционирование позволяет Selena пропускать целые блоки данных во время выполнения запроса, используя отсечение партиций, и обеспечивает операции жизненного цикла только с метаданными, такие как удаление старых данных или данных конкретного tenant'а.
• Bucketing, с другой стороны, помогает распределять данные по tablet'ам для параллелизации выполнения запросов и балансировки нагрузки, особенно в сочетании с hash-функциями.

Аспект	Партиционирование	Bucketing (Hash/Random)
Основная цель	Грубое отсечение данных и управление жизненным циклом (TTL, архивирование).	Мелкозернистый параллелизм и локальность данных внутри каждой партиции.
Видимость планировщику	Партиции — это объекты каталога; FE может пропускать их через предикаты.	Только предикаты равенства поддерживают отсечение bucket'ов
Операции жизненного цикла	DROP PARTITION — операция только с метаданными, идеальна для удалений GDPR, ежемесячного очищения.	Bucket'ы нельзя удалить; они изменяются только с помощью ALTER TABLE … MODIFY DISTRIBUTED BY.
Типичное количество	10^2–10^4 на таблицу (дни, недели, tenant'ы).	10–120 на партицию; Selena BUCKETS xxx настраивает это.
Обработка перекоса	Объединяйте или разделяйте партиции; рассмотрите композитную/гибридную схему.	Увеличьте количество bucket'ов, хешируйте по составному ключу, изолируйте "китов" или используйте random bucketing
Красные флаги	>100 k партиций могут привести к значительному потреблению памяти для FE	>200 k tablet'ов на BE; tablet'ы, превышающие 10 GB, могут столкнуться с проблемами compaction.

Когда следует использовать партиционирование?

Тип таблицы	Партиционирование?	Типичный ключ
Fact / event stream	Да	date_trunc('day', event_time)
Огромная dimension (миллиарды строк)	Иногда	Время или дата изменения бизнес-ключа
Маленькая dimension / lookup	Нет	Полагайтесь на hash distribution

Выбор ключа партиционирования

1. Время в первую очередь по умолчанию — если 80% запросов включают фильтр по времени, начните с date_trunc('day', dt).
2. Изоляция tenant'а — добавьте tenant_id в ключ, когда вам нужно управлять данными на основе tenant'а
3. Выравнивание с периодом хранения — поместите в ключ столбец, который вы планируете очищать.
4. Составные ключи: PARTITION BY tenant_id, date_trunc('day', dt) отсекает идеально, но создает #tenants × #days партиций. Держите ниже ≈ 100 k в общей сложности, иначе пострадают память FE и compaction BE.

Выбор детализации

Детализация PARTITION BY date_trunc('day', dt) должна корректироваться в зависимости от варианта использования. Вы можете использовать "hour", "day" или "month" и т.д. См. date_trunc

Детализация	Используйте когда	Плюсы	Минусы
Daily (по умолчанию)	Большинство BI и отчетности	Мало партиций (365/год); простой TTL	Менее точно для запросов "последние 3 часа"
Hourly	> 2 × tablet на день; всплески IoT	Изоляция горячих точек; 24 партиции/день	8 700 партиций/год
Weekly / Monthly	Исторический архив	Крошечные метаданные; легкое объединение	Более грубое отсечение

• Правило большого пальца: Держите каждую партицию ≤ 100 GB и ≤ 20 k tablet'ов/партицию с учетом replica.
• Смешанная детализация: Начиная с версии 3.4, Selena поддерживает смешанную детализацию путем объединения исторических партиций в более грубую детализацию.

Примеры рецептов

Click-stream fact (single-tenant)

CREATE TABLE click_stream (
  user_id BIGINT,
  event_time DATETIME,
  url STRING,
  ...
)
DUPLICATE KEY(user_id, event_time)
PARTITION BY date_trunc('day', event_time)
DISTRIBUTED BY HASH(user_id) BUCKETS xxx;

SaaS метрики (multi-tenant, паттерн A)

Рекомендуется для большинства SaaS рабочих нагрузок. Отсекает по времени, держит строки tenant'а совместно расположенными.

CREATE TABLE metrics (
  tenant_id INT,
  dt DATETIME,
  metric_name STRING,
  v DOUBLE
)
PRIMARY KEY(tenant_id, dt, metric_name)
PARTITION BY date_trunc('DAY', dt)
DISTRIBUTED BY HASH(tenant_id) BUCKETS xxx;

Whale tenant composite (паттерн B)

Когда необходимы DML/DDL операции для конкретного tenant'а или присутствуют крупномасштабные tenant'ы, будьте осторожны с потенциальным взрывом партиций.

CREATE TABLE activity (
  tenant_id INT,
  dt DATETIME,
  id BIGINT,
  ....
)
DUPLICATE KEY(dt, id)
PARTITION BY tenant_id, date_trunc('MONTH', dt)
DISTRIBUTED BY HASH(id) BUCKETS xxx;