为什么SQL LAG(HIVE)会在数据在表中稍后的位置(而不是在有问题的行旁边)重复时给出0的差异?

device        metric            timestamp          value
 d_1         cpu_time      2020-08-15 00:05:00       10
 d_1         cpu_time      2020-08-15 00:10:00       12
 d_1         cpu_time      2020-08-15 00:15:00       08
 d_2         cpu_time      2020-08-15 00:05:00       62
 d_2         cpu_time      2020-08-15 00:10:00       14
 d_2         cpu_time      2020-08-15 00:15:00       10
 d_3         cpu_time      2020-08-15 00:05:00       12
 d_3         cpu_time      2020-08-15 00:10:00       44
 d_3         cpu_time      2020-08-15 00:15:00       60

因此,对于每个不同的设备,时间窗口显示10秒(05:00到15:00)。这意味着当数据中遇到新设备时,3个时间戳的集合 重复 .

实际的配置单元表有大约1200万行、数千个设备和一个 每个设备的总时间窗口 26天(而不是示例表中显示的10秒)。另外,时间戳之间的采样间隔是5秒(就像上面的示例表一样)。因此,实际表中的模式与示例表中的模式相同,只是更多的数据。

我运行以下查询以确定每个度量的采样间隔(预计为5分钟):

select
    metric,
    (unix_timestamp(timestamp) - unix_timestamp(lag_ts)) / 60 sampling_interval_minutes,
    count(*) no_hits
from (
    select 
        t.*, 
        lag(timestamp) over(partition by metric order by timestamp) lag_ts
    from my_table t
) t
group by metric, (unix_timestamp(timestamp) - unix_timestamp(lag_ts)) / 60 
order by metric, no_hits desc

…为实际配置单元表提供如下输出:

metric      sampling_interval_minutes     no_hits
cpu_time              0.0                 11976480
cpu_time              5.0                  7486
cpu_time           1445.0                   1
cpu_time             NULL                   1

令人惊讶的结果显然是第一行,显示11976480次点击,0次延迟。这几乎是配置单元表中的所有行。我假设这意味着从时间窗口(26天)开始 重复 . 这是因为在实际的表中有大约1600个不同的设备,它们都有26天的时间窗口(7488个不同的5分钟间隔),1600 x 7488大约是1200万。