spark sql中avg() over()必须显式指定order by子句，否则报错；移动平均推荐用rows between 6 preceding and current row配合升序时间字段，分区计算需partition by与order by共存且升序，注意null处理、时区一致性和数据排序优化。
Spark SQL里AVG OVER窗口函数怎么写才不出错
直接说结论：Spark SQL支持标准SQL的AVG() OVER()语法，但必须显式定义ORDER BY子句，否则会报错AnalysisException: Window function AVG requires an ORDER BY clause。Spark不接受无序窗口——哪怕你只想按行号滑动，也得先用ROW_NUMBER()或时间字段排序。
常见错误是照搬MySQL或PostgreSQL写法，漏掉ORDER BY，或者误以为PARTITION BY能替代它。实际上PARTITION BY只分组，不定义窗口内顺序，而移动平均依赖“前N行”这种有序概念。
- 必须搭配
ORDER BY，推荐使用时间戳字段（如event_time）或自增ID - 避免用
ORDER BY RAND()——窗口无意义，结果不可复现 - 如果原始数据没时间字段，可用
monotonically_increasing_id()生成近似序号，但注意它不保证全局单调（集群环境下可能重复）
计算7日移动平均：ROWS BETWEEN语法怎么配
移动平均的核心是控制窗口范围。ROWS BETWEEN比RANGE更可控，尤其当时间有空缺或重复时。例如“最近7天”在RANGE下容易因日期重复膨胀窗口，而ROWS BETWEEN 6 PRECEDING AND CURRENT ROW严格取当前行及往前6行——共7行。
示例：按天聚合后算7日销量均值
SELECT
sale_date,
daily_amount,
AVG(daily_amount) OVER (
ORDER BY sale_date
ROWS BETWEEN 6 PRECEDING AND CURRENT ROW
) AS moving_avg_7d
FROM daily_sales
-
6 PRECEDING表示从当前行往前数6行，加上当前行正好7个点 - 若想包含“未来3天”，写成
ROWS BETWEEN 3 PRECEDING AND 3 FOLLOWING，但业务上慎用——实时计算通常只看历史 - 注意
sale_date必须唯一且有序；如果有同天多条记录，先GROUP BY sale_date聚合，否则窗口会把同天多行全纳入
分区+滑动：按用户ID分别算30天行为均值
真实场景常需“每个用户独立计算移动平均”。这时PARTITION BY user_id必须和ORDER BY event_time共存，且ORDER BY必须在分区内部有意义——即每个用户的事件时间要可排序。
错误写法：PARTITION BY user_id ORDER BY event_time DESC会导致窗口倒序，CURRENT ROW变成最早那条，移动平均就反了。
- 始终用
ORDER BY event_time ASC（升序），确保“过去→现在”方向 - 若
event_time精度到秒但存在并发写入，加二级排序如ORDER BY event_time, log_id防歧义 - Spark 3.0+支持
UNBOUNDED PRECEDING，但慎用于长周期（如ROWS BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW会累积所有历史，内存压力大）
性能和NULL值怎么处理
窗口函数本身不触发Shuffle，但ORDER BY隐含Sort操作，若数据量大且未提前按窗口键排序，会显著拖慢。另外，AVG()自动忽略NULL，但如果你的指标字段本身含大量NULL，移动平均结果会出现“跳变”——比如连续5个NULL后突然一个有效值，均值直接等于该值。
- 上线前用
COUNT(*) OVER(...)检查窗口内有效行数，确认是否真有7个非NULL值 - 对关键指标，建议先用
COALESCE(amount, 0)填充，或用WHERE amount IS NOT NULL预过滤 - 大数据量下，优先在源头按
user_id, event_time排序存储（如Delta表Z-Order），减少运行时Sort开销
最易被忽略的是时间字段的时区和粒度一致性——比如前端传的是UTC时间，但窗口按本地时区解析，或者时间戳混用毫秒/秒级，会导致ORDER BY错乱，移动平均完全失真。动手前先SELECT MIN(event_time), MAX(event_time), COUNT(*)探查数据分布。
