GBase 8a 窗口函数在 MPP 中的执行路径与优化要点

前言

窗口函数（Window Function）在 OLAP 场景中使用频率高，能在不折叠行数的前提下计算排名、累计和、移动平均等指标。GBase 8a 作为 MPP 数据库，其窗口函数执行路径与单机数据库存在明显差异：PARTITION BY 指定的分组键必须与当前数据分布匹配，否则优化器会在窗口计算前插入 REDISTRIBUTE 算子，产生额外的跨节点数据传输。

本文面向 DBA 和 SQL 开发，说明 GBase 8a 窗口函数的执行机制、EXPLAIN 计划的关键看点，以及如何通过分布键选型和 SQL 改写减少重分布开销。前提知识：已了解 GBase 8a 的 Coordinator/DataNode 模型和 EXPLAIN 基本输出格式。

---

窗口函数在 MPP 中的执行原理

GBase 8a 将查询拆分为多个执行阶段（Stage），每个 Stage 内各 DataNode 并行执行；Stage 之间通过 Motion 算子传输数据。对于窗口函数，核心决策点在于：PARTITION BY 键是否与表的分布键（Distribution Key）一致。

情形一：PARTITION BY 键与分布键一致

同一 PARTITION 的所有行已经落在同一 DataNode 上，窗口计算完全本地执行，不产生跨节点数据移动。这是性能最优的情形。

情形二：PARTITION BY 键与分布键不一致

优化器在窗口函数执行前插入 REDISTRIBUTE 算子，按 PARTITION BY 键将数据重新发送到各 DataNode。重分布代价取决于参与行数和网络带宽，在亿级大表上可能成为主要瓶颈。

以下语句中，若 orders 按 order_date 分布，则 PARTITION BY user_id 会触发重分布：

EXPLAIN
SELECT
    user_id,
    order_date,
    amount,
    SUM(amount) OVER (PARTITION BY user_id ORDER BY order_date) AS running_total
FROM orders;

| id | select_type | table  | type | rows   | Extra                                              |
|----|-------------|--------|------|--------|----------------------------------------------------|
|  1 | SIMPLE      | orders | ALL  | 500000 | Using filesort; Using window; REDISTRIBUTE by user_id |

Extra 中出现 REDISTRIBUTE by <列名> 即表示窗口计算前发生了重分布。

---

EXPLAIN 关键看点

1. REDISTRIBUTE 标记

Extra 信息	含义
REDISTRIBUTE by	窗口前触发重分布，数据按 `` 重新分发
Using window	执行了窗口函数计算
Using filesort	窗口排序需要额外排序操作
无 REDISTRIBUTE	PARTITION BY 键与分布键一致，本地计算

2. rows 估算准确性

重分布前的行数估算影响内存分配与落盘策略。若 rows 严重低估（如实际 500 万行但估为 1 万），应先执行 ANALYZE TABLE 更新统计信息，再重新分析 EXPLAIN 输出。

3. ROWS 与 RANGE 子句的差异

-- 基于物理行数的移动窗口
SUM(amount) OVER (
    PARTITION BY dept_id
    ORDER BY order_date
    ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
)

-- 基于值范围的滑动窗口
SUM(amount) OVER (
    PARTITION BY dept_id
    ORDER BY order_date
    RANGE BETWEEN INTERVAL '7' DAY PRECEDING AND CURRENT ROW
)

ROWS 和 RANGE 都要求 PARTITION BY 的所有行先聚集到同一节点，对 REDISTRIBUTE 的触发逻辑相同。两者的区别在排序语义：ROWS 依赖物理行序，RANGE 依赖值的逻辑区间，处理重复 ORDER BY 值时结果不同。

---

常见场景与排查步骤

场景一：按地区计算分区排名

SELECT
    region_id,
    merchant_id,
    txn_date,
    txn_amount,
    RANK() OVER (PARTITION BY region_id ORDER BY txn_amount DESC) AS region_rank
FROM daily_txn
WHERE txn_date = '2024-01-15';

排查步骤：

1. 确认 daily_txn 的分布键：

SHOW CREATE TABLE daily_txn\G

找到 DISTRIBUTE BY HASH(...) 子句中的列名。

2. 若分布键为 txn_date，则 PARTITION BY region_id 触发 REDISTRIBUTE。过滤条件 WHERE txn_date = '...' 已限制分区裁剪范围，但重分布量仍取决于当日数据行数。
3. 若 region_rank 计算是高频需求，评估将分布键改为 region_id 或 region_id, txn_date 联合分布的可行性。

