我正在从事物联网项目。我有一个Raspberry pi,可将智能电表数据发送到Azure上的IoT eventhub。我使用Azure流分析作业读取数据。仪表读数每10秒发送一次。
我创建的查询之一使用滚动窗口来计算每小时的用电量。它从该窗口中计算出最大抄表读数,再减去使用滞后的前一个窗口的最大抄表读数。我正在使用来自IOT设备的时间戳,而不是默认的到达时间。
WITH onehourwindow AS
(
SELECT
max(total_low) * 1000 as max_low,
max(total_high) * 1000 as max_high,
max(gas) * 1000 as max_gas,
round(avg(current_consumption), 1) as avg_consumption,
max(timestamp) as max_timestamp
FROM
eventhuninputsmartmeter TIMESTAMP BY timestamp
GROUP BY TUMBLINGWINDOW(hour, 1)
)
SELECT
(max_low - LAG(max_low) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_low,
(max_high - LAG(max_high) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_high,
(max_gas - LAG(max_gas) OVER (LIMIT DURATION(hour, 1))) / 1000 as total_consumption_gas,
avg_consumption,
max_timestamp
INTO
MeterReadingSQLDB
FROM
onehourwindow
查询返回测试中的预期结果。这是测试结果中时间戳和消耗量的示例。不出所料,最新的时间戳记(最大值)是该小时的最后一个仪表读数,时间为59分50秒左右。
|----------------------------|---------------------------|
| max_timestamp | total_consumption_high |
|----------------------------|---------------------------|
|2020-02-28T22:59:52.1794730 | 1.171 |
|2020-02-28T21:59:51.6680430 | 0.500 |
|----------------------------|---------------------------|
当我运行查询作业时,我将以下结果写入我的SQL DB。现在,最新的时间戳(最大值)不是(时钟)小时的最后一个仪表读数,而是在54分钟处。如果我手动进行消耗量计算,可以看到使用的窗口是一小时,它不是从00开始,而是每小时55分钟。
|----------------------------|---------------------------|
| max_timestamp | total_consumption_high |
|----------------------------|---------------------------|
|2020-02-28T22:54:52.1300000 | 1.353 |
|2020-02-28T21:54:51.6830000 | 0.510 |
|----------------------------|---------------------------|
如何解决?我尝试了很多事情,但似乎无法解决。下面帖子的答案看起来很有希望,但是我的活动不会迟到,绝对不会迟到6分钟。因此仍然使用默认的事件排序策略。
Azure Stream Analytics 'TimeStamp By' in query doesn't works on job but works fine on test
是否有解决此问题的想法,以便使窗口的最大时间戳记在59分50秒左右?
谢谢!
托马斯
根据您的详细描述:您的测试作业很好,并且可以根据需要输出结果,我认为sql可能按预期工作。您可以考虑流数据源侧的原因和ASA作业的设置。
我正在使用IOT设备上的时间戳,而不是默认值到达时间。
基于ASA TIMESTAMP BY文档的statements,自定义时间戳可能会由于网络或其他因素而导致延迟。
我建议您在Windows函数中设置offsize参数来平衡此间隙。
由于您是基于事件有效负载中的时间戳进行处理的,因此您为您的工作所拥有的事件顺序策略可能正在过滤掉一些可能导致此问题的输入。您可以查看2 metrics了解是否是这种情况:
如果实际上输入事件晚点或乱序,请确保将您的event ordering policies配置正确,以包括或删除此类事件。您还应该尝试查看输入数据的示例,以查看时间戳是否符合预期。