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

【问题标题】：Custom timestamp is not taken into account in blob path for Stream analytics流分析的 blob 路径中不考虑自定义时间戳
【发布时间】：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”作为一列来确认行为。

标签： azure-blob-storage azure-stream-analytics

【解决方案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。
仔细观察后，在 Azure Portal 上运行查询时 system.timestamp 属性发生了变化，但它实际上并没有生成正确的路径。
我正在努力重现您的情况，但我可能会错过赏金截止日期。对我来说，路径正在完美调整，但我没有尝试弄乱设置，所以我不确定你可能会做些什么不同的事情。我正在完成大四的最后一个学期，我的大学正在忙着工作哈哈！会尽快为您解决这个问题！
如果我能得到这个旋转，我没有问题再次添加赏金。您是在 vs 中还是在门户中进行测试？您能否分享您正在测试的确切查询和路径设置，这些设置正在工作和测试数据。你也调整了一天以上吗？此外，我收到的传感器数据可能长达 3 年，这意味着我必须超出迟到阈值，或者将其关闭，我不确定这是可能的。
我正在使用 Visual Studio，我目前没有使用生成 3 年前数据的测试用例（我只玩了几天），所以我会切换它并进行更好的测试。不过，我对您的问题有一个理论……它可能与Side effects of event ordering time tolerances 的第 5 节有关。 “System.Timestamp 值与 事件时间 字段中的时间不同。”我担心活动时间可能会改变路径？