Azure Log Analytics中series_decompose_anomalies执行结果不一致问题

问题描述 #

在Azure Log Analytics工作区执行以下KQL查询时，每次返回的结果都不一致，尽管已确保：

• 使用固定不变的数据集
• 在series_decompose_anomalies中定义了所有参数（包括Seasonality）
• estimate_data_size的返回结果始终相同

原始查询：

MyTable
| where TimeGenerated > startofday(ago(60d)) and TimeGenerated < endofday(ago(1d))
| order by TimeGenerated asc
| where toint(dayofweek(TimeGenerated)/1d) in (1, 2, 3, 4, 5)
| extend DataSize = estimate_data_size(*)
| summarize DataSizeBins = sum(DataSize) by bin(TimeGenerated, 1h)
| summarize TimeGenerated = make_list(TimeGenerated), DataSizeBins = make_list(DataSizeBins)
| extend series_decompose_anomalies(DataSizeBins, 2, 5*24, 'none', 0, 'ctukey')
| mv-expand TimeGenerated to typeof(datetime), series_decompose_anomalies_DataSizeBins_ad_flag to typeof(real)
| where series_decompose_anomalies_DataSizeBins_ad_flag <> 0

原因 #

问题出在时序序列的生成顺序上：
Kusto的summarize运算符输出顺序是不确定的（由数据分片和执行计划决定）。即便你在查询开头加了order by TimeGenerated asc，但执行summarize by bin(TimeGenerated, 1h)后，分组的顺序会被打乱。后续用make_list生成时间和数据的列表时，如果没有明确对分组后的结果排序，列表内的时序数据顺序可能每次执行都不同——而series_decompose_anomalies是依赖严格有序的时序数据进行异常检测的，顺序混乱自然会导致结果不一致。

解决方案 #

在第一个summarize之后，添加order by TimeGenerated asc，确保分组后的时间序列严格按递增顺序排列，这样make_list生成的列表顺序就固定了：

MyTable
| where TimeGenerated > startofday(ago(60d)) and TimeGenerated < endofday(ago(1d))
| where toint(dayofweek(TimeGenerated)/1d) in (1, 2, 3, 4, 5) // 先过滤工作日再排序，优化性能
| order by TimeGenerated asc
| extend DataSize = estimate_data_size(*)
| summarize DataSizeBins = sum(DataSize) by bin(TimeGenerated, 1h)
| order by TimeGenerated asc // 关键步骤：固定时序顺序
| summarize TimeGenerated = make_list(TimeGenerated), DataSizeBins = make_list(DataSizeBins)
| extend series_decompose_anomalies(DataSizeBins, 2, 5*24, 'none', 0, 'ctukey')
| mv-expand TimeGenerated to typeof(datetime), series_decompose_anomalies_DataSizeBins_ad_flag to typeof(real)
| where series_decompose_anomalies_DataSizeBins_ad_flag <> 0

另外，把工作日的过滤步骤提前到排序之前，可以减少需要排序的数据量，提升查询性能。

内容的提问来源于stack exchange，提问作者Felix Bodmer