GBase 8a MPP 分布式查询执行机制深度解析

本文适合已有 GBase 8a 基本使用经验的读者，重点讲清楚一条 SQL 在集群内部的完整执行路径，以及协调节点、计算节点各自扮演的角色。

一、架构回顾：三层角色

GBase 8a MPP Cluster 的核心进程分三类：

客户端只与 gcluster 通信。gcluster 不存储用户数据，它只持有元数据（表定义、分布信息、副本拓扑）。

二、查询执行的完整生命周期

以一个典型的分析查询为例：

SELECT dept_id, SUM(sale_amount) AS total
FROM orders
WHERE order_date >= '2024-01-01'
GROUP BY dept_id
ORDER BY total DESC
LIMIT 100;

阶段 1：SQL 解析与语义检查（gcluster）

gcluster 的 SQL Parser 将文本解析成 AST，随后进行语义校验：

• 表、列是否存在
• 数据类型兼容性
• 视图展开

阶段 2：查询计划生成（gcluster）

优化器根据元数据（行数统计、列分布信息）生成分布式执行计划（DQP，Distributed Query Plan）。核心决策有两个：

决策一：下推 vs. 汇总

对于 WHERE order_date >= '2024-01-01' 这类过滤条件，优化器会将其下推到每个 gnode 执行，避免将全量数据传回协调节点。

对于 SUM(sale_amount) GROUP BY dept_id，因为 orders 表极可能按某列 Hash 分布，dept_id 并不一定是分布键，所以需要：

1. 每个 gnode 先做局部聚合（Partial Aggregation）
2. 将局部结果 Hash 重分布到各节点（按 dept_id 重新 shuffle）
3. 各节点再做最终聚合（Final Aggregation）

决策二：数据重分布方式

关键参数：gcluster_hash_redistribute_join_optimize 和 gcluster_hash_redistribute_groupby_optimize 控制是否对小表做广播优化，避免把小表当成分布表强制做 Hash Shuffle。

阶段 3：任务分发与并行执行（gcluster → gnode）

gcluster 将 DQP 拆分成多个子任务（Fragment），通过内部通信通道（默认走 TCP）并发推送给所有参与节点。

每个 gnode 收到子任务后，启动工作线程池（受 gbase_parallel_degree 控制）并发扫描本地存储的数据分片（Segment）。

gcluster
  ├─ Fragment-1 → gnode1 (扫描本地分片 + 局部聚合)
  ├─ Fragment-1 → gnode2 (扫描本地分片 + 局部聚合)
  └─ Fragment-1 → gnode3 (扫描本地分片 + 局部聚合)
         ↓
  [Hash Redistribute by dept_id]
         ↓
  ├─ Fragment-2 → gnode1 (最终聚合 dept_id ∈ 某 Hash 桶)
  ├─ Fragment-2 → gnode2
  └─ Fragment-2 → gnode3
         ↓
  gcluster 汇总 TOP 100

阶段 4：结果汇总与返回（gcluster）

各 gnode 将 Fragment 结果流式返回给 gcluster。对于 ORDER BY ... LIMIT 100，gcluster 做一次最终归并排序，取 Top-N 返回客户端。

三、中间结果表与调试手段

GBase 8a 在执行复杂查询时会在各 gnode 上创建临时中间表（Internal Temp Table）。执行结束后自动清理。

若想保留中间表以排查数据问题，可设置：

-- 会话级开启，保留执行中间结果
SET gcluster_executor_debug = 1;

⚠️ 此参数仅用于调试，生产环境务必关闭，否则中间表堆积会撑爆磁盘。

查看正在执行的查询及其状态：

-- 查看当前集群上活跃的 SQL
SHOW FULL PROCESSLIST;

-- 查看每个节点的执行时间（需提前开启统计）
-- gcluster_dql_statistic_threshold = N (毫秒，超过N则记录)
SELECT * FROM gclusterdb.dql_statistic ORDER BY exec_time DESC LIMIT 20;

四、常见的查询性能陷阱

陷阱 1：笛卡尔积导致磁盘暴涨

当 JOIN 条件缺失或写错时，两张大表做笛卡尔积，中间结果可以达到 TB 级别。参数 _gbase_result_threshold 可以限制中间结果行数：

-- gnode 的 gbase.cnf 中设置
_gbase_result_threshold = 1000000000  -- 超过 10 亿行报错

陷阱 2：数据倾斜导致某节点成为瓶颈

当 GROUP BY 的列唯一值很少（如 gender 只有 M/F），Hash 重分布后所有数据集中到 1~2 个节点，并行度形同虚设。

解决思路：

1. 选择高基数列作为分布键
2. 对倾斜的 GROUP BY 启用多列 Hash 重分布：

SET _t_gcluster_distinct_multi_redist = 1;
SET _t_gcluster_hash_redistribute_groupby_on_multiple_expression = 1;

陷阱 3：小表被错误地当成分布表 JOIN

当大量小表参与 JOIN 时，优化器可能将每张小表都通过 Hash Redistribute 分发，产生大量网络往返。此时应手动将常用小表建为复制表（Replicated Table）：

-- 建表时指定复制表（数据在每个节点都有完整副本）
CREATE TABLE dim_region (
    region_id INT,
    region_name VARCHAR(64)
) REPLICATED;

五、总结

理解这条链路，就能在遇到慢查询时快速定位瓶颈：是分发阶段的重分布代价过高，还是某个 gnode 的本地扫描太慢，还是 gcluster 的汇总成了单点。后续可结合 EXPLAIN 和 dql_statistic 系统表做精确诊断。