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

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

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

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

Партиционирование против группировки — разные задачи

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

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

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

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

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

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

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

Выбор гранулярности

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

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

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

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

Факт потока кликов (один арендатор)

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 (мульти-арендатор, шаблон A)

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

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;

Составной кит-арендатор (шаблон B)

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

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;