必须为lag指定默认值（如时间型用'1970-01-01'）、正确使用partition by和确定性order by（如ts, record_id），并用unix_timestamp等统一单位计算差值判断断点。
LAG函数在Spark SQL里怎么写才不会返回NULL
直接用 LAG 而不指定默认值，前一行不存在时必然返回 NULL——这会让后续的“是否断点”判断失效。必须显式传入第二个参数（默认值），且该值需与业务逻辑兼容。
比如按时间排序识别设备心跳中断，LAG(timestamp, 1, '1970-01-01') OVER (PARTITION BY device_id ORDER BY timestamp) 比裸调用 LAG(timestamp) 更可控；否则一旦首条记录参与计算，timestamp - LAG(timestamp) 就是 NULL，整个差值列报废。
- 默认值不能填
NULL，否则等于没设 - 数值型字段建议用极小值（如
0或-1），时间型建议用远古时间（如'1970-01-01'） - 分区键（
PARTITION BY）漏写会导致跨设备混算，断点识别完全失真
如何用LAG结果判断“连续”还是“断点”
LAG本身只取前值，断点逻辑得靠你补全：通常是当前值减去前值，再和阈值比较。但要注意单位统一和空值穿透问题。
例如检测传感器数据是否间隔超5分钟中断：
SELECT ts, LAG(ts, 1, '1970-01-01') OVER (ORDER BY ts) AS prev_ts, (unix_timestamp(ts) - unix_timestamp(LAG(ts, 1, '1970-01-01') OVER (ORDER BY ts))) > 300 AS is_gap FROM sensor_data
- 必须用
unix_timestamp()把字符串时间转成秒数再相减，直接减字符串会报错 - 如果
ts是timestamp类型，可改用ts - INTERVAL 5 MINUTES > LAG(ts)，更安全 -
is_gap为TRUE表示当前行是断点后的第一条数据（即断点发生在上一行之后）
为什么按时间排序后还是出现乱序断点误判
Spark SQL的窗口函数依赖排序稳定性。如果 ORDER BY 字段存在重复值（比如毫秒级时间戳被截断、或批量写入导致相同时间戳），LAG 的“前一行”就不可预测，断点位置会漂移。
- 务必在
ORDER BY中加入唯一性字段兜底，例如ORDER BY ts, record_id - 避免仅用
ORDER BY date（精度太粗），断点检测会失效 - 分区键（
PARTITION BY）和排序键不匹配时（如按用户分组却按全局时间排序），LAG结果毫无意义
性能坑：LAG套子查询或JOIN后变慢十倍
LAG必须在最终结果集上计算，如果先 JOIN 大表再开窗，Shuffle量爆炸；更糟的是在子查询里嵌套LAG，Spark可能无法优化执行计划。
- 把
LAG放在最外层查询，上游只做必要过滤（WHERE）和轻量投影 - 避免
SELECT * FROM (SELECT ..., LAG(...) OVER (...) FROM t) t2 JOIN ...这种结构 - 对超大表，考虑先用
ROW_NUMBER()打标+广播小维度表，再用LEFT JOIN补前值，有时比LAG更快
实际跑通的关键不在函数本身，而在排序键的确定性、默认值的业务合理性、以及窗口定义是否真正对应你的“连续”语义——这三个地方错一个，断点就识别歪了。
