流分析的 blob 路径中不考虑自定义时间戳

Posted 2023-05-08

【中文标题】流分析的 blob 路径中不考虑自定义时间戳

【英文标题】：Custom timestamp is not taken into account in blob path for Stream analytics

【发布时间】：2020-04-03 11:41:09

【问题描述】：

给定一个如下所示的查询：

SELECT
    EventDate,
    system.Timestamp as test
INTO
    [azuretableoutput]
FROM
    [csvdata] TIMESTAMP BY EventDate

根据文档，EventDate 现在应该用作时间戳。 但是，当使用此路径将数据存储到 blobstorage 中时：

sadata/Y=datetime:yyyy/M=datetime:MM/D=datetime:dd

我似乎仍然需要摄取时间。就我而言，摄取时间毫无意义，我需要使用 EventDate 作为路径。这可能吗？

在 Visual Studio 中检查数据时，test 和 EventDate 应该相等，但结果如下所示：

EventDate                   ;Test
2020-04-03T11:13:07.3670000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.0460000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.0460000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:07.3670000Z;2020-04-09T02:16:15.5390000Z
2020-04-03T11:13:08.1470000Z;2020-04-09T02:16:15.5390000Z

延迟到货窗口设置为：99:23:59:59 乱序容差设置为：00:00:00:00，乱序操作设置为调整。

在 Azure 上的流分析中运行相同的查询时，我得到以下结果：

["eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z",
"eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z",
"eventdate":"2020-04-03T11:13:20.1060000Z","test":"2020-04-03T11:13:20.1060000Z"] 

到目前为止一切顺利。在 Azure 上使用数据运行查询时，它会生成以下路径：

 Y=2020/M=04/D=09

它应该产生这条路径： 年=2020/月=04/日=03 有趣的是，在检查实际存储在 blobstorage 中的数据时，我发现：

EventDate,test
2020-04-03T11:20:39.3100000Z,2020-04-09T19:33:35.3870000Z,

System.timestamp 似乎只在对采样数据进行查询测试时才会更改，但在查询正常运行并接收数据时实际上并未更改。

我已将延迟到达设置设置为 0 天和 20 天对此进行了测试。实际上，我需要禁用延迟到达调整，因为我可能会通过管道获得多年前的事件。

【问题讨论】：

当您测试查询或您的 blob 输出不使用路径时，您是否获得了所需的时间戳？

blob 始终将路径输出为当前日期，即使 eventdate 时间戳早于 2-3 天。所以我在输出时检查它，并通过 Visual Studio 对其进行测试。

“System.Timestamp”的值用于 blob 输出路径。 “System.Timestamp”通常使用“TIMESTAMP BY”中的值分配，但是，由于无序阈值和迟到阈值，这可能会有所不同。您可以选择“System.Timestamp”作为一列来确认行为。

【参考方案1】：

此问题已在MicrosoftDocs GitHub 上提出并关闭

微软人说：

延迟抵达的最长天数为 20 天，因此如果政策设置为 99:23:59:59（99 天）。调整可能会导致 System.Timestamp 出现差异。

通过定义延迟到达容忍窗口，对于每个传入事件，Azure 流分析将事件时间与到达时间进行比较；如果事件时间在容差窗口之外，您可以将系统配置为丢弃事件或将事件的时间调整到容差范围内。

考虑到水印生成后，服务可能会接收到事件时间低于水印的事件。您可以将服务配置为删除这些事件，或将事件的时间调整为水印值。

作为调整的一部分，事件的 System.Timestamp 被设置为新值，但事件时间字段本身并没有改变。此调整是事件的 System.Timestamp 可能与事件时间字段中的值不同的唯一情况，并且可能导致生成意外结果。

如需了解更多信息，请参阅Understand time handling in Azure Stream Analytics。

很遗憾，目前在 Azure 门户中使用示例数据进行测试并未将策略考虑在内。

其他可能有用的资源：

System.Timestamp() TIMESTAMP BY Event ordering policies Time handling Job monitoring

【讨论】：

我在问题中添加了更多信息，似乎 system.timestamp 属性根本没有改变，即使使用 TIMESTAMP BY。

仔细观察后，在 Azure Portal 上运行查询时 system.timestamp 属性发生了变化，但它实际上并没有生成正确的路径。

我正在努力重现您的情况，但我可能会错过赏金截止日期。对我来说，路径正在完美调整，但我没有尝试弄乱设置，所以我不确定你可能会做些什么不同的事情。我正在完成大四的最后一个学期，我的大学正在忙着工作哈哈！会尽快为您解决这个问题！

如果我能得到这个旋转，我没有问题再次添加赏金。您是在 vs 中还是在门户中进行测试？您能否分享您正在测试的确切查询和路径设置，这些设置正在工作和测试数据。你也调整了一天以上吗？此外，我收到的传感器数据可能长达 3 年，这意味着我必须超出迟到阈值，或者将其关闭，我不确定这是可能的。

我正在使用 Visual Studio，我目前没有使用生成 3 年前数据的测试用例（我只玩了几天），所以我会切换它并进行更好的测试。不过，我对您的问题有一个理论……它可能与Side effects of event ordering time tolerances 的第 5 节有关。 “System.Timestamp 值与 事件时间 字段中的时间不同。”我担心活动时间可能会改变路径？