窗口函数触发全量Shuffle是因为需将同一PARTITION BY值的数据重分布到同一节点排序或累积计算，若分区字段非物理分片键则必shuffle；全表窗口更会单点汇聚致OOM。
窗口函数为什么触发全量Shuffle
因为窗口函数（如 ROW_NUMBER()、RANK()、SUM() OVER (PARTITION BY ... ORDER BY ...)）必须对指定 PARTITION BY 的全部数据做排序或累积计算，而分布式数据库（如 Spark SQL、Flink SQL、Doris、StarRocks）的数据天然分散在多个节点上。只要 PARTITION BY 字段不是数据的物理分片键（shard key），系统就必须把所有匹配同一分区值的行重分布到同一个节点——这就是 Shuffle。
常见错误现象：EXPLAIN 输出中看到大量 Exchange 或 Repartition 节点；任务监控显示 shuffle write/read 量远超原始输入大小；执行时间集中在 Stage 2+ 阶段。
- 即使只
PARTITION BY user_id，只要user_id在存储时未按其哈希分片，就大概率触发跨节点拉取 -
ORDER BY子句会让开销进一步放大：不仅要重分布，还要在目标节点做全局排序（非局部 sort） - 若未指定
PARTITION BY（即全表窗口），等价于单分区，强制所有数据汇聚到一个节点，极易 OOM 或拖慢整个集群
哪些窗口函数能避免或减少 Shuffle
并非所有窗口函数都必然引发重分布。关键看是否依赖跨行比较/累积，以及执行引擎能否下推优化。
-
COUNT(*) OVER ()（无 partition）在部分引擎（如 StarRocks 3.2+）可转为广播聚合 + 本地累加，不 shuffle；但 Spark SQL 仍会 shuffle -
LAG(col, 1) OVER (PARTITION BY a ORDER BY b)必须 shuffle：需要按a分组 + 按b排序后逐行取前一行，无法拆分 -
FIRST_VALUE(col) OVER (PARTITION BY a)（无ORDER BY）在 Doris 中可能用 hash-agg 优化，跳过排序 shuffle；但语义不明确时行为不稳定 - 带
RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW的累计求和，在多数引擎中仍需排序后 scan，无法绕过 shuffle
如何验证和定位 Shuffle 瓶颈
不能只看 SQL 写得“简洁”，得看执行计划和运行时指标。
- 在 Spark SQL 中执行
EXPLAIN FORMATTED your_sql，重点找Exchange类型为REPARTITION或REPARTITION_BY_EXPRESSION的节点，并检查其输入行数是否远大于源表 - 在 Flink Web UI 的 “Task Managers → Metrics” 中查看
shuffleWriteBytes和shuffleReadBytes，若二者之和是输入数据的 5 倍以上，说明窗口设计有问题 - Doris 执行
EXPLAIN VERBOSE后，关注Fragment列中是否出现AGGREGATE+EXCHANGE组合，且Partition Columns与表实际DISTRIBUTED BY不一致 - StarRocks 的
SHOW PROC '/statistic'可查各 fragment 的ShuffleSendRows，结合EXPLAIN中的PartitionExprs对齐分析
替代方案：用 Join 或预聚合绕过窗口函数
当窗口逻辑本质是“每个用户最新一条记录”或“每组 topN”，强行用 ROW_NUMBER() OVER (...) = 1 往往是最慢解法。
- 用
GROUP BY + MAX(time)先聚合出每组最大时间，再自 join 原表取完整行，通常比窗口快 2–5 倍（尤其数据倾斜时） - 在写入端预计算：例如用 Flink CDC 实时写入时，同步维护一张
user_latest_profile表，查询直接走主键点查 - StarRocks 支持物化视图自动刷新，定义
SELECT user_id, MAX(event_time), ... GROUP BY user_id，查询时优化器可自动路由 - 如果只是去重取首行，
DISTINCT ON (a) ... ORDER BY a, b（PostgreSQL）或QUALIFY ROW_NUMBER() = 1（Snowflake/Doris）语义等价，但底层实现可能复用已有索引，不一定 shuffle
真正难优化的是带严格顺序语义的窗口（比如滑动平均、同比环比），这时候 shuffle 是刚性成本——别幻想“调参数就能消除”，优先确认业务是否真的需要实时窗口，还是可以接受 T+1 预聚合。
