Бакетирование¶

Краткое практическое руководство по выбору между Hash Bucketing и Random Bucketing в StarRocks: как они работают, их компромиссы и рекомендуемые сценарии применения.

Быстрое сравнение¶

Hash Bucketing¶

Как это работает¶

Строки распределяются по таблетам хешированием одного или нескольких столбцов. Число таблет фиксируется после создания, если не изменить вручную.

Требования¶

• Нужно заранее выбрать стабильный, равномерный, высококардинальный ключ. Кардинальность обычно должна быть в ~1000 раз больше числа BE‑узлов, чтобы предотвратить перекос по бакетам.

• Изначально выберите подходящий размер бакета, предпочтительно в диапазоне 1–10 GB.

Преимущества¶

• Локальность запросов — селективные фильтры и join затрагивают меньше таблетов.

• Colocate joins — факт/измерение могут разделять хеш‑ключи для быстрых join.

• Предсказуемый макет — строки с одинаковым ключом всегда попадают вместе.

• Локальная агрегация и bucket‑shuffle joins — идентичная хеш‑схема по партициям позволяет локальную агрегацию и снижает стоимость shuffle при больших join.

Недостатки¶

• Уязвимость к «горячим» таблетам при перекосе распределения данных.

• Статическое количество таблет; масштабирование требует обслуживающих DDL.

• Недостаток таблет может ухудшать загрузку, компакцию и параллелизм выполнения запросов.

• Чрезмерное число таблет увеличивает объём метаданных.

Пример: Dimension‑Fact Join и обрезка таблетов¶

-- Fact‑таблица с партиционированием и hash‑бакетированием по (customer_id)
CREATE TABLE sales (
  sale_id bigint,
  customer_id int,
  sale_date date,
  amount decimal(10,2)
) ENGINE = OLAP
DISTRIBUTED BY HASH(customer_id) BUCKETS 48
PARTITION BY date_trunc('DAY', sale_date)
PROPERTIES ("colocate_with" = "group1");

-- Dimension‑таблица с тем же ключом и числом бакетов, colocated с sales
CREATE TABLE customers (
  customer_id int,
  region varchar(32),
  status tinyint
) ENGINE = OLAP
DISTRIBUTED BY HASH(customer_id) BUCKETS 48
PROPERTIES ("colocate_with" = "group1");


-- StarRocks может выполнять обрезку таблетов
SELECT sum(amount) 
FROM sales
WHERE customer_id = 123

-- StarRocks может выполнять локальную агрегацию
SELECT customer_id, sum(amount) AS total_amount
FROM sales
GROUP BY customer_id
ORDER BY total_amount DESC LIMIT 100;

-- StarRocks может выполнять colocate join
SELECT c.region, sum(s.amount)
FROM sales s JOIN customers c USING (customer_id)
WHERE s.sale_date BETWEEN '2025-01-01' AND '2025-01-31'
GROUP BY c.region;

Что даёт этот пример?¶

• Tablet pruning: предикат по customer_id WHERE customer_id = 123 включает обрезку бакетов, позволяя запросу обратиться только к одному таблету — это снижает задержку и нагрузку на CPU, особенно для точечных выборок.

• Локальная агрегация: когда столбец хеш‑распределения — подмножество ключа агрегации, StarRocks может обойти фазу shuffle‑агрегации, снижая общую стоимость.

• Colocated join: поскольку обе таблицы разделяют число бакетов и ключ, каждый BE может выполнять локальный join своей пары таблет без сетевого shuffle.

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

• Стабильные схемы с хорошо известными ключами распределения/фильтрации/join.

• Нагрузки DWH, которые выигрывают от обрезки бакетов.

• Нужны специфические оптимизации вроде colocate join/bucket shuffle join/local aggregation.

• Используются таблицы Aggregate/Primary Key.

Random Bucketing¶

Как это работает¶

Строки распределяются по кругу; ключ не задаётся. С PROPERTIES ("bucket_size"="<bytes>") StarRocks динамически делит таблеты по мере роста партиций (v3.2+).

Преимущества¶

• Нулевой дизайн‑долг — без ключей и вычислений по бакетам.

• Стойкость к перекосу при записи — равномерная нагрузка на диски и BE.

• Эластичный рост — деление таблет поддерживает высокую скорость ingest при росте данных или кластера.

Недостатки¶

• Нет обрезки бакетов — каждый запрос сканирует все таблеты партиции.

• Нет colocated join — отсутствие ключа мешает локальности.

• На сегодня ограничено Duplicate Key таблицами.

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

• Логи/события или multi‑tenant SaaS, где ключи меняются или наблюдается перекос.

• Пайплайны с высокой нагрузкой на запись, где критична равномерная пропускная способность ingest.

Операционные рекомендации¶

• Задайте размер бакета (например, 1 GiB) для Random Bucketing, чтобы включить авто‑деление.

• Для Hash Bucketing мониторьте размер таблет; выполняйте повторное шардинг‑разбиение до того, как таблетки превысят 5–10 GiB.