我遇到了真正的问题,让AWS IoT Analytics Delta窗口(文档(工作。
我正在尝试设置它,以便每天运行查询以获取最后1小时的数据。根据文档,schedule
功能可用于使用CRON表达式(在我的情况下每小时(运行查询,并且delta window
应将我的查询限制在指定的时间窗口中仅包括记录(在我的情况下,最后一个小时(。
我正在运行的SQL查询只是SELECT * FROM dev_iot_analytics_datastore
,如果我不包含任何Delta窗口,我会根据预期获得记录。不幸的是,当我包括三角洲表情时,我一无所获。我离开了大约10天的数据,因此数据库中有几百万个记录。鉴于我不确定最佳格式是什么,我将以下时间字段包括在条目中:
datetime : 2019-05-15T01:29:26.509
(A string formatted using ISO Local Date Time)
timestamp_sec : 1557883766
(A unix epoch expressed in seconds)
timestamp_milli : 1557883766509
(A unix epoch expressed in milliseconds)
也有一个称为__dt
的AWS自动添加的值,该值使用与我的datetime
相同的格式,除非它在1天之内似乎是准确的。即,在给定的一天内输入的所有值都具有相同的值(例如2019-05-15 00:00:00.00
(
我尝试了来自标准SQL和Presto的一系列表达式(包括建议的AWS表达式(,因为我不确定哪个用于此查询。我知道他们将PRESTO子集用于分析,因此他们将其用于三角洲是有道理的,但是文档只是说' ...任何有效的SQL Expression '。
表达式我已经尝试过没有运气的时间:
from_unixtime(timestamp_sec)
from_unixtime(timestamp_milli)
cast(from_unixtime(unixtime_sec) as date)
cast(from_unixtime(unixtime_milli) as date)
date_format(from_unixtime(timestamp_sec), '%Y-%m-%dT%h:%i:%s')
date_format(from_unixtime(timestamp_milli), '%Y-%m-%dT%h:%i:%s')
from_iso8601_timestamp(datetime)
您使用的偏移和时间表达参数是什么?
由于Delta Windows有效地插入了SQL中,因此您可以手动将过滤器表达式插入数据集的查询来解决问题。
也就是说,将Delta窗口过滤器应用于-3分钟(负(偏移量和'frof_unixTime(my_timestamp('时间表达式到'从my_datastore中选择my_field'查询'QUERY'QUERY'QUERY'QUERY转换为等效查询:
>SELECT my_field FROM
(SELECT * FROM "my_datastore" WHERE
(__dt between date_trunc('day', iota_latest_succeeded_schedule_time() - interval '1' day)
and date_trunc('day', iota_current_schedule_time() + interval '1' day)) AND
iota_latest_succeeded_schedule_time() - interval '3' minute < from_unixtime(my_timestamp) AND
from_unixtime(my_timestamp) <= iota_current_schedule_time() - interval '3' minute)
尝试使用类似的查询(没有delta时间过滤器(具有正确值的值,以进行偏移和时间表达式,并查看您获得的内容,(...之间的_dt(只是限制扫描的分区的优化。您可以为故障排除而将其删除。
请尝试以下内容:
- 将查询设置为
SELECT * FROM dev_iot_analytics_datastore
- 数据选择过滤器:
- 数据选择窗口:
Delta time
- 偏移:-1小时
- 时间戳表达:
from_unixtime(timestamp_sec)
- 数据选择窗口:
- 等待数据集内容运行一会儿,例如15分钟或更长时间。
- 检查内容
经过数周的测试并尝试了本文中的所有建议以及更多的建议,似乎非常技术性的答案答案是要"关闭并返回"。我删除了整个分析堆栈,并用不同的名称重建所有内容,现在似乎正在工作!
重要的是,即使我由于实际分辨率而将其标记为正确的答案。@populus和@Roger提供的答案都是正确的,如果我的部署按预期运行。
在SQL查询中使用这些功能解决了问题:
-
iota_current_schedule_time()
:返回当前查询的时间戳。 -
iota_latest_succeeded_schedule_time()
:返回成功的先前查询的时间戳。
所以,下一个查询:
SELECT <field_1>, <field_2>, <...>
FROM <datastore_name>
WHERE from_unixtime(<timestamp_field>) BETWEEN
iota_current_schedule_time() AND
iota_latest_succeeded_schedule_time()
您正在获取在上一个成功的查询和实际查询之间存储在数据存储中的数据。这是与三角洲窗口相同的动作。from_unixtime()
功能返回与iota_current_schedule_time()
和iota_latest_succeeded_schedule_time()
的类型。
您可以在此处找到有关时间戳类型的更多信息:https://prestodb.io/docs/current/functions/dateTime.html
我偶然发现将SELECT * FROM datastore
更改为SELECT id1, id2, ... FROM datastore
解决了问题。
编辑20/03:
我发现了根本原因(至少在我的情况下(。
随着它的使用,让我们尝试解释:
查询仍然是:从数据存储中选择 * *和Delta窗口基于:From_unixTime(TIMESTAMP/1000(时间表 - cron表达式-Cron(0/1 * * *? *(
"时间戳"变量(在数据窗口中(是在IoT Core规则SQL:SELECT *,TIMESTAMP((为TIMESTAMP ...
的过程中定义的误解是,物联网核心规则执行与数据存储在数据存储中的存在之间存在延迟(可能是一分钟左右(。然后,时间戳是消息到达IoT Core而不是消息到达数据存储的时候。
IoT Analytics SQL查询基于" Timestamp"。执行此查询后,它正在查看t = now((和t-1m = iota_latestrongucceeded_schedule_time((((之间的消息时间戳。在此查询中,在此窗口中可以包含在IoT Core中收到的消息,但仍在数据存储中不存在。答案是空的,然后我认为Delta窗口是故障的:/不是这样,消息只是在数据存储的路上。
在我的情况下,经常看到问题,因为时间表频率(1分钟(与消息传播的延迟持续时间相同。如果频率要高得多(景象的一天(可能会丢失一些信息,并且很难理解原因。
解决方法:我已经在IoT Analytics Pipeline中创建了一个LAMBDA,以在lambda执行的末尾向消息添加新的时间戳(TS_LAMBDA((在消息进入数据存储之前(。
(。然后,Delta窗口现在基于:From_unixTime(ts_lambda/1000(
现在每件事都可以,没有更多的消息丢失。