分桶

选择 StarRocks 中 Hash 分桶和 Random 分桶的简明指南，包括它们的机制、权衡以及推荐的用例。

---

快速概览比较

方面	Hash 分桶	Random 分桶
示例	DISTRIBUTED BY HASH(id) BUCKETS 16	DISTRIBUTED BY RANDOM
Key 声明	必需 HASH(col1, …)	无 – 行以轮询方式分配
省略时的初始 bucket 计数	CREATE 时自动选择，然后固定	CREATE 时自动选择；如果设置了 bucket_size，则可以增长
Tablet 分裂/收缩	手动 ALTER … BUCKETS	自动分裂 ⇢ 仅增长 (≥ v3.2)
倾斜抵抗	取决于 key 基数	高 – 设计上均匀
Bucket 裁剪	✅ (过滤器，连接)	🚫 (全 tablet 扫描)
Colocate 连接	✅	🚫
本地聚合/bucket-shuffle 连接	✅	🚫
支持的表类型	全部	仅 Duplicate Key 表

---

Hash 分桶

工作原理

通过对一个或多个列进行哈希处理，将行分配给 tablet。创建后，tablet 计数是固定的，除非手动更改。

要求

• 必须预先选择一个稳定、均匀、高基数的 key。基数通常应是 BE 节点数的 1000 倍以上，以防止 hash bucket 之间的数据倾斜。
• 最初选择适当的 bucket 大小，最好介于 1 到 10 GB 之间。

优势

• 查询局部性 – 选择性过滤器和连接触及较少的 tablet。
• Colocate 连接 – 事实/维度表可以共享 hash key 以实现高速连接。
• 可预测的布局 – 具有相同 key 的行始终一起着陆。
• 本地聚合 & bucket‑shuffle 连接 – 跨分区的相同 hash 布局支持本地聚合并减少大型连接的数据 shuffle 成本

劣势

• 如果数据分布倾斜，则容易出现热 tablet。
• Tablet 计数是静态的；扩展需要维护 DDL。
• Tablet 不足可能会对数据摄取、数据压缩和查询执行并行性产生不利影响。
• 过度使用 tablet 会扩大元数据 footprint。

示例：维度-事实连接和 Tablet 裁剪

-- Fact table partitioned and hash‑bucketed by (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 table hash‑bucketed on the same key and bucket count colocated with the sales table
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 can do tablet pruning
SELECT sum(amount) 
FROM sales
WHERE customer_id = 123

-- StarRocks can do local aggregation
SELECT customer_id, sum(amount) AS total_amount
FROM sales
GROUP BY customer_id
ORDER BY total_amount DESC LIMIT 100;

-- StarRocks can do 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 裁剪：customer_id 谓词 WHERE customer_id = 123 启用 bucket 裁剪，允许查询仅访问单个 tablet，从而降低延迟和 CPU 周期，尤其对于点查找。
• 本地聚合：当 hash 分布 key 是聚合 key 的子集时，StarRocks 可以绕过 shuffle 聚合阶段，从而降低总体成本。
• Colocated 连接：因为两个表共享 bucket 数量和 key，所以每个 BE 都可以连接其本地的 tablet 对，而无需网络 shuffle。

何时使用

• 具有众所周知的分布过滤器/连接 key 的稳定模式。
• 受益于 bucket 裁剪的数据仓库工作负载。
• 您需要一些特定的优化，例如 colocate 连接/bucket shuffle 连接/本地聚合
• 您正在使用 Aggregate/Primary Key 表。

---

Random 分桶

工作原理

行以轮询方式分配；未指定 key。使用 PROPERTIES ("bucket_size"="<bytes>")，StarRocks 会随着分区增长动态地拆分 tablet (v3.2+)。

优势

• 零设计负担 – 没有 key，没有 bucket 计算。
• 防倾斜写入 – 在磁盘和 BE 上均匀压力。
• 弹性增长 – tablet 分裂使数据或集群增长时保持快速摄取。

劣势

• 没有 bucket 裁剪 – 每个查询都会扫描分区中的所有 tablet。
• 没有 colocated 连接 – 无 key 布局阻止局部性。
• 今天仅限于 Duplicate Key 表。

何时使用

• Key 更改或倾斜的日志/事件或多租户 SaaS 表。
• 统一摄取吞吐量至关重要的写繁重管道。

---

操作指南

• 为 random 分桶选择一个 bucket 大小（例如，1 GiB）以启用自动拆分。
• 对于 hash 分桶，监控 tablet 大小；在 tablet 超过 5–10 GiB 之前重新分片