1. 分桶策略的本质与数据倾斜的关联

第一次接触Doris分桶时，我误以为这只是个简单的数据分组机制。直到某次大促期间，我们的订单表查询突然变慢，部分BE节点CPU飙到100%，才真正理解分桶策略对系统性能的影响。当时使用的分桶列是user_id，结果发现头部商家账号产生的订单量是普通用户的数千倍，导致数据严重倾斜——这就是典型的分桶策略设计不当引发的问题。

分桶的本质是通过特定规则将数据均匀分布到不同Tablet上。Doris提供两种分桶方式：Hash分桶和Random分桶。Hash分桶通过对分桶列值计算crc32哈希再取模确定位置，适合离散分布的列；Random分桶则完全随机分配，适合临时表或小批量数据导入。在电商场景中，90%的性能问题都源于错误选择了分桶列——比如用有明显倾斜特征的user_id做Hash分桶。

数据倾斜会引发三大致命问题：

• 热点写入：某个Tablet持续接收大量写入请求，导致BE节点I/O瓶颈
• 查询延迟：少数Tablet数据量过大，拖慢整个查询流程
• 资源浪费：部分BE负载过高，其他节点却处于闲置状态

我曾用以下SQL验证过数据分布情况（假设分桶数为10）：

SELECT 
  tablet_id, 
  COUNT(*) AS row_count,
  COUNT(*)/(SUM(COUNT(*)) OVER())*100 AS percentage
FROM order_table
GROUP BY tablet_id
ORDER BY row_count DESC;

当发现某个tablet的数据占比超过30%时，就需要立即调整分桶策略了。

2. 电商场景下的分桶列选择实战

去年优化一个跨境电商平台时，我们遇到个典型案例：订单表按user_id分桶后，发现某些海外代购账号的订单量占比达40%。这直接导致对应BE节点频繁OOM。经过多次测试，最终采用组合分桶列方案解决了问题：

1. 识别高基数列：通过分析数据特征，选取order_id（唯一值）、user_region（6大洲）、create_hour（24小时）作为候选列
2. 计算离散度指标：

-- 计算列的基数与数据分布
SELECT 
  COUNT(DISTINCT user_id)/COUNT(*) AS user_id_ratio,
  COUNT(DISTINCT concat(user_region,create_hour))/COUNT(*) AS combo_ratio 
FROM orders;

3. 验证组合列效果：最终选用(user_region, create_hour)组合，离散度提升到0.92，比单用user_id的0.15有质的飞跃

对于特殊场景还有两个技巧：

• 热点隔离：为VIP用户单独建表，避免影响主表性能
• 动态调整：通过ALTER TABLE...MODIFY DISTRIBUTION定期优化分桶数

实测表明，合理的分桶列选择能使查询性能提升3-5倍。有个容易忽略的细节：分桶列应该尽量匹配常用查询的JOIN条件，这样能充分利用Colocate Join特性。

3. 分桶数量与性能的平衡艺术

分桶数量就像炒菜放盐——太少则乏味，太多则难以下咽。初期我们机械地按"BE节点数×3"设置分桶数，结果吃了大亏。现在总结出这套方法论：

核心公式：

理想分桶数 = min(
    BE节点数 × 副本数 × 并行度系数(通常3-5),
    数据量/(每个Tablet建议大小(1-10GB))
)

具体操作步骤：

1. 估算表数据量：比如订单表预计1TB
2. 确定Tablet大小：我们设定为5GB（OLAP场景理想值）
3. 计算理论分桶数：1TB/5GB=200
4. 考虑集群规模：假设有10台BE，副本数3，则最大可支持10×3×5=150
5. 最终取最小值：150个分桶

这是我们在生产环境的配置示例：

CREATE TABLE order_analysis (
    order_id BIGINT,
    user_id INT,
    -- 其他字段...
)
DISTRIBUTED BY HASH(user_region,create_hour) 
BUCKETS 150
PROPERTIES (
    "replication_num" = "3",
    "colocate_with" = "order_group"
);

特别注意：

• 分桶数超过128会导致写入性能明显下降
• 小表（<10GB）建议设置较少分桶，甚至用Random分桶
• 通过SHOW BACKENDS\G监控各BE的Tablet数量差异，超过20%就需要调整

4. 高级调优：Colocate与数据重分布

去年双十一前，我们通过Colocate Join将订单表和用户表的关联查询从15秒降到1.2秒。这个功能的核心原理是把需要频繁JOIN的表设置为相同分桶方式，使关联数据分布在相同BE节点上，避免网络传输开销。

配置方法分三步：

1. 创建Colocate Group

ALTER TABLE order_table 
SET ("colocate_with" = "order_user_group");

ALTER TABLE user_table 
SET ("colocate_with" = "order_user_group");

2. 验证数据分布

SHOW PROC '/colocation_group';
-- 确保所有表的DistributionKey完全一致

3. 执行Colocate Join

-- 查询时自动生效，无需特殊语法
SELECT * FROM order_table o JOIN user_table u ON o.user_id = u.id;

对于已存在倾斜的表，可以用数据重分布拯救：

-- 创建临时表
CREATE TABLE order_new LIKE order_table 
WITH ("colocate_with" = "order_user_group");

-- 数据迁移
INSERT INTO order_new SELECT * FROM order_table;

-- 原子替换
RENAME TABLE order_table TO order_old, order_new TO order_table;

有个踩坑经验：重分布过程中要关闭自动 compaction，否则可能引发BE内存溢出。我们曾因此导致集群短暂不可用，教训深刻。

5. 监控与应急处理方案

完善的监控体系能提前发现分桶问题。这是我们团队使用的监控看板配置：

关键指标：

• 各BE节点Tablet数量方差 >20%
• 单个Tablet数据量 >10GB
• 查询耗时P99 >5s
• BE磁盘I/O利用率 >80%

自动化处理脚本（部分摘录）：

#!/bin/bash
# 监控分桶倾斜
skew_ratio=$(mysql -hFE_HOST -P9030 -uroot -e "
  SELECT MAX(tablet_count)/AVG(tablet_count) 
  FROM (SELECT COUNT(*) AS tablet_count 
        FROM information_schema.tablets 
        GROUP BY backend_id) t" | tail -n 1)

[ $(echo "$skew_ratio > 1.2" | bc) -eq 1 ] && \
  alert "Bucket skew detected: ratio=$skew_ratio"

对于突发性热点问题，我们准备了三级应急方案：

1. 短期：通过SET exec_mem_limit=8G临时增加查询内存
2. 中期：用ALTER TABLE...ADD TEMPORARY PARTITION隔离热点数据
3. 长期：重新设计分桶策略并迁移数据

记得某次大促时，突然出现某个商品页面的查询QPS暴涨，我们立即启用临时分区将相关数据单独处理，避免了集群雪崩。这种应急机制已经成为我们稳定性保障的标准配置。