obsidian-sync/问题排查/doris/Doris 数据倾斜.md

如果一张表数据非常大，并且分桶数量有问题就会出现数据倾斜。

分桶（Bucketing）的根本目的是将数据打散，使其均匀地分布到所有BE节点上。每个桶就是一个数据分片，在Doris中称为Tablet。

• 数据均匀分布：可以避免数据倾斜，防止单个BE节点成为写入或查询的瓶颈。这对于高成本的主键模型（Merge-on-Write） 尤为重要。
• 最大化并行处理：当查询或写入发生时，Doris可以同时在多个BE节点上的多个Tablet上并行执行任务，从而大幅提升效率。

黄金法则：分桶数与节点数的关系

法则1：分桶数应该是BE节点数的整数倍

这是为了保证每个BE节点上的Tablet数量完全相等。

• 场景: 3个BE节点，副本数通常为3。
• 如果分桶数为10: Doris会尝试均匀分配，但无法做到绝对平均。可能会出现类似 BE1: 4个Tablet, BE2: 3个Tablet, BE3: 3个Tablet 的情况（这只是一个示意，实际分配更复杂），导致轻微的负载不均。
• 如果分桶数为12 (3的倍数): Doris可以精确地为每个BE节点分配 12 / 3 = 4 个Tablet（的主副本）。这样在数据写入和查询时，负载可以完美地均分到3个节点上。

法则2：总Tablet数量要适中

一个分区的总Tablet数 = 分桶数 × 副本数。 单个BE节点上的Tablet数 = 分桶数 (在副本数为3，BE节点为3的典型情况下)。

Doris官方和社区的最佳实践建议：

• 单个BE节点上的Tablet总数不宜过多：过多的Tablet会增加FE的元数据管理压力，增加RPC开销，并可能导致Compaction调度不及时，产生大量小文件。
• 单个Tablet的数据量不宜过小或过大：
  • 太小（< 100MB）: 说明分桶太多，增加了管理开销，且无法发挥Doris列存和压缩的优势。
  • 太大（> 10GB）: 可能导致单Tablet的Compaction时间过长，或者在节点故障时，单个Tablet的迁移恢复时间过长。
  • 理想范围: 单个Tablet的数据量建议保持在 100MB ~ 1GB 之间。

如何计算最适合你的分桶数？

这是一个自上而下的推算过程：

1. 预估分区数据量: 评估一下您的表，单个分区（通常是一天或一个月）的数据增量大概是多少？例如，我们预估一天的数据量是 50 GB。

2. 设定理想Tablet大小: 我们选择一个理想的Tablet大小，比如 1 GB。

3. 计算理想分桶数:

   • 理想Tablet总数 = 分区数据量 / 理想Tablet大小 = 50 GB / 1 GB = 50 个。
   • 因为总Tablet数 = 分桶数 × 副本数，所以：
   • 理想分桶数 = 理想Tablet总数 / 副本数 = 50 / 3 ≈ 16.7。

4. 结合“法则1”进行调整:

   • 我们计算出的理想分桶数是 16.7。
   • 我们需要找到一个最接近 16.7 并且是 3 的倍数的数字。
   • 15 和 18 都是很好的选择。在这种情况下，选择 18 会让Tablet更小一些，更灵活；选择 15 会让Tablet更大一些，管理开销更小。两者都是合理的。