You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Sep 12, 2024. It is now read-only.
Currently the AnomalyDetectionController class has a single detect function which runs anomaly detection for all 3 series types:
overall
sudim
data_quality
A more fine grained control would help in multiple scenarios down the line, including in cases where we would run anomaly detection for the overall kpi or a combination of overall and data_quality etc. giving the user a choice for what to run.
This would also help in handling scheduler load, by staggering anomaly detection for different series_type to coincide with live data updation.
Proposed Solution Implementation:
Creation of another field in the anomaly_params dictionary which will contain a series of flags signalling which series_type to run anomaly detection for.
The text was updated successfully, but these errors were encountered:
Status Quo of current architecture:
Currently the AnomalyDetectionController class has a single detect function which runs anomaly detection for all 3 series types:
A more fine grained control would help in multiple scenarios down the line, including in cases where we would run anomaly detection for the overall kpi or a combination of overall and data_quality etc. giving the user a choice for what to run.
This would also help in handling scheduler load, by staggering anomaly detection for different series_type to coincide with live data updation.
Proposed Solution Implementation:
Creation of another field in the anomaly_params dictionary which will contain a series of flags signalling which series_type to run anomaly detection for.
The text was updated successfully, but these errors were encountered: