5步精通Apache Doris执行计划：面向数据工程师的查询优化实战指南

问题引入：当SQL遇到性能瓶颈

在数据密集型应用中，一条看似简单的SQL查询可能隐藏着巨大的性能隐患。某电商平台数据团队曾遇到这样的案例：一个日常销售报表查询突然从3秒延迟飙升至2分钟，经过排查发现是由于新增数据导致执行计划选择了低效的全表扫描。执行计划就像SQL的"X光片"，能够揭示查询内部的执行逻辑。本文将通过五步法，帮助数据工程师掌握Apache Doris执行计划的解析技巧，解决90%的查询性能问题。

核心概念：揭开执行计划的面纱

🧩 执行计划的本质与价值

执行计划是查询优化器生成的"操作说明书"，它定义了数据从存储到结果的完整加工流程。如同餐厅的后厨流程——从采购（数据读取）、切配（数据转换）到烹饪（计算聚合），每个环节的效率都直接影响最终出餐速度（查询延迟）。

在Apache Doris中，执行计划采用有向无环图（DAG） 结构，由多个算子按数据流向串联而成。通过EXPLAIN命令生成的执行计划，我们可以直观看到：

• 数据从哪些表读取（扫描算子）
• 采用何种方式连接（连接算子）
• 如何进行聚合计算（聚合算子）
• 数据如何在节点间传输（交换算子）

🔄 优化器工作原理

Apache Doris提供两代优化器：

• Legacy Planner：基于规则的传统优化器，采用启发式算法
• Nereids Planner：基于Cascades框架的新一代优化器，支持代价估算和更丰富的算子选择

通过会话变量可切换优化器：

-- 启用Nereids Planner（推荐）
SET enable_nereids_planner = true;

图1：执行计划生成流程示意图，展示从SQL解析到计划生成的完整路径

实践操作：执行计划的生成与解读

📝 基础使用方法

生成执行计划仅需在SQL前添加EXPLAIN关键字：

EXPLAIN SELECT category, SUM(sales) 
FROM sales_data 
WHERE dt = '2023-10-01' 
GROUP BY category;

执行计划输出包含六列核心信息：

字段名	含义说明	类比解释
ID	算子唯一标识	工序编号
OPERATOR	算子类型	加工设备类型
NAME	算子具体名称	设备型号
EST. ROWS	估计输出行数	预计产出数量
EST. BYTES	估计输出数据量	预计产出体积
PROPERTIES	算子属性（过滤条件、连接键等）	设备运行参数

🔍 关键算子识别技巧

1. 扫描算子（SCAN）：执行计划的起点，负责从存储引擎读取数据

   | 3  | SCAN           | OLAP_TABLE | 1000000   | 40000000   | table: sales_data, partitions: [p20231001], buckets: [1-10] |
   

   关键指标：partitions和buckets是否有具体值，空值表示全表扫描

2. 聚合算子（AGGREGATE）：执行COUNT、SUM等聚合操作

   | 2  | AGGREGATE      | FINAL      | 1000      | 40000      | group by: category, sum: sales |
   

   关键指标：是否包含PARTIAL和FINAL两个阶段，完整聚合通常需要两阶段处理

3. 连接算子（JOIN）：实现表连接操作

   | 1  | HASH_JOIN      |            | 50000     | 2000000    | join_type: INNER JOIN, condition: a.id = b.product_id |
   

   关键指标：连接类型（HASH_JOIN/MERGE_JOIN/NESTED_LOOP_JOIN）和连接条件

4. 交换算子（EXCHANGE）：实现数据重分布

   | 0  | EXCHANGE       | HASH       | 1000      | 40000      | HASH KEYS: category |
   

   关键指标：数据重分布类型（HASH/RANGE/BROADCAST）

✨ 小试牛刀：生成并分析第一个执行计划

1. 准备测试数据：

   CREATE TABLE sales_data (
     dt DATE,
     category VARCHAR(50),
     sales DECIMAL(10,2)
   ) DISTRIBUTED BY HASH(category) BUCKETS 10
   PROPERTIES ("replication_num" = "1");
   
   INSERT INTO sales_data VALUES 
   ('2023-10-01', 'electronics', 12000.50),
   ('2023-10-01', 'clothing', 8500.30),
   ('2023-10-01', 'electronics', 5600.80);
   

2. 生成执行计划：

   EXPLAIN SELECT category, SUM(sales) 
   FROM sales_data 
   WHERE dt = '2023-10-01' 
   GROUP BY category;
   

3. 分析输出结果，尝试回答：

   • 执行计划包含哪些算子？
   • 数据扫描是否使用了分区过滤？
   • 聚合操作是否采用了两阶段处理？

案例分析：从执行计划到性能优化

📊 案例1：消除全表扫描

问题现象：某用户行为分析查询耗时20秒，执行计划如下：

+--------------------------------------------------+
| ID | OPERATOR        | NAME       | EST. ROWS | ... |
+--------------------------------------------------+
| 0  | AGGREGATE       | SUM        | 1000      | ... |
| 1  |  SCAN           | OLAP_TABLE | 5000000   | ... | table: user_behavior, partitions: [], buckets: [] |
+--------------------------------------------------+

优化过程：

1. 识别问题：partitions: []表明未使用分区过滤
2. 添加分区条件：WHERE dt = '2023-10-01'
3. 优化后执行计划：

   | 1  |  SCAN           | OLAP_TABLE | 50000     | ... | table: user_behavior, partitions: [p20231001], buckets: [1-10] |
   

4. 性能提升：查询时间从20秒降至1.2秒，性能提升16倍

🔗 案例2：优化多表连接顺序

问题现象：三表连接查询耗时35秒，执行计划显示连接顺序不合理：

+--------------------------------------------------+
| ID | OPERATOR        | NAME       | EST. ROWS | ... |
+--------------------------------------------------+
| 0  | HASH_JOIN       |            | 10000     | ... |
| 1  |  HASH_JOIN      |            | 100000    | ... |
| 2  |   SCAN          | ORDERS     | 1000000   | ... |
| 3  |   SCAN          | CUSTOMERS  | 500000    | ... |
| 4  |  SCAN           | PRODUCTS   | 1000      | ... |
+--------------------------------------------------+

优化过程：

1. 识别问题：小表PRODUCTS最后连接，导致中间结果集过大
2. 使用HINT调整连接顺序：

   EXPLAIN SELECT /*+ JOIN_ORDER(PRODUCTS, CUSTOMERS, ORDERS) */ ...
   

3. 优化后执行计划：

   +--------------------------------------------------+
   | ID | OPERATOR        | NAME       | EST. ROWS | ... |
   +--------------------------------------------------+
   | 0  | HASH_JOIN       |            | 10000     | ... |
   | 1  |  SCAN           | ORDERS     | 1000000   | ... |
   | 2  |  HASH_JOIN      |            | 5000      | ... |
   | 3  |   SCAN          | CUSTOMERS  | 500000    | ... |
   | 4  |   SCAN          | PRODUCTS   | 1000      | ... |
   +--------------------------------------------------+
   

4. 性能提升：查询时间从35秒降至8秒，中间结果集减少95%

核心组件工作原理

📡 扫描组件（Scan Operators）

扫描组件负责从存储引擎读取数据，是执行计划的起点。Doris支持多种扫描类型：

扫描类型	应用场景	性能特点
OLAP_TABLE_SCAN	原生OLAP表	支持分区裁剪、谓词下推、向量执行
MYSQL_SCAN	MySQL外部表	依赖MySQL性能，支持谓词下推
HIVE_SCAN	Hive外部表	支持Parquet/ORC等列式存储，适合大数据量扫描
ES_SCAN	Elasticsearch外部表	擅长全文检索，支持复杂过滤条件

扫描组件的核心优化技术包括：

• 分区裁剪：仅扫描符合条件的分区
• 桶裁剪：根据分桶键过滤不需要的桶
• 谓词下推：将过滤条件下推至存储层执行
• 列裁剪：只读取查询所需的列

🔄 聚合组件（Aggregation Operators）

聚合组件实现GROUP BY和聚合函数计算，采用"部分聚合+全局聚合"的两阶段模式：

1. PARTIAL_AGGREGATE：在每个数据分片上进行初步聚合，减少数据传输量
2. FINAL_AGGREGATE：对各分片的聚合结果进行最终计算

聚合优化技术：

• 流式聚合：对有序数据进行增量聚合，减少内存占用
• 预聚合：利用物化视图提前计算常用聚合结果
• 向量化执行：批量处理数据，提高CPU利用率

🔗 连接组件（Join Operators）

Doris支持三种连接算法，各有适用场景：

1. HASH_JOIN：将小表构建哈希表，适合大表连接小表

   • 优点：处理大数据量效率高
   • 缺点：内存消耗大

2. MERGE_JOIN：要求输入数据有序，适合已排序的表连接

   • 优点：内存消耗低，适合大表连接
   • 缺点：需要预先排序

3. NESTED_LOOP_JOIN：小表驱动大表，适合极小规模的表连接

   • 优点：实现简单，适合小数据量
   • 缺点：大数据量下性能差

🌐 交换组件（Exchange Operators）

交换组件实现数据在不同节点间的传输，是分布式执行的核心：

• HASH_EXCHANGE：根据哈希值重分布数据，用于GROUP BY和JOIN
• BROADCAST_EXCHANGE：将小表广播到所有节点，避免数据重分布
• GATHER_EXCHANGE：将分布式结果收集到单个节点，用于最终结果返回

常见误区解析

❌ 误区1：执行计划中的估算行数不重要

正解：估算行数（EST. ROWS）直接影响优化器的算子选择。当估算行数与实际行数偏差超过10倍时，可能导致优化器选择低效执行计划。

验证方法：通过EXPLAIN ANALYZE对比估算与实际行数：

EXPLAIN ANALYZE SELECT category, SUM(sales) FROM sales_data GROUP BY category;

解决方案：定期更新统计信息：

ANALYZE TABLE sales_data WITH SYNC;

❌ 误区2：Nereids Planner总是比Legacy Planner好

正解：Nereids Planner在复杂查询上表现更优，但某些简单查询可能不如Legacy Planner。可通过HINT在查询级别指定优化器：

-- 强制使用Legacy Planner
EXPLAIN SELECT /*+ SET_VAR(enable_nereids_planner=false) */ * FROM test_table;

❌ 误区3：分区越多查询越快

正解：分区过多会导致元数据管理开销增大，通常建议分区数不超过1000个。合理的分区策略应基于业务查询模式，例如按天分区适合日报表查询。

❌ 误区4：所有查询都需要添加索引

正解：索引适合点查询和高基数列过滤。对于全表扫描或大表聚合查询，索引可能反而增加存储和维护成本。Doris的前缀索引已能满足多数场景需求。

进阶技巧：执行计划调优实战

🎯 HINT优化技术

HINT是干预执行计划的高级手段，常用HINT包括：

1. JOIN_ORDER：指定表连接顺序

   SELECT /*+ JOIN_ORDER(t1, t2, t3) */ t1.id, t2.name, t3.value 
   FROM t1 JOIN t2 ON t1.id = t2.id JOIN t3 ON t2.id = t3.id;
   

2. SET_VAR：设置会话变量

   SELECT /*+ SET_VAR(dynamic_partition_pruning=true) */ * 
   FROM sales_data WHERE dt = '2023-10-01';
   

3. USE_INDEX：指定使用的索引

   SELECT /*+ USE_INDEX(t1, idx_category) */ category, SUM(sales) 
   FROM sales_data t1 GROUP BY category;
   

📊 执行计划对比分析

通过对比不同优化器或参数下的执行计划，可找到性能差异点：

-- 生成Nereids执行计划
EXPLAIN SELECT /*+ SET_VAR(enable_nereids_planner=true) */ * FROM test_table;

-- 生成Legacy执行计划
EXPLAIN SELECT /*+ SET_VAR(enable_nereids_planner=false) */ * FROM test_table;

📈 性能监控与分析

结合Doris的监控指标分析执行计划效率：

1. 查看查询扫描行数：SHOW PROC '/statistic'
2. 监控内存使用：SHOW PROC '/memory'
3. 分析CPU占用：SHOW PROC '/processes'

扩展学习路径

1. 官方文档：查询优化模块 - 深入了解执行计划生成的源代码实现
2. 测试用例：pytest/qe/query_regression/sql/ - 包含丰富的执行计划测试场景
3. 进阶课程：Apache Doris官方培训中的"查询优化实战"模块，系统学习执行计划调优方法论

通过掌握执行计划解析技巧，数据工程师能够从"黑盒调优"转变为"基于原理的精准优化"。建议养成编写SQL前先看执行计划的习惯，这将使你在处理复杂查询性能问题时游刃有余。记住，优秀的数据工程师不仅要会写SQL，更要懂SQL背后的执行逻辑。