当数据在表中的更高位置不是紧挨所讨论的行的旁边重复时，为什么SQL LAGHIVE的差值为0？

问题描述

我有一个这样的HIVE表：

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个时间戳记会重复。

实际的HIVE表具有大约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

...为真实的HIVE表提供如下输出：

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

第二行显示了预期的输出，因为实际HIVE表中的时间窗口为26天，这是7488个5分钟的观测值（以上为7486，但忽略了差异）。

令人惊讶的结果显然是第一行，显示11976480的命中数为0滞后。这几乎是HIVE表中的所有行。我假设这意味着自时间窗口（26天）以来，重复被认为时间戳之间的差异为0。但是我希望延迟不关心重复，而只是给出数据中遇到的行之间的差异。换句话说，我原本希望每5分钟就有1200万个滞后。这是因为实际表中大约有1600种不同的设备，并且它们都有26天的时间窗口（7488个不同的5分钟间隔），而1600 x 7488大约为1200万。

sql中的滞后是否使用排列或组合，而不是仅逐行评估时间戳的差异？

解决方法

我认为您要每个设备的计算，所以您应该使用：

    lag(timestamp) over (partition by metric,device order by timestamp) as lag_ts

至此声明：

但是我希望延迟不关心重复，而只是给出数据中遇到的行之间的差异。

您的期望仅不适用于SQL数据库。 SQL表表示无序集。 lag()关于排序和分区的所有知识都在lag()表达式本身中。

hiveql sql sql