Doris 中大表与大表 Join 优化策略

在 Doris 中，大表与大表 Join 的性能瓶颈主要源于 数据分布、网络传输 和 内存资源 三大核心问题。结合 Doris 的 MPP 架构、列式存储和分布式计算特性，以下是针对性的优化方案及技术细节：

---

0. 常见的优化方向和策略

‌优化方向‌	‌适用场景‌	‌核心手段‌
‌数据分布优化‌	高频 Join 键分布均匀	使用 ‌Colocate Join‌ 或 ‌分桶键优化‌
‌计算下推‌	Join 条件可提前过滤数据	‌谓词下推‌、‌分区裁剪‌、‌Runtime Filter‌
‌资源与执行计划‌	内存/CPU 资源不足或执行计划不合理	调整 Join 顺序、启用 ‌Broadcast Join‌ 或Shuffle Join‌、优化内存配置
‌物化视图‌	高频重复查询	预计算 Join 结果，直接查询物化视图

1. 数据分布不均优化

问题：分桶键选择不当或数据倾斜导致节点负载不均，部分 BE 节点成为性能瓶颈。
优化方法：

• 合理选择分桶键

  • 优先选择 高频过滤字段 或 Join Key 作为分桶键（如 user_id），确保相同键值的数据落在同一分桶。
  • 避免使用低基数字段（如性别、状态码）或时间字段作为分桶键，易导致数据倾斜。

  -- 示例：以高基数的 user_id 作为分桶键
  CREATE TABLE table_a (
    user_id BIGINT,
    ...
  ) DISTRIBUTED BY HASH(user_id) BUCKETS 32;
  

• 动态调整分桶数

  • 数据量级大时，适当增加分桶数（如从 32 调整为 64），提升并行度。
  • 通过 SHOW DATA 命令监控分桶数据量，确保各分桶大小均衡（差异不超过 20%）。

• 处理数据倾斜

  • 若分桶键存在热点值（如 user_id=0 表示匿名用户），采用 复合分桶键（如 HASH(user_id, city)）分散数据。
  • 对倾斜键值单独处理：

    -- 将热点数据与非热点数据分开处理
    SELECT * FROM a JOIN b ON a.user_id = b.user_id 
    WHERE a.user_id != 0
    UNION ALL
    SELECT * FROM a JOIN b ON a.user_id = b.user_id 
    WHERE a.user_id = 0;
    

---

2. 网络传输开销优化

问题：跨节点数据传输（Shuffle）导致网络带宽成为瓶颈，尤其大表 Join 时。
优化方法：

• Colocate Join ‌

  • 将关联表的数据 物理共置 在相同节点，消除网络传输。 简单点说就是：通过 ‌分桶键（Bucket Key）‌ 将两张表的数据按相同规则分布到相同节点，实现本地 Join，避免跨节点数据传输。
  • 建表时指定同一 Colocate Group：

    -- 表A和表B使用相同的分桶键和分桶数
    -- 分桶键=user_id，桶数=32
    CREATE TABLE table_a (...) 
    DISTRIBUTED BY HASH(user_id) BUCKETS 32
    PROPERTIES ("colocate_with" = "group1");
    
    CREATE TABLE table_b (...) 
    DISTRIBUTED BY HASH(user_id) BUCKETS 32
    PROPERTIES ("colocate_with" = "group1");
    

  • 执行 Join 时自动触发本地计算，通过 EXPLAIN 验证是否命中 colocate: true。
  • 限制‌：
    • 分桶键需严格一致，且数据需均匀分布。
    • 仅适用于等值 Join。

• Runtime Filter

  • 在 Build 端（右表）生成过滤条件（如 Bloom Filter、Min/Max Filter），减少 Probe 端（左表）扫描数据量。 简单点说就是：利用 ‌Bloom Filter‌ 或 ‌Min/Max Filter‌ 在扫描阶段过滤不匹配的数据，减少 Join 数据量。
  • 启用参数：

    -- 启用 Runtime Filter（默认开启，可调整参数）
    SET runtime_filter_type = "BLOOM_FILTER,MIN_MAX";  -- 同时启用两种过滤器
    SET runtime_filter_wait_time_ms = 5000;           -- 适当延长等待时间
    

