Hive窗口函数RANGE仅支持数值型偏移，需将时间列转为unix_timestamp(ts)等数值类型；ORDER BY必须存在且ts不能为NULL；5分钟滑动求和应写为SUM(amount) OVER (ORDER BY unix_timestamp(ts) RANGE BETWEEN 300 PRECEDING AND CURRENT ROW)。
Hive 本身不处理实时流，所谓“流控统计”实际是用窗口函数模拟滑动时间窗口的批式近似计算。关键不是“流”，而是如何让 RANGE 窗口真正按物理时间生效——多数失败都卡在时间类型和排序上。
为什么 OVER (ORDER BY ts RANGE BETWEEN ...) 总是返回空或全为 NULL
因为 Hive 的 RANGE 窗口只认数值型偏移，不认 TIMESTAMP 或字符串时间。哪怕 ts 是 TIMESTAMP 类型，Hive 3.1+ 也默认不支持直接用于 RANGE 计算（需显式转为 DOUBLE）；若仍是 STRING（如 '2023-05-01 10:30:45'），RANGE 完全失效，窗口不覆盖任何行。
- 先用
unix_timestamp(ts)转成秒级整数（推荐），或cast(unix_timestamp(ts) as DOUBLE) -
ORDER BY必须存在且非空——没它，RANGE报错或行为未定义 - 检查
ts列是否有NULL：有则整行被排除出窗口；重复值在RANGE中会合并处理，可能掩盖预期结果 - 加个
COUNT(*) OVER (ORDER BY unix_timestamp(ts) RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW)辅助验证窗口是否真在“动”
怎么写一个 5 分钟滑动求和（含当前事件）
核心是把时间对齐到统一数值尺度，再用秒数做偏移。别信 INTERVAL '5' MINUTE，Hive 不支持这种写法，会直接报语法错误。
- 如果
ts是标准TIMESTAMP或可解析的STRING：unix_timestamp(ts)返回秒数，300 PRECEDING即向前推 5 分钟 - 如果
ts是毫秒时间戳（如1683091845123）：unix_timestamp(cast(ts/1000 as BIGINT))或更稳妥地cast(ts/1000 as DOUBLE) - 完整示例：
SUM(amount) OVER (ORDER BY unix_timestamp(ts) RANGE BETWEEN 300 PRECEDING AND CURRENT ROW) - 注意：这个窗口是“事件时间”驱动，不是处理时间；数据乱序时结果不可靠，需预排序或补
PARTITION BY控制范围
当需要“最近一条满足时间条件的记录”而非固定区间聚合时
RANGE 框架做不到“取前 N 行中时间差最小的那个”，它只做数值范围聚合。此时必须退回到 LAG + 手动判断逻辑。
- 用
LAG(ts, 1) OVER (PARTITION BY user_id ORDER BY ts)拿上一行时间 - 用
unix_timestamp(ts) - unix_timestamp(prev_ts) 判断是否在 7 分钟内 - 配合
CASE WHEN返回对应字段（如LAG(amount, 1)），否则填NULL - 这种写法性能比
RANGE差，但逻辑可控；若数据量大，建议先用DISTRIBUTE BY user_id减少 shuffle
最易被忽略的一点：Hive 窗口函数的默认帧是 RANGE BETWEEN UNBOUNDED PRECEDING AND CURRENT ROW，但前提是写了 ORDER BY；如果只写 PARTITION BY 没写 ORDER BY，默认帧其实是无界全分区，根本不是“累计”效果——这会导致移动平均、滑动求和类统计完全跑偏。