场景二：用户行为序列的时间间隔

SELECT
    user_id,
    event_time,
    LAG(event_time, 1) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_event_time
FROM user_events
WHERE event_time >= '2024-01-01'
ORDER BY user_id, event_time;

若 user_events 按 event_date 分布，PARTITION BY user_id 必然引发重分布。重分布量 = 过滤后总行数，因此先过滤再开窗是减少代价的直接手段：

WITH recent AS (
    SELECT user_id, event_time
    FROM user_events
    WHERE event_time >= DATE_SUB(CURDATE(), INTERVAL 30 DAY)
)
SELECT
    user_id,
    event_time,
    LAG(event_time, 1) OVER (PARTITION BY user_id ORDER BY event_time) AS prev_event_time
FROM recent;

场景三：多个窗口函数合并

SELECT
    dept_id,
    employee_id,
    salary,
    RANK() OVER (PARTITION BY dept_id ORDER BY salary DESC)   AS dept_rank,
    AVG(salary)  OVER (PARTITION BY dept_id)                  AS dept_avg
FROM employees;

若两个窗口函数的 PARTITION BY 相同，GBase 8a 优化器通常只执行一次 REDISTRIBUTE 和一次数据排序，整合计算。若 PARTITION BY 不同，则各触发一次重分布，需拆分 SQL 或用 CTE 中间化，根据实际查询计划判断哪种更优。

---

分布键设计建议

按窗口函数频率选分布键

若某个列在业务中频繁作为 PARTITION BY 键（如用户分析类场景的 user_id，报表场景的 dept_id），应优先将该列设为分布键。建表示例：

CREATE TABLE user_events (
    user_id     INT          NOT NULL,
    event_time  DATETIME     NOT NULL,
    event_type  VARCHAR(32)
) DISTRIBUTE BY HASH(user_id);

此后，所有 PARTITION BY user_id 的窗口函数均可本地执行，无 REDISTRIBUTE。

避免在 PARTITION BY 中使用函数

-- 不推荐：对 order_date 应用函数，即使分布键是 order_date 也会触发重分布
SUM(amount) OVER (PARTITION BY DATE_FORMAT(order_date, '%Y-%m') ORDER BY order_date)

-- 推荐：在数据模型层预计算 order_month 列，直接按该列分布和分区
SUM(amount) OVER (PARTITION BY order_month ORDER BY order_date)

函数作用于分布键列后，列值已改变，优化器无法判断行是否已按该函数结果聚集，必须重分布。

联合分布键的适用场景

若业务既有 PARTITION BY dept_id 又有 PARTITION BY region_id，单列分布键无法兼顾两者。可考虑：

• 按主要查询场景选分布键（优先覆盖频次最高的窗口函数）
• 或将高频的 region_id 维度做成复制表（REPLICATED），通过全节点副本避免 Broadcast 和 REDISTRIBUTE

---

统计信息维护对窗口函数的影响

行数估算偏差会影响 REDISTRIBUTE 前的内存预分配和是否触发落盘（spill to disk）。以下两种情形需要及时执行 ANALYZE：

情形	现象	处理
大批量 INSERT 后	EXPLAIN rows 严重低估，实际执行内存不足	ANALYZE TABLE
分区替换或截断后	统计信息基于旧分区，与当前数据不匹配	替换后立即 ANALYZE

-- 更新单表统计信息
ANALYZE TABLE user_events;
ANALYZE TABLE orders;

ANALYZE 完成后，重新执行 EXPLAIN 确认 rows 估算是否合理（与 SELECT COUNT(*) 结果量级相符）。

---

小结与检查清单

在 GBase 8a 中遇到窗口函数查询慢时，按以下顺序检查：

1. 确认分布键：SHOW CREATE TABLE 找 DISTRIBUTE BY HASH(...) 子句
2. EXPLAIN 看 REDISTRIBUTE：Extra 出现 REDISTRIBUTE by 则对照 PARTITION BY 键，评估分布键调整
3. 先过滤再开窗：用 CTE 或子查询缩减参与行数后再执行窗口计算
4. 合并同 PARTITION BY 的窗口函数：写在同一 SELECT，减少重分布次数
5. 更新统计信息：大批量加载或分区替换后执行 ANALYZE TABLE，确保行数估算准确
6. 函数不放 PARTITION BY：预计算为列，避免因函数求值后与分布键不匹配触发重分布