Spark SQL 3.0+才真正支持RANGE窗口帧与TIMESTAMP类型组合；低版本会退化为ROWS或报错；需用INTERVAL字面量指定单位，ORDER BY仅限单个非空时间戳列，且RANGE性能差、易倾斜。
Spark SQL中RANGE窗口帧对时间戳字段的支持情况
Spark SQL从3.0开始才真正支持RANGE窗口帧与时间戳类型（TIMESTAMP、TIMESTAMP_LTZ）的组合。低于3.0版本（如2.4）即使语法不报错，实际计算也会退化为ROWS语义或抛出AnalysisException: RANGE is not supported with timestamp type。确认版本后，还需确保时间戳列是标准类型——不能是字符串或bigint模拟的时间戳。
正确写法：必须显式指定时间单位并使用INTERVAL字面量
Spark不接受直接写RANGE BETWEEN 1 HOUR PRECEDING AND CURRENT ROW这种自然语言式表达。必须用INTERVAL关键字配合精确单位，且单位需与时间戳精度匹配（例如TIMESTAMP默认到微秒，但INTERVAL 1 HOUR是合法的，而INTERVAL 30 MINUTES也行，但INTERVAL 1.5 HOUR会报错）。
常见有效写法：
RANGE BETWEEN INTERVAL 1 HOUR PRECEDING AND CURRENT ROWRANGE BETWEEN UNBOUNDED PRECEDING AND INTERVAL 7 DAYS FOLLOWINGRANGE BETWEEN INTERVAL 30 SECONDS PRECEDING AND INTERVAL 30 SECONDS FOLLOWING
错误写法示例：
-
RANGE BETWEEN 3600 PRECEDING ...（缺少INTERVAL和单位） -
RANGE BETWEEN '1 HOUR' PRECEDING ...（字符串字面量不被识别） -
RANGE BETWEEN INTERVAL '1' HOUR PRECEDING ...（引号导致解析失败）
ORDER BY必须是单个时间戳列，且不能有NULL
RANGE窗口依赖有序连续的时间值做距离计算。如果ORDER BY包含多个列（如ORDER BY event_time, user_id），Spark会拒绝执行，报错Only single sort column is allowed for RANGE window frame。更隐蔽的问题是NULL值：任何NULL时间戳都会导致该行被完全排除在窗口外（不是排最后，而是不参与计算），且不会触发警告。
安全做法：
- 提前过滤：
WHERE event_time IS NOT NULL - 或补默认值：
COALESCE(event_time, TIMESTAMP('1970-01-01'))（注意补的值会影响窗口范围） - 避免在
ORDER BY里混用升序/降序：ORDER BY event_time DESC可行，但不能ORDER BY event_time ASC, id DESC
性能隐患：RANGE比ROWS慢，且容易触发数据倾斜
Spark对RANGE窗口不做本地排序优化，每次都需要全局排序+全阶段shuffle。当时间粒度很粗（如按天聚合）、或存在大量相同时间戳（例如日志打点全落在整点），会导致一个task处理远超均值的数据量——典型的数据倾斜。相比之下，ROWS BETWEEN 100 PRECEDING AND CURRENT ROW能利用局部缓存，快一个数量级。
判断是否真需要RANGE：
- 业务逻辑是否严格依赖“过去一小时内所有事件”，而非“最近100条事件”？
- 时间戳是否有足够区分度？若90%记录的
event_time都精确到秒，且集中在某几分钟内，RANGE会放大倾斜。 - 考虑替代方案：先用
WINDOW函数分桶（如FLOOR(UNIX_TIMESTAMP(event_time) / 3600)），再按桶+ROWS聚合。
真正要用RANGE时，务必在PARTITION BY里加入高基数维度（如user_id、session_id），否则单个窗口可能横跨数GB数据。
