PySpark窗口函数lag、row_number执行结果不一致问题求助

• 排序键隐式精度截断导致排序不稳定：你声明timestamp字段唯一非空，但实际执行中如果timestamp存储精度高于查询时隐式使用的精度（比如存储为纳秒精度，执行引擎默认截断到微秒/毫秒处理），会出现逻辑上的重复排序键，窗口函数在排序键重复时的行顺序是不确定的，lag函数取到的上一行值会随机变动，最终计数结果波动。row_number出现相同问题也是同样根因，排序不稳定导致行号分配随机。
• 时区隐式转换导致比较逻辑不一致：AWS Glue和Athena默认时区配置可能存在差异，或者作业运行时不同执行节点的时区参数不统一，timestamp类型在比较、排序时会发生隐式时区转换，导致相同的时间戳值被判定为不同，或者排序顺序发生变化。
• 数据源非静态：如果snapshots表是动态更新的表（比如流表、近实时同步的事务表），或者后台正在进行小文件合并、数据重分区、版本清理等操作，每次查询扫描到的文件列表可能存在差异，导致输入数据本身不一致。
• timestamp类型比较精度损失：originalcol为timestamp类型，直接使用!=比较时，部分引擎会做隐式类型转换（比如转成字符串、double类型），精度损失会导致原本相等的值被判定为不等，或者反之。

• 首先验证排序键的实际唯一性：执行查询select timestamp, count(1) as cnt from snapshots group by timestamp having cnt > 1确认是否存在重复的时间戳，即使字段声明唯一也需要验证，避免写入时的精度截断导致重复。
• 显式指定排序精度与次排序键：如果存在排序键重复，在窗口排序逻辑中增加次排序字段保证排序稳定性，比如partition by key order by timestamp, key（如果key全局唯一的话），同时显式转换时间戳到最高可用精度，比如order by cast(timestamp as timestamp(9))。
• 统一时区配置并使用数值比较：将Glue作业和Athena的会话时区统一设置为UTC，同时把timestamp的比较转换为数值比较避免隐式转换，比如将lg != originalcol替换为unix_millis(lg) != unix_millis(originalcol)（需要更高精度可以用unix_micros）。
• 验证数据源一致性：将snapshots表导出为静态的不可变文件集，基于静态文件重复执行查询，如果结果稳定则说明原表存在动态变更，可通过指定表的快照版本（如果是iceberg、hudi等事务表）、或者固定查询的文件路径解决。
• 规避保留字冲突：timestamp是SQL标准保留字，查询时用反引号包裹该字段，避免引擎解析错误导致的逻辑异常。

内容的提问来源于stack exchange，提问作者Tiago Marques