Azure流分析测试查询编辑器与ComosDB和Blob中的最终输出不匹配

Question

我创建了Stream Analytics作业，并使用门户网站验证了查询产生了正确的输出。问题是当我启动Stream Analytics Job时，发送到CosmosDB的输出是完全不同且出乎意料的结果。

这是基本查询，它使用一些带有SlidingWindow的聚合函数：

SELECT src.DeviceID, System.Timestamp as Time, 
AVG(src.Value) as [AvgValue],
MIN(src.Value) as [MinValue],
MAX(src.Value) as [MaxValue],
COUNT(src.Value) as [SampleCount]
INTO [AvgOutputToCosmosDB]
FROM
[blob-stream-dev-testsample] as src TIMESTAMP BY src.DateTimeEndUTC
GROUP BY SlidingWindow(hour,1), src.DeviceID

我已经使用WITH语句并写入CosmosDB和Blob存储来测试上述交替，但是两者都具有相同的错误输出。

我希望每个设备ID的平均日志为576个。我得到的是每个设备ID的一条平均日志，它使用576条日志（SampleCount）计算平均值。

如上所述，在使用Azure门户测试查询时，它可以工作。每个设备平均576滚动小时。 我有：

1. 使用测试C＃应用程序计算滚动平均值验证门户中的输出，一切都很好。
2. 将CosmosDB集合配置为不受限制，并在deviceid上使用分区。我不认为这是CosmosDB，因为它发生在Blob存储中。

在测试中，我手动上传了JSON文件，还从blob存储中读取了JSON文件-门户再次正常运行。

有人看过吗？ 我想知道流分析作业使用的语言环境是否存在某种DateTime转换问题？

更新

我刚刚使用事件中心主题作为输入流测试了相同的查询，它既可以在门户中运行，也可以在运行SA Job时使用。 SA作业从Blob存储读取JSON文件时，肯定存在某种日期时间序列化问题。

Answer 1

blob与另一个输入之间的区别是我们到达时间的方式：对于blob，到达时间是从BlobLastModifiedUtcTime中读取的。这意味着，如果应用程序时间（src.DateTimeEndUTC）与到达时间（BlobLastModifiedUtcTime）之间的差大于延迟到达策略，则会对其进行调整，并且所有事件都将在同一时间窗口内。您可以找到与此设置here相关的更多信息。

我的建议是检查您当前的延迟到达政策，并确保事件在此政策结束前到达Blob。

顺便说一句，您是在流传输实时数据，还是正在重新处理历史数据？

如果您还有其他疑问，请告诉我。