Partition by dimension in metrics_anomaly_score

[nescobar]

Describe the bug
In metrics_anomaly_score.sql, the metric_value is not partitioned by dimensions when using the dimension properties. This affects the calculation of the anomaly score since it is derived from the average of the metric values across ALL dimensions.

To Reproduce
Steps to reproduce the behavior:

In the code below, the metric_value is not being partitioned by dimensions:

avg(metric_value) over (partition by metric_name, full_table_name, column_name order by bucket_start asc rows between unbounded preceding and current row) as training_avg

Expected behavior
The average metric_value should be partitioned by dimension_value when dimensions are being used

avg(metric_value) over (partition by metric_name, full_table_name, column_name, dimension_value order by bucket_start asc rows between unbounded preceding and current row) as training_avg

[wbarth11]

We are encountering the same thing here. Just to add to what @nescobar mentioned, in cases where there may be multiple dimensions named the same thing, I think we would also want to include dimension in the partition, as well.

avg(metric_value) over (partition by metric_name, full_table_name, column_name, dimension, dimension_value order by bucket_start asc rows between unbounded preceding and current row) as training_avg

[Sora-hotaru]

I am experiencing the same issue, but I think the {project}_elementary.metrics_anomaly_score table is not currently used for alerts—just my opinion. This is because, although a record has the value is_anomaly=false, the test corresponding to that record has failed in my test. In addition, the values of training_stddev, training_avg, and training_start are also different from the actual ones. The correct values are recorded in the {project}_elementary.test_result_rows table, and the alerts are based on this table.

Does anyone know about this?