• 本地化计算

  • 利用 Doris 的 MPP 架构，将计算任务下推至数据所在的 BE 节点，减少跨节点数据传输。
  • 通过 EXPLAIN 检查执行计划，确保 EXCHANGE 节点（数据交换）数量最小化。

---

3. 内存资源不足优化

问题：大表 Join 时哈希表构建或中间结果缓存导致内存溢出（OOM）。
优化方法：

• 优化 Join 算法选择

  • 默认使用 Hash Join，但右表过大时易 OOM。强制使用 Shuffle Join 分散内存压力：

    SET enable_broadcast_join = false;  
    -- 广播只是适合右表较小的情况（如右表 < 100MB）
    -- 右表过大时易 OOM，禁用 Broadcast Join
    

  • 对非等值 Join，尝试 Sort-Merge Join（需预先排序）。

• 内存参数调优

  • 增加单查询内存上限，防止 OOM：

    SET exec_mem_limit = 32G;  -- 根据 BE 节点内存调整
    

  • 控制并发查询数，避免资源争抢：

    SET parallel_fragment_exec_instance_num = 4;  -- 降低并行度
    

• 流式传输与分批处理

  • 对超大表 Join，启用 Pipeline 执行引擎（Doris 2.0+），通过流水线化减少内存峰值：

    SET enable_pipeline_engine = true;
    

---

4. 列式存储与计算优化

问题：全列读取或复杂表达式计算导致 IO 和 CPU 开销大。
优化方法：

• 列裁剪与谓词下推

  • 仅读取 Join 所需的列，减少 IO 消耗：

    SELECT a.user_id, b.order_id  -- 只选择必要字段
    FROM table_a a JOIN table_b b ON a.user_id = b.user_id;
    

  • 利用 Doris 的智能谓词下推，提前过滤数据：

    SELECT ... 
    FROM table_a a JOIN table_b b ON a.user_id = b.user_id
    WHERE a.city = 'Beijing' AND b.price > 100;  -- 过滤条件下推至存储层
    

• 向量化执行

  • 默认开启向量化引擎，确保复杂计算（如聚合、表达式）按批处理（1024行/批），提升 CPU 缓存利用率。

---

5. 场景化优化策略

场景 1：历史数据与实时数据 Join

• 分区策略：
  • 按时间分区（如 PARTITION BY RANGE(dt)），定期淘汰旧分区，缩小 Join 范围。
  • 对实时表使用 动态分区，自动管理分区。

场景 2：高并发点查询 Join

• 物化视图：
  • 预计算高频 Join 结果，转为宽表：

    CREATE MATERIALIZED VIEW mv_wide_table
    AS 
    SELECT a.user_id, a.name, b.order_count
    FROM users a JOIN orders b ON a.user_id = b.user_id;
    

  • 查询直接扫描物化视图，避免实时 Join。

场景 3：多表链式 Join

• 执行顺序优化：
  • 手动调整 Join 顺序，优先过滤数据量小的表：

    SELECT /*+ STRAIGHT_JOIN */ ...  -- 强制指定 Join 顺序
    FROM small_table s 
    JOIN medium_table m ON s.id = m.sid
    JOIN large_table l ON m.id = l.mid;
    

---

6. 监控与诊断工具

1. 执行计划分析：

   EXPLAIN SELECT ...;  -- 检查是否命中 Colocate Join、Runtime Filter
   

   • 关注 EXCHANGE 节点数量（越少越好）和 HASH JOIN 类型。

2. Profile 分析：

   SET enable_profile = true;
   SELECT ...;  -- 执行后通过 WEB 界面查看 Profile
   

   • 定位耗时最高的 Operator（如 HashJoinProbe、Aggregation）。

3. 日志与监控：

   • 通过 SHOW BACKENDS 监控 BE 节点负载。
   • 查看 BE 日志中的 Memory limit exceeded 警告，调整内存参数。

---

总结

大表 Join 优化需结合 数据分布设计、计算引擎特性 和 资源管控 三个维度：

1. 数据分布：通过分桶键、Colocate Join、分区裁剪减少数据移动。
2. 计算优化：利用 Runtime Filter、向量化执行、Pipeline 引擎提升效率。
3. 资源管控：调整内存、并行度参数，避免 OOM 和资源争抢。

最终方案需根据业务特征（如数据倾斜程度、查询并发度）进行针对性调优，并通过执行计划验证效果。