【问题标题】:Date histogram expression does not break search span into buckets that are aligned with search span日期直方图表达式不会将搜索范围分成与搜索范围对齐的存储桶
【发布时间】:2019-05-05 15:01:37
【问题描述】:

我目前正在使用 Azure 时序见解来聚合我的数据。它为我提供了一种生成日期直方图的方法,我可以在其中指定搜索范围和存储桶大小。但是,bucket 的结果并没有达到我的预期。

例如,如果搜索范围是从 2016-08-01T01:00:00.000Z 到 2016-08-0 5T01:00:00.000Z,bucket size为1天,则bucket的结果如下,

从 2016-08-02T00:00:00.000Z 到 2016-08-03T00:00:00.000Z,

从 2016-08-03T00:00:00.000Z 到 2016-08-04T00:00:00.000Z,

从 2016-08-04T00:00:00.000Z 到 2016-08-05T00:00:00.000Z。

我从结果中观察到两种行为。首先,第一个桶没有与搜索范围对齐,从 2016-08-01T01:00:00.000Z 开始。其次,搜索跨度的头部和尾部是聚合的,即从2016-08-01T01:00:00.000Z到2016-08-02T00:00:00.000Z的数据和从2016-08-05T00:00:00.000Z的数据至 2016-08-05T01:00:00.000Z 不包括在内。

相反,我希望第一个存储桶与搜索跨度的起点对齐,并覆盖整个搜索跨度。目前在业务逻辑中需要计算bucket,并发查询多次,很快就会达到极限。

这种行为适用于所有时间单位,例如秒、分钟、小时和天。如果我将存储桶大小指定为 7 天,则存储桶的结果甚至会与星期一对齐。

由于我找不到有关此类行为的任何文档,因此,我的问题是,

如果可能的话,如何得到我预期的结果?

如果不是,Azure 推荐的服务是什么来实现我的目标?

【问题讨论】:

    标签: azure-timeseries-insights


    【解决方案1】:

    这是 TSI 设计的。行为解释here

    "对于指定的搜索范围和时间间隔,此 API 返回时间序列 ID 的每个变量的每个时间间隔的聚合响应。响应数据集中的时间间隔数是通过计数 epoch ticks 来计算的(经过的毫秒数自 Unix 纪元 - 1970 年 1 月 1 日以来)并将刻度除以查询中指定的间隔跨度大小。响应集中返回的时间戳是左间隔边界,而不是间隔中的采样事件。"

    目前没有解决此问题的好方法,客户必须自己处理。这是一个已知问题,TSI 有待解决的待办事项!请点赞反馈项here

    【讨论】:

      猜你喜欢
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 1970-01-01
      • 2016-10-15
      • 2016-10-14
      • 2018-12-30
      相关资源
      最近更新 更多